Um termo que ganha cada vez mais momento nos noticiários de TI é o BPM. O BPM significa Business Process Management e pode mudar a forma com que a TI desenvolve sistemas. Mas, afinal, o que é o BPM?

Para entendermos o BPM, precisamos entender primeiramente como a TI desenvolve software hoje. Podemos resumir o processo da forma abaixo:

1. O analista de requisitos entrevista um conjunto de usuários para coletar suas necessidades para desenvolver uma visão sobre o sistema ser montado.

2. Após uma série de entrevistas e reuniões, uma específicação de requisitos é produzida.

3. Em paralelo, o time de arquitetura técnica começa a trabalhar os requisitos suplementares do sistema (segurança ou desempenho, por exemplo) e trabalhar os riscos técnicos de um projeto através de testes preliminares. Uma arquitetura executável é produzida como resultado desta tarefa.

4. Após uma fase de maturação dos requisitos, o sistema começa a ganhar corpo e é implementado e testado funcionalmente.

5. O sistema é colocado em ambiente de testes de homologação até que atinja estabilidade para ser colocado em produção.

O ciclo acima, com pequenas variações, parece ser bem adequado. Muitas vezes, entretanto, o sistema colocado em produção não melhora a lucratividade ou outras metas de uma empresa. Isso ocorre porque a TI não tem fim em si mesma. A TI serve apenas a um propósito maior, que é fazer uma empresa funcionar mais eficientemente. A questão que se coloca é como uma empresa funciona com mais eficácia e eficiência.

A chave para esta resposta é com um processo de negócio mais adequado. Um processo de negócio é a descrição de um conjunto de procedimentos que envolve pessoas, tarefas, máquinas, softwares e outros elementos coordenados para atingir metas (objetivos) de negócio. Por exemplo, podemos ter uma meta em um banco de trazer 30M de reais em um ano através de novas contas. Isso pode ser realizado de várias formas, mas apenas os processos eficientes e eficazes podem implementar esta meta. Nesta hora o BPM entra em ação. O BPM é uma metodologia que permite que um especialista (ex: em operações bancárias) defina ou experimente diversos processos de negócio (ex: abertura de conta) e veja qual o mais efetivo.

O BPM pode ser feito apenas em papel, através de modelos e diagramas como os clássicos workflows. Entretanto, workflows não são modelos vivos e deixam muita margem para especulação ou incertezas.

O BPM pode ser feito através da geração de demandas para a TI para a construção de sistemas, experimentado hipóteses de negócios. Infelizmente, este processo é muito lento pois a construção de sistemas de informação é naturalmente demorada e o custo de readaptações nos sistemas é inviável.

Recentemente, o BPM ganhou força com ferramentas que permitem não somente expressar um processo de negócio através de seus componentes (pessoas, tarefas, máquinas, softwares), como também exprimir custos, tempo e consumo de recursos para cada um destes componentes. O analista de negócio pode então criar um simulacro do mundo real, desde que possua um profundo conhecimento do negócio (ex: abertura de contas bancárias). Além disso, algumas ferramentas podem literamente simular os diversos cenários propostos pelos analistas e gerar métricas de eficiência temporal ou monetária para o processo. Cenários podem ser comparados e o melhor cenário é passado para a TI para ser automatizado como um sistema de informação.

Exemplos de ferramentas que suportam estes modelos incluem:
- JBOSS jPBM (open-source)
- IBM WebSphere Business Modeler (Ferramenta mais robusta e profissional para BPM)

Modelos BPM podem ser expressos em linguagems vivas como o BPEL, que permitem a simulação de um workflows em um engine de simulação, presentes nas ferramentas acima. Modelos BPEL podem ser exportados como modelos UML para a TI ou mesmo ser incorporados em orquestradores de processo (ex: IBM WebSphere Process Server) para execução real.

A forma de trabalho da TI é diferente e pode ser então reescrita da seguintes forma:

1. O analista de negócio simula diversos processos de negócio para promover o alinhamento das metas organizacionais. Os melhores processos de negócio são escolhidos para automatização parcial (dado que componentes do processo de negócio envolvem seres humanos, como um correntista no processo de abertura de uma conta).

2. O analista de requisitos entrevista um conjunto de usuários para coletar suas necessidades para desenvolver uma visão sobre o sistema ser montado, que irá automatizar parte do processo de negócio.

3. Após uma série de entrevistas e reuniões, uma específicação de requisitos é produzida.

4. Em paralelo, o time de arquitetura técnica começa a trabalhar os requisitos suplementares do sistema (segurança ou desempenho, por exemplo) e trabalhar os riscos técnicos de um projeto através de testes preliminares. Uma arquitetura executável é produzida como resultado desta tarefa.

5. Ainda em paralelo, o time de arquitetura de negócio “coreografa’ o processo de negócio em uma ferramenta de orquestração. Cada elemento do processo de negócio será possivelmente automatizado como um ou mais serviços. (Por exemplo, a verificação de restrições bancárias em um sistema de abertura de contas pode ser implementada através de um ou mais serviços que consultam o Banco Central, CDL ou SERASA, por exemplo. Tecnicamente, estes serviços podem ser implementados em WebServices com o suporte de linguagens como Java ou C#).

6. Após uma fase de maturação dos requisitos, o sistema começa a ganhar corpo e é implementado e testado funcionalmente. O sistema agora não é mais uma peça monolítica, mas um conjunto de serviços (Web Services) que juntos formam workflows (processos de negócio derivados dos modelos BPEL dos analistas de negócios).

7. O sistema é colocado em ambiente de testes de homologação até que atinja estabilidade para ser colocado em produção.

Claramente, o sistema implementado agora estará alinhado com o negócio. Se o negócio mudar (e irá mudar), o ciclo é realizado em termos de manutenções evolutivas. Entretanto, esta dinâmica pode ser realizada de forma muito mais ágil que os antigos sistemas monolíticos pois o sistema é implementado como um conjunto de serviços, dirigido *por* workflows de negócio. Os serviços podem então ser re-arranjados muito mais facilmente para se adaptar às mudanças com menor custo.

Mais informações sobre BPM podem ser achadas aqui.
O padrão OASIS BPEL é descrito aqui