1) Trabajando en equipo en entornos presenciales, remotos e híbridos: Enlace a inscripción (disponible desde diciembre 2022-) 2) Liderazgo de equipos remotos: Enlace a inscripción (disponible desde noviembre 2022 -inicio curso marzo 2023-) 3) Habilidades de Comunicación interpersonal adaptada a equipos remotos: Enlace a inscripción (disponible desde noviembre 2022 -inicio curso mayo 2023-)
(versiones en inglés a partir de noviembre 2023)
Las competencias transversales (soft skills) son esenciales en prácticamente todos los puestos de trabajo actuales y complementan a las competencias técnicas (hard skills) para construir un perfil exitoso de las personas que abanderan/representan el talento de una organización. Para este programa hemos seleccionado un conjunto de tres competencias transversales cruciales (Trabajar en equipo, Influir positivamente en el comportamiento de las personas del equipo y comunicarse de manera efectiva con ellas). Este programa proporciona habilidades para trabajar en equipo en un entorno remoto, algo que ya es habitual en todas las instituciones y empresas y que cada vez lo será más.
Se sabe mucho sobre cómo usar estas competencias en entornos presenciales (y edX tiene ya moocs de esto). Sin embargo , existe un hueco en formación sobre cómo adaptar los comportamientos esenciales en cada competencia cuando el equipo trabaja remotamente.
It is very easy to confuse good interview questions with good Evidence-Based Management questions. They are related, but they are not the same thing. An interview question is something you ask one person about their own experience:
Do you feel that your supervisor listens to your suggestions?
What usually happens when a machine breaks down during your shift?
Why do you think people leave this department?
Do you find the new scheduling system useful?
These can all be excellent questions. They may generate rich information, examples and stories. But they are still questions designed to collect data from individual respondents.
A management question operates at a different level. It asks what we want to understand once we combine evidence from several people, teams, sites, documents or studies.
For example:
To what extent do employees perceive that their improvement suggestions are taken into account, and what organizational factors influence that perception?
Or, in an operations context:
What factors are associated with recurring production disruptions, and how do operators and supervisors perceive the effectiveness of the current response process?
The difference may look subtle, but it matters.
A simple test: Could a single interviewee give me the answer? If the answer is yes, you probably have an interview question. If answering the question requires gathering evidence from several people, comparing experiences, identifying patterns, or combining interview evidence with other sources, then you are much closer to a management question. This distinction is particularly useful for junior professionals because, in practice, they are often given broad assignments such as:
Find out why productivity has fallen.
Understand why people are leaving.
See whether employees are really involved in continuous improvement.
Investigate why the new process is not working.
The temptation is to immediately prepare a long list of interview questions. But before doing that, it is worth deciding what you actually want to know.
Start from the interview questions, but do not stop there
You do not need to discard the questions you have already written. Instead, group the questions that appear to explore the same underlying phenomenon. Imagine, for example, that you are analysing employee participation in an operations team. You may have drafted questions such as:
What happens when an operator identifies an improvement opportunity?
How can employees submit improvement ideas?
Who decides whether an idea is implemented?
Can you remember an occasion when an employee’s suggestion resulted in a real change?
Do people receive feedback about the ideas they submit?
These are useful interview items. But together they point towards a broader question:
How do employee participation channels operate in practice, and to what extent do employees perceive that their suggestions lead to meaningful action?
That is the question that gives coherence to the interviews.
The same logic applies in people management. Suppose you are trying to understand voluntary turnover in a department. Your interview guide may contain questions about workload, supervision, promotion opportunities, scheduling, recognition, and team relationships. The management question might instead be:
What factors do employees and line managers associate with voluntary turnover in this department, and which of these factors appear consistently across different roles or teams?
Now the project has a clearer analytical purpose. You are not simply collecting twenty individual stories. You are looking for patterns, differences, and plausible explanations.
A good management question defines the scope of the problem
In the CEBMa approach, a useful Evidence-Based Management question normally makes several things reasonably explicit.
Absenteeism, employee voice, turnover, implementation of standard work, quality problems, safety behavior, workload, coordination between departments, and adoption of a new technology?
Third, what do we want to know about it?
How frequently does it occur?
How does the process operate?
How do people experience it?
What factors appear to influence it?
What consequences does it have?
What interventions seem to improve it?
And if a comparison is important, include that comparison explicitly.
For example:
How does perceived workload differ between production and support teams, and what organizational factors are associated with those differences?
Or:
How do highly standardized production units differ from less standardized units in the way operators report and resolve process deviations?
Once the comparison appears in the question, it becomes much harder to forget that you need to collect the corresponding information.
Why this matters in real organizational projects? The quality of the management question affects almost everything that follows. A vague question often produces a vague evidence-gathering exercise. You interview many people, collect dozens of interesting comments, and eventually discover that the material is difficult to synthesize because different interviews were actually exploring different issues. A clearer question helps you decide:
Whom you need to interview;
What information do you need to collect;
Which comparisons are relevant;
What additional organizational data may be useful;
What external research evidence you should look for.
Consider an operations problem such as recurring delays.
If the question is simply:
Why are there delays?
the investigation can quickly become unmanageable. But suppose you formulate it as:
What are the main sources of recurrent scheduling delays in the assembly process, and how consistently are these causes identified across operators, supervisors and production data?
That question immediately suggests several sources of evidence. You may need interviews with operators and supervisors, but you may also need downtime records, production schedules, quality data or process observations.
That is an important feature of Evidence-Based Management: interviews are one source of evidence, not necessarily the whole evidence base.
Do not confuse a long interview guide with a sophisticated research design. Junior professionals sometimes worry that having only one or two management questions makes a project look too simple. Usually the opposite is true. A well-defined management question can require many interview items, several evidence sources and substantial analysis. For example, one question about employee involvement in continuous improvement may require you to explore:
Access to participation channels
Managerial response
Psychological safety
Feedback mechanisms
Implementation rates
Perceived fairness
Differences between departments
Examples of successful and unsuccessful suggestions
Those are not eight separate management questions. They may simply be different aspects of one phenomenon that need to be examined carefully. This is why one or two strong questions are often enough. If you end up with ten “research questions,” there is a good chance that some of them are actually interview questions in disguise.
The practical shift
For someone starting a career in Operations Management or People Management, I think the most useful change in mindset is this:
Do not begin by asking, “What questions should I ask people?”
Begin by asking “What do we need to understand in order to make a better management decision?”
Then decide what evidence would help answer that question. Some of that evidence may come from interviews. Some may come from organizational data. Some may come from scientific research. Some may come from professional expertise or stakeholder concerns.
The interview guide comes later.
Moving from questions to ask individuals to questions the organization needs evidence to answer is one of the most important steps in turning an informal investigation into an Evidence-Based Management process.
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.
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.
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.
La UAB publicó a principio de 2026 un informe sobre absentismo con 3.045 participantes de sus trece centros.
Olmos, P., y Márquez, D. (inv.); Vila, L. (col.); Muñoz, J. L. (coord.), y Badillo, E. (coord.). (2026). L’absentisme a les aules universitàries de la UAB. Per què val la pena anar a classe. ICE, Universitat Autònoma de Barcelona. https://ddd.uab.cat/record/327188?ln=es
Creo que el fenómeno no es nuevo (quizás lo llamativo es el volumen). Ya hace muchos años comentaba con mis compañeros la anécdota de exalumnos que decían que “la universidad no aportaba nada” (y luego se jactaban de haber aprobado sin ir a las clases, ni al campus). Efectivamente, si no participas de la experiencia universitaria, tu paso (de pasar) de la universidad no ha dejado ningún poso en ti.
Es como si te matricularas en un gimnasio, luego no fueras y dijeras que el gimnasio no sirve para nada. ¡Obvio, bro!
El ejemplo del gimnasio/deporte me gusta, porque conozco mucha gente de mi edad que me dice “no sé por qué te machacas tanto haciendo deporte, total estamos igual tú y yo”. En la superficie, seguro, incluso más guapos y jóvenes algunos (sobre todo los que se han hecho un implante de pelo). Pero las procesiones van por dentro. Y con la formación universitaria, igual.
Los condicionantes estructurales están presentes (trabajo, transporte, etc.), pero apenas separan a quien asiste de quien no. En la tabla comparativa, entre los que han dejado de asistir a alguna asignatura, trabaja el 42,3 % y entre los que no, el 37,6 %; tardan más de una hora en llegar al campus el 34,2 % frente al 30,4 %. Lo que sí discrimina es repetir asignatura y el curso, porque los de primero asisten más. Es decir, las condiciones de vida complicadas las tiene casi todo el mundo y eso no les impide asistir a clase. El problema no es quién puede ir, es en qué momento se rompe el hábito y por qué nadie lo nota hasta que es irreversible.
Eso se relaciona con un proyecto de escritura que tengo en curso donde queremos analizar qué es lo que hace a una clase presencial insustituible.
Te comparto un flujo de trabajo para poder trabajar con ATLASti (que me resulta muy comodo para análisis cualitativo) y convertir los resultados en el formato de tabla acordado con tu equipo de trabajo, si no quieren tablas en formarto pseudo-long (que es como lo saca Atlas-ti)
En la reunión de mi grupo acordamos un formato de matriz de este estilo (wide): una fila por cita, una columna por código, y el texto de la cita colocado en la columna que le toca.
Lo que exporta ATLAS.ti es una fila por cita con un campo multivalor: todos los códigos concatenados dentro de una celda separados por saltos de línea. Eso incumple la primera forma normal (los valores no son atómicos), así que técnicamente es una tabla no normalizada. En el vocabulario de tidyverse se le suele llamar campo anidado o colapsado, que es lo que deshace separate_rows() o unnest(). El formato “long” de verdad sería una fila por par cita-código, sin repetir el texto en columnas.
De modo que me he creado uin script de python que genera el formato wide requerido, (una matriz de incidencia cita × código, one-hot salvo que, en lugar de un uno, lleva el texto de la cita como carga. Este formato no es tidy (pero es el que acordamos). Es justo el contraejemplo canónico de Wickham: las 21 cabeceras de columna son valores de una variable (el código), no nombres de variables.
La versión tidy, que además coincide con la primera forma normal, es precisamente el long intermedio de una fila por par cita-código, con columnas ID cita, fuente, texto y código. El script lo construye y saca como hoja adicional. Así que la cadena real es: anidado → long/tidy → matriz wide.
El flujo es muy simple:
Se codifica en ATLAS.ti, que es donde tiene sentido hacerlo porque es donde están el libro de códigos, los memos, los grupos de códigos y la posibilidad de filtrar por lo que te interese (en mi caso, las citas codificadas con cualquier código de las familias C6.A o C6.B).
Se exporta el informe de citas a Excel, que sale en formato largo: una fila por cita con el identificador, la fuente, el texto, el comentario y todos los códigos apilados dentro de una misma celda separados por saltos de línea.
Y ahí es donde entra un script de Python de poco más de cien líneas que lo transpone al formato que acordamos, añadiéndolo como hoja nueva en el mismo libro para que quede la traza entre el export original y la matriz derivada.
Mi export tenía 97 citas, 54 fuentes y 21 códigos distintos, con 162 etiquetas en total (la mayoría de las citas llevan una o dos, alguna llega a cinco). El script imprime al terminar estas cifras, etiquetas en origen frente a celdas rellenas en la matriz, y si no coinciden, es que algo raro ha pasado. Es el tipo de comprobación que cuesta tres líneas de código y te ahorra descubrir el problema cuando ya llevas media tabla de contingencia calculada.
Un par de detalles que no son obvios hasta que te los encuentras. Ordenar los códigos alfabéticamente te coloca C6.B10 justo detrás de C6.B1, así que hay que ordenar por familia y número. ATLAS.ti mete dentro del texto de algunas citas un carácter separador de párrafo (U+2029) que Excel muestra como un cuadradito y que conviene traducir a salto de línea normal.
El script falló en el primer intento con un ModuleNotFoundError porque VS Code había decidido ejecutarlo con el Python que viene empotrado dentro de Inkscape. No en el mío, que está instalado en D:. En los notebooks eliges el kernel y lo ves; en un .py el intérprete está escondido en la barra de estado y no te enteras hasta que revienta.
Lo he montado con Claude, que es lo que hace que esto pase de “algún día lo automatizo” a estar funcionando en la misma tarde.
El script está en un repositorio público (pipeAtlasti-Excel, bajo AGPL-3.0) por si a alguien le sirve, aunque está bastante atado a mi esquema de códigos. La función que ordena las columnas es el único sitio que habría que tocar para adaptarlo.
El formato de matriz decidido es cómodo para revisar la codificación a ojo y para las tablas de frecuencias, pero para casi cualquier análisis posterior el formato largo es mejor punto de partida. Sospecho que dentro de dos reuniones habremos acordado volver al formato del que venimos…
Durante el curso 2025-26 hemos ido observando qué ocurre mientras nuestros-as estudiantes resuelven casos en clase, cuando intentan utilizar el Triple Diamante, para analizar problemas, identificar causas, priorizar alternativas o justificar una decisión. El resultado provisional es una red de 29 concepciones alternativas. Esta red parte únicamente de la observación no participante en vivo (nos falta aún analizar las reflexiones posteriores a la tarea que han realizado los-as estudiantes por escrito).
Muchas de esas concepciones son atajos que parecen funcionar en determinados contextos. Sin embargo, aunque no sean conscientes, la “calidad” de sus soluciones queda mermada por esas concepciones y, en otros contextos, acaban creando una trampa en la que las soluciones se ven sesgadas y, en muchas ocasiones, resultan inadecuadas.
En esta primera agrupación , hemos creado un núcleo que tiene que ver con los datos y las evidencias. Aparecen concepciones como que no es necesario medir para decidir, que si no tenemos datos podemos decidir intuitivamente, que alguien debería proporcionarnos los datos que necesitamos (aunque podríamos estimarlos, no lo hacemos) o que expresiones como “es obvio” o “me di cuenta enseguida” son suficiente garantía de que una conclusión es correcta. Relacionada con esto está la dificultad para distinguir entre hechos, inferencias, opiniones y percepciones.
Un segundo núcleo tiene que ver con cerrar el proceso de decisión demasiado pronto. Si aparece rápidamente una solución plausible, ¿para qué seguir explorando? Si todo el grupo está de acuerdo, ¿para qué buscar otras perspectivas? Si el problema parece sencillo, ¿para qué utilizar herramientas estructuradas? En esta lógica, el Triple Diamante corre el riesgo de convertirse en una forma de documentar una decisión que ya estaba tomada, en lugar de ser una ayuda para construirla.
También aparece un tercer bloque relacionado con el proceso de toma de decisiones en grupo. Por ejemplo, asumir que la alternativa más votada es necesariamente la mejor o que votar equivale a deliberar. Pero hacer estadística con las preferencias del grupo no es lo mismo que compartir información, confrontar argumentos y permitir que las personas cambien su punto de vista.
Otra agrupación aparece alrededor del procedimiento de análisis: confundir la identificación de problemas, sus causas y las alternativas de solución; interpretar los 5 porqués como una cadena obligatoriamente lineal, o asumir que todas las causas identificadas tienen la misma fuerza o impacto.
Hemos creado un último grupo relacionado con procesos de comprensión, aprendizaje (cómo emerge el conocimiento implícito y como se transoforma en explícito para poder ser gestionado en el grupo): considerar que revisar superficialmente una respuesta generada por IA equivale a analizar personalmente un problema, que subrayar es suficiente para incorporar conocimiento, que localizar una palabra clave con la función de busqueda en un “PDF” sustituye a leer y comprender un documento o, sencillamente, que haber completado una tarea demuestra que se ha aprendido o se domina un proceso.
Una interpretación provisional es que, detrás de muchas de estas concepciones, emerge una tendencia a evitar hacer explícito nuestro razonamiento. Si algo parece evidente, si encontramos pronto una solución o si el grupo alcanza rápidamente un acuerdo, dejamos de medir, contrastar, explorar alternativas o explicar por qué hemos llegado a esa conclusión.
Si esta interpretación se confirma, enseñar pensamiento crítico no consistirá solo en explicar mejor las herramientas. Tendremos que diseñar situaciones que hagan visible el razonamiento implícito, pidiéndoles evidencias, que contrasten inferencias alternativas, que trabajen con datos incompletos, y que se pregunten ¿por qué?
La idea es utilizar “thinking aloud” para descubrir qué está ocurriendo mientras se toma la decisión y comprobar si eso, además, les ayuda a tomar conciencia de sus concepciones y cambiarlas.
Dudaba si titular esta entrada como “The Book of Why y la madre que lo parió”.
Empecé a leer el libro a mediados de julio de 2026 como una lectura curiosa que fue despertándome dudas, inquietudes, posibles propuestas de para qué me serviría el operador “do(X)”… Y poco a poco, la sensación de incomodidad, incultura y casi desesperación fue invadiéndome a medida que avanzaban las páginas.
He acabado de leer el libro, no he entendido casi nada, pero creo que me he reconciliado con la curiosidad y ahora tengo ante mí un arduo camino para intentar llegar a alguna comprensión a partir de esta lista de referencias, un montón de páginas que no se cuántos meses o años tardaré en digerir:
Pearl, J. (2014a). Interpretation and identification of causal mediation. Psychological Methods, 19(4), 459–481. https://doi.org/10.1037/a0036434
Pearl, J. (2014b). Reply to commentary by Imai, Keele, Tingley, and Yamamoto concerning causal mediation analysis. Psychological Methods, 19(4), 488–492. https://doi.org/10.1037/met0000022
Pearl, J., Glymour, M., & Jewell, N. P. (2016). Causal inference in statistics: A primer (Reprinted with revisions). Wiley.
Pearl, J., & Mackenzie, D. (2018). The book of why: The new science of cause and effect (First trade paperback edition). Basic Books. (Bib UPV B 0-16/01514).
Tennant, P. W. G., Murray, E. J., Arnold, K. F., Berrie, L., Fox, M. P., Gadd, S. C., Harrison, W. J., Keeble, C., Ranker, L. R., Textor, J., Tomova, G. D., Gilthorpe, M. S., & Ellison, G. T. H. (2021). Use of directed acyclic graphs (DAGs) to identify confounders in applied health research: Review and recommendations. International Journal of Epidemiology, 50(2), 621–632. https://doi.org/10.1093/ije/dyaa213
Textor, J., van der Zander, B., Gilthorpe, M. S., Liśkiewicz, M., & Ellison, G. T. (2016). Robust causal inference using directed acyclic graphs: The R package ‘dagitty.’ International Journal of Epidemiology, 45(6), 1887–1894. https://doi.org/10.1093/ije/dyw341
VanderWeele, T. J. (2015). Explanation in causal inference: Methods for mediation and interaction. Oxford University Press.
VanderWeele, T. J. (2016). Explanation in causal inference: Developments in mediation and interaction. International Journal of Epidemiology, 45(6), 1904–1908. https://doi.org/10.1093/ije/dyw277
Bini, G., & Quattrociocchi, W. (2026). Epistemia in the classroom: The problem of evidence of understanding in education in the age of generative AI. AI And Society. https://doi.org/10.1007/s00146-026-03227-y
Tenemos un listado provisional de 21 concepciones alternativas detectadas. Tres se conectan directamente con este artículo:
Revisar superficialmente una respuesta generada por IA produce un aprendizaje equivalente al análisis personal
Subrayar información es suficiente para incorporarla al conocimiento propio
Tomar notas consiste principalmente en copiar o extraer fragmentos relevantes
Damos por hecho que alguien ha entendido cuando lo que dice suena bien. Eso pasaba mucho antes de que existiera la IA generativa (es un caso documentado por Erlwanger desde los años setenta). Se trata de una tendencia cognitiva anclada en mecanismos reforzados a lo largo de todo el proceso evolutivo de la especie humana.
Un fragmento que nos resulta muy útil es este:
“these interventions point towards a shift from the production of texts to their critical interrogation, understood as the ability to question claims, test arguments, compare frameworks, identify limits, confront outputs with independently grounded knowledge, and ultimately assume responsibility for what is asserted.” (Bini y Quattrociocchi, 2026, p. 9)
Este será el objetivo de la observación participante en directo en los grupos para poder capturar el proceso.
Cuestionar algo solo es posible si ya tienes una base de conocimiento suficiente y familiaridad con las fuentes para reconocer referencias con sentido, formular preguntas y detectar lo que falta. Que es justo lo contrario de lo que se asume cuando se dice que con la IA ya no hace falta saber porque todo el conocimiento está accesible en los chats. Cuanto más parece que el sistema reduce la necesidad de producir conocimiento por tu cuenta, más se necesita ese conocimiento para ser usado críticamente. El saber no desaparece; se recoloca como recurso para cuestionar en vez de ser un fin en sí mismo (no es reproducción, es comprensión, pero para comprender necesitas tener una memoria a largo plazo densamente poblada). Esto me viene bien para reforzar los argumentos sobre qué es aprender, que llevo repitiendo en varios foros y charlas durante el último año.
El objetivo del PIME-DECIDE es fomentar el pensamiento experto basado en evidencia en las personas graduadas en Ingeniería de Organización. Medir eso es complicado y aún no contamos con un instrumento fiable. Mientras, usaremos soluciones provisionales para ir informando del progreso, con las limitaciones que eso implica y asumiendo que habrá que tirar a la basura alguna de esas soluciones en el futuro.
El artículo es una contribución teórica, y sus autores lo dicen abiertamente. Una de las cosas que piden es precisamente comprobar si las intervenciones que hacen visible cómo se genera el producto y guían su cuestionamiento logran fomentar el aprendizaje. Eso es más o menos lo que vamos a intentar en el PIME-DECIDE el próximo curso 2026-27.
Analizar contenido cualitativo consiste en crear un árbol de códigos y temas, definirlos y organizarlos. Para ello hace falta tener criterio, y el criterio se construye codificando a mano un montón de material, equivocándote y volviendo atrás. ¿Qué le digo a alguien que va a hacer su primer análisis cualitativo con un LLM al lado desde el minuto uno? La respuesta actual es “que primero aprenda a hacerlo sin”. Pero no sé si eso va a seguir siendo posible (o tendrá sentido) dentro de unos años.
Susanne Friese ha expresado en un post (ver referencia abajo) algo que llevo años comentando. El peligro de usar IA para codificación automática es que un código se acepte porque suene bien, un tema se quede porque se lea bien, y que el apartado de resultados acabe organizándose alrededor de un relato que propuso el modelo, no se sabe muy bien en base a qué, pero que resulta convincente porque está lingüísticamente bien construido.
Es cierto que en algunas aplicaciones se puede hacer “minería de datos”. Si los códigos y sus significados están claramente establecidos, se pueden etiquetar fragmentos que encajen con esos códigos. Es más, se podría tener una métrica de “proximidad” entre el fragmento y cada uno de los códigos.
Eso no resuelve quién decide qué constituye un fragmento (chunk). A veces lo que tiene sentido es una frase, otras es el párrafo entero, y no es sencillo entrenar un algoritmo que haga esto bien de manera universal, aunque se podría entrenar para usos o corpus específicos o con ciertas características. Por ejemplo, si estás etiquetando mensajes de Twitter (X) o Bluesky, donde tienes unos 300 caracteres como máximo, quizás el mensaje entero es “el fragmento”. Pero en textos largos, o no excesivamente bien puntuados (comas, puntos y coma, puntos), puede ser complejo de automatizar.
Si queremos que el análisis que hacemos esté justificado por los datos y por un marco de referencia, no podemos confundirlo con “esto tiene sentido cuando lo leo” (que es lo que nos puede dar la IA). La trampa es que la IA te devuelve un texto que está (MUY) bien escrito, casi siempre tiene sentido cuando lo lees, y eso le da una apariencia de convincente.
En la mayoría de los casos, el significado no está enterrado en la transcripción esperando a que alguien lo extraiga. No se mina. Se construye con las preguntas que te haces o decides no hacerte, con la lente teórica desde la que miras, y con todo lo que te llevaste del contexto y que nunca entró en la grabación o el texto que estás trabajando. El silencio de tres segundos antes de responder. La persona que estaba delante y no dijo nada. El hecho de que la entrevista fuera en el despacho del jefe…
Se atribuye a Miguel Ángel la frase «La escultura ya estaba dentro de la piedra; yo, únicamente, he debido eliminar el mármol que le sobraba». Es una frase ingeniosa (y falsa) y en el análisis cualitativo pasa lo mismo.
Esto no significa que no haya usos donde la IA pueda ayudar. Susanne sugiere que proponga una lectura alternativa de un fragmento, que me señale un patrón que no había visto, y sobre todo, que me busque el pasaje que contradice un tema (que siempre hay uno, y que uno tiende a no encontrar precisamente porque acabas un poco contaminado por los datos).
