Medidas, Métricas e Indicadores na Gestão de Processos

Em muitos projetos de implantação de BPM que têm como foco principal a automatização de processos é comum que as organizações deixem de prestar a atenção devida a um aspecto essencial: o gerenciamento do desempenho de processos.

Nos eventos sobre BPM dos quais participamos, sempre que se perguntou quais dos participantes eram oriundos da área de TI, vimos muitas mãos serem levantadas. A maioria, na verdade. De fato, é sabido que em muitas organizações a adoção de BPM é consequência de iniciativas da área de tecnologia, seja em iniciativas próprias da TI (para fazer benchmarking, por exemplo), seja pela percepção incompleta de que BPM se trata de um conjunto de tecnologias que apoiam a TI no desenvolvimento e monitoração de processos de workflow e aplicativos.

Não perca o alvo

Talvez por isso a preocupação principal nesses projetos seja a correta implementação de BPMS, BRMS, SOA e todo o dicionário de siglas tecnológicas envolvidas, relegando os aspectos relacionados ao negócio (e o gerenciamento de desempenho, consequentemente) a um plano secundário.

Mas não percamos o alvo, o motivo de ser do BPM é a letra “M”.

Um importante ponto para realizar o gerenciamento do desempenho de processos é a definição de bons indicadores de desempenho. Esses indicadores devem ser capazes de permitir o monitoramento do negócio pelos gestores e servirem de gatilhos para a tomada de ação quando o processo apresentar uma performance diferente da esperada.

MEDIDAS x MÉTRICAS x INDICADORES

Antes de tudo, é necessário desfazer uma confusão comum na utilização dos termos “medida”, “métrica” e “indicador”, que muitas vezes são equivocadamente tomados como sinônimos.

Medida

Segundo o BPM CBOK – versão 3.0,

“Medida é a quantificação de dados em um padrão e qualidade aceitáveis (exatidão, completude, consistência, temporalidade).”

Medida é a avaliação de uma grandeza por meio da comparação com outra grandeza da mesma espécie tomada como unidade. Quando se mede o comprimento de um material ou peça, por exemplo, pode-se utilizar o metro como unidade, isto é, o objeto medido é representado como uma fração (ou múltiplo) do metro.

Medida representa um dado.

Métrica

A definição do BPM CBOK, diz que:

“Métrica é uma extrapolação de medidas, isto é, uma conclusão com base em dados finitos.”

Segundo essa definição, uma métrica pode ser entendida como a relação entre duas medidas de grandezas iguais ou diferentes.  Um exemplo seria o número de defeitos identificados em um lote de produtos finalizados (defeitos [número] / total do lote [número]).

Outro exemplo poderia ser a razão entre o número total de atendimentos realizados por um Serviço de Atendimento ao Cliente (SAC) e o número de horas trabalhadas pelos atendentes (atendimento [número]/ horas trabalhadas [tempo]).

Métrica representa uma informação.

Indicador

De acordo com o BPM CBOK,

“Indicador é uma representação de forma simples ou intuitiva de uma métrica ou medida para facilitar sua interpretação quando comparada a uma referência ou alvo.”

Indicadores representam informações a partir das quais é possível avaliar uma situação e sua evolução histórica. Contudo, indicadores mal definidos podem levar a conclusões equivocadas. Por exemplo, tomar somente a quantidade de reclamações de clientes, mês a mês, ao longo do ano, e verificar que o número absoluto de reclamações cresceu no período não indica, necessariamente, uma piora nos negócios. Está claro que se a sua empresa efetuar 1.000 vendas em dezembro e ter 10 reclamações de clientes é uma situação melhor que ter efetuado 100 vendas em janeiro e ter recebido 5 reclamações. Proporcionalmente, o número de reclamações terá caído de 5% (5/100) para 1% (10/1.000), embora em números absolutos elas tenham dobrado.

É claro que números absolutos podem ser bons indicadores, a depender do que se queira avaliar. Mas indicadores que relacionam diferentes métricas e medidas permitem relativizar a realidade e fazer melhores comparações, como no exemplo acima, pois embora o número de reclamações tenha crescido em termos absolutos, a situação, na verdade, melhorou.

Dois gráficos com interpretações comparadas

Duas interpretações de uma mesma realidade

 

INDICADORES DIRECIONADORES x INDICADORES DE RESULTADOS

Ao definir indicadores com o objetivo de monitorar o desempenho dos processos, muitas organizações definem seus painéis de monitoramento com base em métricas que focam apenas no resultado desejado e perdem, assim, a valiosa oportunidade de monitorar não apenas o resultado do processo, mas a sua execução. Dessa forma, o resultado é conhecido apenas quando não há mais nada a se fazer para que a conclusão do processo seja favorável à organização.

Para evitar essa situação, é necessário definir dois tipos de indicadores:

  • Indicadores direcionadores (drivers), que monitoram a causa antes do efeito e caracterizam-se pela possibilidade de alterar o curso para o alcance de um resultado.
  • Indicadores de resultados (outcome), que monitoram o efeito e não permitem mais alterar um dado resultado.

Um bom painel de monitoramento deve conter indicadores direcionadores e indicadores de resultados de forma balanceada. Note no exemplo abaixo a combinação de gráficos do tipo Gauge, que são normalmente utilizados para acompanhar um indicador direcionador, através de monitoramento instantâneo, e de análise histórica, como os gráficos de área.

Painel de indicadores

Painel de indicadores balanceados

Pense em uma companhia de seguros que estabelece uma meta mensal de 40 apólices de seguro por agente. Assim, cria um indicador de resultados para demonstrar as vendas por mês.

A empresa observou o histórico do processo e identificou que, para cada quatro contatos realizados por um agente com clientes potenciais, um negócio é fechado. Logo, conclui que o resultado das vendas de apólices está relacionado ao número de contatos realizados pelos agentes. Portanto, define outra meta: 160 contatos por mês, por agente. Esse é um indicador direcionador, pois permite uma melhor administração dos esforços para o alcance das metas através de ações de correção de curso, como campanhas de final de semana, plantões de vendas e outras medidas contingenciais.

Esperamos que tenha ficado clara a diferença entre medida, métrica e indicador, e o benefício de utilizar não apenas indicadores de resultado mas também indicadores direcionadores de forma balanceada.

Tem um exemplo prático que gostaria de compartilhar? Comente este artigo e contribua para a discussão e o conhecimento dos demais leitores.

Métodos para levantamento de informações na Modelagem e Análise de Processos

Em projetos envolvendo modelagem e análise de processos de negócio é imprescindível que a equipe tenha a compreensão correta dos processos ponta-a-ponta da organização para uma visão precisa do negócio. Esta compreensão pode ser obtida com uma coleta de informações realizada ao longo do esforço de forma consistente, caso contrário alguma informação importante poderia faltar, e seria difícil fornecer uma visão clara do negócio.

Existem diversos métodos especializados para levantamento destas informações. Falaremos sobre isto em uma série de artigos, trazendo as diversas formas de captura de informações para a realização do trabalho de modelagem.

Neste artigo, iniciaremos falando dos métodos Pesquisa, Entrevista e Observação Direta.

PESQUISA

A pesquisa serve para obter o contexto inicial do processo, serve também para complementar o entendimento do negócio e para preencher algumas lacunas na documentação do processo que não foram obtidas por outros métodos.

Pode ser pesquisado todo o tipo de documento, desde formulários, manuais dos sistemas da empresa, políticas da organização, registros de auditorias, documentação de processos, descrições escritas das partes interessadas e autores do processo, etc.

Esforço: O empecilho fica por conta do tempo requerido para realizar estes levantamentos, que muitas vezes não é suficiente para conciliar diferenças de opinião e informações levantadas versus o trabalho realizado na prática.

ENTREVISTA

Entrevista é um “processo de comunicação fundamental entre pessoas que se caracteriza pela realização direta, face a face, que se estabelece entre o profissional e o usuário” (Ballestero-Alvarez, 1997).

A entrevista é um método muito utilizado para a coleta de informações. Ela pode ser realizada de forma individual ou em grupo, conduzida por um facilitador. Pode ser presencial, por telefone, conferência web ou e-mail.

Participantes: Devem ser entrevistados os integrantes do processo, que contribuem com informações sobre as atividades que executam, assim como seus líderes. Podem também ser pessoas responsáveis pelo desenho, execução e desempenho do processo, não esquecendo daqueles que fornecem entradas ou recebem saídas do processo.

Ponto de atenção: A realização da Entrevista (em grupo) é muitas vezes confundida com outro método, o Workshop.
A diferença básica destes dois métodos é que no caso da entrevista em grupo os participantes limitam-se em falar das suas atividades (seu papel no processo), é algo mais pontual. Por exemplo: Entrevistar três operadores de empilhadeira de um CD (Centro de Distribuição). Ambos operadores realizam atividades referentes a movimentação de porta pallets da área de armazenagem para a área de separação.

Já o Workshop  consiste em reunir diferentes pontos de vista sobre o processo com representantes de todos os papéis envolvidos para discutir o processo. Falaremos mais sobre este método em nosso próximo artigo sobre o assunto.

Vale ressaltar que nada impede que outros métodos sejam aplicados juntamente com a entrevista, servindo assim como complemento para coleta de informações não obtidas com esta técnica.

Perfil do entrevistado: A avaliação do perfil do entrevistado é crucial para uma coleta consistente, portanto antes da escolha do entrevistado, verifique seu nível de atuação dentro da empresa e se o seu papel condiz com o nível de informação exigida.
Por exemplo: Analista marca uma entrevista com o Gestor do Centro de Distribuição para mapear atividades operacionais do setor de coleta de encabidados da sua unidade. Neste caso, o que poderia dar errado? Possivelmente o gestor simplificará as atividades operacionais, e com isto detalhes das atividades poderão ser perdidos, pois só quem executa é que conhece as atividades e muitos problemas que hoje acontecem não serão relatados.
Desta forma, concluímos que a escolha pelo gestor não seria a mais apropriada, pois a definição e manutenção de procedimentos de nível operacional fica em posse do auxiliar de operação, além é claro daqueles detalhes práticos, tarefas e passos executados no dia-a-dia que não são documentados e não passam pelo conhecimento do gestor.

Esforço: A entrevista pode exigir um grande esforço do analista para obter o grau de detalhamento satisfatório, isso deve-se a forte dependência das informações fornecidas pelos entrevistados. Esta dinâmica pode ser ineficiente caso o entrevistado não compartilhe, por algum motivo, as informações de como suas atividades são executadas de verdade. Os motivos são diversos, desde medo do fracasso e reprovação, até o medo da mudança (do novo) ou ter que começar a  fazer diferente de como é realizado hoje (este é um medo cultural). Além disto, a entrevista exige que os entrevistados parem as suas atividades, o que pode trazer dificuldades de agenda.

OBSERVAÇÃO DIRETA

Segundo Lakatos & Marconi (1992), a observação direta intensiva é um tipo de atividade que “[…] utiliza os sentidos na obtenção de determinados aspectos da realidade. Não consiste apenas em ver e ouvir, mas também examinar fatos ou fenômenos que se deseja estudar”.

Observação direta é um método que pode ser definido como um acompanhamento presencial do processo a ser modelado que sujeita o pesquisador a um contato mais direto com a realidade.

Este método auxilia na identificação de evidências revelando comportamentos, atividades e tarefas difíceis de serem lembradas por outras técnicas. Muito eficiente no diagnóstico de oscilações e desvios que ocorrem no dia-a-dia do trabalho.

Participantes: A escolha correta do executor do processo deve representar o nível de desempenho típico para executores daquele processo. Este executor deve entender o impacto de suas tarefas no resultado final do processo ponta-a-ponta, ter uma compreensão (uma visão) do todo e ter critérios para entender se o desempenho de suas atividades são satisfatórias.

Esforço: Para que o observador possa capturar informações consistentes com um grau de detalhamento satisfatório, deve ser levado em conta uma variedade grande de execuções de processos, observação de diversos grupos de executores e locais. Este esforço exige tempo e esforço, o que pode não ser possível em determinados projetos.

Riscos: A presença do observador pode provocar alterações na forma como os atores executam suas atividades, acabando com a naturalidade dos mesmos. Com isto, os atores ao serem observados realizam suas atividades da forma como aprenderam e não como realmente realizam no seu dia-a-dia. Este cenário pode gerar uma visão distorcida, criando falsas impressões da realidade e impactando de forma direta no resultado do processo.

Alguns cuidados podem ser tomados para que este tipo de problema não venha ocorrer, como dar as condições e tempo necessário para que o executor do processo se sinta confortável. Outra solução é realizar um comparativo dos resultados obtidos na observação com resultados anteriores registrados, garantindo assim que o trabalho realizado pelo observador represente a rotina diária do ator do processo.

Em nosso próximo artigo sobre o assunto continuaremos falando dos métodos especializados para levantamento e coleta de informações.
Confira: Métodos para levantamento de informações na Modelagem e Análise de Processos – Parte 2.

 


Conheça mais sobre estas e outras atividades relacionadas à modelagem de processos no curso de Modelagem de Processos de Negócio da iProcess Education.

 

Desmistificando tipos de tarefas em BPMN: Tarefas automáticas

No artigo anterior (Desmistificando tipos de tarefas em BPMN: Tarefa Abstrata, Tarefa de Usuário e Tarefa Manual) iniciamos uma série de três artigos sobre os tipos de tarefas em BPMN. Para facilitar o entendimento, estamos discutindo os os tipos de tarefa de acordo com seu propósito (essa divisão não é oficial):

Tarefas de execução de rotinas automáticas

Para representar situações em que rotinas que são executadas automaticamente no processo (em que seu acionamento é determinado pelo andamento do fluxo do processo, sem que haja uma pessoa para acioná-lo), BPMN sugere três tipos de tarefa: tarefa de serviço, tarefa de script e tarefa de regra de negócio:

Os tipos de tarefa automáticas: tarefa de serviço (service task), tarefa de script (script task) e tarefa de regra de negócio (business rule task)

De acordo com a especificação:

“Uma Service Task (tarefa de serviço) é uma tarefa que usa algum tipo de serviço, que pode ser um Web Service ou uma aplicação automatizada.” (pág 156)

“Uma Script Task (tarefa de script) é executada pelo motor de processos de negócio (business process engine). O modelador ou implementador define um script em uma linguagem que o motor de processos consegue interpretar. Quando a tarefa estiver pronta para iniciar, o motor de processos executará o script. Quando o script for concluído, a tarefa também será concluída.” (pag 162)

“Uma Business Rule Task (tarefa de regra de negócio) propicia um mecanismo para o processo para enviar informações a um Business Rules Engine (motor de regras de negócio) e obter o resultado do cálculo que o motor de regras pode prover. ” (pag 161)

 

Todas as três são utilizadas na modelagem quando temos um processo que está sendo automatizado (se o processo é executado manualmente, fora de um BPMS ou workflow, é necessário que haja uma atividade manual em que uma pessoa acione a execução de uma funcionalidade; portanto a tarefa em si é de uma pessoa).

 A diferença entre elas é que a tarefa de serviço (service task) aciona a operação de um sistema de informação externo com o qual o motor de processo se comunica (process engine) – que pode ser implementado através de tecnologias como webservices, RMI (Remote Method Invocation), EJB (Enterprise Java Beans), etc. Já a tarefa de script (script task) executa um trecho de código que a própria aplicação de motor de processos interpreta e executa (e cada fornecedor de produto pode definir sua linguagem de script própria). Por exemplo, a transformação de um tipo de dado em outro ou a realização de cálculos com os dados da instância do processo, são exemplos de tarefas de script.

A tarefa de regra de negócio (business rule task) comporta-se da mesma forma que a tarefa de serviço, porém possui o propósito específico de obter resultado da aplicação de uma determinada regra de negócio no processo (leia mais sobre regras de negócio e Business Rules Management no artigo Business Rules e a Dinâmica do Negócio).

Um exemplo de processo com tarefas automáticas de serviço, de tarefa e regra de negócio

No processo hipotético acima temos exemplos aplicados dos três tipos de tarefas automáticas.

  • A tarefa “Identificar prioridade do atendimento” é uma tarefa de regra de negócio, pois executa uma regra da organização (por exemplo: chamados de clientes com contas premium ou chamados que já tiveram uma visita técnica mas o problema não foi solucionado são tratadas como prioridade “emergência”, enquanto as demais são prioridade “normal”. Se a organização quiser mudar esta regra e incluir outros planos no atendimento de prioridade emergencial, pode modificar a regra de negócio sem impactar no processo).
  • Neste processo em que todos os chamados são originados com prioridade “normal”, a tarefa “Elevar prioridade do atendimento” é uma tarefa de script pois muda de “normal” para “emergência” uma informação do próprio processo, elevando a prioridade dos processos que passam por ela (sem precisar acessar outros sistemas).
  • A tarefa “Identificar técnico responsável” é uma tarefa de serviço pois acessa o sistema de localização da empresa identificando que técnico está mais próximo do endereço do cliente. Ela aciona um serviço deste sistema, e recebe como retorno a informação do técnico disponível.
  • A tarefa de serviço a seguir “Sinalizar sistema de chamados”, aciona um serviço do sistema usado pela empresa para enviar ao comunicador do técnico a nova chamada prioritária.
  • A tarefa de serviço “Agendar visita técnica” registra o chamado no sistema que libera a lista de clientes a serem visitados no dia pelos técnicos. Como é uma visita normal, ela é registrada de acordo com o agendamento realizado com o cliente na criação da ficha de atendimento.

Aprenda a dominar a notação BPMN utilizando as melhores práticas com nossos instrutores, em um curso repleto de exercícios e um laboratório prático de modelagem de um processo de negócio de ponta a ponta!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br/ipe04

Projetos de Modelagem de Processos – Parte 1: Objetivos e Motivadores

A modelagem de processos está sendo muito utilizada pelas organizações para conhecer, documentar e melhorar os seus processos. Porém, as necessidades que levam uma organização a iniciar a modelagem de processos acabam direcionando a tipos de projetos de modelagem com focos diferentes.
Trataremos, neste primeiro artigo da série, dos principais objetivos e motivadores relacionados aos mais comuns tipos de projetos de modelagem de processos.

 

Modelagem para Conhecer o Processo:

Objetivo
  • modelar o processo de modo que a forma como ele é realizado passe a ser de conhecimento dos participantes que executam o processo e da organização como um todo
Motivadores
  • formalizar e institucionalizar o modelo do processo
  • processo em que ninguém da instituição conhece de ponta a ponta
  • entender o funcionamento do processo para identificar a causa de problemas e falhas
Modelagem para Documentação ou Treinamento:

Objetivos
  • documentar o processo para que dúvidas operacionais possam ser diluídas através da consulta ao processo
  • fornecer uma documentação completa para que os seus executores saibam como realizar suas atividades, evitando erros ou demoras devido a dúvidas
  • fornecer uma documentação que facilite o treinamento de novos colaboradores:
    • minimizando o efeito de perdas de colaboradores
    • auxiliando a organização que passe por um processo de expansão
Motivadores
  • processos em que os executores não tem experiência em executá-lo porque:
    • os papéis tem alta rotatividade ou
    • o processo não é executado com frequência por determinados papéis
  • formalizar e institucionalizar o modelo do processo
  • processo em que ninguém da instituição conhece de ponta a ponta
  • entender o funcionamento do processo para identificar a causa de problemas e falhas
Modelagem para Implantação de Auditoria:

Objetivo
  • descrever os processos que serão objetos de auditoria para que exista uma referência comum sobre o que deve ou não ser feito no processo
Motivadores
  • padronização e documentação de processos que precisam ser auditados devido a exigências internas ou externas da organização
Mapeamento de Processos de Toda a Organização:

Objetivo
  • criar um repositório de processo com todos os processos da organização modelados e documentados
Motivadores
  • criar um ponto de partida para as iniciativas de gestão por processos
  • permitir que novas demandas de melhoria de processos possam ser atendidas rapidamente
Modelagem para Padronização dos Processos:

Objetivo
  • garantir que toda a organização executa o mesmo processo
Motivadores
  • demandada por processos executados em mais de um local. Ex.: Processo utilizado em várias unidades geográficas como no varejo ou no sistema financeiro.
  • processos que possuem diferente desempenhos de acordo com o local onde são executados ou das pessoas que os executam
  • aquisição de outras empresas → Necessidade de unificar a operação
  • abertura de novas unidades → Necessidade de replicar o modelo de gestão
Modelagem para o Redesenho de Processos:

Objetivos
  • a modelagem é focada no entendimento da situação atual do processo (AS IS)
  • objetivo não é a documentação do processo e sim o entendimento de
    • quais são suas atividades
    • quais os seus pontos fracos
    • quais os seus pontos fortes
    • quais suas oportunidades de melhoria
  • criar base para executar todo o ciclo BPM de melhorias: Mapeamento, Redesenho, Automação, Implantação e Melhoria Contínua.
Motivadores
  • redução de custos ou perdas do processo
  • processos críticos que, se não forem bem executados, podem gerar um grande impacto na organização
  • processos com metas cronológicas bem delimitadas
  • processos que possuem muitas perguntas a serem respondidas. Ex: Como é feito o processo? Porque acontecem tantos erros? Porque o processo é tão lento? Como posso melhorá-lo? Como meço os indicadores deste Processo?
  • processos com SLA bem definidos
  • melhorar o atendimento ao cliente final
  • expansão organizacional
  • processos inter-organizacionais (B2B)
  • empresa precisa se certificar ou aderir a uma legislação
Modelagem para Automação de Processos:

Objetivo
  • conhecer o processo o suficiente para propor uma versão automatizada que busque aumentar a sua eficiência operacional
Motivadores
  • ocorre quando a organização está satisfeita com o seu processo, mas acredita que ele poderia ser melhorado com o uso da tecnologia
  • organização entende que não precisa necessariamente discutir o processo a nível de negócio, e sim entregar com mais eficiência o processo da forma como atua hoje

Leia também o artigo Parte 2 – Características e Desafios, que trata da profundidade da modelagem, características, desafios e riscos relacionados a cada tipo de projeto de modelagem.

A importância de avaliar a cultura e o medo da mudança na implementação de BPM

Neste artigo vamos abordar alguns dos aspectos mais críticos, e frequentemente ignorados, no que se refere a implementar BPM nas organizações: como a cultura organizacional e o medo da mudança são fatores que podem afetar consideravelmente o resultado desta iniciativa.

Durante a implementação de projetos de BPM, é muito frequente se deparar com obstáculos relacionados à cultura da organização, principalmente no que se refere à forma como as coisas costumam ser feitas. São procedimentos, padrões e ferramentas que se estabeleceram com o passar do tempo, e acabaram virando a única forma conhecida das pessoas de realizar o seu trabalho. Com a realização de um trabalho de análise e redesenho do processo através de uma iniciativa de BPM, então todos os gaps, ineficiências e problemas desta forma de trabalho podem vir à tona. Podemos citar como exemplo um caso clássico na automatização de processos: a substituição de formulários em papel que devem ser assinados manualmente pelos gestores, por formulários eletrônicos em que a aprovação é controlada por um processo automatizado e realizada através de uma lista de trabalho.

É do nosso conhecimento casos em que usuários de negócio ficaram receosos e resistentes pelo simples fato de que as aprovações necessárias não iriam mais ser em papel, ou seja, sem a assinatura “física” do seu gestor. São usuários que não foram suficientemente informados de todos os conceitos por trás de uma aprovação digital, e chegaram a exigir (já numa fase bem adiantada de uso do processo) que os participantes deveriam adicionalmente imprimir o histórico de aprovações e anexar junto a solicitação, para que fosse dado o encaminhamento para a próxima área envolvida. Temos aqui um caso em que um dos maiores benefícios da automatização de processos, que é a economia de papel, foi praticamente anulada simplesmente pelos receios de usuários mal informados.

Uma mudança na forma de como são feitas as coisas pode mexer ainda com questões comportamentais enraizadas na organização, e que podem passar despercebidas até para o mais experiente analista de processos. Podemos citar o exemplo de um solicitante que aproveitava o momento em que solicitava a aprovação do seu gestor (com o formulário em papel em mãos), para sentar com ele na sua sala, tomar um cafezinho e discutir com ele banalidades e o resultado do futebol no fim de semana. E que, de uma hora pra outra, teve esta rotina agradável e esperada (do ponto de vista dele) sendo substituída pela rápida, eficiente e distante aprovação eletrônica. O exemplo pode até parecer exagerado e cômico, mas é um tipo de percepção que de fato ocorre entre os usuários, e é preciso ficar atento.

A resistência a mudanças pode ser um grande impeditivo para o sucesso de projetos de BPM. Se os usuários não forem suficientemente informados e principalmente convencidos da necessidade da mudança, podem virar grandes opositores e chegar ao ponto de boicotar a iniciativa, levando muitas vezes o projeto ao fracasso. Em outro exemplo que ilustra esta situação, uma das pessoas envolvidas na execução de um processo chegou a temer pelo seu emprego, quando descobriu que a automação do processo iria realizar de forma automática muito dos procedimentos que esta pessoa executava de forma manual, procedimentos os quais tomavam boa parte do seu dia. Foi então necessário um trabalho de informação e conscientização com esta pessoa, informando que esta seria direcionada para atividades de maior valor agregado, para que a resistência e o medo da mudança fossem finalmente superados.

Se durante uma iniciativa de BPM as organizações optarem por ignorar a avaliação da cultura interna e não realizarem uma etapa de gerenciamento das mudanças com todos os envolvidos, certamente poderá se esperar como resultado uma resistência muito grande e, em casos extremos, até o cancelamento da iniciativa.

Evitando as armadilhas mais comuns em projetos de otimização de processos

Projetos de otimização de processos consistem em realizar o trabalho de ajustar um processo buscando sua melhoria. De acordo com Reint Jan Holterman, autor do white paper “Five Common Pitfalls in Process Optimization, And how to avoid them“, os esforços de otimização devem “reforçar as atividades essenciais da empresa, produzindo melhores produtos e serviços, em um período mais curto de tempo, a um custo mais baixo e com mínimo de impacto ambiental”.

A otimização de processos requer, então, que se possa produzir uma visão de futuro melhor para a execução de um processo olhando para a forma como ele acontece atualmente e seu histórico (lições aprendidas). Envolve atividades de modelagem, análise e redesenho do processo, e apesar de este ciclo já se constituir em uma prática comum em organizações que buscam a melhoria de processos através das práticas de BPM, estima-se que 60 a 70% de todos os processos de otimização não produzam resultados satisfatórios (leia mais aqui: http://esopsfables.wordpress.com/2012/02/29/why-process-improvement-projects-fail/).

Em seu white paper, Holterman explora as cinco falhas mais comuns, responsáveis pelos problemas neste tipo de projeto:

1. Falta de clareza sobre onde começa e onde termina o trabalho

Muitos projetos são iniciados com uma declaração “vamos otimizar o processo tal”, mas não está claro para a equipe por onde começar e até onde se vai.

A falta de clareza sobre o início e fim do projeto leva a uma sequência de armadilhas que resultam em um processo desestruturado e interminável.

Em um projeto de otimização de processos é fundamental compreender a situação atual, o status quo do processo. Quem está envolvido, quais são as entradas e saídas, quais são os limites do escopo deste processo, qual é o tempo que o processo leva atualmente para ser executado, que exceções comumente levam a resultados diferentes e com que frequência acontecem, são questões iniciais que precisam ser feitas antes mesmo de se iniciar alguma ação de otimização.

Conhecer bem a situação atual do processo é tão importante quanto ter claro onde se quer chegar. É preciso que todos os participantes tenham uma visão clara de que melhoria deseja-se atingir com o projeto, se é um ganho de produtividade, de redução de tempo, de redução de custos, e que parâmetros definirão o atingimento do resultado esperado.

2. Usar indicadores (KPIs) inadequados

Os indicadores de performance (KPIs) são as referências que apontam a direção para a linha de chegada.

Indicadores mal definidos levarão a equipe a sair do curso, já que apontam para a direção errada.

Sintomas comuns de um KPIs mal definido:

  • não está relacionado ou é impactado muito levianamente pelo processo de negócio;
  • pode gerar interpretações diferentes;
  • não é impactado apenas pelo processo, mas também por  fatores externos;
  • não está relacionado de alguma forma aos objetivos estratégicos da organização, de forma que mesmo que o processo obtenha alguma otimização, não há garantia que produzirá algum resultado melhorado para a empresa.

3. Falta de apoio do dono do processo e da alta gestão

O Dono do Processo (Processo Owner) é o responsável pelo desempenho do processo de negócio, e espera-se que seja o maior interessado no sucesso de um projeto de otimização, já que afetará diretamente os resultados do produto ou serviço gerado pelas atividades do processo de negócio.

Consequentemente, sem um Dono do Processo que se importe em acompanhar o trabalho de otimização do seu processo (seja por falta de interesse ou de tempo para apoiar o trabalho), não se pode esperar grandes resultados do projeto.

Também o apoio da alta gestão da empresa ao projeto de otimização é essencial para o sucesso da iniciativa, de forma a garantir o envolvimento e a disponibilidade dos recursos necessários às ações de melhoria.

4. Não adotar as mudanças no processo

É da natureza humana apresentar resistência a mudanças – mudar envolve sair da zona de conforto, aquela em que conhecemos e controlamos como as coisas funcionam.

Por este motivo, comunicar bem e garantir que os envolvidos tenham tempo suficiente para compreender e aceitar as mudanças propostas é fundamental para o sucesso da implantação de otimizações no processo. As pessoas precisam entender por quê as mudanças estão sendo feitas para assimilar os benefícios a serem obtidos e efetivamente adotá-las.

5. Displicência na execução

Holterman aponta que em muitas organizações, os projetos de otimização acabam se perdendo em um perpétuo estudo e desgastante levantamento de informações, colecionando e analisando todo tipo de dado que se pode coletar acerca do processo na tentativa de representá-lo da forma mais apurada, às vezes envolvendo até mesmo coleta de informações de outros processos que nem estão diretamente relacionados ao escopo de otimização prevista no projeto. Mas dispender toda energia em gerar estatísticas complexas e painéis de monitoramento não trarão resultados práticos de otimização.
Controlar a execução, garantindo que as otimizações definidas sejam efetivamente executadas como planejadas, são um dos grandes desafios de um projeto de otimização e podem encontrar suporte na implementação do processo em um BPMS (Business Process Management Sustem).  Para mais informações do que esperar da implementação de um processo em um BPMS, leia nosso post “Benefícios da Automação de Processos“.

E veja no artigo “Estudo de Caso: Automatizar o processo (ou não)? Eis a questão!” que avaliações recomendamos antes da decisão por automatizar um processo de negócio.