Modelagem de Processos de Negócio: Diferenças entre diagrama, mapa e modelo de processos

Quantas vezes você já se referiu ou ouviu pessoas se referirem a um mesmo desenho de processo como sendo um diagrama de processo ou mapa de processo ou ainda, como um modelo de processo?

Este é um assunto controverso, principalmente para pessoas que estão começando em projetos que envolvem iniciativas de processos de negócio ou iniciando o estudo de BPM.

Dúvida comum que é esclarecida em nosso curso de Modelagem de Processos de Negócio (iPE01). Constatamos que os termos diagrama, mapa e modelo de processos são utilizados, por muitas vezes, de forma errônea, como sinônimos, porém eles na verdade tem diferentes propósitos e aplicações.

Falaremos neste artigo sobre os três níveis de modelagem (diagrama, mapa e modelo), as diferenças em seus desenhos, no nível de detalhamento e utilidade de cada um.

Diagrama, mapa e modelo são três níveis de “representação” de processos.

Estes três níveis de representação de processos diferem-se em níveis de abstração, informação, utilidade, precisão, complexidade, padronização de elementos do fluxo, evolução e amadurecimento do desenho proposto.

diagrama, mapa e modelo de processos

Fazendo uma analogia com mapa geográfico, podemos dizer que o diagrama de processo demonstra a rota que é realizada em uma visão simplificada, com o trajeto percorrido, evidenciando os principais pontos de referência, o local de origem e destino. O mapa do processo apresenta a rota de forma mais detalhada, com elementos como nome de avenidas, ruas, principais pontos de referências, opções de rotas alternativas, trajeto e tempo estimado para cada rota. O modelo de processo apresenta a rota de forma mais completa e precisa, descrevendo a situação atual do trânsito, rota de transporte público, clima na região da rota, além de fotos das avenidas e ruas.

O Diagrama é uma representação inicial do processo. Ele demonstra o fluxo básico focando as principais atividades. Não trata exceções ou falhas no processo.

Utilizado para capturas rápidas no processo, por isto não é muito preciso.
Ajuda a obter entendimento rápido das principais atividades, representando ideias simples em um contexto alto nível.

Esta representação inicial do processo pode significar várias coisas. O diagrama pode representar um macroprocesso organizacional, por exemplo, como também se tratar de apenas um esboço (versão inicial do processo) de uma primeira avaliação.

diagrama de processo

Em um primeiro momento busca-se conhecer os processos identificando as atividades chave. Esta é uma das técnicas mais utilizadas para conhecer os processos organizacionais, conhecida como abordagem top-down, em uma visão de macroprocessos (visão interfuncional) até chegar aos processos operacionais.

Em uma primeira versão, o processo muitas vezes não recebe as informações necessárias para partir diretamente para um nível de mapa ou modelo. Fatores como a precisão e nível de detalhamento influenciam a forma como o processo é modelado. A precisão varia de acordo com a profundidade em que se avalia cada aspecto do processo e suas atividades, e aumenta de acordo com o número de pessoas entrevistadas das áreas que fazem parte dos processos.

O nível de detalhe define o quanto cada processo, sub-processo, atividades, tarefas, procedimentos, atributo ou aspecto é descrito.

O mapa é uma evolução do diagrama, acrescentado de atores, eventos, regras, resultados e um detalhamento do processo. Ampliada para uma visão mais detalhada, o mapa fornece informações de maior precisão do desenho do processo.

Neste nível as atividades do processo e seus objetivos estão mais claros. Foram identificadas as responsabilidades atribuídas ao longo do processo. Isto se deve aos métodos de levantamento de informações utilizadas pela equipe envolvida na iniciativa de BPM.

Através de pesquisas a equipe obteve um entendimento inicial, e segue para as entrevistas com os envolvidos no processo (donos de processos, clientes, fornecedores, pessoas que trabalham no processo, etc). Esta etapa é de grande importância para identificação das regras, validações, caminhos de exceções, papéis e detalhamento de atividades.

Existem diversos métodos para levantamento de informações, como workshops, conferências, observações diretas, etc. Abordaremos este assunto em um próximo post.

A escolha do nível de representação de processos dependerá do propósito da modelagem, em muitos casos, o diagrama ou mapa já são suficientes para representar o processo.

O modelo é a versão final da evolução do processo. Esta representação traz um alto grau de precisão e detalhamento do processo.

Uma grande vantagem é a capacidade de execução do processo através de simulações. Estas simulações geram informações que acercam o desempenho do processo, úteis para analisar/validar a execução do processo.

Este nível de execução requer uma descrição detalhada dos atributos do processo, descrevendo propriedades e características das entradas/saídas, procedimentos/passos, recursos, custos, alocação, simulação, parâmetros de duração, etc. Estes atributos podem ser classificados em categorias e sua documentação varia de acordo com o objetivo da modelagem realizada.

A partir do modelo é possível executar as próximas etapas do ciclo de gestão por processos, como a análise, redesenho, reengenharia, melhoria continua e medição do processo.

Você se interessou pelo assunto?

A área de conhecimento de modelagem de processos fornece o entendimento dos propósitos, benefícios, habilidades e técnicas e é muito utilizada pelas organizações para conhecer, documentar e melhorar processos.
Este tema é explorado com mais profundidade em nosso curso de Modelagem de Processos de Negócio, onde abordamos de forma mais abrangente o tema: http://www.iprocesseducation.com.br/ipe01.html, oferecido pela iProcess Education.

A diferença entre “desenhar” e “modelar” processos

Não basta saber usar um editor de textos para ser um bom escritor.
O mesmo se dá na relação entre uma ferramenta de modelagem e o designer de processos(1).

Pode parecer estranho começar um artigo com uma afirmativa como essa. Mas o fato é que muitas vezes já nos encontramos em conversas com pessoas envolvidas em iniciativas de processos com a expectativa que, se treinassem pessoas da empresa para usar alguma ferramenta para desenhar de processos (como o Bizagi, por exemplo), isso bastaria para que essas pessoas pudessem documentar os processos das suas áreas (e assim teriam modelados os processos da organização).

Mas criar um bom modelo de processo é como escrever um bom texto. Não basta apenas dominar o editor de textos e saber escrever as palavras, é preciso preocupar-se com a clareza do conteúdo – em como ele será interpretado por quem o lerá.

Designer de processos em ação.

O primeiro passo para uma boa escrita é conhecer e aplicar bem as regras gramaticais da linguagem usada. Uma vírgula fora do lugar pode mudar completamente o sentido de uma frase. Da mesma forma, um elemento BPMN aplicado sem a preocupação com as regras da sua especificação também pode levar a interpretações distintas dos leitores em relação à expectativa de quem fez a modelagem.

As definições da especificação BPMN funcionam como as regras gramaticais de um idioma. Se forem bem conhecidas por quem as usa podem ser relativamente fáceis de aplicar, já que são bastante claras. Elas definem como são os símbolos, como podem se conectar e o que significam.

Conhecer as regras de uso de um idioma ou de uma notação são apenas o primeiro passo para comunicar-se bem com quem lerá o produto do trabalho. As dúvidas mais frequentes geralmente estão relacionadas a como aplicá-las ao conteúdo que queremos transmitir.

Em uma história bem contada, a sequência de fatos, determinada pelo enredo, é fundamental para o seu entendimento. Em algumas situações, fatos podem ser contados em paralelo, em outros casos eles têm uma sequência que se for quebrada pode dificultar a compreensão ou mesmo gerar interpretações equivocadas.

Na modelagem de processos, a lógica do processo é o enredo. Ela se define tendo um evento que sinaliza o início da estrutura de precedência entre as atividades e regras de roteamento do fluxo, que podem apresentar cenários com sequências de atividades paralelas ou alternativas, até atingir o seu fim. É ela que determina como os elementos da notação devem ser usados para criar o diagrama do fluxo do processo. Toda a modelagem deve ter em vista garantir a integridade da lógica do processo.

Assim como a boa escrita, isto é fruto de uma habilidade desenvolvida com a prática. Esta habilidade se constrói:

  • desenhando processos,
  • tendo a sensibilidade de lê-lo sob a perspectiva do leitor,
  • validando – não apenas gramaticalmente mas também a lógica representada junto com as outras pessoas envolvidas
  • e discutindo a modelagem proposta com outros analistas, avaliando até mesmo outras alternativas de transmitir mais claramente a ideia do processo.

Esse trabalho envolve alguns cuidados que o designer de processos deve observar em suas modelagens se quiser apresentar resultados claros, objetivos e precisos na representação de processos:

  • Criar modelos limpos. Diagramas de processos devem primar pela interpretação fácil com olhar simples. Isto se obtém evitando-se desenhar linhas sobre linhas, cruzar linhas sobre as outras ou traçar conexões entre elementos muito distantes. Isso pode ser resolvido com o uso de elementos de links (mas use com parcimônia!) e alguma reorganização (avalie se as lanes onde os elementos que devem se conectar não podem ser aproximadas). Usar nomes breves e objetivos para eventos, gateways e atividades também ajudam a manter o diagrama limpo.
  • Aplicar boas práticas. Existem diversas práticas, que foram sendo agregadas por profissionais com experiência na modelagem de processos e que são recomendadas no uso da notação. Confiar nessas práticas pode facilitar o trabalho e ajudar na elaboração de diagramas eficazes na comunicação.
  • Usar a notação de forma padronizada. Padronizar a forma como usa a notação dá harmonia ao conteúdo representado, gerando conforto a quem lê e confiança de que o processo está bem modelado.
  • Modelar no grau de detalhamento apropriado. De acordo com o propósito da modelagem do processo, o diagrama requer uma representação em maior ou menor nível de detalhe. Algumas situações requerem um processo desenhado numa perspectiva superficial, suficiente para dar entendimento ao negócio, enquanto outras requerem detalhamento no nível de atividade da operação, ou mais além, em que todas as exceções do processo sejam previstas e tratadas. Compreender o grau de detalhamento esperado – e mantê-lo no decorrer de todo o fluxo modelado -, é um cuidado fundamental.

Encontre uma pessoa com habilidades de compreensão gramatical e boa escrita e você terá nela um excelente profissional para modelar seus processos. Desenvolva estas habilidades e você será esta pessoa.

_____
(1) De acordo com BPM CBOK v3 em português, “Designer de Processos” é o papel realizado por um membro da equipe de modelagem de processos cujo trabalho é desenhar novos processos e transformar processos de negócio. Tipicamente possui habilidades analíticas, criativas e de descrição visual e lógica dos passos de processos e na forma de organização do trabalho. Não é uma função, mas um papel, que pode ser realizado por um profissional específico ou mesmo pelo analista de processos ou de negócios.

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.

BPMN: Uma atividade para mais de um participante do processo

Há uma questão recorrente na modelagem de processos relacionada à distribuição de atividades nas lanes de processo: como representar um trabalho sendo realizado por mais de uma pessoa?

Por exemplo:
Digamos que em um processo há uma reunião realizada entre o Diretor de Planejamento e o Diretor Financeiro, que recebem uma proposta de um analista e realizam uma reunião para avaliar sobre o investimento. A seguir, eles atuam na priorização das ações relacionadas ao investimento, e a partir desta priorização são realizadas outras ações.

Para essa situação em que há dois participantes envolvidos na realização de uma mesma tarefa, já vimos diagramas que tentam representar isso de algumas formas peculiares:

"Tentei demonstrar que as atividades são realizadas pelos dois usuários posicionando-as sobre o limite entre as duas lanes."

A abordagem acima é inadequada sob o ponto de vista de uso da notação BPMN e poderá gerar interpretações diferentes. Para a notação, uma atividade só pode estar associada a uma raia (lane), e mesmo que a ferramenta de criação do diagrama não aponte o problema na validação do processo, o fato é que internamente as atividades estão vinculadas a apenas uma lane. Isto está estabelecido na própria especificação da notação. Se a ferramenta utilizada dispõe de geração de relatório que lista quais tarefas estão relacionadas a quais lanes, essas tarefas só estarão associadas a um único participante.
Tem um outro problema ao se praticar o mapeamento desta forma: e se os investimentos tivessem que envolver também o Diretor de Tecnologia – como colocar as tarefas compartilhando pessoas de três raias?

Outra tentativa comum é a refletida no exemplo abaixo:

"Coloquei as tarefas em paralelo porque eles fazem a reunião ao mesmo tempo."

No diagrama acima, as regras de validação lógica do uso da notação também não apontariam problema, mas o processo ainda não estaria corretamente representado.

A interpretação que se deve ter no uso do gateway paralelo não é de que as atividades paralelizadas serão realizadas ao mesmo tempo, e sim que elas podem ser feitas em paralelo porque não há restrição de dependência entre elas. Assim, apesar de serem iguais no exemplo acima, cada tarefa tem sua execução própria, levando ao entendimento que cada um fará as atividades quando tiver disponibilidade. Por exemplo: digamos que o Diretor de Investimentos faça “Avaliar investimento” pela manhã e já siga para a próxima tarefa, enquanto o Diretor Financeiro só consiga iniciar a tarefa “Avaliar investimento” à tarde. O processo mapeado acima permite essa interpretação.

Se a ideia é de que os dois realizem juntos a tarefa “Avaliar investimento” e “Priorizar etapas do investimento”, recomendamos uma forma de mapear isto um pouco diferente:

Uma raia com um papel em grupo que abstrai os participantes e garante que as tarefas sejam realizadas em conjunto pelos envolvidos.

Nesta abordagem, criamos uma raia para um papel que abstrai um grupo (o  “Comitê de Avaliação de Investimentos”), e atribuímos as atividades a ela. Na descrição da raia, ficam estabelecidas as regras usadas para definir quem são os participantes do comitê – que neste caso será formado pelos Diretores de Investimentos e Financeiro. Esta abordagem ainda possibilita que outros diretores possam se juntar ao comitê sem impactar no diagrama do processo, bastando apenas ajustar a descrição dos participantes do grupo.

Definindo o Escopo de Modelagem de um Processo de negócio

Uma definição essencial no início de um projeto de modelagem é o escopo do processo que será modelado. A definição clara dos limites em que será trabalhado o processo é um fator chave para a realização de qualquer projeto de modelagem.

Tomando como exemplo um processo de venda de uma fábrica de móveis: num primeiro momento, poderíamos imaginar que o escopo de um processo desta natureza  inicia com a chegada do cliente na loja e termina com o pagamento:

Contudo, extrapolando um pouco as atividades que se seguem ao pagamento, poderíamos questionar se não deveriam também estar contempladas as etapas de:

  • Entrega dos móveis;
  • Montagem, quando necessário;
  • Acompanhamento dos pagamentos parcelados; ou
  • Acompanhamento da garantia.

Onde efetivamente deveria começar e finalizar este processo?
Não existe uma resposta certa para esta pergunta, pois o escopo de um projeto de modelagem depende de diversos fatores, estando entre eles:

1. Os Resultados esperados do projeto: A motivação inicial pela realização do projeto é um fator primordial na definição do seu escopo. No exemplo acima, a modelagem pode ter sido demandada pela equipe comercial que tem como meta abrir mais 50 lojas nos próximos 12 meses e que precisa, portanto, unificar o processo de atendimento. Ou por uma necessidade desta mesma equipe em unificar o atendimento das suas lojas, tendo em vista que algumas unidades possuem um desempenho espetacular e em outras deixam muito a desejar. Nestes casos, a primeira versão do processo atende as expectativas.
Porém, digamos que a motivação seja garantir a melhor experiência de atendimento ao cliente. Neste caso, a empresa pode estar preocupada com o fato que o atendimento fora da loja, nas etapas de transporte e montagem, são os momentos em que ela menos tem condições de garantir a sua qualidade, criando assim uma necessidade de maior gestão e controle.

2. A Equipe envolvida no projeto: A modelagem de processos é uma atividade de natureza interfuncional que necessita para o seu sucesso da cooperação de todas as áreas envolvidas no processo. Desta forma, a amplitude do escopo da modelagem deve ser norteada também pelas áreas que estão engajadas no projeto de modelagem. A ampliação do escopo exigirá a sensibilização das novas áreas de negócio que serão afetadas.

3. As Expectativas de Prazo e Custos do Projeto: As variáveis clássicas de custo, prazo e escopo estão interligadas desde a concepção do projeto, e a mudança em uma delas tende a gerar reflexos nas demais. Desta forma, a reflexão sobre o escopo do processo deve levar em conta as expectativas de prazos e custos previstos para o projeto, de modo a garantir que a alteração não impactará a sua viabilidade.

Respeitando estes quesitos, podemos avaliar se determinadas partes do processo, devido às suas características, não poderiam ser modeladas separadamente. São exemplos destas situações as etapas de um processo que:

  • Aparentam ser mais independentes em relação a outras. Etapas com estas características costumam tem um bom nível de desacoplamento do restante. Por exemplo, uma etapa final de pesquisa de satisfação do cliente tende a ser a menos acoplada ao processo do que a etapa de pagamento, e poderia ser analisada separadamente.
  • Se repetem em outros processos. Por exemplo, o serviço de transportes pode ser necessário tanto num processo de venda como num processo de manutenção ou devolução do móvel adquirido.
  • São claramente de apoio, sem visibilidade para o cliente final.
  • Não podem retroagir a um ponto anterior do mesmo processo. Por exemplo, no nosso processo de vendas, não é razoável pensarmos que no momento em que o cliente está recebendo o montador do seu móvel ele possa voltar para a etapa de cadastro realizada antes da compra. Isso demonstra que a etapa de montagem e a etapa de cadastro possuem uma certa independência que permite que elas sejam analisadas separadamente.

Neste momento, algumas perguntas chaves muito comuns no início de um projeto de modelagem também podem ser fundamentais para definirmos o escopo mínimo e máximo de um processo, tais como:

  • Quem é o cliente do processo? Ele será atendido com o escopo que está sendo proposto?
  • Quem são os seus fornecedores? No escopo proposto eles interagirão com o processo?
  • Quais são as entradas e saídas do processo? As entradas previstas serão utilizadas no escopo proposto? Este escopo entregará as saídas esperadas?
  • Quais são os indicadores principais? No escopo proposto estes indicadores poderão ser medidos?

Finalmente, é importante que o escopo previsto para o projeto contemple alguns cuidados de modo a evitar que o mesmo não se limite a um escopo tão pequeno que não seja contributivo ou tão grande que se torne inviável. Desta forma, sugerimos sempre uma dose de atenção para que:

  • O processo não se limite a uma só área ou departamento, ou seja, preserve suas características interfuncionais. Processos departamentais tendem a não apresentar todos os benefícios da gestão por processos como aqueles transversais à organização.
  • Se evitem projetos que exigem 6, 10 ou 12 meses de trabalho. Projetos desta amplitude tende a já ter o seu resultado desatualizado ao seu final, além de gerar desmotivação devido a demora na entrega dos seus resultados.
  • No caso do processo ser muito extenso, seja verificada a possibilidade de que o seu escopo seja dividido em dois ou mais projetos, de modo a garantir entregas frequentes.
  • Se lembre que, quanto maior o escopo, mais complexa a sua gestão.
  • Se esteja, contudo, sempre atento para evitar que uma divisão excessiva que sacrifique a visão ponta a ponta do processo.

Finalizando, não podemos deixar de ressaltar que, tão importante quanto à definição do escopo é que estes limites fiquem sempre muito claros para os stakeholders e para as áreas de negócio. A falta de clareza sobre o escopo a ser trabalhado tende a gerar desmotivação e retrabalho nas reuniões de levantamento do processo.

Se você quiser saber um pouco mais sobre este assunto, conheça o nosso curso de modelagem de processo, http://www.iprocesseducation.com.br/ipe01.html, oferecido pela iProcess Education.

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.