Grupo: Turma GEEP17/SP – Gestão Estratégica e Econômica de Projetos
ANDRÉ PONTES SAMPAIO ARISTIDES SOUZA BARCELLOS CRISTIANE NICOLI SANSEVERO EDUARDO SALVADOR RAMOS
ANÁLISE COMPARATIVA ENTRE METODOLOGIAS DE
GERENCIAMENTO DE RISCOS BASEADAS NO PMI, FMEA,
HAZOP, ISO 31000 E MERCADO FINANCEIRO
Trabalho apresentado ao curso MBA em Gerência de Projetos, Pós-Graduação lato
sensu, da Fundação Getulio Vargas como
requisito parcial para a obtenção do Grau de Especialista em Gerência de Projetos.
ORIENTADOR: Prof. Mário Luis Sampaio Pereira
São Paulo 04/2011
FUNDAÇÃO GETULIO VARGAS PROGRAMA FGV MANAGEMENT MBA EM GERÊNCIA DE PROJETOS
O Trabalho de Conclusão de Curso
ANÁLISE COMPARATIVA ENTRE METODOLOGIAS DE
GERENCIAMENTO DE RISCOS BASEADAS NO PMI, FMEA,
HAZOP, ISO 31000 E MERCADO FINANCEIRO
elaborado por André Pontes Sampaio, Aristides Souza Barcellos, Cristiane Nicoli Sansevero, Eduardo Salvador Ramos e aprovado pela Coordenação Acadêmica do curso de MBA em Gerência de Projetos, foi aceito como requisito parcial para a obtenção do certificado do curso de pós-graduação, nível de especialização do Programa FGV Management.
São Paulo, 05 de Abril de 2011
Carlos A. C. Salles Jr. Coordenador Acadêmico Executivo
Mário Luis Sampaio Pereira Prof. Orientador
TERMO DE COMPROMISSO
O(s) aluno(s) André Pontes Sampaio, Aristides Souza Barcellos, Cristiane Nicoli Sansevero e Eduardo Salvador Ramos, abaixo assinado(s), do curso de MBA em Gerência de Projetos, Turma 17 do Programa FGV Management, realizado nas dependências da Fundação Getúlio Vargas – São Paulo, no período de 17/08/2009 a 07/12/2010, declara que o conteúdo do Trabalho de Conclusão de Curso intitulado ANÁLISE COMPARATIVA ENTRE METODOLOGIAS DE GERENCIAMENTO DE RISCOS BASEADAS NO PMI, FMEA, HAZOP, ISO 31000 E MERCADO FINANCEIRO, é autêntico, original e de sua autoria exclusiva.
São Paulo, 05 de Abril de 2011
André Pontes Sampaio
Aristides Souza Barcellos
Cristiane Nicoli Sansevero
À Deus pela oportunidade. Às nossas famílias, por tudo. Aos professores e amigos que trabalham arduamente
RESUMO
A área de gerência de projetos que lida com estas incertezas ou problemas, mesmo antes que eles ocorram, é a gerência de riscos. Entender e tratar adequadamente tais riscos, visando minimizar impactos negativos nas organizações é o principal objetivo do processo de Gerenciamento de Risco.
Como forma de auxiliar o gerenciamento de riscos, surgiram no mercado algumas metodologias e ferramentas com o propósito de permitir identificar, analisar e traçar respectivos planos de ação de resposta aos riscos dos projetos.
O presente trabalho discute brevemente a fundamentação teórica de Gerenciamento de Projetos e Gerenciamento de Riscos. O objetivo principal é apresentar a conceituação teórica e prática das principais metodologias para análise e gerenciamento de riscos em projetos (PMBOK, FMEA, HAZOP, ISO 31000 e mercado financeiro); verificar o respectivo favorecimento na análise de riscos; efetuar um comparativo entre elas no tocante às perspectivas de aplicabilidade - ambiente de negócios mais compatível - e apresentar as vantagens e desvantagens de cada metodologia.
A escolha de uma metodologia de gerenciamento de riscos integrada com o projeto e alinhada à organização, certamente garantirá o sucesso deste processo.
Palavras Chave: Metodologias de análise de risco, PMBOK, FMEA, HAZOP, ISO
31000, riscos no mercado financeiro, Gerenciamento de Projetos, Gerenciamento de Riscos
ABSTRACT
Risk Management Plan is an important part of any project management. Risk Management Plan deals with uncertainties or problems even before they occur. To understand and provide risk responses in order to minimize negative impacts in an organization is the main purpose of the Risk Management Plan.
In order to perform a project risk management, several project risk management tools and methodologies enable us to identify, analyze and establish risk response action plans.
This research presents a general view of Project Management and Risk Management theories. The main objective of this narrative is to present the mains project risk management methodologies (PMBOK, FMEA, HAZOP, ISO 31000 and financial market); to analyze the benefits coming from their use; to establish a comparative analysis between them in respect of business perspective applicability and determine their advantages and disadvantages.
Choosing a good methodology, adherent to the company’s needs and projects, will certainly ensure a successful risk management process.
Key Words: Risk management tools, PMBOK, FMEA, HAZOP, ISO 31000, financial
AGRADECIMENTOS
Às nossas famílias pelo apoio, incentivo e por acreditarem em nós.
Agradecemos em especial nossos queridos pais, pois sem seus esforços para nos educar, nós não teríamos chegado a lugar algum.
SUMÁRIO 1. INTRODUÇÃO ... 10 1.1.PROPOSTA DO TRABALHO... 10 1.2.OBJETIVO... 12 2. FUNDAMENTAÇÃO TEÓRICA... 12 2.1.O QUE É PROJETO? ... 12
2.2.O QUE É GERENCIAMENTO DE PROJETOS? ... 13
2.3.O QUE É RISCO? ... 13
2.4.O QUE É GERENCIAMENTO DE RISCOS? ... 13
2.5.O QUE É METODOLOGIA? ... 14
2.6.POR QUE É IMPORTANTE GERENCIAR RISCOS EM PROJETOS... 14
3. METODOLOGIA DE GERENCIAMENTO DE RISCO ... 15
3.1.HAZOP ... 15
3.2.FMEA... 24
3.3.ISO31000... 34
3.4.PMBOK ... 54
3.5.MERCADO FINANCEIRO... 61
4. ANÁLISE COMPARATIVA ENTRE OS MÉTODOS... 66
4.1.RELACIONAMENTOS ENTRE PROCESSOS... 66
4.2.MATRIZ COMPARATIVA... 68
5. CONCLUSÕES... 72
7. REFERÊNCIAS BIBLIOGRÁFICAS ... 101
8. GLOSSÁRIO ... 104
LISTA DE FIGURAS E TABELAS Figura 1 Fluxograma de análise de desvio ...22
Figura 2 Formulário de registro da análise HAZOP ...23
Figura 3 Formulário Padrão de FMEA (IQA, 2001) ...10
Figura 4 Componentes do framework...39
Figura 5 Processos de gestão de risco ...46
Figura 6 Processos de gestão de risco ...55
Figura 7 Fluxograma de análise de risco de projeto pela metodologia HAZOP ...84
Figura 8 Formulário de registro da análise HAZOP para gerenciamento de risco em projeto....85
Tabela 1 Palavras-chave da análise HAZOP e respectivos desvios ...20
Tabela 2 Palavras-chave da análise HAZOP e respectivos desvios ...20
Tabela 3 Critérios de exeqüibilidade sugeridos...21
Tabela 4 Índice de ocorrência ...27
Tabela 5 Índice de severidade ...28
Tabela 6 Índice de detecção...29
Tabela 7 Escala de N.P.R ou RPN (IQA, 2001) ...29
Tabela 8 Metodologia HAZOP...67
Tabela 9 Metodologia FMEA ...67
Tabela 10 Metodologia ISO 31000...67
Tabela 11 Metodologia PMBOK...68
Tabela 12 Metodologia Mercado Financeiro ...68
Tabela 13 Principais características da metodologia HAZOP ...69
Tabela 14 Principais características da metodologia FMEA ...69
Tabela 15 Principais características da metodologia ISO 31000 ...69
Tabela 16 Principais características da metodologia PMBOK ...70
Tabela 17 Principais características das metodologias CreditRisk+ e Credit Portifolio View ...70
Tabela 18 Principais características das metodologias KMV e Credit Metrics ...71
Tabela 19 Grupo de palavras-chave para análise de desvios do projeto e os respectivos desvios gerados ...81
1. INTRODUÇÃO
1.1. Proposta do trabalho
Quando falamos em gerenciar projetos, surgem muitos termos em comum, como: escopo, tempo, custo, qualidade, recursos, comunicação, dentre outros. À medida que o tempo passa, vivenciamos experiências e delas extraímos algumas lições. De modo análogo, podemos perceber que gerenciar projetos é um processo em constante evolução, agregando conceitos que muitas vezes já existem, mas que não puderam ser percebidos naquele momento. Esses conceitos lentamente ganham visibilidade por se tornarem comuns em lugares diferentes. Alguns deles são vistos como causas de sucesso ou de fracasso. Surge então uma palavra-chave: incerteza.
Quando pensamos sobre incerteza, frequentemente a associamos ao azar, à chance de algo dar errado e a algo ruim que possa acontecer. Culturalmente, tendemos a falar de incertezas sobre o risco que representa em nossas escolhas. Então risco torna-se algo ruim, que deve ser evitado. Mas afinal, risco também não pode ser visto como a chance de dar certo?
Ao gerenciar projetos, é fato que a incerteza representa risco do projeto não acontecer. Naturalmente, pelo processo evolutivo, algumas ferramentas e técnicas foram criadas para evitar que algo ruim aconteça e leve um projeto ao insucesso. Entender e tratar adequadamente os riscos, visando minimizar impactos negativos nas operações das organizações é o principal objetivo do processo de Gerenciamento de Risco.
Para a identificação destes impactos, existem algumas metodologias de análises ou ferramentas de gerenciamento de risco e cada uma dessas ferramentas possui origens diferentes e se desenvolveram sob pontos de vistas, necessidades e percepções diferentes, por pessoas que pensam e sentem de forma diferente. A escolha de uma boa metodologia de análise de risco, adaptada às necessidades da organização, é um dos requisitos chaves para o sucesso deste processo.
As análises de risco são feitas, basicamente, sobre análises probabilísticas. Os primeiros estudos de registros surgiram no século XVII na Inglaterra. Estes estudos foram conduzidos por John Graunt, considerado o precursor da teoria da amostragem (SALLES JR. et al., 2006). No século XIX, com o nascimento da curva de Gauss ou curva normal, foi possível coletar
dados, estudar sua distribuição e projetar o futuro de forma sistemática, permitindo que possamos decidir se devemos ou não correr certo risco (SALLES JR, 2006).
O surgimento destas metodologias se deu, basicamente, com o aprofundamento dos estudos de probabilidade e estatística e com a necessidade do homem em preservar grandes investimentos, sejam eles de recursos financeiros, humanos, materiais ou qualquer outro recurso limitado de alguma forma, e principalmente, durante e após a 2ª Guerra Mundial, período da Guerra-Fria, tempos em que o inimigo era poderoso e os recursos escassos. Neste período, não havia tempo a perder, pois essa poderia ser a diferença entre a vitória e a derrota. Os contratempos em decorrência de incertezas tinham que ser minimizados ou, melhor, eliminados, quando possível. Os grandes projetos governamentais desse período foram a gêneses da gestão de risco. Algumas das metodologias, hoje empregadas na gestão de riscos, surgiram de adaptações e aperfeiçoamentos de metodologias desenvolvidas para projetos deste período.
Entretanto, não limitados aos projetos governamentais, algumas indústrias e setores da economia, utilizando-se do conceito de prevenção desenvolvido e disseminado no referido período, criaram metodologias próprias para a prevenção e mitigação dos efeitos dos eventos inesperados ou não previstos.
Alguns setores, mais recentemente, têm desenvolvido metodologias para aproveitamento de incertezas boas, as oportunidades, porém a grande maioria dos métodos foca nas incertezas ruins, os desvios nos processos ou ocorrências de eventos não esperados. Entenda-se por evento não esperado todo evento não projetado, determinado ou descrito para ocorrer a determinado tempo e em uma determinada etapa do processo/projeto.
Como existem inúmeros métodos para análise de riscos, este trabalho selecionou as metodologias que favorecem estas análises e suas correlações com prática de projetos. A familiaridade com as metodologias e a consolidação em seus setores de origem também foram levados em consideração para a escolha. Frente à necessidade de se compilar comparações entre elas em um só trabalho, uma vez que tal tema não é recorrente na literatura, este trabalho permitirá responder algumas questões levantadas na prática de Gestão de Riscos e Gestão de Projetos.
1.2. Objetivo
Considerando as metodologias HAZOP, FMEA, ISO 31000, PMBOK e Mercado Financeiro, este trabalho tem por objetivo endereçar as seguintes questões:
• Qual a aplicabilidade de cada metodologia?
• Quais as vantagens e desvantagens?
• Qual o favorecimento da análise de riscos para projetos?
• Qual a complexidade?
• Há correlação com práticas de projetos?
Para que seja possível responder estas questões, primeiramente, será feita a análise e o detalhamento das metodologias propostas para o estudo e, posteriormente, a respostas aos questionamentos propostos.
Estes são alguns dos objetivos que este trabalho pretende esclarecer, visando o auxilio das próximas turmas na compreensão da disciplina de gestão de risco e na ampliação da bibliografia disponível. Entendemos que é possível se aprofundar nestas análises, inclusive, com a proposição de uma nova metodologia que congregue os pontos fortes de cada uma delas e que seja alinhada com as boas práticas disseminadas pelo Project Management
Institute (PMI).
2. FUNDAMENTAÇÃO TEÓRICA
2.1. O que é projeto?
“Projeto é um esforço para se atingir um objetivo específico por meio de um conjunto único de tarefas inter-relacionadas e da utilização eficaz de recursos”
(GIDO e CLEMENTS, 2007, p. 4, apud DOMINGUES, 2008, p.13).
Segundo a definição do PMI (PMI, 2004, p. 21), “projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo”. O objetivo do projeto é alcançar e satisfazer os objetivos que os stakeholders aceitaram quando o projeto foi iniciado (HELDMAN, 2005, p. 3, apud DOMINGUES, 2008, p.13).
2.2. O que é gerenciamento de projetos?
“O Gerenciamento de Projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos.”
(PMBOK, 2004).
Em outras palavras, a gestão de projeto envolve primeiramente um planejamento, seguido da execução deste plano para se atingir o objetivo do projeto.
Os gerentes de projetos se deparam com a tripla restrição ao atendimento das necessidades dos stakeholders de seus projetos, onde o escopo, o custo e o tempo têm que ser balanceados e atendidos para que a qualidade não seja afetada. Estes fatores estão intimamente relacionados, sendo que se algum for alterado, pelo menos outro deverá também ser afetado.
2.3. O que é risco?
“O risco do projeto é um evento ou condição incerta que, se ocorrer, terá um efeito positivo ou negativo sobre pelo menos um objetivo do projeto, como tempo, custo, escopo ou qualidade...”
(PMBOK, 2004)
Risco é a incerteza da ocorrência de um evento não projetado, determinado ou descrito para ocorrer a determinado tempo e em uma determinada etapa do processo/projeto, seja esse evento conhecido ou não, podendo como conseqüência da sua ocorrência, gerar ganhos ou perdas ao processo/projeto.
2.4. O que é gerenciamento de riscos?
O gerenciamento de riscos trabalha com a identificação e controle de possíveis incertezas. Se quisermos ter um domínio sobre acontecimentos futuros, devemos prevê-los através da disponibilidade de informações:
• quando todas as informações são conhecidas, há a certeza absoluta. Se há plena ciência, isso não é classificado como risco e sim como um caso já conhecido;
• quando se detém informações parciais, há a incerteza e há um risco de ocorrer ou não;
• quando não há nenhuma informação disponível, temos a total incerteza, portanto, riscos estarão associados (SALLES JR., 2006, p. 24).
Referente ao conceito de risco em gerenciamento de projetos, o PMBOK o define como sendo “um evento ou condição incerta que, se ocorrer, terá um efeito positivo ou negativo sobre pelo menos um objetivo do projeto, como tempo, custo, escopo ou qualidade” (PMI, 2004, p. 8). Com isso, o PMBOK especifica que “o objetivo do gerenciamento de riscos do projeto é aumentar a probabilidade e o impacto dos eventos positivos e diminuir a probabilidade e o impacto dos eventos adversos ao projeto” (PMI, 2004, p. 237).
De nada adianta elaborar um plano de gerenciamento de riscos e não colocá-lo em prática, ou seja, deixá-lo arquivado. De maneira geral, a gerência de riscos é constituída de cinco etapas, as quais devem ser integralmente seguidas:
• identificar e documentar os riscos;
• analisar (qualitativamente e/ou quantitativamente) e estabelecer prioridades;
• elaborar um plano de ações (respostas aos riscos);
• monitorar e controlar este plano;
• realizar revisões do plano de maneira a assegurar que as mudanças ocorridas durante a execução do projeto sejam incorporadas.
2.5. O que é metodologia?
Metodologia é o estudo dos métodos ou então as etapas a seguir de um determinado processo (WIKIPEDIA, 28/03/2011).
No âmbito deste estudo a melhor definição é a de seguir as etapas de um processo, pois serão detalhadas ao longo do trabalho o passo-a-passo de cada uma das metodologias identificadas para o trabalho.
2.6. Por que é importante gerenciar riscos em projetos
De acordo com (SALLES JR, 2006, p 25), neste ambiente existe uma bela reflexão sobre o assunto:
“Eu não me preocupo com as coisas que sei que não sei, Eu só me preocupo com as coisas que não sei que não sei. Porque as coisas que sei que não sei, é fácil – é só procurar que vou saber. Porém, as coisas que não sei que não sei, não tenho nem por onde começar!”
(Einstein, circa 1940)
Em suma, a importância de se gerenciar os riscos do projeto propicia a preparação para a ocorrência das incertezas. Se for maléfica, será possível reduzir os seus efeitos e/ou a probabilidade de sua ocorrência; se for benéfica, poder-se-á otimizar os seus efeitos e/ou a probabilidade de ocorrência.
3. METODOLOGIA DE GERENCIAMENTO DE RISCO
3.1. HAZOP
Esta metodologia, segundo (WIKIPÉDIA, 2011), surgiu em 1963 na HEAVY ORGANIC
CHEMICAL DIVISION OF IMPERIAL CHEMICAL INDUSTRIES – ICI, (Divisão de
Química Orgânica Pesada da ICI, em tradução livre), à época, a maior indústria química britânica e uma das maiores do mundo. Neste período, no intuito de determinar melhorias no processo fabril, uma equipe de 3 pessoas se reunia 3 vezes por semana durante 4 meses para estudar o projeto de uma nova planta industrial de fenol. O grupo iniciou os estudos aplicando a técnica de “análise crítica” na busca por melhorias no projeto da nova planta, entretanto, com o desenvolvimento das atividades e com a maturidade desenvolvida, mudaram o foco para identificação e determinação de soluções para os possíveis “desvios” do projeto.
Posteriormente, após estas adaptações, o método foi redefinido pela ICI e adotou-se a nomenclatura “estudos de operacionalidade” e, em um terceiro momento, quando vislumbradas novas possibilidades para o estudo, introduziu ao método a “análise de perigo”, surgindo o HAZOP (Hazard and Operability Studies) ou, em tradução livre, estudo de perigos e operacionalidades.
De acordo com (REIS, 2008) a metodologia HAZOP é uma técnica de análise qualitativa desenvolvida com o intuito de examinar as linhas de processo, identificando perigos e prevenindo problemas. Esta metodologia é baseada em um procedimento que gera perguntas de maneira estruturada e sistemática através do uso apropriado de um conjunto de palavras-chave aplicadas a pontos críticos do sistema em estudo.
Ainda de acordo com o (KLETZ, 2006), HAZOP é um estudo estruturado e sistemático de processos em planejamento, existentes ou em operação, no intuito de identificar e avaliar problemas que podem representar riscos às pessoas, equipamentos e/ou a eficiência da operação.
Esta técnica é amplamente empregada na indústria, principalmente, na indústria química, onde se originou, porém devido a sua simplicidade e eficácia na identificação dos riscos, pode ser aplicada em outros setores da economia. Além disso, com adaptação, pode ser aplicada à gestão de projetos nas áreas de conhecimentos do PMBOK.
Segundo (SMITH, 2006), em tradução livre, as três questões básicas do HAZOP, são: “O que poderia sair errado?” (What could go wrong?);
“Como poderíamos saber disso?” (How would we know it?);
“O que poderíamos fazer com relação a isso?” (What could we do about it?)
O estudo de perigo e operacionalidade (HAZOP) se propõe a responder estas questões, pois a análise é feita com base em informações específicas levantadas pelos participantes do projeto no grupo de estudo formado para a aplicação da técnica. Esta etapa será detalhada em tópico específico posteriormente.
3.1.1 Aplicação da metodologia HAZOP
O HAZOP se aplica tanto a processos existentes quanto a novos, independentemente do tamanho. Conforme (ALBERTON, 1996) “O método HAZOP é principalmente indicado quando da implantação de novos processos na fase de projeto ou na modificação de processos já existentes. Vale ressaltar que o HAZOP é conveniente para projetos e modificações tanto grandes quanto pequenos.” Inicialmente desenvolvido para a análise dos sistemas de processos químicos, foi posteriormente estendido a outros tipos de sistemas e também para operações mais complexas e de sistemas de software. (WIKIPEDIA, 2011)
Em suma, sempre que se desejar identificar e se precaver de desvios em processos já consolidados ou não, pode-se utilizar o HAZOP.
Devido às limitações bibliográficas, este trabalho foca o desenvolvimento da metodologia na sua área de criação, a indústria química. A bibliografia disponível em português sobre o tema é muito limitada e as fontes em língua inglesa, em sua maioria, são focadas na indústria química e/ou petroquímica.
Primeiramente, forma-se o grupo que analisará os possíveis desvios do processo. Segundo (KLETZ, 2006), HAZOP é uma metodologia desenvolvida em grupo. Para um novo projeto, a equipe usual na indústria química é formada por:
Engenheiro de Projeto ou Projetista:
• Normalmente um engenheiro mecânico e, na fase inicial do projeto, o responsável por manter o orçamento. O engenheiro de projeto deseja minimizar as alterações, mas, ao mesmo tempo, descobrir o quanto antes se há algum perigo ou problema operacional desconhecido.
Engenheiro de Processo
• Normalmente o engenheiro químico que desenvolveu o fluxograma.
Gerente de Comissionamento
• Normalmente um engenheiro químico que terá que iniciar e operar a planta e, portanto, tenderá a pressionar por toda mudança que facilitará sua atividade.
Engenheiro projetista do sistema de controle
• As modernas instalações industriais possuem sofisticados sistemas de controle, monitoramento e automação. O resultado da análise HAZOP, em muitos casos, resulta na adição desses sistemas.
Químico de Pesquisa
• Fará parte da equipe se o desenvolvimento de um novo produto químico estiver envolvido.
• Um especialista na técnica “HAZOP” e não na instalação industrial. Seu trabalho é garantir que a equipe siga o procedimento.
Por se tratar de uma metodologia que tem como definição identificar os perigos dos processos, caso o líder não tenha um bom nível de conhecimento sobre a segurança do trabalho e não haja nenhuma outra pessoa com esse conhecimento, é necessária a presença de um representante com essas características na equipe.
Como percebido, os interesses de cada um dos membros da equipe são diferentes e, conseqüentemente, haverá discussões. Uma das funções do líder é tentar balancear as discussões, corrigindo as distorções.
“In industry the optimal level of conflit is not zero”, isto é, “Na indústria, o nível ótimo de conflito (discussão) não é zero”.
(KLETZ, 2006 apud SIR JOHN HARVEY-JONES)
Ainda, segundo (KLETZ, 2006), caso não haja consenso, o líder deverá considerar o ponto fora de questão - entretanto, na maior parte das vezes a questão é solucionada com a presença de um especialista.
Para uma planta industrial já existente, a equipe deve ser formada por pessoas com experiência na referida planta, normalmente formada por:
Gerente de Operações
• Pessoa responsável pela operação da planta.
Encarregado de Operações
• Pessoa que realmente sabe o que acontece e não o que se supõe que era para acontecer.
Engenheiro de manutenção
• Responsável pela manutenção mecânica, o engenheiro de manutenção sabe muitas das falhas que ocorrem.
• Responsável pela manutenção dos instrumentos de controle, bem como, pela instalação de novos instrumentos.
Gerente de análise de falhas
• Responsável pela investigação técnica dos problemas e por transferir os resultados de laboratório para a escala industrial.
Líder de equipe independente
• Um especialista na técnica “HAZOP” e não na instalação industrial. Seu trabalho é garantir que a equipe siga o procedimento.
(KLETZ, 2006), adverte para o tamanho da equipe. A equipe deve ter uma combinação como a descrita acima, mas não deve ser muito grande, uma vez que isso pode atrapalhar o progresso das atividades. Seis ou sete pessoas são geralmente suficientes.
Vale observar que em ambos os casos, tanto na implantação de uma nova planta industrial como na ampliação de uma já existente, a equipe deve contar ainda com um redator que auxiliará o líder da equipe nos registros das decisões tomadas nas reuniões.
Com relação ao tamanho da equipe, recomenda-se uma equipe mínima de 5 membros e detalha que para a execução do método HAZOP deve-se formar um grupo de estudo multidisciplinar que avaliará os possíveis desvios dos processos do projeto. Quando o projeto for muito complexo ou muito grande, recomenda-se a formação de vários grupos menores, entre 5 a 8 membros cada, sendo que o líder do estudo e o redator deverão ser os mesmos em todos os grupos. A manutenção do líder e do redator em todos os grupos auxilia na compatibilização das soluções dos diversos estudos e no monitoramento das soluções propostas.
Uma vez definido o grupo, este analisará os componentes do sistema em pequenas seções e, separadamente, os equipamentos e demais componentes promovendo os possíveis desvios. A comparação dos parâmetros determinados nos projetos com os parâmetros gerados pelos desvios identificados determina o impacto do desvio no processo e, com a identificação das causas e das conseqüências para os possíveis desvios analisados, pode-se determinar as ações a serem tomadas pelo grupo.
Posteriormente, para auxiliar na análise, o grupo utiliza uma combinação de palavras-chave com os parâmetros de projeto em estudo. Com isso, têm-se os desvios possíveis para os diversos parâmetros, sendo para (KLETZ, 2006) as palavras-chave apresentadas nas tabelas abaixo:
Tabela 1 Palavras-chave da análise HAZOP e respectivos desvios
Fonte: HAZOP and Hazan 4ª Edição, KLETZ, T. (2006)
Palavra-chave Significado
NÃO Negação completa da intenção do projeto
MAIS Aumento quantitativo
MENOS Diminuição quantitativa
PARTE Modificação qualitativa / redução
ALÉM Substituição completa
Outros autores acrescentam ao rol de palavras-chave às listadas abaixo:
Tabela 2 Palavras-chave da análise HAZOP e respectivos desvios
Fonte: WIKIPEDIA, 2011
Palavra-chave Significado
BEM COMO Modificação qualitativa / aumento REVERSO Oposto lógico da intenção do projeto PRECOCE Relativo ao tempo do relógio
TARDIO Relativo ao tempo do relógio ANTES Relativo à ordem ou seqüência
Para determinar se uma solução deve ou não ser registrada e avaliada, devem-se considerar alguns critérios de exeqüibilidade, sendo que (KLETZ, 2006) define algumas perguntas que auxiliam nesta determinação:
Tabela 3 Critérios de exeqüibilidade sugeridos
Fonte: Adaptação Table 2.4 HAZOP and Hazan 4ª Edição, KLETZ, T. (2006)
Alguns fatores a serem considerados na escolha de uma solução para registro dos resultados do HAZOP.
É de fácil utilização? Qual o grau de treinamento requerido? É bem comprovado?
Quais são os custos iniciais e os de implantação? Qual a viabilidade e a qualidade do suporte? Atualizações são viáveis?
É compatível com outros programas? (inclusive e-mail e internet) Quais outros estudos são considerados?
Pode ser personalizado?
Como são monitoradas as ações e as mudanças?
Pode ser integrado com o arquivo histórico de acidentes?
É possível realizar uma pesquisa nos relatórios por palavras especificas? Existe um mecanismo de verificação ortográfica?
Após a formação do grupo, as palavras-chave que formarão os desvios a serem estudados e as perguntas de exeqüibilidades que auxiliarão na aceitabilidade ou não da solução proposta, apresenta-se a seguir o fluxograma da análise dos desvios identificados no sistema.
Figura 1 Fluxograma de análise de desvio
Fonte: Adaptação Figure 2.1 HAZOP and Hazan 4ª Edição, (KLETZ, 2006)
Como observado acima, este fluxograma é genérico e serve para a análise de todos os possíveis desvios identificados pelo grupo de estudo. O resultado de cada análise é registrado pelo redator, inclusive as responsabilidades de cada setor. O acompanhamento será feito pelo líder, que será o responsável por monitorar a implantação das soluções propostas.
3.1.3 Exemplo de formulário HAZOP
O formulário abaixo exemplifica como a metodologia HAZOP pode ser aplicada:
Título de Estudo: N.º Projeto:
Elaborado por: Folha
Equipe de estudo: Linha do Diagrama:
Data: N.º de ref. Desvio Operacional (Palavra-Chave) Notas de ações e consultas Responsável Acompanhamento e Comentários de Revisão
Figura 2 Formulário de registro da análise HAZOP Fonte: HAZOP and Hazan 4ª Edição, (KLETZ, 2006)
O campo “título de estudo” é o local destinado ao título que identificará o estudo HAZOP realizado.
O campo “n.º do projeto” é o local destinado ao código do projeto em estudo, utilizado para equipes.
O campo “elaborador por” destina-se a inclusão do redator responsável pelo preenchimento do formulário.
O campo “folha” destina-se à identificação da numeração da página do formulário da análise da respectiva “linha do diagrama”.
O campo “equipe de estudo” destina-se a relacionar os participantes do grupo de estudos HAZOP, inclusive com a identificação do cargo que ocupava no momento do estudo.
O campo “linha do diagrama” destina-se a identificar a seção ou o equipamento ou o componente a que se refere o estudo.
O campo “data” é destinado à informação da data em que o estudo HAZOP foi realizado. A coluna “n.º de referência” é a ordenação das análises, isto é, a numeração que identifica o desvio estudado ou na seção ou no equipamento ou no componente.
A coluna “desvio operacional” identifica o desvio analisado para aquela etapa.
A coluna “notas de ações e consultas” é o local onde se relaciona as ações definidas a serem tomadas para tratar o desvio identificado para aquela etapa do processo (“n.º de referência”). A coluna “responsável” identifica o responsável por implementar as ações propostas na coluna “notas de ações e consultas”.
A coluna “acompanhamento e comentários de revisão” é o local que se destina a anotações sobre o status de implementação das ações e as revisões das ações propostas.
3.2. FMEA
Em 1949, o exército americano criou um processo formal denominado “Procedures for
Performing a Failure Mode, Effects and Criticality Analysis” (Procedimentos para
desenvolver uma análise de modo, efeitos e criticidade de falhas), que mais tarde foi denominado FMEA (Failure Mode and Effects Analysis, ou Análise de Modo e Efeito de Falhas). A NASA, por volta dos anos 60, desenvolveu esta técnica para o programa Apollo, com o objetivo de eliminar falhas em equipamentos que não teriam como ser reparados após o lançamento. Em 1972 a Ford introduziu seu uso (FMEA de Processo) na indústria automobilística, difundindo-o na indústria por meio da Norma Q 101 (RAMOS, 2006, p.71).
O principal objetivo do FMEA é evitar que problemas cheguem até o consumidor final do produto, sistema, processo ou serviço. Por isso, FMEA provê um método sistemático para examinar todos os modos que uma falha pode ocorrer (STAMATIS, 2003, p. 22, apud DOMINGUES, 2008, p.32). Neste sentido, (RAMOS, 2006, p.71) explica que “a técnica de FMEA foi criada com enfoque no projeto de novos produtos e processos, mas devido a sua grande utilidade, passou a ser aplicada de diferentes formas e em diferentes tipos de organizações”. O FMEA pode ser descrito como uma metodologia sistemática que deve ser aplicada por grupos multidisciplinares, para aumentar, com a agregação e sinergia dos conhecimentos das pessoas envolvidas, o grau de percepção, de análise e de solução das falhas e defeitos (TOLEDO, 2002, apud VIEIRA, 2008).
O FMEA surgiu da combinação de cinco técnicas: Kaizen, Brainstorming, Regra de Pareto, Análise de Causa Raiz e Mapeamento de Processo (DAILEY, 2004, p. 6 apud DOMINGUES, 2008, p. 32) e seu uso é requerido pelas normas QS9000, ISO TS 16949, EAQF94, VDA 6.1, AVSQ para projetos e processos de fabricação. O FMEA é atualmente utilizado por indústrias de diferentes ramos como química, automotiva, alimentícia.
Conforme o QS9000, FMEA é:
1- Um conjunto de atividades com intuito de identificar e avaliar as falhas potenciais do produto/processo e os efeitos destas falhas;
2- Identificar ações que poderiam eliminar ou reduzir a chance da falha potencial ocorrer; 3-Documentar o processo.
Em resumo, o FMEA procura listar todas as possíveis falhas (de produto ou do Processo) e suas causas para que sejam analisadas e tomadas as ações preventivas necessárias. A maior vantagem da utilização do FMEA é a de evidenciar qual é o ponto mais crítico do projeto, com vistas à tomada de ações preventivas para minimizar o impacto dos riscos para cada área de conhecimento do PMBOK: integração, escopo, custos, tempo, qualidade, recursos humanos e comunicação.
Tipos de FMEA
FMEA de projeto (dFMEA - design failure modes and effects analysis): na qual são
consideradas as falhas que poderão ocorrer com o produto dentro das especificações do projeto. O objetivo desta análise é evitar falhas no produto ou no processo decorrente do projeto. É comumente denominada também de FMEA de produto.
FMEA de processo (pFMEA - process failure mode and effect analysis): são consideradas
as falhas no planejamento e execução do processo, ou seja, o objetivo desta análise é evitar falhas do processo, tendo como base as não conformidades do produto com as especificações do projeto.
O fundamento da metodologia de FMEA é o mesmo, seja para produto ou processo, sistema ou procedimento, para produtos novos ou em operação. O FMEA pode ser personalizado, considerando-se atributos exclusivos de cada projeto.
Aplicação e elementos básicos da FMEA
A utilização da técnica de FMEA deve ocorrer na melhoria da qualidade dos produtos e processos, desenvolvimento de novo produto ou processo, para reduzir as falhas potenciais de produtos e processos que já estão em operação e ainda, redução da ocorrência de não conformidades em processos administrativos.
Passos para execução do FMEA: Esta metodologia avalia as possíveis formas que o produto
ou processo podem falhar de maneira lógica e sistemática. O modo como as falhas podem ocorrer são avaliados com base em 3 quesitos: ocorrência, gravidade e detecção. Abaixo, seguem os passos para a execução do FMEA.
• Equipe: a equipe de execução do FMEA deve ter conhecimento de como funciona o método, deve identificar quais as implicações das falhas do item considerado. As equipes de trabalho devem ser formadas durante o planejamento do FMEA, devem ser multidisciplinares e com integrantes de diversas áreas.
• Determinação dos itens: a equipe deverá identificar as etapas/itens com maior número de falhas, quais as etapas críticas do processo;
• Definir um formulário padrão do FMEA: o formulário FMEA pode ser adequado considerando atributos exclusivos de cada projeto ou empresa;
• Coleta de informações: para que o preenchimento do formulário seja o mais real possível, deve-se obter o máximo de dados possíveis. FMEA’s realizados anteriormente, registros internos de falhas e demais documentações podem ser utilizados para contribuir com a identificação das falhas;
• Preenchimento do formulário FMEA: as informações registradas deverão ser claras e concisas para facilitar a avaliação e entendimento dos envolvidos;
• Identificação dos tipos de falhas: para auxiliar esta etapa e agrupar as possíveis falhas, pode-se utilizar o diagrama de Ishikawa (“espinha de peixe”);
• Identificação de seus efeitos: Descrição dos efeitos a partir de cada falha ocorrida;
• Identificação das causas das falhas: as falhas anteriores, projetos e produtos similares podem auxiliar na identificação;
• Análise das falhas para determinação de índices: para cada falha determina-se um índice de ocorrência, gravidade e detecção.
Na avaliação do índice de ocorrência (Tabela 04), são examinados históricos de manutenção, dados do fornecedor, relatórios de falhas, entre outros.
Tabela 4 Índice de ocorrência
Fonte: Adaptada de (Helman e Andery, 1995 apud BARASUOL)
ÍNDICE DE OCORRÊNCIA (O)
Índice
Probabilidade de
1 Remota Excepcional
2 Muito pequena Muito poucas vezes
3 Pequena Poucas vezes
4-6 Moderada Ocasional
7-8 Alta Freqüente
9-10 Muito alta Inevitável
O índice de gravidade ou índice de severidade (Tabela 05) - é analisado o grau de insatisfação que poderá trazer ao cliente.
Tabela 5 Índice de severidade
Fonte: Adaptada de (Helman e Andery, 1995 apud BARASUOL).
Índice Conceito
1 Falha de menor ocorrência e quase não são
percebidos os efeitos sobre o produto ou processo.
2-3 Produto: redução de desempenho.
Processo: perda gradual de eficiência.
4-6 Produto: degradação progressiva.
Processo: ineficiência, baixa produtividade.
7-8 Produto: não desempenha sua função.
Processo: quase não se consegue manter a produção, baixa eficiência e produtividade. Alta taxa de refugo.
9-10 Produto: não desempenha sua função.
Processo: quase não se consegue manter a
produção, baixa eficiência e produtividade. Alta taxa de refugo.
9-10 Processo: não se consegue produzir, colapso. Produto: problemas catastróficos, pode ocasionar danos a bens ou pessoas.
A probabilidade de a falha ser detectada antes de acontecer denomina-se índice de detecção (Tabela 06).
Tabela 6 Índice de detecção
Fonte: Adaptada de (Helman e Andery, 1995 apud BARASUOL).
Índice Probabilidade de detecção
1 Muito alta
2-3 Alta (cerca de 90% das vezes)
4-6 Moderada (cerca de 50% das vezes)
7-8 Pequena
9-10 Muito pequena
9 Remota (a falha não pode ser detectada)
• Hierarquização das causas: determinar o RPN (Risk Priority Number) ou NPR: para tal, multiplicam-se entre si os índices de ocorrência, gravidade e detecção. A causa que tiver o maior RPN deve ser atacada primeiramente, e assim por diante.
Tabela 7 Escala de N.P.R ou RPN (IQA, 2001)
N.P.R. Critério de priorização para tomada de ação Alto Prioridade zero. Item vulnerável e importante.
(acima de 100) Requer ações preventivas.
Médio (de 50 a 100)
Prioridade um. Item vulnerável. Requer ações preventivas ou corretivas.
Baixo (de 1 a 50)
Prioridade dois. Item pouco vulnerável. Podem ser tomadas ações preventivas ou corretivas.
• Resposta aos riscos: Deve-se elaborar um plano de ação para cada falha, atacando primeiramente as falhas com maior risco e estabelecer respectivas ações para preveni-las. O plano de ação visará reduzir a probabilidade de ocorrência da falha, reduzir a sua gravidade e aumentar a probabilidade de detecção.
Ainda, as ações podem envolver diferentes estratégias para se lidar com os riscos, como:
• Aceitar o risco da falha, dependendo do seu impacto x custo de prevenção.
• Tomar medidas para prevenção total da falha.
• Tomar medidas para redução da ocorrência falha ou da causa da falha.
• Tomar medidas para aumentar a probabilidade de detecção da falha.
• Tomar medidas para reduzir o efeito da falha.
Exemplos de formulário FMEA
A “função” - Expressam o que o projeto, processo ou serviço deve fazer para satisfazer o cliente.
Um “modo de falha” é a maneira pela qual um processo pode falhar potencialmente em atender aos requisitos de produto ou processo descrito na coluna função.
Os “Efeitos da falha” é a descrição das conseqüências do modo de falha, isto é, o que o cliente sofre quando o modo de falha, definido no elemento anterior, ocorre.
As “Causas da falha” - são as deficiências do projeto que podem resultar no modo de falha em questão e devem ser listadas de forma a permitir ações preventivas para cada uma delas. A “Severidade ou Gravidade” é o grau de seriedade/importância de cada efeito da falha potencial. A severidade é normalmente medida em uma escala de 1 a 10. O número 1 indica que o efeito não é sério aos olhos do cliente ou que o cliente talvez nem perceba o efeito. O número 10 reflete os piores efeitos e conseqüências resultantes do modo de falha. As definições correspondentes aos números na escala de severidade que aparecem na Tabela 05 servem como um guia para o desenvolvimento de uma escala específica à organização. A “Ocorrência” é a probabilidade de ocorrência da causa da falha potencial. A ocorrência é a freqüência com que o modo de falha ocorre durante o ciclo de vida do projeto. A ocorrência é estimada através de uma escala de 1 a 10. O número 1 indica uma chance remota do modo de falha ocorrer. O número 10 reflete a ocorrência certa do modo de falha. As definições que aparecem na Figura 3 servem como um guia para o desenvolvimento de uma escala específica à organização. Uma redução no índice de ocorrência somente ocorre quando uma ou mais das causas do modo de falha são removidas ou controladas.
A “Detecção” é a probabilidade de a causa da falha potencial ser identificada antes de a falha chegar ao cliente. A detecção é a estimativa da probabilidade de se detectar o modo de falha ou a causa, no ponto previsto e com a precisão e exatidão necessária, baseando-se nas formas de controle previstas.
A detecção é estimada através de uma escala de 1 a 10. O número 1 sugere que esse modo de falha ou suas causas certamente serão detectados antes de chegarem ao cliente. O número 10 sugere que a forma mais provável de a organização tomar conhecimento do problema ocorre com a reclamação do cliente.
A escala de detecção que aparece na Tabela 06 serve como um guia e deve ser ajustada, a fim de se adequar a cada organização.
Para alcançar um índice de detecção menor, o planejamento do controle do projeto tem de ser melhorado.
NPR = Severidade x Ocorrência x Detecção
É o produto dos índices de severidade, ocorrência e detecção, conforme a fórmula (IQA, 2001): ecção ocorrência severidade N N N NPR= * * det Onde:
NPR Número de prioridade do risco;
severidade
N Índice de severidade do modo de falha;
ocorrência
N Índice de ocorrência do modo de falha;
ecção
Ndet Índice de detecção do modo de falha ou causa.
Dentro do escopo da FMEA este valor ficará entre 1 e 1000 e poderá ser usado para priorizar as deficiências do projeto.
Uma sugestão de tabela de prioridade é apresentada na tabela 07.
“Ações Recomendadas” são as ações recomendadas para evitar a ocorrência da falha antes da
concepção do produto/processo. Todas as ações recomendadas devem ser implementadas ou adequadamente abordadas.
Esta é uma das principais colunas do FMEA é deve ser preenchida para assegurar que serão tomadas ações para evitar a ocorrência da falha potencial. Esta coluna indica que houve realmente análise sobre os riscos identificados.
Responsável e Prazo
É a pessoa, equipe ou organização que executará a ação recomendada no elemento anterior dentro do prazo estabelecido pela equipe do projeto.
Resultados da Ação
É uma breve descrição da ação realizada, com a data de sua efetivação e com os novos índices resultantes (severidade, ocorrência e detecção).
Controles Atuais
Os controles são as formas de prevenção e detecção de cada modo de falha, estes são estrategicamente colocados no processo de desenvolvimento do projeto, a fim de detectar possíveis problemas que foram previstos pela equipe e impedir que estes evoluam para as fases subseqüentes.
Utilização da FMEA para Gestão de Riscos em Projetos
O FMEA pode ser aplicado para cada área de conhecimento do PMBOK, com o objetivo de se evitar que algum problema em alguma das áreas passe despercebido. As áreas de conhecimento devem ser informadas na coluna das funções no formulário de FMEA, sendo, desta forma, a base para identificação dos modos de falhas, efeitos e causas.
Uma desvantagem do FMEA para o gerenciamento de riscos é que ele foi concebido para encontrar problemas potenciais no projeto, sistema ou processo, o que acaba excluindo seu uso como ferramenta para análise de riscos positivos.
Após o início de sua aplicação, o FMEA deverá ser atualizado e revisto sempre que necessário, pois novas falhas passam a ser conhecidas e previstas (devido às alterações de critério de qualidade por parte dos clientes, alterações de fornecedores e propostas vindas através de serviços de atendimento ao cliente).
FMEA possui um enfoque genérico, o que lhe permite cobrir as mais diversas áreas e situações. O FMEA é um formulário que pode – e deve – ser personalizado para cada situação, projeto ou empresa. É composto por tabela e índices de classificação sucintos e objetivos, o que o caracteriza como uma técnica simples, eficiente, de fácil compreensão e implantação.
Alguns autores sugerem que para a utilização de FMEA na gestão de riscos em projetos, faz-se necessário registrar no formulário FMEA: a estratégia de resposta ao risco, responsável / prazo implementação, status da execução das ações recomendadas a cada revisão da FMEA.
3.3. ISO 31000
Dois mil e nove foi o ano da padronização na área da gestão de riscos, tanto no mundo como no Brasil. Uma empreitada que começou em 2005, em Tókio, no Japão, culminou em 2009 com o lançamento da ISO 31000. A primeira norma internacional da história sobre Gestão de Riscos ISO 31000:2009 - Risk management - principles and guidelines (Gestão de riscos - princípios e diretrizes), um documento de apenas 24 páginas, podendo ser adotado por organizações de todos os tipos e tamanhos, e de qualquer setor de atividade (indústrias, instituições financeiras, órgãos públicos, hospitais, etc).
O texto original da ISO 31000 foi baseado na norma AS/NZS 4360:2004. O desenvolvimento da norma internacional foi feito por um comitê especial composto por delegações de 35 países que se uniram para criar um grupo de trabalho único denominado ISO Technical Management
Board on Risk Management. No Brasil, a ABNT (Associação Brasileira de Normas Técnicas)
criou a Comissão de Estudo Especial de Gestão de Riscos (CEE 63), com mais de 100 empresas e entidades de diferentes setores, com o intuito de discutir e definir a norma.
A ISO 31000 surgiu da necessidade de harmonizar padrões, regulamentações e frameworks já publicados que estavam relacionados com a gestão de riscos. A origem da norma vem da necessidade das corporações de lidar com as incertezas que podem afetar os seus objetivos, suas iniciativas estratégicas, suas atividades operacionais, seus processos ou seus projetos. Por isso, a norma pode ser aplicada aos vários tipos de riscos de diferentes setores da organização, tais como financeiro e de projetos, saúde, entre outros, incluindo a visão moderna de que risco também é oportunidade.
A proposta de convergência está alinhada com a visão integrada de ERM – Enterprise Risk
Management. Portanto, por se tratar de uma norma de alto nível, não há concorrência com as
normas já existentes, pois a ISO 31000 fornece orientações e alinhamento com outras normas específicas.
A ISO 31000 surge também para integrar as diversas metodologias e terminologias, pois faltava um consenso em relação à terminologia e aos conceitos utilizados para a gestão de riscos. O resultado mais comum dessa equação é que a gestão de riscos acaba sendo tratada de forma isolada, fazendo com que vários gestores (saúde, meio ambiente, segurança de TI, jurídico, financeiro, seguros, entre outros) trabalhem em ilhas departamentais, o que ocasiona a utilização de terminologias, sistemas, critérios e conceitos diferentes para cada uma das
áreas da empresa. Ou seja, cada departamento não possui o denominado “impacto cruzado”, pois não enxerga o impacto do risco que está estudando em outras áreas ou processos. A ISO 31000 possui um processo consistente e uma estrutura abrangente para ajudar a assegurar um gerenciamento de risco de forma eficaz, eficiente e coerente. Por esta razão, a abordagem é genérica fornecendo os princípios e diretrizes para gerenciar qualquer forma de risco de uma maneira sistemática, transparente e confiável, dentro de um escopo e contexto definido pela organização.
Segundo estipula a própria ISO 31000, ela é destinada ao seguinte público alvo:
a) responsáveis pelo desenvolvimento da política de gestão de riscos no âmbito de suas organizações;
b) responsáveis por assegurar que os riscos são eficazmente gerenciados em toda a organização ou em uma área, atividade ou projeto específico;
c) aqueles que precisam avaliar a eficácia de uma organização em gerenciar riscos;
d) desenvolvedores de normas, guias, procedimentos e códigos de práticas que, no todo ou em parte, estabelecem como o risco deve ser gerenciado dentro do contexto específico desses documentos.
A gestão de riscos já faz parte das práticas e processos de gestão de muitas organizações, embora não de maneira plena. Não é preciso que exista um centro de excelência corporativa em Gestão de Riscos na empresa, para que se faça uma análise crítica das práticas e processos existentes. Uma distinção interessante que a norma faz é entre os termos “gerência de riscos” e “gerenciamento de riscos”. A “gerência de riscos” trata da arquitetura (princípios,
framework e processos) para o gerenciamento dos riscos, enquanto que o “gerenciamento de
riscos” se refere à aplicação dessa arquitetura para tratar riscos particulares. A norma possui o seguinte índice de conteúdo (ISO 31000, 2009):
Introdução
1. Escopo
3. Princípios
4. Estrutura (Framework) 5. Processos
6. Anexos: Atributos da gestão de riscos avançada
3.3.1 Escopo
A ISO 31000 estabelece os princípios e orientações genéricas sobre a gestão de risco, podendo ser utilizada por qualquer empresa pública, privada, associação, grupo ou indivíduo. Assim, esta norma não é específica para alguma indústria ou setor, podendo ser aplicada em toda a organização e em um vasto leque de necessidades, incluindo as estratégias e decisões de operações, processos, funções, projetos, produtos e serviços. A norma pode ser aplicada a qualquer tipo de risco, seja qual for a sua natureza, mesmo de consequências positivas ou negativas. Ela foi criada com o objetivo de harmonizar os processos de gestão de risco nas normas existentes e futuras. A ideia é que a norma ofereça uma abordagem comum de apoio às normas existentes que tratam de riscos específicos para alguns setores, porém não para substituí-las, mas sim para suportá-las. Finalmente, também está definido no escopo que essa norma não se destina para fins de certificação.
3.3.2 Termos e definições
A norma ISO 31000 não tinha por objetivo padronizar as terminologias de gestão de riscos, pois já existia uma norma anterior, denominada ISO Guide 73, que criou uma linguagem comum, definindo vocabulário, terminologia e conceitos genéricos que se aplicam a todas as áreas e setores no gerenciamento de riscos. No Brasil, ambas as normas foram traduzidas e publicadas pela ABNT em 30 de novembro de 2009, como normas brasileiras: ABNT NBR ISO 31000 (contendo 24 páginas) e ABNT ISO Guia 73 (contendo 12 páginas).
Outra norma relacionada à ISO 31000 é a norma ISO/IEC 31010:2009 “Risk management –
Risk assessment techniques” ou, em português, Gestão de riscos – Técnicas de avaliação de
riscos, que entrou oficialmente em vigor no dia 1º de dezembro de 2009. Essa norma ISO 31010 não se destina nem à certificação nem a usos regulatórios ou contratuais, mas fornece orientação detalhada sobre a seleção e aplicação de técnicas sistemáticas qualitativas e quantitativas de avaliação de riscos.
3.3.3 Princípios
A ISO estabelece una lista de 11 princípios que devem ser compreendidos e difundidos por toda a organização, como forma de suportar um gerenciamento de risco eficaz na empresa. 1. A gestão de riscos cria e protege valor.
• A gestão de riscos contribui para a realização dos objetivos e melhoria do desempenho, por exemplo, saúde e segurança humana, segurança, conformidade legal e regulamentar, proteção ambiental, qualidade do produto, gerenciamento de projetos, eficiência nas operações, governança e reputação.
2. A gestão de riscos é parte integrante de todos os processos organizacionais.
• A gestão de riscos não é uma atividade autônoma, separada das principais atividades e processos da organização. A gestão de riscos é parte integrante de todos os processos organizacionais, incluindo planejamento estratégico e todos os processos de gestão da mudança.
3. A gestão de riscos é parte do processo decisório.
• A gestão de riscos ajuda no processo de tomada de decisões, uma vez que as decisões serão tomadas com base nas melhores informações disponíveis, tendo maior chance de sucesso ou fracasso na priorização das ações e alternativas. 4. A gestão dos riscos aborda explicitamente a incerteza.
• A gestão de riscos tem em conta explicitamente a incerteza e como ela pode ser abordada para minimizar prejuízos ou maximizar os lucros.
5. A gestão de riscos é sistemática, estruturada e oportuna.
• Uma abordagem sistemática, oportuna e estruturada de gestão de riscos contribui para a eficiência e resultados confiáveis.
6. A gestão de riscos é baseada na melhor informação disponível.
• As entradas para o processo de gerenciamento de risco são baseadas em fontes de informação, tais como dados históricos, experiências, observações dos envolvidos,
previsão e julgamento de especialistas. No entanto, os tomadores de decisão devem levar em consideração eventuais limitações dos dados ou da modelagem utilizada, uma vez que existe a possibilidade de divergência entre as informações previstas e o que irá realmente ocorrer.
7. A gestão de risco é alinhada com o perfil da empresa.
• A gestão de riscos está alinhada com o contexto externo e interno da organização, além do perfil de risco (moderado ou arriscado).
8. A gestão de riscos leva os fatores humanos e culturais em consideração.
• A gestão de riscos deve identificar capacidades, percepções e intenções das pessoas internas ou externas à organização que podem facilitar ou dificultar a realização dos objetivos planejados.
9. A gestão de riscos deve ser transparente e inclusiva.
• O adequado envolvimento e a participação dos responsáveis por tomarem decisões na organização garantem que a gestão de risco é pertinente e adequada. Responsáveis por processos críticos também devem ser envolvidos para que a sua opinião seja levada em consideração na identificação e tratamento dos riscos. 10. A gestão de riscos é dinâmica, interativa e receptiva às mudanças.
• Como eventos externos e internos podem ocorrer, ocasionando a mudança do contexto, deve haver uma revisão sistemática da gestão dos riscos para acompanhar e detectar essas mudanças.
11. A gestão de riscos facilita a melhoria contínua da organização.
• As organizações devem desenvolver estratégias para melhorar a sua maturidade em gerenciamento de riscos junto com todos os outros processos da organização.
3.3.4 Estrutura (framework)
O sucesso da gestão de riscos depende de como irão incorporá-la através de toda a organização, em todos os níveis. O framework descreve os componentes necessários para gerenciar riscos e as formas como eles se relacionam.
A figura a seguir ilustrar os componentes do framework de gestão de riscos a ser adotado pela organização:
• Mandato e comprometimento;
• Concepção da estrutura para gerenciar riscos;
• Implementação da gestão de riscos;
• Monitoramento e análise crítica;
• Melhoria contínua da estrutura.
Figura 4 Componentes do framework
De acordo com a ISO, o framework não se destina a especificar um sistema de gestão, mas sim a ajudar as organizações a integrar a gestão de risco em seu sistema de gestão global. Portanto, as organizações devem adaptar os componentes do framework às suas necessidades específicas para que as práticas de gestão da organização e os processos existentes incluam os componentes de gestão de risco para determinados riscos ou situações.
3.3.4.2 Mandato (pela diretoria) e comprometimento (pelos demais níveis)
A introdução da gestão de riscos na organização e o suporte à sua eficácia exigem forte comprometimento da alta administração, bem como o planejamento estratégico e rigoroso para atingir o empenho de todos os níveis organizacionais.
A administração deve:
• definir e aprovar a política de gestão de risco;
• garantir que a cultura da organização e a política de gestão de risco estejam de acordo;
• determinar indicadores de desempenho da gestão de riscos que se alinham com os indicadores de desempenho da organização;
• alinhar os objetivos de gestão de riscos com os objetivos e estratégias da organização;
• assegurar a conformidade legal;
• atribuir responsabilidades em níveis apropriados para os departamentos da organização;
• garantir que os recursos necessários estejam alocados à gestão de riscos;
• comunicar os benefícios da gestão de riscos a todos os interessados;
• garantir que a gestão de riscos continua a ser apropriada.
3.3.4.3 Concepção da estrutura para gerenciar riscos
3.3.4.3.1 Entendimento da organização e seu contexto
Antes de iniciar o projeto e implementação da estrutura de gestão do risco, é importante avaliar e compreender tanto o contexto externo como o contexto interno da organização. A avaliação do contexto externo da organização pode incluir:
• o ambiente social e cultural, jurídico, regulamentar, financeiro, tecnológico, económico, natural e competitivo, seja internacional, nacional, regional ou local;
• relacionamentos e percepções das partes interessadas externas.
Já a avaliação do contexto interno da organização pode incluir:
• governança, estrutura organizacional, papéis e responsabilidades na organização;
• políticas, objetivos e estratégias definidas para a organização;
• pontos fortes da organização, em termos da capacidade dos recursos e seus conhecimentos (por exemplo: capital para investir, tempo, pessoas, processos, sistemas e tecnologias);
• sistemas de informação, fluxos de informação e processos de decisão (formais e informais);
• relações entre os diversos envolvidos pela gestão de riscos e a cultura da organização;
• normas, diretrizes e modelos adotados pela organização;
• modelo utilizado para as relações contratuais.
3.3.4.3.2 Estabelecer uma política de gestão de risco
A organização deve ter uma política de gestão de riscos aprovada pela alta direção da corporação, caso essa ainda não exista. A política de gestão de risco deve indicar claramente os objetivos da organização e normalmente aborda os seguintes temas:
• justificativa da organização para o gerenciamento de risco;
• relacionamentos entre os objetivos da organização e as políticas de gestão de riscos;
• responsabilidades e competências para o gerenciamento de risco;
• processo que determina como os interesses conflitantes serão tratados;
• compromisso de tornar disponíveis os recursos necessários à gestão de risco;
• compromisso de rever e melhorar a política de gestão de riscos em resposta a um evento ocorrido.
A política de gestão de risco deve ser comunicada de forma apropriada.
3.3.4.3.3 Responsabilidade
A organização deve assegurar que haja responsabilidades, autoridades e competências adequadas para o gerenciamento de riscos, incluindo a implementação e manutenção do processo de gestão de riscos. Deve ser assegurada a adequação, a eficácia e a eficiência dos controles que medem o desempenho da gestão de riscos.
Isso pode ser facilitado pelas seguintes definições de responsabilidade:
• identificar os proprietários dos riscos, que terão a responsabilidade e a autoridade para gerenciá-los;
• identificar quem é responsável pelo desenvolvimento, implementação e manutenção do
framework de gestão de risco;
• identificar as responsabilidades das pessoas em todos os níveis da organização que estejam relacionadas aos projetos ou atividades do processo de gestão de riscos;
• responsáveis pela medição do desempenho e a emissão de relatórios.
3.3.4.3.4 Integração em processos organizacionais
A gestão de riscos deve ser incorporada em todas as práticas de organização e nos seus processos de forma eficiente. O gerenciamento de riscos deve fazer parte dos processos organizacionais, e não ser um processo separado dos demais.
Em particular, a gestão de riscos deve ser incorporada no planejamento estratégico e na política dos negócios, principalmente nos processos de mudanças.
Deve haver um plano de gestão de risco em toda a organização para assegurar que a política de gestão de riscos é implementada e que a gestão de riscos faz parte de todas as práticas organizacionais e seus processos. O plano de gerenciamento de risco pode ser integrados em outros planos organizacionais, tais como o planejamento estratégico.
3.3.4.3.5 Recursos
A organização deve alocar recursos adequados para a gestão de riscos, considerando os seguintes pontos:
• pessoas, habilidades, experiência e competência que são necessárias para a efetiva gestão de riscos;
• recursos necessários para cada etapa do processo de gestão de risco;
• processos, métodos e ferramentas a serem utilizadas para o gerenciamento de risco;
• processos e procedimentos organizacionais devem estar documentados;
• sistemas de informação e sistemas de gestão do conhecimento devem ser utilizados para suportar a gestão de riscos;
• programas de treinamentos devem estar previstos.
3.3.4.3.6 Estabelecer a comunicação interna e os mecanismos de comunicação
A organização deve estabelecer a comunicação interna e os mecanismos que serão utilizados para essa comunicação de forma a apoiar e incentivar o controle das responsabilidades e a propriedade dos riscos.
Esses mecanismos devem assegurar que:
• a estrutura de gerenciamento de risco deve ser comunicada de forma adequada;
• relatórios internos adequados sobre a eficácia dos processos e os resultados obtidos no gerenciamento dos riscos;
• informações relevantes derivadas da aplicação de gestão de riscos deve estar disponíveis aos interessados nos momentos certos e em níveis apropriados;
• deve existir um processo de consulta com as partes internas, incluindo formas de consolidar as informações sobre os riscos e sua sensibilidade.
