Gestão por Processos

Lendo o livro de David Anderson (2010 - Kanban), percebi um detalhe interessante que estava passando desapercebido por mim.

Ele diz que descobriu e ficou curioso sobre teoria das restrições, e aprendeu os conceitos iniciais desta técnica. São cinco passos para melhorar o desempenho do sistema a partir da identificação do elo mais fraco da corrente. Muito simples, muito interessante, dizem que roubado dos japoneses que não tinha tradição de publicar nada, mas já praticavam a maioria das técnicas propostas por Goldratt sem ter documentado no Sistema Toyota de Produção.

Ocorre que no trabalho em manufatura tais conceitos são claramente úteis, mas na administração de serviços administradores, gerentes de projeto, executivos mais tradicionais não percebem como ou onde aplicar tais técnicas. A administração contemporânea de serviços segue uma linha de princípios e técnicas separada da manufatura industrial.

Entretanto David Anderson explica que ao perceber os conceitos da indústria de manufatura, instintivamente percebeu como aplicá-los para o gerenciamento do desenvolvimento de software.

Ele percebeu que poderia olhar para o problema de desenvolvimento de software como um trabalho em fluxo. Desta forma a otimização do fluxo poderia utilizar a técnica de TOC (Theory of Constraints) de Goldratt, com a qual ele estava encantado.

Ele aplicou em seu trabalho como gerente de projetos na M$ e obtever resultados muito bons.

Na verdade, muitos dizem que TOC é um sistema produtivo, mas eu o considero na verdade uma filosofia para otimização de processos. Deverá existir um processo especificado para a produção que será otimizado pelos princípios da TOC.

Da mesma forma, existem outras metodologias de otimização de processo como o Pensamento enxuto com seus 5 passos, as ferramentas do STP, Six-Sigma, Sense and Respond, Sistema da Volvo, entre outros.

Ele deu continuidade em seus estudos e percebeu a amplitude de conhecimento sobre processos no Sistema Toyota de Produção e no Lean Thinking. Melhorou ainda mais os resultados para desenvolvimento de software.

Ao publicar estes resultados causou polêmica na academia, pois de fato as áreas de manufatura e serviços ainda usam princípios e teorias separadas.

Ocorre que qualquer ambiente administrativo "gerenciado" por administradores "convencionais" pode ser transformado em um processo, e como tal, irá apresentar sob este novo ponto de vista um fluxo, com lead-time, cycle-time, variação, anormalidades, sigmas, etc.

Isto se chama Gerenciamento por Processos. Pode-se manter todos os conceitos da "ciência administrativa", e seus caminhos, paradigmas e tal, porém observando o sistema delimitando-o geograficamente como um processo, limitado pelas fronteiras, entradas e saídas, e possibilitando assim trazer a cultura de processos da indústria para o ambiente de serviços.

Assim, torna-se possível melhorar 5 a 10 vezes o desempenho de qualquer departamento administrativo. As melhorias de qualidade na produção chegam a taxas superiores 90% em departamentos mal "administrados". Diminuição de erros, utilizando por exemplo six-sigma são imensas.

Ao ler o livro Lean Office, que é um dos poucos sobre Lean para Serviços, percebi que na verdade existe uma Lacuna gigantesca neste tema. A Engenharia de Produção domina perfeitamente os conceitos de administração de fluxo, conceitos sobre processos, enquanto áreas originalmente de serviços estão tateando para começar a entender sobre o assunto.

A Engenharia de Software por exemplo, ao tratar de Processos, como no CMMI, não faz idéia sobre o que significa otimização, em seu nível 5.

As referência bibliográficas utilizadas no CMMI são baseadas na década de 90 e antes. Eles descobriram Deming mas ainda usam Ford e Taylor, enquanto na Engenharia de Produção já se estuda Sistemas que Aprendem, Chaordics, e muito mais.

A distância entre a Engenharia de Software e a Engenharia de Produção pode ser medida diante das datas das referência bibliográficas sobre processo utilizadas nas últimas publicações.

FATO: ao identificar informações sobre processos e gerenciamento de processos da engenharia de software estará identificando referências ingênuas, ultrapassadas e que já tiveram sua contribuição em outra realidade que não a nossa.

CMM e CMMI não são antigos, mas pecam ao não perceberem o mundo que existe por traz do gerenciamento de processos, que não se limita a Taylor, Fordismo, e às primeiras contribuições de Deming.

Por volta de 2004 a SEI começou, timidamente a avaliar Six-Sigma, que tem muito a contribuir, mas parece não ser ainda considerada por eles uma ferramenta padrão para seu processo.

Acredito sinceramente em six-sigma e em controle estatístico de processos, porém entendo que o conjunto da obra do Sistema Toyota de Produção e o Pensamento Enxuto é muito, mas muito mais apropriado para lidar com desenvolvimento de software.

Não se trata de eliminar a variabilidade do processo, mas sim de ser reativo a variação.

Na indústria, variações como anormalidades devem ser suprimidas.
Na Engenharia de Software ainda não se percebeu que o mundo está mudando rapidamente, e que esta mudança é adaptativa. Empresas precisam se adaptar rapidamente. Fechar o escopo neste contexto, ou eliminar este tipo de variação não é o que a indústria precisa.

Existe uma diferença GRANDE entre eliminar o desvio do erro, de eliminar a variabilidade decorrente da demanda. Se a demanda for verdadeira deve haver resposta ágil do sistema.

Penso.