Resolução de Problemas em Serviços de TI

Passei a gostar de Filosofia e sua utilidade nas minhas aulas do Doutorado. Em uma matéria de Ética e Gestão Ambiental tive contato com os ensinamentos sobre Método de René Descartes, Ética de Kant/Hegel e Tédio/Stress de Schopenhauer. Em seu famoso livro “Discurso do Método” de 1632, Descartes dizia que a filosofia era uma coleção de opiniões e, para não basear decisões em opiniões, resolveu sair do conforto do seu quarto aquecido e caminhar pela fria Europa para conhecer a verdade. Neste livro (encontrado em qualquer livraria. Comprei o meu por R$ 10,00), ele recomenda, entre outras coisas:

“Nunca confiar nos sentidos, em vez disto procurar todas as evidências possíveis sobre a veracidade de qualquer coisa.”

Dividir cada um dos problemas em tantas parcelas quantas forem necessárias (mais tratáveis). Começar pelos objetos mais simples e mais fáceis de serem conhecidos para, aos poucos, como que por degraus, chegar aos mais complexos e, para cada caso, fazer enumerações o mais exatas possíveis a ponto de estar certo de nada ter omitido. Eis alguns trechos do livro.

No Brasil, entre os seguidores do método de Descartes temos o INDG (Vicente Falconi), Ambev e Gerdau. O professor Falconi, em entrevista a HSM Management em 2008, falava que o método é a busca e o conhecimento da verdade (do grego Meta = Meta, Hodos = Caminho, portanto: Caminho para a Meta). Existem as verdades mostradas na análise dos dados e fatos. E as empresas, na grande maioria, não trabalham com elas. As pessoas vivem tomando decisões, que custam milhões, baseadas em opiniões. Todo gestor deveria ler Descartes. Precisa ser normal um bom gestor exigir que um plano de ação se baseie em análise, em qualquer nível hierárquico. As pessoas têm de achar, naturalmente, que é a análise que funciona. Vicente Falconi conta um fato curioso que aconteceu na Ambev. Numa reunião, quando o sujeito chegava lá com um plano de ação, o Carlos Brito (Presidente Mundial da InBev) pedia para ele mostrar a análise. Não tendo análise, o Brito dizia: “Não acredito nas ações que você propõe”. O Brito começou a fazer isso sistematicamente e dali a pouco todos faziam análise.

Traduzindo o método de Descartes para o mundo da informática. Na Gestão de Serviços de TI, os problemas não são vistos como oportunidades de melhoria, mas sim de fracassos e, desse modo, são ocultados em vez de serem abordados. Existe uma tentação de passar do problema direto para um plano de ação, sem uma análise bem elaborada. Existe a necessidade de reforçar que a identificação correta do problema é a fase mais importante e deve ser a etapa onde a maior parte do esforço é aplicada, já que um excelente trabalho para resolver o problema errado tem pouco impacto a longo prazo.

“Não se deve resolver um problema de 5 centavos
com uma solução de 1 real.”

Bem, quais as alternativas ? Existem vários métodos de resolução de problemas indicados para serviços de TI. Vou abordar aqui algumas visões incorporadas em três conjunto de melhores práticas: ITIL v3, CMMI 1.2 for Services e STP (Sistema Toyota de Produção). Bem, o ITIL v3 tornou-se muito mais prescritivo no processo de gerenciamento de problemas, trazendo conceitos como gráfico de ishikawa, 5 whys e outros. No ITIL v2 a análise de causa raiz (RCA) resumia-se à descrição do seu conceito. O ITIL v3, Além do KEDB (Known Error DataBase) que faz parte do SKMS (Service Knowledge Management System), traz uma série de ferramentas úteis para análise. No apêndice D do livro Service Operation, é apresentado o diagrama de ishikawa com uma série de passos para análise da causa raiz. No apêndice C é apresentado o método Kepner & Tregoe para análise de resolução de problemas. Este conceito trabalha com a definição do problema, estratificação, estabelecimento das possíveis causas (utilizando técnicas como 5whys), teste da causa mais provável e elaboração do plano de ação para resolução da causa raiz. O CMMI 1.2 for Services apresenta dentro da área de processo CAR (Causal Analysis and Resolution) uma série de sub-processos direcionados para análise e resolução de problemas. Contempla seleção de defeitos e problemas, análise de causas, Implementação das ações, análise da eficácia e registro em base de conhecimento. O CMMI recomenda também técnicas prescritivas com o Pareto, 5Whys, Ishikawa, 5w2H (plano de ação) e DOE (Planejamento de Experimentos). Traz também em suas práticas genéricas provisão de recursos, determinação de responsabilidades e envolvimento de stakeholders no processo de CAR. O SD (Service Delivery), um dos novos processos do CMMI Svc, aborda vários assuntos relacionados com o tema, a exemplo de análise de performance de dados e prevenção de incidentes em aplicações.

No STP (Sistema Toyota de Produção), a metodologia de solução de problemas percorre toda a empresa e todas as funções. A melhoria deve ocorrer em todo o tempo, em todos os níveis e em todos os profissionais. Lembro-me de um caso contado no livro de Michael Hammer, “a Agenda”, sobre um faxineiro com visão de processos e outro sem nenhuma visão. Ao perceber a presença de um chiclete no chão, o primeiro passa a vassoura e não o remove (sua visão é de passar a vassoura de um lado para o outro) enquanto o segundo preocupa-se em pegar uma ferramenta para retirar o chiclete. Sua preocupação é ter a sala limpa, pois alguém precisará dela na sequência (reunião, treinamento). Este segundo profissional vai além: sugere uma conscientização para os usuários da sala não jogarem chiclete no chão (resolução do problema). Na Toyota é sempre questionado: “por que você escolheu este problema ? “, “Como você determinou que o problema merece seu tempo e atenção ?. O STP questiona a tendência de “pular” imediatamente do “problema” para a “solução”, exatamente como afirmava Descartes. Com relação a análise de causa raiz o STP enfatiza bastante o conceito de 5whys (cinco porquês). Segundo o método, em quase todas as situações, há várias causas para os problemas; assim, a análise deve ser abrangente.

“Como há diversas causas possíveis, é necessário limitar-se às mais significativas. A limitação permite a concentração dos esforços para gerar melhores resultados.”

Pelo que foi explicado, conclui-se que há necessidade das empresas e departamentos de TI ensinarem habilidades básicas de solução de problemas para todos os seus profissionais, de modo que todos se tornam solucionadores de problemas, com claro retorno de investimento. Não ficaremos mais no “apagar incêndio” do dia-a-dia. Uma frase do STP que carrego sempre comigo é: "A Densidade gera mudanças". Para um conhecimento mais avançado dos métodos apresentados, recomendo a leitura de dois livros: Root Cause Analysis (RCA) da ASQ (American Society for Quality) e do livro Root Cause Analysis Handbook (vide fotos neste post). Bem, eis um assunto bem instigante e desafiador.