Cómo definir indicadores de procesos de Ingeniería con lead time, WIP, aging, throughput, retrabajo, first pass yield y SLA sin confundir proceso y proyecto.
¡Descúbrelo!
Los indicadores de procesos de Ingeniería son medidas utilizadas para demostrar si un flujo recurrente está produciendo el resultado esperado con plazo, calidad, capacidad, coste y riesgo compatibles con sus objetivos. No sirven únicamente para crear dashboards. Sirven para responder preguntas concretas de gestión: cuánto tiempo espera el cliente del proceso, dónde envejece el trabajo, cuánto regresa, qué proporción se aprueba a la primera y si la capacidad acompaña la demanda.
En empresas de Ingeniería, procesos como revisión documental, tratamiento de RFIs, gestión de cambios, procurement, inspección, RNCs, mediciones, aprobaciones y puesta en marcha pueden implicar decenas de etapas y participantes. Medir únicamente la productividad individual o la cantidad de tareas finalizadas crea una visión parcial. Un proceso puede producir mucho y mantener una gran cola; cumplir volumen y aumentar el retrabajo; reducir el tiempo local y alargar el lead time de extremo a extremo.
Por ello, un buen sistema de medición debe combinar indicadores de resultado, flujo, calidad, capacidad y gobernanza. La pregunta central no es “¿cuántos KPIs podemos supervisar?”, sino qué pocas medidas permiten comprender si el proceso funciona y por qué está cambiando su desempeño.
¿Qué son los indicadores de procesos?
Los indicadores de procesos son medidas cuantitativas o, en algunos casos, clasificaciones estructuradas utilizadas para supervisar el desempeño de un proceso y sus resultados. El enfoque por procesos de ISO 9001 incluye la definición de requisitos de seguimiento y medición, el análisis del desempeño, lead times, fallos, desperdicios y otras medidas de conformidad con los objetivos.
APQC recomienda seleccionar métricas a partir del propósito, las fronteras, los stakeholders y los objetivos del proceso. Su orientación organiza las medidas de desempeño en categorías como coste-efectividad, productividad, eficiencia del proceso y tiempo de ciclo, evitando la idea de que existe una lista universal de KPIs válida para cualquier organización.
En Ingeniería, el indicador debe estar conectado con lo que el proceso debe producir. Un proceso de revisión técnica puede tener como objetivo emitir decisiones fiables dentro del plazo necesario para el proyecto. Un proceso de procurement puede buscar una contratación técnicamente adecuada en el tiempo requerido para la implantación. Un proceso de RNC debe eliminar o controlar la desviación e impedir su recurrencia cuando corresponda.
La métrica solo adquiere valor de gestión cuando ayuda a tomar una decisión o probar una hipótesis sobre el proceso.
Métrica, indicador y KPI: ¿cuál es la diferencia práctica?
Los términos se utilizan con frecuencia como sinónimos, pero una distinción sencilla ayuda a organizar la gestión.
- métrica: cualquier medida observable del proceso, como la cantidad de documentos recibidos;
- indicador: medida interpretada en relación con una pregunta de desempeño, como el porcentaje de documentos aprobados dentro del plazo;
- KPI: indicador considerado crítico para demostrar si el proceso cumple un objetivo relevante.
Un proceso puede tener decenas de métricas disponibles en los sistemas y aun así necesitar pocos KPIs. El exceso de indicadores crea ruido y dificulta la rendición de cuentas.
APQC recomienda limitar y organizar las medidas, destacando un KPI estratégicamente importante por proceso u objetivo, apoyado por un pequeño conjunto de indicadores explicativos. La lógica es especialmente útil en Ingeniería: el process owner necesita ver rápidamente el resultado y después profundizar en las causas.
Por ejemplo, si el KPI principal es el lead time del proceso de aprobación documental, los indicadores de apoyo pueden incluir tiempo de espera por etapa, tasa de retrabajo, aging, porcentaje de entradas rechazadas y tiempo de decisión por nivel de autoridad.
Antes de medir, defina la frontera del proceso
Los indicadores pueden ser técnicamente correctos y aun así inducir decisiones equivocadas cuando la frontera de medición no representa el resultado real.
Si el lead time de revisión comienza únicamente cuando el revisor abre el documento y termina cuando registra comentarios, todo el tiempo de espera de clasificación queda invisible. Si procurement se mide solo desde la emisión de la RFQ hasta la recepción de las propuestas, no aparece el periodo en que la requisición estuvo detenida por un alcance incompleto.
La frontera debe ser coherente con el proceso de extremo a extremo. Esto significa definir:
- evento de inicio;
- resultado de finalización;
- cliente o usuario del resultado;
- condiciones de entrada;
- criterios de salida;
- excepciones relevantes;
- unidades de análisis.
Sin esta definición, dos áreas pueden utilizar el mismo nombre de indicador y medir periodos diferentes.
¿Qué dimensiones debe equilibrar un buen sistema de indicadores?
Medir únicamente velocidad puede aumentar el riesgo. Medir únicamente calidad puede ocultar lentitud. Medir solo productividad puede estimular volumen en detrimento del resultado.
Una estructura equilibrada puede combinar seis dimensiones.
| Dimensión | Pregunta de gestión | Ejemplos |
| Resultado | ¿el proceso entrega lo que debería? | aceptación, cumplimiento del requisito, resolución |
| Tiempo y flujo | ¿cuánto espera el cliente y dónde? | lead time, espera, aging |
| Calidad | ¿cuánto trabajo sale correcto? | FPY, retrabajo, rechazo |
| Capacidad | ¿el sistema acompaña la demanda? | throughput, WIP, backlog |
| Coste y esfuerzo | ¿cuánto recurso se consume? | HTE por elemento, coste por transacción |
| Riesgo y gobernanza | ¿funcionan las decisiones y los controles? | excepciones, SLA crítico, tiempo de aprobación |
La combinación depende del proceso. Un flujo de aprobación de baja criticidad puede enfatizar tiempo y calidad. Un proceso de inspección puede exigir mayor peso para conformidad, evidencia y riesgo. Procurement puede combinar plazo, calidad técnica de las requisiciones, competitividad y desempeño de proveedores.
Un dashboard no corrige una mala definición del proceso. Antes de elegir KPIs, es necesario definir fronteras, resultado, owner y las causas que realmente explican plazo, calidad y capacidad.
Lead time: ¿cuánto tiempo espera el cliente del proceso?
Lead time es una de las medidas más relevantes porque representa el tiempo transcurrido desde el inicio definido hasta el resultado final. En un proceso de conocimiento, incluye periodos de ejecución y periodos de espera.
Ejemplo: una RFI se abre el 1 de agosto y recibe una respuesta formal aceptada el 8 de agosto. Si la frontera se definió así, el lead time es el tiempo total entre esos eventos, independientemente de cuántas horas se hayan dedicado efectivamente al análisis.
El indicador responde una pregunta sencilla: ¿cuánto tiempo debe esperar el cliente del proceso para obtener el resultado?
Sin embargo, el lead time aislado no explica la causa. Para interpretar un deterioro, es necesario descomponer el flujo en procesamiento, espera, bloqueo, retrabajo y decisión.
Lean Enterprise Institute diferencia lead time del tiempo necesario para ejecutar una actividad o proceso. Esta distinción ayuda a mostrar por qué un flujo puede tener pocas horas de trabajo y muchos días de duración.
Processing time: ¿cuánto tiempo se consume realmente en la ejecución?
Processing time es el tiempo durante el cual el elemento recibe trabajo efectivo. En procesos técnicos, su medición puede ser más difícil que la del lead time porque el profesional alterna entre distintas demandas.
Incluso una muestra puede ser útil. Si un dictamen requiere dos horas de análisis técnico, pero permanece nueve días en el proceso, actuar exclusivamente sobre la productividad del analista tendrá un impacto limitado en el plazo total.
La comparación entre lead time y processing time ayuda a identificar la proporción de tiempo perdida en:
- colas;
- espera de información;
- handoffs;
- aprobaciones;
- bloqueos externos;
- retrabajo;
- prioridades concurrentes.
Esta lectura conecta los indicadores con el artículo sobre Cuellos de Botella en Procesos de Ingeniería, cuya cuestión central es localizar la restricción organizativa.
Cycle time: cómo utilizarlo sin confundir objetos diferentes
Cycle time puede asumir definiciones específicas según el método y el contexto. En gestión de flujo, se utiliza con frecuencia para representar el tiempo entre el inicio efectivo del trabajo sobre un elemento y su finalización. Lean Enterprise Institute define cycle time como el tiempo necesario para producir una pieza o finalizar un proceso, medido por la ejecución real.
En el sitio de A3A Engenharia, el artículo Métricas Ágiles vs. EVM en Proyectos Híbridos ya trata cycle time como métrica operativa de flujo asociada a throughput, WIP, SPI y CPI. Este artículo no pretende competir con esa intención.
Aquí, cycle time aparece como una de las medidas posibles dentro de un sistema de desempeño de procesos recurrentes. El objeto no es el desempeño del proyecto como iniciativa, sino el funcionamiento de procesos organizativos que pueden ejecutarse repetidamente en varios proyectos.
La principal precaución es documentar la definición utilizada. “Cycle time de revisión” puede significar el tiempo desde el inicio del análisis hasta su finalización, mientras que “lead time de revisión” puede incluir la espera desde la presentación. Sin una regla explícita, las comparaciones pierden valor.
Waiting time: ¿cuánto del plazo es simplemente espera?
Waiting time es el periodo durante el cual el elemento se encuentra dentro de la frontera del proceso, pero no recibe procesamiento efectivo porque espera un recurso, información, decisión, fecha, proveedor o condición de preparación.
En Ingeniería, esta medida es extremadamente útil porque gran parte del plazo puede estar entre actividades.
Los tipos de espera incluyen:
- cola de revisión;
- cola de aprobación;
- espera de respuesta del proveedor;
- bloqueo por información de campo;
- dependencia de otra disciplina;
- espera de reunión de decisión;
- espera de documento precedente;
- hold point no liberado.
El objetivo no es eliminar toda espera. Algunas son necesarias por secuencia, seguridad, madurez o contrato. El análisis debe separar espera necesaria de espera evitable.
Throughput: ¿cuánto puede finalizar el proceso por periodo?
Throughput mide la cantidad de elementos finalizados en una unidad de tiempo. Puede ser documentos por semana, RFIs resueltas por mes, requisiciones contratadas por periodo o RNCs cerradas con eficacia verificada.
Es una medida de capacidad de salida, no de esfuerzo individual.
El indicador debe utilizar unidades comparables. Si algunos elementos son mucho más complejos que otros, contarlos como equivalentes puede distorsionar la lectura. Las estrategias posibles incluyen segmentar por clase de criticidad, tipo de documento, disciplina o rango de complejidad.
Throughput adquiere valor cuando se compara con la tasa de llegada. Si entran 120 elementos por semana y solo salen 90 de forma sostenible, el WIP tiende a crecer. Esta diferencia ayuda a identificar presión estructural sobre el proceso.
WIP: ¿cuánto trabajo se ha iniciado y aún no ha finalizado?
WIP — Work in Progress — representa trabajo en curso. En Ingeniería puede incluir documentos en revisión, RFIs abiertas, requisiciones en contratación, RNCs sin cierre, acciones de riesgo abiertas, pendientes técnicas y paquetes de puesta en marcha incompletos.
Un WIP elevado no es automáticamente negativo. Puede existir por el tamaño del proceso, dependencias o características de la demanda. El problema aparece cuando crece sin control o sin relación con la capacidad de finalización.
El artículo Kanban en Proyectos de Ingeniería profundiza en límites y políticas de WIP. En este artículo, WIP se trata como indicador de proceso para explicar flujo y capacidad.
Una lectura útil combina:
- WIP total;
- WIP por etapa;
- WIP por antigüedad;
- WIP bloqueado;
- WIP por criticidad;
- WIP sin responsable definido.
Aging: ¿cuánto tiempo lleva abierto cada elemento?
Aging mide la antigüedad de los elementos aún no finalizados. Es diferente de lead time porque observa el trabajo en curso, no solo los elementos cerrados.
Este indicador evita un problema clásico: analizar únicamente casos finalizados e ignorar el stock de elementos antiguos que permanece en el proceso.
Una cartera puede dividirse en rangos según el SLA o el comportamiento histórico. Por ejemplo:
- hasta 2 días;
- 3 a 5 días;
- 6 a 10 días;
- 11 a 20 días;
- más de 20 días.
Los rangos son solo ejemplos y deben definirse para cada proceso.
Aging es especialmente útil en RFIs, RNCs, punch lists, aprobaciones, vendor documents, acciones de riesgo y solicitudes de cambio.
First Pass Yield: ¿cuánto sale correcto a la primera?
First Pass Yield — FPY — representa la proporción de elementos que atraviesan una etapa o proceso sin necesidad de corrección o retrabajo antes de ser aceptados.
En procesos de Ingeniería, la adaptación debe ser cuidadosa. No toda revisión adicional significa un fallo; los diseños pueden exigir iteraciones legítimas. El indicador debe aplicarse donde existan criterios claros de completitud y calidad de entrada o salida.
Ejemplos posibles:
- porcentaje de requisiciones aceptadas por Procurement sin devolución por falta de datos;
- porcentaje de vendor documents aprobados sin comentarios impeditivos;
- porcentaje de paquetes de puesta en marcha aceptados sin pendientes documentales;
- porcentaje de mediciones aceptadas sin corrección administrativa;
- porcentaje de documentos que superan la verificación interna sin retrabajo relevante.
El valor del FPY es hacer visible el coste oculto de la reentrada. Un equipo puede tener un throughput bruto alto y un resultado neto bajo si muchos elementos regresan.
Tasa de retrabajo: ¿cuánto esfuerzo se está repitiendo?
La tasa de retrabajo complementa FPY al medir elementos o esfuerzo que deben regresar a etapas anteriores.
Puede expresarse por cantidad de elementos devueltos, ciclos adicionales, HTE consumida en correcciones o porcentaje de entregables reprocesados. La elección depende de la disponibilidad de datos y del tipo de proceso.
Es importante clasificar la causa. Mezclar error, cambio de alcance e iteración técnica en un único indicador puede conducir a acciones injustas o incorrectas.
Una taxonomía sencilla puede separar:
- error técnico;
- entrada incompleta;
- requisito modificado;
- fallo de interfaz;
- comentario no tratado;
- documentación inadecuada;
- cambio legítimo;
- decisión reabierta;
- proveedor no conforme.
El objetivo es aprender dónde pierde capacidad el proceso, no crear un ranking de culpabilidad.
Tasa de rechazo de entrada
Una de las métricas más útiles para identificar problemas aguas arriba es el porcentaje de elementos recibidos que no cumplen los criterios mínimos para iniciar el procesamiento.
Ejemplos:
- requisición sin memoria o especificación necesaria;
- RFI sin referencia documental;
- documento sin revisión válida;
- inspección solicitada sin documentación de preparación;
- medición sin las evidencias exigidas;
- paquete de puesta en marcha sin checklists completos.
Un rechazo de entrada elevado reduce la capacidad de la etapa siguiente y crea ping-pong entre áreas. El indicador debe acompañarse de la causa y del responsable de corregir el proceso.
SLA y cumplimiento de plazo: porcentaje dentro del compromiso
SLA representa un compromiso de nivel de servicio. En procesos internos, puede definir el tiempo esperado para análisis, respuesta o aprobación. En contratos, puede estar asociado a una obligación formal.
Los indicadores habituales incluyen:
- porcentaje finalizado dentro del SLA;
- porcentaje vencido;
- retraso medio de los vencidos;
- aging de los vencidos;
- SLA por criticidad.
Utilizar un único plazo para todos los elementos puede ser inadecuado. Una revisión sencilla y un análisis de desviación técnica crítica no tienen necesariamente el mismo esfuerzo o riesgo. El SLA puede segmentarse por tipo, prioridad y complejidad.
El indicador también debe considerar la suspensión legítima cuando el cómputo depende de información de terceros. Si el reloj se detiene, la regla debe ser explícita y auditable.
Tiempo de decisión y cuellos de botella de gobernanza
Los procesos pueden tener capacidad técnica adecuada y seguir siendo lentos porque las decisiones esperan niveles de autoridad.
Medir el tiempo de decisión ayuda a identificar:
- aprobación centralizada;
- sponsor no disponible;
- comité con frecuencia inadecuada;
- criterios vagos de escalado;
- excepciones sin owner;
- decisiones reabiertas repetidamente.
La Gobernanza de Procesos de Ingeniería define cómo deben estructurarse ownership y derechos de decisión. El indicador permite verificar si esta gobernanza funciona en la práctica.
Tasa de excepción: ¿cuánto trabajo se sale del proceso estándar?
Las excepciones son necesarias en procesos de Ingeniería, pero una frecuencia elevada puede indicar que el proceso estándar no representa la realidad.
Una tasa de excepción puede medir elementos que:
- siguen una aprobación extraordinaria;
- utilizan un flujo manual fuera del workflow;
- requieren waiver o desviación;
- saltan el orden normal por urgencia;
- regresan por una condición no prevista;
- dependen de una decisión ad hoc.
El análisis debe distinguir excepciones legítimas de atajos creados porque el proceso formal es impracticable.
Si el 40 % de los casos necesita tratamiento excepcional, el problema puede estar en el diseño del proceso, no en los usuarios.
Indicadores de calidad del resultado
No todos los procesos terminan en “finalizado”. Es necesario saber si el resultado cumple el requisito.
Los indicadores pueden incluir:
- tasa de aceptación;
- no conformidades asociadas a la salida;
- errores detectados en una etapa posterior;
- reclamaciones del cliente interno;
- reapertura de un elemento cerrado;
- fallos atribuidos a la información entregada;
- cumplimiento de criterios técnicos.
Estos indicadores evitan optimizar el plazo sacrificando la calidad.
Indicadores de coste y esfuerzo
Cuando la organización dispone de datos fiables de esfuerzo, puede medir coste o HTE por elemento, proceso o clase de entrega.
Ejemplos:
- HTE media por revisión técnica;
- coste de procesamiento por requisición;
- horas consumidas en retrabajo;
- esfuerzo de gestión por documento;
- coste de no calidad asociado al proceso.
La interpretación debe considerar la complejidad. Una reducción de HTE puede reflejar eficiencia o simplemente menor profundidad de análisis. Por ello, el coste debe leerse junto con la calidad y el resultado.
La media puede ocultar el problema: utilice distribución y percentiles
La media es intuitiva, pero los procesos con gran variabilidad pueden quedar mal representados por un único valor.
Imagine diez solicitudes con lead times de 2, 2, 3, 3, 4, 4, 5, 6, 8 y 40 días. La media se ve arrastrada por el caso extremo, mientras la mayoría de los elementos se comporta de otra forma. Por otro lado, excluir el caso de 40 días ocultaría un riesgo importante.
Además de la media, pueden ser útiles:
- mediana;
- percentiles como P80 o P90;
- mínimo y máximo;
- desviación o rango de variación;
- distribución por clase;
- aging de los elementos aún abiertos.
El objetivo no es sofisticar la estadística sin necesidad. Es evitar que un único número oculte estabilidad, colas de distribución y excepciones.
NIST destaca que el control de procesos depende de comprender la variación y distinguir el comportamiento estable de los cambios relevantes. En procesos administrativos de Ingeniería, el rigor estadístico debe ser proporcional al volumen y la calidad de los datos, pero el principio sigue siendo útil.
Indicadores de tendencia vs. indicadores de resultado
Una clasificación útil separa las medidas que muestran el resultado después de producirse de las que ayudan a anticipar un deterioro.
Indicadores de resultado
- lead time finalizado;
- porcentaje dentro del SLA;
- tasa de aceptación;
- retrabajo realizado;
- coste por elemento.
Indicadores anticipatorios
- WIP creciente;
- aging en aumento;
- cola en un recurso crítico;
- tasa de rechazo de entradas;
- aumento de excepciones;
- backlog bloqueado;
- demanda por encima del throughput sostenible.
Un process owner que supervisa únicamente resultados cerrados puede reaccionar tarde. Los indicadores de tendencia ayudan a intervenir antes de perder el SLA.
Indicadores locales vs. indicadores de extremo a extremo
Cada área necesita medidas operativas, pero el proceso debe tener un resultado transversal.
Ejemplo: Ingeniería mide el tiempo de preparación; Calidad mide el tiempo de verificación; Document Control mide el tiempo de emisión. Todas pueden cumplir sus metas y, aun así, el lead time total ser deficiente por la espera entre etapas.
La solución es crear una jerarquía:
- KPI de extremo a extremo vinculado al resultado;
- indicadores por etapa que expliquen ese KPI;
- métricas diagnósticas utilizadas cuando existe una desviación.
Esto reduce el riesgo de optimización local.
Cómo construir un árbol de indicadores
Un árbol de indicadores conecta el resultado con sus posibles causas.
Si el lead time empeora, el árbol orienta la investigación. El responsable verifica si la causa está en el procesamiento, la cola, las decisiones, el retrabajo o las dependencias.
Esta estructura es más útil que un dashboard con decenas de cifras sin relación causal.
Un indicador útil debe revelar dónde se está degradando el flujo, no limitarse a registrar que el resultado empeoró. Cuando lead time, aging, WIP y retrabajo se analizan en conjunto, resulta más fácil distinguir cuellos de botella, espera, pérdida de calidad y problemas de gobernanza.
Vea cómo diagnosticar cuellos de botella en procesos de Ingeniería
Ejemplo: indicadores de aprobación documental
Un proceso de revisión y aprobación documental puede tener como KPI principal el lead time desde la presentación hasta la emisión aprobada.
Indicadores de apoyo:
| Indicador | Interpretación |
| lead time total | experiencia del cliente del proceso |
| espera para revisión | cola técnica |
| tiempo de decisión | nivel de autoridad y gobernanza |
| FPY | calidad de la primera presentación |
| tasa de devolución | reentrada y retrabajo |
| WIP | cantidad de trabajo en curso |
| aging | riesgo de elementos olvidados |
| % dentro del SLA | fiabilidad del compromiso |
El equipo también puede segmentar por disciplina, criticidad, tipo documental o proyecto.
La precaución es no utilizar el indicador para comparar ingenieros sin controlar la complejidad. El objetivo es mejorar el sistema.
Ejemplo: indicadores de Procurement de Ingeniería
Procurement puede medir mucho más que el plazo de cotización.
Un conjunto posible incluye:
- lead time desde la requisición hasta la contratación;
- tiempo de Ingeniería a RFQ;
- porcentaje de requisiciones rechazadas por falta de información;
- cantidad media de ciclos de aclaración;
- tiempo de evaluación técnica de ofertas;
- porcentaje de propuestas técnicamente comparables en la primera ronda;
- vendor response time;
- cambios de alcance después de la RFQ;
- plazo de emisión de la PO o del contrato;
- entregas de proveedores dentro del plazo.
Estas medidas ayudan a distinguir un cuello de botella de Compras de un problema de madurez de Ingeniería o de desempeño del proveedor.
El artículo sobre Procurement en Proyectos de Ingeniería profundiza la jornada de contratación.
Ejemplo: indicadores para RNC y acciones correctivas
Un proceso de no conformidad puede medir:
- tiempo hasta la contención;
- tiempo hasta la disposición;
- lead time total de la RNC;
- porcentaje vencido;
- aging por criticidad;
- reincidencia;
- porcentaje con causa identificada;
- tiempo hasta la verificación de eficacia;
- tasa de reapertura.
La meta no debe incentivar un cierre administrativo rápido sin solución técnica. Un buen KPI debe preservar la calidad del resultado.
Cómo definir metas sin inventar cifras arbitrarias
Las metas deben reflejar requisitos, riesgo, capacidad y expectativa del cliente. Copiar un benchmark externo sin considerar el contexto puede producir objetivos imposibles o irrelevantes.
Una secuencia razonable es:
- estabilizar la definición del indicador;
- construir una baseline fiable;
- analizar la distribución y las causas;
- identificar el requisito contractual o la necesidad del cliente;
- estimar capacidad y riesgo;
- definir la meta y el horizonte de mejora;
- revisar después de cambios relevantes en el proceso.
El benchmarking externo puede ayudar, pero no sustituye la comprensión interna. APQC utiliza frameworks y datos comparativos precisamente para contextualizar el desempeño, no para imponer una meta universal.
La calidad del dato viene antes que el dashboard
Un indicador sofisticado basado en datos inconsistentes genera una falsa confianza.
Antes de automatizar la medición, verifique que:
- los eventos de inicio y fin se registran de forma consistente;
- los timestamps no se modifican manualmente sin control;
- los estados tienen una definición común;
- los elementos cancelados se tratan de forma explícita;
- los bloqueos pueden identificarse;
- las causas de devolución tienen una taxonomía útil;
- las duplicidades están controladas;
- los periodos de suspensión del SLA son trazables;
- los usuarios comprenden por qué se recopilan los datos.
El proceso de medición también necesita gobernanza.
Evite indicadores que incentiven comportamientos incorrectos
Toda métrica influye en el comportamiento. Si a un equipo se le exige únicamente cantidad de documentos revisados, puede priorizar elementos simples y dejar envejecer los complejos. Si el objetivo es cerrar RNC rápidamente, los casos pueden cerrarse antes de verificar la eficacia.
Señales de una métrica mal diseñada incluyen:
- mejora del indicador sin mejora percibida por el cliente;
- desplazamiento del problema a otra etapa;
- aumento del retrabajo;
- selección artificial de casos fáciles;
- manipulación de estados;
- cierre y reapertura para “reiniciar” el aging;
- aumento de excepciones fuera del flujo oficial.
Por ello, los indicadores deben estar equilibrados y revisados por el process owner.
El papel del process owner en la medición
El process owner debe asegurar que los indicadores representen el proceso completo y se utilicen para mejorar, no solo para reporting.
Entre sus responsabilidades están:
- aprobar definiciones;
- garantizar coherencia de las fronteras;
- analizar tendencias;
- convocar la investigación de desviaciones;
- priorizar mejoras;
- ajustar metas cuando cambia el contexto;
- evitar métricas locales conflictivas;
- asegurar que las decisiones queden registradas.
La Gobernanza de Procesos de Ingeniería proporciona la estructura de accountability necesaria para que el dashboard no sea meramente informativo.
Cómo estructurar una rutina de análisis
Un indicador sin una rutina de decisión tiende a convertirse en un informe.
Una rutina puede incluir:
- revisión del KPI principal;
- comparación con baseline y meta;
- análisis de tendencia;
- identificación de desviaciones relevantes;
- drill-down en los indicadores explicativos;
- análisis de aging y excepciones;
- definición de acciones;
- responsable y plazo;
- verificación del efecto de la acción.
La frecuencia debe acompañar la velocidad del proceso. Un flujo diario puede exigir seguimiento semanal o incluso diario. Un proceso mensual puede analizarse con otra cadencia.
Un dashboard de proceso no es un dashboard de proyecto
Esta distinción evita solapamientos conceptuales y errores de gestión.
Los indicadores de proyecto responden preguntas sobre un esfuerzo temporal: avance, coste, plazo, riesgo, hitos y valor ganado. Los indicadores de proceso miden un flujo recurrente que puede ser ejecutado por muchos proyectos.
Por ejemplo:
| Pregunta | Objeto | Indicador adecuado |
| ¿el proyecto está adelantado o retrasado respecto al plan? | proyecto | SPI, hitos, variación de cronograma |
| ¿cuánto tarda una RFI en resolverse? | proceso | lead time de la RFI |
| ¿cuántos documentos están envejeciendo? | proceso | WIP y aging |
| ¿el coste del trabajo producido está alineado? | proyecto | CPI / CV |
| ¿cuánto retrabajo existe en la revisión técnica? | proceso | FPY / tasa de retorno |
El artículo sobre Métricas Ágiles vs. EVM en Proyectos Híbridos sigue siendo el contenido principal para comparar métricas de flujo y control del proyecto. Aquí el foco es el sistema de medición de procesos organizacionales.
Cómo apoyan los indicadores el diagnóstico de cuellos de botella
Los indicadores no solo reportan desempeño; ayudan a probar causas.
Si el lead time aumenta y el processing time permanece estable, investigue la espera. Si el WIP crece y el throughput permanece constante, compare demanda y capacidad. Si el FPY cae, verifique la calidad de entrada y el retrabajo. Si aumenta el tiempo de decisión, investigue niveles de autoridad y gobernanza.
Esta lectura causal transforma los datos en gestión.
El Diagnóstico y Optimización de Procesos de Ingeniería combina mapeo AS-IS, análisis de cuellos de botella, indicadores y diseño TO-BE para que la organización pueda medir el efecto de los cambios.
¿Cuándo automatizar la recopilación de indicadores?
La automatización tiene sentido cuando las definiciones están estabilizadas y los eventos se registran de forma consistente. Antes de eso, el dashboard puede limitarse a automatizar la ambigüedad.
La recopilación puede evolucionar por etapas:
- muestra manual para validar el concepto;
- hoja de cálculo controlada para construir la baseline;
- extracción de datos existentes;
- integración entre sistemas;
- dashboard automatizado;
- alertas de aging, SLA y excepciones.
La solución de Gestión de Procesos, Workflows y Aprobaciones Técnicas puede estructurar eventos, responsables, plazos y pistas de auditoría. Sin embargo, el proceso y sus métricas deben definirse antes de la plataforma.
Indicadores para procesos con bajo volumen
No todos los procesos tienen cientos de ocurrencias. En Ingeniería, los procesos críticos pueden tener pocos casos y consecuencias elevadas.
Con bajo volumen, los análisis estadísticos complejos pueden no ser útiles. La organización puede combinar:
- seguimiento caso a caso;
- aging;
- cumplimiento de hitos;
- calidad del resultado;
- causas de excepción;
- análisis cualitativo estructurado;
- tendencia acumulada en periodos más amplios.
El rigor debe ser proporcional al dato disponible y al riesgo de la decisión.
Indicadores para procesos con alto volumen
Los procesos con gran cantidad de ocurrencias permiten un mayor uso de distribución, segmentación y control estadístico.
Se pueden analizar:
- mediana y percentiles de lead time;
- estabilidad por periodo;
- tasa de defectos;
- volumen por categoría;
- tendencias de throughput;
- relación entre WIP y plazo;
- causas más frecuentes de retorno;
- variación entre unidades.
Los métodos de control de procesos, como los descritos por NIST para monitorizar el comportamiento y detectar cambios, pueden aplicarse cuando los datos, la repetitividad y el contexto lo justifican.
Cómo empezar sin crear un proyecto de BI
La organización no necesita esperar un data lake o una plataforma completa para empezar a medir procesos.
Un piloto puede seguir seis pasos:
- elegir un proceso con un problema claro;
- definir la frontera y el KPI principal;
- seleccionar entre 3 y 6 indicadores explicativos;
- recopilar una muestra histórica fiable;
- construir la baseline;
- utilizar los datos en una rutina real de decisión.
Después de demostrar valor, la recopilación puede automatizarse.
El error es empezar por el dashboard y después buscar una pregunta a la que los gráficos puedan responder.
Errores comunes en la gestión de indicadores de procesos
Medir todo lo que ofrece el sistema
La disponibilidad de datos no implica relevancia para la gestión.
Usar únicamente promedios
El promedio puede ocultar colas de distribución, excepciones y elementos antiguos.
Comparar personas sin controlar la complejidad
Esto incentiva un comportamiento defensivo y distorsiona el objetivo sistémico.
Mezclar proyecto y proceso
SPI, CPI y avance físico no sustituyen lead time, aging y calidad de un flujo recurrente.
Definir SLA sin capacidad ni riesgo
Las metas arbitrarias producen incumplimiento crónico o manipulación de prioridades.
Medir el cierre y no el resultado
Cerrar un estado no significa resolver el problema.
Crear un indicador sin owner
Sin alguien responsable de interpretar y actuar, el KPI se convierte en un informe.
Automatizar una definición inestable
El dashboard pasa a reproducir inconsistencias a escala.
¿Cuándo contratar un diagnóstico de indicadores y desempeño de procesos?
El análisis externo es útil cuando la organización dispone de muchos datos, pero tiene poca claridad sobre qué métricas explican realmente el desempeño; cuando las áreas utilizan definiciones diferentes; o cuando los dashboards están en verde mientras persisten retrasos y retrabajo.
Un diagnóstico puede incluir:
- definición de fronteras;
- inventario de métricas existentes;
- análisis de calidad de los datos;
- selección del KPI principal;
- árbol de indicadores;
- baseline de lead time, WIP, aging y calidad;
- segmentación por criticidad;
- revisión de SLA;
- definición de la rutina de análisis;
- integración con owners y gobernanza;
- roadmap de automatización y dashboard.
La finalidad es transformar los datos en un mecanismo de gestión y decisión, no aumentar la cantidad de informes.
Si las cifras existen, pero no ayudan a explicar retrasos, retrabajo o capacidad, el problema ya ha dejado de ser de dashboard. Es necesario revisar el proceso, sus fronteras, indicadores y responsabilidades como un sistema único.
Conozca el Diagnóstico y Optimización de Procesos de Ingeniería
Consideraciones finales
Los indicadores de procesos de Ingeniería deben revelar si el flujo está produciendo el resultado esperado y explicar por qué cambia su desempeño. Un sistema equilibrado combina resultado, lead time, espera, WIP, throughput, aging, calidad, retrabajo y gobernanza según el contexto.
Ninguna métrica debe interpretarse de forma aislada. El throughput puede aumentar mientras empeora el retrabajo; el lead time puede reducirse porque los elementos complejos quedaron en cola; el SLA puede parecer bueno mientras las excepciones se tratan fuera del sistema.
Una medición madura conecta el KPI de punta a punta con indicadores explicativos, mantiene definiciones estables, analiza distribuciones y genera decisiones. Cuando esto ocurre, el dashboard deja de ser una capa de reporting y pasa a apoyar el diagnóstico, la priorización y la mejora continua de los procesos de Ingeniería.
Referencias técnicas
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). The process approach in ISO 9001:2015. Geneva: ISO, 2015. Disponible en: https://www.iso.org/files/live/sites/isoorg/files/archive/pdf/en/iso9001_2015_process_approach.pdf
[2] APQC. What Are the Best Metrics to Measure Process Performance? Houston: APQC. Disponible en: https://www.apqc.org/What-Are-the-Best-Metrics-to-Measure-Process-Performance
[3] LEAN ENTERPRISE INSTITUTE. Cycle Time. Lean Lexicon. Disponible en: https://www.lean.org/lexicon-terms/cycle-time/
[4] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). What are Process Control Techniques? NIST/SEMATECH e-Handbook of Statistical Methods. Disponible en: https://www.itl.nist.gov/div898/handbook/pmc/section1/pmc12.htm
Preguntas frecuentes
Depende del objetivo del proceso, pero un conjunto frecuente incluye lead time, tiempo de espera, WIP, aging, throughput, tasa de retrabajo, first pass yield, cumplimiento de SLA y calidad del resultado.
La definición debe documentarse en el contexto utilizado. En general, lead time representa el tiempo total desde el inicio definido hasta el resultado, incluida la espera; cycle time suele representar el periodo de ejecución de un elemento o proceso desde el inicio efectivo del trabajo.
Es la proporción de elementos que atraviesan una etapa o proceso sin necesidad de corrección o retrabajo antes de la aceptación. Debe utilizarse únicamente cuando existen criterios claros de completitud y calidad.
El lead time normalmente se calcula para elementos concluidos. El aging muestra la edad del trabajo que sigue abierto y revela elementos que pueden estar olvidados o bloqueados en colas.
No. Los indicadores de proceso miden flujos recurrentes como aprobaciones, RFI o procurement. EVM y los indicadores de proyecto miden el desempeño de un esfuerzo temporal respecto a plazo, coste y valor producido.
No existe un número universal, pero la gestión debe ser enxuta. Una práctica eficaz es tener un KPI principal vinculado al objetivo del proceso y pocos indicadores de apoyo que expliquen sus variaciones.
Materiales técnicos complementarios
Contenidos principales sobre el tema
- Gestión de Procesos y BPM: qué es, etapas y aplicación en Ingeniería
- Procesos de Punta a Punta en Ingeniería
- Cuellos de Botella en Procesos de Ingeniería
- Gobernanza de Procesos de Ingeniería
Contenidos técnicos relacionados
- Métricas Ágiles vs. EVM en Proyectos Híbridos
- Kanban en Proyectos de Ingeniería
- Procurement en Proyectos de Ingeniería
