Base de conocimiento

Cómo construir un caso de negocio para un sistema operativo de planta

Equipo DBR77 IRIS9 min de lectura

Pantallas de DBR77 IRIS: tarjetas KPI de OEE del MES enlazadas a informes guardados del generador, como desecho por estación

Construya el caso de negocio de un sistema operativo de planta a partir de su propia línea base, no de los porcentajes del proveedor. Mida de cuatro a seis pérdidas en una línea durante unas semanas, asigne un coste a cada una y calcule qué parte de esa pérdida debe eliminar el sistema para pagarse solo. Después deje que un piloto en una línea muestre si lo consigue, antes de comprometerse con toda la planta.

Así finanzas recibe una cifra que puede auditar, y ambas partes quedan protegidas del fallo más habitual: un caso construido con los resultados de otros. A continuación: por qué fracasan la mayoría de los casos, cómo medir una línea base, cómo valorar cada pérdida, el coste completo, la prueba del punto de equilibrio y el papel del piloto.

Por qué fracasan la mayoría de los casos de negocio para software de planta

La mayoría de los casos fracasan de una de estas tres formas. Copian porcentajes de beneficio de un folleto, así que nadie en la planta se los cree. Solo cuentan las licencias, así que el coste real aparece después. O prometen una cifra sin ninguna forma de comprobarla.

La investigación de McKinsey sobre fabricación digital concluyó que las empresas atrapadas en el "purgatorio de los pilotos" no estaban obteniendo beneficios significativos en la cuenta de resultados, y aconsejaba trabajar desde el valor en la cuenta de resultados hacia atrás y no desde la tecnología hacia delante, con una hoja de ruta por fases y un caso de negocio. Dicho de forma sencilla: empiece por lo que la planta pierde hoy.

Dónde están esas pérdidas en una planta con herramientas separadas se explica en El coste real de los sistemas aislados y las hojas de cálculo en una planta. Este artículo las convierte en un caso de negocio.

Gráfico de valores mensuales: paradas 33.000 €, tecleo 5.800 €, coste del sistema 6.000 €, equilibrio con 4 h menos de paradas

Paso 1: mida una línea base que pueda defender

Elija una línea y mida durante cuatro a ocho semanas, completando los huecos a mano si hace falta. Cada pérdida necesita una definición, una fuente y un responsable.

PérdidaCómo medirlaDónde están hoy los datosCómo valorarla
Paradas no planificadasHoras al mes, con motivos de paradaDatos de máquina, partes de turno, MESMargen de contribución perdido por hora en el cuello de botella, horas extra para recuperar
Chatarra y retrabajoUnidades o kg por semana, por tipo de defectoFormularios de calidad, MES, ERPMaterial más mano de obra más tiempo de máquina
Material tardío o ausenteMinutos que la línea espera materialNotas de turno, registros de almacénIgual que las paradas, más los portes urgentes
Volver a teclear y conciliarHoras por semana copiando datos entre herramientasPregunte a planificadores, jefes de turno y personal de calidadCoste por hora con cargas
Mantenimiento con retrasoÓrdenes de trabajo preventivas vencidas, averías repetidasCMMS, pizarraCoste de reparación, repuestos, paradas que causó
Reclamaciones de clientesNúmero por trimestre y coste de resolverlasCalidad, ventasAbonos, clasificación, envíos, pedidos perdidos

Para las pérdidas de calidad, el método del coste de la calidad de ASQ es un marco útil. Divide los costes de los fallos en costes de fallos internos, por defectos detectados antes de que el cliente reciba el producto, y costes de fallos externos, por defectos detectados después. Cuente los dos por separado.

Las cifras del sector sirven como contexto, no como su cifra. Siemens indica que una gran planta media pierde 27 horas al mes por paradas no planificadas. Su línea puede estar muy por encima o por debajo. En el caso de negocio solo cabe su propia cifra.

Paso 2: valore cada pérdida y pruebe el punto de equilibrio

No empiece por "el sistema reducirá las paradas un X %". Empiece por la pregunta que finanzas puede comprobar: ¿cuánta pérdida hay que eliminar para cubrir el coste?

Ejemplo ilustrativo: una planta de dos turnos mide una línea cuello de botella durante seis semanas. Las paradas no planificadas suman de media 22 horas al mes. Cada hora en esa línea vale 1.500 € de margen de contribución perdido, así que las paradas cuestan unos 33.000 € al mes. Planificadores y jefes de turno dedican 30 horas por semana a volver a teclear datos, a 45 € la hora, lo que añade unos 5.800 € al mes. Si el coste mensual total del sistema para esa línea es de 6.000 €, alcanza el punto de equilibrio cuando elimina unas 4 horas de paradas al mes, o una combinación menor de paradas y datos tecleados de nuevo. El equipo lo deja por escrito como objetivo del piloto.

Esto cambia el debate. En lugar de discutir la afirmación de un proveedor, el equipo se pregunta: ¿es realista eliminar 4 de 22 horas al mes? Operaciones puede juzgarlo a partir de los motivos de parada.

Mantenga dos listas separadas. Los ahorros tangibles se miden en dinero: paradas, desecho, horas extra, portes. Los beneficios intangibles, como auditorías más rápidas o una incorporación más fácil del personal, van en una lista aparte y no se suman al total. Un director financiero confiará más en el caso si la lista de intangibles está claramente etiquetada.

Paso 3: cuente el coste completo

Las cuotas de suscripción son solo una parte del coste:

  • Software: por módulo, por centro, por usuario, según el modelo de precios.
  • Implementación: configuración, limpieza de datos maestros, pruebas.
  • Integración: ERP, CMMS o WMS existentes, datos de máquina.
  • Hardware: tabletas, escáneres, dispositivos edge, cambios de red en planta.
  • Tiempo interno: usuarios clave, IT/OT, jefes de turno durante la formación. Es un coste real aunque no llegue ninguna factura.
  • Gestión del cambio: formación, nuevas rutinas, supervisión en los primeros meses.

No recorte la última partida para que cuadren los números. La investigación de Prosci concluyó que los proyectos con una gestión del cambio excelente tenían unas siete veces más probabilidades de cumplir sus objetivos que los que tenían una gestión del cambio deficiente: 88 % frente al 13 %.

Paso 4: convierta el piloto en la prueba

El piloto es donde el caso se confirma o se descarta. Antes de empezar, acuerde por escrito:

  1. La línea y el alcance: qué módulos, qué turnos.
  2. Las medidas: las mismas definiciones que en la línea base.
  3. El objetivo: la cifra de punto de equilibrio del paso 2, más un objetivo ambicioso.
  4. La fecha de decisión: cuándo compararán los resultados finanzas y operaciones.
  5. La regla: qué resultado lleva a escalar, a un segundo piloto o a parar.

Si la planta también está decidiendo un cambio de distribución o un equipo nuevo, pruébelo por separado en una simulación. Cómo construir un caso de negocio para un gemelo digital trata las decisiones de inversión. Cómo elegir entre proveedores antes del piloto se explica en Cómo evaluar un sistema operativo de planta.

Cómo funciona en DBR77 IRIS

DBR77 IRIS permite un caso de negocio que empieza en pequeño. El precio es por módulo, así que el piloto puede cubrir un módulo en una línea, y más adelante se pueden añadir módulos conservando los datos y las configuraciones. El precio mensual incluye alojamiento, actualizaciones y soporte estándar. La implementación, las integraciones a medida y la formación premium se presupuestan aparte, así que pueden figurar en la línea de costes desde el principio.

La página de precios de IRIS tiene una calculadora de retorno de la inversión que pide el número de líneas, las horas de paradas no planificadas al mes, el presupuesto de mantenimiento y el coste de la calidad. Sus resultados son estimaciones basadas en referencias del sector, así que tómelos como un primer esbozo y sustitúyalos por su línea base.

Durante el piloto, IRIS KPI y los análisis de calidad de IRIS QMS siguen las mismas medidas que la línea base: OEE, MTBF, MTTR, paradas planificadas y no planificadas, rendimiento a la primera y coste de la no calidad, con desglose desde la planta hasta la línea, el turno y la máquina. Así la comparación entre el antes y el después es un informe, no un debate.

Preguntas frecuentes

¿Podemos usar las cifras de referencia del proveedor en el caso?

Solo como contexto. Finanzas debe ver su propia línea base y un objetivo de punto de equilibrio. Las referencias de otras plantas describen otras plantas.

¿Y si no tenemos datos de línea base?

Mida a mano durante cuatro semanas en una línea: horas y motivos de parada, recuentos de desecho, horas dedicadas a volver a teclear datos. Unos datos aproximados propios valen más que unos datos precisos prestados.

¿Qué plazo de recuperación debemos buscar?

Use el mismo umbral que su planta usa para los equipos y júzguelo con las mismas reglas.

Conclusión

Un caso de negocio para un sistema operativo de planta no necesita cifras inventadas. Necesita una línea base de su propia línea, un valor para cada pérdida, una lista de costes completa y un objetivo de punto de equilibrio que un piloto pueda confirmar. Así finanzas recibe una cifra que puede auditar y operaciones un objetivo que puede asumir como propio.

Fuentes