Architecture Sprint
Diez días hábiles para entender dónde se está rompiendo el modelo operativo y determinar qué conviene implementar, si conviene implementar algo.
Trazamos cómo se mueven el trabajo, las decisiones y la información entre las funciones involucradas, y escribimos la arquitectura operacional que la operación realmente necesita. El resultado es una decisión sobre la que puedes actuar, con el razonamiento a la vista.
¿Qué es un Architecture Sprint de BoRo?
Un Architecture Sprint de BoRo es un diagnóstico de duración fija, de unos diez días hábiles. BoRo traza cómo se mueven el trabajo, las decisiones y la información entre las funciones de una operación, escribe la arquitectura operacional que necesita y entrega una decisión sobre qué conviene implementar, si conviene implementar algo. Puede concluir que no conviene construir software a medida. Un sprint cuesta típicamente US$3.000–7.500.
- Proyecto típico
- US$3.000–7.500
- Duración
- Unos diez días hábiles
Rango típico del proyecto de entrada.
La mayoría de los sprints que estamos dimensionando hoy son para empresas de entrega de proyectos Solar + BESS. Cómo se aplica a la entrega de proyectos Solar + BESS
Qué dispara un sprint
No un ciclo de planificación. Una restricción concreta que alguien de la operación ya sabe nombrar.
- Personas con experiencia pasan el día trasladando contexto entre equipos y sistemas.
- Una decisión cambia y la operación entera tarda semanas en actuar sobre ella.
- Dos funciones reportan números distintos de lo mismo, y las dos tienen razón.
- El trabajo se queda detenido en traspasos que nadie tiene a cargo.
- Estás por comprar o construir software y no puedes enunciar qué problema resuelve.
Qué pasa en diez días hábiles
Cuatro bloques. Al final no se escribe nada que no se haya trazado durante el trabajo.
- Días 1–2
Recepción de evidencia
Leemos lo que la operación ya produce, en vez de pedirle que se describa de memoria.
- Días 3–5
Trazar el flujo real
Entrevistas con quienes de verdad cargan el trabajo entre funciones, siguiendo unidades de trabajo concretas de punta a punta.
- Días 6–8
Escribir la arquitectura
Estados y compuertas del ciclo de vida, derechos de decisión, límites de sistema de registro, propagación de cambios, traspasos y excepciones.
- Días 9–10
Decidir
Hoja de ruta priorizada, la salida que recomendamos y una lectura ejecutiva donde se toma la decisión.
Quién participa habitualmente
Entre seis y diez personas, unas pocas horas cada una. Trabajamos alrededor de la operación, no en lugar de ella.
- Un sponsor ejecutivo que pueda cambiar cómo se opera, no solo qué se compra
- Los responsables de las funciones a cada lado de los traspasos que están fallando
- Las personas que hoy son la capa de integración, con nombre y apellido
- Quien es dueño de cada sistema de registro, incluido el ERP
- Finanzas o control de proyecto, cuando los números no coinciden entre funciones
Qué evidencia examinamos
Documentos y estado de los sistemas, no un cuestionario. Miramos lo que la operación produjo cuando nadie la estaba observando.
- Artefactos del ciclo de vida de unidades de trabajo reales: órdenes, proyectos, avisos de cambio, trabajos de servicio
- La cadena de una decisión que cambió, y cuándo empezó a actuar cada función
- La misma cifra reportada por dos funciones distintas, y por qué difieren
- Dónde se vuelve a tipear información a mano entre sistemas
- Caminos de excepción: qué hace la gente cuando el flujo normal no aplica
- Las reuniones e informes de los que la operación depende hoy para mantenerse alineada
Qué recibes
Arquitectura operacional del estado actual
Cómo funciona la operación hoy, incluyendo las partes que solo existen en la cabeza de alguien.
Modelo de estados y compuertas del ciclo de vida
Los estados por los que pasa una unidad de trabajo y qué debe cumplirse para salir de cada uno.
Mapa de derechos de decisión
Quién decide qué, con qué información, y a quién hay que avisar.
Límites de sistema de registro
Qué sistema es dueño de qué dato, para que dos sistemas dejen de contradecirse sobre la misma realidad.
Mapa de propagación de cambios
Qué le pasa al resto de la operación cuando una decisión cambia.
Arquitectura de traspasos y excepciones
Dónde cambia de manos el trabajo y qué ocurre cuando el camino normal no aplica.
Cadencia de gestión e indicadores
Las reuniones y los números que mantienen honesto al modelo operativo.
Hoja de ruta de implementación priorizada
Qué hacer primero, qué postergar y qué no hacer.
Lectura ejecutiva de decisión
Una sesión donde la decisión se toma, no un documento que se archiva.
Decisiones que salen
- Quién es dueño de cada estado del ciclo de vida y qué debe cumplirse para salir de él
- Qué sistema es el registro de cada dato y cuáles solo lo leen
- Cómo se propaga un cambio y qué tiene que ocurrir de forma automática
- Qué traspasos necesitan un contrato explícito y cuáles deberían desaparecer
- Qué implementar, en qué orden y qué no implementar
Cómo puede terminar un sprint
El resultado no es automáticamente una propuesta de software. Cuatro salidas honestas:
- A
No hace falta construir
Los sistemas y procesos actuales alcanzan. El problema está en otra parte y lo decimos.
- B
Cambios en el modelo operativo
Hay que cambiar gobernanza, proceso o propiedad del estado. Sin software nuevo.
- C
Se justifica implementar
Hay una configuración, integración o capa de control que vale la pena implementar.
- D
Operations OS
La arquitectura requiere una capa de control operacional mayor.
Arquitectura antes que implementación. Operations OS.
Qué no es
- No es una demo de software.
- No es una venta de licencias con una etapa de descubrimiento adelante.
- No es un informe que da por supuesto que la respuesta es tecnología.