Introdução


Organizações de grande porte possuem processos de negócio muito complexos, os quais dificilmente são revistos pelos funcionários da empresa de forma sistemática. Como consequência disso, as razões principais para uma tomada de decisão operacional precipitada geralmente passam despercebidas até provocarem grandes perdas. Um exemplo é o banco alemão IKB, que perdeu cerca de $3,3 bilhões desde o início da crise do subprime nos EUA, graças a uma análise errada dos seus riscos. Outro caso é a nova estação principal de Berlim, cujos custos de projeto foram calculados em 700 milhões de dólares, em 1997, e quase duplicaram durante a sua construção, chegando a 1,2 bilhões de dólares. Enquanto problemas como esses podem demandar uma mudança substancial nos processos (nesses casos, nas políticas de riscos e na estimação de custos de projetos), não é tão óbvio como as reais causas raízes desses problemas podem ser identificadas de uma maneira sistemática.

A Análise de Causa Raiz vem sendo conduzida na indústria através de uma variedade de técnicas (ver [1]). Enquanto os fluxogramas têm sido identificados como ferramentas potenciais para facilitar a Análise de Causa Raiz, a prática recorrente baseia-se, principalmente, em brainstormings e em técnicas pouco formais [2]. O fato de que organizações de grande porte possuem, usualmente, um grande número de documentos sobre seus processos de negócio, em termos de seus modelos, não tem sido bem explorado até hoje. Por outro lado, quanto ao reprojeto de processos de negócio, o foco tradicional ainda é no desenho de modelos que reflitam as práticas atuais (chamados modelos as-is) seguidos pelo desenho de modelos de processos melhorados (to-be) [3]. Nesse contexto, a ponte entre processos as-is e to-be é insuficientemente feita com o auxílio de ferramentas populares de modelagem de processos. Na realidade, a combinação de modelos de processos de negócio e Análise de Causa Raiz tem o potencial de revelar problemas em uma organização de uma maneira mais sistemática, dependendo, cada vez menos, da intuição dos envolvidos na análise.

Contra esse pano de fundo, nós apresentamos uma técnica nova para conduzir Análises de Causa Raiz baseadas em modelos de processos de negócio. Dessa forma, nossa contribuição é um mecanismo para complementar linguagens para modelagem de processos – usaremos os Event-driven Process Chains (EPCs) para fins ilustrativos – com conceitos de Engenharia de requisitos2. Em particular, nós reutilizamos ferramentas consagradas de mensuração de softwares, tais como modelos de qualidade, obtenção e explicitação de softgoals, a abordagem Goal/Question/Metric (GQM) e a correlação de softgoals como fatores para uma abordagem sistemática sobre a condução de Análises de Causas Raízes. Nós nos referimos a essa técnica como Análise de Causa Raiz baseada em Processos (ACRP).

O restante do artigo é estruturado da seguinte forma: na Seção 2 é introduzido um case sobre um processo de projeto de software, o qual é usado pela Software House Inc. (SH) para participar de concorrências. Recentemente, a SH ganhou um negócio graças a uma estimativa ilusoriamente baixa dos custos do projeto. A fim de evitar maiores perdas no futuro, a SH precisa descobrir porque essa estimativa estava errada. Na Seção 3, nós introduzimos nossa abordagem para Análise de Causa Raiz. Em particular, apresentamos um metamodelo de nossa técnica e depois discutimos cada passo para entender e disseminar esse modelo. Para ilustrar, nós usamos o exemplo da proposta da SH. Após isso, a Seção 4 compara nossas técnicas com diferentes áreas de trabalhos relacionados ao assunto. Finalmente, a Seção 5 conclui o artigo.


_____________________________

22Engenharia de requisitos (ou requirement engineering) é um processo que envolve todas as atividades necessárias para a produção de um documento sobre os requisitos (funcionais ou não-funcionais) de um sistema e sua manutenção durante o tempo. (N. do T.)