ADR / 015

Nombrar 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 de referencia

Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.

01Contexto

Una transformación comercial asignó a “el negocio” la responsabilidad del ciclo de vida del cliente y a “IT” la del CRM. Cuando un cliente se creó dos veces, ventas, finanzas, los administradores del CRM y datos maestros se señalaron unos a otros. Cada uno era responsable de algo; nadie lo era de la excepción.

02Factores de decisión

  1. F01

    Las excepciones necesitan un responsable con nombre

  2. F02

    Los administradores de sistemas no deben tomar decisiones de negocio

  3. F03

    La calidad del dato debe corregirse en origen

  4. F04

    Los KPI necesitan a alguien que actúe, no solo a alguien que los calcule

03Opciones consideradas

Descartada

Un único “responsable de negocio” por proceso

Procesos pequeños de una sola función

Coste: Oculta la responsabilidad sobre decisiones, datos y sistemas; las excepciones rebotan
Descartada

Una matriz RACI completa por actividad

Auditorías

Coste: Ilegible; rara vez sirve para resolver nada
Elegida

Tipos de responsable con nombre por proceso, decisión, sistema, concepto de datos y KPI

Procesos transversales sobre plataformas compartidas

Coste: Un modelo de responsabilidades que mantener

04Decisión

Para cada flujo de valor, nombrar a un responsable del proceso, responsable último del resultado de extremo a extremo; a un responsable por etapa; a un responsable por decisión (con aprobadores separados cuando haga falta); a un responsable por plataforma, a cargo de la configuración y las releases pero no de las reglas de negocio; a un responsable por concepto de datos, a cargo de la calidad en origen; y a un responsable de KPI que actúe sobre cada medida, distinto del responsable de la definición cuando no coincidan. Registrarlos en un único modelo de responsabilidades y enrutar las excepciones por tipo al responsable con nombre.

05Consecuencias

  • Las excepciones llegan a una persona con nombre al primer intento.
  • Los responsables de sistemas dejan de decidir cuestiones de negocio al implementarlas.
  • La calidad del dato tiene un responsable que puede corregirla.
  • El modelo de responsabilidades se convierte en un artefacto que cambia con la organización.

06Cuándo revisarla

01

El proceso vive por completo dentro de una función y un sistema.

02

La organización adopta un modelo de equipos de producto que, por diseño, une varios tipos de responsabilidad.

07Dónde se aplica esta decisión

Casos que adoptan esta decisión, y por qué importa en cada uno.

  1. Caso de modelo operativo / 03De herramienta CRM a plataforma operativa comercialUn CRM que existe pero no hace funcionar el negocio: rutinas de gestión trasladadas a él, herramientas paralelas retiradas, calidad del dato con responsable, definiciones del ciclo de vida gobernadas—y un plan para después del go-live.Modelo Operativo DigitalCambio y AdopciónRevenue OperationsEscenario ficticio · 8 min
  2. Caso de modelo operativo / 04Diseñar la responsabilidad sobre el cliente en una organización con varias filialesUna relación con un cliente que abarca varias entidades legales, filiales y equipos de ventas: quién es responsable de la relación, de cada transacción local y de los datos globales de la cuenta—y quién resuelve los conflictos.Modelo Operativo DigitalArquitectura de Sistemas y CRMDatos e IntegracionesEscenario ficticio · 8 min
  3. Caso de adopción / 05De los campos obligatorios a datos que la gente usaUn CRM lleno de datos completos pero sin sentido: cada campo auditado según quién lo registra, quién lo usa y qué decisión alimenta; después se elimina, se deriva, se prerrellena, se hace condicional o se mantiene, devolviendo valor a quien lo introduce.Cambio y AdopciónArquitectura de ProcesosDatos e IntegracionesEscenario ficticio · 8 min
  4. Caso de adopción / 06Mantener la adopción con responsable cuando el equipo de proyecto se vaUn despliegue que terminó en el go-live: responsabilidades traspasadas de los roles de proyecto a responsables operativos con nombre, un registro de fricción que alimenta un único backlog gobernado, una cadencia de releases y señales de adopción revisadas con calendario, para que el diseño siga mejorando.Cambio y AdopciónModelo Operativo DigitalAutomatizaciónEscenario ficticio · 8 min