Estado operacional fragmentado
Por qué sistemas individualmente buenos pueden producir igual una operación de proyectos incoherente.
BoRo Studio · Parte del trabajo de BoRo sobre arquitectura operacional para la entrega de proyectos Solar + BESS.
Qué es el estado operacional
El estado operacional es la respuesta a una pregunta simple: ¿en qué está este proyecto ahora? Qué revisión de diseño está vigente, qué se compró contra ella, qué está construido, qué cambió y todavía no se absorbió, y cuánto se espera que cueste el proyecto como resultado.
El estado está fragmentado cuando esa respuesta no se puede leer en un lugar acordado y tiene que armarla una persona a partir de varias fuentes que no coinciden.
Por qué las buenas herramientas no lo evitan
Una organización de entrega típica tiene una herramienta de gestión de proyectos, un ERP para finanzas y compras, algo para control documental, una herramienta de programación y algo para la ejecución en terreno. Cada una puede estar bien elegida y bien operada.
Cada una también acierta solo en su parte. La herramienta de programación conoce el plan. El ERP conoce lo comprometido. Control documental conoce qué revisión se emitió. Ninguna está equivocada, y ninguna regla dice cuál describe el proyecto. La coherencia nunca fue trabajo de ninguna herramienta.
La reunión semanal como base de datos
Cuando ningún sistema es el registro del conjunto, la organización arma uno con personas. La revisión semanal de proyectos es donde se concilian las versiones: alguien lee el cronograma, alguien lee el reporte de costos, el jefe de proyecto aporta lo que ninguno contiene.
Funciona mientras haya atención disponible. También significa que el estado verdadero del proyecto existe durante una hora a la semana, en una sala, y empieza a degradarse cuando termina la reunión.
Límites de sistema de registro
La solución rara vez es un sistema más y casi nunca un único sistema para todo. Es un conjunto de límites: para cada dato que importa, qué sistema es el registro y qué sistemas solo lo leen.
El costo comprometido tiene un dueño. La revisión de diseño vigente tiene un dueño. El estado de un cambio tiene un dueño. Una vez que eso está escrito, que dos sistemas no coincidan deja de ser materia de opinión y pasa a ser un defecto con una corrección evidente.
Dónde mirar primero
Busca un número que dos funciones reporten distinto y que ambas puedan defender. El costo comprometido visto por compras y por control de proyecto es uno frecuente. Traza por qué difieren. La causa suele ser una diferencia de tiempo en cuándo se entera cada sistema de un cambio, que es la misma latencia de coordinación vista desde los datos.
Esa traza te dice qué límite falta. Es mejor punto de partida que una comparación de herramientas, porque parte de cómo se comporta la operación.