Cómo diseñar el operating model
El proceso de construcción: desde el diagnóstico de lo que no funciona hasta el diseño de un modelo adaptado al contexto del negocio.
- El proceso de diseño en 4 fases
- Fase 1: Diagnóstico — qué no funciona hoy
- Fase 2: Contexto — qué necesita el negocio
- Fase 3: Diseño — estructura, procesos, decisiones, capacidades
- Fase 4: Validación — test antes de implementar
- Criterios de un buen diseño
- Errores frecuentes en el diseño
- Preguntas frecuentes
- Referencias y bibliografía
El proceso de diseño en 4 fases.
Diseñar un operating model no es un ejercicio de planificación abstracta — es una respuesta a problemas reales de ejecución que se manifiestan en la operación cotidiana del equipo. El proceso tiene cuatro fases que deben ejecutarse en orden: diagnóstico de lo que no funciona, comprensión del contexto del negocio, diseño de los cuatro componentes, y validación antes de implementar.
Cada fase produce un entregable específico. El diagnóstico produce una lista de fricción observable. El contexto produce restricciones y objetivos. El diseño produce el borrador del modelo. La validación produce ajustes antes de la implementación. Sin alguna de estas fases, el modelo resulta o bien desconectado de la realidad (si se salta el diagnóstico), o bien genérico (si se salta el contexto), o bien incompleto (si se salta el diseño), o bien frágil (si se salta la validación).
Diagnóstico
Identificar qué no funciona hoy. ¿Dónde se traba la ejecución? ¿Qué componente del operating model actual produce fricción recurrente? El diagnóstico debe ser específico: "las decisiones tácticas tardan semanas" es útil, "el equipo no funciona" no lo es.
Contexto
Entender qué necesita el negocio. ¿Qué tipo de ejecución requiere la estrategia? ¿Velocidad o consistencia? ¿Autonomía o coordinación? ¿Profundidad técnica o generalismo? El contexto define las restricciones de diseño.
Diseño
Diseñar los cuatro componentes de manera coherente: estructura, procesos, decisiones, capacidades. Cada componente debe responder al diagnóstico y encajar con el contexto. El resultado es el borrador del modelo operativo.
Validación
Testear el diseño con el equipo antes de implementar. ¿Las personas entienden cómo va a funcionar? ¿Identifican problemas que el diseño original pasó por alto? La validación reduce el riesgo de un cambio disruptivo que falla en la ejecución.
Diagnóstico: qué no funciona hoy.
El diagnóstico identifica los síntomas de fricción — los puntos donde el equipo se traba de manera recurrente. No se trata de opiniones sobre cómo debería funcionar el equipo, sino de observaciones de dónde falla el modelo actual. El diagnóstico debe ser específico y observable.
Las preguntas correctas de diagnóstico varían según el componente que se está evaluando:
- ¿Hay áreas donde no está claro quién es responsable?
- ¿Se duplica trabajo porque múltiples personas asumen la misma responsabilidad?
- ¿Hay cuellos de botella recurrentes en personas específicas?
- ¿El equipo puede ejecutar iniciativas cross-funcionales sin fricción?
- ¿Los rituales de planificación y revisión se cumplen consistentemente?
- ¿Las iniciativas tienen fechas de inicio y fin claras?
- ¿El equipo puede coordinar trabajo entre áreas sin reuniones ad-hoc?
- ¿Los procesos actuales producen documentación útil o burocracia?
- ¿Cuánto tiempo toma cerrar decisiones operativas? ¿Y tácticas?
- ¿Las decisiones pequeñas escalan innecesariamente al líder?
- ¿Las personas saben qué pueden decidir sin pedir permiso?
- ¿Se toman decisiones grandes sin el input correcto?
- ¿Hay habilidades críticas que faltan en el equipo?
- ¿Las herramientas actuales eliminan trabajo manual o lo producen?
- ¿El equipo tiene acceso a la información que necesita para decidir?
- ¿Hay procesos de mejora continua o se repiten los mismos errores?
El resultado del diagnóstico debe ser una lista concreta de fricción observable, priorizada por impacto. "Las decisiones tácticas requieren aprobación del líder y tardan 3-5 días" es un problema diagnosticado. "El equipo no tiene claridad" no lo es.
03 — Fase 2Contexto: qué necesita el negocio.
El contexto define las restricciones de diseño. No hay un operating model universalmente óptimo — hay un modelo que encaja con el tipo de ejecución que la estrategia requiere. Una estrategia que compite en velocidad de innovación necesita un modelo diferente al de una estrategia que compite en consistencia de marca a gran escala.
Las preguntas de contexto más relevantes son:
¿Qué tipo de ejecución necesita la estrategia?
Si la estrategia requiere velocidad de experimentación (lanzar, testear, aprender rápido), el modelo debe minimizar dependencias y descentralizar decisiones. Si requiere consistencia de marca a través de múltiples touchpoints, el modelo necesita funciones centralizadas que mantengan coherencia. Estos dos objetivos producen modelos operativos distintos.
¿Qué tan complejo es el portafolio de productos?
Un solo producto con un GTM simple permite estructura funcional. Múltiples productos con GTMs diferenciados requieren equipos por producto o híbrido. La complejidad del portafolio determina cuánta autonomía por producto se necesita.
¿Cuál es el tamaño actual y proyectado del equipo?
Un equipo de 8 personas puede coordinarse informalmente. Un equipo de 25 necesita procesos explícitos. Un equipo de 40+ probablemente necesita estructura híbrida. El tamaño no solo afecta la estructura — afecta también qué procesos son viables y qué decisiones pueden descentralizarse.
¿Qué capacidades son críticas para la ventaja competitiva?
Si el negocio compite en SEO técnico, necesitás un especialista full-time — no podés tercerizar. Si compite en creatividad de contenido, necesitás un content team robusto. Las capacidades críticas deben internalizarse; las no críticas pueden terciarizarse o compartirse.
04 — Fase 3Diseño: estructura, procesos, decisiones, capacidades.
El diseño toma como input el diagnóstico (qué no funciona) y el contexto (qué necesita el negocio) y produce un borrador de los cuatro componentes del operating model. Cada componente debe diseñarse de manera coherente con los otros.
Diseñar la estructura
Elegir entre funcional, por producto o híbrido según el contexto. Definir qué áreas existen, quién reporta a quién, y cómo colaboran áreas que no tienen línea de reporte directo. Documentar la lógica de la estructura: por qué se eligió este modelo y no otro.
Diseñar los procesos
Definir la cadencia de planificación (trimestral, mensual, semanal), los rituales de revisión (qué se revisa, cuándo, con quién), y los puntos de sincronización cross-funcional. Los procesos deben ser el mínimo necesario para mantener alineación — no el máximo posible de control.
Diseñar el sistema de decisiones
Clasificar decisiones en tres niveles (tácticas, operativas, estratégicas) y asignar autoridad a cada nivel. Definir qué información se necesita para cada tipo de decisión y cuánto tiempo debería tomar cerrarlas. El sistema debe estar documentado para que todos sepan quién decide qué.
Diseñar las capacidades
Identificar qué habilidades faltan, qué herramientas se necesitan, qué sistemas de información requieren las personas para tomar decisiones y qué procesos de mejora continua se van a implementar. Las capacidades deben permitir que los procesos funcionen — no al revés.
El diseño del operating model no es un ejercicio creativo — es un acto de ingeniería inversa. Primero diagnosticás qué se traba. Después entendés qué necesita el negocio. Recién entonces diseñás un modelo que resuelva la fricción sin crear complejidad innecesaria. El mejor modelo no es el más sofisticado — es el más simple que produce el tipo de ejecución que la estrategia requiere.
Lisandro IserteValidación: test antes de implementar.
La validación reduce el riesgo de un cambio disruptivo que falla en la ejecución. El líder puede diseñar el borrador del modelo, pero las personas que van a operar con ese modelo necesitan tener input en su diseño y oportunidad de señalar problemas antes de la implementación.
La validación tiene tres pasos:
1. Presentar el diseño al equipo
Explicar la lógica: qué problemas se diagnosticaron, qué restricciones de contexto se identificaron, qué modelo se diseñó y por qué. La presentación no es un anuncio — es una invitación a desafiar supuestos y señalar problemas.
2. Recoger feedback estructurado
Preguntar: ¿Qué no está claro? ¿Qué problemas ven que este diseño no resuelve? ¿Qué fricción nueva podría producir? El feedback debe ser específico: "no entiendo quién decide X" es útil, "no me gusta" no lo es.
3. Iterar el diseño
Ajustar el modelo según el feedback. No todas las objeciones ameritan cambios — algunas señalan trade-offs inevitables. Pero si múltiples personas señalan el mismo problema, probablemente hay un defecto de diseño que debe corregirse antes de implementar.
La validación no es buscar consenso — es identificar problemas antes de que se conviertan en fricción operativa. Un modelo validado no es perfecto, pero tiene menos probabilidades de fallar en la implementación.
06 — Criterios de calidadCriterios de un buen diseño.
Un buen diseño de operating model cumple con estos cuatro criterios:
Resuelve fricción real
Si el diagnóstico identificó que las decisiones se traban, el nuevo modelo debe reducir ese tiempo de decisión. Si no resuelve la fricción diagnosticada, el rediseño es movimiento sin mejora.
Encaja con el contexto
El modelo debe producir el tipo de ejecución que la estrategia requiere. Un modelo que optimiza para velocidad cuando la estrategia requiere consistencia (o viceversa) falla por desalineación con el contexto.
Los componentes son coherentes
La estructura, los procesos, las decisiones y las capacidades deben estar alineados. Si la estructura descentraliza pero las decisiones se mantienen centralizadas, hay incoherencia que producirá fricción.
Es ejecutable por el equipo actual
El modelo debe poder implementarse con las personas y capacidades actuales (o con un plan claro de cómo se van a adquirir). Un diseño que requiere 10 contrataciones inmediatas no es ejecutable.
Errores frecuentes en el diseño.
Diseñar sin diagnosticar primero
Saltar directo al diseño sin entender qué componente del modelo actual está fallando. El resultado es un modelo que soluciona problemas que no existen y no soluciona los que sí. El diagnóstico es el fundamento — sin él, el diseño es arbitrario.
Copiar modelos de otras empresas
Adoptar el modelo de una empresa admirada sin adaptar al contexto propio. Un modelo que funciona para un equipo de 100 personas con 5 productos no funciona para un equipo de 15 con 1 producto. El contexto determina el diseño — no las referencias externas.
Optimizar un componente a expensas de los otros
Diseñar una estructura perfecta sin pensar en cómo se tomarán decisiones o qué procesos se necesitan. El operating model es un sistema — optimizar una parte puede degradar el todo. La coherencia entre componentes importa más que la perfección de cada uno.
No validar con el equipo antes de implementar
Anunciar el nuevo modelo sin dar oportunidad al equipo de señalar problemas. Las personas que operan con el modelo ven problemas que el diseñador pasa por alto. Sin validación, esos problemas se descubren en la ejecución — cuando son más costosos de corregir.
Preguntas frecuentes.
¿Cuánto tiempo lleva diseñar un operating model?
Depende de la complejidad del equipo. Para un equipo de 10-15 personas, el proceso completo (diagnóstico + diseño + validación) puede tomar 2-3 semanas de trabajo dedicado. Para un equipo de 30+ personas con múltiples productos, puede extenderse a 4-6 semanas. No es un ejercicio de un día — requiere conversaciones, iteración y validación con el equipo.
¿Necesito involucrar al equipo en el proceso de diseño?
Sí — especialmente en el diagnóstico y la validación. El líder puede diseñar el primer borrador del modelo, pero las personas que van a operar con ese modelo necesitan tener input en su diseño y oportunidad de señalar problemas antes de la implementación. Un modelo diseñado top-down sin validación del equipo generalmente falla en la ejecución.
¿Qué hago si el diagnóstico muestra problemas en múltiples componentes?
Priorizá el componente que más traba la ejecución. Si las decisiones se traban constantemente, empezá por el sistema de decisiones. Si los procesos son caóticos, empezá por ahí. Intentar arreglar todos los componentes simultáneamente produce cambio disruptivo. Es mejor iterar por componente: diseñá, implementá, estabilizá, siguiente.
Referencias y bibliografía.
Galbraith, J. R. (2014). Designing Organizations: Strategy, Structure, and Process at the Business Unit and Enterprise Levels. Jossey-Bass.
Martin, R. L., & Lafley, A. G. (2013). Playing to Win: How Strategy Really Works. Harvard Business Review Press.
Lencioni, P. (2002). The Five Dysfunctions of a Team. Jossey-Bass.
Kim, W. C., & Mauborgne, R. (2015). Blue Ocean Strategy, Expanded Edition. Harvard Business Review Press.
Rumelt, R. (2011). Good Strategy/Bad Strategy: The Difference and Why It Matters. Crown Business.
Términos del glosario