Soft Systems Methodology (SSM) is a problem-solving framework that helps structure thinking about complex, human problems. It involves 7 stages: expressing the problem situation, defining relevant systems, creating conceptual models of systems, comparing models to reality, and implementing feasible changes. The goal is to formulate and test ideas to improve problem situations through changes to structures, processes, and attitudes.
SSM é uma metodologia que foi desenvolvida pelo professor Peter Checkland e basicamente fornece-nos um conjunto de principios que nos ajuda a estruturar o nosso pensamento quando tentamos lidar com problemas que são por natureza complexos e tem uma componente social muito elevada.
Cerca de 1950 surgiu o chamado “system movement” como reacção à incapacidade do metodo scientifico lidar com problemas complexos e por isso irredutiveis e irrepetiveis. Este movimento assenta-se num principio de filosofia de artitotles – “O todo é mais do que a soma das suas partes”. Deste principio surgem uma seria de disciplinas e metodologias entre elas, teoria dos sistemas, sistems engineering e systems analysis. Estas metodologias e disciplinas tentam lidar com a construção e desing de sistemas, isto é, como problemas ditos hard. SSM vai beber a estas metodologias e disciplicas o seu mapa conceptual e tenta que isto seja um ponto de partida para a resolução de problemas na área de management. Claro que não foi possivel aplicar directamente o que já tinha sido desenvolvido, o proprio checkland sabia disso, e SSM surge com a alteração de tecnicas aplicas a engineirar sistemas mas aplicados a problemas relacionado com pessoas.
O diagrama da figura contém as 7 fases da metodologia de SSM. A numeração presente apenas demostra a ordem mais lógica de a explicar, na pratica esta metodologia pode começar por exemplo na fase 4 e é na verdade um process iterativo. Como podem ver estas fases estão devididas por uma linha que dita o seguinte: as fases a cima da linha são executadas no mundo real, e por isso são feitas com as pessoas que estão de alguma forma envolvidas na situação ou q tem interesse em resolver a situação e usam uma linguagem apropriada para interargir com humanos; as fases da linha de baixo é onde se aplica os principios da área de systemas para resolver a situação, estas fases são feitas pelos system thinkers e usa um linguagem apropriada por o efeito. Checkland diz claramente que esta metodologia não é um livro de receitas e que não tem como objectivo encontrar soluções. Esta metodologia serve para ajudar as pessoas a lidar com complexida ao fornecer um processo bem definido que permite ás pessoas aprender a agir com o objectivo de melhorar a situação presente.
Esta fase a que ele chamou experssion tem como objectivo construir uma rich picture que expressa não o problema mas a situação onde foi indentificado existir um problema. Nesta fase deve ser escolhido o viewpoint que evidencia de forma mais clara quais os aspectos mais relevantes que devemos considerar quando tentamos lidar com este tipo de situações. O viewpoint deve ser escolhido com algum cuidado pois restringe obviamente ao que vamos dar atenção e ao que vamos à partida descartar. Esta figura deve por isso ter em conta contribuições de todas as pessoas que tem algum contacto com a situação que queremos expressar.
Nesta fase olhamos para a figura que foi contruida na fase anterior e tentamos responder à pergunta “Quais são os nomes dos sistemas que são relevantes tendo em conta o que foi previamente analisado?” e não á pergunta “Quais os sistemas que devem ser contruidos para resolver o problema?”. O objectivo de dar um nome ao sistema é torna explicito o que o sistema é e qual o papel dele no contexto da situação. Esta nomeação está obviamente limitada pelo viewpoint que foi escolhido e deve-se nesta fase já tentar perceber se a escolha foi a mais acertada. Um bom analista deve também ter em conta as fases que se segue e ir já prevendo que tipo de mudanças poderão emergir a partir destas definições e avaliar por alto se de facto fazem sentido no contexto da situação em causa.
Nesta fase o objectivo é contruir os modelos conceptuais dos sistemas que foram identificados na fase anterior. Checkland acredita que há duas formas de descrever um sistema: Ou pela descrição de estados, que são contituidos por um conjunto de elementos, tem um estado actual e que tem relações com elementos externos que alteram o seu estado actual. Ou como uma entidade que recebe inputs e através de um processo de transformação as transforma em outputs. A segunda forma é que o Chekland acha fazer mais sentido para descrever os sistemas neste context. Assim nesta fase vai se fazer o levantamento do conjunto minimo de actividades necessárias para descrever a transformação do sistemas definido na fase anterior. Este conjunto de actividades são basicamente verb phrases que depois são ligadas por setas de forma a demonstrar a dependencia entre elas. Finalmente deve exitir uma forma de forma de medir a performance de cada actividade e um mecanismo de controlo que garante que cada actividade faz exactamente o que é definido. É também nesta fase que estes mecanismos são definidos. É muito importante que os modelos sejam construidos desligados da realidade, isto é, não queremos saber como é q as coisas funcionam nos sistemas existentes mas como é que certo processo deveria funcionar idealmente. Só assim vamos conseguir emergir deste processo as mudanças que poderão melhor ou corrigir a situação identificada.
Nesta fase vamos comprar os modelos conceptuais com a realidade. Ao longo do desevolvimento desta metodologia, estamos a falar de cerca de 30 de action research, checkland identificou 4 formas de fazer a comparação de forma a dar os resultados esperados: Em situações em que o que foi levantado é muito diferente da realidade, ele acha mais productivo usar o modelo com base para debater as potenciais mudanças do que usa-lo com para um comparação directa em que poderia dar a impressão ás pessoas envolvidas que teriam de mudar radicalmente o que tem feito até agora. Outra forma é anotar como um determinado processo é executado nos sistema geral (e aqui estamos sempre a incluir pessoas) e comparar como o mesmo processo seria executado no modelo conceptual se este fosse de facto implementado. Outra medida é analisar quais são as funcionalidades que são fundamentalmente diferententes ou inexistentes no sistemas real, e analisar o porque juntamente com as pessoas envolvidas. Finalmente, outra forma é construir um modelo conceptual da realidade seguindo exactamente as guidelines usadas para construir o modelo conceptual e comparar os dois. Deve já nesta fase verificar se as mudanças que estão a emergir fazem sentido para a situação em análise. Caso se note, nalgum inconsistência deve-se repetir as fases anteriores de forma a corrigir esta situação.
Finalmente nesta fase vamos implementar as mudanças que emergiram na fase anterior. Antes de implementar as mudanças deve verificar se elas são feasible e desirable. Como isto quero dizer se fazem sentido tendo em conta a cultura da organização e se por outro lado são de facto benéficas para a situação em análise. As logo da sua experiência Checkland identificou 3 tipos de mudanças. Mundanças na estrutura, por exemplo mudanças a nivel dos departamentos existentes Mudanças em processos, por exemplo se um reporting é feito por voz, ou por papel Mudanças em atitudes, por exemplo as espectativas que as pessoas tem de outras com determinados roles. Os primeiros dois tipos de mudanças são na opinião dele implementáveis mas que o último tipo é mais complicado devido a sua natureza e por estar directamente ligado com caractericas pessoais das pessoas.
Analysis one - Analysis two – é um modelo que contém a visão do que significa cultura e é simplemente descrita tendo em conta 3 elementos – papeis, normas e valores. Analysis three – responde a esta pergunta – Como o poder está distribuido nesta situação? O poder restringe a possibilidade de implementar certas mudanças e a forma como as coisas são feitas.