Cuando un pedido, una solicitud o un caso atraviesa varias aplicaciones, es habitual que cada equipo vea una versión diferente de su situación. El CRM puede mostrarlo como «cerrado», la herramienta operativa como «pendiente» y atención al cliente como «en espera». No siempre es un fallo técnico: con frecuencia es el resultado de no haber definido qué representa cada estado, qué sistema tiene autoridad para cambiarlo y qué hechos lo justifican.
El diseño de estados de proceso en integraciones convierte un recorrido de negocio en un contrato comprensible entre producto, operaciones y tecnología. Su objetivo no es imponer un catálogo idéntico a todas las aplicaciones. Es conseguir que un estado compartido tenga un significado inequívoco, una evidencia observable y reglas de transición que todos los sistemas conectados respeten.
Diagnosticar si hace falta un estado compartido
No todos los sistemas deben usar los mismos estados internos. Una aplicación puede requerir pasos técnicos que no aportan valor a otros equipos: validación de formato, cola de trabajo, sincronización o cálculo. El problema aparece cuando un estado se usa para coordinar decisiones entre dominios distintos o para comunicar una promesa al cliente.
Conviene establecer un modelo compartido si se da una o varias de estas señales:
- Dos equipos responden de forma distinta a la pregunta «¿qué ha ocurrido con esta solicitud?».
- Una aplicación habilita una acción basándose en un estado que otra aún no reconoce.
- Las cancelaciones, rechazos o reanudaciones se gestionan por canales manuales.
- Los informes agregan etiquetas locales que parecen equivalentes, pero incluyen casos diferentes.
- Los reintentos de una integración devuelven un proceso a una fase anterior o duplican tareas.
Si la necesidad es solo mostrar información local, una tabla de traducción puede ser suficiente. Por ejemplo, varios estados técnicos pueden proyectarse como «en curso» en una vista de negocio. Pero si varios sistemas deciden, facturan, notifican o cierran trabajo según esa fase, hace falta un contrato explícito. Traducir etiquetas no sustituye definir responsabilidades ni transiciones.
Diseñar el modelo desde el recorrido de negocio
El mejor punto de partida no es la lista de estados de una herramienta existente, sino el ciclo que vive la entidad de negocio. Dibuje el recorrido completo de un pedido, caso o solicitud y pregunte qué compromiso representa cada etapa. En muchos procesos transversales aparecen cinco momentos, aunque sus nombres cambien:
- Inicio: la entidad existe y se ha recibido o creado.
- Evaluación o compromiso: se valida la información y se acepta, rechaza o solicita una corrección.
- Ejecución: hay trabajo activo para cumplir el compromiso.
- Resultado: la ejecución termina con éxito, fallo, rechazo o cancelación.
- Cierre: se completan efectos posteriores, como comunicación, conciliación o archivo.
Estos momentos no obligan a crear cinco estados. Sirven para descubrir decisiones relevantes. Un estado merece existir cuando modifica qué puede hacer una persona o sistema, qué expectativa debe recibir otra parte o qué control operativo es necesario. Si dos estados producen exactamente las mismas decisiones, probablemente añaden complejidad sin valor.
Para cada estado compartido, documente como mínimo:
- Su definición en lenguaje de negocio y la condición observable que la acredita.
- La entidad a la que aplica y, si procede, su alcance: solicitud completa, línea, envío o tarea.
- El sistema propietario que puede confirmarlo.
- Los estados de origen permitidos y los desencadenantes válidos.
- Las acciones habilitadas, prohibidas o requeridas al entrar en él.
- La política de salida: automática, manual, por evento externo o por tiempo.
Una definición como «completado cuando el equipo termina» es ambigua. Es preferible: «completado cuando el sistema operativo registra que todas las tareas obligatorias de la solicitud han finalizado correctamente». Así se puede comprobar, auditar y automatizar.
No mezclar estado, evento, motivo y acción
Gran parte de la incoherencia proviene de usar una sola etiqueta para conceptos diferentes. Separarlos reduce discusiones y permite conservar contexto sin multiplicar estados.
- Estado: condición actual persistente de la entidad, como «en ejecución» o «cancelada».
- Evento: hecho ocurrido en un instante, como «pago autorizado», «documentación recibida» o «operación iniciada».
- Motivo: explicación codificada de una decisión o resultado, como un motivo de rechazo o cancelación.
- Acción: instrucción para provocar un cambio, como «cancelar solicitud», «reintentar envío» o «asignar agente».
Por ejemplo, «cliente llamó» no debería ser un estado: es un evento de interacción. «Cancelada por duplicado» combina un estado final y un motivo. Separar ambos permite medir cancelaciones sin perder la causa y evita crear una lista interminable de variantes.
También hay que distinguir estado de negocio y estado técnico. «Mensaje pendiente de publicar» puede ser esencial para observabilidad, pero no debe reemplazar «solicitud aceptada». Mantenga el estado de negocio estable frente a los detalles de transporte; exponga los datos técnicos cuando ayuden a resolver incidencias.
Asignar autoridad y controlar las transiciones
Un estado compartido necesita una fuente de verdad por cada decisión, aunque la entidad se replique en varios lugares. El CRM puede ser propietario de la admisión de una solicitud; el sistema operativo, de su ejecución; y un sistema financiero, de una confirmación de cobro. Lo peligroso es permitir que varios sistemas escriban el mismo estado sin una regla de precedencia.
Construya una matriz sencilla con estado, sistema autorizado, evidencia y consumidores. Después defina transiciones permitidas. Un diagrama es útil, pero las reglas deben poder implementarse. Por ejemplo:
recibida -> validada -> en_ejecucion -> completada recibida|validada|en_ejecucion -> cancelada validada -> rechazada
No todas las transiciones deben ser reversibles. Los estados terminales deben tratarse como terminales salvo una corrección gobernada. Si aparece un error tras marcar «completada», no conviene volver silenciosamente a «en ejecución». Registre una acción de corrección, el motivo, el responsable y, si el negocio lo exige, un nuevo ciclo o una entidad derivada.
Los estados intermedios son necesarios cuando cambian una expectativa o una regla operativa. «En espera de cliente» puede justificar detener un plazo y activar una comunicación; «en cola» quizá sea una condición interna que no debe salir del sistema operativo. Defina además límites temporales: cuánto puede permanecer una solicitud en cada fase, quién revisa la excepción y qué alerta se genera.
Cancelar, reintentar y recuperar sin crear regresiones
Las integraciones distribuidas fallan, se retrasan y pueden entregar el mismo mensaje más de una vez. El diseño del estado debe asumirlo. Publicar un cambio no implica que todos los consumidores lo procesen una única vez ni en orden perfecto.
Para cada cambio de estado, publique un identificador estable de la entidad, un identificador único del evento, el nuevo estado, la fecha efectiva, el origen y una versión o secuencia. Un consumidor debe poder ignorar con seguridad un evento ya aplicado y detectar uno antiguo. La operación de actualización ha de ser idempotente: procesar dos veces el mismo cambio no puede crear dos tareas, dos notificaciones ni dos cancelaciones.
Los reintentos técnicos tampoco deberían cambiar por sí mismos el estado de negocio. Si un mensaje que anuncia «en ejecución» falla al entregarse, reintente su entrega y registre el incidente; no vuelva la solicitud a «validada». Cuando haya mensajes fuera de orden, decida una política explícita: rechazar eventos con una versión menor, conservarlos para revisión o admitirlos solo si la transición sigue siendo válida.
La cancelación requiere una decisión de negocio clara. Determine:
- Qué estados admiten cancelación por cliente, por operación o automáticamente.
- Qué efectos deben compensarse: tareas, reservas, comunicaciones o movimientos posteriores.
- Cuándo la cancelación es inmediata y cuándo queda «solicitada» hasta que un sistema confirme que puede detener el trabajo.
- Qué motivos son obligatorios y qué roles pueden ejecutar una corrección manual.
Una modificación manual debe dejar trazabilidad; no es una excepción invisible. Guarde quién la hizo, cuándo, por qué, qué estado anterior había y qué efectos se notificaron. Esta información permite resolver reclamaciones y mejorar reglas defectuosas.
Ejemplo y controles antes de desplegar
Imagine una solicitud que nace en un formulario, se gestiona en un CRM, se realiza en una aplicación operativa y se consulta desde atención al cliente. El formulario puede crear «recibida», el CRM confirmar «validada» o «rechazada», y la operación declarar «en ejecución» y «completada». Atención al cliente consume el estado compartido, pero no lo modifica. Si el cliente pide cancelar durante la ejecución, atención crea una acción de cancelación; el sistema operativo confirma después «cancelada» o informa de que ya no es posible detenerla. Así se evita que una petición se confunda con un resultado.
Antes de implementar, revise este checklist:
- ¿Cada estado responde a una decisión real de negocio u operación?
- ¿Existe una condición observable y un único sistema autorizado para confirmarlo?
- ¿Están separadas las causas, los eventos y las acciones del estado persistente?
- ¿Se han definido transiciones inválidas, estados terminales y correcciones excepcionales?
- ¿Los consumidores soportan duplicados, retrasos y mensajes fuera de orden?
- ¿Hay alertas para permanencias anómalas y conciliación entre fuente y réplicas?
- ¿Los cambios del contrato incluyen versión, responsables y un plan de compatibilidad?
El modelo debe evolucionar con el proceso, pero no mediante cambios informales de etiquetas. Revise periódicamente los estados con más esperas, intervenciones manuales, discrepancias o consultas de soporte. Esas señales indican que una definición es insuficiente, que falta un evento o que se está usando un estado técnico para representar una decisión de negocio. Un contrato pequeño, explícito y gobernado es más útil que un catálogo exhaustivo que ningún sistema interpreta igual.