La respuesta depende. Las condiciones, a la vista.
Registros concretos de decisiones de procesos y sistemas bajo premisas explícitas, porque una decisión sin su contexto se convierte en una regla que nadie recuerda cómo cuestionar.
01Registro18 registros
- ADR / 001Crear el cliente en el ERP de forma asíncronaProteger el flujo comercial de la latencia del ERP, con el estado pendiente y la recuperación explícitos.Aceptada para las premisas planteadasIntegraciónERPResiliencia
- ADR / 002Ubicar los KPI comerciales según su horizonte de acciónElegir entre CRM, plataforma de datos o data warehouse por latencia y capacidad de acción, no por una pretensión universal de fuente de referencia.Patrón propuestoAnalíticaCRMDatos
- ADR / 003Usar código en las fronteras de orquestaciónMantener declarativas las reglas locales y transparentes; llevar la orquestación con estado y entre sistemas detrás de fronteras de servicio probadas.Patrón propuestoAutomatizaciónGobiernoIntegración
- ADR / 004Separar la aprobación comercial de la validación financieraDos decisiones con distintos responsables, evidencias y SLA no deben compartir un único paso de aprobación, aunque un mismo formulario recoja los datos de ambas.Patrón propuestoProcesosGobiernoERP
- ADR / 005Separar la identidad comercial de la identidad legal del clienteUna cuenta es una relación comercial; una entidad legal es una organización registrada; un cliente del ERP es esa entidad en una de nuestras sociedades. Modelar tres identidades vinculadas, no un registro que signifique todo a la vez.Patrón propuestoIdentidadCRMERP
- ADR / 006Resolver la variación regional con configuración, no con bifurcaciones del CRMLas diferencias locales legítimas van en puntos de configuración declarados y, rara vez, en extensiones registradas; nunca en copias del modelo de datos o del ciclo de vida global.Patrón propuestoCRMGobiernoVariación
- ADR / 007Tratar un resultado de integración incierto como desconocido, no como fallidoUn timeout no dice nada sobre si el receptor confirmó la operación. Modelar ‘desconocido’ como estado propio, resolverlo por clave de petición y solo entonces reintentar o darlo por fallido.Patrón propuestoIntegraciónResilienciaERP
- ADR / 008Mantener la conciliación como control permanente, no como proceso de excepciónLas garantías de entrega fallan en silencio. Una comparación programada entre las poblaciones esperada y real, con un responsable para cada tipo de diferencia, forma parte de la arquitectura; no es una limpieza.Patrón propuestoIntegraciónDatosGobierno
- ADR / 009Modelar la automatización de larga duración como un registro de ejecución con máquina de estadosCuando la automatización abarca varios pasos, sistemas o días, cada ejecución necesita identidad, estado y guardas por paso, para poder esperar, fallar, reanudarse y terminar exactamente una vez.Patrón propuestoAutomatizaciónOrquestaciónOperaciones
- ADR / 010Automatizar las salidas, no solo las entradasToda automatización que crea trabajo cuando un registro entra en un estado debe definir también qué ocurre cuando sale de él; si no, el estado posterior queda obsoleto.Patrón propuestoAutomatizaciónRevOpsDatos
- ADR / 011Definir las etapas del pipeline por estado de negocio y criterios de salida, no por probabilidadUna etapa dice qué es cierto sobre la oportunidad y qué debe ocurrir para salir de ella. La probabilidad y la categoría de forecast se derivan de ahí; nunca se introducen a mano en su lugar.Patrón propuestoRevOpsPipelineCRM
- ADR / 012Gobernar los objetivos como datos versionados, con un punto de publicación y de congelaciónPublicar los objetivos desde planificación con un grano y una periodificación declarados, congelarlos por periodo y revisarlos como nuevas versiones, para que el rendimiento acumulado del año sea reproducible.Patrón propuestoRevOpsObjetivosDatos
- ADR / 013Conceder autoridad al agente por acción y consecuencia, nunca por confianzaClasificar cada acción que un agente podría realizar (leer, recomendar, preparar un borrador, ejecutar, aprobación humana o prohibida) según su consecuencia y reversibilidad. La confianza cambia cómo se presenta el trabajo, no quién puede comprometerlo.Patrón propuestoIAAutoridadGobierno
- ADR / 014Exponer las capacidades del agente como contratos de herramienta acotados, no como API de sistema en brutoCada herramienta declara propósito, entrada, salida, permisos, precondiciones, efecto, fallo y reversibilidad, y los impone en código, para que el prompt no sea la última línea de defensa.Patrón propuestoIAIntegraciónSeguridad
- ADR / 015Nombrar por separado a los responsables de procesos, sistemas, datos y KPI“Responsable” no es un único concepto. Nombrar por separado al responsable del proceso, de cada etapa, de cada decisión, de cada sistema, de cada dato y de cada KPI, para que la excepción siempre tenga nombre.Patrón propuestoModelo operativoResponsabilidadGobierno
- ADR / 016Registrar cada variación local con motivo, responsable, alcance, coste y fecha de revisiónLas diferencias locales son decisiones, no costumbres. Cada una se clasifica (cambio global, configuración, extensión local o rechazo) y se registra con su motivo, responsable, alcance, coste y fecha de revisión.Patrón propuestoModelo operativoVariaciónGobierno
- ADR / 017Medir la adopción por cumplimiento del proceso y uso por la dirección, no por inicios de sesiónLos inicios de sesión miden acceso. La adopción se mide por si el trabajo sigue el proceso previsto, si las decisiones se toman con la evidencia del sistema y si ha desaparecido la forma paralela de trabajar; cada señal, con un responsable y una acción.Patrón propuestoAdopciónMediciónGobierno
- ADR / 018Retirar las herramientas paralelas por clasificación y fecha, no por decretoUna hoja de cálculo junto al CRM suele ser la señal de una capacidad que falta. Inventariar cada herramienta paralela, clasificarla (necesaria temporalmente, sustituida, integrada o retirada), trasladar su valor legítimo y después congelarla y retirarla en una fecha, con un aprobador para las excepciones.Patrón propuestoAdopciónCRMModelo operativo