Escritório de Processos TI e Competitividade

O MEPP - Mito do Elo Perdido de Processos

11 de Agosto de 2008 às 00:57 Rafael Bortolini  | Enviar por e-mail Hits para esta publicação: 571

 

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.

Publicação arquivada em: Estratégia e gestão, BPM, BPMN, BPEL, Modelagem de processos

Enviar por e-mail | Hits para esta publicação: 572

4 Comentários Faça seu próprio

  • 1. Fagner Vieira  |  11 de Agosto de 2008 às 09:31

    Olá Rafael, muito bom teu texto principalmente porque nos faz refletir a respeito de nossa própria exitência enquanto área de BPM.
    Apenas para constar que o MEPP, no modelo Toyota, por exemplo, é relacionado como “fluxo falso” de processos. E isso de fato ocorre, por isso, não menos importante, é termos uma metodologia que identifique defeitos e nos possibilite resolver os problemas antes que algo de errado se repita. Atribuimos isso ao processo de melhoria contínua.

    Um abraço!

    Fagner Vieira
    Gestão de Processos
    Universidade de Passo Fundo

  • 2. Helio Pereira  |  12 de Agosto de 2008 às 19:31

    Rafael, este teu post está brilhante! Vou divulgar pois o POVO PRECISA ouvir isso!!!!

  • 3. Liliane Cristina Rodrigues  |  20 de Agosto de 2008 às 15:42

    Olá Rafael,

    Ótimo mesmo o seu texto acima.
    Incrível a importância do objetivo estar MUITO claro desde o início do projeto.

    Abraços,
    Liliane

  • 4. Romeu Flores  |  15 de Setembro de 2008 às 12:06

    Perfeito esse post. Estou traduzindo pro inglês para meus colegas aqui na Inglaterra.

    Estive em contato com analistas de negócio e a tendência deles é desenhar processos de maneira mais detalhada. É comum vermos atividades de uma pessoa para ela própria.

    No meu entender, os processos que devem ser modelados em um BPMS devem ser de maior granularidade, evitando-se atividades de uma pessoa para ela própria. Assim:
    -cliente realiza compra (aqui estão incluídas todas as interações que um cliente pode ter tido num web site por exemplo).
    -setor de compra processa pedido (pega no estoque, imprime nota fiscal e etiqueta de endereço, anexa a nota e cola a etiqueta no pacote e coloca na área de transporte);
    -transportadora entrega o pedido (pega o pedido da área de transporte e entrega).

    BPM é “catch the ball throw the ball”: pegue a bola e passe… Vc não vai ficar passando a bola pra você mesmo. E esse é o grande pulo do gato: (re) estruturar processos de maneira que cada pessoa envolvida realize atividades pontuais, reduzindo as idas e vindas. No fim você terá uma organização otimizada.

    No entanto, cheguei à conclusão que os analistas de negócio não sentem que BPMN seja adequado para definir seus processos. Eles precisam de uma ferramenta para melhor definir seus requisitos (ex: não basta dizer que o setor de compra vai processar o pedido - em algum lugar eu tenho que dizer que a nota fiscal tem que ser anexada).

    Ainda há um buraco a fechar entre TI e negócios.

Deixe um Comentário

Requerido

Requerido,escondido

Linkar esta publicação  |  Assine os comentários via o RSS


Calendário

Agosto 2008
S T Q Q S S D
« Jul   Set »
 123
45678910
11121314151617
18192021222324
25262728293031

Minhas Publicações Recentes

Publicações por Mês

Meta