Categoría: Resultados

Más números, más criterios y más cálculos no implican necesariamente una decisión mejor. El rigor consiste en saber qué estamos midiendo, evitar contar dos veces lo mismo, mantener independientes los juicios y utilizar un método coherente con la calidad real de la información disponible.

Errores frecuentes que hacen que una matriz de priorización parezca más rigurosa de lo que realmente es:

• Duplicar dimensiones sin darse cuenta. Si dos criterios miden aspectos iguales o muy solapados, esa dimensión entra varias veces en la decisión. Es una ponderación oculta.

• Cuando el valor de un criterio depende del nivel de otro, asignarles pesos separados puede no tener sentido.

• Confundir criterios con requisitos. Hay condiciones que no deberían recibir un peso ni compensarse con otras. Si algo es imprescindible (por ejemplo, disponer de una habilitación necesaria para un puesto) debe funcionar como filtro o umbral previo, no como una columna más de la matriz.

• Puntuar viendo la alternativa completa. Cuando el evaluador ve simultáneamente la fila, las demás puntuaciones y, sobre todo, el total, aparecen el efecto halo, el anclaje y los ajustes para que gane la alternativa preferida. La matriz deja entonces de ayudar a tomar la decisión y pasa a justificar una decisión que, consciente o inconscientemente, ya estaba tomada. La unidad de juicio debería ser cada celda, valorada de la forma más independiente posible.

• Creer que poner números convierte un juicio relativo en una medición absoluta. Una escala 1–5 sin anclas descriptivas no significa necesariamente que “4” represente un nivel objetivo. Con frecuencia significa simplemente “mejor que estas alternativas y peor que aquellas”. Es decir, es una ordenación relativa disfrazada de medición. La medición absoluta requiere una rúbrica que describa qué significa cada nivel.

• Usar métodos sofisticados con criterios mal definidos. Si “encaje estratégico”, “impacto” o “calidad” significan cosas diferentes para cada evaluador, hacer más cálculos no aumenta la calidad de la decisión. Puede producir justo lo contrario. Genera una falsa rigurosidad, fundamentada en la precisión matemática, que se basa en juicios imprecisos. La sofisticación del método no debería superar la calidad de la definición de los criterios.

• Desaprovechar la redundancia de la comparación pareada. AHP y otros métodos de comparación pareada de alternativas exigen muchos más juicios precisamente porque esa redundancia permite detectar inconsistencias. Si unas comparaciones se deducen de otras para ahorrar trabajo, puede obtenerse una consistencia aparentemente perfecta, pero se ha eliminado precisamente la información que justificaba realizar las comparaciones adicionales.

• Elegir el método por su apariencia de rigor y no por el problema de medición. Una lista ordenada puede ser la opción más adecuada cuando el juicio es holístico o los criterios están poco definidos. Una matriz de priorización tiene sentido cuando los criterios están bien definidos, son lo bastante independientes y existen anclas que permitan valorar las alternativas. La comparación pareada resulta especialmente útil cuando los criterios están definidos, pero no existen buenas anclas, y queremos hacer explícitos los juicios relativos y comprobar su coherencia.

Visitas: 27

El primer error está antes de cualquier porqué. Si un efecto está mal definido, por ejemplo “Tenemos problemas de calidad”, no permite trabajar a nadie. El efecto tiene que poder medirse (qué defecto, en qué línea, cuánto, desde cuándo), porque todo el diagrama se va a contrastar contra él.

En la primera ronda casi siempre salen etiquetas vagas: “molde viejo”, “material malo”. Suenan a causa, pero no se pueden comprobar. La corrección consiste en bajar a la máquina o a los datos y reescribir el posit con algo verificable, lo que se ha visto o lo que dice la ficha técnica. Un posit que no se puede confirmar o descartar no sirve para seguir preguntando.

Con el culpable pasa algo parecido. “Operarios descuidados” o “el técnico no lo conectó” aparecen, y a veces muy abajo, cuando el grupo ya creía haber superado esa fase. Hay una prueba sencilla: si cambiando a la persona el problema seguiría ahí, la causa no es la persona. Se reescribe como conducta observable o como fallo del sistema (la tarea no tiene responsable, nadie enseña otra forma de reaccionar).

Algunas ideas son ciertas, pero responden a otra pregunta. “No se revisan las piezas” explica por qué el defecto llega al cliente, no por qué se produce. No se tira: se deja en espera de decisión, porque merece su propio análisis. Mezclarla con el resto contamina el diagrama. Los posits genéricos que solapan con otra rama (“falta mantenimiento”) se retiran sin más, y lo que tuvieran de cierto acaba saliendo más abajo con palabras concretas.

El error más frecuente, y el más difícil de ver, está en las flechas. Un posit puede estar bien escrito y colgar del sitio equivocado. Ocurre de dos maneras. La primera es poner como hermanas dos causas que en realidad son padre e hijo: subir la presión no está al lado de “presión alta”, la explica, y por eso tiene que bajar un nivel. La segunda es agrupar por tema en lugar de por causalidad. La secadora se pone bajo “material” porque todo lo del material parece ir junto, pero no explica que la fluidez varíe entre lotes. Explica el material húmedo, que está en otra rama y dos niveles más abajo. Cuando se descubre esto, el diagrama no se corrige añadiendo, se corrige moviendo cosas.

También faltan eslabones. Pasar de “el plan cuenta horas, no ciclos” a “desgaste en el molde” parece razonable hasta que se lee despacio: contar horas no desgasta nada. Falta el paso intermedio (el molde supera los ciclos previstos sin revisión), y al intercalarlo todo lo que cuelga debajo baja un nivel.

La herramienta para detectar tanto las flechas mal puestas como los huecos es leer cada rama en voz alta, de abajo arriba, uniendo los posits con “por tanto”. Si alguna frase chirría, ahí hay un problema.

Otro error es pararse demasiado pronto, en la causa técnica: la resistencia de la secadora está rota. Eso se arregla cambiando la resistencia, y la próxima avería volverá a pasar inadvertida. Se sigue preguntando hasta llegar a algo que depende de cómo está organizado el trabajo (las averías de equipos auxiliares no entran en el sistema de gestión de mantenimiento) y que admite una acción concreta con responsable. Ahí se para, y no antes. Por eso hacen falta cinco o seis niveles en las ramas largas, mientras que otras se cierran en tres. No hay que igualarlas.

Personalmente prefiero el formato en gota (“tear drop”) al diagrama de espina de pescado o de Ishikawa, y buena parte de los comentarios anteriores explican por qué. La espina de pescado arranca con categorías fijas (máquina, método, material, mano de obra, medio, medición) y eso empuja justo a agrupar por tema. La secadora acabaría en la espina de “máquina” o en la de “material”, y la relación con el material húmedo, que es lo que importa, quedaría escondida. La categoría “mano de obra” es además una invitación a apuntar culpables. En la gota no hay cajones previos: cada posit cuelga del posit al que explica, y la estructura sale de las relaciones causales, no de una clasificación.

La otra razón es la profundidad. Las espinas de pescado suelen quedarse anchas y planas, con muchas causas en el primer o segundo nivel y pocas cadenas que bajen de ahí, en parte porque en las espinas pequeñas no cabe casi nada. En la gota los niveles se ven: se nota de un vistazo qué rama se ha quedado corta, y el espacio crece hacia abajo justo donde aparecen más causas. Con posits, mover una idea de nivel o cambiarla de flecha es cuestión de segundos, y la lectura de abajo arriba con “por tanto” funciona porque cada cadena es una línea continua. No descarto las categorías del Ishikawa. Cuando un grupo se bloquea en la primera ronda, repasarlas ayuda a que salgan ideas. Las uso como lista de comprobación, no como estructura del diagrama.

Todo esto solo se ve si se acepta que el diagrama no se dibuja de una vez. Lo que sale en la primera media hora es un borrador, y la forma de gota aparece después de reescribir, mover y quitar posits varias veces.

Framework relacionado:

Marin-Garcia, J. A., Garcia-Sabater, J. J., Garcia-Sabater, J. P., & Maheut, J. (2020). Protocol: Triple Diamond method for problem solving and design thinking. Rubric validation. WPOM-Working Papers on Operations Management, 11(2), 49–68. https://doi.org/10.4995/wpom.v11i2.14776

Visitas: 25

The first mistake comes before any why: a poorly defined effect. “We have quality problems”, for example, gives nobody anything to work with. The effect has to be measurable (which defect, on which line, how much, since when), because the whole diagram will be checked against it.

The first round almost always produces vague labels: “old mould”, “bad material”. They sound like causes, but they can’t be verified. The fix is to go down to the machine or to the data and rewrite the sticky note with something verifiable, whether it’s what was seen or what the process sheet says. A note that can’t be confirmed or ruled out is no use for asking the next why.

Something similar happens with blame. “Careless operators” or “the technician didn’t connect it” show up, sometimes far down the diagram, when the group thought it had moved past that stage. There is a simple test: if the problem would still be there with a different person, the cause isn’t the person. The note is rewritten as observable behaviour or as a failure of the system (the task has no owner, nobody teaches another way to react).

Some ideas are true but answer a different question. “Parts aren’t inspected” explains why the defect reaches the customer, not why it happens. It isn’t thrown away. It goes to “awaiting decision”, because it deserves its own analysis. Mixing it in with the rest contaminates the diagram. Generic notes that overlap with another branch (“lack of maintenance”) are simply removed, and whatever truth they held ends up surfacing further down in concrete terms.

The most frequent mistake, and the hardest to spot, is in the arrows. A note can be well written and hang from the wrong place. This happens in two ways. The first is placing two causes side by side as siblings when they are really parent and child: raising the pressure doesn’t sit next to “high pressure”, it explains it, so it has to drop a level. The second is grouping by topic instead of by causality. The dryer gets placed under “material” because everything about material seems to belong together, but it doesn’t explain why the flow index varies between batches. It explains the damp material, which is in another branch and two levels further down. When this comes to light, the diagram isn’t corrected by adding things. It’s corrected by moving them.

Links go missing too. Going from “the plan counts hours, not cycles” to “wear on the mould” seems reasonable until you read it slowly: counting hours doesn’t wear anything. The intermediate step is missing (the mould exceeds its planned cycles without inspection). Once it’s inserted, everything hanging below it drops a level.

The tool for catching both misplaced arrows and gaps is to read each branch aloud, bottom-up, joining the notes with “therefore”. If any sentence grates, there’s a problem there.

Another mistake is stopping too early, at the technical cause: the dryer’s heating element is broken. That gets fixed by replacing the element, and the next breakdown will go unnoticed again. You keep asking until you reach something that depends on how the work is organised (failures on auxiliary equipment aren’t logged in the maintenance management system) and that allows a concrete action with an owner. That’s where you stop, and not before. This is why the long branches need five or six levels while others close at three. There’s no need to even them out.

Personally, I prefer the tear drop format to the fishbone or Ishikawa diagram, and many of the mistakes above explain why. The fishbone starts from fixed categories (machine, method, material, manpower, environment, measurement), and that pushes people towards exactly the grouping by topic described above. The dryer would end up on the “machine” or the “material” bone, and its link to the damp material, which is what matters, would stay hidden. The “manpower” category is also an open invitation to write down culprits. In the tear drop there are no predefined boxes: each note hangs from the note it explains, and the structure comes from causal relationships, not from a classification.

The other reason is depth. Fishbone diagrams tend to end up wide and flat, with many causes on the first or second level and few chains going further. Part of the reason is that the small bones have almost no room. In the tear drop the levels are visible. You can see at a glance which branch has stopped short, and the space grows downwards precisely where more causes appear. With sticky notes, moving an idea to another level or another arrow takes seconds, and reading bottom-up with “therefore” works because each chain is a single continuous line. I don’t discard the Ishikawa categories. When a group gets stuck in the first round, going through them helps ideas come out. I use them as a checklist, not as the structure of the diagram.

None of this becomes visible unless you accept that the diagram isn’t drawn in one go. What comes out in the first half hour is a draft, and the tear drop shape emerges only after rewriting, moving and removing notes several times.

Related Framework:

Marin-Garcia, J. A., Garcia-Sabater, J. J., Garcia-Sabater, J. P., & Maheut, J. (2020). Protocol: Triple Diamond method for problem solving and design thinking. Rubric validation. WPOM-Working Papers on Operations Management, 11(2), 49–68. https://doi.org/10.4995/wpom.v11i2.14776

Visitas: 8