Tópico:

- Troca de correspondências sobre megaprojetos encaminhada para à lista TOC –

 

Carta de Humberto Baptista
__________________________________________

 

—– Original Message —–
From: Humberto Baptista
To: toc-brasil@yahoogrupos.com.br
Sent: Friday, June 19, 2009 11:45 AM
Subject:[toc-brasil] TOC em mega projetos

 

     Olá Rômulo,

     O quanto você sabe sobre TOC?
     Com o risco de “chover no molhado”: você conhece o princípio de Pareto, certo? 80% dos fenômenos pode ser explicado por 20% das causas em uma coleção de eventos independentes. Agora se os eventos não são independentes a relação não é mais 80:20, mas em geral sobe para 99:1 ou mais ainda. Ou seja, quanto mais fortemente conectado um sistema menos causas impactam o sistema como um todo.
Imagine agora “mega projetos”: existem muitas relações entre as partes destes, tantas que às vezes a própria rede de projetos (que deveria ser uma visão simplificada da relidade) chega a ser incompreensível. Justamente por esta vasta quantidade de relacões de causa e efeito podemos ver que o número de causas (ou pontos de alavancagem) nestes sistemas é muito pequeno.
      A TOC fornece ferramentas para identificar os pontos de alavancagem (restrições) e gerenciar o sistema através deles.

 

Abraços,
Humberto

 

___________________________________
Peter Mello, em resposta ao debate:

 

     Humberto,

     Goldratt fala da “Simplicidade Inerente” e por isso defende projetos simplificados em até 300 atividades, não é isso?

     Creio que por isso você fala que uma rede “deveria ser uma visão simplificada da relidade”, certo?

      Este é um ponto fundamental de diferença entre a abordagem de Restrições desenvolvida por Goldratt e uma abordagem de Restrições desenvolvida com base ao RCP (Resource Critical Path) na Rússia.

      Depois de estar em um evento com Goldratt e ter participado do seu webcast (graças ao seu generoso convite junto com o Alonso), eu mais do que nunca acredito que este conceito “de manter simples” é um mecanismo de lidar com o problema mais amplo quando não se tem ferramentas adequadas para os cálculos em menor nível.

     Ou seja: Já que a rede fica grande e eu não sei o que fazer com ela, preciso simplificar a rede para poder fazer algo!

      No entanto, vivemos em um mundo de altíssimo avanço tecnológico e da mesma forma que um engenheiro faz desenhos eletrônicos usando CAD, podemos desenhar cronogramas detalhadíssimos, utilizando as melhores ferramentas da qualidade para entender o MENOR grão possível do projeto e – sem entender exatamente como o software faz – ter um resultado em um nível mais alto, em que eu ENXERGO e ENTENDO, algo que será melhor do que eu simplificar por conta própria.

      Ou seja: Eu acho que todos os conceitos de CCPM são aplicáveis em pequenos, médios e mega projetos, menos o conceito de redes simplificadas. Há centenas, se não milhares, de restrições que precisam ser trabalhadas nestes megaprojetos e para você focar nas mais importantes, precisa que “alguém mais” (ou o software) resolva boa parte das outras por você!

     PROJETOS SÃO DINÂMICOS. A instabilidade é muito mais comum neste ambiente do que na indústria, onde nasceu a TOC. Por esta razão, uma rede de projeto pode mudar drasticamente da noite para o dia simplesmente por que uma equipe de projeto não pode chegar ao local, ou um equipamento importante quebrou.

     Na indústria, uma máquina quebrada é tratada pelas reservas para as incertezas e logo que ela é reparada, a sequencia de atividades continua. Se o tempo quebrado for MENOR do que o buffer, a sequencia continua sem grandes prejuízos.

      Em um projeto, uma máquina quebrada não pode ser só tratada pelas reservas! A ausência da mesma pode determinar que um conjunto completamente novo de atividades precise ser executado, ou uma nova sequÊncia de uso dos recursos seja criada para lidar com a impossibilidade de trabalhar exatamente naquele segmento.

      SUPONHA que em meu projeto eu precise de uma PONTE para atividades subsequentes que será construída no próprio projeto. Em função da forma com que organizo as atividades baseado nos recursos possíveis, pode acontecer que eu programe para DEPOIS da ponte atividades que de fato poderiam ser feitas SEM ela, mas por falta de recursos eu primeiro planejei eles utilizados na PONTE e depois então nas atividades remanecentes.

      Em uma rede CCPM, eu vou colocar um buffer e minha sequência no caminho crítico fica IMUTÁVEL. Assim, se a PONTE sofre atrasos ou quebra, todas as atividades seguintes na mesma rede ficam aguardando a solução, enquanto o buffer vai sendo consumido. Em muitos casos, mesmo que o gerente possa atuar de forma distinta, como o CRONOGRAMA é simplificado, ele nem percebe as demais coisas que pode fazer enquanto espera a ponte (planejamento da rede com nível pequeno de detalhe).

      Em uma rede SDPM, eu não tenho o buffer “preso” a um único caminho e tenho detalhadamente TODAS as atividades que cada recurso pode efetuar. No momento em que a PONTE não está disponível, eu posso reprocessar todo o diagrama de redes e adiantar atividades que de fato não dependem da ponte enquanto o problema é resolvido.

     Portanto, meu alerta para o Rômulo é: Se não tem ferramenta adequada, use CCPM x CPM que você terá muitas vantagens. Se pode contar com ferramentas de otimização de cronograma, planeje em maior detalhe e utilize CCPM aliado a conceitos de SDPM, para lidar com as incertezas dos mega projetos!

Abraço,

 

Peter Mello, PMI-SP, PMP
The Spider Team

http://www.thespiderteam.com/sdpm