Justificar la digitalización ante el comité

Convierte un beneficio técnico en horas, paradas o coste que el comité pueda aprobar, usando solo registros que la planta ya tiene.

Nota técnica de una incidencia junto a su ficha de comité en horas semanales.

El comité casi nunca vota en contra de “digitalizar”. Vota en contra de una frase que no sabe cómo aprobar. “Reducir el tiempo de investigación de incidencias” suena bien en ingeniería. No deja claro qué se autoriza, con qué dinero, bajo qué responsable ni qué contaría como fracaso. Sin esas piezas, la reunión aplaza, pide otra diapositiva o convierte el pedido en una plataforma sin límite.

Esta guía enseña a pasar de un beneficio técnico a una frase de negocio construida solo con registros que la planta ya tiene, y a meter esa frase en un caso de una página: responsable, ventana, límite y criterio de parada. El ejemplo trabajado convierte “reducir el tiempo de investigación de incidencias” en “recuperar horas semanales de ingeniería que hoy se pierden recopilando datos”.

Cualquier número de ese ejemplo es aritmética etiquetada sobre inputs que aporta la planta (horas registradas, recuento de incidencias, ventana). No es un baremo de sector y no inventa un porcentaje de ahorro.

No es asesoramiento de inversión. El único número válido para aprobar o rechazar es el de la propia planta, revisado por quien tenga autoridad financiera y operativa. El NIST documenta métricas heterogéneas y comprensión limitada a escala nacional, no un baremo local listo para firmar (NIST publication page). Esta página no elige el activo a comprar: eso se trata en decisiones de inversión en planta.

Tampoco enumera los cinco modos de fallo después del piloto (por qué fracasan los proyectos de digitalización industrial), ni mide el coste de buscar información (coste de buscar información en planta), ni explica por qué un solo ingeniero absorbe alarmas y desviaciones (ingeniero de proceso como cuello de botella). Aquí el objeto es más estrecho: una frase que el comité pueda firmar.

La decisión que un comité puede aprobar: alcance, responsable, horizonte y lo que queda fuera

Una plataforma no es una decisión. Frases como “implantar analítica” o “conectar el histórico” describen un catálogo. No describen un acto que alguien pueda autorizar con fecha y límite (ISO 55000:2024). El comité necesita un paquete que separe qué se prueba, quién responde del resultado, hasta cuándo se mira la evidencia y qué queda explícitamente fuera del alcance. Sin eso, la reunión discute tecnología mientras nadie ha definido el trabajo que se autoriza.

ISO 55000 sitúa la gestión de activos en el valor a lo largo del ciclo de vida y en los objetivos de la organización, por encima de la mera compra de un sistema (ISO 55000:2024). Traducido a comité: la pregunta útil es qué valor operativo se pretende realizar, con qué activo o proceso, y bajo qué objetivo de planta. La novedad de la herramienta es secundaria.

El trabajo del NIST sobre medición del rendimiento orientada a operaciones insiste en caracterizar el sistema y analizar datos operativos antes de evaluar mejoras (NIST performance measurement). Eso es lo contrario de pedir presupuesto para “empezar a medir” sin haber nombrado el problema.

El alcance se escribe en lenguaje de decisión. Incluye la población (qué líneas, turnos o familias de producto), la tarea que se espera cambiar y la medida que se revisará. El responsable no es el proveedor ni el comité en bloque: es una persona con autoridad para liberar tiempo de planta, pedir registros y aceptar o rechazar el siguiente paso.

El horizonte es una ventana de evidencia, no un eslogan de transformación. Si el beneficio depende de incidencias poco frecuentes, la ventana tiene que ser lo bastante larga para ver varios sucesos comparables; si depende de un turno concreto, la ventana debe cubrir ese turno.

Lo que queda fuera también se escribe. Fuera puede quedar la ampliación a otras plantas, la sustitución de un sistema de control, la promesa de reducir plantilla o cualquier ahorro de caja que finanzas no haya reconocido. Declarar fuera no debilita el caso: evita que el comité oiga una frase estrecha y apruebe, sin querer, una transformación abierta.

AACE 18R-97 clasifica estimaciones según la madurez de la definición del proyecto y recuerda que el propósito de esa clasificación es mejorar la comunicación entre quienes preparan, evalúan y usan las estimaciones de coste (AACE 18R-97). Un caso de digitalización que llega al comité con definición de Clase 5 (concepto) no debería venderse como si ya tuviera la madurez de una autorización de presupuesto detallada.

La decisión aprobable, entonces, tiene cuatro casillas visibles: alcance, responsable, horizonte y exclusiones. Si falta una, la frase técnica sigue siendo una opinión de ingeniería. Si las cuatro están, el comité puede decir sí, no o “sí con este límite”, que es exactamente el tipo de voto que una reunión de capital o de gasto sabe emitir (AACE 18R-97).

Ese voto autoriza un acto con fecha y límite, no una demo de plataforma. Mantén las cuatro casillas en la misma página que la línea de beneficio, para que nadie reconstruya la decisión desde un anexo del proveedor. Si las casillas están en lenguaje de planta, quien no habla el idioma técnico puede discutir el caso sin traducir la jerga en la sala.

Si aun así no puede, el pedido no está listo para el calendario del comité.

Los registros que la planta ya tiene

El caso no empieza pidiendo sensores nuevos. Empieza inventariando lo que ya se registra: informes de incidencia, códigos de parada, partes de horas, retenciones de calidad y horas extra. Cada registro prueba algo concreto y deja otras cosas sin probar. Mezclar esas pruebas es la forma más rápida de hinchar un beneficio que el comité no podrá defender tres meses después.

Douglas S. Thomas, en el informe del NIST sobre costes y beneficios del mantenimiento avanzado, detalla las partidas que harían falta para estimar costes y pérdidas: costes directos de mantenimiento y reparación (mano de obra y materiales), costes de parada, ventas perdidas por retrasos o calidad, y retrabajo o defectos (NIST AMS 100-18).

El mismo trabajo señala que esas partidas deben separarse según el tipo de mantenimiento con la ayuda del personal de mantenimiento. Para un caso de digitalización ante el comité, la lección no es copiar un porcentaje de la literatura: es usar la misma disciplina de partidas con los registros locales.

Un informe de incidencia puede demostrar que el suceso ocurrió, cuándo se abrió y cuándo se cerró, y a veces quién intervino. No demuestra por sí solo cuántas horas de ingeniería se fueron a recopilar datos frente a diagnosticar. Un código de parada puede demostrar interrupción del tiempo programado si la planta lo usa con esa definición; no demuestra el coste de oportunidad ni el impacto en entrega.

Un parte de horas puede demostrar tiempo imputado a una orden o a una investigación; no demuestra que ese tiempo se convertirá en caja liberada si nadie cambia la plantilla o el alcance del trabajo. Una retención de calidad puede demostrar que un lote quedó retenido; no demuestra por sí sola la causa ni el tiempo de investigación.

Las horas extra pueden demostrar carga adicional; no demuestran que la causa sea la recopilación de datos de incidencias.

El proyecto del NIST sobre medición del rendimiento recuerda que las mejoras de rendimiento se obtienen hoy sobre todo con aplicaciones concretas, y que hace falta ciencia de la medición para evaluar el rendimiento en el diseño y el análisis de sistemas de fabricación inteligentes (NIST performance measurement). En la práctica de comité, eso significa elegir de antemano qué registro alimenta la medida del caso.

Si la medida es horas semanales de ingeniería en recopilación, el registro maestro es el parte de horas o el registro de tiempo ligado a las incidencias, no un cuadro de mando nuevo.

Michael Brundage describe el caso de un fabricante que compró sensores antes de decidir qué haría con los datos nuevos, aunque ya tenía órdenes de trabajo de mantenimiento difíciles de analizar (NIST, How Do We Get Smart?). El ejemplo sirve aquí como límite: pedir instrumentación nueva para justificar la digitalización suele ser una señal de que el caso aún no ha mirado los registros existentes.

ISO 22400-1 exige, entre otros criterios, que un indicador sea cuantificable, accionable y comprensible, y caracteriza cada KPI por contenido (elemento cuantificable con unidad) y contexto (lista verificable de condiciones) (ISO 22400-1). Un registro de planta solo entra en el caso si puede alimentar ese contenido y ese contexto sin reinterpretaciones silenciosas.

Cada afirmación del caso apunta a un registro existente. Cada registro declara qué no prueba. Si hace falta un dato que la planta no captura, el caso lo dice como laguna. Inventárselo como beneficio es lo que luego tumba la revisión. El inventario tiene que caber en el caso de una página.

Cinco tipos de registro bastan para empezar, y cada uno lleva una nota de una línea, “prueba / no prueba”, junto a la medida que sostiene. Sin esa nota, una reunión posterior puede tratar un código de parada como línea de caja, o el total de un parte de horas como si finanzas ya hubiera convertido las horas en coste.

Un inventario honesto de lagunas todavía permite un siguiente paso acotado. Un beneficio que depende de un registro sin dueño, no.

Traducir una frase técnica a una frase de comité

La traducción pide mecanismo, unidad, responsable y ventana. El mecanismo dice qué cambia en el trabajo. La unidad dice cómo se mide (horas, paradas, lotes retenidos, coste que finanzas reconozca). El responsable es quien convive con el resultado. La ventana fija el periodo de observación. Sin eso, “mejorar la investigación de incidencias” sigue siendo una intención.

Ejemplo trabajado. Frase técnica de partida: reducir el tiempo de investigación de incidencias. Frase de comité: recuperar horas semanales de ingeniería que hoy se pierden recopilando datos. El mecanismo no es “más analítica”; es dejar de gastar tiempo de ingeniería en reunir registros dispersos para cada incidencia. La unidad es horas por semana de ingeniería. El responsable es quien lidera la investigación o quien libera ese tiempo. La ventana es el periodo en el que se contarán incidencias y horas.

La aritmética se etiqueta como aritmética sobre inputs de la planta, no como baremo industrial. Supongamos que la planta aporta, para una ventana de cinco semanas, estos inputs propios: 15 incidencias cerradas en el perímetro acordado y un tiempo medio registrado de 4,0 horas de ingeniería por incidencia dedicado a recopilar datos (no a diagnosticar ni a ejecutar la reparación). Entonces:

15 incidencias × 4,0 h/incidencia = 60 h en la ventana
60 h ÷ 5 semanas = 12 h/semana

Esos 12 h/semana salen de la fórmula con esos inputs (ISO 22400-1). Si la planta aporta otros números, el resultado cambia. No es un ahorro de sector. No es el porcentaje de un proveedor. Tampoco es evidencia fotográfica: la imagen del artículo solo ilustra el contraste entre una nota de incidencia y una ficha en horas semanales.

ISO 22400-1 indica que los KPI de operaciones se calculan a partir de datos del dominio de control y dan soporte a la decisión en el dominio empresarial y en el de MOM, y que un indicador comparable necesita medios para referenciar las medidas de apoyo en el tiempo y un factor de normalización con unidades adecuadas (ISO 22400-1).

Convertir el total de la ventana en horas por semana es exactamente ese tipo de normalización: hace legible la carga para un comité que piensa en capacidad semanal, no en el sumatorio de un mes atípico.

El informe del NIST sobre costes de mantenimiento recuerda que las estimaciones publicadas usan métricas muy distintas y rangos amplios, y que a escala nacional hay comprensión limitada de costes y pérdidas asociados al mantenimiento (NIST publication page). Por eso esta guía prohíbe importar un porcentaje de ahorro de la literatura al caso local. Lo que sí se puede importar es la estructura de partidas: separar mano de obra, parada, calidad y retrabajo antes de sumar (NIST AMS 100-18).

Si el comité pregunta “¿y en euros?”, la respuesta honesta depende de finanzas. Las horas recuperadas no son caja hasta que exista una decisión de plantilla, de alcance o de coste evitado reconocido. El caso puede mostrar la línea de horas y, en otra línea, la condición bajo la cual finanzas aceptaría traducirlas a coste.

Meter ambas en una sola cifra sin esa condición suele costar la credibilidad en la siguiente revisión. Deja visible, junto a las horas, la condición bajo la cual finanzas aceptaría traducirlas a coste, para que una diapositiva posterior no convierta las 12 h/semana en un ahorro de caja que la planta no ha aprobado. La frase que el comité firma sigue siendo la de las horas.

El dinero es una segunda frase, con su propio responsable.

El caso de una página

Una página basta si concentra lo que el comité puede firmar y deja fuera el catálogo del proveedor. El formato mínimo lleva coste del siguiente paso, línea de beneficio, lo que no se afirma, fecha de revisión y criterio de parada. Lenguaje de planta. Registros ya citados.

El coste nombra el gasto o el esfuerzo del siguiente paso (licencia de prueba, integración acotada, horas internas), no el precio de una plataforma completa. AACE 18R-97 alinea la clase de estimación con la madurez de la definición y con el uso previsto de la estimación (cribado conceptual, estudio, autorización de presupuesto, control o licitación) (AACE 18R-97). Si el caso solo tiene definición temprana, el coste se presenta como estimación de baja madurez, no como partida cerrada de capital.

La línea de beneficio repite la frase de comité y la medida: por ejemplo, horas semanales de ingeniería en recopilación de datos de incidencias, con la fórmula y los inputs de la planta. ISO 55000 enmarca ese beneficio dentro del valor que la organización espera realizar con sus activos y objetivos (ISO 55000:2024). No hace falta narrar la transformación digital; hace falta una línea que finanzas y operaciones puedan contrastar con un registro.

Lo que no se afirma se escribe en la misma página. No se afirma un porcentaje de ahorro de sector. No se afirma que las horas se convierten solas en caja. No se afirma que el piloto escalará a otras líneas.

El Foro Económico Mundial documentó que más del 70 % de las empresas industriales seguían en “purgatorio de los pilotos”, y que entre quienes pilotaban, muchos tropezaban al alinear valor y retorno (informe WEF Beacons). Declarar lo que no se afirma es la forma de no entrar en ese purgatorio con una promesa abierta.

La fecha de revisión es una cita en el calendario, no “cuando el proveedor termine”. El criterio de parada se fija antes de gastar: si en esa fecha la medida no se mueve dentro de lo acordado, si falta el responsable o si los registros no sostienen los supuestos, el patrocinador decide detener, reparar o reducir.

El NIST subraya que hace falta caracterizar el sistema y usar datos operativos para evaluar mejoras (NIST performance measurement). Un criterio de parada sin medida es teatro de seguimiento.

La página cabe en una reunión si evita anexos que reintroducen el catálogo. Si hace falta más detalle técnico, se enlaza como apéndice para ingeniería, no como condición para que el comité entienda la decisión. Imprime la página, o añádala al orden del día, como un solo bloque: coste del siguiente paso, línea de beneficio con la fórmula, exclusiones, fecha de revisión, criterio de parada y responsable con nombre.

Si en la reunión piden el folleto del proveedor, responde con esa misma página. El comité vota ese bloque. Si el bloque está completo, aplazar por más diapositivas exige señalar una casilla vacía, no pedir un pulido vago.

Objeciones que plantea un comité no técnico

Las objeciones habituales no piden más jerga. Piden pruebas que no dependan de instrumentación nueva ni de la diapositiva del proveedor.

Teatro de piloto. El comité ya ha visto demostraciones que funcionan un día y no cambian el turno. El Foro Económico Mundial describió el purgatorio de los pilotos y la dificultad de alinear valor y ROI al escalar (informe WEF Beacons). Sin sensores nuevos, el antídoto es aburrido y eficaz: misma medida del caso, fecha de revisión, criterio de parada, registros que ya existen. Si el piloto no se alimenta de esos registros, aún no toca pedirlo.

ROI del proveedor. Un porcentaje atractivo entra en la presentación y se multiplica por la producción local. El NIST documenta que las estimaciones publicadas sobre mantenimiento usan métricas distintas y rangos muy amplios, y que el efecto de técnicas avanzadas no está bien documentado a escala nacional (NIST publication page; NIST AMS 100-18). Ese ROI se trata como hipótesis externa. Se sustituye por la aritmética local de la sección anterior.

El proveedor puede ayudar a diseñar la prueba. El número que el comité aprueba lo pone la planta.

Horas sin responsable. El comité acepta que hay carga, pero no ve quién recuperará esas horas ni qué dejará de hacerse. ISO 22400-1 incluye el criterio de que un KPI sea accionable: el equipo responsable debe tener conocimiento, capacidad y autoridad para mejorar el valor del indicador dentro de su proceso (ISO 22400-1).

Hay que nombrar al responsable operativo en la misma frase que las horas, y decir qué trabajo se reduce o se redistribuye si la medida baja. Sin dueño, las horas son un síntoma.

Queda una objeción más quieta: “¿y si compramos primero la plataforma y ya veremos el caso?”. Brundage describe la compra de sensores sin saber qué hacer con los datos, mientras las órdenes de mantenimiento ya contenían información difícil de explotar (NIST, How Do We Get Smart?). El orden correcto es el inverso: primero la frase de negocio con registros existentes; después la herramienta mínima capaz de mover esa medida.

AACE recuerda que la madurez de la definición condiciona la clase de la estimación y su uso (AACE 18R-97). Comprar la plataforma antes del caso es financiar una definición que aún no existe.

Ninguna de estas respuestas pide un sistema nuevo de adquisición de datos. Piden disciplina sobre lo que la planta ya escribe: el papel, el GMAO, el parte de horas, el registro de calidad. Si una objeción vuelve en la reunión siguiente, responde con las mismas cuatro casillas y el mismo inventario de registros, no con una presentación más larga del proveedor.

Si la preocupación es la caja, lleva a finanzas a la condición de conversión antes del voto siguiente, en lugar de inventar una cifra en euros a partir de las horas. Si la preocupación es la confianza tras pilotos anteriores, pon el criterio de parada y la fecha de revisión al principio de la página, para que el comité vea la salida antes que el gasto.

Preguntas frecuentes

¿Qué puede aprobar un comité que no entiende la tecnología?

Puede aprobar un alcance acotado, un responsable, un horizonte de evidencia y un criterio de parada expresados en horas, paradas o coste con registros de la propia planta. ISO 55000 sitúa esa decisión en el valor y los objetivos de la organización, no en la novedad del sistema (ISO 55000:2024). El NIST pide caracterizar el sistema y usar datos operativos antes de evaluar mejoras (NIST performance measurement).

Una plataforma sin esas cuatro piezas no es una decisión aprobable. El comité autoriza un acto acotado, con responsable y fecha de revisión, no una categoría de tecnología. Si falta una de las cuatro piezas, pide que reescriban el caso antes del voto.

¿Basta el ROI del proveedor para justificar la digitalización?

No. El relato del proveedor es una hipótesis; el caso de la planta necesita referencia local, mecanismo, carga total y condición de parada con números propios. El NIST muestra rangos amplios y métricas heterogéneas en la literatura de costes de mantenimiento, no un ROI transferible a cualquier centro (NIST AMS 100-18). El WEF señala la dificultad de alinear valor y retorno al salir del piloto (informe WEF Beacons).

Finanzas de la planta decide qué supuestos son aceptables. Un porcentaje del proveedor puede orientar el diseño de una prueba. No sustituye la aritmética de la planta ni el criterio de parada escrito antes de gastar.

¿Cómo se traduce reducir el tiempo de investigación a una frase de comité?

Se expresa como recuperar horas semanales de ingeniería que hoy se pierden recopilando datos, con aritmética etiquetada sobre horas registradas, recuento de incidencias y ventana. ISO 22400-1 describe contenido, contexto y normalización para que el indicador sea comprensible y comparable (ISO 22400-1). Los números los aporta la planta; no se importan de un baremo de sector. Las horas no son caja hasta que finanzas reconozca la condición de conversión.

Mantén en la misma frase el mecanismo (menos tiempo reuniendo registros dispersos), la unidad (horas de ingeniería por semana), el responsable y la ventana.

¿Qué registros demuestran el beneficio sin instrumentación nueva?

Informes de incidencia, códigos de parada, partes de horas, retenciones de calidad y horas extra ya existentes; cada uno prueba una parte y ninguno prueba solo el retorno de caja. Thomas detalla partidas de mano de obra, parada, calidad y retrabajo que deben separarse con ayuda del personal de mantenimiento (NIST AMS 100-18).

Brundage advierte contra comprar sensores antes de usar el conocimiento ya presente en órdenes difíciles de analizar (NIST, How Do We Get Smart?). Si el dato no existe, el caso declara la laguna. Elige antes el registro maestro que alimenta la medida, y escribe junto a cada registro qué prueba y qué no prueba.

¿Cuándo conviene detener el caso de digitalización?

Cuando, en la fecha de revisión acordada, la evidencia no cambia la medida elegida, falta responsable o los supuestos del caso quedan sin soporte en los registros de la planta. El criterio se escribe antes de gastar, alineado con la madurez real de la definición de la estimación (AACE 18R-97). Seguir financiando un piloto sin medida es el camino al purgatorio que documentó el WEF (informe WEF Beacons).

Detener a tiempo no es fracaso de ingeniería; es una decisión de comité con evidencia. Pon la regla de parada en la misma página que el coste del siguiente paso, para que la salida se vea antes de autorizar el gasto.

Fuentes

Hablemos

Si quieres revisar una frase técnica de tu planta y convertirla en un caso de una página (medida, registros, responsable y criterio de parada), hablemos. Trae un problema concreto y los registros que ya existen. WizeeMind ayuda a ordenar la evidencia; la aprobación sigue en el comité y en las funciones autorizadas de la planta.