What is the process mapping notation you use most and what you consider most appropriate?

With the advent of BPMN and integration in BPM suites I’ve seen a lot of discussion about the best standard for process mapping.

Vendors (except ARIS that supports EPC) have embed BPMN and BPEL for obvious reasons once it provides automatic process automation.

BPMN was presented as the process standard of the future because for the first time it could represent the participants in the processes, tasks, events and information flow. However, and contrary to process management methods that converged to the same concepts (Discovery, Analysis, Implementation, Monitoring and Improvement), the business process representation reached near chaos.

Companies that began their efforts in managing business processes in the last 10 years, used different trends, various notations and as result now is somewhat very mixed up. Process participants use process documentation or process representation pictured that tastes different. Some people understand task sequence and business rules that could cause bad process performance. Companies that began to structure business processes recently use the flavor of the year (EPC, Swimlane, etc.) and now don’t know what to do if is necessary to move to BPMN. On the other hand, when process improvement teams gather AS IS information sometimes they must rewrite or have to lose some time interpreting those dissimilar sketches (sounds familiar hum?).

Due to its complexity BPMN requires to qualify people to understand their contents. That is relearn how to draw and interpret processes (let's start all over again) some people will never make it. Lately, in various discussion forums I have noticed that still there is mapping and process improvement made on a brown paper with a marker and post-it glued with very good results, or using simple flow charts as before (this is typical in shopfloors process improvement workshops).

Half a year ago I completed an upgrade in an ERP system and used BPMN. The work was successful because people responsible for ERP implementation understood perfectly what changes were to be introduced (they were IT guys). When I tried to pass the changes to the people that were going to work with the system using the BPMN flows things stalled. I have convert everything to simple process flow notation.

There is a lot of debate about the adoption of BPMN and bearing in mind that version 2.0 is coming what is your opinion about the best notation for mapping business processes?

Comentários

G disse…
I think all processes should now be described with BPMN. It is the standard we have and the beauty of BPMN is that is can be used very simply - that was one of its key design features.
I am sure all business people can understand BPMN in its very simplest form.
We have produced a Content Module to better present process information to users in Word using standard templates if you are interested - please see http://www.activemodeler.com/avantageContentManagement

Best regards
Geoffrey Long
glong@kaisha-tec.com
Anónimo disse…
Embora esta não seja a primeira vez que escuto o argumento de que o BPMN é excessivamente complexo e difícil de entender pelos não-especialistas, eu discordo.

Na minha opinião, o BPMN tem como uma de suas principais vantagens a sua extrema facilidade de leitura. Costumo brincar com meus alunos e clientes dizendo que o BPMN nada mais é do que "um fluxograma metido a besta", o que, aliás, é exatamente o que ele é. A notação básica do BPMN (atividades como retângulos, decisões como losangos e círculos como eventos) é antiqüíssima (== fluxograma) e conhecida por virtualmente todo mundo. Em geral, não preciso de mais de 10 minutos para explicar a notação para novos "leitores", e eles sempre compreendem perfeitamente.

É claro que, para que isso seja possível, é necessário respeitar a curva de aprendizagem das pessoas. Não tem sentido despejar diagramas com a notação full logo de cara. O ideal é ir preenchendo as lacunas aos poucos. Eu começo com os itens básicos acima e mais uma pequena coleção de tipos de eventos (message e timer, normalmente) e os forks AND e OR e swimlanes / pools (esses últimos parecem ser incrivelmente intuitivos para todo mundo). Via Pareto, é fácil verificar que isso é capaz de representar mais de 80% das situações normais nas empresas. Conforme o tempo passa, é possível ir acrescentando mais sintaxe e semântica e cobrindo os casos mais complexos.
Anónimo disse…
Ele me faz lembrar as famosas e antigas réguas plásticas de cor verde de Diagrama de Bloco da IBM.
Anónimo disse…
minha opinião é que o EPC ainda é o melhor método pra representar processos de um modo geral. É claro que, no fundo, a melhor notação depende do objetivo da modelagem. Para desenvolvimento de sistemas / automação, acho que o BPMN equilibra ou até supera (ainda bem, pq, afinal, foi criado pra isso por patrocinadores que estavam interessados nisso etc.). No mais, acho que BPMN ainda tem pontos fracos relevantes que me fazem relutar em usá-la. Em particular:

1) O fato de modelar processos em 'lanes' previamente estabelecidas funcionaliza a visão por processos, não permite que você enxergue o processo independentemente da organização do trabalho. Acho esse o 'defeito' mais grave, apesar de sutil. É um problema quase pedagógico.

2) Os message flows são uma boa sacada, mas aumentam a complexidade do modelo se forem exaustivos (e precisam ser), fazendo com que, por exemplo, o princípio da clareza seja violado e o modelo de processos perca uma parte importante da utilidade (a menos para o objetivo único de automação já citado).

3) O foco em automação induz o modelador a confundir fluxo de atividades com fluxo de informação. Um erro conceitual meio básico, mas muito comum.

4) A limitação de tipos de objetos e modelos para outras finalidades que não a automação (já mencionado neste fórum etc.) e relacionado às anteriores.

E outros. Enfim, é só minha opinião. Como docente (Eng. Produção / UFRJ), me obrigo a apresentar ambas para os alunos da diciplina de EPN, os faço praticar com EPC no laboratório, mas dou liberdade para usar qualquer notação em seus trabalhos de campo, muitos usam BPMN, EPC. Poucos IDEF e outras.

Sobre o aprendizado, tendo a concordar com os argumentos do artigo do Recker e Dreilling de 2007 (ref. a seguir), que concluem que não importa muito com que notação você aprende, no fim, você se habilita a aplicar todas, bastando vencer uma pequena curva de aprendizado acerca dos objetos e relações possíveis (além da operação da ferramenta, é claro). Acho que é por isso que o pessoal das 'réguas plásticas' (hein, Rui?) tem facilidade de modelar em qualquer notação.
Anónimo disse…
RECKER, J., DREILING, 'Does It Matter Which Process Modelling Language We Teach or Use? An Experimental Study on Understanding Process Modelling Languages without Formal Education', Proceedings of 18th Australasian Conference on Information Systems Understand Process Modelling Languages, Toowoomba, 2007.
Anónimo disse…
Mas coloco outra questão: será que houve tanta evolução assim? Por conta de notações, tenho certeza que não, não há nada "revolucionário", e o "evolucionário" foi tão pequeno para tantos anos desde as "réguas verdes", os IDEFs, etc... Em termos de software, me perdoem os fabricantes, mas também não vejo tanta evolução assim.... Lembro do Process (não me lembro o fabricante) que em 1989 já fazia até simulação gráfica e se você errasse no fluxograma os bonequinhos ou os carrinhos ficavam "batendo cabeça".... o que é isso senão Fayol, Ford, Taylor, Weber... quem era de logística nesta época deve lembrar do case da Volkswagen.... que funciona até hoje em várias fábricas e depois todas as outras copiaram... Just-in-Time da BMW...

Em ferramentas talvez a maior evolução tenha sido no acesso: por incrível que pareça tá mais barato.... tem até algumas boas ferramentas free e open-source.

Em termos de cultura, me permitam usar o termo... "involuímos".... e estamos tentando retomar o tempo dos Analistas de O&M (ei, Analista de Negócios, este título - Analista de Negócios - já é usado pela IBM desde os idos de 89/90... e é a mesma coisa de hoje... o sujeito que sabe mais de negócios mas que trabalha para TI ...). A re-engenharia foi confundida com redução de custos e o Analista de O&M (atual Analista de Processos) teve que virar Analista de Sistemas ou morreria de fome..

Quem estudava Administração de Empresas com ênfase em Análise de Sistemas (belo nome de curso.....) lembra que Cálculo, ADM, Economia e O&M eram mais importantes (difíceis) que Redes, Linguagem de Programação, Análise de Sistemas ou qualquer outra... e que outros cursos tinham as mesmas matérias (Engenharias, Economia, Administração, etc...). Hoje o imediatismo do mercado leva a uma formação meio "boba" em muitas instituições.... É incrível um graduado em qualquer meleca de TI não saber fazer um fluxograma, seja com as réguinhas verdes, com IDEF, com BPMN, sei lá mais o que. Eu não emprego ninguém (em qualquer área técnica) que esteja acima do terceiro ano que não saiba fazer um belo desenho de processo (de processo, não de sistema...). E, gente, este negócio de AS-IS, pelo amor de Deus, é muito raro ter algum valor.... a não ser que você esteja vendendo as horas para fazer o AS-IS... outro exemplo é em outra situação muito difícil de acontecer... você está fazendo uma comparação entre os processos da empresa compradora e a comprada para ver com qual fica....

Enfim, a melhor notação é a que a tua empresa usa.... se ainda não usa, pega a tendência do mercado.... na minha opinião, BPMN.

Mensagens populares deste blogue

BPMN can bring death to your process data

5th November 2016 - Frankfurt - She is in parties

29-12-2016 - Paris - Book of the year