Primero respondemos cómo debería funcionar la operación. Después qué construir.
En una operación compleja, la mayoría de las decisiones de tecnología se toman antes de que alguien haya escrito cómo se supone que funciona la operación. Nosotros hacemos eso primero, y la implementación sale de ahí.
El modelo
Entra un problema operacional. Sale una decisión y, a veces, un sistema.
Algo en la operación no se sostiene: un traspaso, una decisión que llega tarde, dos sistemas que se contradicen.
- 01
Diagnosticar
Trazar cómo se mueven de verdad el trabajo, las decisiones y la información, no cómo dice el procedimiento que se mueven.
- 02
Arquitecturar
Definir estados del ciclo de vida, propiedad, derechos de decisión, traspasos, excepciones y límites entre sistemas.
- 03
Implementar
Configurar, conectar, extender o construir solo lo que la arquitectura operacional exige.
- 04
Operar y mejorar
Medir cómo se comporta el modelo operativo y seguir cambiándolo a medida que cambia la operación.
El orden de las preguntas importa
¿Cómo debería funcionar realmente esta operación?
¿Qué deberíamos construir?
En ese orden, la segunda pregunta tiene una respuesta corta y un alcance defendible. Al revés, terminas con software que codifica la confusión que venía a eliminar.
Cuatro formas de actuar sobre tus sistemas
Conectar, extender, reemplazar o transformar. Cuál aplica es un resultado de la arquitectura, no una postura inicial.
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.
Ninguna de estas se decide antes de entender el modelo operativo.
Qué puede incluir la implementación
Estas son las áreas de capacidad en las que construimos. Cada una tiene su página con el detalle operacional, y cada una se construye solo si la arquitectura lo pide.
Preguntas frecuentes
¿Un proyecto siempre termina en software?
No. Un Architecture Sprint puede concluir que tus sistemas y procesos actuales alcanzan y que el problema está en la propiedad, los derechos de decisión o la cadencia. Entregamos esa conclusión y el razonamiento que la sostiene.
¿Reemplazan nuestro ERP?
Normalmente no. Lo habitual es que el ERP siga siendo el sistema de registro de lo que ya le corresponde, y que definamos el límite y construyamos la capa operacional a su alrededor. Reemplazar un sistema es una de cuatro opciones y hay que justificarla.
¿Por dónde empieza el diagnóstico?
Por cómo se mueven hoy el trabajo, las decisiones y la información, incluidas las partes que solo existen en la cabeza de alguien. Ahí suele estar el modelo operativo sostenido a mano.
¿Y si ya sabemos qué queremos construir?
Entonces el sprint es corto y confirma o corrige el alcance. Lo que no vamos a hacer es implementar un alcance que no se pueda trazar hasta una restricción operacional.