Todo mundo sabe que o BPM (Business Process Management) é uma das siglas de negócio/TI mais quentes do momento. Gartner diz, Forrester diz, todos os institutos de pesquisas dizem. A previsão é de crescimento de mais de 20% ao ano até 2009.
Mas alguns fatos que só quem acompanha isso desde 2001/2002 viu:
1. Quando começamos a trabalhar com processos/BPM, se você entrasse no Google, escolhesse a opção “páginas do Brasil” e pesquisasse por “BPM”, as duas ou três páginas iniciais traziam sites de batalhões de polícia motorizada. Era 11 0 BPM, o 23 0 BPM, o 16 0 BPM….A partir da segunda página começavam a vir sites sobre música eletrônica e DJ´s (devido ao batidas por minuto). Entre hoje e veja o resultado.
2. Quando iamos fazer alguma apresentação do nosso software de BPM, o Orquestra BPM, a reação ao final de uma reunião de 2 horas podia ser:
- Nossa! Fantástico esse produto de vocês. Muito bonito. Mas para quê eu posso usar mesmo na minha empresa se não tenho processos?
Hoje, ainda bem, essas situações não ocorrem mais…
26 de Julho de 2007 às 21:29
Rafael Bortolini
Para quem está acompanhando nossa série de posts sobre padrões e siglas de BPM, finalmente o segundo capítulo. Acompanhe os anteriores aqui e aqui.
Existe muito material na Internet sobre o BPMN, pois trata-se do padrão mais difundido e utilizado atualmente dentro da área de BPM.
O BPMN foi desenvolvido inicialmente por uma organização composta basicamente por vendors e consultores de BPM, a BPMI (Business Process Management Initiative, http://www.bpmi.org), e foi lançado em maio de 2004. Logo, o BPMI foi incorporado à OMG (Object Management Group http://www.omg.org/) outra organização internacional que trata da especificação de uma série de padrões, entre eles o UML.
O BPMN com o tempo passou a receber apoio de diversas empresas de porte, como Microsoft, SAP, IBM e Oracle, o que com certeza ajudou na sua popularização. Ao contrário do XPDL, que analisamos antes, o BPMN é um padrão visual, isso é, ele é composto por uma série de objetos (desenhos) que são utilizados para mapear processos. Veja o exemplo abaixo de um diagrama BPMN:
Um dos objetivos do BPMN (muito nobre, pode-se dizer) é “aproximar a área de negócios e a área de TI”. Nesse sentido, o BPMN pode ser uma ferramenta eficaz de comunicação entre a área de negócios (que conheçe como funciona o fluxo de atividades) e a área de TI (que precisa automatizar esse fluxo), diminuindo os riscos de um projeto e tornando a solução final mais aderente aos objetivos de negócio. Isso significa, ao final, que tanto analistas quanto programadores deveriam ver um diagrama BPMN e entendê-lo da mesma maneira.
Quem já trabalhou com BPMN na prática, entretanto, sabe que nem tudo funciona assim. Em primeiro lugar, é muito fácil notar lendo a especificação que o BPMN foi feito por programadores, por pessoal técnico, e não por pessoal de negócio. Ou pelo menos foi feito mais por pessoal técnico. Além disso, o grande número de elementos que podem ser usados na modelagem de um processo pode tornar o fluxo confuso, e não é incomum encontrar um analista que usou ou tentou usar todos os elementos em um mesmo fluxograma, muitas vezes de maneira errada.
Por isso, a dica mais importante que fica é que, antes de começar a usar BPMN, é importante estudar a fundo a especificação e definir um set de elementos básicos, iniciais, que a empresa vai começar a trabalhar. Criar um manual de padronização interno, gerar alguns templates e comunicar a todos os analistas como a empresa irá usar o BPMN.
Mesmo com essas restrições, é inegável a importância do BPMN hoje. O jeito é contornar suas limitações e esperar a versão 2.0, que virá em 2008.
Enquanto isso, acompanhe um resumão do BPMN aqui .
às 21:02
Rafael Bortolini
Para quem chegou ao final do dia e está precisando de um pouco de diversão.
Ou para aqueles que querem se vingar do seu projeto de SOA que até agora não decolou mas que já gastou boa parte do budget…
Conheça o SOA Facts
Algumas das minhas preferidas:
SOA can’t be named BOA (Business Oriented Architecture) since that would be too constricting for SOA.
The most dangerous animal in the IT jungle is the SOA constrictor. It has been known to squeeze the life out of all other IT initiatives.
SOA knows what you did last summer, and is disappointed that it wasn’t SOA.
Software architects don’t use SOA. SOA uses software architects.
às 20:33
Rafael Bortolini