Una página explica qué entrego. La otra cuenta cómo lo hago. Esta es la del cómo.
La publico entera por dos razones.
Una: el método tiene autor. Si esto se vuelve una práctica común, prefiero que me la copien sabiendo de dónde viene.
Dos: lo que vendo no es la información. Es la ejecución. Puedes leer este método completo, entenderlo, y aún así no poder aplicarlo en tu empresa. Por qué no puedes, lo explico al final. La distancia entre leer y ejecutar es donde vivo yo.
Si en tu negocio hay dos o tres personas cuyo criterio funciona con ellas delante y se aplana sin ellas, este texto explica exactamente cómo se hace visible, se codifica y se comprueba.
Esta página tiene dos lectores. Tú, que diriges la empresa. Y tu experto, la persona cuyo criterio se va a codificar. Reenvíasela. Su criterio no se codifica a sus espaldas: define la decisión correcta, conserva la autoría y aprueba los límites del motor.
Léela entera. Después decides si lo intentáis solos o si me escribes.
Si el criterio de tu gente clave sigue funcionando solo cuando ellos están en la sala, no es porque no lo hayáis intentado resolver.
El manual está escrito para el caso normal. Pero el valor de tu experto no está en el caso normal. Está en lo que decide cuando el caso normal no aplica. Eso no cabe en un manual, porque para escribirlo tendría que saber primero que lo hace. Y no lo sabe.
Los vídeos y las sesiones enseñan la técnica, no el criterio. El empleado avanza mientras los casos encajan en lo que aprendió. El día que algo no encaja, se queda mirando la pantalla. Y el veterano no está dentro del vídeo para decirle qué hacer.
La sombra funciona mientras están juntos, que es exactamente el problema que intentabas resolver. Por ósmosis se pegan los hábitos y el vocabulario, no las decisiones condicionadas. Y reproduce el cuello de botella: un aprendiz cada vez, años por cabeza.
Cuando alguien le pregunta «¿qué decides cuando un caso se desvía?», su respuesta es una versión de manual. Es lo que cree que hace, no lo que hace. Lo que hace depende de cosas que no está procesando conscientemente, y una entrevista no captura ninguna.
Suena a vuestra empresa pero no decide como vuestro experto. Es una imitación de la voz corporativa, no una réplica del juicio. No podía salir otra cosa: los documentos con los que se entrenó ya tenían el problema de los cuatro puntos anteriores.
Imagina que en tu empresa entran pedidos urgentes y hay una persona que siempre acierta al decidir cuáles aceptar.
Cuando documentas, escribes así «Al evaluar un pedido urgente es importante analizar la capacidad disponible, el margen y el impacto en los compromisos existentes.»
Cuando codificas, escribes así «Si el cliente pide plazo urgente pero tarda más de dos días en enviar la información técnica, la urgencia es negociación, no necesidad: acepta el pedido con el plazo estándar. Excepción: si es uno de los tres clientes que concentran la facturación y quien pide es fábrica y no compras, la urgencia es real aunque el papeleo llegue tarde. Ahí se reorganiza la planificación y se asume el coste.»
La primera versión es información. Cualquiera la lee y asiente. Nadie sabe qué hacer con ella mañana.
La segunda versión es una decisión. Tiene una entrada (lo que pasa), una salida (lo que haces) y una excepción (cuándo no aplica la regla normal). Es lo que en Encode llamo una Regla con su Matriz de Excepciones.
El trabajo de tu experto, cuando funciona, está hecho de decisiones del segundo tipo. Cientos de ellas. La mayoría las toma sin darse cuenta de que las está tomando. Por eso no puede documentarlas: para documentarlas tendría que primero darse cuenta de que existen.
Vuestros manuales están documentados. Vuestro archivo tiene que estar codificado.
Si le pregunto a tu director de operaciones «¿qué haces cuando un pedido se complica?», me va a dar una respuesta de manual. Va a hablar de evaluar capacidad, de comunicar al cliente, de priorizar.
Si en cambio pongo esto sobre la mesa:
Su cerebro entra en un modo distinto. No puede recurrir a la respuesta de manual porque la respuesta de manual no resuelve la situación específica. Se ve obligado a aplicar su criterio real.
Y mientras lo aplica, yo escucho.
Lo que escucho no es lo que dice. Es las decisiones que toma sin explicar por qué.
No «un pedido complicado» sino este cliente, este plazo, este director de compras nuevo, el comité esta tarde. Los detalles obligan a respuestas reales.
El comité es esta tarde. No puede posponer la decisión. La presión temporal activa el criterio. Sin urgencia, todo el mundo habla en abstracto.
La regla normal de operaciones es proteger la planificación. Pero si la proteges siempre, pierdes al cliente que sostiene la facturación. El escenario obliga a decidir cuándo la regla normal no aplica. Ese momento es donde aparece el juicio tácito.
Cualquier escenario que cumpla las tres condiciones hace el mismo trabajo. En tu Diagnosis construyo entre cinco y ocho de ellos, calibrados a tu sector y a la operación concreta de tu empresa. Algunos los preparo en la inmersión previa, desde vuestra documentación y vuestros casos reales. Otros los improviso en la sesión, a partir de lo que descubro mientras tu experto habla.
Mi trabajo es escuchar las decisiones que toma sin explicar por qué, y anotarlas mientras las aplica.
Se guardan en lo que llamo la Matriz de Excepciones. Cada regla del sistema tiene tres campos: la decisión que se toma en el caso estándar, las condiciones específicas que rompen esa decisión, y la decisión alternativa que aplica cuando la regla normal no sirve.
Dos ejemplos. El primero sale de mi propio sistema de venta; el segundo, del escenario de operaciones de arriba.
Cuando una operación se estanca, la decisión normal es construir un mensaje de reactivación con un insight nuevo, nunca «hacer seguimiento»: algo que ha cambiado en su negocio, un dato que contradiga lo que creen.
Pero antes de escribir ese mensaje, la regla obliga a repuntuar la evidencia del deal. Si la cualificación cae por debajo del umbral y no hay plan concreto para cerrar los huecos, el mensaje de reactivación solo alarga la agonía.
En ese caso, la decisión cambia: la operación se depriorita, se acepta el no que el cliente no verbaliza, y el tiempo se libera para operaciones vivas.
Cuando un cliente pide adelantar una entrega, la decisión normal es evaluar capacidad y aceptar solo si no rompe compromisos con otros clientes.
Pero si quien pide es un director de compras recién llegado a su cargo, la petición no es logística. Es una prueba de poder. Tratarla como logística la convierte en precedente.
En ese caso, la decisión cambia: la respuesta la da dirección comercial, no planificación, y cualquier concesión va acompañada de una contrapartida visible.
Cada criterio codificado tiene entre 8 y 30 reglas como estas. Mi primer motor tenía 11; hoy el sistema va por su versión 4.2, con cinco métodos y once protocolos conectados. Los entregables de Encode trabajan en ese rango.
La pieza que separa un sistema mediocre de uno útil es la condición intermedia: la que dice cuándo la regla normal no aplica. Si codificas solo las reglas, capturas la parte fácil del trabajo. Las excepciones contienen el criterio diferencial. La Matriz de Excepciones es la diferencia entre un archivo que decide como tu experto y un archivo que decide como cualquiera.
Coges un caso que tu experto ya resolvió en el pasado. Se lo das al sistema sin contarle cómo se resolvió. Comparas. Si el sistema toma la misma decisión que tomó él, ese caso pasa. Si toma una diferente, una de dos cosas: o el sistema está mal calibrado, o la solución original fue subóptima. Las dos son útiles.
Coges un caso que tu empresa tiene encima de la mesa esta semana, todavía sin resolver. Se lo das al sistema. Anotas su recomendación. Tu experto toma su propia decisión por separado, sin mirar lo que dijo el sistema. Comparas. Si coinciden, el sistema funciona en datos no vistos.
Inventas el caso más raro posible dentro de vuestro negocio. Algo que tu experto solo ha visto una o dos veces en su carrera. Se lo das al sistema. Aquí no esperas que acierte. Esperas que reconozca que está fuera del rango normal y que devuelva una respuesta del tipo «este caso no encaja en ninguna de las once reglas conocidas; antes de decidir, necesito saber [tres preguntas concretas]».
Los sistemas malos improvisan en los casos extremos. Los sistemas buenos saben pedir ayuda.
Diseñas un caso donde se cumplen todas las condiciones de una regla normal pero hay un detalle escondido que la invalida. El detalle no está marcado. No le dices al sistema «ojo, esto es una excepción». Tiene que detectarlo gracias a la Matriz de Excepciones.
Este es el caso más difícil. Es el que separa un sistema de manual de un sistema con criterio.
Reservamos casos que el motor no ha visto durante la construcción. Los elige tu experto entre decisiones reales de vuestro negocio, los resuelve por separado y es él quien define cuál era la respuesta correcta: ni yo ni el modelo. Comparamos decisiones, no estilos de redacción. El estándar exige coincidencia en al menos 8 de cada 10 decisiones recurrentes.
No todos los errores pesan igual, y por eso el 8 de 10 es un criterio de reparto, no un permiso. Dice qué volumen recurrente puede resolverse solo. Los casos nuevos, ambiguos o de alto riesgo no se dejan a una media: el motor debe reconocer el límite, pedir contexto o escalar la decisión. Donde equivocarse sale caro, la revisión humana no es opcional aunque el motor tenga una respuesta. Si después de tres ciclos no alcanza el umbral acordado, devuelvo el coste íntegro de Build.
Tú defines la decisión correcta, conservas la autoría de tu criterio y apruebas los límites del motor. Encode no amplía su autoridad ni automatiza nuevas decisiones sin autorización escrita. El objetivo es quitarte los casos repetitivos y reservar tu atención para las excepciones.
Tu experto lleva décadas acumulando criterio. No le falta dominio ni experiencia. Si su criterio sigue funcionando solo cuando él está en la sala, es por dos razones distintas.
Cuando alguien se examina a solas, su cerebro acude al patrón ya cargado. Salta directamente a la respuesta de manual porque la tiene a mano y no hay nadie delante que le obligue a explicar otra cosa.
Cuando quien pregunta no sabe nada de su dominio, pasa otra cosa. Tiene que explicar sus decisiones en términos que esa persona pueda entender. Al explicar, descubre reglas que no sabía que tenía. La fricción no está en apretar a nadie. Está en la obligación de hacer visible algo que normalmente queda implícito.
Y nadie de dentro de la empresa puede hacer de testigo. Su equipo conoce demasiado bien las respuestas de manual y las acepta. Su jefe introduce jerarquía: nadie confiesa sus atajos delante de quien le evalúa. Y al fundador no le frena ningún empleado.
Acepta sus propias respuestas demasiado rápido. Pasa por alto contradicciones. Asume coherencia donde no la hay.
Cuando hay un arquitecto externo, no pasa eso. Detengo cada «depende del caso» hasta identificar de qué depende. Cada «se nota cuando…» se convierte en una señal observable. Cada cambio de criterio se contrasta con su excepción.
Eso es Diagnosis. Dos semanas para hacer visible un criterio que normalmente queda implícito. Tu experto aporta el juicio. Yo aporto la distancia y el método para convertirlo en reglas comprobables.
Coge a tu experto. Diseña tres escenarios exigentes con las tres condiciones. Pídele a alguien de fuera de su dominio (no su jefe, no su equipo) que se los lea en voz alta y le pida una decisión concreta en tiempo limitado. Escribid lo que decide. Después, buscad las excepciones. Construid la Matriz de Excepciones. Calibradla contra casos reales reservados. Si llegáis al 8 de 10, habéis hecho lo que yo hago. Estaré encantado de leerlo si me lo mandas.
No tiene por qué terminar en un archivo. La sola conciencia de que el criterio tácito existe, de que tiene estructura, de que tiene excepciones, ya cambia cómo hacéis las incorporaciones, la formación interna y los traspasos. Mucha gente que lea este método no va a contratar Encode. Va a hacer mejores traspasos. También me parece bien.
En dos semanas te digo si el criterio crítico de tu empresa se puede codificar. Si la respuesta es sí, te entrego el Mapa de Criterio Crítico con las reglas y excepciones que extraje. Si decides que quieres el archivo ejecutable, pasamos a Build. Si no, te quedas el Mapa.
Llevo años intentando explicar lo que hago. Esta es la versión más clara que tengo. Si te ha servido, mándamela de vuelta con tus comentarios. Si lo aplicáis y no funciona, todavía mejor: dime dónde se rompió. La próxima versión de este método incorporará lo que aprenda de los primeros casos reales y de la gente que lo lea con honestidad.
Aplicar a Diagnosis →Dos semanas · Seis proyectos por trimestre · Cada aplicación la reviso yo
Diagnosis es una intervención independiente y remunerada. Si la respuesta es no, te quedas el Mapa de Criterio Crítico y no existe obligación ni inversión posterior en Build.