Você está na página 1de 24

Metodologa de Sistemas Suaves

Dale Couprie Alan Goodbrand Bin Li David Zhu


Universidad de Calgary

Traduccin e interpretacin de Juan Antonio del Valle Flores

Resumen.
o

Este documento trata de la Metodologa de Sistemas Suaves tal


como fue concebida por el Profesor Peter Checkland. Esta
metodologa es una manera de ocuparse de situaciones problema en
las cuales hay un alto componente social, poltico y humano en la
actividad, es el caso de la Planeacin. Esto distingue a la SSM de
otras metodologas que se ocupan de problemas duros, de
orientacin ms tecnolgica.

Introduccin
Los problemas duros son problemas caracterizados por el hecho de
que estan bien definidos. Se asume, en ellos, que hay una solucin
definida y que se pueden definir metas numricas especficas a ser
logradas. Esencialmente, con un problema duro se puede definir qu
tipo de resultado se lograr antes de poner en ejecucin la solucin.
Los " QU " y " los CMO " de un problema duro pueden estar
determinados previamente en la metodologa.
Los problemas suaves, por otra parte, son difciles de definir.
Tienen una componente social y poltica grande. Cuando pensamos
en problemas suaves, no pensemos en problemas sino en situaciones
problema. Sabemos que las cosas no estn trabajando de la manera
en que lo deseamos y queremos averiguar porqu y vemos si hay
alguna cosa que podamos hacer para aliviar la situacin. Una
situacin clsica de esto, es que tal vez no sea un " problema " sino
una "oportunidad", como es el caso de un proyecto a planear.
La metodologa de sistemas suaves fue desarrollada por Peter
Checkland para el propsito expreso de ocuparse de problemas de

este tipo. l estuvo en la industria por aos trabajando con


metodologas de sistemas duros. l vio cmo stas eran inadecuadas
al ocuparse de problemas complejos que tenan un componente
social grande; as en los aos 60, l ingres a la Universidad de
Lancaster, localizada en el Reino Unido, en una tentativa de
investigar esta rea y de ocuparse de estos problemas SUAVES. Su
"metodologa de sistemas suaves" ["Soft Systems Methodology"]
fue creada en base a la investigacin en un gran nmero de
proyectos de la industria y su aplicacin y refinamiento se
concluyeron aos despus. La metodologa, que es muy agradable
cmo lo sabemos hoy, fue publicada en 1981, cuando Checkland
viva de la universidad y tena pensado perseguir una carrera como
profesor e investigador.
SSM se divide en siete etapas distintas. stas son;
1. El encontrar hechos de la situacin problema. sta es una
investigacin bsicamente en el rea del problema. Quines
son los jugadores claves? Cmo trabaja el proceso ahora ?
etc.
2. Expresar la situacin problema con diagramas de Visiones
Enriquecidas. En cualquier tipo de diagrama, ms
conocimiento se puede comunicar visualmente. Un dibujo
vale ms que 1000 palabras.
3. Seleccionar una visin de la situacin y producir una
definicion raz. Puede qu existan perspectivas diferentes al
mirar la situacin problema.
4. Modelos conceptuales construidos de lo que hace, las
necesidades del sistema para cada una de las definiciones
raz. Usted tiene bsico " los qus" de las definiciones de la
raz. Se definen "los cmo".
5. Comparacin de los modelos conceptuales con el mundo
verdadero. Compare los resultados de los pasos 4 y 2 para ver
donde hay diferencias y similitudes.
6. Identifique los cambios factibles y deseables. Hay las
maneras de mejorar la situacin.
7. Recomendaciones para tomar la accin que mejore la
situacin problema. Cmo usted pondra prctica los
cambios del paso 6.

Cuadro 1.Mapa de la Metodologa de los Sistemas Suaves.


Este es un enfoque iterativo. Varias iteraciones de estos siete pasos se requieren a
veces para producir buenos resultados.
El resto de este documento presentar los detalles de cada uno de las siete
etapas. Despus de esto se muestran los detalles de un caso especfico en que
Checkland particip dentro del Shell Group en el UK. Este estudio de caso
implic una revisin importante de las Funciones de Manufactura de Shell y se
llev a cabo a finales de los aos 80. Checkland, mismo, se refiere a este
proyecto como un ejercicio maduro de la Metodologa de Sistemas Suaves.

Etapa 1: Situacin problema no estructurada.


La etapa inicial consiste simplemente en que los encargados y/o los empleados
(propietarios del problema) deciden que son requeridos una revisin o un cambio

de tareas y la manera en que debe realizarse y llaman a un analista (facilitador del


problema). La gente de la organizacin acepta que puede haber un problema o
ven una posibilidad de mejorar y son de la idea de que se inicie el anlisis o la
revisin. La metodologa de sistemas suaves aporta en principio que el trmino
'el problema'es inadecuado porque hace que se minimice la visin de la situacin.
La metodologa de los sistemas suaves cree que 'la situacin problema' es un
termino ms apropiado puesto que puede haber muchos problemas que tienen la
necesidad percibida a ser solucionados.

Etapa 2: Situacin problema expresada.


La etapa 1 incluy bsicamente las problemticas, lo que la gente de la
organizacin sospecha que puede haber un problema y/o un posibilidad para la
mejora, y pide iniciar el anlisis o la revisin. En la etapa 2, el analista recoge y
clasifica la informacin y prov una cierta descripcin de la situacin problema.
Lo siguiente es la informacin que estamos buscando:

la estructura de la organizacin: esos factores que no cambian fcilmente


(las construcciones, las localizaciones, el ambiente, etc);
procesos o transformaciones que se realizan dentro del sistema: muchos de
stos estn cambiando constantemente;
hechos que son expresados o sentidos por los miembros de organizacin
(quejas, crticas, sugerencias, etc).

Hay muchas estrategias que los analistas pueden emplear cuando recogen los
hechos, ms all de enfoques muy informales, no estructurados a las
herramientas hasta las muy formales, estructuradas empleadas en anlisis
tradicional de los sistemas. Algunas de las tcnicas son:

Observacin del trabajo:


o identificacin de las tareas realizadas
o identificacin de las herramientas empleadas
o establezca las interacciones entre personas/sistemas
o produzca registros, anote.
o descripciones de un"da en la vida "
o haga los grficos de estructuras/layouts
o grabaciones video, si es posible.
o recoja las muestras de las herramientas usadas para manejar la
informacin
o coleccione la observacin de cada participante

Entrevistas:


o
o
o
o
o

no estructurada, informal ("dgame lo que usted hace")


semi estructurada (cuestionario con respuestas ampliables)
altamente estructurada (cuestionario con rectngulos a hacer tictac)
incidentes crticos
grabacin audio

Talleres y discusin:
o talleres futuros
o talleres de la revisin
o talleres de las resoluciones del conflicto
o la mofa sube, las simulaciones, juegos de la mente

La etapa 1 y la etapa 2 son una fase de la 'expresin' durante a la cual una


tentativa se hace para construir la posible visin enriquecida, no 'el problema'
sino la situacin que all se percibe como problema. Es muy importante no
reducir nuestro alcance de la investigacin demasiado rpido. Si seleccionamos
un enfoque muy estructurado tal como un cuestionario bien escogido mltiple al
principio de nuestro estudio, y construimos un modelo en base de esos resultados
solamente, excluimos probablemente mucha de la informacin que podran ser
relevante. Pues una estrategia general, por lo tanto, es mejor emplear una
seleccin no estructurada tcnicamente desde el principio, y emplear ms bien
tcnicas estructuradas despus de que una primera impresin del problema se
haya definido, con el fin de sacar la informacin detallada o de
controlar suposiciones. Las tcnicas especficas se deben seleccionar siempre
para caber adentro con el trabajo de la organizacin, y cada una que est
proveiendo la informacin debe ser informada acerca de cul es el propsito del
anlisis.
Cuando un analista saca la informacin de los miembros de una organizacin,
ste se comunica con ellos usando el lenguaje natural (espaol). Esto plantea
nmerosos problemas y potenciales trampas. El analista debe estar preparado
para aceptar que en esta etapa, la informacin obtenida es incompleta y contiene
contradicciones y ambigedades. El sistema al cual estamos mirando es un
sistema suave y por lo tanto la informacin acerca del sistema es probable que
sea cualitativa ms bien que cuantitativa.
La Visin Enriquecida.
La visin enriquecida se utiliza para proveer un modelo para pensar acerca del
sistema y para ayudar al analista a obtener una apreciacin de la situacin
problema. Es importante notar la diferencia entre visin enriquecida y modelo

formal. La visin enriquecida no procura modelar al sistema de una manera


particular. Provee una representacin de cmo podemos mirar y pensar acerca el
sistema. sta puede ser refinada conforme nuestra comprensin del sistema llega
a ser ms clara, dado qu deseamos hacerla ms clara. La visin enriquecida
mostrada en el cuadro 4 se basa en el estudio del caso Shell "Repensando una
funcin de servicio del grupo Shell ". El crculo representa el lmite del sistema,
los crculos pequeos representan a los componentes del sistema, mientras que
aquellos crculos del exterior son las entidades externas con las cuales el sistema
intercta. Las burbujas representan a las ideas actuales de la gente, en ese grupo
de servicio: deseaban saber que tan buena era su organizacin y cmo evaluar su
funcionamiento actual porque deseaban mejorla.
La visin enriquecida es una expresion intelectual e individualista, y por lo tanto
no se puede calificar de "correcta" o "incorrecta". Sin embargo, la visin
enriquecida debe representar a la estructura, a los procesos y a los hechos de la
organizacin que podran ser relevantes en la definicin de problema, y debe
intentar dar una impresin del clima de la organizacin. Cada analista o equipo
desarrollar a su propio estilo la visin enriquecida. Se puede comenzar con la
gente o las localizaciones; puede poner objetos, items o hechos o dgitos binarios
para intentar agruparlos o encerrarlos en la estructura. La visin enriquecida no
es un mapa del modelo del sistema (que se genera en fases posteriores), ni
tampoco debe ser un organigrama (la clase de mapa de jerarqua de gestin que
las organizaciones utilizan a menudo para describirse a s mismas).
Los hechos obtenidos se pueden poner en un ndice o agrupar segn temas o
causas. En estudios grandes, las herramientas computarizadas tales como una
base de datos o un sistema de hipertexto se pueden utilizar para guardar y
manejar la informacin obtenida.
La necesidad siguiente del anlisis de ser realizado en un visin enriquecida para
la situacin problema expresada:

El rol del anlisis de la intervencin, es un anlisis que identifica


deliberadamente las hechos encontrados implicados en la situacin y que
se piensan como problemticas.
El anlisis social, identifica las misiones de la gente completa de la
organizacin, las normas del comportamiento segn visualizacin de esa
gente y los valores por los cuales su comportamiento es juzgado.
el anlisis del poder, se refiere a hechos tales como 'cules son los objetos
del poder en esta situacin' , 'cul es la materia obtenida' , y 'cmo es la
materia pasada'

Ilustracin Global de las etapas 1 y 2 de la SSM.


Un diagrama de la transformacin fue producido para ilustrar la primera etapa 1
y la etapa 2 en SSM como el mostrado en el cuadro 2:

Cuadro 2: Proceso de transformacin para producir una Visin


Enriquecida.
La ayuda del propietario del problema es la entrada de informacin al proceso. El
facilitador de problema realizar el anlisis del sistema suave y terminar
satisfactoriamente con una Visin Enriquecida como produccin de este
proceso de transformacin. El analista utilizar la Visin Enriquecida. para
ayudarse en su comunicacin con el propietario del problema. ste le notificar
del conflicto observado del personal y la funcin. La Visin Enriquecida se
utiliza para identificar problemas e informar al propietario de la situacin
problema ms bien que proverle de la solucin posible.
Trampas que necesitan ser evitadas

Las trampas siguientes necesitan ser evitadas durante la etapa inicial de SSM:

No reducir el alcance de la investigacin muy al principio.


La visin enriquecida se ensambla sin la imposicin de una estructura
y/o de una solucin determinada a la situacin problema.
Pueble tienen difcil de interpretar el mundo de la manera floja, y muestran
a menudo un deseo concludo-urgente para la accin.
No presionar el anlisis en trminos de los sistemas en todos.
Advertir que habr muchas versiones posibles del sistema.

Etapa 3: Nombramiento de los Sistemas Relevantes.


Definiciones raz.
Es necesario prestar atencin a la formulacin del nombramiento de los sistemas
relevantes para escribirlos de manera que un modelo pueda ser construido basado
en cada nombramiento. Estos nombramientos se conocen como Definiciones
Raz. El propsito de la definicin raz es expresar el propsito central de un
cierto sistema til de actividad. Es importante que se ponga atencin en el
desarrollo de las definiciones raz. Las definiciones raz correctamente escritas
proveen una directriz mucho ms simple en la construccin del modelo de un
sistema.
Una definicin de raz se expresa como un proceso de la transformacin que
toma una entidad como entrada de informacin, cambia o transforma a esa
entidad, y produce una nueva forma de la entidad. Una prescripcin para
desarrollar estos procesos la transformacin se muestra en la siguiente tabla, que
muestra ejemplos de transformaciones tpicas de la operacin de un curso de
golf. Como usted puede notar, estas transformaciones variarn grandemente,
dependiendo de la opinin del mundo que se aplique.
ENTRADA DE
INFORMACIN

PRODUCCIN

COMO ES VISTO A
LOS OJOS DE:

Pista inusitada

Pista ocupada por curso


del golf.

Arquitecto.

Necesidad por
tiempos de la te.

La necesidad por tiempos


de la te se resuelve.

Gestin Del Club.

Bolas nuevas del golf.

Utilizado, rascado encima


Industria del equipo.
de bolas del golf.

Germen de la hierba

Hierba madura.

Greenskeepers

Alimento crudo.

Comidas de calidad.

Cocinero de la
cocina.

Golfer registrado.

Golfer que termin


alrededor en X frota
ligeramente.

Favorable personal
del departamento.

Programa de la
leccin del golf.

Programa facilitado de la
leccin.

Profesional del Club.

Tabla 1. Transformaciones una a una que implican opiniones diferentes del


mundo.
Producir una definicin de raz es un proceso progresivo de dos pasos.
1. Un hecho o una tarea se elige de una visin enriquecida
2. Se define un sistema para realizar la tarea o para dirigir los hechos.
Cada definicin raz implica dos cosas importantes. Lo primero es que debemos
implicar cierta visin del mundo. La definicin de la opinin del mundo no es
siempre trivial. Tambin, no es deseable definir todas las opiniones del mundo.
Recuerde que cada visin enriquecida implicar una variedad de opiniones del
mundo. Los ojos pueden venir de fuentes tales como oficiales del gobierno,
ejecutivo de compaas, encargados del proyecto, empleados, clientes,
competidores y medios de noticias. Cada una de estas opiniones del mundo ser
conectada a unas o ms definiciones raz distintas.
Es importante prestar la atencin a la cardinalidad del proceso de la
transformacin. Cada definicin raz implica una transformacin de una entrada
en una produccin. Suponga que definimos una transformacin como el "
equipamiento de golf " ms " curso del golf " ms " mano de obra " (tres entradas
de informacin) para producir "necesidades de golf puestas" ms "mercado de
golf servido" (dos producciones). Esta transformacin " tres a dos " es ambigua,
pero se puede resolver con muchas transformaciones una a una que se
correspondan ms claramente (el equipamiento de golf se transforma en
equipamiento de golf usado ).
CATWOE
Las definiciones de la raz se escriben como sentencias que efectan una
transformacin. Hay seis elementos que hacen a una definicin raz bien
formulada, que se resumen en la mnemnica CATWOE.

Cliente: considera a cada uno que est presto para obtener beneficios de un
sistema. Si el sistema implica sacrificios tales como despidos, son vctimas
deben tambin ser contadas como clientes.
Actor: Los actores realizan las actividades definidas en el sistema.
Proceso de la transformacin: Esto se muestra como la conversin de la
entrada de informacin a la produccin.
Weltanschauung: La expresin alemana para la opinin del mundo. Esta
opinin del mundo hace que el proceso de la transformacin sea
significativo en contexto.
Propietario:Cada sistema tiene algn propietario, quien tiene el poder para
comenzar y/o para cerrar el sistema.
Apremios ambientales: Los elementos externos que existen fuera del
sistema que se toman como dados. Estos apremios incluyen polticas de
organizacin as como materias legales y ticas.

CATWOE se utiliza principalmente con el fin de analizar las sentencias de la


definicin raz, pero se puede utilizar como bloque de construccin para derivar
la sentencia de la definicin raz si sabemos los elementos de CATWOE.
Utilizamos CATWOE como la espina dorsal para desarrollar definiciones raz
debido a que el uso de la transformacin en s misma como definicin raz se
hace difcil de modelar. La transformacin y la opinin del mundo son el centro
del CATWOE. Cada actividad se puede expresar en muchas maneras, usando
opiniones diferentes del mundo. Es una buena idea que diferentes puntos de vista
sean utilizados para desarrollar definiciones raz diferentes. CATWOE tambin
reconoce la necesidad de explicar lo relativo a propiedad, funcionamiento,
beneficiarios, vctimas y apremios externos, que son cosas importantes a explicar
en la documentacin del sistema.

Etapa 4: Modelos Conceptuales.


Dado una definicin raz de un sistema, un modelo conceptual puede ser modelo
conceptual trazado de A es un modelo humano de la actividad que estrictamente
se conforma con la definicin raz usando el conjunto mnimo de actividades.
Los pensamiento de sistemas se aplican en este desarrollo.
Pensamiento de Sistemas.

Cuadro 3. La Ruta del Pensamiento de Sistemas.


El cuadro 3 muestra que los pensamiento de sistemas es un proceso iterativo que
combina tres conceptos

El mundo percibido:Cada uno de nosotros tenemos nuestras propias


opiniones del mundo.
Ideas:Percibimos el mundo a travs del marco de ideas que estn internas
en nosotros.
Metodologa: Hay muchas de stas para pensar acerca del mundo, la SSM
es solo una.

Modelacin de Sistemas Formales


El Pensamiento de Sistemas Formal se aplica al desarrollo del modelo
conceptual. El Modelo Formal del Sistema sirve como una gua de consulta para
controlar el modelo conceptual que trazamos. Deje que S represente a un sistema
de actividad humana. Bajo el modelo de Sistema Formal, S es un sistema formal
si y solamente si cumple los criterios siguientes:
S debe tener una misin.

S debe tener una medida del funcionamiento.


S debe tener un proceso de toma de decisin
S debe tener componentes que interactuan con unos con otros tal que los
efectos y acciones son transmitidos a travs del sistema.
S debe ser acotado por un sistema ms amplio con el cual interactua.
S se debe limitar del sistema ms ancho, basado en el rea donde su
proceso de toma de decisin tiene poder para hacer cumplir una accin.
S debe tener recursos a disposicin de su proceso de toma de decisin.

S debe tener estabilidad a largo plazo, o la capacidad de recuperarse en el


caso de un disturbio.
Componentes de S deben ser sistemas que tienen todas las caractersticas
de S (subsistemas).

El modelo conceptual se puede escribir como grfico dirigido, similar a una


grfica PERT. Los nodos en el grfico son actividades que se harn. Estas
actividades se basan en los verbos de la definicin raz. La estructuracin del
sistema se basa en la dependencia lgica. Las dependencias lgicas se muestran
como arcos en el grfico. Un arco en el grfico significa que la actividad de la
fuente es un requisito previo para la actividad de la destinacin.
El modelo conceptual para un sistema consiste de un sistema operacional que se
cubra - pero limitado por - un proceso de monitoreo. Este sistema operacional
consiste en una actividad central y algunas actividades prerequisitos se requieren
tal que la actividad central pueda ser hecha. La psicologa cognoscitiva sugiere
que el cerebro humano pueda hacer frente a 7 +/- 2 conceptos al mismo tiempo.
Por lo tanto, debemos apuntar tener 7 +/- 2 actividades dentro de cada sistema
operacional. Si esta gua de consulta conduce a actividades que estn en un nivel
demasiado alto, esas actividades se pueden ampliar a otro nivel. Puesta
simplemente, cada actividad general se convierte en una fuente para que una
definicin raz sea ampliada al nivel siguiente.
Monitorear un sistema.
Monitorear un sistema operacional consiste en tres actividades:

Defina una medida del funcionamiento: Podemos utilizar cualesquiera o


las tres para la medida del sistema operacional

Eficacia - trabaja
o Eficiencia - cunto del trabajo termin con los recursos consumidos
dados
o Eficacia - son las metas satisfechas.
Monitorear las actividades en el sistema operacional, de acuerdo con la
mtrica definida en etapa 1.
Tomar la accin del control: Utilice los resultados de estas mtricas para
determinar y para ejecutar la accin que controle al sistema operacional.
o

Sin embargo las tres e mostradas arriba no son las nicas mtricas que pueden ser
utilizadas. Muchas firmas utilizarn mtrica incluyendo las mtricas econmicas,

ticas , elegantes, y otras que pueden ser dependientes en el contexto del trabajo
que es hecho.

Etapa 5: Comparar modelos conceptuales con realidad


sta es la etapa de regreso al mundo verdadero, pasando sobre la lnea punteada.
En esta etapa, los modelos conceptuales construidos en la etapa 4 sern
comparados con la expresin verdadera del mundo, de la etapa 2. El trabajo
puede conducir en esta etapa a la reiteracin de la etapa 3 y la 4. Previa
experiencia anterior de usar SSM indic que la comparacin no es de hecho una
comparacin propiamente dicha. Esto ser discutido ms adelante. Basado en el
anlisis razonado de esta metodologa, hay cuatro maneras de hacer la
comparacin del nmero de experiencias.
Antes de que se realice la comparacin, varios otros aspectos necesitan ser
mencionados. La primera pregunta es cul es el fin de la etapa 4. Cuando deber
ser tiempo de parar de construir el modelo conceptual y de moverse a la
comparacin verdadera del mundo. La tentacin siempre es complacer la
prolongacin y elaboracin de la construccin del modelo. Es divertido trabajar
en modelar y no es tan cmodo traer al modelo a la realidad y engancharse con
las dificultades de las situaciones del problema. De hecho, de la experiencia de
Checkland, es mejor moverse rpidamente a la etapa de la comparacin. Se
permitir refinar el modelo posteriormente cuando tenga que ir de nuevo a la
etapa de la conceptualizacin otra vez.
Antes de que resumamos la etapa 5 de SSM, necesitamos entender la definicin
de comparacin. Generalmente, comparacin es una parte importante del
pensamiento racional y serio que contiene percibir, predecir y comparar. En
SSM, Checkland define la comparacin como el punto que las opiniones
intuitivas del problema son reunidas con las construcciones de los sistemas por lo
que los pensadores de sistemas afirman proveer una profundidad epistemologica
y ms generalidad de la realidad debajo de los aspectos superficiales; es la etapa
de la comparacin la que incorpora las hiptesis bsicas de los sistemas que los
conceptos de los sistemas proveen un medio de prueba de la complejidad de la
'realidad' .
Cuatro maneras de hacer la comparacin pueden ser resumidas como sigue:
1. Usar los modelos conceptuales como base para cuestionamientos
ordenados

ste es un tipo de comparacin que puede ser hecha cuando la situacin


verdadera del mundo es muy diferente del modelo conceptual. Los modelos del
sistema se utilizan para abrir un debate acerca del cambio. El modelo se utiliza
como fuente de preguntas acerca de la situacin existente. Se anotan y se
contestan las preguntas sistemticamente. Las respuestas a las preguntas pueden
proveer la iluminacin al problema percibido.
2. Comparar historia con prediccin del modelo
Otro mtodo de comparacin es hecho reconstruyendo una secuencia de eventos
en el pasado y comparando qu habra sucedido en producirla con lo que habra
sucedido si lo modelo conceptual relevante han puesto en ejecucin realmente.
De esta manera, el significado de los modelos puede ser exhibido y satisfactorio
de la comparacin puede ser alcanzado. Basado en experiencia de Checkland,
esto es un mtodo usado con xito para un consultor que dese saber porqu uno
el suyo estudia para un cliente haba sido un incidente espectacular. En que el
caso, el contenido entero del estudio era historia, y el anlisis compar la historia
como recordada y registrada en ese entonces por los participantes, con un modelo
de sistema de la interaccin de consultant/client. Checkland tambin advirti que
este mtodo de comparacin fuera utilizado cuidadosamente de modo que pueda
revelar las insuficiencias del procedimiento real y pueda ser interpretado como
recriminacin ofensiva referente a su ltimo funcionamiento.
3. Comparacin Total General
Checkland sugiri que en la ilustracin de la metodologa en su totalidad, sea
generalmente apropiado a la comparacin de la etapa 5 general, preguntando qu
caractersticas de los modelos conceptuales son especialmente diferentes de la
actual realidad y porqu. Esta comparacin tambin se discute generalmente con
" cul est " y "Hows" por Checkland. Es la distincin entre 'qu y' cmo cul
hace la palabra 'comparacin' una descripcin algo cruda de lo que est
sucediendo en la etapa 5. Checkland precisa que en la etapa 5, tenemos modelos
de sistemas disponibles que ellos mismos derive del nombramiento cuidadoso, en
definiciones de la raz, de los sistemas humanos de la actividad que esperamos es
relevante a la situacin problema y a su mejora. En la etapa 5, examinamos los
modelos junto a la expresin de la situacin ensamblada en la etapa 2. que la
comparacin entre los dos es la estructura formal de los cambios acerca de
posibles de una discusin, una discusin del problema celebrada con la gente en
cuestin en la situacin problema. Para que la discusin sea rica y de amplia
extensiona, deseamos preguntar as como si las varias actividades en los modelos
perceptibles en el mundo verdadero, - si ella est presente - cmo est bien la
estn haciendo. Tambin deseamos discutir alternativas posibles a las actividades

verdaderas del mundo. Veremos cmo esta comparacin ser realizada en un


estudio de caso ilustrado ms adelante. Aqu la comparacin de amplia
extensiona con excepcin de como con como se acenta y ahora podemos ver
porqu la etapa 5 no es una comparacin directa.
4. Recubrimiento Modelo
El cuarto mtodo de hacer la etapa 5 es referido como " recubrimiento modelo "
por Checkland. Para la comparacin, despus de terminar la conceptualizacin
basada en la definicin elegida de la raz, hicimos un segundo modelo de qu
existe. El segundo modelo tiene como cercanos como posible la misma forma
que el modelo conceptual, siendo el objetivo el de re el drenaje que modelen,
cambindolo solamente donde la realidad diferenci del modelo conceptual. Con
este mtodo, el recubrimiento directo de un modelo en el otro entonces revel la
discordanca que es la fuente de la discusin del cambio. Con este mtodo,
preguntas tales como qu definicin raz es implicada por este sistema? Cmo
compara con el que era la base de la conceptualizacin en la etapa 4?
Los cuatro mtodos pueden ayudar a asegurar la comparacin en la etapa 5 son
conscientes, coherentes y defendibles. Dependiendo de los problemas percibidos,
el mtodo determinado se puede utilizar para hacer la comparacin, o todas las
clases de comparacin se pueden realizar con todos estos cuatro mtodos. Para el
sistema existente, la comparacin puede ser hecha con qu existe, pero para un
nuevo sistema, la comparacin no puede estar con qu existe, slo con una cierta
expectativa redefinida. En este caso, la experiencia anterior implic que el
incrementalism y el ensayo y el error son el enfoque mejor.

Etapas 6 y 7: Poner cambios en ejecucin 'factibles y


deseables'
En la etapa 6, se identifican y se discuten los cambios factibles y deseables, y
sern puestos en la accin en la etapa 7. que el propsito de la etapa de la
comparacin es generar los cambios acerca de posibles del discusin que se
pudieron realizar dentro de la situacin percibida del problema. Esto se puede ver
claramente con el segundo mtodo de hacer la comparacin como discutido
arriba.
El resultado de la etapa 6 y 7 para el sistema duro y suave ambos es la creacin y
la puesta en prctica de un sistema. Generalmente, en estas situaciones ms
nebulosas del problema, la accin eventual es probable sea menos que la puesta

en prctica de un sistema, es ms probable que halla la introduccin de un


cambio ms modesto.
Normalmente, hay tres clases de cambios:

cambio en la estructura, son cambios realizados a esas partes de realidad


que en corto plazo, en el funcionamiento que contina de cosas, no
cambian.
cambio en el procedimiento, que son cambios a los elementos dinmicos
cambio en la actitud, que es comportamiento apropiado a las varias
misiones, as como cambios en la preparacin a ciertas clases de
comportamiento 'bueno' o de 'malo' concerniente a otros.

Los cambios en estructura y procedimiento son fciles de especificar y


relativamente fcil poner en ejecucin. Por lo menos, stos se pueden hacer por
la gente que tiene autoridad o la influencia. Es relativamente difcil cambiar
actitud. Es posible en principio intentar traer acerca de cambios de esta clase. Si o
no esto est procurada, el esencial principal debe continuamente vigilar actitud si
se van los cambios a ser hechos en las situaciones percibidas como problemas de
modo que la gente en cuestin en la situacin convenga que se ha logrado la
mejora . Una de las caractersticas importantes en SSM es l nfasis en cambio.
Otra caracterstica importante de SSM es la meta conducida, se concentra en un
sistema deseable y cmo alcanzarlo. Checkland indic que los cambios deben ser
sistemticamente deseables como resultado de la penetracin ganada de la
seleccin de las definiciones raz y de la construccin del modelo conceptual, y
deben tambin ser culturalmente factibles dadas las caractersticas de la
situacin, de la gente en ella, de sus experiencias compartidas y de sus prejuicios.
Es duro encontrar cualquier cambio que no resuelvan ambos criterios . Checkland
encontr en uno de sus estudios de casos que es importante moverse rpidamente
y ligeramente a travs de todas las etapas metodolgicas, varias veces en caso de
necesidad, para ser un puente del tcnico entre los 'qu y 'qu pudo ser' . l
tambin sugiri que para poder tener que incorporar la 'raz obligramos a
comprometer una situacin que propuso cambios tenga que ser cambiante debido
a la influencia del poder.
El empleo en la etapa 7 debe poner cambios en ejecucin y ponerlos en la accin.
Cuando se toma la accin, puede ser que sea directa. Sin embargo, otras
situaciones pueden ser encontradas. La introduccin de la accin puede cambiar
la situacin de modo que aunque se ha eliminado el problema originalmente
percibido , emerja el nuevo problema. Se recomienda a menudo que un sistema
temporal est utilizado para realizar la tarea bajo supervisin del analista, seguida

por una transicin a la operacin del nuevo sistema. Checkland precis que esta
metodologa tiene de hecho no emergente mientras que un acercar algo defini de
una vez por todas sostenidamente como problema, pero percibi como problema.

Estudio de un Caso - revisin de la funcin de servicio del


Grupo Shell
Este estudio de caso fue conducido por Checkland y ordenado junto con la
gestin de shell. ste es tambin el estudio de caso para ilustrar cada etapa
individual de la SSM.
Etapas 1 y 2.
Un grupo del servicio en el shell, funcin de manufactura (MF), provee varios de
los servicios para el otro grupo en shell con objeto de ayudarles a tomar la
decisin para el desarrollo futuro. El MF se ha estado ejecutando durante mucho
tiempo, y la gente piensa que es tiempo para ella de repensar su papel en Shell y
cmo hacer su funcionamiento mejor. As, la situacin problema para ella ser
que tan bueno es se ordene nuestro sistema actual y cmo evaluar nuestro
funcionamiento del sistema?, Podemos hacerlo mejor? Un visin enriquecida
fue producida para esta situacin problema en el cuadro
4.

Cuadro 4. La visin enriquecida de MF de shell.


ETAPA 3:Nombramiento de Sistemas Relevantes.
Es shell una compaa que cambia y este cambio requiere el entrenamiento
constante de empleados. Los modelos discutidos en la discusin de las etapas 3 y
4 fueron preparados por General Workshop II y se basan en el concepto de
entrenamiento siguiente

Cuadro 5. opinin del mundo del entrenamiento de Shell's MF .


A los ojos del ejecutivo de la compaa, se consideran dos necesidades: una
necesidad del personal entrenado con maestra de la fabricacin as como tener
esta maestra en otras funciones. La manera mejor de resolver la necesidad deba
inyectar a aprendices en el volumen de trabajo normal, entrenndoles con
situaciones verdaderas de la vida. Vienen de fuera bien enseados y pueden ser
empleados en otras funciones.
Una definicin raz para un sistema de entrenar de acuerdo con este concepto es
como sigue:

MF poseia y provey de personal al sistema que, en respuesta a una


necesidad continua de personal de la ms alta calidad para mantener y
manejar las operaciones de la fabricacin del Groupo Shell , y una
necesidad de fabricar maestra en otras funciones, desarrollar y entrenar a
gente y proverla de experiencia de una manera rentable, dentro de los
apremios impuestos por MF realizando sus tareas centrales como
proveedor y tecnologa del servicio.

El anlisis de CATWOE para esta definicin raz es como sigue:

C: sos entrenaron; a travs de ellos, la compaa

A: MF Personnel
T: La necesidad de gente experimentada entrenada es tranformada a una
necesidad satisfecha.
W: El entrenamiento puede emerger de hojas de operacin (planning)
cuidadosas del trabajo de MF con objeto de proveer experiencia
conveniente.
O: MF
E: tareas centrales de MF

Nota cmo la opinin del mundo de esta transformacin hace cumplir el


entrenamiento a travs de las manos en experiencia.
Etapa 4: Modelos Conceptuales.
De raz la definicin viene este modelo
conceptual.

Cuadro 6. Shell's MF que entrena al modelo conceptual.


Este modelo consiste en un modelo operacional que se vigila en dos niveles
diferentes. La actividad central de este sistema operacional es personal de la tarea
6 (Assign MF a las tareas). No obstante ser capaz de hacer esta tarea requiere con
eficacia muchos de entender, que se cubre en las tareas 1 a 5. Necesitamos saber
acerca de el ambiente que cambia del shell y requisitos en curso de la tarea de
MF. Estos requisitos llenan una necesidad de la maestra en MF y otras
funciones. Tambin necesitamos saber la experiencia del personal existente y
nuevo de MF. Una vez que se llenen esos requisitos, se termina la asignacin de
la tarea. La asignacin de la tarea tambin tiene una produccin, que es una lista
de las habilidades y de la experiencia recibidas por personal de MF como
resultado de hacer tareas asignadas. stos se deben registrar y apreciar en las
asignaciones futuras de la tarea.
Dos niveles de vigilar se toman en este modelo, pero notar cmo este proceso
sigue las guas de consulta de " mtricas, de vigilar, y de la accin del control ".
El sistema operacional es vigilado por el grupo de MF, y estn utilizando eficacia
y eficacia como sus medidas de funcionamiento. El segundo nivel de vigilar se
hace en un nivel del managment, cuya medida de funcionamiento es la
rentabilidad.
Etapa 5: Comparar modelos conceptuales con realidad
Para una investigacin cmo fue utilizadala en etapa 5 , vamos al taller general I.
Este taller deba discutir el desarrollo de la tecnologa en Manufacturing Function
(MF) de Shell Group. La definicin raz se afirma como un sistema provisto de
personal que a MF le maneje los lazos entre sos implicados en tareas de MF
para lograr una organizacin, no hecha fragmentos flexible que haga un impacto
en negocio del shell ". CATWOE fue utilizado para trazar esta definicin raz y
un modelo conceptual fue construido para esta definicin basada en la edicin de
la raz. Despus de que el modelo conceptual fuera construido, un formato
especial fue utilizado para realizar la comparacin. Este formato se muestra
abajo. Comparando las actividades en las actividades modelo y existentes, el
modelo fue evaluado y los alternativas fueron sugeridos.
Actividad
en modelo

Exista?

Acumule el
depsito de S
la habilidad

Cmo?

Quin?

Bueno/Malo Alternativas?

Discusin
y accin
de la
gestin

gestin de
MF,
Bueno
personal de
Shell

Contratista

Corporation
Determine
la naturaleza
S
de la accin
necesitada

discusin
de
MF/Shell gente de
Co.
MF y de
vario
Shell Co.
informal
formal

Decida el
alcance y la
profundidad No
de la
formalmente
habilidad
acumulacin

Bueno en
general

Ningn
alternativa

Malo

Ejercicio
especial,
destacamento
de fuerzas,
regularidad
de la base de
datos puesta
al da

Vector 2. Shell's Comparison con realidad.


Etapa 6 y 7: Poner cambios en ejecucin 'factibles y deseables'
En este estudio de caso, despus de comparar modelos, los cambios deseables y
factibles haban sido identificados. Son:
1. Manteniendo y poniendo al da un depsito de los 'conocimientos tcnicos'
2. Objetivos relevantes y programas de R&D que se convierten
3. Crear opciones del negocio en base de la nueva o mejorada tecnologa

Observaciones y conclusiones
Peter Checkland afirma en su libro " pensamiento de sistemas, prctica de los
sistemas " ["Systems Thinking, Systems Practice"], " la complejidad del universo
est ms all de expresin en cualquier notacin posible ". La metodologa de los
sistemas suaves es una tentativa de aplicar ciencia a los sistemas de actividad
humana. Por la misma naturaleza de estos sistemas, Checkland admite que
cualquier metodologa ser inadecuada, pero so no significa que sea intil.
Examinando los sistemas de Actividad Humana de esta manera, podemos trazar
cierta interaccin y opinin vitales del conocimiento acerca de. Este
conocimiento nos ayudar en entender mejorar a estos sistemas.

Fue afirmado en el principio que SSM era un enfoque iterativo. Checkland


afirma que la metodologa actual se ha desarrollado despus de que cerca de 50
aplicaciones se han tan obviamente no solamente el uso de la metodologa
iterativa pero tambin es l es crecimiento. Esto es debido a la naturaleza de los
tipos de situaciones problema que se significan por tratar con problemas
estructurados y mal definidos de la enfermedad con un componente social
grande. La ventaja principal de la metodologa es que da la estructura a estos
tipos o a la situacin problema que puede permitir que sean ocupados adentro de
una manera ordenada. Fuerza el desarrollador para buscar una solucin que sea
ms que tcnica.
Varios personas estn conduciendo actualmente la investigacin en maneras de
superar los problemas inherentes con SSM. Hay investigacin en curso en el
University of Ulster que se ocupa del realce de SSM con tcnicas de Formal
Methods y de Risk Analysis. Un enfoque ms prctico debe utilizar SSM para
generar las preguntas DURAS que se pueden entonces tratar por de,
metodologas ms tradicionales, MS DURAS.
Ejercicio para SSM
Objetivo: Este ejercicio se disea para ayudarle a tener una buena comprensin de cul es
SSM y de cmo utilizarlo en la prctica.
Recuerde: No hay respuesta'correcta' o 'incorrecta' para este ejercicio, qu usted necesita
presentar es su pensamiento acerca de de la situacin problema y de un modelo de sistema
relevante para su pensamiento. Hay cinco requisitos para este ejercicio, hace tanto como
usted puede en el plazo de 20 minutos. Si usted necesita las indirectas para estas preguntas,
refiera por favor el apndice.

Situacin del problema:

Una sociedad coral local de Calgary tiene siempre la dificultad en la


obtencin de los nombramientos para sus oficiales y comit y la atraccin
de la gente a la participacin en trabajos relacionados corales. Pues es una
sociedad de ejecucin un nmero de tareas no corales deben ser
manejadas. Cmo poda esta dificultad ser dirigida y ser examinada?

Requisito 1: Utilice una visin enriquecida para dirigir la etapa expresada


situacin del " problema ["Problem Situation Expressed"] " en SSM para esta
situacin del problema.
Requisito 2: Defina una " definicin raz " ["Root Definition"] para esta
situacin del problema.
Requisito 3: Haga un anlisis de CATWOE en su Definicin Raz.

Requisito 4: Produzca un "Modelo Conceptual " basado en su Definicin Raz.


(las actividades por ejemplo identifican necesidades de la comunidad local,
atraen la calidad de miembro, fondos del general, atraen a audiencias se podran
utilizar para esta situacin del problema)
Requisito 5: Utilice el mtodo de la comparacin de la " visualizacin ["Tabular
Display"] tabular " para realizar la comparacin entre el mundo verdadero y el
mundo intelectual.
Resultados para la cacerola de Adi Damian, de Danfeng Hong, de Quan Li y
de Dong.
Resultados para Qian Wang, Kim Johnson, Jasper Fai, y Sheng Ouyang
Resultados para Daniela Herlea, Stephen Lam, y Micheal Wu

Referencias:
[1].Wilson, Brian (1990), Sistemas: <="" u="">. John Wiley, Nueva York
[ 2 ].
[ 3 ] Checkland, Peter y Jim Scholes (1990). Metodologa de los sistemas suaves
en accin. Toronto, John Wiley e hijos.
[ 4 ] Macaulay, Linda A (1996).Ingeniera de Requerimientos. Londres. Springer.
[ 5 ]Checkland, Peter (1981). Pensamiento de Sistemas, Prctica de Sistemas.
Londres, John Wiley and Sons.

Você também pode gostar