Puntos clave
El incentivo del equipo del proyecto termina en la puesta en marcha. El contrato era entregar el activo operativo; una vez que está produciendo, el proyecto ha terminado. El equipo rota al siguiente proyecto. La documentación que existe en los archivos del proyecto pero no en manos del equipo de operaciones se pierde en la transición. El conocimiento que vivía en la cabeza del ingeniero del proyecto abandona el edificio.
El equipo de operaciones hereda un activo que funciona el primer día y acumula problemas durante el siguiente trimestre.
Algunos de esos problemas están documentados en los archivos del proyecto que nadie entregó; algunos están en la cabeza del ingeniero OEM que nadie conoció; algunos están en el código de integración de terceros que nadie sabe cómo modificar.
La primera falla mayor obliga a un ejercicio de ingeniería inversa que debería haber sido una conversación de 30 minutos.
La solución es procesal. Una lista de verificación de entrega que se ejecuta en los últimos 30 días del proyecto captura la mayoría de las lagunas antes de que se conviertan en deuda operativa. El artículo sobre el sistema de gestión de órdenes de trabajo cubre las estructuras de datos a las que alimenta la salida de la entrega.
No el contacto de ventas, no el correo de soporte, sino el ingeniero real que conoce este activo específico. Cuando algo falla en el mes cuatro, el equipo de operaciones necesita contactar a alguien que haya trabajado en este activo, no a una cola de soporte genérica. La entrega debe capturar este contacto y el ingeniero debe ser informado para que espere la llamada.
Toda instalación tiene tolerancias que se aplicaron en campo pero que nunca regresaron a los documentos de diseño.
El activo se niveló con una configuración específica de calzas; el alineamiento se ajustó a una tolerancia más estricta que la estándar; el caudal de agua de refrigeración se ajustó a un valor que el manual no menciona. Estos ajustes a menudo marcan la diferencia entre que el activo funcione bien o mal.
El artículo sobre análisis de causa raíz explica cómo estas tolerancias no documentadas aparecen en fallos tempranos.
Código personalizado, configuraciones, scripts de integración, normalmente escritos por un tercero durante la puesta en marcha. El equipo de operaciones necesita saber quién posee este código, quién puede modificarlo y cómo es el acuerdo de soporte. Sin esto, el primer problema de integración seis meses después se convierte en una investigación de varias semanas para averiguar quién puede siquiera cambiar el código.
Qué se cambió durante la puesta en marcha que no estaba en el diseño original. Cambios en el cableado, rutas de tuberías, ajustes en la lógica de control. Estos casi siempre existen; casi nunca llegan a los planos "tal como construido" a menos que el proceso de entrega los capture explícitamente.
No la secuencia de arranque documentada, sino la real que usó el equipo de puesta en marcha. La mayoría de los activos tienen un ritual de arranque que el OEM no documenta: qué válvula se abre primero, cuánto tiempo esperar antes de energizar, cuál debe ser la primera lectura. Ese ritual a menudo marca la diferencia entre un arranque limpio y uno que daña el equipo.
Cada activo tiene peculiaridades que conoce el equipo de puesta en marcha. "El tercer indicador marca un 5% de más
lo calibramos contra el maestro." "El PLC tarda 30 segundos más de lo que dice el manual en arrancar después de un corte de energía." "El motor consume más de lo esperado en arranque en frío esto es normal." Estas peculiaridades ahorran al equipo de operaciones semanas de investigación cuando se las encuentran.
Los manuales describen cadencias de PM genéricas; los ingenieros OEM a menudo recomiendan cadencias más estrictas o más laxas según la instalación específica, el ciclo de trabajo y las condiciones locales. La entrega captura la recomendación que hizo el ingeniero OEM, no solo el valor predeterminado del manual. El artículo sobre el programa de mantenimiento preventivo explica cómo esto informa el diseño de PM a largo plazo.
Lo que al equipo de puesta en marcha no le sorprendería ver en los primeros 90 días, incluso en una instalación exitosa. Los sellos nuevos se asientan, ciertos pernos necesitan un reajuste tras el ciclo térmico, la deriva del sensor en el primer mes es normal. Sin esta lista, cada problema menor parece un defecto de instalación.
La estructura que captura los ocho elementos:
El artículo sobre KPI de fabricación cubre las métricas post-puesta en marcha que muestran si la entrega fue exitosa.
La medida honesta es el MTBF del primer trimestre comparado con el MTBF estimado del proyecto. Una entrega limpia produce un número del primer trimestre cercano al estimado. Una entrega omitida produce un número del primer trimestre muy por debajo del estimado, con la brecha cerrándose en 6-12 meses a medida que el equipo de operaciones redescubre lo que el equipo del proyecto ya sabía.
Las plantas que siguen esta métrica en múltiples proyectos de capital construyen un bucle de retroalimentación: los equipos de proyecto que entregan bien consiguen negocios repetidos; a los equipos de proyecto que no lo hacen se les exige responsabilidad por la brecha. La disciplina se propaga con el tiempo.
La lista de verificación de entrega funciona en cualquier planta con un CMMS. Donde una plataforma unificada de OEE + CMMS ayuda es en dos puntos: los ocho elementos de la entrega se convierten en campos permanentes asociados al activo (no enterrados en una carpeta del proyecto)
y la lista de problemas esperados en los primeros 90 días se vincula al flujo de eventos de OEE para que el equipo de operaciones pueda distinguir "patrón esperado" de "problema real" sin tener que memorizarlo. Fabrico está construido para ese flujo de trabajo.
Para ver cómo se ve un registro de activo listo para la entrega, programa una demo .
La función de proyectos de capital de la planta, con operaciones como la parte receptora. Si la planta no tiene una función dedicada de proyectos de capital, el ingeniero de planta o el director de operaciones asume el rol. Sin un único responsable, la lista de verificación se degrada a "responsabilidad de todos".
La lista de verificación de entrega se convierte en un entregable contractual. El contratista debe cobrarse contra la entrega exitosa, no solo contra la puesta en marcha. Los contratos EPC que pagan solo en la puesta en marcha producen de forma consistente los peores resultados de entrega.
90 días como mínimo. Los primeros 90 días revelan la mayoría de los problemas que la entrega omitió; la disponibilidad del equipo del proyecto durante ese período es lo que llena las lagunas residuales.
Ese es el camino desafortunado. El equipo de operaciones tiene que reconstruir los ocho elementos por sí mismo, normalmente por ensayo y error durante los primeros 6-12 meses. La lista de verificación existe para prevenir este escenario; una vez que ha ocurrido, la única solución es documentar lo que descubran para que la próxima entrega sea mejor.
Ejecutar la lista de verificación como papeleo en lugar de como conversación. Los ocho elementos anteriores se capturan mejor en un recorrido conjunto con los equipos de proyecto y operaciones juntos, no como un formulario que el equipo del proyecto rellena solo. La conversación saca a la luz las peculiaridades; el formulario captura las casillas marcadas.
Iniciar sesión
Blog
