Procedimentos de mapeamento dos processos

A modelagem de processos consolida modelos de processo na forma de diagramas operacionais. De acordo com Oliveira e Neto (2009) os objetivos de desenvolver um modelo são:

a) Entender o negócio - identificar os gargalos, requisitos e ineficiências do trabalho; b) Implementar soluções - facilitar a identificação dos problemas por meio do uso de

metodologias, proporcionando as melhores práticas dos modelos de gestão;

c) Padronizar conceitos - compartilhar a visão do negócio e sistematizar o conhecimento entre os profissionais envolvidos no projeto;

d) Analisar melhorias - monitorar processos e seu funcionamento promovendo a observação de oportunidades de melhoria.

Segundo Baldam (2009) deve-se modelar duas situações do processo: a situação atual (as is) e a situação futura (to be). Na modelagem do processo atual deve-se compreender como o processo acontece, seus modos de falha e intenções. Deve-se prover informações para

integrar dados e processos. Na modelagem de situação futura (to be) deve-se empregar metodologias para otimizar processos, fazer simulações, inovações e novas modelagens, definir mudanças nos novos processos e adotar quando possível e/ou necessário melhores práticas e modelos de referências.

Para modelar o processo de IT e o subprocesso de coleta de documentos de patente optou-se por observar os procedimentos práticos da unidade e um manual de atividades. Aplicou-se a ferramenta e metodologia BPMN, e em reunião os modelos foram desenhados e debatidos em parceria com os pesquisadores chave da unidade. O diagrama dos processos as is permitiu maior detalhamento e conhecimento de como a inteligência é executada, além de servir de base para compreender as ineficiências no subprocesso de coleta, permitindo a posterior aplicação dos aportes da qualidade para melhoria de processo e criação de um novo modelo to be. A seção a seguir detalha os procedimentos de melhoria e modelagem do novo processo.

6.2.2 2 Procedimentos de melhorias: levantamento das causas, priorização e proposta de ação corretiva

Após o mapeamento dos processos, as causas e os modos de falhas que impactam negativamente na precisão da coleta foram levantados e compreendidos considerando seus efeitos e possíveis soluções através de um brainstoming. Isso foi realizado por uma equipe de 6 analistas e coletores de inteligência. Durante a reunião foram levantadas duas categorias de causas: a) aquelas relacionadas às bases de dados; b) aquelas relacionadas ao desenvolvimento da estratégia de busca. Na primeira categoria foram levantadas 12 causas que impactam negativamente na precisão dos dados e informações coletadas. Já na segunda foram levantadas 7 causas (APÊNDICE A).

As causas e efeitos e as soluções levantadas foram utilizadas como insumo para aplicação de uma análise FMEA de processo (APÊNDICE B). Na FMEA, as categorias das causas foram transformadas em funções do processo e as causas foram transformadas em modos de falhas. Posteriormente, derivaram-se os efeitos, formas de controle e ações recomendadas.

A primeira fase foi realizar o planejamento FMEA, que consistiu na escolha da abordagem de análise, classificação dos modos de falha, causas e efeitos, escala de avaliação, e regras adotadas. As funções foram compreendidas como etapas que o subprocesso de coleta de documentos de patente deveria desempenhar. Os modos de falha são as formas como o

processo poderia deixar de desempenhar a sua função definida, utilizando uma expressão negativa, por exemplo, no caso da função da escolha satisfatória da base de dados, o modo de falha seria não escolher uma base que forneça vocabulário controlado (Quadro 23).

Os efeitos são as consequências do modo de falha sob a ótica do analista de inteligência (cliente interno). Por exemplo: se o coletor não escolher uma base de dados que forneça um vocabulário controlado, isso pode gerar excesso de documentos irrelevantes para a análise. As causas foram consideradas como as condições comuns que provocam o modo de falha. Por exemplo, para o efeito acima, uma causa poderia ser a baixa compatibilidade entre os termos utilizados na estratégia de busca e aqueles indexados nos documentos (Quadro 23).

Quadro 23 - Termos utilizados na FMEA

Funções Funções que o processo deve desempenhar.

Modos de falha Definem como o processo pode deixar de desempenhar essas funções.

Efeitos Evidenciam as consequências de cada modo de falha. Severidade Qual a gravidade das consequências dos efeitos?

Causas Razões principais que podem resultar na ocorrência dos modos de falha.

Ocorrência Com que frequência o modo de falha ou causa tende a ocorrer? Controle

Descreve os procedimentos ou equipamentos existentes que detectam ou previnem que os modos de falha sejam repassados

para etapas posteriores. Detecção

Qual a chance de detectar o modo de falha/causa antes do produto ser entregue ao cliente? *Define-se cliente como

qualquer pessoa, ou operação Ações

recomendadas

Recomendações identificam as ações necessárias para abordar os modos de falha. Todas as ações recomendadas devem

resultar em benefícios de qualidade e confiabilidade. Fonte: Palady (1997)

A execução da FMEA seguiu algumas regras propostas por Palady (1997), sendo elas: a) um modo de falha pode ser inserido ou não. No caso em que a equipe decidiu que um modo de falha é fisicamente possível, mas não prático, essa falha não foi incluída no formulário; b) no caso de dúvidas, se um modo de falha deveria ser incluído ou não, este foi incluído; c) no caso de questionamento se um modo de falha seria efeitos ou possíveis causas, o modo de falha foi redigido como a expressão negativa da função; d) as colunas severidade, ocorrência e detecção foram mensuradas independentemente, ou seja, os membros da equipe não passaram para a segunda coluna sem finalizar a primeira; d) quando o membro da equipe não se sentiu seguro em avaliar, absteu-se; e) os votos de todos os participantes receberam pesos iguais.

severidade dos efeitos, sob a perspectiva do analista; na média da média dos valores de ocorrência das causas dos modos de falha e na média dos valores de detecção das causas. O valor do grau de prioridade de risco - NPR ou RPN (Risk Priority Number) foi dado pelo produto dos valores médios de severidade, ocorrência e detecção. Cada participante da FMEA assumiu um valor para as variáveis considerando as escalas dos Quadros 24, 25, 26.

Quadro 24 - Escala de severidade

Escala de Severidade Nível

1 Efeito não percebido pelo analista Nenhum

2 Efeito bastante insignificante, percebido pelo analista, mas não faz com que procure o coletor.

Baixo 3 Efeito insignificante que perturba o analista, mas não faz com que procure o

coletor.

4 Efeito bastante insignificante, mas que perturba o analista, fazendo com que procure o coletor

5 Efeito menor, inconveniente para o analista, mas não faz com que procure o

coletor. Moderado

6 Efeito menor, inconveniente para o analista fazendo com que procure o coletor 7 Efeito moderado, que prejudica o desempenho do processo levando a uma

falha grave ou uma falha que pode impedir a execução das funções Alto 8 Efeito significativo, resultando em falha grave

9 Efeito crítico que provoca a insatisfação do analista e interrompe o processo.

Extremo 10 Perigoso, coloca em risco a continuidade operacional da organização

Fonte: Adaptado de Palady (1997)

Quadro 25 - Escala de ocorrência

Escala de Ocorrência Nível

1 Extremamente remoto, altamente improvável Nenhum

2 Remoto, improvável Muito baixo

3 Pequena chance de ocorrência Baixo

4 Pequeno número de ocorrências

Moderado

5 Espera-se um número ocasional de falhas

6 Ocorrência moderada

7 Ocorrência frequente

Alto

8 Ocorrência elevada

9 Ocorrência muito elevada

Extremo

10 Ocorrência certa

Fonte: Palady (1997)

Quadro 26 - Escala de detecção

Escala de Detecção Nível

1 É quase certo que será detectado

Extremo

2 Probabilidade muito alta de detecção

3 Alta probabilidade de detecção

Alto

4 Chance moderada de detecção

5 Chance média de detecção

Moderado

7 Baixa probabilidade de detecção

8 Probabilidade muito baixa de detecção

Baixo

9 Probabilidade remota de detecção

10 Detecção quase impossível Muito baixo

Fonte: Palady (1997)

Após o planejamento e execução, iniciou-se a etapa de avaliação. Avaliou-se a severidade dos efeitos, a ocorrência e detecção das causas. No FMEA os valores altos são ruins e os baixos são bons. A análise dos dados considerou o nível crítico dos fatores dado pela pontuação de risco das falhas que foram ordenadas. Esses níveis foram: a) índice de ocorrência - mede com que frequência o modo de falha ocorre; b) índice de severidade - mede a gravidade do efeito do modo de falha em uma escala de 1 a 10; c) índice de detecção - mede a chance de detectar o modo de falha ou as causas.

Entre os métodos existentes para interpretar o FMEA existe o método tradicional, que se configura pela ordenação do NPR e que foi utilizado pela primeira vez em 1963 pela National Aeronautics and Space Administration (NASA), e também o método gráfico de áreas, proposto por Paul Palady em 1994 como uma crítica ao método tradicional. O método gráfico permitiu uma aplicação baseada na severidade e na ocorrência, principalmente. Nesse método, o gráfico permitiu determinar a existência de falhas com severidade extrema (valores de 10), embora tenham pouca ocorrência (valor 1) (PALADY, 1997; ROOS; ROSA, 2008).