Sistemas Duros y Sistemas Blandos: la Metodología SSM

Esta guía asume que ya viste Modelado de Sistemas: Diagramas Causales y Dinámica de Sistemas y Cibernética Avanzada: Variedad y Viabilidad de los Sistemas. No los vuelve a explicar: los va a usar directamente como el ejemplo de referencia de "pensamiento de sistemas duros", para contrastarlos contra algo nuevo.

Al finalizar esta guía vas a poder distinguir cuándo un problema pide pensamiento de sistemas duros y cuándo pide pensamiento de sistemas blandos, y vas a poder aplicar las herramientas centrales de la Metodología de Sistemas Suaves (SSM) de Peter Checkland —rich pictures, definiciones raíz con CATWOE, modelos conceptuales, y la comparación que separa cambios deseables de cambios factibles— para estructurar el debate en una situación organizacional real, ambigua y sin una única solución correcta.

No se trata de que lo duro esté anticuado y lo blando sea superior. Se trata de usar la herramienta correcta según el tipo de situación: reducir la latencia de un servicio, o corregir la estructura de un sistema viable según el VSM, son problemas duros — hay criterios objetivos para saber si la solución es mejor o peor. Decidir si una universidad debería priorizar investigación o docencia, cuando docentes y directivos ni siquiera coinciden en qué significa "calidad", es un problema blando: no hay ningún criterio técnico que zanje esa discusión.

El cambio de nombre no es casual. Checkland dejó de hablar de "ingeniería de sistemas" (diseñar "el" sistema correcto para un objetivo dado) y empezó a hablar de metodología de sistemas: un proceso flexible de aprendizaje que ayuda a las propias personas involucradas a estructurar el debate y decidir, entre ellas, qué cambios tienen sentido. En 1981 publicó Systems Thinking, Systems Practice, documentando esa década de investigación-acción y formalizando el SSM.

No tiene notación estándar ni oficial — cada practicante desarrolla su propio estilo — pero típicamente combina: figuras simples para las personas y roles involucrados, símbolos de estructura para procesos y recursos, líneas de relación entre ellos, un símbolo de "espadas cruzadas" en los puntos de conflicto o tensión, y globos de diálogo o signos de interrogación para opiniones, quejas o confusiones que la gente expresa sobre la situación.

Un diagrama de bucle causal ya asume qué variables importan y cómo se relacionan entre sí: es, en sí mismo, una herramienta de pensamiento duro. Una rich picture se dibuja antes de decidir eso, precisamente porque en una situación blanda ese "qué importa" es parte de lo que está en disputa entre los involucrados — decidirlo demasiado pronto sería imponer una sola visión sobre las demás.

CATWOE es una mnemotecnia con seis elementos que toda definición raíz sólida debería poder responder. No es un formato rígido de redacción: es una lista de verificación para no dejar afuera algo esencial.

Dos personas pueden describir casi la misma transformación T con una W distinta, y ahí es exactamente donde aparece el desacuerdo blando. "Clasificar tickets por orden de llegada" y "clasificar tickets por impacto en el cliente" son dos definiciones raíz con una T parecida pero una W distinta — y esa diferencia de cosmovisión suele ser el verdadero conflicto detrás de una situación confusa, no la transformación en sí.

"Un sistema, operado por los agentes de soporte técnico de NubeFácil (A), propiedad de la gerencia de Operaciones (O), que transforma solicitudes de ayuda sin clasificar (entrada) en solicitudes resueltas según su urgencia real para el negocio, y no según el orden de llegada (salida), en beneficio de los clientes afectados (C), dado el sistema de tickets y el personal ya disponibles (E), porque se cree que la urgencia del impacto en el cliente debe determinar el orden de atención, no quién preguntó primero (W)."

1. Recibir la solicitud sin clasificar. 2. Evaluar su impacto potencial en el cliente. 3. Asignar un nivel de urgencia. 4. Priorizar la cola según urgencia, no según orden de llegada. 5. Asignar un agente disponible. 6. Resolver la solicitud. 7. Confirmar la resolución con el cliente. 8. Monitorear si la urgencia asignada correspondió con la urgencia real, y ajustar el criterio de asignación si no.

La última actividad de un modelo conceptual suele ser de control, y para eso Checkland propone monitorear tres criterios: eficacia (¿la transformación logra el resultado buscado?), eficiencia (¿lo logra con el mínimo de recursos razonable?) y efectividad (¿ese resultado vale la pena a largo plazo, para el objetivo de más arriba?). Un sistema puede ser eficiente sin ser eficaz, y eficaz sin ser efectivo — las tres preguntas son distintas.

Un cambio es sistémicamente deseable cuando el modelo conceptual y la comparación lo justifican: "esto debería existir, según la lógica de la transformación que definimos". Un cambio es culturalmente factible cuando es aceptable dado el poder, las relaciones y la cultura reales de esa situación específica: "esto se puede hacer con esta gente, en este momento, sin romper algo más importante". Un cambio solo se lleva adelante si es ambas cosas a la vez.

ClaseViva es una startup edtech de tres años que provee una plataforma de evaluaciones para colegios. Los fundadores presionan por lanzar funciones nuevas cada semana para no perder terreno frente a la competencia. El equipo pedagógico insiste en que cada función nueva debería validarse pedagógicamente antes de salir, porque una función mal diseñada puede afectar la evaluación real de estudiantes. Soporte recibe quejas constantes de docentes que no entienden funciones lanzadas sin previo aviso. Cada área describe "el problema" de forma distinta — y las tres tienen razón desde su propia Weltanschauung.

Al comparar el modelo conceptual con la realidad, queda claro que hoy ninguna función pasa por validación pedagógica antes de salir a producción: se valida, a veces, después del lanzamiento, si sobra tiempo. Los fundadores proponen dos cambios posibles: (A) exigir validación pedagógica obligatoria antes de cualquier lanzamiento, sin excepción; (B) crear una validación exprés de 48 horas, obligatoria solo para funciones que tocan la evaluación de estudiantes, y opcional para el resto.