Saltar al contenido principal

Manual de AGF App: ING – Ingeniería

Alcance

El área ING – Ingeniería es el núcleo de producción técnica de AGF. Reúne todo el trabajo de diseño, cálculo, especificación y generación de documentos técnicos.

Ingeniería es ambivalente: produce tanto hacia fuera (documentos para cliente, regulador) como hacia dentro (especificaciones para GEM, datos para Comercial, información para GP).

Su objetivo es registrar toda la actividad técnica de forma trazable, permitiendo que el trabajo deje un rastro completo de decisiones, especificaciones, versiones y cambios. Esta información es fundamental para que otros departamentos ejecuten correctamente y para que la empresa mejore estimaciones futuras.

1. Acceso y estructura​

En el menú lateral, abrir ING – Ingeniería. El área está formada por cinco módulos:

Informes

Consulta y creación de informes técnicos, estudios y análisis.

Diseño

Gestión del proceso de diseño: tareas, planos, modelos, iteraciones.

Documentos

Seguimiento de documentos técnicos entregables (memorias, planos, DTI, diagramas).

Búsqueda de comentarios

Consulta, filtrado y análisis de comentarios técnicos.

Reuniones

Registro de reuniones técnicas con cliente, otros departamentos, contratas.

nota

Los registros creados en Ingeniería se identifican con el origen ING. Aunque la aplicación utiliza una base de datos común, cada área muestra la información correspondiente a su origen. Esto permite que Comercial, GP y GEM accedan a información técnica cuando la necesitan, manteniendo segregación clara de responsabilidades.

2. Principios operativos de Ingeniería​

2.1. Proyecto, ambiente y fase técnica​

La actividad de ingeniería se organiza siempre a partir de:

  • Proyecto: Referencia del trabajo (cliente, localización, tipo).
  • Ambiente: Fase técnica del proyecto.

Ambientes típicos en Ingeniería:

  • Ingeniería Básica (IB): Estudio conceptual, pre-diseño, viabilidad técnica.
  • Proyecto Técnico (PT): Diseño preliminar, especificaciones principales, presupuesto técnico.
  • Ingeniería de Detalle (ID): Diseño detallado, cálculos completos, planos para fabricación.
  • Ingeniería de Ejecución (IE): Documentos finales para obra, ajustes de campo, fabricación.
  • Puesta en marcha (PM): Comisionado, pruebas, puesta en operación.

Cada ambiente tiene:

  • Documentos esperados.
  • Nivel de detalle.
  • Responsables.
  • Hitos y entregas.
consejo

Antes de crear una tarea o documento de ingeniería, ubicarse en el ambiente correcto. Un plano de Ingeniería Básica tiene diferente nivel de detalle que uno de Ingeniería de Ejecución. Confundirlos genera problemas.

2.2. Estructura jerárquica de tareas de ingeniería​

Las tareas se organizan en tres niveles claros:

Nivel 1: Grupo de tareas

Contenedor temático, no ejecutable. Ejemplos:

  • Diseño de planta.
  • Ingeniería de proceso.
  • Diseño civil.
  • Especificaciones mecánicas.
  • Sistemas de control.
  • Ingeniería de detalle de instalación eléctrica.

Nivel 2: Tarea principal

Acción concreta con entidad técnica. Ejemplos:

  • Preparar diagrama de flujo.
  • Diseñar layout de planta.
  • Especificar motores.
  • Calcular instalación eléctrica.
  • Redactar memoria descriptiva.
  • Generar plano de implantación.

Nivel 3: Tarea derivada (opcional)

Desglose de la tarea principal en bloques relevantes. Ejemplos:

  • Si "Diseñar sistema de ventilación" implica: revisar códigos, calcular caudales, seleccionar equipos, generar especificaciones.
aviso

Máximo tres niveles: Grupo → Tarea principal → Tarea derivada. Si es más pequeño, usar subtarea.

2.3. Subtareas: acciones concretas​

Las subtareas son acciones específicas derivadas de una tarea. Características:

  • Asignadas a una persona concreta.
  • Tienen fecha límite.
  • Tienen tiempo estimado.
  • Aparecen en la pantalla de inicio del asignado.
  • Son obligatorias si alguien debe hacer algo concreto.

Ejemplos:

  • Tarea principalDiseñar sistema de ventilación
    • SubtareaCalcular caudales de ventilaciónJuan5 sept3h
    • SubtareaRevisar normativa de ventilaciónMaría4 sept2h
    • SubtareaEspecificar equipos de ventilaciónPedro7 sept4h
    • SubtareaGenerar plano de ventilaciónJuan8 sept3h

Cuando Pedro termina su especificación, Juan puede empezar el plano (orden lógico visible).

2.4. Tiempo estimado, importancia y urgencia​

Al crear una tarea de ingeniería, indicar obligatoriamente:

  • Nombre: Descripción clara de qué se debe hacer.
  • Tiempo estimado (minutos): Fundamental para cálculo de urgencia y planificación.
  • Fecha límite: Cuándo debe estar lista.
  • Importancia: Asignación manual (Alta/Media/Baja).

La urgencia se calcula automáticamente según:

  • Tiempo restante para ejecutar.
  • Tiempo hasta fecha límite.
aviso

Sin tiempo estimado y fecha límite, no hay urgencia calculada. Esto puede distorsionar prioridades. Una tarea crítica sin tiempos puede parecer inofensiva.

2.5. Importancia vs. Urgencia​

  • Importancia: Cuán crítica es la tarea para el proyecto (Alto = afecta a entregas, cliente, hito).
  • Urgencia: Cuán pronto debe ejecutarse según tiempo disponible y fecha límite.

Ambas deben considerarse juntas:

  • Alta importancia + Alta urgencia = Acción inmediata.
  • Alta importancia + Baja urgencia = Planificar próximas 2 semanas.
  • Baja importancia + Alta urgencia = Resolver rápido pero no es crítica.
  • Baja importancia + Baja urgencia = Cuando haya capacidad.

2.6. Comentarios vs. subtareas​

Comentario: Deja constancia, explica decisión técnica, registra criterio, incidencia.

  • Uso: "Se ha decidido cambiar de acero al aluminio por peso".
  • Riesgo: Puede no generar acción visible.

Subtarea: Encarga acción concreta a alguien.

  • Uso: "Revisar especificación de material y hacer presupuesto alternativo con aluminio" (asignada a María, 3 sept).
  • Ventaja: Aparece en pantalla de inicio de María.

Regla práctica:

  • Si solo documentas decisión técnica → Comentario.
  • Si alguien debe hacer algo → Subtarea.

2.7. Fichajes de tiempo en Ingeniería​

Todo trabajo técnico se registra mediante fichajes:

  • Inicio de tarea: Iniciar fichaje.
  • Durante: Fichaje activo mientras trabajas.
  • Cambio de tarea: Detener fichaje anterior, iniciar el nuevo.
  • Fin de tarea: Detener fichaje.

Propósito:

  • Medir dedicación real vs. estimado.
  • Construir estadísticas (tiempo típico por tipo de ingeniería).
  • Identificar tareas que consumen más de lo esperado.
  • Mejorar estimaciones futuras.
aviso

Los fichajes automáticos se detienen a las 15:00. Es normal; no es un error. Así se evita que queden abiertos indefinidamente.

3. Informes técnicos​

El módulo Informes permite registrar y consultar informes generados desde Ingeniería. Un informe técnico recoge análisis, estudios, decisiones de diseño o información relevante para el proceso técnico.

Los informes de Ingeniería se almacenan con origen ING.

3.1. Acceso a un informe​

  1. Abrir ING – Ingeniería → Informes.
  2. Localizar mediante búsqueda o filtrado.
  3. Abrir el informe para consultar contenido.

Tipos de informes técnicos:

  • Informe de viabilidad técnica.
  • Análisis de alternativas técnicas.
  • Estudio de impacto ambiental.
  • Informe de especificaciones.
  • Informe de cálculos.
  • Informe de pruebas.
  • Análisis de fallos.

3.2. Permisos de informes​

El acceso depende de permisos sobre:

  1. Tipo de informe (p. ej., "Informe técnico", "Análisis de costos").
  2. Asunto del informe (p. ej., "Sistema de control", "Especificaciones de equipos").

Si falta alguno, el usuario no podrá acceder. Los permisos pueden ser individuales o por grupo.

4. Diseño: proceso y gestión de iteraciones​

El módulo Diseño es específico de Ingeniería. Gestiona el proceso de generación y refinamiento de documentos técnicos de forma iterativa.

4.1. Concepto de "Diseño" como proceso​

"Diseño" no es solo planos. Es el proceso completo de crear especificaciones técnicas, que incluye:

  • Lluvia de ideas y conceptos.
  • Evaluación de alternativas.
  • Cálculos y validación.
  • Generación de planos y esquemas.
  • Revisiones iterativas.
  • Incorporación de cambios.
  • Validación final.

4.2. Estructura del módulo Diseño​

En Diseño se organizan tareas por:

  • Proyecto.
  • Ambiente (IB, PT, ID, IE, PM).
  • Grupo de tareas (tema: proceso, mecánico, eléctrico, etc.).
  • Tarea principal (acción concreta).
  • Tarea derivada (desglose).
  • Subtareas (acciones asignadas).

4.3. Flujo de diseño iterativo: ejemplo completo​

CASO PRÁCTICO: Diseño de Sistema de Ventilación (Proyecto 240, PT)

Fase 0️⃣: Creación de estructura​

Tarea principal creada:

DatoValor
Nombre"Diseñar sistema de ventilación"
Proyecto240
AmbienteProyecto Técnico (PT)
Tiempo estimado20 horas
Fecha límite30 septiembre
Estado🟡 Abierta

Subtareas derivadas:

NºSubtareaAsignadoFechaTiempo
1Estudiar alternativas de ventilaciónJuan5 sept3h
2Calcular especificaciones técnicasMaría6 sept4h
3Generar plano preliminarPedro7 sept5h

Timeline Visual: Semana 1 de diseño​

DíaResponsableActividadEstadoComentario
5 septJuan 🧑‍💼Estudiar alternativas✅ Completo"Recomiendo sistema mixto: conductos + difusores directos. Opción más eficiente para esta configuración."
6 septMaría 👩‍💼Calcular especificaciones✅ Completo"Especificación: 15.000 m³/h. Potencia ventilador: 11 kW. ⚠️ CAMBIO: Inicial estimada 8 kW, pero cálculos dan 11 kW."
6 sept PMPedro 👨‍💼Recibe datos🔄 RevisandoNota inconsistencia: "En zona B los cálculos no coinciden con datos de entrada."
7 septPedro 👨‍💼Revisa y crea nueva subtarea⚠️ BloqueadoCrea: "👉 Revisar cálculo zona B (asignado a Juan)"
8 septJuan 🧑‍💼Revisa cálculo zona B✅ Completo"Error encontrado: entrada de aire zona B mal dimensionada. Corregido. María puede actualizar."
8 septMaría 👩‍💼Actualiza especificación✅ Completo"Especificación actualizada v0.2. Potencia final: 11.5 kW."
10 septPedro 👨‍💼Genera plano v1✅ Completo"Plano ventilación v1.0 generado. Listo para revisión cliente."

Fase 1️⃣: Iteración Cliente​

Estado actual del diseño:

ElementoEstadoVersiónObservación
Plano✅ Completadov1.0Listo para revisión cliente
Especificación✅ Completadov0.2Alineada con diseño v1.0
Fase actual🔄 En revisión—Esperando feedback cliente (deadline: 20 sept)
EventoFechaQuiénAcción
📬 Envío a cliente10 septPedroComentario: "Plano ventilación v1.0 enviado a cliente para revisión. Ubicación: Dropbox/.../240-PT-VEN-001-v1-r0.pdf. Esperamos feedback para 20 sept."
📞 Cliente solicita cambio18 septGP (recibe)Comentario en tarea: "Cliente solicita: zona B necesita difusores adicionales para mejor distribución. Cambio requerido."
👉 Nueva subtarea18 septPedroCrea: "Incorporar difusores adicionales zona B (cambio cliente)" → Asignado: Juan (19-21 sept)
✏️ Juan revisa y modifica21 septJuanComentario: "Plano zona B modificado. Añadidos 3 difusores. Especificación de caudal por difusor: 2.5 m³/s. Listo para nueva versión."
🔄 Pedro genera v222 septPedro"Plano ventilación v2.0 generado con cambio cliente. Especificación también v1.0."

Fase 2️⃣: Validación y cierre​

Estado de tarea: 🔴 EN SUPERVISIÓN (Responsables completaron el trabajo, esperando validación de supervisor técnico)

Checklist de validación:

  • ☑️ Plano final v2.0 generado y completo
  • ☑️ Especificación técnica v1.0 coherente con plano
  • ☑️ Todos los cambios cliente incorporados correctamente
  • ☑️ Tiempos fichados correctamente en AGF App
  • ☑️ Documentos generados y ubicados en almacenamiento
  • ☑️ Comentarios dejan rastro completo de decisiones y cambios

Acción supervisor: ✅ ACEPTAR

Comentario de cierre registrado:

"Validado. Diseño ventilación v2.0 correcto y completo. Cliente conforme. Especificación alineada con montaje. Tarea cerrada."

Estado final: 🟢 TAREA CERRADA

📊 Estadísticas de esta tarea​

MétricaValorObservación
Tiempo estimado20 horasEstimación inicial
Tiempo real fichado18.5 horasFichajes registrados en AGF App
Diferencia-1.5h✅ 1/12 menos de lo estimado (buena estimación)
Iteraciones2Diseño preliminar + cambio cliente
Cambios post-entrega1Zona B: adición de difusores
Personas involucradas3Juan, María, Pedro
Duración total17 días5 sept - 22 sept

Aprendizaje documentado: Los cálculos y especificaciones de sistemas de ventilación de esta complejidad tardan ~4-5 horas. Para presupuestos futuros similares, usar este dato como referencia en lugar de basarse en estimaciones genéricas.

🔄 Concepto clave: Iteración visible​

Cada cambio, decisión y problema es registrado como comentario. Los comentarios constituyen el histórico completo de por qué el diseño es exactamente así.

Ejemplo real: Pregunta futura: "¿Por qué hay 3 difusores en zona B y 2 en zona C?"

Con comentarios registrados: Buscar comentarios → Encontrar el registro exacto: "Cliente solicitó cambio zona B para mejor distribución de temperatura (18 sept). Incorporado en v2.0. Impacto: recalcular presión ventiladores. Aprobado."

Sin comentarios: Solo se ve el resultado final: "Hay 3 difusores en zona B." La razón, la decisión, el cambio, todo desaparece.

Conclusión: Los comentarios transforman un archivo de planos en un documento de conocimiento. Permiten que años después alguien entienda no solo qué se diseñó, sino por qué se diseñó de esa forma.

🎯 Lo que hace especial este flujo en AGF App:​

ElementoBeneficio
Subtareas asignadasCada persona ve su acción en pantalla de inicio. No se pierde ninguna acción.
Comentarios en cada pasoCada decisión, problema, cambio queda documentado.
Versiones explícitasv1.0, v2.0, r1, r2... Claridad total de qué cambió.
Fichajes de tiempoSaber exactamente cuánto tardó realmente cada parte.
Trazabilidad completa6 meses después: ¿qué se decidió y por qué? Los comentarios lo cuentan.
Integración con GEMEspecificación v2.0 contiene datos exactos para que GEM compre los difusores correctos.

4.4. Versionado de documentos dentro de Diseño​

Durante el diseño, los documentos evolucionan:

  • Versión 0.1: Concepto.
  • Versión 0.5: Diseño preliminar.
  • Versión 1.0: Diseño final (listo para entrega).
  • Revisión 1.1: Cambio menor post-entrega.

Los cambios menores = revisión (0.1 → 0.2). Los cambios mayores = versión (0.5 → 1.0).

Cadena de referencia: Proyecto-Ambiente-Nº-0[X]-0[Y]. Ejemplo: 240-PT-001-01-00 (Proyecto 240, PT, doc 001, versión 1, revisión 0).

5. Documentos técnicos​

El módulo Documentos registra y controla los documentos técnicos entregables. Los archivos se gestionan en almacenamiento externo (Dropbox), pero AGF App conserva trazabilidad completa.

5.1. Estructura documental de ingeniería​

  1. Proyecto
  2. Ambiente
  3. Entregable
  4. Documento

Entregables típicos de ingeniería:

FaseEntregables esperados
IB (Ingeniería Básica)Memoria IB, Presupuesto conceptual, Diagramas, Casos de estudio
PT (Proyecto Técnico)Memoria PT, Planos de implantación, Diagrama de flujo, Especificaciones, Presupuesto PT
ID (Ingeniería de Detalle)Memoria técnica, Planos de detalle (mecánico, eléctrico, civil), Cálculos, Listas de materiales, DTI
IE (Ingeniería de Ejecución)Planos finales, Documentación de montaje, Manuales, Especificaciones de soldadura/pintura, Certificaciones
PM (Puesta en marcha)Informe de pruebas, Diagramas de puesta en marcha, Procedimientos, Certificado de conformidad

5.2. Documentos dentro de un entregable​

Ejemplo: Entregable "Memoria de Proyecto Técnico" contiene:

  • Documento 1: Portada e índice.
  • Documento 2: Descripción del proyecto.
  • Documento 3: Alternativas técnicas evaluadas.
  • Documento 4: Especificaciones de equipos principales.
  • Documento 5: Presupuesto.

Cada documento tiene su propia versión/revisión, aunque pertenezcan a la misma memoria.

5.3. Metadatos críticos de documentos técnicos​

Cada documento debe registrar:

CampoDescripciónCrítico
EstadoBorrador, revisión, final, entregado.✓
NúmeroID único dentro del ambiente.✓
VersiónCambios mayores (0.5 → 1.0).✓
RevisiónCambios menores (1.0 → 1.1).✓
Fecha de emisiónCuándo se marcó como final/entregado.✓
ResponsableQuién diseñó/redactó.✓
RevisorQuién validó.✓
DestinatarioInterno, cliente, regulador.✓
ObservacionesCambios solicitados, limitaciones, notas.

Cadena de referencia automática: Proyecto + Ambiente + Nº + 0[X] + 0[Y] + Tipo = 240-PT-001-01-00

Esta cadena debe sincronizarse exactamente con el nombre del archivo en Dropbox.

5.4. Procedimiento de documentación​

  1. Abrir Documentos en ING.
  2. Seleccionar proyecto y ambiente.
  3. Abrir o crear el entregable.
  4. Crear o actualizar documento.
  5. Indicar: responsable, revisor, estado, versión/revisión, fecha.
  6. OBLIGATORIO: Dejar comentario cuando se emita o entregue.

Comentario de emisión debe contener:

  • Qué documento se emite (nombre, versión).
  • Para qué sirve (contexto).
  • Destinatario (cliente, interno, regulador).
  • Cambios respecto a versión anterior (si aplica).
  • Ubicación en almacenamiento (ruta Dropbox).
  • Estado esperado (revisión pendiente, aprobación, información).
aviso

Un documento emitido sin comentario queda en el aire. Meses después, nadie sabrá qué se envió, cuándo, a quién, ni dónde está. Los comentarios son el rastro.

5.5. Control de versiones en documentos técnicos​

Regla de versionado:

  • Revisión (0[X]): Cambios internos menores.

    • Correcciones de redacción.
    • Ajustes de formato.
    • Cambios muy locales.
    • Incrementar: 1.0 → 1.1 → 1.2.

  • Versión (0[X]): Cambios mayores en contenido o estructura.

    • Nuevas especificaciones técnicas.
    • Cambios en criterios de diseño.
    • Nuevas alternativas estudiadas.
    • Cambios en componentes principales.
    • Incrementar: 1.0 → 2.0.

Ejemplo de evolución: Memoria PT para Granada:

  1. v0.1
    Concepto inicialentrega preliminar
  2. v0.5
    Diseño preliminar con alternativascliente para revisión
  3. v1.0
    Diseño final, aprobado clienteentrega
  4. v1.1
    Corrección de números de páginarevisión menor
  5. v1.2
    Ajuste en presupuesto finalrevisión menor
  6. v2.0
    Incorporación de cambio cliente mayor: nuevo sistemanueva versión
consejo

Mantener versionado coherente. Un documento que tiene 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6... puede indicar falta de criterio en qué es "revisión" vs. "versión".

6. Búsqueda de comentarios técnicos​

El módulo Búsqueda de comentarios permite consultar, filtrar y analizar comentarios técnicos de Ingeniería.

Los resultados están limitados a comentarios con origen ING.

6.1. Buscar y filtrar comentarios técnicos​

  1. Abrir ING → Búsqueda de comentarios.
  2. Escribir palabra clave (p. ej., "acero inoxidable", "cambio cliente").
  3. Aplicar filtros avanzados:
    • Rango de fechas.
    • Autor (diseñador, calculista).
    • Tipo de comentario (decisión técnica, problema, cambio).
    • Proyecto.
    • Tarea específica.
  4. Revisar resultados.

Casos de uso:

  • "¿Cuándo se decidió cambiar de acero al aluminio?" → Buscar "aluminio" en proyecto 240.
  • "¿Qué problemas se detectaron en ventilación?" → Buscar "ventilación" + tipo "problema".
  • "¿Quién especificó el motor?" → Buscar "motor" + autor "Juan".

6.2. Exportar y analizar comentarios​

  1. Aplicar filtros.
  2. Pulsar Genera PDF con los comentarios filtrados.
  3. Sistema genera reporte con comentarios filtrados.
  4. Descargar PDF.

Uso futuro con IA:

  • Cargar PDF en ChatGPT.
  • Preguntar: "¿Qué problemas técnicos se han detectado en este proyecto?"
  • IA resume basándose en comentarios registrados.
consejo

La IA solo es útil si los comentarios son de buena calidad: claros, contextualizados, útiles. Comentarios vacios o mal redactados añaden ruido.

7. Reuniones técnicas​

El módulo Reuniones registra reuniones de ingeniería: internas, con cliente, con contratas, con otros departamentos.

7.1. Crear una reunión técnica​

  1. Abrir ING → Reuniones.
  2. Pulsar Nueva reunión.
  3. Completar:
    • Título: Descripción clara (p. ej., "Reunión técnica diseño ventilación - Proyecto 240").
    • Fecha y hora.
    • Proyecto(s) asociado(s).
  4. Crear reunión.
  5. Añadir participantes.
  6. Guardar.

7.2. Iniciar reunión y temporizador​

  1. Abrir reunión.
  2. Pulsar Iniciar (botón verde).
  3. Se inicia el temporizador.
  4. Se detiene fichaje de tareas activas de participantes.
  5. Se inicia fichaje de reunión.

7.3. Resumen técnico de reunión​

Durante la reunión, registrar:

  • Decisiones técnicas: Qué se decidió y por qué.
  • Problemas identificados: Qué no funciona, requiere cambio.
  • Alternativas analizadas: Opciones técnicas discutidas.
  • Acuerdos: Qué se hará, quién lo hará, cuándo.
  • Contactos cliente: Nombres de personas clave.
  • Documentos referenciados: Qué se discutió (planos, especificaciones).

Ejemplo de resumen técnico:

Reunión diseño puesta en marcha Proyecto 240.

Asistentes: Juan (AGF), Pedro (cliente), Contrata X.

Decisiones:

  • Avanzar puesta en marcha con sistema de control nuevo (frente a sistema manual).
  • Pruebas calefacción: calendario 15-20 sept.

Problemas:

  • Especificación sensor temperatura incompleta. Revisar y enviar a contratas.

Acuerdos:

  • Juan: completar especificación sensor (10 sept).
  • Pedro (cliente): confirmación presupuesto adicional (8 sept).
  • Contratas: preparar procedimiento pruebas (12 sept).

7.4. Finalizar reunión y derivadas​

  1. Pulsar Finalizar.
  2. Validar fichaje cerrado.
  3. Completar resumen si falta.
  4. Crear subtareas para acciones derivadas:
    • "Completar especificación sensor temperatura" → Juan (10 sept, 2h).
    • "Preparar procedimiento pruebas" → Contratas (12 sept, 4h).
  5. Guardar reunión.
consejo

Una reunión sin acciones derivadas formalizadas es información perdida. Cada acción acordada debe convertirse en una subtarea con fecha y responsable claros.

8. Integración de Ingeniería con otros departamentos​

8.1. Relación Ingeniería ↔ Comercial​

Comercial solicita a Ingeniería:

  • Documento técnico para oferta.
  • Especificaciones para presupuesto.
  • Viabilidad técnica de propuesta cliente.

Ingeniería responde:

  • Tarea "Preparar ingeniería básica para oferta" (ambiente: propuesta).
  • Documento entregable.
  • Comentario técnico con criterios.

Medio: Tareas asignadas, documentos compartidos, reuniones.

8.2. Relación Ingeniería ↔ Gestión de Proyectos​

GP solicita a Ingeniería:

  • Documentos técnicos para cliente.
  • Cambios solicitados por cliente.
  • Información de avance.

Ingeniería responde:

  • Incorpora cambios como nuevas tareas/subtareas.
  • Deja comentarios explicando impacto.
  • Genera nuevas versiones de documentos.

Medio: Reuniones técnicas, cambios formalizados, documentos versionados.

8.3. Relación Ingeniería ↔ GEM (Gestión de Ejecución Material)​

Ingeniería proporciona a GEM:

  • Especificaciones técnicas: Qué componentes usar, referencias exactas.
  • Listas de materiales: Elemento a elemento.
  • DTI (Diagrama Técnico de Instalación): Detalles de montaje.
  • Documentos de ejecución: Planos finales, especificaciones de montaje.

GEM utiliza para:

  • Compras (orden de compra con elementos precisos).
  • Inventario (saber qué elementos existen, dónde están).
  • Campo (instrucciones de montaje).
  • Obra (especificaciones civiles, eléctricas).

Medio: Documentos compartidos, lista de materiales, base de datos de elementos.

aviso

Crítico: Si Ingeniería no especifica elementos con precisión, GEM no puede comprar correctamente. Una especificación vaga = compras incorrectas = obra problemática.

9. Integración con elementos y compras (futuro cercano)​

9.1. Base de datos de elementos​

Ingeniería especifica elementos codificados internamente (no por proveedor).

Ejemplo:

Válvula neumática control flujo

Código interno AGF
VN-CF-02
Proveedor A
REF-2457-X
Proveedor B
REF-1023-Y

Cuando Ingeniería especifica VN-CF-02, GEM sabe:

  • Qué es (válvula neumática control flujo).
  • Proveedores disponibles.
  • Precio de cada uno.
  • Tiempo de entrega.

9.2. Automatización de órdenes de compra​

Futuro próximo:

  1. Ingeniería genera lista de materiales (elementos + cantidades).
  2. GEM valida, selecciona proveedores.
  3. AGF App genera orden de compra automáticamente.
  4. Orden se envía a proveedor.
  5. Recepción actualiza inventario.
  6. Todo queda trazado.

10. Estadísticas y mejora continua en Ingeniería​

10.1. Análisis de tiempos por tipo de ingeniería​

Con datos acumulados, Ingeniería puede analizar:

¿Cuánto tiempo toma típicamente...?

Una ingeniería básica de 500 kWe
120 horas
Un proyecto técnico
90 horas
Ingeniería de detalle (mecánico)
200 horas
Especificación de control
40 horas
Pruebas de comisionado
60 horas

Uso operativo: Cuando se presupuesta una tarea nueva, usar estos datos como referencia.

10.2. Análisis de calidad: cambios post-entrega​

Contar cambios solicitados por cliente post-entrega:

  • ¿Cuántos cambios se solicitan típicamente?
  • ¿Qué tipos de errores se repiten?
  • ¿Qué fases generan más cambios?

Indicador de calidad: Si siempre hay cambios post-entrega, puede indicar:

  • Falta de revisión interna.
  • Especificación incompleta.
  • Cambios no comunicados del cliente.

11. Criterios de buena ingeniería en AGF App​

✅ Hacer:

  • Documentar decisiones técnicas en comentarios.
  • Especificar elementos con precisión (códigos internos).
  • Versionar documentos consistentemente.
  • Dejar rastro de cambios y razones.
  • Asignar subtareas para acciones.
  • Registrar tiempos correctamente.
  • Revisar internamente antes de entregar.

❌ No hacer:

  • Entregables sin trazabilidad.
  • Documentos sin versionado claro.
  • Cambios sin comentario explicativo.
  • Tareas sin subtareas asignadas.
  • Tiempos no fichados.
  • Especificaciones vagas o ambiguas.

12. Resumen operativo​

El área Ingeniería es donde AGF crea valor técnico. Sus componentes permiten:

  • Los informes técnicos recogen análisis y decisiones de diseño.
  • El diseño es el proceso iterativo de creación y refinamiento.
  • Los documentos controlan entregables, versiones, responsables.
  • La búsqueda de comentarios permite recuperar decisiones técnicas y problemas.
  • Las reuniones técnicas registran acuerdos y acciones derivadas.
  • La integración con GEM asegura que especificaciones se traduzcan en compras y montaje correctos.

Objetivo final: Convertir la actividad técnica en un rastro completo, trazable, versionado y explotable. Esta información es el cimiento para que otros departamentos ejecuten correctamente y para que AGF mejore sus estimaciones y procesos.