Metodologa de Sistemas Suaves

ndice.

Resumen. Introduccin Correspondencia Etapa 1. Situacin problema no estructurada. Etapa 2. Situacin Problema expresada. Visin Enriquecida Ilustracin de la Etapa1 y etapa 2 en su totalidad en SSM Trampas que deben ser evitadas. Etapa 3: Nombramiento de sistemas relevantes Definiciones De la Raz CATWOE Etapa 4: Modelos Conceptuales Pensamiento de Sistemas Modelo Formal de Sistemas Monitorear un sistema Etapa 5: Comparar modelos conceptuales con realidad Usar modelos conceptuales como base para preguntar pedido Comparar historia con la prediccin modelo Comparacin Total General Recubrimiento Modelo Etapas 6 y 7. Poner cambios factibles y deseables en ejecucin Estudio de un Caso - revisin de una funcin de servicio en el Grupo Shell Etapas 1 y 2 Etapa 3: Nombramiento de sistemas relevantes Etapa 4: Modelos Conceptuales Etapa 5: Comparar modelos conceptuales con realidad Etapas 6 y 7. Poner cambios en ejecucin factibles y deseables Observaciones y conclusiones Ejercicio Referencias

Resumen.
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. 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 pueden estar 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 duras. 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 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;

11

11

11

11

11

11 11

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. 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. Seleccionar una visin de la situacin y producir una definicion raz. Puede qu existan perspectivas diferentes al mirar la situacin problema. 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". 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. Identifique los cambios factibles y deseables. Hay las maneras de mejorar la situacin. 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 o o o o o

produzca registros, anote. descripciones de un"da en la vida " haga los grficos de estructuras/layouts grabaciones video, si es posible. recoja las muestras de las herramientas usadas para manejar la informacin 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 ms rica, no 'el problema'sino la situacin que all se percibe como problema. Es muy importante no reducir nuestro alcance de la investigacin demasiado temprano. 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 los muchos de informacin que podran ser relevante. Pues una estrategia general, por lo tanto, es mejor emplear una seleccin de tcnicas no tambin estructuradas al principio, y emplea ms tcnicas estructuradas despus de que una primera impresin del problema se haya definido con el fin de sacar la informacin detallada o de controlar asunciones. 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 PRODUCCIN INFORMACIN Pista inusitada COMO ES VISTO A LOS OJOS DE:

Pista ocupada por curso del Arquitecto. golf.

Necesidad por tiempos La necesidad por tiempos Gestin Del Club. de la te. de la te se resuelve. Bolas nuevas del golf. Germen de la hierba Alimento crudo. Golfer registrado. Utilizado, rascado encima Industria del equipo. de bolas del golf. Hierba madura. Comidas de calidad. Golfer que alrededor en ligeramente. Greenskeepers Cocinero de la cocina. termin Favorable personal X frota del departamento.

Programa de la leccin Programa facilitado de la Profesional Del Club. del golf. leccin. 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. Components of S debe 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 cerca - 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 Eficiencia - cunto del trabajo termin con los recursos consumidos dados 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 o 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 sertiempo de parar la construir del 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 el 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 la 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 ser menos que la puesta en prctica de un sistema, l es ms probable a ser la introduccin de un cambio ms modesto. Normalmente, hay tres clases de cambios:

cambia en la estructura, que es cambios realizados a esas partes de realidad que en corto plazo, en el funcionamiento que contina de cosas, no cambian. cambia en el procedimiento, que es los cambios a los elementos dinmicos cambia en la actitud, que es comportamiento apropiado a las varias misiones, as como cambios en la preparacin a ciertas clases de la tarifa 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 que es meta conducida, l 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 de la raz y del edificio modelo conceptual, y deben tambin ser cultural factibles dados las caractersticas de la situacin, de la gente en ella, de sus experiencias compartidas y de sus prejudicar. Es duro encontrar cualquier cambio que no resuelvan criterios ambos. Checkland encontr hacia fuera a partir del uno de sus estudios de caso que es importante moverse rpidamente y ligeramente a travs de todas las etapas metodolgicas, varias veces en caso de necesidad, para sima bridgeable del tcnico A entre 'qu los i y 'qu pudo ser' . l tambin sugiri que poder tener que incorporar la 'raz obligramos para 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 muchos de servicio para el otro grupo en shell de ayudarles a tomar la decisin para el desarrollo futuro. El MF se ha estado ejecutando durante mucho tiempo, y la gente piensa que trata de la poca para ella de repensar su papel en shell y cmo hacer su funcionamiento mejor. As, la situacin problema para ella ser cmo es bueno es se ordene nuestro sistema actual y cmo evaluar nuestro funcionamiento del sistema? Podemos hacer mejor? Un visin enriquecida fue producido para esta situacin problema en el cuadro 4.

Cuadro 4. La visin enriquecida de MF de shell.

ETAPA 3: Nombramiento de Sistemas Relevantes.

El shell es 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 para General Workshop II y se basan en el concepto siguiente del entrenamiento.

Cuadro 5. opinin del mundo de Shell's MF del entrenamiento. De 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 fuera de bien ensen$ado y pueden ser empleadas en otras funciones. Una definicin raz para un sistema para entrenar de acuerdo con este concepto es como sigue:

Un MF posey y provei de personal el sistema que, en respuesta a una necesidad continua de un personal ms de alta calidad para mantener y manejar las operaciones de la fabricacin del Shell Group, y una necesidad de fabricar maestra en otras funciones, desarrolla y entrena a gente y provee 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 la gente experimentada entrenada es tranformed 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 vigile 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 nota 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 del funcionamiento. El segundo nivel de vigilar se hace en un nivel del managment, que medida de funcionamiento es rentabilidad.

Etapa 5: Comparar modelos conceptuales con realidad

Para una investigacin de cmo la etapa 5 fue utilizada, vamos al taller general I. Este taller deba discutir el desarrollo de la tecnologa en Manufacturing Function (MF) of Shell Group. La definicin raz se afirma como sistema provisto de personal posedo "A MF que maneje los lazos flidos 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 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 Exista? modelo Acumule el depsito de S la habilidad Cmo? Quin? Good/Bad Alternativas?

gestin de Discusin MF, y accin personal de Bueno de la Shell gestin Corporation

Contratista

Determine la naturaleza de S la accin necesitada

discusin de gente de MF MF/Shell Bueno en Ningn y de Shell Co. vario general alternativa Co. informal formal Ejercicio especial, destacamento de fuerzas, regularidad de la base de datos puesta al da

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

Malo

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 sa 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 y mejorar estos sistemas. Fue afirmado en el principio que SSM era un enfoque iterativo. Checkland afirma que la metodologa corriente se ha desarrollado despus de que acerca de 50 aplicaciones sean 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 del problema que se significa para tratar de; 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.