El Analista de los 5 Porqués skill para Claude

El método se atribuye en general a Sakichi Toyoda, el fundador de Toyota Industries. Taiichi Ohno lo hizo conocido como parte fija del Sistema de Producción Toyota y lo describió en su libro sobre ese sistema de 1978. El razonamiento detrás es simple: todo problema visible es consecuencia de algo más profundo, y esa causa más profunda solo se alcanza bajando varias capas. Cinco no es un número sagrado. Es una regla práctica que dice que, en la primera explicación plausible, probablemente todavía no has llegado.

El Analista de los 5 Porqués traduce ese método a una forma de trabajo fija para Claude. Una skill es un archivo de instrucciones, SKILL.md, que le da a un asistente de IA una forma fija de abordar una tarea. No es software que instalas, no hay suscripción ni conexión con tus sistemas: un archivo de texto de 2.189 palabras que le dice a Claude cómo debe montarse un análisis de causas, qué debe preguntar primero, cómo marca la certeza de cada capa y qué no puede inventar bajo ningún concepto. Descargas el zip al principio de esta página, lo colocas en tu entorno de Claude, y desde ese momento cada pregunta de causa pasa por esta lógica.

Lo que hace diferente a la skill de simplemente preguntar cinco veces por qué está en tres cosas. Primero, te obliga a hacer el problema medible antes de nada. Antes de que caiga el primer porqué, reescribe tu queja como una frase objetiva con lugar, momento y magnitud. Segundo, etiqueta cada capa según la prueba que la respalda, para que al final veas qué parte de tu análisis se apoya en datos y qué parte en una historia que por casualidad cuadra. Tercero, separa el parche de la intervención: el arreglo directo que detiene el síntoma esta semana queda aparte de la medida estructural que elimina la causa, cada una con su responsable y su plazo.

El archivo forma parte de la biblioteca de skills NL de TheSEO, donde hay 100 skills gratis para descargar, y nace del servicio IA y automatización. Si es la primera vez que usas este tipo de archivos, empieza por qué son las skills de Claude NL: ahí se explica en lenguaje sencillo qué es y qué no es una skill.

La cadena apunta a personas. Es la trampa más conocida, y Eric Ries le puso nombre en The Lean Startup, de 2011: Five Blames. Cada capa acaba en alguien que olvidó algo, no lo comunicó o no prestó atención. Resulta satisfactorio, porque hay un culpable. Pero puedes reparar un sistema y no puedes reparar a una persona, así que ese análisis siempre termina en una conversación y nunca en una medida. Señalar a una persona como causa raíz lo rechaza sin rodeos, y las causas las escribe precisamente en voz pasiva para quitar de en medio la pregunta de la culpa. No fue Juan quien olvidó el control, sino que el control se saltó porque no había un campo obligatorio.

La cadena reformula en lugar de explicar. La capa tres dice con otras palabras lo mismo que la capa dos. Los presupuestos tardan porque el plazo es alto: parece un paso más profundo, pero sigues en el mismo sitio. En el modo de evaluación de la skill este es el primer punto de control, y el archivo llama a las reformulaciones literalmente el error más frecuente.

La cadena se detiene en la capa técnica. El SKILL.md distingue tres tipos de capa que sueles encontrar: la capa técnica, donde algo falló en una acción, un ajuste o un fragmento de código; la capa de proceso, donde el proceso permitió ese fallo o incluso lo provocó; y la capa de sistema, donde nadie era responsable, los incentivos estaban mal orientados o una decisión anterior causó esto sin querer. Un buen análisis rara vez termina en la capa técnica. Ahí está el arreglo rápido, no la solución estructural.

O la cadena aparenta que todo es seguro. Cinco respuestas seguidas se leen como cinco hechos, aunque tres de ellas sean una apuesta. Por eso cada capa del resultado lleva una línea de Certeza, con uno de tres valores: confirmado por datos, plausible pero no probado, o pura hipótesis. En la FIG.01 hay dos capas en hipótesis, y esas dos vuelven al final en un bloque aparte con lo que todavía hay que averiguar. Ese bloque es la sección más honesta de todo el resultado.

En forma de diff, con una cadena que se razona hacia una persona frente a la misma cadena que sigue hasta el sistema:

Después viene un capítulo de teoría: Toyoda y Ohno, las tres capas técnica, de proceso y de sistema, y cuatro variantes que la skill puede usar cuando el contexto lo pide. La cadena ramificada, para cuando una capa tiene varias causas válidas. La combinación con el diagrama de Ishikawa, para cuando todavía nadie sabe dónde está el problema. Five whys plus how, en la que después de la causa raíz se recorre la cadena hacia arriba preguntando cómo se protege cada capa. Y la variante lean startup de Eric Ries, en la que por cada capa se hace una inversión proporcional a la gravedad del problema.

El núcleo es una lista de siete cosas que la skill hace siempre. Reformula el problema en una frase objetiva y medible, con lugar, momento y magnitud, antes de que caiga un porqué. Plantea las cinco preguntas una por una y las responde según lo que tú le has dado, no según una suposición. Marca en cada capa la certeza de la respuesta. Divide la cadena visiblemente en ramas en cuanto una capa tiene varias causas válidas, y sigue la rama de mayor impacto.

Formula la causa raíz en una frase, planteada como sistema o proceso. Entrega el arreglo directo y la medida estructural por separado, cada una con responsable y plazo. Y cierra con un paso de verificación.

Antes de analizar nada, la skill repasa una lista de comprobación obligatoria de seis puntos: el problema en tus propias palabras, cuándo ocurre y con qué frecuencia, a quién o a qué afecta, qué se ha intentado ya y por qué no funcionó, qué datos o cifras hay disponibles, y qué puedes y qué no puedes cambiar en presupuesto, mandato e influencia sobre otros departamentos. Solo pregunta lo que falta y después deja de preguntar. Si no sabes algo, sigue adelante y marca esa capa como no probada. Es decir, no recibes un formulario, como mucho dos o tres preguntas concretas.

Sorprendentemente muchas reglas hablan de lenguaje. Neerlandés claro (el archivo está escrito en neerlandés), trato de tú, sin guiones en el texto corrido, AI en mayúsculas, sin listas de exactamente tres elementos, lo concreto por encima de lo abstracto, la cifra por encima del adjetivo, y frases cortas alternadas con largas. Incluso hay una lista de palabras y giros prohibidos porque huelen a IA. Y hay una regla de redacción que es de contenido y no cosmética: escribe las causas en voz pasiva cuando eso quita de en medio la pregunta de la culpa. Si quieres entender cómo llegan reglas así a un archivo de skill, escribir un SKILL.md NL explica la estructura paso a paso.

El resultado está fijado en siete bloques en orden fijo: planteamiento, la cadena de porqués, causa raíz, arreglo directo, medida estructural, verificación, y lo que todavía hay que averiguar. Además, el archivo tiene un modo de evaluación aparte para análisis existentes, una lista de siete cosas que la skill nunca hace, y una lista de cinco fuentes. Estas dos últimas tienen su propia sección más adelante en esta página.

El método en sí viene de Toyoda y Ohno. Taiichi Ohno describió el Sistema de Producción Toyota en 1978, con la edición en inglés en 1988, y en ella atribuye las cinco preguntas de porqué a Sakichi Toyoda. Lo que a menudo se pasa por alto es el contexto: en Toyota, preguntar una y otra vez no era una técnica de reunión sino un hábito en el taller, cerca de la máquina, con las personas que hacían el trabajo. Eso explica por qué la skill insiste tanto en los hechos y en lo que tú mismo puedes observar.

La antesala viene de Kaoru Ishikawa. Su Guide to Quality Control, de 1968, contiene el diagrama de causa y efecto que en la práctica casi siempre se usa junto con el método de los 5 porqués. El reparto de papeles es claro: el diagrama de espina de pescado amplía, la cadena de porqués profundiza. Quien quiera ampliar primero y elegir después también puede acudir a la skill de Entrenador de Estructura MECE NL, que divide un problema en casillas que no se superponen y juntas lo cubren todo.

La trampa viene de Eric Ries. The Lean Startup, de 2011, describe el método de los 5 porqués en el desarrollo de producto e introduce el término Five Blames para la cadena que en cada capa apunta a una persona. Ries también le añadió una regla de inversión: el esfuerzo que pones en una medida debe ser proporcional a la gravedad del problema, para que no empieces un proyecto de medio año después de un incidente pequeño.

El lado del coaching viene de Mike Rother. Toyota Kata, de 2009, trata sobre cómo se estructuran la mejora y el coaching dentro de Toyota. Es relevante porque un análisis de causas rara vez es una acción puntual: si repites la misma rutina de preguntas cada semana, preguntar una y otra vez se convierte en un hábito en vez de en un ejercicio ocasional.

La advertencia viene de Sidney Dekker. The Field Guide to Understanding Human Error, de 2006, explica por qué los análisis de causas que terminan en una persona no sirven. El error humano no es una explicación sino el punto donde hay que empezar a buscar. Esta fuente es la razón por la que la prohibición de culpar en la skill no es una norma de cortesía sino una herramienta de análisis: mientras la cadena termine en un nombre, todavía no has respondido a la pregunta.

Incluso sin instalar la skill puedes mejorar tus propios análisis con estos principios: haz el problema medible primero, etiqueta en cada capa cuánto de seguro estás, y oblígate a formular la última capa como proceso y no como persona.

Después, el uso es sencillo: describe el problema tal como lo vives, con las cifras o registros que tengas. Cuanto más en bruto, mejor, siempre que sea información real. La skill pregunta por su cuenta lo que falta y sigue con lo que ya tiene. Si la instalación se atasca en algún punto, la explicación completa por entorno está en instalar skills de Claude NL, incluidos los errores más frecuentes con carpetas y permisos. Y si quieres aprender a trabajar con IA de forma más amplia, en la base de conocimiento NL encuentras los artículos de fondo.

Dos ajustes que el propio archivo menciona, y que mucha gente pasa por alto. Puedes parar antes de cinco capas si ya has llegado a una causa sobre la que tienes influencia, siempre que digas que paras y por qué. Y puedes seguir más allá de cinco capas si la quinta sigue siendo un síntoma. En incidentes con impacto en seguridad o en lo financiero, la skill añade además una capa extra que no trata sobre la causa sino sobre la detección: por qué no se notó antes. Esa pregunta suele dar una segunda medida, independiente de la primera.

También hay situaciones en las que es mejor dejarla de lado, y la skill lo dice ella misma en su frontmatter. No durante un incidente en curso: primero se apaga el fuego y después se analiza, porque analizar durante una avería consume atención que necesitas para detenerla. En sesiones de brainstorming donde precisamente quieres abrir opciones funciona al revés, porque este método reduce en vez de expandir. Tampoco escribe textos. Y no para varios problemas a la vez.

Otro límite honesto que no está en el archivo pero cuenta en la práctica: la skill mejora tu análisis, no tu organización. Si la causa raíz está en una decisión que tomó alguien por encima de ti y no quiere revertir, tienes un análisis muy claro y sigues teniendo el mismo problema. Lo que la skill sí hace entonces es poner eso claro por escrito, con un paso de verificación debajo, para que la conversación vaya sobre hechos y no sobre impresiones. Si quieres pasar de una causa a una prioridad, la skill de Analista de Pareto NL es el siguiente paso lógico: determina qué causas explican la mayor parte del problema.

Si el problema que investigas está en la entrada, en muy pocas solicitudes en vez de en el plazo posterior, el trabajo empieza en otro sitio: en que te encuentren las personas que te buscan. El análisis SEO gratis muestra en pocos segundos dónde está tu web. Y si quieres hablar sobre lo que la IA puede hacer más por tu empresa, desde skills sueltas hasta automatización completa, lo hacemos simplemente en una conversación.