Uma empresa com milhões de clientes possui diversos sistemas, controles e mecanismos de registro de chamados no seu call center, mas, ainda assim, não é vista como um exemplo de atendimento pelo mercado. Seus sistemas nasceram motivados por urgências que atendiam interesses de unidades de negócio distintas, sem uma visão de arquitetura corporativa. Uma administração pró-ativa dos problemas enfrentados por seus clientes é praticamente impossível.
Esse é um real e clássico exemplo de necessidade imediata de controles consolidados e mecanismos pró-ativos de gestão de processos de negócios. O artigo a seguir descreve os principais pontos e características de uma solução de monitoramento de processos, um dos principais benefícios de negócio que uma arquitetura BPM pode prover a uma organização.
Objetivos de uma solução de monitoramento
Ilustrei acima um exemplo de um cenário de call center. De forma análoga, poderiamos citar uma situação onde gerentes de vendas querem saber, por exemplo, como andam as vendas Brasil afora, quanto falta para fechar a meta estipulada para uma determinada regional e onde estão os principais gargalos nos seus processos de vendas e, a partir de controles que mostram a tendência de um mercado consumidor, identificar oportunidades de negócio que levem a uma estratégia para revisão de processos para atender a um perfil específico ou o lançamento de um novo produto. Enfim, controles que, em última análise, levem a empresa a tornar-se especial, inovadora no seu mercado. De forma resumida, podemos listar os principais objetivos de negócio de uma solução de monitoramento de processos:
• Entendimento da execução e performance dos processos de negócio;
• Acompanhamento de medições e controles de acordos de níveis de serviço (SLAs);
• Melhoria na agilidade do processo através de tomada de ações automáticas;
• Analise consolidada da execução de processos de negócios que apóiem decisões pró-ativas de revisões de processos;
Ponto de entrada / saída de um projeto BPM/SOA
Pode-se considerar que uma solução completa de BPM envolve as seguintes etapas: (Re)Desenho, Implementação, Execução e Monitoramento. Não necessariamente, projetos de BPM devem iniciar por uma etapa de desenho ou modelagem. Podem acontecer situações em que o processo está bem definido, implementado e executado por sistemas proprietários como, por exemplo, um ERP integrado com outros sistemas legados. A “dor” da empresa, motivo que a levou a uma solução inicial de BPM, pode estar na falta de monitoramento de um processo já existente e em execução.
A base de tudo: Eventos
Para entendermos o conceito fundamental de uma solução de monitoramento, falamos agora na definição de um evento. Um evento pode ser entendido como uma ocorrência de log, tracing, gerenciamento de aplicação e/ou evento de negócio que encapsula dados num formato consistente para tratamento por outros sistemas (com isso, sendo base para os conceitos de autonomic computing). Um exemplo de especificação de eventos é o formato CBE (Common Base Event). A IBM e a Cisco, em outubro de 2003, anunciaram este formato como um padrão facilitador de troca de informações de logs e tracing entre sistemas heterogêneos. Este formato, descrito em XML (seu schema é definido em http://xml.coverpages.org/CBESchemaV20.html), informa a quem o consumir, informações relevantes do estado da aplicação que disparou o evento. Informações do serviço que originou o evento, severidade, número de ocorrências daquele evento além de extensões que descrevem mais a ocorrência são exemplos de dados que podem surgir em um CBE.
O link http://www.ibm.com/developerworks/autonomic/library/ac-cbe1/ descreve, com mais detalhes, o que é o CBE, seu formato e ainda leva a outros endereços com a especificação formal.
Luiz Phelipe Souza
