Definir el resultado. Entender la realidad. Diseñar el sistema.
Trabajo hacia atrás desde el resultado que una empresa necesita conseguir: primero entiendo las personas, los procesos, los sistemas, los datos y las restricciones que ya existen, y después diseño lo que tiene que cambiar.
Output-Driven.Pensamiento de segunda capa.
Trabajo habitual: programas CRM multipaís · ciclos de vida de cliente entre CRM y ERP · IA en flujos comerciales reales.
01 · Output-Driven
Empiezo por lo que tiene que llegar a ser cierto.
Output-driven no va de entregables ni de velocidad. Significa nombrar primero el resultado de negocio—qué tiene que ser verdad cuando el trabajo salga bien—y diseñar hacia atrás a partir de él.
01Resultado
¿Qué tiene que llegar a ser cierto?
- ¿Qué resultado justificaría este trabajo?
- ¿Quién nota que se ha conseguido, y cómo?
- ¿Qué no debe empeorar por el camino?
02Realidad
¿Qué está pasando hoy de verdad?
Antes de diseñar nada, miro la operación desde siete ángulos.
- Personas
- ¿Quién trabaja en el proceso?
- ¿Quién decide?
- ¿Quién se ocupa de recuperar los fallos?
- Proceso
- ¿Qué pasa realmente hoy?
- ¿Dónde están los traspasos?
- ¿Dónde están los atajos?
- Sistemas
- ¿Qué plataformas existen ya?
- ¿Qué limitaciones tienen?
- ¿Qué no conviene sustituir?
- Datos
- ¿Qué es fiable?
- ¿Quién es responsable de la identidad?
- ¿Qué definiciones chocan?
- Organización
- ¿Qué incentivos hay?
- ¿Cómo se gestiona el rendimiento?
- ¿Dónde está la responsabilidad?
- Restricciones
- Legales, financieras, técnicas
- De plazo y de escala
- Límites organizativos
- Excepciones
- ¿Qué pasa fuera del camino feliz?
- ¿Quién se ocupa cuando ocurre?
- ¿Qué excepciones son en realidad política?
- Personas
03Restricciones
¿Qué no se puede ignorar?
- ¿Qué está fijado por ley, contrato, presupuesto o plazo?
- ¿Qué dependencias quedan fuera del control del equipo?
- ¿A qué escala tiene que sobrevivir el diseño?
- Legales
- Financieras
- Técnicas
- De plazo
- De escala
- Organizativas
04Diseño
¿Qué combinación de proceso, personas, tecnología y datos puede producir el resultado?
Aquí, «sistema» no significa solo software.
- Personas
- Proceso
- Responsables
- Tecnología
- Datos
- Automatización
- Gobierno
- Medición
El sistema es todo lo que tiene que funcionar a la vez para que el resultado sea repetible.
05Ejecución
¿Cómo se introduce el cambio sin riesgo?
- ¿En qué orden puede llegar el cambio sin romper la operación?
- ¿Quién tiene que trabajar de otra forma, y qué recibe a cambio?
- ¿Cómo y cuándo se retira la forma antigua?
06Medición
¿Hemos conseguido de verdad el resultado buscado?
- ¿Qué señal muestra que el resultado es cierto?
- ¿Quién es responsable de esa señal, y qué hace cuando se mueve?
- ¿Cómo sabemos que lo produjo el diseño y no la suerte?
La medición comprueba el resultado y prepara el siguiente.
El método en la práctica
La misma petición. Otro punto de partida.
Una petición conocida, leída de dos maneras. Las dos terminan en una arquitectura; solo una está diseñada para alcanzar un resultado.
“Automatizar el alta de clientes.”
Una relación comercial aprobada se convierte en un cliente operativo: de forma fiable, entre sistemas, sin identidades duplicadas ni fallos ocultos.
- El CRM es responsable del contexto comercial.
- El ERP es responsable de la identidad legal.
- Ya existen duplicados.
- Hace falta validación financiera.
- El ERP puede no estar disponible.
- ¿Proceso?
- ¿Responsables?
- ¿Identidad?
- ¿Estado?
- ¿Fallo?
- ¿Recuperación?
- ¿Medición?
- CRM
- Integración
- ERP
- Datos
- Automatización
Guiada por el resultadoCada pieza de la arquitectura responde a una pregunta que planteó el resultado, incluido qué pasa cuando falla.
Leer el caso del ciclo de vida del cliente entre CRM y ERP02 · Pensamiento de segunda capa
El requisito es la primera capa. La arquitectura empieza debajo.
Output-driven me dice por dónde empezar. El pensamiento de segunda capa, hasta dónde llegar: más allá de la petición visible, hasta las decisiones, los responsables, los tiempos y los fallos que deja sin decir.
“Conectar el CRM con el ERP.”
Construir una integración entre los dos sistemas.
4 de 8 preguntas a la vista
Una cuenta comercial puede existir mucho antes que el cliente legal.
- Output-Driven
- marca la dirección
- Segunda capa
- descubre la complejidad
- Disciplinas
- aportan las herramientas
- Casos
- muestran el resultado
03 · Casos seleccionados
Donde el método enseña su trabajo.
Escenarios ficticios y compuestos. Todos parten de un resultado; ninguno pertenece a una sola disciplina.
Diseñar el ciclo de vida del cliente entre CRM y ERP
- Una relación comercial aprobada se convierte en un cliente operativo de forma fiable, sin identidades duplicadas ni fallos ocultos.
- Dos sistemas con distinta autoridad, un ERP que puede no estar disponible y timeouts que no prueban un fallo.
Disciplinas: Arquitectura de Sistemas y CRM · Datos e Integraciones
Diseñar un modelo operativo global de lead a cliente
- Cada lead cualificado se convierte en cliente a través de etapas con un único responsable, y cada rechazo llega a quien puede corregirlo.
- Marketing, ventas, dirección comercial y finanzas tenían cada uno una parte; un único paso de aprobación mezclaba decisiones que nadie podía valorar solo.
Disciplinas: Arquitectura de Procesos · Modelo Operativo Digital
Un orquestador mensual para el rendimiento comercial
- Una ejecución por periodo que puede esperar, fallar, reanudarse y terminar exactamente una vez, y que un responsable de negocio puede leer.
- Varios sistemas, esperas largas, fallos parciales y un resultado que tiene que cuadrar antes de contar.
Disciplinas: Automatización · Revenue Operations
Diseñar un agente de entrada de RFQ asistido por IA
- Cada RFQ se prepara en minutos con evidencia para cada valor, y nada con consecuencias sin la aprobación de una persona con nombre.
- Peticiones sin estructura, productos y clientes ambiguos, y un agente que nunca debe ser quien se compromete.
Disciplinas: IA y Flujos Agénticos · Arquitectura de Procesos
Diseñar un modelo operativo comercial global para varias filiales
- Un único modelo operativo comercial para todas las filiales: un núcleo global que no varía y diferencias locales con responsable, motivo y revisión.
- Filiales con distinta madurez, requisitos legales y costumbres, y cada preferencia local presentada como una excepción.
Disciplinas: Modelo Operativo Digital · Arquitectura de Sistemas y CRM
04 · Disciplinas
Las disciplinas con las que trabajo.
Ocho ópticas que elijo según lo que pida el resultado. Un problema real casi nunca pertenece a una sola.
Modelo operativo
05 · Decisiones, lab y artículos
El razonamiento detrás del trabajo.
DecisionesPor qué se tomó una decisión de arquitectura
- Crear el cliente en el ERP de forma asíncrona
- Conceder autoridad al agente por acción y consecuencia, nunca por confianza
Sobre mí
Conozco las plataformas, pero no parto de ellas.
Trabajo entre la operación comercial, los procesos y la tecnología: programas CRM globales, Revenue Operations, la frontera entre CRM y ERP, datos, automatización e IA gobernada. No empiezo por una plataforma: empiezo por el resultado y recorro hacia atrás la realidad operativa hasta que el sistema necesario queda claro.
Más sobre cómo trabajo¿Un resultado más difícil de alcanzar de lo que parece?
Si cruza varios equipos, sistemas o decisiones, me interesará conocerlo.
escasaincarlos@gmail.com Página de contacto