Modelo Operativo Digital
La tecnología implementa el modelo operativo. No lo define.
Diseño cómo se asume la responsabilidad del trabajo comercial, cómo se gobierna, cómo se mide y cómo lo soportan los sistemas—para que la transformación cambie la forma en que opera la organización, no solo las herramientas que usa.
Nueve capas, del resultado a cómo se mide. Se leen de arriba abajo, como un diseño—o de abajo arriba, tal como un proyecto que empieza por la plataforma las decide por accidente.
- 01Resultado de negocio¿Qué tiene que pasar?
- 02Flujo de valor¿Cómo se produce el valor de principio a fin?
- 03Proceso¿Qué estados y decisiones existen?
- 04Responsabilidad¿Quién es el responsable último?
- 05Sistemas¿Dónde se ejecuta el trabajo?
- 06Datos¿Qué información es la de referencia?
- 07Automatización¿Qué se ejecuta automáticamente?
- 08Gobierno¿Quién puede cambiar el diseño?
- 09Medición¿Cómo sabemos que funciona?
No es “implantar una plataforma nueva”. Es rediseñar cómo opera la organización.
El modelo operativo se sitúa entre la estrategia y la tecnología: quién responde del resultado, quién decide, dónde el trabajo cruza fronteras, cómo lo soportan los sistemas, cómo se gobierna la variación local y cómo se mide el rendimiento.
Una hoja de ruta tecnológicaUn organigramaUn mapa de procesosUn comité de gobiernoUn plan de implantación de CRMUna colección de KPI
- ResultadoLo que la organización debe conseguir, en términos observables.
- Flujo de valorEl flujo de extremo a extremo que lo produce, a través de los departamentos.
- ProcesoLos estados, decisiones y caminos de excepción que necesita el flujo.
- ResponsabilidadUn responsable último por etapa, decisión, sistema, conjunto de datos y KPI.
- DecisionesQuién decide, aprueba, recomienda y es consultado—decisión a decisión.
- SistemasDónde se ejecuta y se registra cada parte del trabajo.
- DatosQué información es la de referencia y quién puede cambiarla.
- AutomatizaciónQué se ejecuta por regla y qué sigue siendo una decisión humana.
- GobiernoCómo se deciden la variación, las excepciones y los cambios.
- MediciónKPI con un responsable de la definición, un responsable de negocio y una acción.
- 01Un sistema no debería tomar una decisión organizativa por accidente.
Si el diseño no lo decide, lo decidirá la configuración.
Capas del modelo operativo - 02La responsabilidad compartida suele significar que nadie responde ante la excepción.
Cada tipo de “responsable” se nombra por separado.
Responsabilidad - 03La variación local necesita un responsable, un motivo y una fecha de revisión.
Si no, cada excepción se convierte en arquitectura permanente.
Global frente a local - 04Un gobierno sin derechos de decisión es solo una reunión.
Quién decide qué, con qué evidencia y en qué plazo.
Gobierno
Del resultado a la medición.
Diez movimientos desde lo que la organización debe conseguir hasta cómo sabe que funciona. La elección de plataformas llega después del sexto; saltarse un paso suele significar que un sistema toma esa decisión en silencio.
01Definir el resultado
¿Qué intentamos conseguir?
Un resultado que alguien pueda observar—no «salir en producción».
- Resultado de negocio
- Resultado para el cliente
- Resultado operativo
- Restricciones innegociables
Los resultados que compiten—rapidez frente a control—deben priorizarse de forma explícita
Definir el resultado
¿Qué intentamos conseguir?
Un resultado que alguien pueda observar—no «salir en producción».
- Resultado de negocio
- Resultado para el cliente
- Resultado operativo
- Restricciones innegociables
Declaración de resultados y restriccionesLos resultados que compiten—rapidez frente a control—deben priorizarse de forma explícita
Identificar la cadena de valor
¿Qué flujo de principio a fin produce ese resultado?
El valor atraviesa funciones; las organizaciones se dibujan por funciones.
- Evento de inicio
- Evento de fin
- Resultado para cliente y negocio
- Etapas principales
- Fronteras organizativas
Mapa de la cadena de valorEl tiempo de espera entre departamentos no es de nadie hasta que alguien le pone nombre
Diseñar el proceso
¿Qué estados y decisiones hacen funcionar la cadena de valor?
Estados con criterios de salida, no listas de tareas por departamento.
- Etapas
- Transiciones
- Puntos de decisión
- Caminos de excepción
Arquitectura de procesosCada rechazo necesita un estado de destino definido
Asignar responsables
¿Quién responde de cada etapa y de cada resultado?
«Responsable» no es un único concepto.
- Responsable último
- Rol ejecutor
- Escalado
- Traspaso
Modelo de responsabilidadesLa responsabilidad compartida suele significar que nadie responde de la excepción
Definir derechos de decisión
¿Quién puede decidir qué?
Decide exactamente un rol; aprobar es un derecho distinto.
- Decidir
- Aprobar
- Recomendar
- Consultar
- Informar
Matriz de derechos de decisiónUn gobierno sin derechos de decisión es solo una reunión
Mapear sistemas
¿Qué plataformas soportan cada parte?
Los sistemas implementan decisiones; no deberían tomarlas.
- Sistema de acción
- Sistema de registro
- Responsable de cada capacidad
- Fronteras de sistema
Mapa proceso–sistemaUn sistema no debería tomar una decisión organizativa por accidente
Mapear la propiedad del dato
¿Quién es responsable de la información necesaria para operar y decidir?
Autoridad por concepto—a veces por atributo.
- Origen
- Autoridad
- Custodia
- Datos derivados
- Linaje
Modelo de propiedad del datoLa calidad del dato es responsabilidad de quien puede corregirla en origen
Definir la frontera de automatización
¿Qué debe ejecutarse de forma automática y qué debe seguir siendo humano?
Automatizar las reglas; mantener visible el criterio.
- Automático por regla
- Asistido—una persona confirma
- Decisión humana, con el motivo registrado
Frontera de automatizaciónAutomatizar una decisión sin definir esconde el hueco de la política
Diseñar el gobierno
¿Cómo se controlan las excepciones, la variación local y los cambios?
Quién decide qué, con qué evidencia y en qué plazo.
- Responsable de la variación
- Responsable de las excepciones
- Autoridad de cambio
- Ritmo de revisión
Modelo de gobiernoLa variación local necesita un responsable, un motivo y una fecha de revisión
Definir la medición
¿Cómo sabemos que el modelo operativo funciona?
La medición forma parte del modelo operativo.
- KPIs de proceso
- KPIs de resultado
- Responsable
- Ritmo
- Acción
Modelo de responsabilidad de KPIsUn KPI sin responsable ni acción es ruido en los informes
Los síntomas llegan como “el sistema no encaja con cómo trabajamos”.
Normalmente el sistema encaja con una decisión que nadie tomó. Debajo hay un responsable, un derecho de decisión o una regla de variación que nunca se diseñó.
El proceso global existe sobre el papel; los equipos locales operan de otra manera.
Lo que suele faltarUn núcleo global con variación declarada y gobernadaLa responsabilidad desaparece donde el trabajo pasa de un departamento al siguiente.
Lo que suele faltarUn responsable del flujo de valor y contratos de traspasoUna elección tecnológica zanja en silencio una decisión de negocio que nadie tomó.
Lo que suele faltarDerechos de decisión definidos antes de configurarVarios equipos creen ser responsables del mismo estado del cliente.
Lo que suele faltarResponsables distintos para proceso, sistema, dato y KPILas excepciones locales se convierten en arquitectura permanente.
Lo que suele faltarUn registro de variaciones con responsables y fechas de revisiónLos foros de gobierno debaten problemas pero no pueden decidir.
Lo que suele faltarDerechos de decisión, evidencia y un plazo por dominioLos KPI existen, pero nadie es responsable de su definición ni de la acción.
Lo que suele faltarUna cadena de responsabilidad sobre cada KPIEl proyecto de transformación acaba en el go-live; el modelo operativo no vuelve a cambiar.
Lo que suele faltarControl de cambios y una cadencia de revisión del modelo operativo
Entregables para que una organización opere lo que construye.
Cada uno responde a una pregunta que un plan de despliegue de plataforma nunca se hace.
- Modelo de resultados y restricciones¿Qué hay que conseguir—y qué no se puede sacrificar?
- Mapa del flujo de valor¿Qué flujo de extremo a extremo crea el resultado?
- Blueprint del modelo operativoLas nueve capas, diseñadas juntas
- Hoja de ruta del modelo operativo¿Qué capa cambia cuándo—y en qué orden?
- Modelo de responsables de proceso¿Quién responde de cada etapa y del resultado de extremo a extremo?
- Matriz de derechos de decisión¿Quién decide, aprueba, recomienda y es consultado?
- Modelo de traspasos organizativosQué significa “terminado” antes de que el trabajo cambie de manos
- Mapa proceso-sistemaDónde se ejecuta y se registra cada etapa
- Mapa proceso-datoQué datos necesita cada decisión y quién es su propietario
- Registro de variaciones global / localMotivo, responsable, alcance, coste y fecha de revisión de cada variación
- Gobierno de excepcionesResponsable, circuito, plazo y aprendizaje por tipo de excepción
- Cadencia de gestión¿Qué foro decide qué, y a partir de qué evidencia?
- Modelo de responsabilidad sobre los KPIResponsable de la definición, responsable de negocio, cálculo, acción
- Modelo de control de cambios¿Quién puede cambiar una etapa, una regla, un KPI o una frontera?
- Modelo de gobiernoDominios, responsables de decisión, evidencia y plazos
Un sistema no debería tomar una decisión organizativa por accidente.
Nueve capas, cada una con una pregunta, un fallo típico y un entregable. Selecciona una capa.
Responsabilidad
- Pregunta clave
- ¿Quién es responsable de cada etapa, decisión, sistema, conjunto de datos y KPI?
- Fallo típico
- “Es responsabilidad del negocio”—hasta que una excepción necesita un nombre.
- Entregable
- Modelo de responsabilidades y derechos de decisión
Las organizaciones se estructuran por funciones. El valor las atraviesa.
Las mismas cinco funciones y seis etapas, leídas de dos maneras. En la vista de flujo de valor, selecciona un hueco para ver qué se pierde entre departamentos.
El valor atraviesa los departamentos. Los huecos donde el trabajo cambia de manos son donde fallan los modelos operativos.
| Función | Lead | Oportunidad | Cliente | Pedido | Factura | Rendimiento |
|---|---|---|---|---|---|---|
| Marketing | Lidera | Apoya | Apoya | |||
| Ventas | Apoya | Lidera | Apoya | Lidera | Apoya | |
| Finanzas | Apoya | Lidera | Apoya | Lidera | Apoya | |
| IT / Plataforma | Apoya | Apoya | Apoya | Apoya | Apoya | Apoya |
| Datos | Apoya | Apoya | Lidera |
Un acuerdo ganado espera a que se cree el cliente; ventas lo cuenta como ganado, finanzas aún no lo ha visto.
Un estado compartido con un responsable de la transición, no dos responsables de dos pasos
La responsabilidad compartida suele significar que nadie responde ante la excepción.
“Responsable” no es un concepto único. Para un mismo trabajo, los responsables del proceso, la etapa, la decisión, el sistema, el dato y el KPI suelen estar en funciones distintas—y cada uno necesita un nombre.
- Operaciones comerciales
Responde de El flujo completo desde el acuerdo ganado hasta el cliente activo
No La decisión de crédito
- Ventas internas
Responde de Una solicitud de alta completa y correcta
No El registro legal
- Finanzas
Responde de La validación de crédito y legal
No La relación comercial
- Sistemas comerciales (CRM) · Sistemas financieros (ERP)
Responde de La configuración y las versiones de cada plataforma
No Las reglas de negocio que ejecutan
- Datos maestros
Responde de Razón social, identificador fiscal e identidad de facturación
No Los atributos comerciales
- Operaciones
Responde de El tiempo de alta y la tasa de rechazo—y actuar sobre ellos
No La definición de cliente
Decide exactamente un rol. Los demás tienen un derecho con nombre.
Siete decisiones y siete roles. Selecciona una decisión para ver quién decide, aprueba, recomienda, es consultado e informado—con qué evidencia y en qué plazo.
| Decisión | Comercial | Finanzas | Operaciones | IT / Plataforma | Datos | Filial local | Gobierno global |
|---|---|---|---|---|---|---|---|
| Recomienda | Decide | Consultado | Consultado | Informado | |||
| Recomienda | Decide | Informado | |||||
| Recomienda | Consultado | Consultado | Consultado | Consultado | Decide | ||
| Recomienda | Consultado | Decide | Aprueba | ||||
| Informado | Consultado | Consultado | Recomienda | Decide | |||
| Consultado | Aprueba | Decide | Consultado | ||||
| Recomienda | Aprueba | Informado | Informado | Decide |
Aprobar una variación local
- Decide
- Gobierno global
- Recomienda
- Filial local
- Consultado
- Operaciones, IT / Plataforma
- Informado
- Finanzas
- Evidencia necesaria
- Motivo, responsable, alcance, coste, fecha de revisión
- Plazo para decidir
- 4 semanas
La variación local necesita un responsable, un motivo y una fecha de revisión.
Un núcleo global que no varía, variación en puntos declarados y extensiones locales solo para restricciones legales u operativas reales—cada una registrada con su motivo, responsable, alcance, coste y fecha de revisión.
- Núcleo globalIgual en todas partes. No se negocia localmente.
- Ciclo de vida y significado de las etapas compartidos
- Definiciones comunes de cliente, pedido y ganado
- KPI estándar y sus cálculos
- Gobierno y controles obligatorios
- Variación configurableValores distintos en puntos declarados.
- Umbrales de aprobación por entidad legal
- Reglas de asignación y territorios
- Quién ocupa cada rol
- Pasos de validación locales
- Extensión localSolo ante una restricción legal u operativa real.
- Un campo legal específico de un país
- Una comprobación documental adicional
- Un tipo de pedido del ERP local detrás de la integración
MotivoResponsableAlcanceCosteFecha de revisión
| Variación | Nivel | Motivo | Responsable | Alcance | Coste | Revisión |
|---|---|---|---|---|---|---|
| Umbral de descuento más alto | Configurable | Nivel de precios del mercado | Director comercial de la filial | Una entidad legal | Solo configuración | Anual |
| Paso de validación del identificador fiscal | Extensión local | Requisito legal | Finanzas local | Un país | Una extensión, probada en cada versión | Cuando cambie la ley |
| Nombres de etapa propios | Rechazada | Preferencia | — | — | Rompe la comparabilidad | — |
“¿Podemos hacerlo distinto aquí?”
Cinco comprobaciones deciden entre un cambio global, una variación configurable, una extensión local—o un rechazo documentado.
- ¿Requisito legal?No
- ¿Requisito del cliente o del mercado?Sí
- ¿Restricción del ERP o del sistema?No
- ¿Diferencia de modelo operativo?No
- ¿Preferencia?No
Una diferencia de mercado real en un punto que el núcleo ya declara. Se fija el valor y se registra con un responsable y una fecha de revisión.
Un gobierno sin derechos de decisión es solo una reunión.
El gobierno responde a quién decide qué, con qué evidencia y en qué plazo—por dominio. Las excepciones se encaminan igual.
- 01Incidencia / petición
- 02Clasificar
- 03Responsable
- 04Decisión
- 05Implementar
- 06Revisar
Proceso
- Responsable de la decisión
- Responsable global del proceso
- Evidencia
- Antigüedad por etapa, volumen de excepciones, feedback local
- Plazo
- Revisión trimestral; correcciones urgentes en 2 semanas
- Por ejemplo
- Añadir un criterio de salida a Cualificada
Sistema
- Responsable de la decisión
- Responsable de la plataforma
- Evidencia
- Impacto de la versión, resultados de pruebas, variaciones afectadas
- Plazo
- En cada versión
- Por ejemplo
- Retirar una copia local de una automatización
Datos
- Responsable de la decisión
- Propietario del dato por dominio
- Evidencia
- Métricas de calidad, consumidores afectados
- Plazo
- Foro mensual de datos
- Por ejemplo
- Cambiar la definición de cliente activo
KPI
- Responsable de la decisión
- Responsable de la definición (con el responsable de negocio)
- Evidencia
- Contrato de la métrica, impacto histórico
- Plazo
- Foro mensual; efectivo el siguiente periodo
- Por ejemplo
- Cambiar el horizonte de cobertura
Variación
- Responsable de la decisión
- Gobierno global
- Evidencia
- Motivo, responsable, alcance, coste, fecha de revisión
- Plazo
- 4 semanas
- Por ejemplo
- Aprobar el umbral de una filial
Excepción
- Responsable de la decisión
- Responsable según el tipo de excepción
- Evidencia
- Registro del caso e historial
- Plazo
- Según el tipo—de horas a días
- Por ejemplo
- Una excepción puntual a la política
Gobierno de excepciones
Cinco tipos de excepción, cinco responsables. Una excepción debe resolverse o enseñarle algo al modelo operativo.
| Excepción | Responsable | Circuito | Plazo | Resolución | Aprendizaje |
|---|---|---|---|---|---|
| Excepción de procesoUn pedido que se saltó un paso obligatorio | Responsable del proceso | Caso al responsable de la etapa | 2 días laborables | Completar el paso o registrar por qué no | Causas recurrentes → cambio de proceso |
| Fallo de sistemaUn mensaje de integración que nunca llegó | Responsable de la plataforma | Incidencia con el impacto de negocio anotado | Según severidad | Recuperar y conciliar | Causa raíz → cambio de contrato o de monitorización |
| Problema de calidad de datosDos cuentas para una misma entidad legal | Propietario del dato | Cola de data stewardship | 5 días laborables | Fusionar o corregir en origen | Causas en origen → cambio en la regla de entrada |
| Excepción de políticaUna condición de pago fuera de política | Responsable de la decisión (finanzas) | Aprobación con motivo | 1 día laborable | Aprobar una vez, con caducidad—o rechazar | Excepciones frecuentes → revisión de la política |
| Petición de variación localUna filial quiere un paso distinto | Gobierno global | Registro de variaciones | 4 semanas | Cambio global, configuración, extensión o rechazo | Peticiones repetidas → cambio en el núcleo |
Un KPI sin responsable ni acción es ruido de reporting.
Cinco ritmos hacen funcionar y evolucionar el modelo operativo—de la ejecución semanal al objetivo anual. Cada KPI que usan tiene un responsable de la definición, un responsable de negocio, un lugar donde se calcula y una acción.
Revisión de la ejecución
- Participantes
- Mandos de equipo
- Evidencia
- Pipeline, acciones vencidas, excepciones abiertas
- Decisiones
- Desbloquear trabajo; escalar excepciones fuera de plazo
- Resultados
- Acciones por elemento
Rendimiento y recuperación
- Participantes
- Mandos, operaciones, finanzas
- Evidencia
- Segmentos, planes de recuperación, tendencias de KPI
- Decisiones
- Aceptar, escalar o cerrar la recuperación; acciones sobre KPI
- Resultados
- Resultados de los planes, escalados
Revisión del modelo operativo
- Participantes
- Responsables de proceso, sistema y dato; gobierno global
- Evidencia
- Registro de variaciones, patrones de excepciones, antigüedad por etapa
- Decisiones
- Cambiar el núcleo, renovar o retirar variaciones
- Resultados
- Cambios aprobados, registro actualizado
Cambio de arquitectura y de proceso
- Participantes
- Responsable de la plataforma, responsable del proceso, filiales afectadas
- Evidencia
- Peticiones de cambio, impacto, resultados de pruebas
- Decisiones
- Qué sale y qué espera
- Resultados
- Alcance de la versión, comunicación
Objetivos y modelo estratégico
- Participantes
- Dirección, finanzas, gobierno global
- Evidencia
- KPI de resultado, cambios de mercado, hoja de ruta
- Decisiones
- Objetivos, prioridades, hoja de ruta del modelo operativo
- Resultados
- Versión de objetivos, hoja de ruta
Cadena de responsabilidad de un KPI
- Cobertura de pipeline
- RevOps
- Dirección de ventas
- Plataforma de datos
- Revisión semanal del pipeline
- Generación de pipeline por debajo del múltiplo acordado
Cinco organizaciones, una pregunta: ¿quién decide?
Escenarios B2B globales sintéticos. El caso de estandarización se lee aquí desde el modelo operativo; cuatro casos nuevos cubren el modelo global, el CRM como plataforma operativa, la responsabilidad sobre el cliente y el cambio tras el go-live.
- Caso 01Caso seleccionadoNúcleo global, variación gobernada, ciclo de vida con responsable
Diseñar un modelo operativo comercial global para varias filiales
Cada filial lleva el negocio comercial a su manera; está a punto de desplegarse una plataforma global encima de esas diferencias.
¿Qué decisiones son globales y cuáles locales—y quién es responsable del ciclo de vida completo cuando cruza filiales?
CRM globalERP localesPlataforma de datosRegistro de variacionesArquitectura de ProcesosArquitectura de Sistemas y CRM - Caso 02Caso de Procesos · lectura de modelo operativoAutoridad de decisión sobre la variación
Estandarizar un proceso comercial global sin romper la operación local
Se impone un proceso global; las filiales lo cumplen sobre el papel y lo esquivan en la práctica.
¿Quién tiene autoridad para permitir—o rechazar—una diferencia local, y cómo se gobierna esa decisión en el tiempo?
Plantilla global de CRMERP localesRegistro de variacionesArquitectura de ProcesosCambio y Adopción - Caso 03Rutinas, responsables y retirada
De herramienta CRM a plataforma operativa comercial
El CRM está implantado, pero los mandos llevan el negocio desde hojas de cálculo y cada equipo interpreta las etapas a su manera.
¿Qué rutinas de gestión, decisiones y responsabilidades tienen que pasar al CRM para que la empresa opere de verdad a través de él?
CRMHojas de cálculo (en retirada)Plataforma de datosHerramientas de colaboraciónCambio y AdopciónRevenue Operations - Caso 04Responsabilidad sobre la relación, la transacción y el dato
Diseñar la responsabilidad sobre el cliente en una organización con varias filiales
Un grupo cliente compra a varias filiales; tres equipos lo llaman “mi cuenta” y nadie puede resolver los desacuerdos.
¿Quién es responsable de la relación, de cada transacción y de los datos globales de la cuenta—y quién resuelve los conflictos de responsabilidad?
CRM globalERP localesDatos maestrosPlataforma de datosArquitectura de Sistemas y CRMDatos e Integraciones - Caso 05Autoridad sobre el cambio y evolución versionada
Gobernar los cambios del modelo operativo después del go-live
Dos años después del go-live, los cambios llegan como tickets al equipo de plataforma; nadie decide si cambian el modelo operativo—así que la configuración se va desviando.
¿Quién puede cambiar cada parte del modelo operativo, con qué evidencia, y cómo se publica cada cambio?
CRMBacklog de cambiosPlataforma de datosRegistro de variacionesCambio y AdopciónArquitectura de Sistemas y CRM
Toda petición de transformación tiene una segunda capa.
La petición visible es donde empieza el diseño, no donde termina.
“Necesitamos un CRM nuevo para todas las filiales.”
Elegir una plataforma y desplegarla país a país.
4 de 6 preguntas a la vista
Si la respuesta es “usamos el CRM nuevo”, el resultado sigue sin definirse.
El modelo operativo decide. Procesos, sistemas y datos lo implementan.
Modelo Operativo Digital
- Arquitectura de Procesos
El modelo operativo decide quién es responsable del flujo de valor; la arquitectura de procesos diseña sus estados, decisiones y excepciones.
- Arquitectura de Sistemas y CRM
El modelo operativo asigna responsabilidades a los sistemas—no al revés.
- Datos e Integraciones
La propiedad y la autoridad del dato siguen al modelo de responsabilidades, concepto a concepto.
- Revenue Operations
La cadencia comercial y la responsabilidad sobre los KPI hacen funcionar el modelo operativo semana a semana.
- Cambio y Adopción
Las personas operan con el nuevo modelo solo cuando los roles, las rutinas y los incentivos cambian con él.
- Automatización
La frontera de automatización es una decisión del modelo operativo: qué reglas se ejecutan solas y cuáles siguen siendo humanas.
Decisiones de arquitectura
Casos y artículos
Un modelo operativo digital no es una plataforma, un organigrama ni un comité. Es el diseño coherente de
- Resultado
- Flujo de valor
- Proceso
- Responsabilidad
- Decisiones
- Sistemas
- Datos
- Automatización
- Gobierno
- Medición
Diseñar cómo opera la organización antes de decidir cómo debe comportarse la plataforma.
La tecnología implementa el modelo operativo. No lo define.
Una plataforma nueva—y nadie ha decidido quién es responsable de qué.
- ¿Quién es responsable de tu ciclo de vida de cliente de principio a fin?
- ¿Qué diferencias locales son legales—y cuáles son costumbre?
- ¿Qué foro puede decidir de verdad?