Por Maurício A. Santos, ProcessMind
A pergunta pode até parecer um pouco estranha, mas considero que é uma das mais importantes ao se iniciar um trabalho de análise de processos. É comum encontrarmos documentação detalhada de um processo mas que, na prática, continua com diversos problemas de padronização, falta de controle, gargalos, retrabalhos etc etc etc. Muitas vezes é mais crítico termos um bom plano de ação para implementação de melhorias no processo do que ter sua documentação detalhada até o nível de atividades e tarefas.
Não que o mapeamento de um processo não seja importante, mas antes de se começar a análise do processo devemos fazer algumas perguntas como:
- Qual o objetivo do mapeamento?
- O que eu espero ao final do mapeamento?
- Como a documentação será utilizada?
- Quem é o cliente do trabalho de mapeamento e o que ele deseja?
Algumas respostas e o conseqüente nível de detalhamento necessário dos processos que encontramos em nossos trabalhos são os seguintes:
1. Objetivo = Implantar melhorias e controlar o desempenho do processo
Neste caso, um bom mapeamento gerencial do processo é suficiente, procurando identificar quem são os clientes do processo, quais suas necessidades e como está o desempenho do processo. Algumas reuniões com os usuários são suficientes para se levantar as oportunidades para melhorar o processo, bem como quais devem ser os indicadores necessários para medir o desempenho do processo. Dedica-se então maior tempo no detalhamento dos planos de ação para implementar estas melhorias. Os fluxos de atividades, neste caso, não são necessários ao trabalho.
2. Objetivo = Definir responsabilidades no processo e as interfaces entre os participantes
Neste caso, já será necessário entender as regras de trabalho e de execução do processo. É necessário, entretanto, desenhar uma visão macro do fluxo de atividades do processo (sem muitos detalhes), a fim de identificar quando e quais informações são passadas de um participante para o próximo. Porém, não é necessário detalhar estas atividades (em tarefas), o que só vai fazer o trabalho demorar mais para acabar e os resultados serão os mesmos no final.
3. Objetivo = Automatizar o processo e implementar ferramenta de BPMS
Neste caso, o nível de detalhamento deverá ser bem maior, principalmente para se levantar todos os dados do processo, bem como as regras para execução de cada atividade. Quase sempre, porém, não será necessário mapear as tarefas do processo, pois o BPMS será utilizado somente para automatizar as atividades.
4. Objetivo = Treinar novos usuários e/ou escrever instruções de trabalho
Neste caso sim, será necessário descer o nível de detalhamento do processo o máximo possível, para que a documentação gerada seja uma eficiente ferramenta de treinamento das pessoas. Este nível de detalhamento é comum para processos mais operacionais, com alta repetição, nos quais a padronização é essencial para se garantir a qualidade do trabalho.
Outros exemplos podem ser dados a cada projeto que participamos. O importante é ter consciência de que não adianta sair elaborando extensa documentação do processo (AS IS e TO BE) em todo e qualquer projeto de análise de processos, sob o risco de se gastar tempo e dinheiro e não alcançar os resultados esperados. Infelizmente, vemos isso acontecer com freqüência, o que acaba inviabilizando até a continuidade do trabalho de processos nas empresas.
Lembre-se: o que se procura normalmente é a melhoria do processo e não sua documentação!!!
Bom trabalho.
Junho 10, 2008 às 2:28 pm
Quando você cita BPMS, você está se referindo às SUITES de BPM?
Você está relacionando o processo mapeado a uma execução on line das atividades através de um WorkFlow?
Junho 11, 2008 às 3:38 pm
Boa tarde
Mauricio, realmente é um tema muito polêmico esse.
Uma dúvida, para se entender e propor melhorias e encontrar gargalos, temos que descer em algumas atividades até o nivél das tarefas, independente se for no itens 1, 2 ou 3 citamos acima, correto isso ?
Atenciosamente
Junho 16, 2008 às 4:12 pm
Ola pessoal,
Obrigado pelos comentários.
Rafael, em relação ao BPMS (business process management systems) me refiro sim às suites de BPM, que é uma evolução dos tradicionais sistemas de workflow, com novas funcionalidades incorporadas como às de integração de sistemas. Assim, ao automatizarmos um processo, conseguimos exatamente o que você colocou: controlar a execução on-line das atividades do processo
Roberta,
Realmente pode ser preciso descer até o nível de tarefas para se encontrar oportunidades de melhoria, como você disse. Porém, na minha experiência, acho que é possível encontrar estas oportunidades de melhoria em reuniões com os usuários, sem que se tenha que mapear o processo até o último nível. O que eu defendo neste post é que muitas vezes “perdemos” muito tempo na formalização do processo até o nível de tarefa, quando deveríamos estar nos dedicando a planejar e implantar as melhorias.
Agosto 26, 2008 às 11:32 am
Mauricio vc crê que podemos implementar algo sem que esteja descrito? algo somente verbal?
Setembro 12, 2008 às 2:11 pm
Que pergunta interessante Joana!
No limite, talvez até seja possível implementar um processo sem descrevê-lo. Desde que, a meu ver, tenha havido uma grande interação com os usuários do processo em reuniões de análise. Porém, se o processo envolver muitos papéis, o mínimo de mapeamento deverá ser formalizado para facilitar a divulgação e o treinamento das pessoas.
De qualquer forma, como coloquei no item 1, depois será importante a gestão da implantação das melhorias no processo e a medição dos seus indicadores de desempenho.
Um abraço,
Fevereiro 11, 2009 às 2:55 pm
Olá Maurício,
Ao final de seu artigo você diz
“Lembre-se: o que se procura normalmente é a melhoria do processo e não sua documentação!!!” em referência a projetos que detalham demais o AS IS e o TO BE… com isso acabam por inviabilizar a continuidade do projeto… Em parte eu concordo, uma vez que o AS IS será águas passadas ao final da implementação das melhoriias. Por outro lado, vejo como um dos pricipais fatores de sucesso da continuidade do projeto a documentação completa do TO BE, uma vez que se torna uma ferramenta essencial na divulgação dos processos aos atores. também vejo importância nas futuras medições de indicadores e a melhoria constante dos processos. Pois nesta fase teremos o AS IS pronto (antigo TO BE), facilitando então as alterações e melhorias.
O que pensa à respeito?
Fevereiro 12, 2009 às 8:03 am
Ola Fernando,
Realmente, você tem razão: o TO BE de hoje será o AS IS de amanhã e, além disso, a documentação do processos é uma importante ferramenta de treinamendo das pessoas envolvidas.
Por isso, a documentação do TO BE é importante e precisa ser feita sempre. Porém, o que eu defendo é que nem sempre ela precisa ser extensa. Por exemplo, muitas vezes nós nem chegamos a desenhar um único fluxo de atividades do processo. Nós apenas documentamos o que chamamos na ProcessMind de “Mapa Operacional do Processo”, definindo gestor, objetivo, entradas, saídas, clientes, indicadores de desempenho e oportunidades de melhoria para o processo, entre outras informações. Este documento é suficiente para implantar o processo, treinar as pessoas e manter a documentação atualizada.
É até paradoxal, mas na minha opinião o fluxo de atividades às vezes até confunde o usuário, que não entende aquele monte de caixinhas com flexinhas. Mas depende de empresa para empresa.
Espero ter esclarecido. Um abraço,