Cuando la entrega de proyectos Solar + BESS supera al modelo operativo
El problema no es necesariamente que a tus equipos les falte software. Es que ingeniería, compras, construcción y puesta en marcha ya no operan desde el mismo modelo.
A medida que crece el volumen de proyectos, las personas con experiencia se convierten en la capa de integración entre ingeniería, compras y construcción. BoRo diseña cómo debe operar la organización de entrega y después implementa los sistemas que ese modelo operativo exige.
¿Con quién trabaja BoRo?
BoRo Studio trabaja con empresas en crecimiento de entrega de proyectos solares y de BESS: EPC, developer-EPC y organizaciones integradas de entrega de proyectos, típicamente de 50 a 300 personas, que llevan varios proyectos a la vez entre ingeniería, compras, construcción y puesta en marcha. El gatillo habitual es que la empresa creció más rápido que su modelo operativo.
Escrito paraCOO · VP de Operaciones · Head of Project Delivery · VP de Proyectos · Director de Operaciones · liderazgo de PMO y control de proyecto · fundadores y CEO de empresas en crecimiento
La empresa creció más rápido que su modelo operativo
Nada se rompió un día en particular. Cada proyecto sumó un poco más de coordinación que el anterior, y quienes la absorben son las personas que menos puedes permitirte perder en eso.
- Más proyectos exigen una coordinación desproporcionadamente mayor.
- Los jefes de proyecto dedican una parte creciente de la semana a conciliar información.
- El estado del proyecto vive en varios sistemas, y ninguno es el acordado.
- Los cambios aprobados se propagan de forma distinta de un proyecto a otro.
- Compras trabaja con información de ingeniería que ya está desactualizada.
- La ejecución en terreno se entera tarde de las decisiones.
- Las personas senior resuelven una y otra vez la misma falla de coordinación.
En qué parte del ciclo de vida del proyecto
BoRo trabaja en la ejecución operacional posterior a la adjudicación comercial. No diseñamos originación, ventas ni estrategia comercial.
- Contexto aguas arribaOportunidad / Adjudicación
- Foco de BoRoPreconstrucción
- Foco de BoRoIngeniería
- Foco de BoRoCompras
- Foco de BoRoConstrucción
- Foco de BoRoPuesta en marcha
- Foco de BoRoEntrega
La mayor parte del trabajo está en los traspasos: de desarrollo y preconstrucción a ingeniería, de ingeniería a compras, de compras a construcción, de construcción a puesta en marcha y de puesta en marcha a la entrega.
Latencia de coordinación
El tiempo entre que se aprueba una decisión o un cambio y que todas las funciones operan desde la misma realidad.
Ingeniería aprueba un cambio.
¿Cuánto pasa hasta que cada una de estas funciones opera desde esa misma decisión?
Compras
¿La orden de compra abierta se revisó, o ya se emitió contra la revisión anterior?
Control de proyecto
¿El pronóstico ya incluye el nuevo alcance, o cambia en el próximo ciclo de reporte?
Construcción
¿La cuadrilla construye con el plano vigente, o con el que llegó a terreno la semana pasada?
Puesta en marcha
¿El plan de pruebas lo sabe, o se entera en la energización?
En la mayoría de las organizaciones de entrega en crecimiento nadie puede responder eso con un número, porque la ruta de propagación nunca se diseñó. Ocurre cuando alguien se acuerda.
Middleware humano
Los jefes de proyecto y las personas senior se convierten en la capa manual de integración. Cargan contexto entre equipos, reuniones, planillas, correos y sistemas, porque no hay un traspaso definido que lo haga por ellos.
Funciona, y por eso cuesta verlo. Tampoco escala: cada proyecto adicional consume más de las mismas pocas personas, y lo que saben sobre el estado de un proyecto no está escrito en ningún lugar donde una segunda persona pueda leerlo.
- El estado real de un proyecto es lo que diga el jefe de proyecto en la reunión semanal.
- Un cambio solo es seguro cuando una persona específica le avisó personalmente a compras.
- Incorporar a un nuevo jefe de proyecto toma meses, porque el proceso vive en las personas.
- Cuando falta una persona senior, varios proyectos se frenan al mismo tiempo.
Estado operacional fragmentado
Distintos equipos y sistemas tienen versiones distintas del estado del proyecto. Un software bueno en lo suyo puede convivir con un modelo operativo roto, porque cada herramienta acierta en su parte y nada dice cuál es el registro del conjunto.
- Gestión de proyectos
- ERP y finanzas
- Compras
- Control documental
- Programación
- Ejecución en terreno
Cada una puede ser la herramienta correcta para su función. La operación sigue siendo incoherente si ninguna es el registro acordado de en qué está un proyecto, y la conciliación vive en una reunión semanal.
Lo que suele haber debajo
Los tres patrones anteriores son lo que siente la dirección. Estas son las causas estructurales que una arquitectura tiene que resolver.
Falla de propagación de cambios
Un cambio aprobado no llega de forma confiable desde ingeniería a compras, control de proyecto, construcción y puesta en marcha.
Fallas de traspaso
El trabajo cambia de manos entre fases sin una definición acordada de qué se entrega ni de qué significa terminado.
Propiedad indefinida del ciclo de vida
Cada función es dueña de su fase. Nadie es dueño del estado del proyecto a través de todas.
Fragmentación del sistema de registro
El mismo dato se guarda en varios sistemas y ninguna regla dice cuál manda cuando no coinciden.
Techo de capacidad
La empresa no puede sumar proyectos simultáneos sin sumar una carga de coordinación desproporcionada.
Cómo lo diagnostica el Architecture Sprint
Unos diez días hábiles, trabajando a partir de lo que tus proyectos ya produjeron y no de un cuestionario.
Estados del ciclo de vida
Los estados por los que pasan de verdad un proyecto y sus paquetes de trabajo, y qué debe cumplirse para salir de cada uno.
Propiedad
Quién es dueño de cada estado, y quién es dueño del proyecto a través de las funciones.
Traspasos
Qué se entrega entre fases, a quién, y cómo sabe quien recibe que está completo.
Propagación de cambios
La ruta que sigue un cambio aprobado por todas las funciones que tienen que actuar sobre él.
Sistemas
Qué sistema es el registro de qué dato, y cuáles solo deberían leerlo.
Excepciones
Qué hace la gente cuando el camino normal no aplica, y quién puede decidir.
Derechos de decisión
Quién decide qué, con qué información, y a quién hay que avisarle.
Un sprint puede concluir que no conviene construir software a medida. Es un resultado real y lo entregamos.
La tecnología sigue a la arquitectura
Si la arquitectura identifica una brecha de sistemas, hay cuatro formas de cerrarla. Cuál aplica es un resultado del sprint, no una posición de partida.
Conectar
Los sistemas son los correctos pero no se hablan. Construimos la integración y las reglas de propiedad del estado entre ellos.
Extender
El sistema de registro es el correcto pero está incompleto. Agregamos la capa operacional que le falta.
Reemplazar
Un sistema está frenando activamente el modelo operativo y tiene que salir.
Transformar
La operación necesita una capa de control que no existe en ningún producto que puedas comprar.
¿Calza con tu operación?
Buen calce
- Varios proyectos simultáneos
- Varios equipos especializados
- Varios sistemas, cada uno bueno en lo suyo
- Una carga de coordinación que crece más rápido que el volumen de proyectos
- Personas con experiencia actuando como capa de integración
- Un crecimiento que deja a la vista las debilidades del modelo operativo
No calza
- Un solo equipo pequeño
- Un solo flujo simple
- Un software estándar ya resuelve la operación
- La necesidad principal es capacidad de desarrollo barata
Qué podemos mostrarte y qué no
La entrega de proyectos Solar + BESS es el foco comercial actual de BoRo. No publicamos casos de clientes de este sector y no vamos a insinuar ninguno. Lo que sí podemos mostrar es trabajo real en otras operaciones, y arquitecturas de ejemplo de entrega de proyectos que están marcadas como ejemplos.
Para seguir leyendo sobre entrega de proyectos
- Middleware humano en la entrega de proyectosCómo las personas con experiencia se convierten en la capa de integración entre ingeniería, compras y construcción.
- Latencia de coordinación¿Cuánto tarda una decisión de proyecto en convertirse en realidad operacional?
- Propagación de cambios de ingenieríaCómo debería moverse un cambio aprobado por ingeniería, compras, control de proyecto, construcción y puesta en marcha.
- Estado operacional fragmentadoPor qué sistemas individualmente buenos pueden producir igual una operación de proyectos incoherente.
- Capacidad de entrega de proyectosPor qué sumar más proyectos puede generar una carga de coordinación desproporcionada.
Conversemos una restricción operacional
Cuéntanos dónde te está costando la coordinación. Si la respuesta es que no necesitas construir nada, te lo vamos a decir.
Conversemos una restricción operacional