Escoge un cuello de botella observable
Busca un proceso con retrasos, duplicación o falta de seguimiento que el equipo pueda describir con casos. Define inicio, final y excepciones. Un primer lanzamiento útil completa ese recorrido, aunque cubra pocos módulos. “Digitalizar toda la empresa” no permite estimar ni comprobar un resultado concreto.
Modela datos y responsabilidades
Nombra las entidades, sus estados y las personas que pueden cambiarlas. Separa datos maestros de transacciones y documenta la fuente autorizada. Diseña conflictos y correcciones desde el principio. Esta conversación evita que distintas pantallas presenten interpretaciones incompatibles del mismo pedido, stock o cliente.
Entrega un recorrido vertical
Conecta interfaz, reglas, datos y una integración necesaria en un recorrido pequeño. Prueba con usuarios representativos antes de ampliar. No confundas muchas pantallas con un proceso terminado: debe ser posible completar la tarea, comprobar su estado y recuperarse de un error sin depender del desarrollador.
Presupuesta también la operación
Incluye observación, soporte, copias, restauración y formación en la planificación. Asigna responsables de incidencias y cambios. Mantén un inventario de lo aplazado con su motivo y dependencia. La siguiente versión debe responder a evidencia de uso, no únicamente al deseo de sumar módulos al catálogo.
Ejemplo: de solicitud a recepción
Para una empresa de ejemplo, el primer lanzamiento podría cubrir solicitudes de compra, aprobación y registro de recepción. El solicitante crea una necesidad; una persona autorizada revisa; operaciones confirma lo recibido. Se define quién cambia cantidades y qué ocurre con una entrega parcial. El ERP existente conserva los datos contables y sigue siendo su fuente principal. La aplicación registra el estado del proceso y una referencia al documento externo, sin inventar un segundo libro contable. El piloto empieza con un grupo acotado de usuarios y casos sintéticos. Tras comprobar el recorrido, se incorporan casos reales autorizados y se decide si conviene ampliar módulos o corregir primero el proceso.
Criterios para autorizar el piloto
Comprueba que una solicitud puede recorrer todos sus estados, que un rechazo conserva su motivo y que una recepción parcial no cierra indebidamente el pedido. Prueba los permisos con cuentas distintas, no solo con una cuenta administradora. Reconcilia identificadores con el sistema principal y simula su indisponibilidad. Deben quedar claros los asuntos pendientes y cómo continuarlos manualmente. Acepta el piloto con un responsable de operación, un procedimiento de incidencias y un límite de usuarios o procesos definido. Registra por separado funciones no incluidas, como contabilidad completa o planificación avanzada, para que nadie las dé por entregadas.
Puntos clave
- Un proceso completo pequeño vale más que muchas pantallas desconectadas.