METODOLOGÍA DE LOS SISTEMAS SUAVES

Teoría de Sistemas Universidad Autónoma del Perú Ing. Heyner Ninaquispe Castro

METODOLOGÍA DE LOS SISTEMAS SUAVES

LA METODOLOGÍA EN GENERAL

Los estudios de sistemas que fueron el contenido de la investigación

enfrentaron problemas pequeños y problemas grandes, se basaron en

organizaciones tanto pequeñas como grandes, y en organizaciones públicas

como privadas.

Si el pensamiento de sistemas “suaves” se reduce al método, este

fracasará porque eliminará mucha de la variedad munífica que observamos en

la vida real. Una metodología es intermedia en el estatus entre una filosofía, y

una técnica o un método. Una filosofía será una pauta no específica (amplia)

para la acción. Una técnica es un programa de acción específico y preciso que

generará un resultado estándar. Donde una técnica indica el “cómo” y una

filosofía indica el “qué”, una metodología contendrá elementos tanto de “qué”

como de “cómo”.

Es una metodología en la que se puede acomodar una exploración de la

importancia o de las implicaciones de adoptar una postura particular en

relación con la situación problema. Se infirió en forma experimental en el año

1979 y representa el aprendizaje alcanzado en un gran número de proyectos de

“investigación en la acción”. Se basa en el paradigma del “aprendizaje” y no

en el de la “optimización”. Este cambio ha sido necesario dado el aumento de

la preocupación por los problemas mal estructurados (suaves), para los que no

existen respuestas optimizadas o “correctas”.

RESUMEN

La metodología puede describirse como un proceso de siete etapas o estadios

de análisis que emplean el concepto de un sistema de actividad humana como

un medio de conseguir tanto “investigar” (diagnosticar) la situación como

“efectuar acciones” (direccionar e implementar) para mejorarla.

La secuencia lógica ilustrada en la figura es una manera útil de describir

la metodología pero no necesariamente representa la secuencia en que se usa.

En realidad representa un patrón de actividades. El analista puede empezar


con una actividad, progresar en alguna dirección y usar una iteración

significante en cualquier etapa. En trabajos recientes se ha proporcionado

pruebas de que es posible el iniciar un proyecto en el estadio 4, por ejemplo; y

en principio, un inicio se puede hacer desde cualquier punto. La iteración y la

exploración en reversa son esenciales. En un estudio real el analista mas

diestro está trabajando simultáneamente, en diferentes niveles de detalle, en

distintos estadios.

Análisis

PATCRW

Consideración

de otros

sistemas

Situación del

problema : no

estructurado

1

Acción para

resolver el

problema o mejorar

la situación7

Definición de los

cambios

deseables sistémicamente y

factibles (viables)

culturalmente6Situación del

problema :

expresado2

Comparación

de 4 con 2

5

Definiciones raíz de

los sistemas relevantes

3

Modelos

Conceptuales4

REALIZACION DE ACCIONES

Mundo Real

Consideración del mundo Real como

sistemas

Concepto del modelo

formal de sistemas4a4b

3a

La metodología incluye dos tipos de actividades. Los estadios 1, 2, 5, 6

y 7 son actividades del “mundo real” que necesariamente involucra gente en la

situación problema; los estadios 3, 3.a, 4, 4.a y 4.b son actividades del

“pensamiento de sistemas”. La línea punteada representa el límite entre la

actividad que está en el mundo real y la actividad relacionada con el uso de los


conceptos de sistemas para estructurar la consideración acerca del mundo real.

Por encima de la línea, la descripción de la situación está en lenguaje

cotidiano, mientras debajo de la línea estará en lenguaje de sistemas (o

metalenguaje).

Los estadios 1 y 2 son una fase de “investigación” y “expresión”

durante la cual se hace un intento por construir la imagen mas rica posible

(cuadro pictórico), no del “problema” sino de la situación en la cual se percibe

que hay un problema. El estadio 3 entonces involucra el nombrar algunos

sistemas que parece pudieran ser pertinentes al problema y el presentar

definiciones concisas de lo que estos sistemas son (investigación causal-

descriptiva) o deberían ser (investigación solucionadora). El objetivo es

obtener una formulación explícita cuidadosamente fraseada de la naturaleza de

algunos sistemas que subsecuentemente se van a considerar como pertinentes

para mejorar la situación problema. Estas definiciones en el estadio 3 se

denominan “definiciones raíz” (hipótesis, en el método científico). Una forma

de verificar la correcta estructuración de la definición raíz es realizar un

análisis PATCRW (CATWOE).

Dada esta definición, o aun estas definiciones, el estadio 4 consiste en la

creación de modelos conceptuales de los SAH nombrados y definidos en la

definición raíz. Se ensambla un grupo estructurado de verbos, que describen a

las actividades mínimas necesarias requeridas en un sistema de actividad

humana que corresponde con la que se describió en la definición raíz. La

construcción del modelo se alimenta en los estadios 4a y 4b. 4a consiste en el

uso de el modelo formal de sistemas que se usa para verificar que los modelos

construidos no sean deficientes; 4b consiste en la modificación o

transformación del modelo, si se desea, adquiriendo cualquier otra forma que

quizá se pueda considerar adecuada en un problema particular. Por ejemplo

expresar un problema en el lenguaje de la dinámica de sistemas.

Los modelos del estadio 4 se introducen en el estadio 5, en “el mundo

real” y se confrontan con las percepciones de lo que existe ahí. El propósito de

esta “comparación” es generar un debate con gente interesada en la situación

problema que, en el estadio 6, definirá posibles cambios que simultáneamente

satisfagan dos criterios: que son cambios deseables sistémicamente y al mismo


tiempo viables culturalmente. El estadio 7 involucra llevar a cabo la acción

basada en el estadio 6 para mejorar la situación problema. Esto de hecho

define “un nuevo problema” y a éste también quizá ahora se le enfrente con la

ayuda de la metodología.

ENFOQUES DE DESARROLLO

La MSS puede usarse desde dos enfoques: proactivo (anticipatorio) y reactivo.

Proactivo: Con la MSS se busca situaciones problemáticas, luego priorizamos

su tratamiento, y finalmente, con la misma MSS lo aliviamos. Esto

corresponde a una investigación cuyo régimen es libre.

Reactivo: Una vez identificado una situación problemática, aplicamos la MSS

para aliviarlo. Para este caso el régimen de la investigación es

orientado.


1° Problemas

(a) Reactivo (b) Procativo

Podemos hacer una analogía entre los estadios de la MSS (sistémico)

con las etapas del PEN (científico).

PEN MSS

Diagnóstico Estratégico Estadio 1 y 2

Direccionamiento Estadio 3, 4, 5 y 6

Implementación Estadio 7

Etapa 1 y 2: investigación y expresión

Esta etapa la entiende generalmente la gente que usa la metodología, estos son

en la práctica estadios difíciles. La gente a menudo muestra un deseo urgente

de llevar a cabo la acción. Los mejores estudios se han caracterizado por

detenerse en los estadios 1 y 2; por coleccionar tantas percepciones del

problema como sea posible a partir de un amplio rango de gente con diversos

roles en la situación problema.

1° Problema

INFRAESTRUCTURA

INFRAESTRUCTURA

2° MSS

1.

Situación

problema no

estructurada

2.

La situación

problema

estructurada

Cuadro Pictórico

Diagnóstico Situacional

Cartera de Negocios

Valores Estratégicos

Microcosmos

Cadena de Valor

Matriz PAF

Análisis Interno

Análisis Externo

Fuerzas Externas

Fuerzas competitivas

Matriz POAM

Sistemas Relevantes (Pertinentes)

Mundo

Real

Observador

(propósito)


Se relacionan con investigar la situación. El estadio 1. es una

declaración de lo que hace la situación problemática y algunos hechos básicos

acerca de ella. Esto tendrá que proporcionarlo alguna persona, o grupo de

personas de acuerdo a algunas Ws mediante encuestas y entrevistas. Parte de

esta etapa será intentar identificar lo que estas Ws podrían ser y descubrir

cuáles otras Ws podrían también ser importantes. El analista debe tener

cuidado de no imponer su propia W sobre la situación. Lo difícil es intentar

ser neutral.

Las técnicas de investigación mencionadas anteriormente deben ser aplicadas

con reuniones DCA y reforzadas con:

Un proceso de benchmarking

Acceso a internet

Revisión de documentos de la empresa

Revisión de libros, revistas, tesis

Percepción del desempeño de los trabajadores

Conversación informal con los trabajadores

Know_how de un consultor externo.

La función principal de los estadios 1 y 2 es el exhibir la situación de

forma que se pueda revelar un rango de selecciones posibles y con suerte

pertinentes, esa y sólo esa es la única función de dichos estadios.

Según Checkland: las tapas 1 y 2 son una fase “de expresión”, durante

la que se intenta construir la imagen (cuadro pictórico) mas rica posible, no

del “problema” sino de la situación en la que se ha percibido un problema.

Una guía en este punto se muestra en la figura:


La situación problema existirá con ciertos medio ambientes (por

ejemplo el resto de las áreas funcionales) y sistemas amplios con los cuales

interactúa (microcosmos). El análisis de esta situación problema debe darse

mediante el registro de elementos con estructura de cambio lenta, dentro de la

situación y elementos de proceso de cambio continuo, y constituyendo una

visualización de cómo la estructura y el proceso se relacionan en la situación

que se investiga. A esta relación se llama clima (contexto o microcosmos y/o

diagnóstico estratégico).

Los elementos de la estructura se definen como aquellas características

relacionadas con la distribución física (infraestructura), la jerarquía de poder

(organigrama), los valores estratégicos y el patrón de comunicaciones

formales e informales. El proceso se relaciona con las actividades en proceso,

de conversión de materia prima en productos, planeamiento para hacer algo,

operación, monitoreo de ambos, toma de decisiones, control, etc.

Medio ambiente(s), Sistemas amplios (SAH)

La Situación Problema, parte del SAH

Estructura Procesos

Planeamiento

Operación

Monitoreo y

Control

Físico

Jerárquico

Reporte

Comunicación

Cuál es la relación entre la

“estructura” y los “procesos”?

Cuál es el clima?

Materia

Energía

Información

Presiones

Influencias


El analista no puede ser neutral. Las preguntas respondidas (ver Formato

de Encuesta) se regirán por alguna W inherente. Esto conduce a preguntas

respecto con las siguientes características (Análisis Externo):


Clientes

Proveedores

Competencia

Competencia Potencial

Productos Sustitutos

Entidades Financieras

Organismos Gubernamentales, etc.

Y además preguntas relacionadas a la situación interna y externa de la

empresa (Análisis Situacional):

Fortalezas

Debilidades

Oportunidades

Amenazas

Es cuestión de juicio seleccionar sistemas relevantes (pertinentes) al

análisis, el analista aprenderá de la efectuada y le será posible cambiarla

basándose en el aprendizaje que ocurra después. No importa cuando se pasa

de la etapa 2 a la 3 pero el buen analista de sistemas es quien logra que los

sistemas que elige se vuelvan relevantes.

Un problema es definir quién en la organización, es el mejor individuo

(o el mejor grupo de individuos) para ser el destinatario de las preguntas. El

organigrama de la organización puede ser el lugar obvio para empezar.

También puede usarse el criterio de elegir una persona (sistema relevante) de

cada uno de los niveles jerárquicos, definidos por Anthony, o que pertenezca

al sistema de valor (Microcosmos o Micromundo o Stakeholders).

Cliente

Proveedor

Otro

Operativo

Gerencial

Administrativo

Sistema de Valor

Empresa


Al seleccionar los sistemas pertinentes el analista sólo puede juzgar que

su elección se volverá útil. Luego pueden seleccionarse los mejores candidatos

para el desarrollo del modelo y construirse las definiciones raíz usando la

prueba (análisis) CATWOE.

Lo que un administrador considera que tiene la suficiente importancia

para decirlo durante una entrevista (a diferencia de responder a la pregunta

directa) dice algo de su W. Esto puede ser importante para la definición raíz

posterior y para el desarrollo del modelo.

La dirección en que avanza el desarrollo del modelo se determina por

las respuestas hechas y lo dicta la situación misma. Los modelos pueden

producirse con rapidez y no necesitan tener un alto grado de detalle para ser

útiles. Proporcionan las bases para un conjunto estructurado y coherente de

entrevistas.

Los administradores son gente ocupada y tienen una cantidad limitada

de tiempo disponible. Un conjunto de entrevistas bien planeadas ayuda a usar

mejor este tiempo y a establecer la credibilidad en el analista y confianza entre

éste y los administradores. Esto es importante para etapas posteriores de un

proyecto si debe propiciarse una disponibilidad de cambio para que puedan

aceptarse las recomendaciones.

Una de las preguntas mas frecuentes y mas difíciles de responder, con

respecto a esta etapa, es “¿cómo se sabe cuando se ha investigado lo suficiente

para pasar a la siguiente etapa, por ejemplo para seleccionar un sistema

relevante?”. La única respuesta realista es que no se sabe. Uno nunca termina

de investigar durante un proyecto. La metodología misma es un sistema de

aprendizaje y, por lo tanto, el aprendizaje continua. El análisis podría

considerarse completo cuando las siguientes preguntas se puedan responder

con certeza y rigurosidad:

¿Cuál(es) es(son) la situación(es) caracterizada(s) por una condición de

desajuste?


¿Qué actividades se llevará a cabo para aliviar la condición

problemática?

¿Qué recursos están distribuidos en qué procesos operacionales bajo qué

procedimientos de planificación con qué estructura, en qué entornos y

sistemas amplios, por quién?

¿Cómo es monitoreado y controlado esta distribución de recursos?

¿Cuáles son las limitaciones (internas y externas) que dificultan el alivio

de la condición problemática?

Hecho este análisis se desarrolla un cuadro pictórico y una definición raíz de

los sistemas relevantes.

Etapa 3: definiciones raíz de sistemas pertinentes (selección)

En el estadio de expresión hemos identificado los sistemas que

necesitan ingenierarse o mejorarse. Debemos escribir y discutir una

descripción precisa de la naturaleza del sistema o sistemas elegidos.

En esta etapa el analista está en posición de usar el lenguaje de sistemas

como un medio de explorar las implicaciones de las visualizaciones elegidas.

Los mejores pensadores de sistemas estarán en este estadio verificando

rápidamente varias posibilidades al ver a futuro los estadios 4,5 y 6 y al ver

qué tipo de modelo seguirá a partir de las definiciones raíz aceptadas y qué

tipo de cambios probablemente emerjan cuando los modelos se examinen

junto con lo que existe en el mundo real.

Las definiciones raíz tienen así el estatus de hipótesis pertinentes al

mejoramiento eventual de la situación problema (hipótesis solucionadora) por

medio de cambios habilitados que sean “viables” y “deseables”.

3.

Definiciones Raíz

de sistemas

pertinentes

Definiciones Raíz

Cuadro

Pictórico

Estadio

1


El analista no intenta definir un sistema que debe existir (hipótesis

descriptiva). Producir varias definiciones raíz ayudará a evitar un análisis

utópico esperado en esta etapa. El analista está elaborando definiciones raíz de

sistemas que sean relevantes (pertinentes), es decir, importantes para producir

ideas. Una definición raíz debe por ello ser una descripción concisa de un

sistema de actividad humana que capture una visión particular de éste. Una

definición raíz no tiene que ser muy ingeniosa para ser útil.

Las definiciones raíz deben expresar de manera clara una

Weltanschauung particular. A menudo es útil incluir un número de

restricciones en la definición raíz.

Validación de la Definición raíz

El conjunto de conceptos relacionados con el modelo formal de

sistemas, proporciona una manera de verificar si el modelo conceptual, una

vez desarrollado, es un modelo defendible de SAH. ¿Qué ayuda puede darse

durante la etapa de la definición raíz (DR) para decidir si la definición es

“buena” o no. D. Smith, examinó varias definiciones raíz usada en proyectos

anteriores considerados exitosos, en el sentido en que los clientes estuvieron

de acuerdo en que se habían alcanzado resultados útiles a partir de los

proyectos. Entonces él se hizo la pregunta “¿Tienen estas definiciones raíz

elementos comunes o con características identificables que sean trasladables

de una definición raíz a otra?”. El resultado de esta interrogante fue un

conjunto de elementos que pueden usarse para probar una definición raíz. No

le indican si la definición raíz es buena en el sentido de utilidad, le indican si

la definición raíz está bien formulada. Estos elementos se resumen como un

conjunto de letras que pueden recordarse en el mnemotécnico PATCRW.

Consideraciones Amplificación

1) “Posesión” (P) Posesión del sistema, control, interés o patrocinio; un

sistema mas amplio que puede explicar el sistema.


2) “Actor(es) (A) Los agentes que realizaron u ocasionaron que se

realizara, el(los) proceso(s) de transformación o las

actividades del sistema.

Quien lleva a cabo la actividad con propósito

definido.

3) “Transformación” (T) El núcleo de la DR; un proceso de transformación

realizado por el sistema; asumido para incluir el

objeto directo del(de los) verbo(s) de la actividad

principal.

4) “Cliente” (C) Cliente (de la actividad), beneficiario o víctima del

subsistema, afectado por la(s) actividad(es)

principal(es); el objeto indirecto del(de los) verbo(s)

de la actividad principal.

5) “Restricciones del Imposiciones ambientales; tal vez interacciones con

ambiente y del siste sistemas mas amplios que el mencionado en el

concepto ma mas amplio” (R) (1) anterior, tomándolos como datos.

A esta lista se añade el sexto ítem que rara vez aparece en una definición raíz

pero siempre está implícito y es relevante

Según Checkland:

El núcleo de una definición raíz de un sistema será un proceso de

transformación (T), es decir, los medios por los cuales las entradas definidas se

transforman en salidas definidas. La transformación incluirá el objeto directo de los

verbos de actividad principal que se requieren subsecuentemente para describir el

sistema. Habrá posesión (O) del sistema, alguna mediación que tenga un interés

primario en el sistema y el poder último para ocasionar que el sistema deje de

existir. Los poseedores pueden argumentar acerca del sistema. Dentro del sistema

6) “Weltanschauung” (W) El marco de trabajo no percibido o dado por

sentado, el cual hace significativa esta DR

particular.


mismo habrá actores (A), los agentes que llevan a cabo o que ocasionan que se

lleven a cabo las actividades principales del sistema, especialmente su

transformación principal. Dentro y (o) fuera del sistema habrá lo que denominamos

consumidores (C) del sistema, beneficiarios o víctimas afectados por las actividades

del sistema. Los "consumidores" serán objetos indirectos de los verbos principales

empleados para describir al sistema. En quinto lugar, habrá restricciones del medio

(E) en el sistema, características de los medios del sistema y (o) sistemas más

amplios que éste tiene que asumir como "dadas'.

A estos seis elementos que se describen en una definición raíz bien formada

se les recordará mediante el nemónico CATWOE.

Este conjunto de elementos representa una lista de verificación útil

contra la que puede probarse una definición raíz. Su utilidad estriba, no en

asegurar que cada elemento se encuentra en la definición, sino en asegurar

que, si uno se omite, se ha hecho de manera consciente. Puesto que un

concepto básico de un SAH es un proceso de transformación, debe estar

presente el elemento T. También, a causa de que la definición sólo tiene

sentido desde un punto de vista particular, debe ser posible identificar la W

que le da sentido. Todos los otros elementos pueden incluirse o excluirse, en

base si son importantes o no, de acuerdo con el juicio del analista. El elemento

que con mayor frecuencia se omite es la primera A, puesto que su inclusión,

por lo general, restringe el sistema a ser particular o no a una área particular de

actividad del mundo real. De acuerdo con nuestra experiencia se puede

obtener más significado de una situación, si, digamos, el límite de un sistema

de mercadotecnia no se iguala con el límite organizacional de un

departamento de mercadotecnia. Hay peligro de introducir en forma

innecesaria una restricción si se especifica A (en el ejemplo anterior) como los

miembros del departamento de mercadotecnia.


Ejemplo

En un estudio realizado, el tema de investigación fue la operación de una

actividad particular voluntaria del hospital, la de visitar enfermos mentales. La

definición raíz tomada en ese estudio fue:

En esta definición raíz los “clientes” se especifican con claridad como

enfermos mentales del hospital. Los “actores” son los estudiantes voluntarios

y la “transformación” es para proporcionar “ayuda”. Se especifican algunas

restricciones ambientales (por ejemplo, aspectos del sistema que el proceso de

toma de decisiones no puede cambiar). La actividad debe ser regular; los

estudiantes tienen que ser voluntarios; y la operación completa debe estar

aprobada por los médicos, no obstante, no se especifica “el propietario” y, por

lo tanto, la W es ambigua. Puede establecerse como “la ayuda” proporcionada

mediante este tipo de actividad del estudiante. No obstante, también puede

interpretarse como que la visita al hospital proporciona una forma de

autosatisfacción a los estudiantes voluntarios; o como que la ayuda gratuita es

una manera justificable de reducir las cargas de trabajo de los que ejercen

como doctores. En este caso, hubiera sido útil, eliminar la ambigüedad

especificando el propietario.

Este ejemplo particular, ilustra que es posible construir tres definiciones

raíz que contenga de manera exacta el mismo proceso de transformación pero

basadas en tres diferentes Ws.

Aparte de ser una prueba útil de una definición raíz, el PATCRW

también es la formulación de la definición. No obstante, una vez formula la

definición raíz, debe probarse para asegurarse que representa lo que se

pretendía.

Un sistema de ayuda regular con estudiantes voluntarios, aprobado

médicamente para pacientes del hospital mental.


Fallas que deben evitarse

1) Debe recordarse que el lenguaje de sistemas descrito hace posible que un

analista forme su opinión acerca de una situación explícita del mundo real.

No es una manera de describir lo que existe sino la manera de describir una

interpretación de lo que existe o alguna consideración en relación con lo

que existe. Por lo tanto, los errores comunes están relacionado con la

confusión asociada a esta situación. Debe recordarse, al construir

definiciones raíz, que la definición se relaciona a un sistema. En un

ejercicio usado en el curso en Lancaster, el objeto de interés es una taberna

inglesa. Se produce con frecuencia definiciones raíz que empiezan con la

frase: “Una taberna es una construcción ....” esto en seguida da a la

definición la forma de una descripción de lo que existe. No podemos

establecer lo que es una taberna, sólo podemos establecer lo que es el

sistema que estamos definiendo. Por lo tanto, una definición raíz en relación

con una taberna podría empezar así: sistemas operados por un tabernero que

posee cerveza para... Resulta evidente que éste es sólo un ejemplo entre

muchos; sin embargo en una definición raíz estamos definiendo un sistema,

así que llamémosle sistema.

2) Algunas veces se producen definiciones raíz que intentan ser definiciones

mixtas. La idea detrás de esto es que, puesto que la situación del mundo real

es una combinación de Ws y procesos de transformación, necesita producir

una definición que refleje esta combinación. Pero recordemos que el

análisis de sistemas que estamos haciendo es un intento de estructurar una

situación no estructurada mediante una simplificación de la complejidad y

no un intento de reflejarla. Por lo tanto, una definición raíz debe contener

un proceso de transformación y debe comprometerse en forma total con una

sola W. Debe enfatizarse que la definición raíz es una descripción de lo que

el sistema es (descriptiva) o debe ser (solucionadora) y el modelo

conceptual es una descripción de lo que debe hacer para ser ese sistema.

Por consiguiente, el objetivo debería ser para un solo proceso de

transformación. No obstante, en la práctica, puede ser necesario proceder

con una definición raíz en la que hay más de una T.


3) Todo el proceso de análisis de PATCRW se relaciona con la identificación

de lo que se establece en la definición raíz, no es un mecanismo para

ampliar de manera inconsciente la definición. Si el análisis de PATCRW ha

señalado ciertos elementos y éstos se consideran importantes, entonces la

definición raíz se modificaría para incluirlos:

Después de todo, es la definición raíz la que está en proceso de

modelado.

4) El lenguaje de sistemas descrito lo forman, en esencia, dos ideas

vinculadas: la definición raíz y el modelo conceptual. Este es el par de ideas

importante. Una falla común, en particular durante el intento inicial de usar

este lenguaje, es la producción de definiciones raíz dispersas que llevan

modelos conceptuales dispersos.

Referirse de nuevo a la importancia de emparejar las definiciones raíz y

el modelo conceptual conduce a una dificultad posterior.

Definición + Análisis Raíz PATCRW

Definición Análisis Raíz PATCRW

Modelo Conceptual

Incorrecto

Definición Análisis Raíz PATCRW modificada

Modelo Conceptual

Correcto


Las palabras usadas en la definición raíz necesitan cuidarse en forma

meticulosa y sólo deben incluirse las que se consideran importantes. A

causa de esto, las actividades que deben incluirse en el modelo conceptual

se relacionan con estas palabras. Esto a menudo ocasiona que se incluya

frases en una definición raíz para hacer el sistema definido muy particular a

la situación del mundo real que se analiza.

Necesita considerarse la siguiente pregunta: ¿son en verdad necesarias

estas palabras?. Si la respuesta es si, entonces el modelo es deficiente en

términos de las actividades que deber ser el conjunto necesario. Si la

respuesta es no, entonces las palabras deben omitirse de la definición.

5) Una dificultad que debe reconocerse se relaciona con el mismo lenguaje de

modelado. Se ha establecido que el lenguaje de actividades son verbos. A

menudo se producen modelos en los que aparecen una combinación de

verbos y sustantivos. La consistencia del lenguaje necesita mantenerse

puesto que, si aparece un sustantivo, esto puede significar que una

restricción del mundo real (en términos de un “cómo” particular) que se ha

introducido, pudiera no ser susceptible de defenderse en base a la definición

raíz.

Tomemos como ejemplo:

En este modelo, una parte de la organización se ha incluido como una

actividad, éste es el Comité de Especificaciones. Este es un “cómo”

particular para hacer la actividad “establecer especificaciones”. Para que el

modelo sea consistente, debe incluirse la actividad como “establecer

Toma muestra del producto

Inspecciona la muestra

Comité de Especificaciones

Decide si el producto está dentro de la

especificación o no

Comunica la decisión a producción


especificaciones” si este “cómo” particular de hacer la actividad es una

restricción, entonces la actividad no debe aparecer ya que, por definición, el

modelo representa el área sobre la que el proceso de toma de decisiones

tiene control. Las restricciones están fuera del límite del sistema y en este

caso (donde “establecer especificaciones” por medio de un comité) las

especificaciones serían una entrada al sistema.

6) La distinción hecha desde el inicio de la sección, esto es, la distinción entre

la actividad de pensar en el mundo real y la actividad en el mundo real lleva

a cometer una falla común. Por lo general, al principio se forma alguna

imagen de la situación a través de entrevistas o mediante conocimientos

adquiridos si el analista es parte de la situación. Esta imagen está en

términos de actividad del mundo real y es la fuente de las DRs.

El problema se presenta como un modelo que es desarrollado a partir de

una DR particular. El analista conoce una actividad del mundo real que no

se incluye en el modelo. Esto no es ilógico ya que la DR representa sólo una

visualización entre las muchas que constituyen la complejidad del mundo

real, de manera que el error está entonces en incluir la actividad aunque no

pueda justificarse en el terreno de la lógica. Este punto se ilustra mejor con

el siguiente diagrama:

En el diagrama de arriba las flechas completas indican el flujo de

análisis. Las flechas entrecortadas eliminan con eficacia la DR y por lo

tanto debilitan al modelo como una representación defendible de una

visualización particular.


7) La elección de las palabras “definición raíz” como un término técnico para

describir la propiedad básica de un sistema se hizo para dar a entender que

esta definición contenía la “esencia” de una visualización particular de la

situación.

Con frecuencia ocurre que se construyen DRs tan generales que

podrían referirse a una gran variedad de situaciones al igual que a aquellas

que se desea referir. Así, por ejemplo, un sistema en relación con una

librería podría describirse como un sistema de empleo. Éste podría ser una

visualización legítima pero no contiene la esencia de la situación que podría

definirse como poner a disposición de usuarios autorizados una

información almacenada. Una prueba útil es tomar la DR desarrollada y

preguntar por ejemplo: “Puedo inferir la situación particular a partir de la

DR?”.

8) Algunas veces se introducen afirmaciones calificativas en una DR, lo que

conduce a la inclusión de actividades en el modelo resultante, fuera del área

de autoridad de quien toma la decisión del sistema y, por lo tanto, externo al

límite del sistema (de manera que no deben incluirse en el modelo).

Regresando al ejemplo de la taberna inglesa, he visto definiciones de la

forma... un sistema operado por un tabernero para vender cerveza a clientes

que participan en la relación social. No pueden introducirse en forma

legítima al modelo las actividades orientadas a que suceda la relación

social. Por lo tanto la frase “que participa en la relación social” debe

borrarse de la DR.

9) Un error común al desarrollar modelos es incluir actividades que en esencia

no son alcanzables. Ya que son modelos de sistemas de actividad humana,

cada actividad, por ejemplo, podría realizarla un administrador individual u

operador y por lo tanto podrían representar su área de autoridad

(especificación del trabajo). En un modelo de la definición anterior de un

sistema para venta de cerveza, aparecen actividades del tipo “genera

beneficios”. No podría darse esta responsabilidad a un individuo. El

beneficio es el resultado de obtener ingresos e incurrir en costos y son las

actividades relacionadas con éstas dos últimas consideraciones las que


deben incluirse. Tomando el mismo ejemplo de la taberna inglesa, un

modelo orientado al cliente puede incluir actividades de la forma “genera

un ambiente social agradable”. De nuevo, esto no es alcanzable. Pueden

incluirse actividades de la forma “proporcionar aquellas atenciones que se

consideran llevarán a un ambiente social favorable”. A esto debería

necesitar añadirse “monitorear el ambiente alcanzado” y “controlar las

atenciones proporcionadas para asegurar que el ambiente alcanzado sea

favorable”. Por lo tanto, estas tres actividades necesitarían reemplazar la

única actividad original. A nivel de empresa una actividad no alcanzable

que con frecuencia se incluye es “generar la imagen deseable de la

compañía”. La imagen de la compañía es algo que resulta de la manera que

una compañía hace todo lo demás. Así, a menos que la compañía referida

esté en el negocio de elaboración de imágenes corporativas en lugar de

seguros, banca, manufactura, etc. esta actividad no debe aparecer. En esta

clase de organizaciones, la imagen de la compañía puede monitorearse

como una actividad independiente.

10) Como el modelo formal de sistemas requiere un modelo de SAH que

contenga los procesos de monitoreo y control, estos con frecuencia se

añaden, tal vez como complemento, para redondear el modelo. Aparecen en

la parte inferior de un modelo, como Tasmania sobresale de la costa de

Australia; necesarios para una descripción completa pero sin relación en

realidad. Este tipo de inclusión casual no es bastante buena. Es necesario

pensar en lo que se controla y por qué. La acción de control que representa

la salida de la actividad de control también difiere de las otras salidas de

actividad. Puede estar a alguna (o a todas) las otras actividades,

dependiendo de la acción de control requerida. Así, es del tipo de

“intervención ocasional” en lugar de una acción continua enfocada a cada

actividad. Suelo ilustrar este vínculo selectivo mediante una flecha

quebrada.

Resumiendo, incluya siempre declaraciones calificativas, después de

verbos de monitoreo y control, para identificar lo que está monitoreando y

por qué debe tomarse acción de control. A causa de que la entrada al


monitoreo y la salida del control son diferentes a las otras entradas y

salidas, haga que parezcan diferentes usando diversos tipos de flechas.

11) Una observación final que vale la pena hacer es en relación con el proceso

mismo de construcción del modelo. El analista no puede asegurar en el

inicio del proceso que las DR elegidas serán relevante o representarán un

conjunto extenso o suficiente. Comparar los modelos con el mundo real

observado, valorar la deseabilidad, etc., dará como resultado la generación

de nuevos modelos y el abandono de otros. Así, el proceso de modelado

necesita ser bastante rápido, aunque defendible y esto necesita práctica. Si

un analista gasta mucho tiempo al ampliar o elaborar un modelo, se resistirá

a abandonarlo, aunque resulte relevante. Habrá generado posesión

psicológica del modelo y su retención bien podría distorsionar el análisis

resultante.

Resumen de fallas

Las fallas discutidas anteriormente se refieren a las siguientes áreas:

1) Distinción del mundo real/mundo intelectual.

2) DRs mixtas.

3) Uso del análisis PATCRW.

4) Dispersidad de DRs y MCs.

5) Lenguaje de modelado incoherente.

6) Inclusión de elementos injustificados del mundo real.

7) DRs sin la esencia de la situación.

8) Introducción de declaraciones calificativas en una DR que conduce a

actividades externas al área de autoridad de toma de decisiones.

9) Introducción de actividades no alcanzables.

10)Inclusión casual de monitoreo y control.

11)Entusiasmo o posesión sicológica excesivos por el MC.


Etapa 4: construcción y verificación (validación) del modelo conceptual

Dado el concepto de un todo que nosotros elegimos para considerar como “un

sistema”, podemos describir a este sistema como una entidad que recibe

algunas entradas y genera algunas salidas; el sistema al mismo tiempo

transforma las entradas en las salidas. Lo que se hace en el estadio 4 es

construir un modelo de sistema de actividad necesario para lograr la

transformación descrita en la definición raíz.

El modelo resultante no es una descripción de un sistema de actividad

humana real. No es una descripción de alguna parte del mundo real; es

simplemente un grupo estructurado de actividades que la lógica requiere en un

sistema nocional que ha sido definido en la definición raíz.

Una vez que la construcción del modelo conceptual se inicia existe una

tendencia para que éste se escabulla y se transforme en una descripción de

sistemas de actividades reales que se sabe existen en el mundo real. Se debe

ofrecer resistencia a esto porque niega todo el propósito del enfoque, que es el

generar pensamiento radical mediante la selección de algunas visiones de una

situación problema, posiblemente pertinentes para mejorarla. Si las

descripciones del mundo real se escabullen en el modelo, entonces en el

4.a Concepto de

sistema formal

Generar

Modelo(s)

conceptual(es)

4.

4.b Otros

pensamientos

de sistemas

Modelo

Conceptual de

Tarea Primaria

Benchmarking

Reingeniería

Outsourcing

Normas ISO

Calidad total

Dinámica de

Sistemas

Etc.

Definiciones

Raíz


estadio de comparación quizá estemos comparando iguales con iguales, y las

posibilidades noveles quizá no emerjan.

Veamos un ejemplo que nos ayudará a aclarar lo anterior. Es el caso de

la situación problema del servicio de transfusión de sangre. Para construir un

modelo no se examinó las operaciones reales de las unidades de recolección

de sangre y de los bancos de sangre dentro del servicio nacional de salud: el

incluirlas en el modelo sería exactamente como generar un estadio de

comparación mediocre. La participación anticipada en un análisis en la cual

las operaciones reales han sido examinadas, facilitará la construcción del

modelo; pero ésta no debe dirigirlo. El modelo se vuelve así un asunto en que

se debe preguntar: ¿qué actividades y en qué secuencia tiene que llevarse a

cabo para hacer la transferencia?

La definición raíz es una afirmación de lo que el sistema es (descriptiva)

o debe ser (solucionadora) para un observador particular. Esta etapa se

relaciona con la expansión lógica de esa definición a las actividades que el

sistema debe hacer para ser el sistema así definido. Estas son las actividades

mínimas necesarias a un nivel de resolución particular y, como tales,

constituyen el modelo conceptual -por ejemplo, “definir donadores

potenciales” debe ir antes de “ubicar donadores potenciales”-. El propósito es

crear, considerando la situación problema en forma imparcial, algo que pueda

ser comparado, formalmente y específicamente, con el cuadro pictórico

construido en la fase de investigación.

Debe haber un modelo para cada definición raíz. El modelo de primer

nivel de resolución de una definición raíz no debe contener mas de 10

actividades, aproximadamente; de otra forma se vuelve difícil defenderlas

como el conjunto mínimo necesario. La experiencia ha mostrado que se debe

comenzar la construcción del modelo conceptual escribiendo no mas de 6

verbos que describan las actividades principales implicadas en la definición

raíz.

El detalle puede incrementarse redefiniendo cada actividad (o un

conjunto seleccionado de actividades) como el sistema y, mediante el

mecanismo de definición raíz, producir un modelo de segundo nivel de

resolución, que puede ser del orden de 80 actividades. Es útil adelantar una


comparación en cada etapa de construcción del modelo. Se ha hecho una

comparación intuitiva al nivel de definición raíz y con base en ella se dice que

los sistemas son relevantes. Vale la pena hacer una comparación superficial en

el primer nivel de resolución para apoyar esa consideración. La comparación

en este nivel podría sugerir la utilidad de alguna modificación de la

definiciones raíz originales.

Los modelos no son un fin en si mismos. Se desarrollan para servir a un

propósito y, aunque el analista puede estar cómodo aislado del mundo real

realizando esta actividad, es necesaria una inmersión continua en el mundo

real si el análisis va a mantener contacto con él. Es posible hacer uso de la

construcción de modelos conceptuales como un medio para definir las bases

de planificación y/o análisis y/o un diseño (por ejemplo de Sistemas de

Información); el desarrollo de modelos conceptuales no es diseño, es un medio

para estructurar el pensamiento acerca de situaciones problema poco claras.

La etapa 4b se incluye para poder obtener ayuda de las ideas de otros

sistemas si se considera apropiado. Por ejemplo de Planeamiento Estratégico,

Calidad total, Benchmarking, Reingeniería, Dinámica de Sistemas,

Outsourcing, etc.

Los dos principales problemas en la construcción de modelos son la

forma de hacerlo, y la forma de validar el modelo conceptual resultante. La

solución al primer problema es armar en la secuencia correcta el mínimo de

actividades que son necesarias en un sistema de actividad humana descrito por

la definición raíz.

El segundo problema ha sido abordado usando conceptos de sistemas

para armar un modelo generalizado de cualquier sistema de actividad humana,

llamado “modelo formal”, el cual puede ser usado, sino para validar la

construcción, al menos para asegurarse que esta no es deficiente. Esta es la

razón para al inclusión de la etapa 4a. El modelo formal de sistemas no es

normativo, es una combinación de componentes de “administración” cuya

ausencia o ineficiencias en situaciones problemas verdaderos se han visto que

son cruciales para la existencia de algo que se percibe que es un problema.

S es un “sistema formal ” si y sólo si:


i) S tiene un propósito o misión en curso. En el caso de un sistema “suave"

esto podría ser una búsqueda constante de algo que finalmente nunca se

pueda lograr -algo como "mantenimiento de relaciones"-. En sistemas más

duros esto es lo que se divide en "objetivos" o "metas", caracterizadas por

ser alcanzables en un momento oportuno. Es significativo el describir a los

objetivos como "todavía no alcanzados", "alcanzados", "abandonados", o

“cambiados”, pero esto no es así con el "propósito" menos preciso asociado

con los sistemas suaves. Las familias, y muchas organizaciones, no tienen

objetivos en este sentido, pero sí tienen propósitos o misiones que sirven

para dar coherencia y unión a sus actividades. Para una universidad, por

ejemplo, que como sistema podría ser considerada como "duro" en algunas

características y como "suave" en otras, esta característica se debe asumir

que es "el descubrimiento, preservación y transferencia del conocimiento".

ii) S tiene una medida de desempeño. Esta es la medida que señala el progreso

o retroceso del alcance de propósitos o del logro de objetivos.

iii) S incluye un proceso de toma decisiones -nocionalmente "algo que toma

decisiones", siempre y cuando éste se asuma que no es una persona, sino

un rol que mucha gente en un sistema dado puedan ocupar-. Vía el proceso

de tomas de decisiones, el sistema puede llevar a cabo acción reguladora

bajo la luz de i) y ii).

iv) S tiene componentes que son en sí sistemas, que tienen todas las

propiedades de S.

v) S tiene componentes que interactúan, que muestran un grado de

conectividad tal, (que podría ser física, o quizá ser flujos de energía,

materiales, información o influencia) que los efectos y acciones se puedan

transmitir por el sistema.

vi) S existe en sistemas más amplios y (o) medios con los cuales interactúa.

vii) S tiene un límite, que los separa de vi), que se define formalmente como

el área dentro de la cual el proceso de toma de decisiones tiene poder para

generar acción --en contraposición a influenciar felizmente el medio.

viii) S tiene recursos, físicos y, a través de los participantes humanos,

abstractos, que están a la disposición del proceso de toma de decisiones.

ix) S tiene alguna garantía de continuidad, no es efímero, tiene "estabilidad a

largo plazo", recuperará la estabilidad después de algún grado de disturbio.


Se podría dar apoyo a esto último desde fuera del sistema; quizá derive

internamente del compromiso de los participantes con i) la misión.

El valor del modelo formal de sistemas reside en que éste permite que

se formulen preguntas que, cuando se refieran al modelo conceptual revelen

deficiencias ya sea en él o en la definición raíz en que se basa. Las preguntas

típicas pueden ser: ¿La medida de desempeño en este modelo es explícita? ¿Y

qué constituirá un desempeño “bueno” y “malo” de acuerdo a ésta? ¿Cuáles

son los subsistemas en este modelo? ¿Las fronteras del sistema están bien

definidas?

Aunque el uso del modelo formal de sistemas no puede asegurar que los

modelos conceptuales sean “válidos”, si puede al menos asegurar que no están

construidos tan descuidadamente como para ser útiles al confrontarlos con

actividades del mundo real, en la comparación de la fase 5. Pero, además, se

puede examinar la validez de los modelos en términos de cualquier otro

sistema de pensamiento que el analista venere. La metodología no debe

excluir algún sistema de pensamiento que se está desarrollando en algún otro

lugar. Este es el estadio en el cual otras vetas se pueden explotar. Este es el

punto en el cual los modelos conceptuales se pueden inspeccionar a la par con

cualquier otra teoría (en especial de sistemas) que sea pertinente a los sistemas

de actividad humana.

Una vez que las actividades mínimas se han considerado es útil

considerar la estructura implícita en el modelo hasta ahora: ¿Cómo se pueden

agrupar las actividades?. La siguiente actividad a considerar es: la auditoría del

éxito de las actividades operacionales mediante otro subsistema, que se ocupa

de las operaciones como una actividad del negocio. Esto podemos añadirlo al

diagrama operacional representándolo como una operación que se ocupa de la

totalidad, como en la figura:

SISTEMA DE NEGOCIOS (La Empresa)

SISTEMA

OPERACIONAL

Desempeño Monitoreo y desempeño

(El área con

el problema)


La actividad de auditoría consiste en el monitoreo del desempeño, la

evaluación de recursos, preparación de un plan para usar esos recursos,

comparación del desempeño con el plan y el replanteamiento. Esta secuencia

puede reemplazar a la actividad “monitoreo y desempeño” de la figura

anterior, el lado derecho se muestra en la siguiente figura:

Los recursos sujetos a este plan deben ser suministrados por un sistema mas

amplio. El sistema mas amplio se interesara por:

1. suministrar recursos para este sistema, o no suministrarlos, dependiendo

de la evaluación de los recursos totales disponibles,

2. los méritos relativos (evaluados subjetivamente y/o cuantitativamente)

de los diferentes planes, y

3. otras consideraciones generales, que para un negocio de editorial, por

ejemplo, pueden ser, por ejemplo, políticas del tipo “a pesar del carácter

lucrativo no se publicará pornografía”.

SISTEMA

OPERACIONAL

Evaluar

recursos

Replantear

(controlar)

Recursos desde

un sistema amplio

Requerimientos del plan

Desempeño

Requerimientos

Hacer un plan

detallado para

este sistema

Comparar el

desempeño con

el plan

SISTEMA DE NEGOCIOS

Propuesto


En un nivel mas detallado es posible examinar cada actividad en los modelos

mostrados y contestar las preguntas:

¿Qué información es necesaria para tomar esta acción?

¿Cuál es su fuente?

¿Cuál es su receptor?

¿Dónde será recibida?

¿A dónde es enviada? ¿Con qué frecuencia? ¿En qué forma?

El gráfico conteniendo las respuestas a estas preguntas y los diagramas de

arriba podrían luego ser usados para preparar diagramas de:

1. estructuras de sistemas de negocios y operacional: Plan de SI, Diagrama

de Dependencia de Procesos, y

2. los flujos de información en estas estructuras: el Modelo E_R, DFD.

En un nivel de resolución superior, la atención gira hacia los sistemas

amplios cuya existencia se mencionó cuando se consideraba la actividad de

“auditoría” del sistema operacional para un sistema de negocios. Este sistema

evaluará los recursos totales disponibles, reuniendo información importante

para los planes generales, evaluando si los sistemas de negocios requieren

recursos extras no disponibles en la compañía o abandonando recursos sin

usar, localizando recursos para los sistemas operacionales, monitoreando el

desempeño y controlando mediante la modificación de los planes.

**pag. 109 wilson

Obtenc ión de l Mode lo de Tarea Pr imar i a

Los modelos derivados de las definiciones raíz contienen diferentes

actividades. El analista enfrenta ahora la dificultad de reducir estos múltiples

modelos a uno solo.

Esta etapa se relaciona con el desarrollo de modelos conceptuales de las

definiciones raíz y la selección de actividades de aquellos modelos que son

deseables de alguna manera. La deseabilidad puede expresarse en términos de

factibilidad o en términos de necesidad pero es definida y las selecciones

hechas por el grupo de administradores a quienes el rango de Ws es relevante.


La etapa 2 de la figura 38 ilustra la inferencia de un modelo de tarea primaria

por una ruta que busca obtener coherencia en el modelo resultante.

Figura 38. Un proceso de condensación de los sistemas.

El procedimiento descrito antes, para llevar a cabo esta consolidación de

modelos, se basa en las siguientes suposiciones:

1) La primera es que, sin importar el tipo de organización considerada,

habrá una descripción de ella que logrará el consenso global; por ejemplo, una

descripción de una tarea primar neutral. Para una prisión, la descripción sería:

un sistema para la recepción, alojamiento y liberación de prisioneros. Por

tanto, no importa si algunos directores consideren que una prisión es, de


manera básica, para la rehabilitación y otros piensan que es para castigo,

estarán de acuerdo que, para que una prisión sea una prisión debe, al menos,

aceptar prisioneros, retenerlos por diversos periodos y luego liberarlos.

Estas definiciones son descripciones aisladas de las operaciones básicas

de la organización bajo revisión y, por tanto, los modelos derivados de ellas

son representaciones dispersas de las diversas actividades emprendidas por las

organizaciones.

2) Pueden obtenerse modelos menos aislados, de manera defendible

mediante la adición de actividades individuales sobre las que existe un

consenso local sobre su deseabilidad. La figura 39 ilustra esta idea.

Figura 39. Ilustración de tarea primaria de “consenso”

El sistema central negro (Sn) representa el sistema de trabajo primario

“neutral”; por ejemplo, el conjunto de actividades que una organización

particular debe hacer para ser ese tipo de organización. Los sistemas S1, S2, S3,

representan al rango de percepciones „legítimas‟ definidas antes

(descripciones potenciales de la tarea primaria de la organización en la que el

límite del sistema podría ubicarse sobre el límite de la organización). Se

espera que el conjunto de actividades en Sn sea común a S1, S2, S3,....etcétera

y puede considerare parte del modelo de tarea primaria final.

Dadas las dos suposiciones anteriores, el proceso que se sigue está en

dos etapas. Cada actividad en los sistemas S1, S2, S3,....(exceptuando las de Sn)


es cuestionada para determinar su deseabilidad. La deseabilidad se determina

en la discusión con el grupo de administradores (sistemas pertinentes).

Las actividades sobre las que hay un consenso local en relación con su

deseabilidad se añade a las contenidas en Sn para formar un modelo de tarea

primaria „tentativo‟. Para las actividades sobre las que hay un consenso local

parcial. (diferente de l00%) en relación a su deseabilidad, el analista debe

juzgar su retención o rechazo. Mi criterio para la retención se basó en la

coherencia resultante del modelo. Si la actividad es necesaria (en un sentido

lógico) para volver coherente el modelo resultante, entonces se incluye, de

otra manera no. Se usa un procedimiento repetitivo para explorar la

coherencia, ilustrado mediante la figura 40.

Figura 40. Desarrollo del modelo.

Aquí se muestra que la selección de las actividades „deseables‟ de tres

modelos MC1, MC2, MC3,...conduce al modelo de tarea primaria tentativo

(MTPT), que en esta etapa puede ser no más que un agregado. Se puede

realizar dos tipos de validación al MTPT: a) Teorética y b) Empírica. El

primero lo hacemos mediante la inferencia; y el segundo, se hará en el estadio

5 mediante la discusión con los grupos de interés. Veamos la validación

lógica:

Dada la vinculación lógica de la definición raíz (DR) y el modelo

conceptual (MC) debe ser posible revertir el proceso e inferir una DR del

modelo de tarea primaria tentativo. Esto e un paso difícil y, por tanto, se


infiere un modelo de „prueba‟ de la DR así formada. Se sabe que es un modelo

coherente y, por tanto, puede compararse contra el modelo de tarea primaria

tentativo derivado y otros. La repetición continúa hasta que el modelo de

prueba inferido, es una versión aceptable del modelo de tarea primaria

tentativo en que se representa las actividades y también es coherente.

Durante este proceso puede ser necesario añadir actividades al modelo

de tarea primaria tentativo (por ejemplo, aquellas en las que no hay l00% de

consenso) pero también puede ser necesario añadir otras. Por ejemplo, las

actividades de MC1 y MC2, podrían ser calificativas de hecho, si DR1 y DR2

representan percepciones conflictivas. En este aso necesita añadirse una

actividad que se relacione con la solución del conflicto.

Adoptando el procedimiento anterior, pueden reducirse varios modelos

iniciales MC1...MCn a un solo modelo, el cual, mediante la interacción con los

administradores relevantes, puede considerarse un modelo de tarea primaria

defendible, importante para la organización particular. El límite de este

modelo se representa por medio del área sombreada de la figura 38.

Vale la pena hacer con rapidez las etapas 3 y 4, y avanzar a la etapa 5, la

comparación, a fin de devolver los modelos al mundo real para probar el grado

de relevancia (pertinencia).

Etapa 5: comparación del modelo conceptual de consenso con la realidad

Ya nos hemos referido a este estadio anteriormente, como el de la validación

empírica del modelo de tarea primaria (MTP). Se debe realizar un juicio luego

de terminar el modelo conceptual y avanzar hacia una comparación explícita

del modelo conceptual de tarea primaria con lo que existe en la situación

problema. Es mejor desplazarse con bastante rapidez al estadio de

“comparación”.

5.

Comparación

de 4 con 2

Matriz de

Comparación

Cuadro

Opiniones

Modelo de Tarea

Primaria de

Consenso


Cada vez que comenzamos a efectuar un pensamiento serio, nuestras

mentes hacen un número de operaciones como: percibir, aseverar y comparar

imágenes o modelos. En la metodología esto está formalizado: la percepción

de la situación de un problema se registra en los estadios 1 y 2 del análisis; las

definiciones raíz y los modelos conceptuales utilizan las ideas de sistemas

para aseverar ciertas características seleccionadas del problema; estas

aseveraciones, bajo la forma de modelos de sistemas, se comparan después

con las realidades percibidas en la situación problema misma.

La comparación se hace para revelar posibles cambios que podrían

“mejorar” la situación problema. Cada cambio potencial debe ser evaluado en

términos del tipo de cambio involucrado (estructural, procedural, tecnológico,

actitudinal, o un cambio en el entorno) y la cantidad de cambio evaluada

subjetivamente; y estimar si los cambios serán aceptables para los

administradores (grupos de interés) dadas las actitudes reveladas durante las

entrevistas en la fase de análisis.

Esta etapa no es precisamente una comparación ya que no se está

comparando similar con similar. Los modelos conceptuales están en términos

de actividades y por lo tanto describen un conjunto de “qués”. Además

describen lo que debe pasar en un sistema descrito por una definición raíz

particular. La distinción entre “qués” y “cómos” es fuerte, sin embargo,

también puede ser confusa. Debemos analizar esto con detalle, antes de

emprender la comparación.

Un “qué” no puede implementarse sin, antes que todo, decir “cómo”

hacerlo. Esto implica la elección entre un conjunto de “cómos” alternativos.


Por ejemplo, si el “qué” hacer es “invertir efectivo excedente”, no puede

hacerlo sin seleccionar uno o mas “cómos” del conjunto siguiente: pagar una

cuenta de deposito al banco; comprar bonos de ahorro; adquirir propiedades,

etc. No es posible revertir este proceso y decidir con alguna certeza la

naturaleza del “qué” implícito y el “cómo” observado. Por ejemplo, si se

observa que alguien compra un cuadro, no se sabe si el “qué” es “invertir

efectivo excedente”, “añadir a la colección”, o “aumentar el catálogo para la

reventa”. La comparación se complica por la característica de que no necesita

haber una correspondencia uno a uno entre los “qués” y los “cómos”.

El aspecto que causa confusión es el hecho de que un “cómo” es

también un “qué”. “Comprar cuadros” (un “cómo” de “invertir efectivo

excedente”) es también un “qué” para el que habrá varios “cómos” posibles,

como “visitar las galerías”, “participar en subastas”, etc. La clave para

entender y hacer uso de la distinción es mediante el concepto de nivel de

resolución.

Tanto la selección de un “cómo” alternativo como la expansión de una

actividad a un nivel de resolución detallado se obtienen respondiendo a la

pregunta, “¿cómo?”. La siguiente figura ilustra las dos posibilidades:


Inv ertir el

ef ectiv o

excedente

A sabe cuánto

efectivo esta

disponible

¿Cómo?¿Cómo?

B identifica las

maneras alternativas

de invertir

A Paga una cuenta de

depósito al banco

B Compra certif icados

de ahorro

(o)

(o)(y )

C Selecciona las

alternativas que

parecen mas

benéficas

(y )

.

.

.

.

D Emprende la inversión

en las alternativas

seleccionadas

C Compra cuadros

(o)

M

1

1

1

- Visitar galerías

- Par ti c i par de

subas tas

La parte derecha de la figura representa el proceso de selección. Si la

respuesta a la pregunta “cómo” es A, B o C, representa el “cómo” de hacer la

actividad al mismo nivel de resolución. Si, como en la parte izquierda de la

figura, la respuesta es A y B y C y D, entonces esto representa el conjunto de

“qués” en el siguiente nivel de resolución, por ejemplo, una expansión mas

detallada de la actividad original.

En general, un modelo conceptual, consistirá en un conjunto

interconectado de “qués” al nivel de resolución particular a fin de ser usados

para comparar. Los “cómos” específicos sólo pueden aparecer en el mismo

nivel de resolución y se introducen como una restricción por medio de la

definición raíz. Habiendo introducido esta restricción a la definición raíz (por

ejemplo, como uno de los elementos de la R en el PATCRW), el modelo

conceptual ahora debe contener actividades que también estén dirigidas por


este “cómo” particular. No es correcto introducir “cómos” particulares en el

modelo conceptual sin hacerlos explícitos en la definición raíz.

Las restricciones de este tipo no deben incluirse a menos que el analista

los considere necesarias. El propósito de los modelos conceptuales es iniciar

un debate de lo que existe y de cómo existe, a fin de producir el cambio. Si

todos los “cómos” existentes están incorporados a las definiciones raíz, los

modelos terminaran describiendo lo que existe y no habrá bases para un

debate al cambio.

Cuatro métodos de comparación se destacan como los usados con mayor

frecuencia. Son: a) la discusión general; b) la definición de preguntas; c) la

reconstrucción (histórica); y d) superposición del modelo.

El analista necesita decidir en qué lenguaje debe emprender la

comparación. Se produce una transición entre hacer el análisis en un lenguaje

de sistemas y debatir el resultado del análisis en el lenguaje del mundo real.

Por lo tanto, a menos que los administradores que participen en el debate estén

familiarizados con el lenguaje de sistemas, el analista debe traducir la

comparación al lenguaje cotidiano. Intentar discutir las definiciones raíz y los

modelos conceptuales es la manera mas rápida de sofocar el debate. Se

avanzará poco si un analista intenta discutir la estructura de una matriz de

programación lineal con un administrador de programación lineal, a menos

que también estuviera familiarizado con la programación lineal.

a) la discusión general (discusión informal): se preocupa por una discusión

general de la naturaleza de los modelos y cualquier organización implicada

por ellos. Tienden a surgir asuntos estratégicos durante este tipo de discusión

en relación con el rol, y a la existencia de ciertas actividades. Surgen

preguntas del tipo: ¿Por qué hacer esto?, más que: ¿Está bien hecho esto? La

discusión mas útil de este tipo, ocurre cuando todos los participantes están

familiarizados con el lenguaje de sistemas; si no es así se puede efectuar


seminarios en las actividades a fin de proporcionar alguna familiarización con

el lenguaje y la metodología.

La primera fase consiste en investigar el rol particular de las

actividades. Se efectúan varios seminarios en las actividades a fin de

proporcionar alguna familiarización con el lenguaje y la metodología por parte

de los administradores interesados. Se entrevista a cada uno de los

administradores por separado. Esto puede dar una idea de los objetivos de su

trabajo, de lo que consideran importante y puede llegar a identificarse sus Ws.

Las definiciones raíz se modelan en un nivel amplio y se adopta la

comparación en forma de una reunión, con todos los administradores

presentes, en la que los pares de conceptos (las definiciones raíz junto con los

modelos conceptuales respectivos) se discutieron. Se analiza si las actividades

son o no deseables y factibles.

Luego de una discusión, uno de los resultados importantes puede ser el

abandono del conjunto de objetivos descritos. Esto puede deberse a la no

factibilidad de las actividades.

b) la definición de preguntas (discusión formal): es el de uso mas común.

Se ha dicho algo en la etapa de investigación. En esta etapa los resultados de

la comparación se presentan como recomendaciones para el cambio en forma

tabular, como la siguiente figura:

Actividad

1)

Mecanismo

presente

2)

Indice de

desempeño

3)

Cambio

propuesto

4)

Tipo de

Cambio 5)

Deseable

Sistémicamente?

6)

Viable

Culturalmente?

7)

Comentarios

8)

Una lista de

actividades del modelo conceptual

(“qués”)

¿Si existe la actividad, cuál es el

“cómo” en esta

situación que sea un ”cómo” de este

“qué”?

Criterio o medida contra el

(la) que se dice,

que es bueno o malo el “cómo”

presente.

Cambios

acumulados para

mejorar la

situación.

Evidencia que se

relaciona con el “cómo”

presente; utilidad

potencial del cambio; importancia de los

vínculos de “actividad a

actividad” existentes o propuestos

“qués” nuevos, “cómos”

alternativos, etc.


Las columnas 1 y 2 representan los resultados del proceso de

cuestionamiento referido antes. Un método para identificar los “cómos” es

determinar, antes de todo, lo que debería ser la salida del “qué” y preguntar si

esa salida existe o no. Por ejemplo si el “qué” es “planear la producción” la

salida sería un plan de producción. Si puede encontrarse un documento así,

entonces puede decirse que existe la actividad sin tomar en consideración si se

hace bien o no.

Las columnas 4, 5, 6 y 7 representan los resultados de la valoración de

lo que existe y las bases en que esa valoración se realizó. Consiste en los

cambios propuestos junto con la evidencia del mundo real para sustentar las

recomendaciones. En esta etapa se efectúa la traducción del lenguaje, referida

antes, y el contenido de estas columnas se comunica a la gente en la situación

problema.

La columna en la mano derecha está resumiendo la fuente de ideas para

el cambio en la situación o ideas nuevas para definiciones raíz pertinentes.

Como un modelo de tarea primaria describe una visualización pública o

de consenso de algunas situaciones, las actividades contenidas en el modelo

deben existir en esa situación mediante un conjunto particular de „cómos‟.

Así, si el modelo describe el proceso que transforma los componentes en

automóviles, entonces uno esperaría encontrar actividades que representan,

por ejemplo, el almacenamiento y ensamble de esos componente en alguna

forma, de lo contrario, la entidad reconocible como un automóvil no podría

parecer que se produce en la fábrica. El „cómo‟ particular de ensamble podría

ser manual o usar los métodos de producción en masa pero, ¿la actividad‟ sólo

necesita identificar que un „cómo‟ así, existe de hecho?. Uno no se interesa, en

esta etapa, de si el „cómo‟ es adecuado o no, de si está bien o mal hecho. La

existencia es el criterio importante. Una manera de hacer la „validación‟, en

forma sencilla, es determinar lo que podría ser la salida de la actividad y

buscar la existencia de ese resultado. Por ejemplo, si la actividad es “planear

la producción” el resultado esperado sería un documento llamado plan de

producción. Si existe tal documento , entonces la actividad de producción


también debe existir, sin tomar en cuenta los métodos de planeación

empleados en la producción.

Un método alternativo útil, en particular si, como parte del análisis,

también se requiere saber quién es el responsable de hacer las actividades, es

identificar a quienes deciden, de manera respectiva. La suposición es que si

puede identificarse a quien toma una decisión con responsabilidad para una

actividad, entonces es justo incluir la actividad en el modelo de tarea primaria.

Este tipo de análisis se asocia, en general, con la reestructuración

organizacional o el análisis de sistemas de información; un análisis de la

metodología adecuada para estos intereses se encuentran en los capítulos 5 y

6. Este método se conoce como „ubicación organizacional‟.

Uno de los conceptos importantes de los sistemas formales referidos

antes es, que el límite de un sistema se define como lo que determina el área

sobre la que algún proceso de toma de decisiones tiene control. El propósito

de la ubicación organizacional es determinar, en forma individual, quién toma

decisiones y realiza este proceso sobre el área representada por el modelo de

tarea primaria.

Así , uno está convirtiendo un modelo independiente de la organización

en un modelo dependiente de ella , trazando los límites alrededor de los

conjuntos de actividades que representan las áreas de autoridad de la gente

relevante . Por lo general, esto no se realiza preguntando a los administradores

individuales por las actividades en el modelo de las que son responsables. Hay

dos razones principales para esto.

En primer lugar, el lenguaje del modelo está en términos de “qués”

mientras los administradores están más familiarizados con la manera en que se

ejecutan las actividades mediante los “cómos” particulares. Esta inconsistencia

del lenguaje puede llevar a una mala interpretación de lo que cubre la

actividad, tanto en la parte del administrador como en la parte del analista.

Segundo, los administradores son humanos y no es raro que alguno de

ellos exija un área de responsabilidad que contenga actividades de las que le

gustaría ser responsable, en adición de las que en realidad tiene y omita

actividades que son su responsabilidad pero no le gustaría hacer. Esto es más


probable que ocurra, en caso de que un resultado posible del proyecto sea

alguna reestructuración de las responsabilidades.

c) la reconstrucción histórica: consiste en reconstruir una secuencia de

sucesos del pasado de acuerdo con un modelo conceptual y luego comprara

esa secuencia con lo que sucedió en la realidad. Esto es una manera

satisfactoria de exhibir el significado de los modelos, y quizás las deficiencias

de los procesos reales. Es necesario usarlo con cuidado. Si se ve como un

medio de recriminación del desempeño pasado, antes que como una manera de

conocerlo, pude producir antagonismo por las parte de los participantes.

Por ejemplo: En un proyecto para un consultor quien había tenido una

relación desafortunada, en uno de sus proyectos, con su cliente. Estaba

ansioso por aprender de la experiencia para que pudiera evitar esos

resultados en el futuro. La situación problema consistió en las cartas y otra

documentación de los proyectos retenidas por el asesor y su cliente. Así,

fue posible desarrollar la historia del proyecto desde ambas partes y

comparar ésta con un modelo de sistemas.

El modelo resultante y su comparación lleva a un aprendizaje

importante tanto para el asesor como al analista. En forma básica, fue esta

experiencia la que condujo a la distinción entre la solución del problema y

el contenido del problema; una distinción que se ha encontrado invaluable.

d) superposición del modelo: consiste en estructurar el modelo conceptual

para que refleje, en todo lo posible la situación del problema actual y

sobreponiendo, en forma literal, una imagen encima de otra (elaborándola en

papel transparente). Las diferencias entre las dos se manifiestan de inmediato,

que es la fuente de la discusión del cambio. Con este método se puede agregar

mordacidad a la comparación al preguntarnos acerca del modelo de lo que

existe: ¿Qué definición raíz implica este “sistema”? ¿Qué tiene de diferente

con aquel modelo que fue la base de la conceptualización en el estadio 4? Se

ha usado este método con mayor éxito en estudios relacionados con la

estructura de la organización.


Debe destacarse dos puntos. Primero, la comparación es para ayudar a

atacar la solución del problema en una forma estructurada, no para indicar qué

“debe” existir. Los modelos conceptuales no son históricos y tienen un aire

inhumano. Implementados podría requerir un comienzo inhumano para

operarlos. Segundo, la etapa de comparación consiste en un debate en el cual

sólo aquellos quienes viven en la situación problema (actores y clientes)

pueden seleccionar un cambio para implementarlo. El analista puede declarar

y defender una sugerencia particular pero la decisión para la acción puede sólo

ser hecha por los actores y clientes.

Los cuatro métodos ayudan a asegurar que el estadio de comparación se

haga con conciencia, que sea coherente y sustentable. En cualquier estudio

particular puede ser útil adoptar uno de ellos o llevar a cabo varias

comparaciones empleando métodos diferentes. Popper señala que se tiene

poco conocimiento certero sobre el cual basar este tipo de “ingeniería social”;

el incrementalismo, el juicio y el error son el enfoque mas sabio.

(** Ver Ejemplos en Checkland: Cap. 5 pag. 156; Cap.6 pag. 190; Cap.9 pag.

265 **)

** Ver detalles en el Apéndice B.

Etapa 6 y 7: recomendaciones para cambiar y proceder

Las comparaciones de la etapa 5 producen un conjunto de recomendaciones

para el cambio que puedan considerarse deseables culturalmente y viables

sistémicamente. Sería poco realista esperar que el conjunto completo sea

aceptable. Un cambio particular puede parecer lógico al analista, pero para un

administrador (grupo de interés) puede ser todo excepto lógico. A fin de

inferir cambios que puedan implementarse, necesitan cumplir dos criterios.

Deben ser deseables con base en el análisis de sistemas y también deben ser

factibles en el aspecto cultural, dados los administradores particulares en su

situación particular.

Recomendaciones

para la

implementación

de los cambios

7. Acción para

mejorar la

situación problema 6. Cambios

deseables y viables

---------- ----------

Cambios

Matriz de


Aunque es una actividad separada de la comparación, puede darse una

valoración de factibilidad al mismo tiempo, en tanto participen los

administradores relevantes. Los comentarios elaborados pueden reunirse como

una columna adicional en al figura anterior. Una vez que los cambios

aceptables se han ensamblado, se vuelve necesario definir cómo deben

implementarse (con ideas de: Reingeniería, Calidad Total, Benchmarking,

Normas ISO 9002, Cultura organizacional, Outsourcing, Implementación

Estratégica, etc.); esto es, para determinar las acciones necesarias con objeto

de mejorar la situación problema.

La acción para introducir el cambio también debe relacionarse con los

cambios estructurales, de procedimientos y actitudinales necesarios para

acomodar las recomendaciones. Los cambios de actitud pueden considerarse

benéficos, pero no puede definirse que se pueda implementar una actividad

específica que produzca un cambio de este tipo. La necesidad de implementar

los cambios puede considerarse otro problema dentro de la misma situación, al

que puede aplicarse la metodología como una ayuda (definición raíz, modelo

conceptual, ...).

** ver Implementación estratégica

Comparación entre el Pensamiento de Sistemas “duros”

y “suaves”

La investigación en la acción que condujo a la metodología descrita

anteriormente comenzó con un intento por usar las ideas del pensamiento de

sistemas “duros” en problemas “suaves”, al alejarse de la tradición ingeniería

“dura” cuando se tuvo necesidad de hacerlos por las dificultades de las


situaciones reales. No se imaginó que los métodos adecuados para enfrentar

problemas ingenieriles bien definidos sobrevivirían sin daños a la

transferencia a situaciones problemas difusas establecidas en los sistemas

sociales, y no lo han hecho. Ahora que un enfoque a los problemas “suaves”

ha emergido y ha sido verificado es interesante comprobarlo con las formas

tempranas del análisis de sistemas que derivan de la ingeniería.

La tabla 5 compara el enfoque del autor con la versión de análisis de

sistemas RAND y con la descripción dada por Jenkins (l969) a partir de la

cual este trabajo comenzó.


Tabla 5. Comparación de metodologías de sistemas “suaves” y “duros”

Metodología de Jenkins (1969) Corporación RAND

(1950)

Sistemas “Suaves”

a) Inicio: una urgencia por ge Inicio: una urgencia por resolver un problema

relativamente nerar mejoría en un sistema bien definido que el analista, quizá

hasta cierto punto,

social en el cual se siente considere como “dado”, una vez que el cliente que

requiere que existe una situación ayuda es identificado.

problema mal definida.

b) Expresar mediante el Análisis al nombrar el Análisis al examinar los

examen de elementos de sistema, sus objetivos, objetivos de los

tomadores de

“estructura” y “proceso”, etc., y su lugar en una decisión como se expresa

en

y sus relaciones mutuas. Jerarquía de sistemas. la necesidad enunciada

de

Definición tentativa de un sistema requerido con

un

sistemas pertinentes para desempeño específico

mejorar la situación problema.

c) Formular definiciones raíz Diseñar el sistema Identificar sistemas

de sistemas pertinentes mediante la simulación y alternativos para

satisfacer

y construir modelos construcción del modelo la necesidad definida y

conceptuales de esos cuantitativo. compararlos mediante el

sistemas modelado, usando los

criterios de desempeño

d) Mejorar los modelos Optimizar el diseño, Seleccionar la alternativa

conceptuales, mediante utilizando el criterio de que mejor satisfaga la

el uso del modelo del sistema desempeño (económico). necesidad y sea viable.

formal y otros pensamientos

de sistemas.


e) Comparar los modelos No hay estadio equivalente: ambos enfoques saben

desde el

conceptuales con “lo que principio que el cambio es necesario.

hay” en la situación real, usar

la comparación para definir

cambios deseables y viables

en el mundo real.

f) Habilitar los Habilitar el sistema diseñado.

cambios acordados.

La principal diferencia entre los enfoques “duros” y “suaves” es que

donde el primero puede dar inicio a preguntarse “¿Qué sistema se tiene que

ingenierear para resolver este problema?” o “¿Qué sistema satisfará esta

necesidad?” y puede tomar el problema o la necesidad como “dada”; el último

tiene que permitir que emerjan respuestas completamente no esperadas en

estadios posteriores. Esta diferencia obliga a la metodología “suave” a incluir

el estadio de comparación, cosa que no tiene equivalente en los enfoques más

“duros”. En este estadio, el pensamiento de sistemas proporciona una

estructura para un debate acerca del cambio que esperanzadoramente será de

buena calidad como resultado del discernimiento capturado en las definición

raíz. En este estadio, los enfoques “duros” se ocupan de preparar la

habilitación del sistema diseñado. Un análisis de sistemas de tipo RAND de

un sistema de armas siempre generará una definición de un sistema de armas.

El análisis que utiliza la metodología “suave” quizá sugiera el desarme, poner

la otra mejilla o la negociación política.

Aparte de esta diferencia principal, la metodología “suave” se considera

que en el caso general del cual las metodologías “duras” son casos especiales.

Así la conceptualización se vuelve, si el problema está lo suficientemente

bien definido, diseño de sistemas. La “mejoría de un modelo conceptual” se

redefine en “optimización de un modelo cuantitativo”. El implementar alguna

variedad de cambio se vuelve habilitación de un sistema diseñado.


La metodología puede así ser considera como un enfoque general de

solución de problema adecuado a los sistemas de actividad humana. Cuando

los problemas se pueden expresar inequívocamente, la metodología podría

simplificarse en uno de los enfoques de ingeniería de sistemas. Cuando los

problemas no se pueden formular claramente y sin ambigüedad, ésta se

convierte en un medio para explorar esa ambigüedad, e incluye un estadio

adicional que utiliza al análisis de sistemas como medio para orquestar el

debate acera del cambio. Este estadio adicional (estadio 5: “comparación”) es

un reflejo de la característica principal de los sistemas de actividad humana,

como se reveló en esta investigación. Esta característica es que, en contraste

con otros tipos de sistema, los sistemas de actividad humana nunca se pueden

describir o (“modelar”) en un solo reporte que sea aceptable generalmente o

suficiente. Para un sistema de este tipo puede muy bien haber tantas

descripciones de él como hay gente que no es completamente indiferente a él.

Esta es la característica del mundo real que obliga a la metodología a

volverse un medio para organizar la discusión, el debate y el argumento, en

vez de un medio para ingenierear “soluciones” eficientes.


Conclusiones

A la metodología anterior es mas útil considerarla como un patrón de

actividades que pueden usarse en cualquier orden y en cualquier punto de

inicio.

El analista que lo usa necesita tener claro que esta investigando el mundo

real comprendiendo sistemas o debatiendo el cambio mediante una

comparación.

Por lo general ocurre iteración importante en torno a las etapas 2, 3, 4 y 5 y,

para funcionar con efectividad, el analista necesita anticiparse. De manera

que, mientras se formula una definición raíz, puede pensar en los tipos de

actividades que aparecerán en el modelo y los resultados probables de una

comparación. Esto ayuda a la producción de definiciones raíz relevantes.

Vale la pena en cualquier proyecto ensamblar, de manera formal, una

imagen (cuadro pictórico) de la situación (el sistema que contiene el

problema) y del sistema solucionador de problemas relacionado. Así, el

(los) analista(s) puede(n) preguntar “¿Cuál es la reunión adecuada de

conceptos, en este sistema solucionador de problemas, para la naturaleza de

la investigación que se emprende?”, de esta manera el analista puede reunir

el conjunto de conceptos que le parecen razonables, dada su experiencia,

que forman el conjunto de recursos para la resolución de problemas.

El lenguaje de sistemas es muy poderoso cuando uno se enfrenta a una

situación problema “suave”. Para usar con eficacia éste y otros lenguajes de

sistemas, el analista debe permanecer orientado al problema.

No hay manera de saber si los resultados serán mejores o peores. Cuanto

puede preguntarse es “¿Fue adecuada la metodología para ese analista en

esa situación?”. la respuesta es sí, si los individuos relacionados con la

situación están de acuerdo que se alcanzo un resultado útil.

En los sistemas duros el “diseño” es el “diseño de sistemas para ser

maniobrados”, y se pueden usar los métodos codificados de simulación,

modelamiento y optimización. En sistemas suaves “diseño” viene a ser el

diseño de un “cambio” seleccionados como resultado del proceso de

definición raíz/ modelo conceptual/ comparación. Diseño no es la creación


de algo que se ejecutara en una forma especifica para lograr algún objetivo

definido, es la creación de alguna modificación.

No es una técnica, ya que no tiene la certeza de producir resultados

conocidos.

No es una ciencia. Una ciencia se caracteriza en la practica por la

repetibilidad de los resultados; y en la lógica por el progreso que puede

hacerse mediante la refutación de hipótesis. La MSS no asegura esta

prescripción. No pude esperar u obtener resultados repetibles en sistemas de

actividad humana, y la idea de hacer progresos mediante la refutación de

hipótesis es inaplicable.

No es una búsqueda de optimización; busca que es conveniente para las

personas interesadas en ser “mejores”. El deseo irrazonable de soluciones

optimas en los sistemas de actividad humana quedara insatisfecho.

No es utópica. No requiere de una definición de objetivos y metas finales,

son un aclaramiento de propósito continuo.

No es una metodología de diseño de sistemas, sólo de construcción de

modelos conceptuales, y diseño de cambios.

La metodología intenta hacer frente al hecho de que la solución de

problemas es dependiente de la estructuración de los problemas. Busca ser

no reduccionista solamente proveer una estructura dentro de la cual muchos

aspectos de las situaciones problema puedan ser adaptados. Esto permite a

las personas involucradas con un problema de toma de decisiones aspirar a

resolverlo, aliviarlo o eliminarlos.

METODOLOGÍA DE LOS SISTEMAS SUAVES

Documents