System Design
Modelado de procesos: as-is y to-be
Explica cómo modelar procesos actuales y futuros para descubrir handoffs, esperas, decisiones, problemas y cambios operativos antes de automatizar.
- Última actualización
- Actualizada
- Nivel
- Aplicación
System Design
Explica cómo modelar procesos actuales y futuros para descubrir handoffs, esperas, decisiones, problemas y cambios operativos antes de automatizar.
Modelar un proceso no consiste en dibujar el camino ideal. Consiste en entender cómo personas, sistemas, información y decisiones producen hoy un resultado, y diseñar un futuro que la operación realmente pueda ejecutar.
Un proceso conecta actividades y responsabilidades a través del tiempo.
entrada o evento
→ actividades
→ decisiones y handoffs
→ resultadoEl modelo as-is representa la realidad actual. El to-be propone una forma futura. Compararlos permite distinguir problemas del proceso, oportunidades de automatización y cambios organizacionales necesarios.
Una solicitud como “automatizar pedidos” puede ocultar que:
Automatizar sin comprender suele acelerar errores o trasladarlos a otra etapa.
as-is
→ observar y medir
→ identificar fricción, riesgo y valor
→ diseñar to-be
→ validar transición y operaciónEl proceso no es lo mismo que un caso de uso. Un proceso puede incluir varios sistemas, personas y casos de uso; también puede contener trabajo completamente manual.
Qué activa el proceso: solicitud, fecha, llegada de datos o cambio de estado.
Trabajo realizado por una persona o sistema. Nómbralo con verbo + objeto.
Condición que determina caminos diferentes. Debe tener criterios explícitos.
Transferencia de responsabilidad o información. Es fuente frecuente de espera y pérdida.
Datos, documentos, bienes o decisiones que consume y produce cada etapa.
Rol con autoridad para ejecutar o decidir.
Variación que impide el flujo normal o exige tratamiento especial.
Tiempo, volumen, errores, retrabajo, espera o coste.
Las entrevistas tienden a describir el proceso esperado. Observa casos concretos, pantallas, hojas, mensajes y llamadas.
Toma un pedido, ticket o factura y rastrea desde origen hasta final. Registra esperas y correcciones.
“¿Qué hacen cuando…?” revela el sistema informal.
Distingue tiempo de trabajo y tiempo de espera.
5 minutos de procesamiento
+ 8 horas esperando aprobaciónOptimizar los 5 minutos no cambia el lead time principal.
Determina dónde se crea, modifica y confirma cada dato.
Cliente envía pedido por WhatsApp
→ vendedor copia productos a Excel
→ llama a bodega para confirmar stock
→ corrige productos faltantes con cliente
→ registra dirección en otro archivo
→ asigna repartidor por chat
→ cliente pregunta estado por teléfonoProblemas observables:
El futuro no debe empezar por “agregar una app”, sino por el resultado deseado.
Pedido centralizado
→ validación de datos
→ reserva de stock
→ preparación visible
→ asignación
→ entrega trazableDecisiones:
Las lanes separan responsabilidades.
Cliente | Sistema | Operaciones | RepartidorPermiten ver:
No uses una lane por departamento si el rol no cambia la responsabilidad del proceso.
| Aspecto | As-is | To-be |
|---|---|---|
| Propósito | Comprender la realidad | Proponer cambio viable |
| Fuente | Observación y evidencia | Objetivos, requisitos y diseño |
| Incluye | Workarounds y fallos | Controles, nuevas responsabilidades y transición |
| Riesgo | Idealizar el proceso actual | Diseñar algo que la operación no adopta |
Bueno para decisiones, paralelismo y responsabilidades a nivel de flujo.
Tiene semántica más rica para mensajes, eventos, timers, errores, pools y procesos organizacionales.
Suficiente para comunicar un flujo sencillo sin requerir notación formal.
Elige según audiencia y precisión. No llames BPMN a un dibujo sin su semántica.
Busca:
Un cuello de botella no siempre debe automatizarse; puede requerir eliminar una regla o cambiar autoridad.
Automatiza cuando:
No automatices una excepción rara y cambiante si una revisión humana controlada es más segura.
Cliente llama → soporte busca venta → solicita fotos por chat → manager aprueba → caja procesa devolución → inventario ajusta manualmente.
Solicitud vinculada a venta → validación de ventana y producto → evidencia adjunta → decisión según reglas → reembolso → movimiento de inventario → notificación.
El to-be todavía necesita definir excepciones: pago externo no reembolsable, producto consumido, evidencia incompleta y caída de inventario.
El to-be no aparece de una vez. Debes diseñar:
Una solución técnicamente correcta puede fracasar si el cambio operativo no está diseñado.
Decide si existe núcleo común con variantes o procesos distintos.
Puede mantenerse, pero necesita handoff y evidencia.
Mide antes de sobrediseñar.
Modela estado pendiente y reconciliación.
Evita duplicación de ownership; define servicio o capacidad común si aporta.
Identifica condición de salida y límites de reintento.
Oculta la realidad. Contrasta con casos observados.
El proceso habla de responsabilidades y resultados, no necesariamente microservicios.
La latencia real suele estar en colas y handoffs.
Primero cuestiona necesidad y valor.
Las actividades nuevas quedan huérfanas.
El equipo mantiene dos procesos indefinidamente.
Divide por nivel o subproceso manteniendo entradas y salidas.
Mide antes y después para demostrar el resultado, no solo la entrega del sistema.
Diagramas de actividad representa decisiones, paralelismo y responsabilidades del flujo con mayor precisión visual.