O termo BPM nos remete a uma ênfase na palavra processos e uma visão de mundo onde uma empresa pode ser vista como uma coleção de processos. Este pensamento, em si, é perigoso e infelizmente enganoso. A palavra processos nos remete ao “como” e nos faz esquecer do entendimento do “quê” deve ser realizado. A consequência prática é que algumas iniciativas BPM de mercado tem falhado ou no máximo obtendo ganhos marginais. Podemos combater este pensamento com o conceito das “capacidades de negócio” como um elemento que precede os processos de negócio.

Repensando o salto em altura
Conforme citado no bom livro Rethink, de Ric Merrifield, os saltos em altura eram realizados com o atleta em direção frontal ou diagonal à barra. Ao tentar melhorar a eficiência destas técnicas, alguns atletas apenas obtinham um ganho marginal na altura transposta. Ao remover o raciocínio limitante e pensar em uma nova forma de saltar, um atleta chamado Dick Fosbury estabeleceu novos patamares para o esporte, ganhou a medalha de ouro no méxico em 1968 e batizou o estilo de salto usado hoje em 2010 com o seu nome. Ele escapou da armadilha do “como” antes do “quê”.

Modelagem de Capacidades de Negócio
O problema do BPM não é o foco em processos, mas o foco prematuro em processos. O atleta Dick Fosbury trabalhou muito na eficiência dos seus processos, mas depois de entender as corretas capacidades a serem realizadas. Estendendo as idéias tradicionais do BPM, destacamos aqui a idéia das capacidades de negócio.

Uma capacidade de negócio é visão multi-dimensional de uma organização com um objetivo claro de negócio, atividades de negócio (processos), recursos humanos, um modelo de governança e serviços de negócio. Um exemplo no segmento de TELECOM seria a “Ativação de Serviços de Telefonia”. Um outro exemplo, no segmento de aluguéis de carros seria a “Gerência de Frotas”. Neste instante do tempo, ainda não estamos preocupados com os processos necessários para a ativação de telefonia ou os processos para o gerenciamento de frotas.

Técnicas de modelagem de capacidades como o IBM Component Business Model ou o Microsoft Business Capability Mapping podem nos ajudam a modelar todas as capacidades da sua organização e desenvolver visões chamadas de mapas de calor para perceber os elementos disfuncionais em uma organização. Ao saber que disfunções a nossa organização possui, podemos então focar então na modelagem dos seus processos e então nas suas melhorias.

A disciplina de modelagem de capacidades é vista como arquitetura de negócio e deve preceder e guiar as atividades de modelagem de processos de negócio. A modelagem de capacidades é realizada pelo arquiteto de negócio da sua organização e a modelagem de processos pelo analista de processos de negócio.

Para os interessados no tema, coloco aqui algumas referências a respeito:

• Artigo de Ulrich Homann sobre o conceito de capacidades de negócio.
• Artigo de Michael Poulin sobre o IBM Business Component Model.
• Entrevista com Ric Merrifield sobre a modelagem de capacidades de negócio.

Postei há algum tempo aqui uma notícai sobre o jogo Innov8 (Innovate) da IBM que mostrava de forma lúdica os conceitos de BPM em um jogo 3-D com excelente qualidade gráfica.

Agora o jogo está disponível online para qualquer usuário (basta preencher um registro e criar uma conta). Para os estudantes universitários da parceria acadâmica IBM, ele pode ser baixado para a sua máquina.

O jogo foi melhorado e agora apresenta cenários de negócios diferentes para os jogadores.

Bons jogos e bom aprendizado!

Veja o trailer aqui.
Jogue o jogo online aqui.
Baixe o jogo completo aqui.

Fizemos hoje uma palestra dentro do circuito de palestras do IGTI (Instituto de Gestão em Tecnologia da Informação) sobre BPM. Discutimos aspectos gerais deste paradigma e apresentamos brevemente algumas soluções BPMS de mercado como o JBOSS jBPM, IBM WebSphere e MetaStorm ProVision.

Disponibilizo a apresentação em anexo para os iniciados e interessados em BPM.

Recursos adicionais como links, associações e blogs a respeito podem ser encontrados aqui.

Pensamento do dia: “Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?” -T.S. Eliot

Recebi um artigo instigante, escrito pelo vice presidente da Fujitsu (Keith Swenson), sobre BPM e a sua relação com engenharia de software - BPM is not Software Engineering. A hipótese do autor, que concordo, é que BPM é uma ciência diferente de engenharia de software e requer uma abordagem diferente para a sua implementação.

Em suas palavras:

“Business Process Management” is, as the name implies, about management of business processes. A business process is not managed by a software engineer. A “business process” is not a program. It may be supported by a program, but the business process is the thing that the organization wants done.

O autor discute erros cometidos por engenheiros de software em implementações BPM tais como o uso excessivo de abstrações e modelos, que não são compreendidos por pessoas das áreas de negócio, e uma crença excessiva na automação ou uso de programas para resolver os problemas de negócio. O artigo me lembra das leis da automação escritas por Bill Gates há algum tempo:

A primeira lei da automação diz que a automação de um processo eficiente irá aumentar a sua eficiência, Bill Gates

A segunda lei da automação diz que a automação de um processo ineficiente irá apenas aumentar a sua ineficiência, Bill Gates

Um outro fato nesta direção que também me chama a atenção também é dos especialistas e renomados consultores BPM Jeston & Nellis, que acabaram de lançar a segunda versão de um dos melhores livros sobre implementação BPM - Business Process Management: Practical Guidelines to Successful Implementations (Paperback). Eles citam neste livro que cerca de 30% de uma implementação BPM é gasta com People Change Management“.

People Change Management é sobre pessoas, é sobre a compreensão genuína dos seus métodos de trabalho, é sobre a detecção dos problemas que tornam os seus processos ineficientes, é sobre o estabelecimento de confiança entre times, é sobre mudança cultural e a proposição de novas formas de trabalho e finalmente, sobre o acompanhamento e suporte em novas formas de trabalho, mais eficazes e mais eficientes.

Citando uma frase de Keith Swenson novamente:

BPMN does not exist for the convenience of Software Engineers, because BPM is not Software Engineering.

.

Acontece hoje em Belo Horizonte o Java Developer’s Day 2008 da ASSESPRO-MG. Tivemos a oportunidade de abrir o evento com uma palestra que disponibilizo aqui (Tecnologias Java para BPM e SOA).

Discutimos nesta palestra os principais padrões Java (WS-*, JBI e SCA) e tecnologias relacionadas (suítes BPM ou BPMS) para o suporte à implementação de projetos BPM e SOA. Para os iniciantes em BPM, recomendo a leitura dos seguintes posts sobre o assunto:

• BPM para Leigos
• Recursos Conceituais BPM

A Fauna BPMS

Ferramentas BPMS Open-Source

• Intalio (Conforme discutido na apresentação, talvez a suíte open-source mais robusta para BPMS).

Ferramentas Open-Source BPMS que suportam o padrão JBI

• Open ESB
• JBOSS ESB
• Apache Service Mix
• Mule
• OpenFuse

Ferramentas BPMS que suportam o padrão SCA

• Apache Tuscany Open-Source
• Eclipse STP Open-Source
• Mule Open-Source
• IBM WebSphere
• BEA AquaLogic

O ano de 2008 foi especialmente interessante para a área de BPM no Brasil. Observamos um grande interesse da comunidade técnica pelo assunto e vários projetos e iniciativas de melhorias sendo colocadas em prática. Notícia positiva também são os sites, associações e redes sociais já disponibilizados sobre o assunto, que resumo abaixo:

• eBizQ - O fórum mais ativo e rico que conheço sobre o uso de BPM na TI para aumentar a agilidade nos negócios. Destaco em particular os seminários gratuitos Web semanais, que trazem especialistas BPM e SOA de todo o mundo para compartilhar suas estórias de sucesso e desafios enfrentados.
• ABPMP (Association of Business Process Management Professionals) - A ABPMP é uma associação internacional de profissionais da área de Gerenciamento de Processos de Negócio (BPM), sem fins lucrativos, independente de fornecedores, e dedicada à promoção dos conceitos e práticas de BPM.
• IIBA (International Institute of Business Analysts) - O IIBA é uma associação sem fins lucrativos que tem como objetivo facilitar o trabalho do crescente número de profissionais que atuam na área de análise de negócios. Destacamos no IIBA o trabalho do BABOK, que documentamos em outro post.
• BPM Institute. Muita informação e colaboração de especialistas sobre BPM e BPMS (ferramentas BPM).
• The BPM Experience. Bom blog com informações ricas e atuais sobre BPM e BPMS.
• BP Trends. Excelente site sobre novidades, análises e tendências da área de BPM e BPMS.

Gostaria de destacar aqui também uma referência fundamental para suporte a BPM, embora na sua aparência seja “apenas” uma revista de administração - a Harvard Business Review. A HBR talvez seja a melhor revista sobre administração no mundo e é inclusive comercializada (em papel) nas melhores bancas e livrarias do Brasil. É uma fonte inesgotável sobre melhores práticas de administração e processos e referência obrigatória para praticantes sérios de BPM.

Pensamento do Dia: “As empresas estão perfeitamente alinhadas para obter os resultados que alcançam.”, Peter Drucker.

A Oracle disponibilizou recentemente um excelente relatório com tendências de adoção do BPM no mundo e também no Brasil.
Resumo aqui para os mais apressados as principais conclusões do relatório:

• O mercado BPM vive um crescimento estupendo, com uma perspectiva de crescimento de quase 10 vezes nos próximos anos, apesar da crise do mercado americano. As projeções indicam um crescimento do mercado de 500 milhões de US$ este ano para quase 6 bilhões até 2011.
• As iniciativas BPM na maior parte das organizações estão maturando, sendo usadas ainda primordialmente dentro de uma área ou unidade.
• O mercado de ferramentas está em franco processo de seleção natural. Ao invés de 150 ferramentas representativas (2006), temos agora apenas 25 ferramentas com representatividade (2008).
• Uso do BPM como ferramenta indireta para integrar aplicações (EAI) e para promover uma cultura de alinhamento a processos e escritórios de processos.
• Uso do BPM como um mecanismo de mudança cultural muito além da questão tecnológica, i.e., uma metodologia para remover silos e promover comunicação e alinhamento.
• Incentivo à combinação de BPM e SOA. Empresas que conjugaram as duas iniciativas tiveram resultados bem mais consistentes que empresas que adotaram apenas BPM.
• Aumento explosivo da colaboração entre pessoas com conceitos como CEP (Complex Event Processing) e ferramentas de EDA (Event Driven Architecture) para a montagem de empresas que respondem aos eventos (internos e externos) em tempo real.
• Dentro de TI, é o segmento que apresenta o maior crescimento no uso de ferramentas. Esta é uma clara mensagem para quem trabalha com TI. Se você nao está pensando em BPM e suítes BPM (BPMS), leia o relatório e repense a sua estratégia.

Para os que dispõe de mais tempo, mais interesse ou ambos em BPM, coloco aqui o link para relatório State of the Business Process Management Market 2008.

Escrevi um artigo há um tempo através sobre conceitos básicos de BPM (Gerenciamento de Processos de Negócio). O BPM envolve um ciclo de vida técnico resumido na figura abaixo e contém um aspecto fundamental chamado de monitoração de processos de negócio (BAM - Business Activity Monitoring, em inglês).

Mas o que é o BAM? Em termos simples, O BAM permite o armazenamento, análise e exibição de informações estatísticas sobre a execução de processos de negócio.

Para entendermos o BAM, devemos lembrar que a metodologia BPM requer que todo processo de negócio seja mensurável, i.e., tenha a capacidade de ser medido através de métricas. Por exemplo, um processo de negócio de pré-venda poderia ser observado através do percentual de vendas fechadas, volume financeiro gerado ou do tempo médio em dias para finalização do processo. Um processo de negócio de fabricação de um produto em uma fábrica poderia ser medido através do percentual de produtos rejeitados pela área de qualidade (% de defeitos) ou também pelo tempo médio em semanas para a sua fabricação.

Dado esta premissa, que vem dos modelos mentais de metodologias que influenciaram o BPM, como o DMAIC Six Sigma, podemos explicar o mecanismo BAM. O BAM é um método que monitora todas as atividades de negócio, i.e., todos os processos de negócio que estejam em execução, e extrai medidas destes processos de negócio em observação.

Não devemos confundir, entretanto, o BAM com ferramentas. O BAM pode ser realizado por um analista de produção que observa toda a cadeia de pessoas, máquinas e sistemas enlaçadas por um processo de negócio e então mede através de processos estatísticos o desempenho deste processo. As medidas extraídas do processo são então comparadas com possíveis métricas pré-acordadas entre o time de análise, gerência e time de produção e eventuais desvios são analisados e tratados. O BAM permite, portanto, que acordos de qualidade entre o time de gerência e análise (SLAs) sejam monitorados e que um processo de gerência de nível de serviço (SLM) seja implementado sobre um determinado processo de negócio.

Ferramentas BAM

O BAM têm obtido popularidade devido a ferramentas BAM. Ferramentas BAM são softwares que monitoram continuamente “tempo real” ou em ciclos de eventos de monitoração como o desempenho de um processo se comporta frente às métricas definidas de um processo. Boas ferramentas de BAM devem oferecer as seguintes funcionalidades (em uma listagem não exaustiva):

• Facilidades para a definição de métricas de processos e um conjunto comum de métricas típicas já implementadas (ex: Custo, Tempo de resposta, Uso de Recursos Humanos, Uso de Equipamentos, Uso de Sistemas Computacionais).
• Facilidades para a coleta de medidas através de fontes de dados diversas (ex: arquivos, bases de dados e sistemas transacionais)
• Facilidades para a consolidação das medidas e transformação destas em métricas do processo. Estes dois últimos aspectos guardam relacionamento
  com ferramentas de ETL (Extração, Carga e Transformaçào), embora em um contexto diferente.

• Facilidades para geração de métricas em “tempo real”, i.e., observação do desempenho atual de um processo.
• Facilidades para a definição e monitoraçào de eventos de negócio. Um evento de negócio é um sinalizador de negócio usado para aumentar a velocidade e adaptação a mudanças de mercado e da saúde de uma organização ou área. Exemplos de eventos de negócio poderiam incluir uma queda acentuada de uma bolsa de valores, um novo contrato fechado ou um aumento súbito no volume de pedidos de produtos.
• Facilidades para a publicação de indicadores em portais e “dashboards”.
• Integrações com soluçÕes SOA e ferramentas como servidores de orquestração, servidores de eventos arquiteturais (EDA) e portais.
• Facilidades para a definição de SLA/SLM e geração de alarmes para a monitoração de desvios.

O BAM, obviamente, não deveria ser o ponto de entrada para uma organização que esteja começando uma iniciativa BPM, mas pode sem dúvida ser alcançada ao longo de uma implementação.

Para os interessados, coloco abaixo uma lista de referências sobre BAM:

• Jump-start business activity monitoring
• Série de 11 artigos sobre BAM com o IBM WebSphere Business Monitor. Independente da ferramenta, os artigos trazem informações valiosas sobre BAM.
• Blogs sobre BAM da TIBCO

O BPM ganha cada vez mais espaço nas empresas como uma excelente forma de se realizar a gestão por processos de uma organização e também alinhar ações de TI com as áreas de negócio.

Para simplificar o aprendizado de BPM, a IBM lançou um jogo (!!!) gratuito para BPM. .

Instalei recentemente o jogo e tenho me divertido consideravelmente com ele. Acredito em mecanismos lúdicos de aprendizagem e o que mais me impressionou foi a excelente qualidade dos gráficos e o interessante roteiro do jogo. Em resumo, você é um analista de processos de negócio e você tem a missão de resolver um gargalo em um determinado processo de negócio que apresenta KPIs inaceitáveis. Você tem uma noite para resolver o problema e colocar a empresa no rumo novamente.

Mais informações sobre o jogo, chamado Innov8 (trocadillho para innovate), podem ser encontradas aqui.

O termo domínio é utilizado para denotar ou agrupar um conjunto de sistemas ou de áreas funcionais que exibam funcionalidades similares.

Exemplos de domínio incluem:

• Domínio de Telecomunicações
• Domínio Logístico Atacadista
• Domínio Bancário
• Domínio de Seguros de Saúde
• Domínio Acadêmico Escolar

Podemos então descrever o domínio aplicacional como sendo uma coleção de aplicações de software que partilham um determinado conjunto de características. Da mesma forma, o domínio é definido por um conjunto de características que descrevem uma família de problemas para os quais uma determinada aplicação pretende dar solução.

Um modelo de domínio é um artefato comum em várias metodologias (RUP ou escolas ágeis) usado para expressar um determinado domínio, normalmente em linguagem UML.

Antes de definir este artefato, vamos dizer o que não é este modelo. Um modelo de domínio não é um diagrama de classes em nível de análise, um diagrama de classes em nível de desenho, muito menos um modelo de entidades e relacionamentos (DER). Um modelo de domínio não carrega informaçães técnicas (Java ou C#), que devem estar presentes em um modelo de desenho. Um modelo de domínio também não carrega todo o detalhamento do comportamento e estrutura (operações e atributos), que devem estar presentes em um modelo de análise. Um modelo de domínio também não carrega informações de armazenamento de informações ou normalizações, que devem estar presentes em um DER.

Mas, afinal, o que é um modelo de domínio?

1. Um modelo de domínio é um produto da modelagem de negócios, i.e., ele representa, em certa escala, o negócio sendo modelado e compreendido.

2. Um modelo de domínio deve, por consequência, ser realizado inicialmente pelos analistas de negócios e usuários do projeto, e revisado e complementado pelo máximo de participantes de um projeto. O modelo de domínio deve ser um artefato colaborativo, compartilhado por todo o time do projeto.

3. Um modelo de domínio captura o vocabulário do sistema ou negócio sob modelagem. Como exemplo, um modelo de domínio de um sistema acadêmico de uma faculdade irá possuir os elementos Aluno, Professor, Curso, Disciplina ou Matrícula, entre diversos outros. Podemos perceber, então, que o modelo de domínio expressa o glossário do negócios sob modelagem.

4. Um modelo de domínio é uma representação lógica e estrutural de elementos do domínio e seus relacionamentos. Um diagrama de classes UML possui os elementos necessários para esta estruturação. Normalmente os conceitos de classes, associações e generalizações são suficientes para estruturar um modelo de domínio. Como consequência, um modelo de domínio não captura interações temporais ou representações físicas de modelagem.

5. Um modelo de domínio expressa uma visão conceitual preliminar acerca de um sistema e é chamado de diagrama de classes conceitual por alguns autores. Um exemplo extraído do excelente site do Scott Ambler (http://www.agilemodeling.com) de modelagem de domínio representa esta idéia.

(c) Scott Ambler, 2003-2006.

6. Um modelo de domínio deve ser feito no começo do projeto. Temporalmente, ele deve ser expresso e ganhar maturidade até o primeiro décimo do projeto. Por exemplo, se você tem na sua mão uma demanda de dois meses, devemos conseguir um modelo de domínio relativamente estável até o fim da primeira semana. Isso requer, como pode ser imaginado, um esforço intenso com os usuários chave para capturar o vocabulário, glossário e representá-lo em UML.

7. Um modelo de domínio (enquanto artefato) não precisa ser evoluído formalmente no restante do projeto. Isto pode parecer estranho, mas o objetivo do modelo de domínio é capturar o negócio e servir de insumo para a geração de modelos mais formais como o diagrama de classes ou o DER e depois o código executável. Em outras palavras, podemos imaginar o modelo de domínio como um estágio evolucionário para gerarmos os diagramas estruturais, comportamentais e o código de um projeto de software. Cabe citar que o modelo de domínio, enquanto conceito, como bem capturado pelas resenhas a este blog, evolui sempre, isto é, o diagramas de classes, o DER e o código também refletem conceitualmente o domínio do problema e por isso podem ser entendidos como “modelos de domínio”.

8. Um modelo de domínio também é um padrão arquitetural para a modelagem de sistemas OO, padrão este que encapsula lógica de negócios e dados em entidades coesas. Uma referência mais densa sobre este aspecto pode ser encontrada no excelente livro Patterns of Enterprise Application Architectures (http://martinfowler.com/books.html#eaa), do autor Martin Fowler. Recomendo também o artigo Anemic Domain Model (http://www.martinfowler.com/bliki/AnemicDomainModel.html) como anti-exemplo do uso deste padrão.

9. Um modelo de domínio pode carregar padrões de análise. Um padrão de análise não é um padrão técnico (desenho ou arquitetura), mas uma representação conveniente para expressar um aspecto de negócio em sistemas de informação. Exemplos de padrões de análise envolvem a representacão de quantidades (monetárias ou medicamentos), a representação de faixas de valores (início/fim), padrões contábeis (parcelamentos de dívidas, contratos) ou representação de papéis (roles). O site sobre Analysis Patterns (http://martinfowler.com/articles.html#ap) do autor Martin Fowler traz informações valiosas sobre este tópico.

Se você não entendeu nada até o momento, um exemplo pode ajudar a colocar alguma luz neste conceito. Vamos assumir que você precise representar o domínio de sistemas de gestão da geração e transmissão de energia elétrica. Um modelo de domínio que mostra este negócio em termos de seus elementos (ex: transformador, consumidor de energia) e relacionamentos é mostrado aqui.

Compilo aqui, para os mais interessados neste artefato e nesta técnica, uma lista de referências mais técnicas de modelagem de domínio de vários especialistas de mercado.

• ICONIX: http://www.ddj.com/architect/184414689 - Fornece uma visão sobre os 10 erros mais comuns na modelagem de domínio de sistemas computacionais.
• Introduction to Class Normalization - http://www.agiledata.org/essays/classNormalization.html - Fornece uma visão evolutiva sobre modelagem de classes em UML.
• Agile Modeling – http://www.agilemodeling.com/essays/amddPresentation.htm - Traz princípios complementares sobre a modelagem ágil de sistemas.
• Análise Robusta – http://www.agilemodeling.com/artifacts/robustnessDiagram.htm e http://www.ddj.com/architect/184414712 - Técnica complementar à modelagem de domínio para capturar entidades, comportamentos e fronteiras de um sistema.