Como chegar neste equilíbrio: Variedade do Ambiente = Variedade Organizacional

Conforme nossos modelos mentais mudam, criamos diferentes regras de decisão e mudamos a estratégia e a estrutura de nossas organizações. As mesmas informações, filtradas e processadas por meio de uma regra de decisão diferente, irão produzir um efeito diferente.

Atrasos de tempo entre a tomada de uma decisão e seus efeitos sobre o estado do sistema são comuns e particularmente problemáticos. Obviamente, atrasos reduzem o número de vezes que se pode circular em torno do ciclo de aprendizagem, retardando a capacidade de acumular experiência, testar hipóteses e melhorar.

Stafford Berr desenvolveu na década de 50 o Modelo de Sistema Viável (VSM) que buscava explicar como as organizações criam a viabilidade, que é a capacidade de existir e prosperar em ambientes às vezes imprevisíveis e turbulentos.

Um dos princípios do sistema era que as organizações deveriam aumentar a autonomia dos seus colaboradores para lidar com a variedade existente no ambiente. Essa é uma das teorias que foram utilizadas por Beer para dar corpo ao seu sistema: a Lei da Variedade de Requisitos de Ashby.

Isso significa que em ambientes complexos são necessárias organizações suficientemente complexas para atender a esses ambientes. Precisamos também de certa variedade na gestão para fazer frente a variedade organizacional.

Uma das formas que Ashby coloca para que a gestão atenue a variabilidade da organização é aumentando a autonomia dos times e departamentos. Só com mais autonomia, a organização será capaz de lidar com os distúrbios do ambiente a qual se encontra.

Um exemplo interessante que gosto sempre de contar em sala de aula para exemplificar como a variedade do ambiente influencia na variedade organizacional e o da indústria automobilística, principalmente envolvendo três gigantes da gestão: Henry Ford, Alfred Sloan e Taiichi Ohno.

A famosa frase de Henry Ford documentada no livro “My Life and Work” de Henry Ford em colaboração com Samuel Crowther escrito em 1922:

“Any customer can have a car painted any colour that he wants so long as it is black.”

“Qualquer cliente pode ter um carro pintado de qualquer cor que ele queira, desde que seja preto.”

Foi dita em uma reunião em 1909 pelo próprio Ford em relação ao futuro em que produziriam apenas um modelo, o Modelo T com o mesmo chassi para todos os carros. Ele completa dizendo que todos teriam a mesma cor: preta.

A produção do Modelo T foi o primeiro carro produzido em massa no mundo. A filosofia de Ford estava de acordo com os princípios da manufatura de Taylor, que defendia firmemente o controle gerencial. Taylor afirmava que uma das funções da administração era controlar as práticas de trabalho para reduzir a proliferação da variedade. A variedade na época era pequena e não trazia tantos distúrbios. Era possível tal limitador da construção de apenas um carro e uma cor. O mercado não demandava muita coisa além disso.

Segundo a linha taylorista o objetivo era o controle do trabalho. Por muitos anos foi visto como uma abordagem que inibe a inovação e principalmente a mudança. Hoje essa abordagem é completamente inútil, mas nem sempre foi assim.

O sucesso impressionante do Modelo T de Henry Ford, ou seja, 15 milhões foram feitos entre 1908 e o final da década de 1920, numa época em que a maioria dos modelos de outros fabricantes eram produzidos em centenas ou menos – prova o quão bem-sucedida foi a abordagem de Taylor.

Então uma pergunta que fica é: o que mudou? Na verdade , no cenário descrito duas coisas precisaram acontecer. Uma foi internamente as organizações. A complexidade da tecnologia e as habilidades das pessoas mudaram. No início do século XX, estimou-se que 95% dos trabalhadores não podiam fazer seu trabalho tão bem quanto seu chefe imediato. No início do século XXI, estima-se que essa estatística tenha praticamente se invertido, de modo que 95% dos trabalhadores podem fazer seu trabalho melhor do que seu chefe. Era muito comum, quando uma fábrica do século XX precisava nomear um novo supervisor para uma oficina mecânica, eles simplesmente promoviam o melhor operador de máquina que trabalhava na oficina. Como os mais qualificados eram promovidos, é claro que eles poderiam fazer o trabalho melhor do que sua equipe. Neste caso, na abordagem taylorista, os gerentes ditavam a conduta do o que e o como deveria ser feito. 

A segunda coisa que mudou foi o ambiente. Nenhuma montadora hoje em dia poderia sobreviver de forma realista, muito menos prosperar para se tornar o maior fabricante de automóveis do mundo se estivesse preparada para oferecer carros em uma única cor. Henry Ford travava o mercado como sendo homogêneo em relação à demanda. Ford apostou na simplificação e padronização do processo produtivo – a solução de Taylor. 

A organização foi então capaz de corresponder à complexidade das necessidades do mercado, tratando os clientes como se fossem os mesmos e oferecendo um produto simplificado em grande número. Onde havia diferenças nas necessidades do cliente, elas não foram tratadas nem muito menos atendidas pela Ford.

Para a Ford, o sucesso nos negócios veio do equilíbrio certo de complexidade em ambos os lados da equação entre a empresa e seu ambiente.

Acontece que essa equação não ficaria estável para sempre. A diversidade e as necessidades dos clientes aumentaram. O ambiente ficou mais complexo. O mercado já não era mais o mesmo e a demanda por carros de diferentes tamanhos, cores, estilos começou a emergir. Aqui entra o nosso segundo gigante da gestão: Alfred Sloan.

Para lidar com este problema, Sloan desenvolveu o modelo de organização divisional que foi usado pela General Motors. A estrutura organizacional da GM passa a ter unidades específicas, cada uma com sua própria marca e com a tarefa de atender a um segmento de mercado específico. 

O aumento da complexidade do ambiente de mercado foi acompanhado por um aumento correspondente na complexidade da organização e, assim, a equação entre as operações e o ambiente foi novamente equilibrada.

A GM impulsionou a autonomia dos setores. Deu aos seus trabalhadores condições de lidar com a complexidade e a variedade do mercado. Essa autonomia levou a GM a se tornar a maior fabricante de automóveis no mundo.

Nosso terceiro gigante da gestão chama-se Taiichi Ohno. O próximo reequilíbrio aconteceu com a criação do Sistema Toyota de Produção. A Toyota então ultrapassa a GM e se torna a maior fabricante de veículos do mundo. 

Liker no livro 14 princípios de gestão do maior fabricante do mundo afirma que a Toyota apresenta o mais rápido processo de desenvolvimento de produtos no mundo. Novos carros e caminhões levam menos de 12 meses para serem criados, enquanto os concorrentes precisam de pelo menos dois ou três anos.

A Toyota inverteu toda uma lógica de produção. Colocou o cliente e a definição de valor no centro da sua filosofia. Saiu do sistema empurrado para o sistema puxado e trabalhou diuturnamente na eliminação de desperdícios e na entrega de qualidade. 

O DNA do sistema Toyota de produção não é nenhum elemento individual, mas o mais importante é ter todos os elementos reunidos como um sistema. Eles devem ser postos em prática de uma maneira sistemática e nada de forma isolada.

O desenvolvimento do pensamento sistêmico é um processo de aprendizagem de ciclo duplo (Argyris) em que substituímos uma visão reducionista, parcial, estreita e de curto prazo por uma visão dinâmica, holística, ampla e de longo prazo para em seguida podermos redesenhar nossas instituições.

Não sabemos nada sobre nosso comportamento. O que nós recebemos são os efeitos do feedback das nossas ações. Nos comportamos de tal maneira esperando uma certa precisão de feedback, entretanto ele poderá vir ou não. Cabe a nós mudar o comportamento em busca do objetivo desejado.

Forrester (1961), afirmou que todas as decisões (incluindo a aprendizagem) ocorrem em contexto dos ciclos de feedback.

As organizações são muito mais complexas em termos dos seus sistemas de controle do que imaginamos.

Todo o sistema se tornará instável se um único nível não puder atenuar a variedade que entra por outro canal. Se o equilíbrio ou a condição de homeostase for perdida, a organização corre o risco de colapso.

Beer ainda afirma que as unidades operacionais devem ser tão autônomas quanto possível e o trabalho da administração é fornecer condições para que isso aconteça.

O sistema existe de qualquer maneira, funcione ou não. E o truque é tornar-se consciente de seu funcionamento, vendo como as coisas mudam, cada vez que passam por você.

Referências:

ARGYRIS, Chris. Double-Loop Learning, Teaching, and Research. Academy Of Management Learning & Education, [S.L.], v. 1, n. 2, p. 206-218, dez. 2002. Academy of Management. http://dx.doi.org/10.5465/amle.2002.8509400.

ASHBY W.R. (1958) Requisite variety and its implications for the control of complex systems, Cybernetica 1:2, p. 83-99.

BEER, Stafford. Brain of the Firm. 2. ed. New York: John Wiley & Sons, 1972.

BEER, Stafford. The Viable System Model: its provenance, development, methodology and pathology. The Journal Of The Operational Research Society, [S.L.], v. 35, n. 1, p. 7-25, jan. 1984. JSTOR. http://dx.doi.org/10.2307/2581927.

FORD, Henry. My Life and Work. Garden City / Ney York: Doubleday, Page & Company, 1923. In Collaboration with Samuel Crowther.

FORRESTER, Jay W.. Industrial Dynamics. Massachusetts: The M.I.T. Press, 1961.

LIKER, Jeffrey K.. O Modelo Toyota: 14 princípios de gestão do maior fabricante do mundo. Porto Alegre: Bookman, 2005.

Introdução ao Pensamento Sistêmico

Ouvimos a todo momento a palavra sistema. Está presente em nosso dia a dia, em casa, onde trabalhamos, nas instituições que frequentamos, nas coisas que compramos. Somos membros de diversos sistemas e todos os dias interagimos com os elementos que compõem cada um.

Em um sistema, a soma de suas partes não representa o todo. Mesmo que todas as partes isoladamente sejam boas, isso não significa que vamos ter um bom sistema. Mais importante que cada parte são as interações existentes entre cada uma e claro conhecer o todo a qual estão inseridas. Systems Thinking é uma maneira de pensar as relações entre as partes de um sistema, saber onde ajustar para conseguir as melhorias desejadas e expandir nossos horizontes em buscas de soluções mais efetivas.

Se você é da área de design ou já trabalhou com softwares tais como o photoshop, você deve conhecer a ferramenta Zoom Out. Basicamente, para gerenciarmos um sistema precisamos dar um zoom out no nosso cenário e enxergar quais os demais aspectos estão influenciando o problema ou situação que queremos resolver.

Por exemplo, as taxas de obesidade estão crescendo cada vez mais e vamos supor que você foi designado como gestor de um programa para reduzir estes índices. O primeiro instinto é criar um programa para as pessoas se exercitarem. Mas, o que na realidade podemos esperar desta abordagem? System Thinkers acreditam que ver apenas uma parte do problema, de forma isolada sem considerar o sistema maior onde isto opera não é o ideal. Tendemos a ignorar outros aspectos que podem influenciar no impacto. Por que? Pesquisas nos mostram que a obesidade é um resultado de uma combinação de muitos problemas: fisiológicos, psicológicos, sociais, e econômico interagindo uns com os outros.

Por exemplo, no nível do indivíduo, existem questões hereditárias, hábitos exercicios, escolhas do que comer,  e ainda a forma como trabalham. Mas, indo além do indivíduo, nós temos outros fatores tais como o ambiente físico que permite, por exemplo, fácil acesso a lanchonetes de fast food e diversos anúncios de promoções, principalmente as práticas deste tipo de restaurante, como o tamanho das porções, combos e sobremesas. A interação de todas estas influências faz da obesidade o que nós chamamos de um Complex System.

Vamos supor que você tenha em sua organização um problema de comunicação, e você é indicado para resolver este tipo de questão. A intuição nos condicionará a irmos até nossa área de comunicação e ampliar nossos canais. Mas será que o simples fato de ampliarmos os canais resolveria os problemas? E se o processo de comunicação for lento e a informação demorar para chegar até as pessoas? E se a forma de escrever as notícias não for atraente? E se as pessoas preferem vídeos ao invés de textos escritos? Certamente, quando nós ampliarmos este cenário, vamos descobrir mais partes deste sistema que nos ajudarão a buscar soluções mais efetivas. Vamos descobrir outros pontos de alavancagem, fora das soluções tradicionais.

Daniel Kin define um sistema como sendo um grupo de partes que interagem e formam um todo com um propósito específico. A chave é lembrar que as partes são interrelacionadas e interdependentes de alguma forma, sem essas interdependências nós temos apenas uma coleção de partes e não um sistema.

Para Russell Ackoff, um sistema é um conjunto de dois ou mais elementos que se relacionam com as seguintes caraterísticas:

  • Cada elemento tem efeito no funcionamento do todo;
  • Cada elemento é afetado por pelo menos um outro elemento do sistema;
  • Todos os possíveis subgrupos de elementos, possuem as duas propriedades acima.

Para ilustrar as definições acima, vamos classificar a seguinte lista em um conjunto de itens ou um sistema:

  • tigela de frutas;
  • time de futebol;
  • torradeira;
  • uma cozinha;
  • banco de dados com nomes de clientes;
  • ferramentas em uma caixa de ferramentas;
  • um casamento.

Quais destes são sistemas ou simplesmente são um conjunto de itens? Vamos analisar cada um:

Uma cozinha, a base de dados com os nomes do clientes e as ferramentas em uma caixa de ferramentas são somente um conjunto de itens. Não há relação entre as partes que compõem estes conjunto, embora a cozinha por exemplo esteja repleta de sistemas (geladeira, microondas, lavadora de roupas), isto são um conjunto de elementos em um lugar (cozinha).

Time de futebol e a torradeira, ambos são sistemas. Eles são colocados juntos para atenderem a um propósito específico. O propósito atua como força organizadora predominante em qualquer sistema. Se você quiser entender o porquê de um sistema estar organizado de alguma forma específica, procure entender o propósito.

Tigela de frutas. Muitas pessoas classificariam como um conjunto, porque as frutas não estão interrelacionadas e não interagem uma com as outras. Na verdade em um nível microscópico elas estão interagindo. Por exemplo, se você colocar certas frutas juntas, elas irão se decompor mais rápido, pois interagem em um nível molecular.

Um casamento. Para qualquer um que viu um casamento como um conjunto, é melhor procurar um aconselhamento matrimonial imediatamente. Brincadeiras a parte, o casamento é um estado de interdependência voluntariamente escolhido com outra pessoa (não a co dependência que é completamente diferente). Existe alguém entre nós que não costumamos lembrar, ou que nossas ações tenham impacto sobre ele ou ela? Às vezes, é assim que nós descobrimos que estamos em um sistema, e como aprendemos de maneira dolorosa que somos parte de um sistema maior do que podemos perceber.

Espero que estes exemplos possam contribuir para o nosso entendimento. Estamos inseridos em diversos sistemas que interagem entre si. No próximo artigo vamos detalhar a Quinta Disciplina: Pensamento Sistêmico!

Referências:

The Systems Thinker – http://thesystemsthinker.com/introduction-to-systems-thinking/

Vídeo Youtube: http://www.youtube.com/watch?v=2vojPksdbtI

Projetos em grande escala como sistemas complexos – Gerenciando o Scope Creep

O famoso ditado de Northcote Parkinson, “O trabalho se expande para preencher o tempo disponível para sua conclusão”, pode ser excessivamente otimista. Infelizmente o trabalho tende a se expandir muito além do tempo e do dinheiro orçados para sua conclusão, particularmente para projetos complexos. Por exemplo, estimativas publicadas no ano passado em Comunicações da ACM (Association for Computing Machinery) indicam que as empresas americanas gastaram aproximadamente US $ 59 bilhões em 1995 em custos excedentes e US $ 80 bilhões adicionais em projetos cancelados de tecnologia da informação (TI). Essas estimativas não incluem excedentes em projetos do governo ou do setor público. Um estudo semelhante da Coopers & Lybrand no Reino Unido indica que 85% dos projetos de TI estão acima do orçamento, não cumprem sua programação ou não atendem às expectativas dos clientes.

Embora os projetos de desenvolvimento de TI e software possam ser as áreas mais visíveis nas quais o trabalho se estende além de seus parâmetros originais, os esforços de reengenharia de processos, iniciativas de mudança organizacional abrangentes e projetos de construção em larga escala certamente não estão isentos. Tomemos, por exemplo, uma pequena cidade na Carolina do Norte que está construindo um reservatório para seu abastecimento de água municipal. A estimativa original para o projeto há cinco anos foi de US $ 5,4 milhões, com um prazo de dois anos para a construção. Hoje, o custo estimado é de US $ 8 milhões. A construção mal começou e agora é projetada para levar três anos.

Dadas essas estatísticas preocupantes, parece justo dizer que grandes projetos raramente, ou nunca, permanecem dentro de suas especificações originais e cumprem suas metas previstas de tempo e dinheiro. Na verdade, qualquer programa ou projeto de natureza complexa que compreende um período de tempo prolongado, requer um investimento monetário significativo de vários componentes que precisam ser gerenciados simultaneamente, se torna vulnerável apesar dos heróicos esforços tradicionais de gerenciamento de projetos. Essa tendência de tais projetos se expandirem além de seus limites iniciais e, portanto, se estenderem muito além de suas previsões, é freqüentemente chamada de “escopo incontrolado”. Neste artigo, examinamos esse fenômeno visualizando grandes projetos como sistemas complexos. Ao entender o descontrole de escopo neste contexto, podemos começar a identificar como e por que isso ocorre. Equipado com esse conhecimento, pessoas, equipes e organizações capacitadas podem planejar e mitigar com mais eficácia os efeitos do descontrole de escopo, adotando uma perspectiva mais realista e dinâmica sobre o processo de gerenciamento de projetos.

A Dinâmica do Scope Creep

Como o descontrole de escopo começa e o que faz com que ele se construa ao longo do tempo, levando a atrasos e atrasos dispendiosos? As organizações iniciam projetos para atender a uma necessidade percebida. Por exemplo, a cidade mencionada acima enfrentou escassez de água periódica durante períodos de seca, por isso decidiu construir um reservatório para atender às suas necessidades de água. Em um mundo ideal, após algum atraso, o projeto deveria ser  completado dentro de seu orçamento original e dentro do cronograma, e a necessidade percebida seria preenchida (B1).

A quantidade de dinheiro investido em um projeto limita a quantidade de trabalho que pode ser realizado e, portanto, geralmente define o escopo do projeto – pelo menos inicialmente. Quanto maior o projeto, e quanto mais pessoas, departamentos e agências envolvidos, mais complexa a governança se torna. Por exemplo, em uma empresa de TI, um esforço de desenvolvimento de produto em larga escala requer informações de vários departamentos, cada um com seu próprio gerenciamento e suas próprias prioridades. Vários subprojetos do esforço maior podem acabar competindo entre si pelas habilidades de testadores, programadores de bancos de dados ou escritores técnicos, tornando a governança geral complexa. A competição por recursos limitados se intensifica à medida que o número de subprojetos se expande, tornando o gerenciamento do esforço geral mais desafiador.

Quando a governança é complexa, os gerentes acham difícil tomar decisões em tempo hábil e atender às consequências de longo prazo de cada decisão. Essas dificuldades ameaçam a precisão das estimativas de cronograma. À medida que os prazos se aproximam e a pressão do tempo sobe, as pessoas tendem a pegar atalhos para manter o projeto no caminho certo. Em um projeto de desenvolvimento de software, por exemplo, os atalhos geralmente significam desenvolvimento paralelo inadequado – talvez desenvolvendo aplicativos que dependam de módulos de nível inferior antes que os módulos de nível inferior sejam totalmente projetados. Pegar atalhos em um projeto de construção pode significar aceitar a proposta mais baixa sem qualificar o fornecedor, não permitindo tempo suficiente para coordenar o trabalho dos vários subcontratados, ou até deixando de permitir a cura do cimento adequadamente. No curto prazo, os atalhos podem parecer aliviar pressões de cronograma (B2), mas na verdade é um exemplo da clássica estrutura arquetípica “Fix That Fail”. Em um cenário “Soluções que Falham”, uma ação que soluciona um problema no curto prazo realmente exacerba a mesma condição a longo prazo. Assim, ao longo do tempo, os atalhos geralmente resultam em retrabalho, o que inevitavelmente cria ainda mais pressão de cronograma (R3)

O retrabalho também aumenta o custo. À medida que o custo de um projeto aumenta, os gerentes de projeto precisam justificar os gastos adicionais para a alta gerência ou para seus constituintes. Para fazer isso, eles geralmente “descobrem” novas features para tornar a despesa adicional mais palatável. Por exemplo, um funcionário eleito pode dizer a um grupo irado de contribuintes: “É claro que uma barragem custando tanto incluirá uma área de recreação.” Ou os constituintes podem decidir que uma empresa tão cara deve incluir uma área de recreação e pressionar os funcionários para fazer uma . As expectativas de um projeto de TI podem aumentar quando o departamento de vendas assegura aos clientes insatisfeitos: “Ah, temos uma nova versão que abordará sua preocupação”. Garantias e premissas como essas aumentam as expectativas dos clientes e expandem o escopo do projeto (R4).

À medida que o escopo do projeto aumenta, a rede de interações e dependências entre tarefas, subprojetos, departamentos e agências se torna ainda mais complexa. Essa complexidade crescente pode levar a atrasos. Por exemplo, em um projeto de construção, se um subcontratado tiver que esperar por um segundo para concluir suas tarefas, ele poderá precisar assumir outro trabalho nesse ínterim. Ele pode então não ter o pessoal imediatamente disponível para trabalhar no projeto original quando o primeiro subcontratado estiver finalmente pronto para ele. Atraso cria ainda mais pressão de prazo e reforça a dinâmica do escopo descontrolado.

Tais interações e dependências também dificultam a estimativa precisa de custos. Os atrasos podem agravar ainda mais o problema, tornando as estimativas de custos ainda menos precisas. Se os custos reais forem muito mais altos do que as estimativas originais, a pressão sobre os funcionários e gerentes para justificar os custos aumenta, o que pode influenciar ainda mais as expectativas do projeto e causar um aumento ainda maior no descontrole de escopo (R5).

A complexidade da governança afeta mais do que a oportunidade das decisões. Também afeta a capacidade dos tomadores de decisão de ver os efeitos de suas decisões – tanto em outros aspectos do projeto quanto no futuro. Com menos visibilidade para efeitos posteriores, as decisões que parecem dar resultados locais positivos podem ter consequências globais negativas. Portanto, a qualidade das decisões pode diminuir – aumentando a probabilidade de retrabalho adicional e criando complexidade adicional (R6).

Assim, a tendência dos grandes projetos de aumentar seu escopo encontra suas raízes em duas hipóteses subjacentes. A primeira é que podemos gerenciar um projeto simplesmente gerenciando suas partes. Essa prática nos leva a ignorar o impacto sistêmico de decisões locais aparentemente pequenas, o que, por sua vez, pode minar estimativas iniciais de tempo e custo e aumentar a complexidade do projeto. A segunda é que assumimos que podemos estimar cronogramas e custos com precisão antes de iniciar o trabalho. Mas, muitas vezes, quando um projeto custa mais ou demora mais do que o esperado, respondemos presumindo que ele deve incluir recursos adicionais ou adicionando mais para justificar o aumento de custo ou tempo – aumentando o descontrole do escopo.

Além do Gerenciamento Tradicional de Projetos

Até hoje, a maioria das explicações sobre o Scope Creep se origina de uma visão linear e sequencial dos projetos e de como eles são gerenciados. Por exemplo, o Project Management Institute define as cinco fases de gerenciamento do projeto como iniciar, planejar, executar, controlar e fechar. Este modelo assume que uma fase é concluída antes do próximo começar e que devemos retornar às fases anteriores somente quando ocorrerem problemas.

Usando essa estrutura sequencial, vários autores escreveram que o Scope Creep ocorre quando a fase de planejamento está incompleta. Por exemplo, alguns sugerem que, se os objetivos e as “entregas” do projeto não estiverem totalmente definidos ou se as falhas do projeto não forem claras, o projeto excederá suas projeções originais de custo e cronograma. Outros atribuem o Scope Creep a requisitos mal definidos ou financiamento insuficiente. Outro conjunto de explicações enfoca os problemas que ocorrem durante a fase de controle; por exemplo, mudanças mal documentadas nas especificações do projeto.

Todas essas explicações provavelmente estão corretas até certo ponto. No entanto, mesmo se uma equipe aderir rigidamente a essa estrutura de gerenciamento de projetos e concluir cada etapa com perfeição aproximada, ainda poderá ocorrer o descontrole de escopo, especialmente em projetos grandes e complexos. Bom, o gerenciamento linear de projetos é necessário. No entanto, com frequência temos Scope Creep, e o gerenciamento linear é insuficiente para evitar o problema.

A desvantagem do modelo tradicional de gerenciamento de projetos é que ele não explica adequadamente o fato de que um grande projeto – como construir um reservatório, desenvolver um software grande e complexo ou escrever um grande currículo de treinamento – é na verdade um grande sistema com múltiplas partes interativas. De acordo com John Sterman, professor do M. I. T., “Projetos de grande escala pertencem à classe de sistemas dinâmicos complexos. Tais sistemas são altamente complexos, consistindo em múltiplos componentes interdependentes,são altamente dinâmicos, envolvem múltiplos processos de feedback,  envolvem relacionamentos não-lineares e envolvem tanto dados tangíveis e intangíveis. Ao descrever problemas nesses tipos de sistemas, a autora Meg Wheatley diz: “Eles não podem ser compreendidos suficientemente antes ou durante o tempo em que estão ocorrendo; portanto, previsão e controle são impossíveis”. Em outras palavras, as interações entre as tarefas, os subprojetos e as estruturas de governança de um projeto complexo tornam praticamente impossível definir as entregas do projeto ou captar os requisitos de recursos com antecedência.

A dinâmica do Scope Creep

Por exemplo, no desenvolvimento de software, os gerentes geralmente dividem os projetos em vários módulos – cada um dos quais deve ser projetado e desenvolvido de forma independente e depois combinado em um produto completo. Eles então dividem o trabalho de cada módulo em uma série de tarefas, que podem ser sequenciadas e colocadas em uma linha do tempo. Parece lógico pensar que, se essas tarefas são realizadas da maneira prescrita, sua conclusão deve constituir o projeto total. Na prática, no entanto, o grau de interdependência entre os módulos geralmente não fica evidente até que as equipes tenham investido muito esforço em design e desenvolvimento. Nesse ponto, os componentes geralmente exigem mais design, codificação e teste do que o rçamento inicial para fazer os módulos funcionarem juntos.

Igualmente importante, à medida que as interdependências entre os diferentes módulos vêm à luz, o escopo do projeto muda – mesmo que o plano de projeto não o faça – porque as pessoas envolvidas obtêm novas idéias sobre o que o produto deve oferecer. Por exemplo, um projeto de software que começou como uma reescrita do código para corrigir um problema evolui quando os projetistas percebem que resolver o problema facilita a implementação de uma solicitação do cliente que era difícil de implementar no código antigo. Para satisfazer o cliente, eles criam a solicitação na fase de reescrita. Uma única adição como essa normalmente não representa um problema. No entanto, quando uma reescrita é grande e dispendiosa, os gerentes podem ser pressionados a adicionar várias dessas solicitações de clientes para justificar as despesas do projeto. A abordagem padrão para gerenciamento de projetos deixa de considerar essas mudanças nas expectativas. Então, o que começou como uma correção simples pode inesperadamente se tornar um grande projeto para atender às demandas dos clientes.

Sterman identifica dois tipos de complexidade em projetos: combinatória e dinâmica. A complexidade combinatória é criada pelas atividades paralelas e sequenciais que ocorrem em um projeto grande e complexo – por exemplo, em um grande projeto de construção, todas as autorizações necessárias antes do início da construção. As ferramentas tradicionais de gerenciamento de projetos, como os gráficos PERT, CPM e GANTT, destinam-se a ajudar as pessoas a lidar com esses detalhes.

Por outro lado, a complexidade dinâmica é criada pelos múltiplos processos de feedback, atrasos de tempo e relações causais não-lineares que existem em qualquer projeto grande. Como as interações entre múltiplas variáveis ao longo do tempo impulsionam esse tipo de complexidade, elas podem crescer geometricamente ou mesmo exponencialmente à medida que elementos adicionais entram no sistema. Por exemplo, a visão tradicional afirma que adicionar uma quarta tarefa a três que já estão agendadas aumentaria a carga de trabalho proporcionalmente – ou seja, 33%. No entanto, esse cálculo não leva em conta o fato de que a nova tarefa interage com cada uma das tarefas existentes, na verdade, duplicando as interações entre tarefas e potencialmente aumentando a quantidade de trabalho em muito mais de um terço. Por essa razão, a complexidade dinâmica contribui significativamente para o fenômeno do Scope Creep e não pode ser adequadamente abordada usando abordagens lineares padrão.

Mitigando o Scope Creep

Claramente, precisamos ampliar nosso pensamento sobre gerenciamento de projetos. Felizmente, existem várias maneiras de fazer isso:

Complexidade Dinâmica da Superfície. A primeira chave para atenuar o aumento do escopo é encontrar maneiras de exibir os processos de feedback, atrasos de tempo e relacionamentos não lineares em um projeto grande e complexo. Aqui estão algumas sugestões:

  • John Sterman demonstrou o valor de usar a modelagem de dinâmica do sistema em projetos de grande escala em conjunto com ferramentas tradicionais. Essa abordagem pode ajudar a expor muitas das interações entre tarefas, subprojetos e estruturas de governança que, em última análise, levam à distorção do escopo e podem tornar explícitas muitas suposições que muitas vezes permanecem não ditas. Com essas informações, os tomadores de decisão e os gerentes de projeto podem tomar decisões mais informadas sobre mudanças nas condições externas, mudanças propostas na estratégia, alocação de recursos, impactos de atrasos e até mesmo a viabilidade do projeto ao longo do tempo.
  • Se não for prático usar um modelo de dinâmica do sistema, desenhar diagramas de loop causal pode ajudar os gerentes a identificar ciclos de feedback e relações causais separados por tempo e espaço. A discussão das interações e dependências entre vários fluxos de trabalho pode criar uma compreensão mais rica das complexidades envolvidas.
  • Com um conhecimento básico de pensamento sistêmico e diagramas de loop causal, os tomadores de decisão reconhecem muitos “atalhos” como “Soluções que falham”. Mas, como é difícil detectar padrões de comportamento durante a implementação de um projeto, os gerentes devem antecipar e documentar possíveis problemas que poderão acontecer. Uma maneira de fazer isso é identificar quaisquer arquétipos de sistemas operando em projetos anteriores, documentá-los e compartilhá-los com a equipe do projeto. A equipe precisa avaliar continuamente se padrões similares estão surgindo no presente projeto e tomar as medidas apropriadas para evitar cair nas mesmas armadilhas. Antecipar essas situações, documentá-las antecipadamente e nomear alguém para sinalizá-las se surgirem, pode levar a decisões mais inteligentes quando a ação começar em uma iniciativa importante.
  • O processo de tomada de decisão em grandes projetos é muitas vezes extremamente complexo, pesado e sujeito a pressões externas. Essas pressões podem incluir considerações políticas, a cultura da organização, práticas de gestão arraigadas e restrições orçamentárias. Devido à complexidade do processo de tomada de decisão, os gerentes de projeto geralmente tomam decisões sem considerar como podem afetar o restante do sistema. Uma maneira de simplificar a tomada de decisões e ajudar a identificar conseqüências não intencionais é usar uma matriz de decisão. Para fazer isso, faça uma lista dos possíveis resultados na parte superior de uma página. Em seguida, converse sobre as possíveis soluções em consideração e liste-as na lateral da página. Discuta as diferentes combinações resultantes representadas por cada “célula” na matriz antes de tomar qualquer decisão. Use um processo de classificação para determinar qual célula ou células melhor atende aos resultados desejados.
  • O planejamento de cenários oferece outra maneira de identificar e explorar os possíveis resultados – tanto previsíveis quanto improváveis – das decisões que estão sendo consideradas. Para uma aplicação simples do planejamento de cenário, leia Peter Senge no livro A Dança da Mudança: Os Desafios para Sustentar o Momento nas Organizações Aprendizes (Doubleday, 1999), pp. 187-190. Durante o processo de planejamento de cenário, os gerentes de projeto e as equipes também podem identificar algumas “Soluções que Falham” adicionais a serem evitadas.

Repensar abordagens para orçamentos e cronogramas. Também precisamos repensar a suposição comum de que podemos fazer previsões precisas de custo e cronograma antecipadamente em um projeto grande. Essa expectativa não é realista, devido à natureza intrinsecamente variável desses projetos. Portanto, precisamos de uma abordagem “escalonável” para orçamentos e cronogramas, em que revisamos e atualizamos regularmente as estimativas de tempo e dinheiro. Essas revisões devem incluir um cronograma para as decisões relacionadas à mudança do projeto, o redimensionamento ou até mesmo cancelar o projeto. Com o tempo, à medida que aprendemos mais sobre o trabalho envolvido, as estimativas devem se tornar mais precisas.

Nenhuma organização pode lançar um projeto sem ter alguma ideia sobre a quantidade de dinheiro e tempo envolvidos. Os gerentes devem, portanto, fornecer uma série de estimativas iniciais de custo e cronograma, juntamente com uma margem de erro e um plano de revisão com áreas de escape, conforme descrito acima. Essas estimativas e as revisões internas ajudam a evitar que as pessoas se sintam presas e traídas quando grandes projetos ultrapassam o orçamento e se atrasam.

Use o propósito original como uma âncora. Há uma tendência de usar as expectativas atuais como um tipo de ponto de ancoragem ao considerar mudanças no escopo de um projeto. Essa propensão pode ser perigosa, porque as expectativas atuais podem ter mudado significativamente desde o início do projeto. De fato, as dinâmicas por trás do Scope Creep são semelhantes às da estrutura arquetípica de “Metas a Deriva”. Em “Metas a Deriva”, dois loops de equilíbrio interagem para fazer com que metas e padrões diminuam com o tempo. No Scope Creep, uma série de processos de reforço constantemente “elevam o padrão” e impedem que o projeto seja finalizado dentro de suas projeções originais. Para ajudar a evitar este processo, volte ao propósito original do projeto e use-o como um ponto de referência. Por que o projeto foi iniciado em primeiro lugar? Se você decidir mudar seu escopo, quais serão as ramificações?

Siga boas práticas de gerenciamento de projetos. Por fim, continue usando boas práticas de gerenciamento de projetos. Muitas ferramentas tradicionais continuam sendo essenciais para acompanhar o progresso de qualquer projeto. No entanto, lembre-se que em um sistema complexo como um grande projeto, o todo não é igual à soma de suas partes; o todo inclui a soma de suas partes, bem como as interações entre todos os componentes.

Além do Velho Paradigma

Albert Einstein é frequentemente citado dizendo: “Os problemas significativos que enfrentamos não podem ser resolvidos no mesmo nível de pensamento em que estávamos quando os criamos”. O descontrole de escopo é um problema. Até hoje, a maioria das tentativas de controlar o Scope Creep usaram a lógica aditiva linear para neutralizar o que é um fenômeno altamente complexo e dinâmico. Esse modo de pensar sequencial coloca a culpa pelo escopo indesejado em práticas inadequadas de gerenciamento de projetos. Mas, em vez de correr para tentar novas tecnologias de gerenciamento de projetos ou culpar as pessoas por não implementarem as mais antigas, o que realmente precisamos é de uma nova maneira de entender grandes projetos como sistemas complexos. Neste artigo, oferecemos abordagens que não são visíveis a partir da abordagem linear tradicional. Acreditamos que essas ideias podem servir como oportunidades de aprendizado e como sementes para outras soluções. Aprender a ver grandes projetos como sistemas complexos pode não ser uma revolução, mas achamos que é um primeiro passo digno para uma evolução possível e necessária na maneira como as organizações operam.

Próximos Passos

  • Circule o artigo entre os membros da equipe do seu projeto e discuta como os conceitos podem se aplicar ao seu trabalho. Pergunte: “Quais idéias do artigo mais chamaram a atenção de vocês?” “Houve alguma parte do artigo que pareceu especialmente verdadeira para nós?” “Como pensar em nosso projeto como um sistema complexo nos ajuda a tomar melhores decisões em longo prazo?
  • Faça uma lista de atalhos que você pode tomar (ou ter) em seu projeto para mantê-lo dentro do prazo. Quais podem ser alguns efeitos indesejáveis a longo prazo desses atalhos?
  • Crie um diagrama de loop causal capturando os relacionamentos entre os vários aspectos do seu projeto. Use este exercício para destacar e desafiar suposições sobre como os elementos do seu projeto afetam uns aos outros.
  • Documente o objetivo do projeto e o que se espera que ele realize e pergunte se as expectativas se expandiram durante as revisões regulares.
  • Indique um “historiador” para extrair dados de projetos anteriores, identificando padrões de comportamento ou arquétipos que levaram a problemas. Eduque a equipe do projeto sobre essas áreas problemáticas para que todos possam observar padrões semelhantes no projeto atual.

Autora: Andrea Shapiro, Ph. D., is an internal organizational learning consultant for Nortel Networks. Her work emphasizes learning, communication, and systems thinking (ashapiro@nortelnetworks.com). Carol Lorenz, Ph. D., of Carol Lorenz and Associates, is an independent contractor who worked at Nortel for a number of years. Her work emphasizes learning, organization effectiveness, and systems thinking (lorenzc@mindspring.com).

Link para o artigo original: https://thesystemsthinker.com/large-scale-projects-as-complex-systems-managing-scope-creep/

Tradução: Rodrigo Zambon

Seu projeto não é uma ilha!

Todas as organizações querem crescer e gerar lucros, por isso é fundamental criar novos produtos e conquistar o mercado. À medida que expandimos, mais complexos nos tornamos. Pelo menos aquelas organizações que querem sair do lugar e prosperar em um mundo cada vez mais competitivo estão fazendo a gestão da complexidade e acreditem, nem toda complexidade é ruim!

A complexidade existe quando perdemos a nossa capacidade de simplificar. E estamos perdendo essa habilidade. Hoje a maioria das coisas consideradas simples há 40, 50 anos ficaram extremamente complexas. Os fatores que levaram a isso não são pontos a serem debatidos neste artigo, mas a globalização decorrente da tecnologia e o acesso a informação foram os grandes catalisadores dessa mudança.

A divisão organizacional proposta por Taylor em 19071 que legitima a profissão de gestão e diferencia a pessoas que pensam das que executam está se achatando. Apesar de ainda presente, na minha modesta opinião tende a desaparecer, a não ser que você contrate pessoas restritas a execução que não tenham tido contato com um smartphone, por exemplo!

Ainda dentro das instituições, um elemento muito comum são as organizações temporárias formadas. Neste contexto estou me referindo as pessoas que por um tempo determinando se agrupam para entregar um objetivo comum que atenderá a estratégia organizacional. As equipes de projetos podem ser encontradas em praticamente todos os segmentos de mercado2 e essas pequenas organizações dentro de uma organização maior, conseguem lidar melhor com a complexidade. Estão mais aptas a responder com mais rapidez as constantes mudanças e podem se adaptar com precisão a qualquer situação.

Para unirmos o pensamento sistêmico ao gerenciamento de projetos, podemos usar quatro temas centrais para fazermos nossa análise: tempo, equipe, tarefa e contexto3, além é claro dos drives específicos de cada projeto.

Em relação ao tempo, cada projeto é único, com início e fim bem determinados. Este tempo não é só do projeto, mas serve também para a equipe ganhar maturidade, para mensuramos o quanto se perde por não ter aquele projeto pronto e o que é possível alterar à medida que o tempo avança. A gestão do tempo de um projeto é diferente da gestão do tempo da organização.

Em relação ao contexto, o comparativo é feito entre a organização temporária e a organização permanente. Esta relação não deve ser negligenciada. As estruturas e os procedimentos empregados em um projeto devem ser entendidos em relação aos cursos anteriores e simultâneos de atividades, aos planos futuros e aos procedimentos operacionais padrão, tradições e normas do entorno4.

Esqueça o resto da organização, temos que tomar conta de nós mesmos.

Os gerentes de projetos que não possuem um olhar sistêmico, tendem a tratar o projeto e a sua equipe de forma isolada em relação a organização. Alguns dos problemas gerados em um projeto estão fora dos limites dele mesmo. Eles são problemas derivados da estratégia ou dos recursos que são comuns a organização.

Sempre que uma organização quer fazer algo, tudo sempre se concentra em uma única pessoa, que pode atrasar todo o projeto. Um engenheiro empaca à espera de decisão de um gerente; uma gerente pensa que não tem autoridade para fazer uma compra importantíssima. Essas pequenas hesitações, aparentemente insignificantes, podem causar terríveis atrasos5. Essas questões podem ser minimizadas com a ampliação da cena. Precisamos consentir que estas decisões não tomadas estejam além do gerente e concentradas em pessoas de outros departamentos.

Como podemos aplicar o pensamento sistêmico

Muitas pesquisas sobre a organização do gerenciamento de projetos separaram a estratégia / tomada de decisão da execução6. A divisão entre os decisores e gerentes de projetos cria dois sistemas gerenciais diferentes; um formal, usado para cumprir especificações externas (geralmente contratuais) e uma informal com base na intuição dos gerentes de projeto e na dinâmica de grupo nos projetos7.

O que realmente melhora um sistema não é o foco nas partes. O mais importante é a interação entre as partes. Precisamos ajustar como os membros do time do projeto se relacionam com as demais áreas. Quais os pontos de convergência? O que está limitando as ações do projeto? Qual o fluxo de comunicação? Até onde eu posso flexbilizar?

Para usar o pensamento sistêmico no gerenciamento de projetos, comece hoje mesmo a olhar o seu entorno. Uma das sete deficiências da aprendizagem é “o inimigo está lá fora”. Peter Senge coloca que precisamos olhar para dentro, olhar para o projeto e como estamos nos relacionando com o restante da organização. Primeiro eu modifico o que está ao alcance do gerente, da equipe e observo os feedbacks decorrentes destas mudanças. Quando as consequências acabam retornando e nos prejudicando, interpretamos incorretamente esses novos problemas como se fossem provocados por causas externas8.

A maior parte das organizações está passando por uma transformação, e esse estágio será cíclico. Uma vez que você termine, precisará rapidamente recomeçar!

Referências lidas:

1 – Taylor, F. W. Princípios de Administração Científica, Atlas; Edição: 8ª.
2 – Hanisch, B. and A. Wald (2014). “Effects of complexity on the success of temporary organizations: Relationship quality and transparency as substitutes for formal coordination mechanisms.” Scandinavian Journal of Management 30(2): 197-213.
3 – Bakker, R. M. (2010). “Taking Stock of Temporary Organizational Forms: A Systematic Review and Research Agenda.” International Journal of Management Reviews 12(4): 466-486.
4 – Engwall, M. (2003). “No project is an island: linking projects to history and context.” Research Policy 32(5): 789-808.
5 – Horowitz, B. (2015). O Lado Difícil das Situações Difíceis, WMF Martins Fontes; Edição: 1ª.
6 – Artto, K., et al. (2008). “What is project strategy?” International Journal of Project Management 26(1): 4-12.
7 – Jaafari, A. (2001). “Management of risks, uncertainties and opportunities on projects- time for a fundamental shift.” International Journal of Project Management.
8 – Senge, P. M. A Quinta Disciplina, Best Seller.

Diagramas de loop e nomes de variáveis

Os diagramas de loop causais, ou CLDs, fornecem um idioma para articular nossa compreensão da natureza dinâmica e interligada do nosso mundo. Podemos pensar nelas como frases que são construídas ligando variáveis-chave e indicando as relações causais entre elas. Ao juntar vários loops, podemos criar uma história coerente sobre um problema ou problema específico.

Cada ciclo consiste em variáveis ​​conectadas por setas que representam conexões causais mostrando o movimento de feedback em todo o sistema. Cada seta é rotulada com um sinal (“s” ou “o”) que indica como uma variável afeta outra: “s” indica uma mudança na mesma direção e “o” uma mudança causal na direção oposta.

Os diagramas de loop causais são compostos por uma combinação de rolamentos de equilíbrio (“B”) e reforço (“R”). Um processo de equilíbrio é a busca de objetivos na natureza e tende a manter o sistema estável em torno de um objetivo particular. Um anel de reforço, ao contrário, produz crescimento ou colapso rápido, alterando a mudança em uma direção com mudanças crescentes na mesma direção cada vez que você passa pelo loop. Os processos de equilíbrio e reforço podem ser combinados em um número infinito de combinações para descrever o comportamento de todos os tipos de sistemas, incluindo o comportamento dos sistemas organizacionais.

Selecionando Nomes de Variáveis

  1. Use substantivos ao escolher um nome de variável. Evite verbos e frases de ação, porque a ação é transmitida nas setas do loop. Por exemplo, “Custos” é melhor do que “Custos crescentes”, porque uma diminuição no aumento dos custos é confusa. O sinal da seta (“s” para o mesmo ou “o” para o lado oposto) indica se os custos aumentam ou diminuem em relação à outra variável.
  1. Use variáveis que representam quantidades que podem variar ao longo do tempo. Não faz sentido dizer que “Estado da mente” aumenta ou diminui. Um termo como “Felicidade”, por outro lado, pode variar.
  1. Sempre que possível, escolha o sentido mais “positivo” de um nome de variável. Por exemplo, o conceito de “Crescimento” aumentando ou diminuindo é mais claro do que um aumento ou diminuição na “Contração”.
  1. Pense nas possíveis conseqüências não intencionais, bem como nos resultados esperados para cada curso de ação incluído no diagrama. Por exemplo, um aumento na “Pressão de Produção” pode aumentar “Produção”, mas também pode aumentar o “Estresse” e diminuir a “Qualidade”.
  1. Todos os loops de equilíbrio são processos de busca de objetivos. Tente tornar explícitos os objetivos de conduzir o loop. Por exemplo, o Loop B1 pode levantar questões quanto ao porquê aumentar “Qualidade” levaria a uma diminuição nas “Ações para Melhorar a Qualidade”. Ao identificar explicitamente a “Qualidade Desejada” como objetivo no Loop B2, vemos que a “Gap in Quality” está realmente conduzindo ações de melhoria.
  1. Distinguir entre estados percebidos e atuais, como “Qualidade Percebida” versus “Qualidade Real”. As percepções geralmente mudam mais lentamente do que a realidade, e confundir o status percebido com a realidade atual pode ser enganosa e criar resultados indesejáveis.
  1. Se uma variável tiver múltiplas conseqüências, comece lingando-as em um termo ao completar o resto do loop. Por exemplo, “Estratégias de enfrentamento” pode representar muitas maneiras diferentes de responder ao estresse (exercício, meditação, uso de álcool, etc.).
  1. As ações quase sempre têm diferentes conseqüências a longo prazo e a curto prazo. Desenhe loops maiores à medida que avançam de processos de curto a longo prazo. O loop B1 mostra o comportamento a curto prazo do uso de álcool para combater o estresse. Loop R2, no entanto, desenha as conseqüências a longo prazo desse comportamento, mostrando que ele realmente aumenta o estresse.
  1. Se um link entre dois termos exige muita explicação para ser claro, redefinir as variáveis ou inserir um termo intermediário. Assim, o relacionamento entre “Demanda” e “Qualidade” pode ser mais óbvio quando a “Pressão de Produção” é inserida entre eles.
  1. Um atalho para determinar se um loop está equilibrando ou reforçando é contar o número de “o’s” no loop. Um número ímpar de “o’s” indica um loop de equilíbrio (ou seja, um número ímpar de curvas em U mantém você na direção oposta); um número par ou não ter “o’s” significa que é um loop de reforço. CUIDADO: Depois de rotular o loop, você sempre deve ler isso para garantir que a história concorda com o rótulo R ou B.

Traduzido por Rodrigo Zambon – Artigo original em https://thesystemsthinker.com/guidelines-for-drawing-causal-loop-diagrams-2/

Pensamento Sistêmico – Espírito Santo

O Lab.ges reuniu no dia 24 de janeiro de 2018 um time de especialistas para debater a pergunta focal: “Como mitigar a extrema pobreza no Espírito Santo nos próximos 20 anos?”. A oficina adotou como base o Pensamento Sistêmico para expandir e encontrar pontos de alavancagem para atuar no problema.

Durante a oficina, os participantes contaram com três especialistas do Governo do Estado para apresentar o tema, dados históricos e as ações que o governo já faz para mitigar o problema. O objetivo dos contextualizadores, nome dado a estes especialistas, foi auxiliar os participantes a entenderem as características da temática para posterior construção dos mapas.

Em relação ao pensamento sistêmico, foi feita uma breve introdução sobre como a disciplina poderia ajudar a encontrar as relações entre os principais drivers que compõem o problema. Buscou-se também, contar com a criatividade dos participantes para encontrar soluções não obvias, nunca pensadas ou pouco exploradas, advindas das relações de causa e efeito presentes nestas relações.

Estas relações de causa e efeito, no pensamento sistêmico são sutis e não lineares, muitas vezes os efeitos tem delays que só serão percebidos ao longo do tempo, sendo que estas ações podem provocar efeitos em outras partes do sistema. Durante a oficina, os participantes foram direcionados a pensar por processos e não a ver a cena de forma estática. A Extrema Pobreza é um problema complexo, no qual nem sempre as relações de causa e efeito são imediatos.

Cada contextualizador falou por 30 minutos sobre o tema, tanto da perspectiva das métricas, números e tendências, quanto da parte social e sobre os programas de governo para transferência de renda e inclusão produtiva. Na fase de apresentação do tema, os participantes já detectaram alguns padrões que acontecem ao longo do tempo. Ficou claro o looping das pessoas nesta situação, que hora saem da extrema pobreza e com o passar do tempo retornam a condição. Outro fator relevante é o ciclo geracional em que os avôs, pais e filhos permanecem neste cenário.

Durante a oficina, com 8 horas de duração, os participantes receberam uma explicação introdutória sobre pensamento sistêmico, suficiente para a construção das relações de causa e efeito e a identificação dos loops de reforço e balanceamento. A ideia básica de uma estrutura é identificar que tipo de influência uma variável tem sobre a outra. Se eu tenho duas variáveis, só existem duas formas da primeira influenciar a segunda:

Influência positiva, onde a primeira variável, influencia diretamente segunda. Esta relação nós vamos identificar com um sinal de (+). É uma relação direta onde as duas variáveis se movimentam na mesma direção. Eu aumento uma e a outra aumenta, ou diminui a primeira e a segunda também diminui. Podemos indicar também com uma seta cheia.

Influência negativa, onde a primeira variável influência a segunda de forma inversa. Esta relação nós vamos identificar com um sinal de (-). É uma relação inversa onde à medida que eu aumento uma variável, a outra diminui. Podemos indicar com uma seta tracejada.

Durante a explicação teórica foram apresentados também os seguintes arquétipos: soluções que falham, limites ao crescimento, escalada, tragédia dos comuns e adversários acidentais.

Dinâmica

Na parte da tarde, cada grupo contou com um system thinker para auxiliar na construção dos mapas e identificação dos loops. Durante uma hora e meia cada grupo trabalhou na identificação dos drivers e como cada um influencia o sistema. As discussões foram extremamente produtivas e possibilitou a expansão do problema para além do pensamento linear. No final, cada grupo apresentou o seu mapa e as conclusões. No final da oficina, cada grupo sugeriu  um ponto de alavancagem para intervir no sistema.

Para realizar esta dinâmica, foram capacitados 5 pensadores de sistemas com o objetivo de auxiliar os grupos na identificação de loops e arquétipos. A próxima etapa será a formação de um grupo de trabalho para construir o mapa e uma narrativa. A intenção é incluir o pensamento sistêmico como uma disciplina regular para atuação nos problemas complexos de governo, formulação de programas e planejamento por cenários.

Galeria de Fotos

Arquétipo – Limites ao Crescimento

Foco: Planejamento

Este arquétipo foi introduzido por Donella Meadows, Jorgen Randers e Willian Behrens em 1972, em um livro com o mesmo nome. A lição principal é que não existe um comportamento de reforço positivo sem restrições. Sempre há limites que eventualmente se tornam conhecidos e sentidos. Este arquétipo afirma que um processo de fortalecimento do crescimento acelerado (ou expansão) enfrentará um processo de balanceamento à medida que o limite desse sistema for abordado. A hipótese de que os esforços contínuos produzirão rendimentos decrescentes à medida que se aproxima dos limites.

Imagine uma empresa que vende um produto para o mercado. À medida que este produto é vendido, a capacidade de compra pelo mercado diminui, até o ponto em que o mercado está saturado e as vendas caem. Este é o limite! Não adianta para esta empresa investir em caras e pesadas campanhas de marketing sendo que as vendas do produto estão no limite. Neste arquétipo, precisamos aumentar o limite, talvez buscar um outro nicho ou modificar o produto para angariar mais compradores, mas nunca tentar vender a mesma coisa para as mesmas pessoas!

No comportamento ao longo do tempo,  quando os limites ao crescimento são abordados, o mecanismo de crescimento começa a perder sua eficácia e a taxa de crescimento começa a se achatar. No final, apesar da pressão contínua do motor de crescimento, a taxa de crescimento pára e depois inverte-se.

Uma das aplicações práticas para este arquétipo é o planejamento. Se nós não planejamos para o limite, não não estamos planejando para as falhas. Durante mais de um século, muitas variáveis do sistema global têm crescido rapidamente. Por exemplo, a população, a produção de alimentos, a produção industrial, o consumo de recursos e a poluição estão crescendo cada vez mais rapidamente. Seu aumento segue um padrão que os matemáticos chamam de crescimento exponencial. Entretanto, este crescimento é finito e algumas perguntas poderão surgir neste estudo: o que acontecerá se este crescimento parar? Como vai ficar a população sem alimentos? E se a poluição crescer demais? Para responder a este tipo de questionamento, precisamos entender o sistema.

Ao definirmos nossas variáveis de crescimento e os possíveis ponto de atenção de forma antecipada, podemos prever os problemas futuros e eliminá-los antes das ações de desaceleração intervenham no sistema.

O arquétipo de limites ao crescimento é um convite aos gerentes para examinarem as causas que podem esta minando os seus esforços. É muito provável que estes contra-ataques podem estar em partes que não estejam sob o seu controle, ou até mesmo estarem fora da organização. O pensamento sistêmico é uma competência chave para localizar os limites ao crescimento.

O ideal é atuar nos limites!

Modelos Mentais

  • O crescimento é bom, mais crescimento é melhor ainda. Quanto mais trabalhamos, mais cresceremos.
  • Nosso crescimento pode durar para sempre. (Não há limites que não podemos superar.) O atraso ou o colapso não nos acontecerão. Nós somos a exceção.
  • Nossos problemas são causados pelo mercado, a economia, a situação mundial, etc. não poderíamos ser a causa de nenhum dos nossos problemas.
  • Nossos acionistas esperam que continuemos mantendo / melhorando os retornos e não aceitaremos nada além de metas de crescimento

Para gerenciar ou alterar a dinâmica “Limites ao Crescimento”

Em primeiro lugar, suspenda seu modelo mental de que não há limites para o crescimento, pois eles existem. Procure antecipar as forças de desaceleração ou limitação e trate o quanto antes, de preferência antes de ganharem impulso. Ao tratar as ações de desaceleração, caso não possa eliminar, faça o possível para minimizar e atue nas consequências. Se você não conseguir lidar com o “freio”, tire o pé do “acelerador”. Pare de pressionar com mais força seu círculo virtuoso e passe a focar no seu ciclo de balanceamento. Lembre-se de que os processos de reforço são intrinsecamente instáveis. Como você pode adicionar uma estrutura de equilíbrio para proteger o colapso ou a espiral da morte?

Referências

BRAUN, Willian. The System Archetypes. The System Archetypes, [S.l.], 27 fev. 2012. -, p. 4. Acesso em: 30 jan. 2018.

CHICHAKLY, Tabor. see the world differently. isee systems. Disponível em: <https://www.iseesystems.com/>.

MEADOWS, Donella H. The limits to growth. [s.l.]: Universe Books, 1976.

MEADOWS, Donella H.; RANDERS, Jørgen and MEADOWS, Dennis L. The limits to growth: the 30-year update. [s.l.]: Earthscan, 2010.

SENGE, Peter M. A dança das mudanças: os desafios de manter o crescimento e o sucesso em organizações que aprendem. [s.l.]: Campus, 2002.

SENGE, Peter M. A quinta disciplina: Caderno de campo: estratégias e ferramentas para construir uma organização que aprende. [s.l.]: Qualitymark, 1999.

SENGE, Peter M. A quinta disciplina: arte e prática da organização que aprende. [s.l.]: Best Seller, 2009.

14 Hábitos do Pensador de Sistemas

O Pensador Sistêmico para se destacar entre os demais precisa mudar seu foco para a não linearidade dos fatos. Em um sistema, a relação causa e efeito nem sempre são claras e estão distantes no tempo. Abaixo estão alguns hábitos que o pensador sistêmico deve assimilar para alinhar sua forma de análise.

 Cut of soil with different layers sketch icon. 1. Todo o Cenário

Procura entender o cenário como um todo.

Um pensador de sistemas “retrocede” para examinar a dinâmica de um sistema e as inter-relações entre suas partes. Ele vê a floresta, em vez dos detalhes de qualquer árvore.

Questões para considerar

  • Como posso manter o equilíbrio entre o quadro geral e os detalhes importantes?
  • Qual frame devo considerar quando estou olhando para o sistema?
  • Estou mantendo o meu foco em áreas que posso influenciar, ou em áreas de preocupação que eu não posso influenciar?
 Chick peeking out of egg shell sketch icon. 2. Mudanças com o Tempo

Observa como os elementos dentro dos sistemas mudam ao longo do tempo, gerando padrões e tendências.

Os sistemas dinâmicos são constituídos por elementos interdependentes, cujos valores mudam ao longo do tempo. Um pensador de sistemas pode usar uma ferramenta como um gráfico de comportamento ao longo do tempo para gravar e observar os padrões e as tendências que essas mudanças geram. Os gráficos podem fornecer informações sobre a interdependência dos elementos e a estrutura do sistema.

Questões para considerar

  • Quais elementos importantes mudaram no sistema?
  • Como os elementos mudaram ao longo do tempo?
  • Quais os elementos representam grande mudanças e quão rapidamente / lentamente eles estão aumentando ou diminuindo?
  • Que padrões ou tendências surgiram ao longo do tempo?
 Business team sketch icon. 3. Estrutura do Sistema

Reconhecer que a estrutura de um sistema gera seu comportamento.

Um pensador de sistemas entende que a culpa não é uma prática efetiva para produzir mudanças duradouras em um sistema complexo. Em vez disso, ele se concentra na estrutura do sistema para facilitar a compreensão dos resultados do sistema. Um pensador de sistemas percebe que, para efetuar mudanças dentro de um sistema, ele deve conhecer a estrutura.

Questões para considerar

  • Como as peças afetam umas às outras?
  • Como a organização e a interação das partes criam o comportamento emergente?
  • Quando as coisas dão errado, como posso me concentrar em causas internas, em vez de atribuir culpa externa?
 Staff turnover sketch icon. 4. Interdependências

Identifica a natureza circular de relacionamentos complexos de causa e efeito.

Um pensador de sistemas sabe que as relações causa-efeito dentro dos sistemas dinâmicos são circulares em vez de lineares. As relações complexas de causa e efeito incluem feedback de equilíbrio, no qual o sistema está tentando alcançar e manter um objetivo(sistema de aquecimento em uma casa). Também pode haver feedback de reforço, que aumenta ao longo do tempo (população).

Questões para considerar

  • Como as peças se afetam mutuamente?
  • Onde surge a causalidade circular / feedback?
  • Um loop de feedback é mais influente ao longo do tempo do que outro? Se sim, como?
 Family sketch icon. 5. Conexões

Faz conexões significativas dentro e entre os sistemas.

Um pensador de sistemas faz conexões intencionalmente para entender as relações. A aprendizagem é alcançada quando novos conhecimentos são integrados. Cria um significado ao considerar a forma como novas informações se conectam ao conhecimento anterior, adicionando, modificando, transferindo e sintetizando a informação para uma compreensão mais profunda.

Questões para considerar

  • Quais são as relações entre peças do sistema e como elas afetam a compreensão do todo?
  • Como diferentes perspectivas de um sistema funcionam juntas para beneficiar o sistema?
  • Como a compreensão de um sistema se transfere para a compreensão de outro sistema?
 Circus old bicycle sketch icon. 6. Mudança de Perspectiva

Muda as perspectivas para aumentar a compreensão.

Para entender como um sistema dinâmico realmente funciona, um pensador de sistemas examina o sistema a partir de uma variedade de ângulos diferentes e de diferentes pontos de vista, talvez em colaboração com outras pessoas.

Questões para considerar

  • Estou aberto a outros pontos de vista?
  • Como diferentes pontos de vista influenciam a maneira como eu entendo o sistema?
  • De quem devo me aproximar para me ajudar a ganhar novas perspectivas sobre um problema?
  • Quando aprendo sobre novas perspectivas, estou disposto a mudar minha opinião?
 Human head with idea sketch icon. 7. Suposições

Traz à tona e testa as suposições.

Um pensador de sistemas examinará rigorosamente os pressupostos para obter uma visão de um sistema. Estes insights postos em ação podem aumentar a performance. A Escada da Inferência (mostrada abaixo) é uma ferramenta visual que ajuda as pessoas a considerar como e por que    o desenvolvidas e as ações são tomadas com base em dados percebidos.

Questões para considerar

  • Como minhas experiências passadas influenciam o desenvolvimento de minhas teorias e suposições?
  • Quão bem a minha teoria ou modelo combina com o sistema em estudo?
  • Ao considerar uma possível ação, eu e aqueles que eu trabalho perguntam sempre “E se?”?
 Domino sketch icon. 8. Questões Completas

Considera uma questão completamente e resiste o desejo de chegar a uma conclusão rápida.

Um pensador de sistemas é paciente. Ele levará tempo para entender a estrutura do sistema e seus comportamentos antes de recomendar e implementar uma ação. Um pensador de sistemas também entende que sucumbir ao desejo de uma solução rápida pode criar mais problemas a longo prazo. Ele está ciente da tensão criada quando uma resolução não é implementada imediatamente e é capaz de manter essa tensão enquanto uma compreensão mais profunda do sistema é desenvolvida.

Questões para considerar

  • Quanto tempo precisamos para entregar a resolução desta questão?
  • Como podemos gerenciar a tensão que existe quando os problemas não são resolvidos imediatamente?
  • Como posso ajudar os outros a serem pacientes enquanto vivem com problemas não resolvidos?
 Cloud computing sketch icon. 9. Modelos Mentais

Considera como os modelos mentais afetam a realidade atual e o futuro.

Em qualquer situação, um indivíduo percebe e interpreta o que está acontecendo, criando assim uma imagem, ou modelo mental, de algum aspecto do mundo. Os modelos mentais são constituídos por suposições, crenças e valores que as pessoas possuem, às vezes por toda a vida. Um pensador de sistemas está ciente de como esses modelos mentais influenciam as perspectivas e as ações tomadas.

Questões para considerar

  • Como os modelos mentais atuais estão avançando nos resultados desejados?
  • Como os modelos mentais atuais impedem nossos esforços nessa área?
  • Como eu estou ajudando os outros a ver a influência que os modelos mentais têm em nossa tomada de decisão?
 Robotic packaging sketch icon. 10. Alavancagem

Usa a compreensão do sistema para identificar possíveis ações de alavancagem.

Com base em uma compreensão da estrutura, interdependências e feedback dentro de um sistema, um pensador de sistemas implementa a ação de alavancagem que parece mais provável produzir resultados desejáveis. De acordo com Senge (1990), a alavancagem é “… ver onde as ações e as mudanças na estrutura podem levar a melhorias significativas e duradouras”.

Questões para considerar

  • Onde uma pequena mudança pode ter um efeito desejado e duradouro?
  • Como podemos usar o que sabemos sobre o sistema para identificar possíveis ações de alavancagem?
  • Existem outras pequenas mudanças que ainda não consideramos que poderiam nos trazer resultados desejáveis
 Shop store sketch icon. 11. Consequências

Considera as consequências de curto prazo, longo prazo e as não intencionais.

Antes de tomar medidas para mudar um sistema dinâmico, um pensador do sistema pesa os possíveis resultados a curto prazo, a longo prazo e os não intencionais da ação. Esta prática aumenta a probabilidade de a ação escolhida produzir os resultados desejados.

Questões para considerar

  • Há conseqüências não intencionais que podem levar a novas ações?
  • Quais as conseqüências não intencionais da ação  proposta e quais compromissos devemos assumir?
  • Quais são as possíveis conseqüências a curto e longo prazo das ações propostas?
  • Estamos dispostos a aceitar a dor a curto prazo para ganho a longo prazo?
 Carton package box sketch icon. 12. Estoques

Presta atenção aos estoques e a taxa de mudança.

As acumulações são quantidades que podem aumentar e diminuir ao longo do tempo. Podemos usar uma ferramenta como um diagrama de estoque e fluxo para identificar acumulações dentro de um sistema e os relacionamentos interdependentes entre eles. As  representações podem ajudar a comunicar uma compreensão da estrutura de um sistema e a identificar alavancagem potencial para aumentar ou diminuir uma acumulação ao longo do tempo.

Questões para considerar

  • Quais elementos em um sistema estão visíveis, quais posso sentir, contar ou medir como quantidades que mudam ao longo do tempo, por exemplo, nível de felicidade?
  • Quão rápido (ou lentamente) essas acumulações aumentam e diminuem?
  • Como a acumulação afeta outros elementos em um sistema?
  • O que pode acontecer se um acúmulo atingir um ponto de inflexão?
 Man with pregnant wife sketch icon. 13. Impacto do Tempo – Atrasos

Reconhece o impacto dos atrasos de tempo ao explorar relacionamentos de causa e efeito.

Um pensador de sistemas reconhece que quando uma ação é tomada dentro de um sistema complexo e dinâmico, este resultado da ação pode não ser visto por algum tempo. Um pensador de sistemas explicará o impacto que esses atrasos no sistema.

Questões para considerar

  • Se fizermos uma mudança no sistema, em  quanto tempo veremos os resultados que desejamos?
  • Como podemos identificar o papel dos atrasos nos efeitos que esperamos ver?
  • Será que a mudança que propomos mostra resultados imediatos ou precisamos esperar para ver melhorias? Se precisarmos esperar, por quanto tempo?
 Scalability sketch icon. 14. Aproximações Sucessivas

Verifica resultados e muda as ações, se necessário: “aproximação sucessiva”.

Os sistemas dinâmicos estão em constante mudança ao longo do tempo. Um pensador de sistemas, portanto, monitora e avalia o comportamento do sistema e toma medidas quando necessário para garantir que o sistema continue produzindo os resultados desejados. Inicialmente pode ser difícil determinar uma “melhor solução” para um problema percebido. Ao tentar uma solução e depois avaliar os resultados, a compreensão da questão aumentará. Ao longo do tempo, cada ciclo ou aproximação sucessiva, de verificação de resultados e sucessivas mudanças, se necessário, moverá o sistema mais próximo do objetivo desejado.

Questões para considerar

  • Que indicadores esperamos ver à medida que buscamos o progresso?
  • Nós agendamos o tempo para pausar, avaliar os efeitos do nosso plano atual e tomar as medidas necessárias?
  • Ao considerar mudanças, estamos acessando outros hábitos de pensamento de sistemas?

Fonte: http://watersfoundation.org/ com adaptações.