Aplicabilidade da análise da variabilidade

Hollnagel (2012) sugere que a variabilidade deve ser analisada em instanciações de eventos específicos que representem a interação entre duas ou mais funções no desenvolvimento de suas atividades.

A presente pesquisa realizou um modelo genérico FRAM do gerenciamento de contingências de manutenção. Devido a esse fato, torna-se inviável a análise da variabilidade, conforme sugerido por Hollnagel (2012), uma vez que esta pesquisa não buscou realizar instanciações de eventos específicos.

Mesmo assim, a presente pesquisa irá apresentar um modelo de análise de variabilidade que poderá ser empregado por pesquisas futuras para realizar a análise da variabilidade upstream-downstream das funções. O exemplo apresentado, a seguir, é uma instanciação derivada do modelo FRAM representado pela figura 26. A plausibilidade deste exemplo foi validada com a empresa. Ele foi elaborado com a intenção de fornecer um modelo para realizar a análise da variabilidade em pesquisas futuras.

5.2.1.3.4.1 Exemplo de análise de variabilidade

Em determinada contingência de manutenção a função <Orientar sobre Procedimentos de Manutenção> solicita que a função <Alocar Recursos> disponibilize uma peça para o reparo de uma aeronave que se encontra em Porto Alegre (esta solicitação foi representada na ligação 1 da instanciação na figura 30). Para atender à solicitação, a função <Alocar

Recursos> realiza uma consulta em um software especializado e descobre que a peça requerida se encontra somente no Rio de Janeiro ou em Salvador.

De acordo com a logística planejada pela função <Alocar Recursos>, a melhor solução é transladar a peça do Rio de Janeiro para Porto Alegre. Esta função entra em contato com os responsáveis do almoxarifado de peças da companhia no Rio de Janeiro e solicita que ela seja enviada no próximo voo para Porto Alegre. Após realizar esta solicitação, a função <Alocar Recursos> informa à função <Orientar sobre Procedimentos de Manutenção> que o recurso solicitado estará embarcando no próximo voo do Rio de Janeiro para Porto Alegre e deve demorar cerca de 2 horas para chegar (esta comunicação foi representada pela ligação 2 na instanciação da figura 30).

Uma vez ciente desta informação, a função <Orientar sobre Procedimentos de Manutenção> calcula que a aeronave deve ser liberada para voo em até 3 horas e repassa esta informação para a função <Coordenar Voos> que decide não cancelar o voo e segurar os passageiros até que o reparo seja concluído e a aeronave possa dar continuidade as operações previstas (isto foi representado pela ligação 3, na figura 30).

Porém, o responsável pelo almoxarifado no Rio de Janeiro não encontra a peça solicitada e, após uma pequena investigação, descobre que o recurso já havia sido utilizado em outra aeronave e que a disponibilidade da peça no software é incoerente.

Imediatamente, a função <Alocar Recursos> é informada da situação e começa de imediato uma nova solicitação de logística para transladar a requerida peça de Salvador para Porto Alegre. Após encontrar a melhor solução, o tempo previsto para chegada da peça passou de duas para seis horas. Esta informação é repassada pela função <Alocar Recursos> para a função <Orientar sobre Procedimentos de Manutenção> (representado na figura 30 pela ligação 4) que repassa a informação para a função <Coordenar Voos> (ligação 5).

Devido ao período previsto para a disponibilização da peça ter triplicado, a função

<Coordenar Voos> decide cancelar o voo, dando início a uma contingência de manutenção.

Após a resolução da mesma, descobriu-se que a peça se encontrava disponível no software devido a um profissional da função <Alocar Recursos> não ter indicado a utilização do recurso no software em virtude de problemas fisiológicos enfrentados na ocasião. Este pequeno detalhe aumentou a variabilidade na resolução da contingência de manutenção, levando ao cancelamento da operação e consequente prejuízo financeiro e de imagem.

De acordo com este exemplo é possível concluir que a variabilidade se originou em uma fonte interna (problema fisiológico) enfrentada pelo profissional responsável pela função <Alocar Recursos>. O problema enfrentado por este profissional, o impediu de concluir suas

atividades e consequentemente de selecionar o recurso como utilizado no software especializado.

Esta indicação errônea fez com que outro profissional da função <Alocar Recursos> projetasse uma logística imprecisa para atender à solicitação que lhe foi empregada.

Esta indicação errônea gerou atrasos tanto para a função <Orientar sobre Procedimentos de Manutenção> quanto para a função <Coordenar Voos>. A consequência foi o cancelamento do voo previsto e prejuízos financeiros e de imagem.

Figura 30 – Exemplo de Variabilidade Contingência de Manutenção – Instanciação FRAM

Fonte: O Autor (2017)

Por meio da figura 30 podemos observar que a ligação 1 foi precisa e a tempo, contribuindo para a diminuição da variabilidade. A ligação 2 foi transmitida a tempo, mas foi imprecisa, pois a função <Orientar sobre Procedimentos de Manutenção> foi informada que a peça estaria disponível em 2 horas. A ligação 3, por consequência, também foi transmitida a tempo, mas manteve a imprecisão da informação.

A ligação 4, por sua vez, foi precisa, informando sobre a real condição da peça solicitada, porém a informação chegou atrasada. Como consequência, a ligação 5 foi atrasada e precisa, forçando a função <Coordenar Voos> a ter que cancelar o voo.

Este exemplo deixa claro como a variabilidade pode afetar o desempenho do sistema. Esta variabilidade muitas vezes causa efeitos indesejados, forçando o sistema a ser mais resiliente para enfrentar contingências. Esta relação mostra-se muito interessante e indica que uma análise da variabilidade em instanciações FRAM de contingências de manutenção pode indicar quando o sistema necessita ser mais ou menos resiliente para enfrentar o problema.

5.2.1.3.5 Comentários gerais sobre a análise da variabilidade durante contingências de