Você já ouviu ou já falou - alguma das seguintes frases:
“- Tenho meus processos mapeados no Visio. O seu BPMS importa de lá para executá-los?”
“- Será muito simples. É só clicar em um botão no Aris e BUM!!, meus processos serão executados no BPMS”
“- Vai ser fácil o projeto. Ano passado uma consultoria mapeou os nossos processos, está 50% pronto.”
“- Não quero retrabalho. Não quero ter que desenhar de novo os meus processos só para automatizar”
“- Quero uma ferramenta onde o usuário desenhe em BPMN e depois a TI só execute o BPEL gerado sem trabalho”
Eu ouço isso praticamente todo o dia. Essas questões, de um jeito ou de outro, refletem uma ansiedade comum em relação a existência do que chamo de “mito do elo perdido de processos”. Como venho da área de TI, que gosta de colocar siglas em tudo, vou chamar amistosamente de “MEPP“.
Assim como os evolucionistas procuram em vão a séculos o elo perdido entre os macacos e os homens, o MEPP representa a busca sem fundamento do elo direto entre o mapa do processo de negócio e a sua execução, ou o processo automatizado. Explico.
Mapear (desenhar) um processo é um meio, e não um fim. Isso está mais que provado e discutido. Antes de iniciar o desenho de um processo, ou mesmo uma iniciativa de processos, tenho que me perguntar: “OK, processos. Mas para quê quero processos? Qual é o objetivo do meu desenho, do meu mapeamento, da minha modelagem?”. Algumas respostas poderiam ser, entre outras:
- Para entender melhor como minha empresa funciona e descobrir gargalos;
- Para entender melhor porque esse processo leva tanto tempo e melhorá-lo;
- Para otimizar o fluxo de informações e pessoas envolvidas no processo;
- Para gerar uma documentação completa de modo que um funcionário novo seja facilmente treinado;
- Para obter a certificação X, Y ou Z;
- Para selecionar e customizar um ERP;
- Para automatizar em um BPMS;
- etc…
O fato é que, dependendo do objetivo selecionado, o analista de processos deve adaptar sua ferramenta - o mapa do processo - para um maior ou menor nível de detalhe. Dependendo do objetivo, determinadas interações deverão ser contempladas ou não. Você já se deparou com a questão “será que junto essas duas atividades em uma só no meu mapa” ou mesmo “o que representa uma atividade?”. A resposta para tudo sempre será: depende do seu objetivo.
Isso significa que o seu processo de compras, por exemplo, pode ser desenhado de 10 maneiras diferentes, e todas podem estar certas. Vai depender do objetivo. Arrisco dizer que, mesmo seguindo o mesmo objetivo, duas pessoas podem desenhá-lo diferente, e ainda assim as versões estarem corretas. Um dia vou fazer esse teste.
Vamos a um exemplo prático. Veja o fluxo abaixo:
Simples, não? Tão simples que nem precisa de explicação. Agora imagine utilizarmos o botão mágico para extraordinariamente automatizá-lo no BPMS, usando o conceito de MEPP. Sabe o que irá ocorrer? Isso:
1. Seu João, responsável pelo setor de entregas, recebe uma tarefa no BPMS dizendo pra ele pegar uma televisão 21 polegadas de código XY1234 no estoque;
2. Seu João pega a TV, volta ao computador e avisa ao BPMS que terminou a atividade;
3. Imediatamente o BPMS avisa seu João que agora ele deve imprimir e anexar a nota fiscal de transporte na caixa da TV;
4. Seu João, um cara obediente, faz exatamente o que o BPMS manda e depois de anexar a NF, orgulhosamente avisa o BPMS que concluiu no prazo a atividade;
5. O BPMS lembra Seu João que ele tem que levar a TV para dentro do caminhão;
6. Seu João coloca a TV dentro do caminhão e volta feliz ao computador, avisando ao BPMS que concluiu com sucesso a operação!
E isso ocorre para todos os produtos que a empresa vende em um dia.
Rídiculo, não? Apesar de o mapa do processo estar correto e coerente com o negócio, e talvez coerente com um objetivo de “entendimento ou treinamento no processo”, obviamente esse mapa não serve de nada para a automação. Parece simples vendo isso agora, mas muitas vezes no meio de um grande processo isso passa despercebido.
O problema é que, ao final, existem dezenas de incoerências como essa em um processo desenhado, e a ligação entre os dois modelos é exatamente o elo perdido, ou MEPP, dos processos - algo que nunca existiu.
Fornecedores vendem softwares com botões mágicos que transformam o “modelo de negócio” para o “modelo de automação”. Clientes não querem retrabalho de tirar o seu processo da ferramenta de mapeamento para a ferramenta de execução; querem que isso seja automático.
Conhece a fábula da fome e da vontade de comer? Você acredita que exista software tão inteligente a ponto de automaticamente compreender a semântica do processo - ou seja, o que ele significa - e magicamente convertê-lo para um modelo executável? Não existe.
Por isso a pergunta “o BPMS importa meus processos do Visio ou do Aris?” na grande maioria das vezes é irrelevante frente a diferença semântica entre o processo originalmente desenhado e o processo a ser executado. A não ser, é claro, que o processo tenha sido, desde o princípio, desenhado para o fim de automação.
Então terei retrabalho de desenhar de novo, só que dessa vez diferente, os meus processos? Sim, terás. A questão é como você irá abordar isso. Em minhas experiências observei que esse é um trabalho 50% braçal, 30% seguir regras e 20% pensar. Cabe a você decidir se irá fazer isso por si mesmo ou irá passar para outra pessoa fazer - alguém que tenha mais tempo livre e custo (valor-hora) inferior ao seu.
(Rafael Bortolini)
“- Tenho meus processos mapeados no Visio. O seu BPMS importa de lá para executá-los?”
“- Será muito simples. É só clicar em um botão no Aris e BUM!!, meus processos serão executados no BPMS”
“- Vai ser fácil o projeto. Ano passado uma consultoria mapeou os nossos processos, está 50% pronto.”
“- Não quero retrabalho. Não quero ter que desenhar de novo os meus processos só para automatizar”
“- Quero uma ferramenta onde o usuário desenhe em BPMN e depois a TI só execute o BPEL gerado sem trabalho”
Eu ouço isso praticamente todo o dia. Essas questões, de um jeito ou de outro, refletem uma ansiedade comum em relação a existência do que chamo de “mito do elo perdido de processos”. Como venho da área de TI, que gosta de colocar siglas em tudo, vou chamar amistosamente de “MEPP“.
Assim como os evolucionistas procuram em vão a séculos o elo perdido entre os macacos e os homens, o MEPP representa a busca sem fundamento do elo direto entre o mapa do processo de negócio e a sua execução, ou o processo automatizado. Explico.
Mapear (desenhar) um processo é um meio, e não um fim. Isso está mais que provado e discutido. Antes de iniciar o desenho de um processo, ou mesmo uma iniciativa de processos, tenho que me perguntar: “OK, processos. Mas para quê quero processos? Qual é o objetivo do meu desenho, do meu mapeamento, da minha modelagem?”. Algumas respostas poderiam ser, entre outras:
- Para entender melhor como minha empresa funciona e descobrir gargalos;
- Para entender melhor porque esse processo leva tanto tempo e melhorá-lo;
- Para otimizar o fluxo de informações e pessoas envolvidas no processo;
- Para gerar uma documentação completa de modo que um funcionário novo seja facilmente treinado;
- Para obter a certificação X, Y ou Z;
- Para selecionar e customizar um ERP;
- Para automatizar em um BPMS;
- etc…
O fato é que, dependendo do objetivo selecionado, o analista de processos deve adaptar sua ferramenta - o mapa do processo - para um maior ou menor nível de detalhe. Dependendo do objetivo, determinadas interações deverão ser contempladas ou não. Você já se deparou com a questão “será que junto essas duas atividades em uma só no meu mapa” ou mesmo “o que representa uma atividade?”. A resposta para tudo sempre será: depende do seu objetivo.
Isso significa que o seu processo de compras, por exemplo, pode ser desenhado de 10 maneiras diferentes, e todas podem estar certas. Vai depender do objetivo. Arrisco dizer que, mesmo seguindo o mesmo objetivo, duas pessoas podem desenhá-lo diferente, e ainda assim as versões estarem corretas. Um dia vou fazer esse teste.
Vamos a um exemplo prático. Veja o fluxo abaixo:
Simples, não? Tão simples que nem precisa de explicação. Agora imagine utilizarmos o botão mágico para extraordinariamente automatizá-lo no BPMS, usando o conceito de MEPP. Sabe o que irá ocorrer? Isso:
1. Seu João, responsável pelo setor de entregas, recebe uma tarefa no BPMS dizendo pra ele pegar uma televisão 21 polegadas de código XY1234 no estoque;
2. Seu João pega a TV, volta ao computador e avisa ao BPMS que terminou a atividade;
3. Imediatamente o BPMS avisa seu João que agora ele deve imprimir e anexar a nota fiscal de transporte na caixa da TV;
4. Seu João, um cara obediente, faz exatamente o que o BPMS manda e depois de anexar a NF, orgulhosamente avisa o BPMS que concluiu no prazo a atividade;
5. O BPMS lembra Seu João que ele tem que levar a TV para dentro do caminhão;
6. Seu João coloca a TV dentro do caminhão e volta feliz ao computador, avisando ao BPMS que concluiu com sucesso a operação!
E isso ocorre para todos os produtos que a empresa vende em um dia.
Rídiculo, não? Apesar de o mapa do processo estar correto e coerente com o negócio, e talvez coerente com um objetivo de “entendimento ou treinamento no processo”, obviamente esse mapa não serve de nada para a automação. Parece simples vendo isso agora, mas muitas vezes no meio de um grande processo isso passa despercebido.
O problema é que, ao final, existem dezenas de incoerências como essa em um processo desenhado, e a ligação entre os dois modelos é exatamente o elo perdido, ou MEPP, dos processos - algo que nunca existiu.
Fornecedores vendem softwares com botões mágicos que transformam o “modelo de negócio” para o “modelo de automação”. Clientes não querem retrabalho de tirar o seu processo da ferramenta de mapeamento para a ferramenta de execução; querem que isso seja automático.
Conhece a fábula da fome e da vontade de comer? Você acredita que exista software tão inteligente a ponto de automaticamente compreender a semântica do processo - ou seja, o que ele significa - e magicamente convertê-lo para um modelo executável? Não existe.
Por isso a pergunta “o BPMS importa meus processos do Visio ou do Aris?” na grande maioria das vezes é irrelevante frente a diferença semântica entre o processo originalmente desenhado e o processo a ser executado. A não ser, é claro, que o processo tenha sido, desde o princípio, desenhado para o fim de automação.
Então terei retrabalho de desenhar de novo, só que dessa vez diferente, os meus processos? Sim, terás. A questão é como você irá abordar isso. Em minhas experiências observei que esse é um trabalho 50% braçal, 30% seguir regras e 20% pensar. Cabe a você decidir se irá fazer isso por si mesmo ou irá passar para outra pessoa fazer - alguém que tenha mais tempo livre e custo (valor-hora) inferior ao seu.
(Rafael Bortolini)
No Response to "Mito do Elo Perdido de Processos"
Postar um comentário