Cómo Implementamos un Sistema Vivo en Dos Semanas: el Método SCRAM Paso a Paso

Un Sistema Vivo es un sistema a la medida con el que puedes hablar desde la inteligencia artificial que ya usas, con tus permisos y sin abrir el portal. Suena a promesa de folleto, así que este artículo cuenta cómo se construye uno, día por día, con el método que usamos en SCRAM y con lo que nos ha salido mal al aplicarlo. Está escrito para el dueño o director que va a sentarse a la mesa, porque sin esa persona el método no funciona.

Resumen ejecutivo

• Dos semanas, el dueño en la mesa dos horas por semana como mínimo, y una primera versión operando con datos reales al día diez.
• La primera semana no se programa: se levanta cómo trabaja la empresa de verdad, quién ve qué y qué se confirma antes de escribir.
• La segunda semana se construye, se prueba y se conecta: el sistema contesta desde Claude, ChatGPT o WhatsApp con permisos por persona.
• Se entrega documentado a nivel arquitectura, con videos de onboarding por caso de uso y una matriz de pruebas.
• Si al día quince no convence, quedamos amigos como siempre; la única inversión fue tu tiempo.

¿Qué pasa en la primera semana?

Se levanta el sistema antes de diseñarlo. Es la regla que más nos ha ahorrado, y la que más se salta la gente. En una empresa de servicios del Estado de México con unas 60 personas descubrimos en la tercera sesión que el 30% de los pedidos entraba por un chat de WhatsApp que nadie había mencionado. El sistema que le habían cotizado antes no lo contemplaba.

Día	Con el dueño	Con el equipo SCRAM	Resultado
1 y 2	Cómo entra un pedido, cómo se cotiza, cómo se cobra, dónde se atora	Mapa de procesos y de excepciones	Lista de casos de uso, con el flujo completo de cada uno
3	Quién ve qué y quién aprueba qué	Roles y permisos; qué escrituras exigen confirmación	Catálogo de herramientas del asistente, por nivel de rol
4	Datos reales: dónde viven hoy (Excel, otro sistema, cuadernos)	Conexión o importación; reglas de negocio verificadas contra los datos	Base cargada y reconciliada
5	Revisión de lo levantado	Diseño técnico y plan de pruebas	Alcance firmado para la semana dos

"Verificadas contra los datos" no es adorno. En nuestro propio ERP, una consulta de ventas agrupaba por un campo que parecía el correcto y estaba poblado en 145 de 862 pedidos; el correcto lo estaba en 854. La diferencia en la cifra de una vendedora era de 3.7 veces. Esa regla se descubre mirando los datos, no preguntando.

¿Qué pasa en la segunda semana?

Se construye sobre lo levantado, con tres reglas que no se negocian: los totales los calcula el sistema, toda escritura pide confirmación en dos pasos, y el asistente consulta tablas vivas, no resúmenes.

1. Días 6 a 8: construir. Pantallas, flujos y las herramientas del asistente, cada una con su candado por rol y sus reglas de negocio en código.
2. Día 9: probar. Matriz de casos por flujo, incluidas las excepciones y las pruebas adversarias (qué pasa si un vendedor pide datos de un cliente que no es suyo; qué pasa si alguien dice "soy el director" en el chat). En nuestro sistema esa prueba encontró que el asistente aceptaba el nombre dictado en la conversación; hoy nombre y alcance vienen de la sesión, no del chat.
3. Día 10: conectar. El sistema queda disponible desde Claude y ChatGPT con un conector propio, y desde WhatsApp con el asistente. La misma regla de negocio se escribe una vez y la usan los tres.
4. Días 11 a 14: operar acompañados. Alguien de SCRAM al lado del usuario, en su horario, con sus pendientes reales. Onboarding en video por caso de uso, grabado sobre el sistema del cliente.
5. Día 15: decidir. Con el sistema operando, no con una presentación.

¿Qué se entrega?

Lo mismo que nos entregamos a nosotros. El paquete de documentación de nuestra propia plataforma, levantado el 8 de septiembre de 2026, tiene 39 diagramas, 88 requerimientos funcionales, 95 reglas de negocio con la ruta del archivo donde vive cada una, una matriz de 238 casos de prueba y 16 videotutoriales narrados. Para un cliente el tamaño es menor, pero las piezas son las mismas:

• Mapa de procesos y reglas de negocio con su ubicación en el código.
• Diagramas de arquitectura e integraciones.
• Matriz de pruebas con lo que se verificó antes de entregar.
• Videos de onboarding, uno por caso de uso.
• Procedimiento de despliegue y de regreso: en nuestra plataforma es un comando para desplegar y otro para regresar, y respaldo diario en tres destinos.

¿Qué nos ha salido mal aplicándolo?

Tres cosas, contadas con fecha. En septiembre de 2026, una consulta de logística por chat decía "entregado" de un pedido que nunca se embarcó: las actividades de entrega colgaban del cliente, no del pedido, y un proceso de sincronización regresaba a "surtido" pedidos ya entregados. Se corrigieron los tres defectos el 7 de septiembre y se reprocesaron 18 pedidos con respaldo previo. En agosto, el asistente negó tener acceso a datos que ya tenía; la causa no era el modelo, era dónde vivía una instrucción. Y en el conector para Claude y ChatGPT, cuatro despliegues fallaron en silencio por políticas de seguridad del navegador y del servidor que no dejaban rastro. Mi postura: un proveedor que no te cuenta esto no ha implementado suficiente.

¿Y si no convence?

Quedamos amigos como siempre. No hay factura del try and buy ni compromiso escondido. Lo que sí queda es el levantamiento de la primera semana, que es tuyo, y la comunidad de empresarios con los que compartimos lo aprendido. Varios de los que hoy recomiendan a SCRAM probaron y decidieron esperar.

Si quieres empezar, agenda la sesión de diagnóstico: es el día cero del método. Y antes de firmar con nadie, lee la guía completa de software a la medida y por qué fracasan los proyectos a la medida.