Escrevi em outro post sobre o conceito principal em cima da sigla BPM e como outra sigla, SOA, complementa e facilita a implementação de soluções de gestão de processos (Leia Aqui).
Neste tópico, vou comentar sobre as principais funcionalidades exigidas pelo mercado de TI para as suítes de BPM e que já estão disponíveis pelos principais players do mercado.
MODELAGEM & SIMULAÇÃO : Espera-se com esta funcionalidade a capacidade de documentar processos de forma rápida e imediata, isto é, sem grandes conhecimentos da ferramenta, é esperado que o usuário seja capaz de começar o desenho do seu processo. Além disso, um requisito mandatório atualmente é a capacidade de simulação, ou seja, conseguir "alimentar" seu processo com informações de custos, prazos e disponibilidade de recursos para identificar, em tempo de projeto, onde podem estar os principais "gargalos" ou pontos de melhoria que justifiquem uma re-engenharia do processo. Por fim, mas não menos importante, é a possibilidade de exportar o resultado do trabalho de modelagem para uso pela equipe de TI, responsável final para colocar aquele processo automatizado e em execução. Com isso, começamos a ter o grupo de negócios e processos trabalhando efetivamente no desenvolvimento de uma solução.
AMBIENTE COLABORATIVO: Entende-se por este conceito a possibilidade de extender o seu ambiente de desenvolvimento e os produtos desenvolvidos para uma comunidade maior de usuários que podem, com isso, colaborar na solução final. Algumas funcionalidades interessantes são a definição de um repositório comum de projetos já construídos ou em desenvolvimento e foruns de discussão sobre os principais objetivos do projeto. Pensando já na execução de um processo de negócios, é natural que existam intervenções humanas ao longo do mesmo(por exemplo, aprovações). Há que se considerar, portanto, que no ambiente de desenvolvimento, as ferramentas incluam facilidades para desenhar as interfaces com o usuário e, além disso, tenham mecanismos para controles de execução de tarefas humanas, como possibilidades de "escalar" outro funcionário em caso de demora excessiva na execução da tarefa ou mesmo a possibilidade de delegações temporárias de papéis.
MONITORAÇÃO DE PROCESSOS: Já bastante comentado em outro post (Leia Aqui), esta funcionalidade tem por objetivo mostrar aos gestores dos processos como andam seus "filhos", isto é, quão bem ou quão mal os processos rodam na organização. Indicadores de desempenho (KPIs), gráficos consolidados e visões operacionais estão como os principais desejos dos gestores que, normalmente, irão patrocinar um projeto de BPM para conseguir a tão sonhada "gestão on-line e real-time".
PROCESSOS DINÂMICOS & APLICAÇÕES COMPOSTAS : Tem sido comum, em tempo de projetos, os requerimentos de dinamicidade e flexibilidade de manutenção do processo, ou seja, a capacidade de manter meu processo sem tirá-lo do ar ou, pelo menos, minimizar ao máximo o downtime. Afinal, este é um grande apelo do "BPM enabled by SOA". Soluções de mercado atuais incluem a possibilidade de se criar um processo customizado e que pode ser mantido a partir de políticas de execução do mesmo, isto é, baseado nas informações do cliente que invocou (se é um cliente preferencial ou não), de onde ele veio (se por um portal, por URA, por atendente, etc) e/ou dos dados contidos na invocação (se é um pedido de um novo produto algo já pedido) chegar a uma granularidade bastante particular do processo que inclui sistemas, grupos de atendimentos distintos e qualidades de serviços completamente distintos.
PROCESSAMENTO DE EVENTOS DE NEGÓCIOS : Não somente a monitoração dos processos está na lista de anseios de clientes de BPM. A capacidade de se identificar padrões de execução e/ou comportamento do cliente final e, com isso, tomar alguma decisão automática tem sido uma funcionalidade bastante comentada. O exemplo mais simples para ilustrar é o caso de um usuário de telefone celular que tem um registro de ligação no Rio de Janeiro e, quinze minutos depois, consta um registro de ligação a partir de Fortaleza. Bom, neste cenário, ficou bastante evidente uma fraude na conta daquele cliente. Com alguma ferramenta que permita extrair eventos de negócios do processo em execução, montar padrões de desvio e invocar ações automáticas, consegue-se implementar este tipo de requerimento, citado no exemplo.
EXECUÇÃO DO PROCESSO: Neste ponto, fala-se principalmente na capacidade de orquestrar e montar o processo (a partir de serviços automáticos ou humanos) além do próprio ambiente operacional que irá ser executado o processo. Em tempo de desenvolvimento, é extremamente importante que se consiga, antes de mais nada, importar algum artefato proveniente da etapa de modelagem (comentei isso acima na perspectiva do analista de processos). Mais: atualmente, o mercado de TI tem desenvolvido alguns padrões de linguagens e conceitos para a implementação do "BPM enabled by SOA". Considero como principais o BPEL, que é uma representação para a execução de um processo e invocações para serviços existentes (automáticos ou humanos) e o SCA (Service Component Architecture) que é uma representação dos processos e suas dependências para execução. Neste caso, temos o "SOA na prática". Vemos em diagramas o processo montado, suas interdependências e, em caso de manutenção para troca de serviços, simplesmente nos limitamos a "trocar caixinhas". Tão simples quanto isso ! Sobre o ambiente operacional... Bom, em primeiro lugar, não se espera de um ambiente que irá rodar, por exemplo, seus processos de venda algo sem grandes contingências, alta disponibilidade, segurança e tudo mais que se espera de um servidor de produção. Portanto, em suas iniciativas de BPM, não se esqueça de verificar com seu fornecedor em que sistemas operacionais o tal servidor rodará além da capacidade de escalabilidade e alta disponibilidade.
REPOSITÓRIO DE SERVIÇOS: Esse é um requerimento diretamente associado aos procedimentos de governança. Pensando num dos apelos de SOA, reuso, como é que se garante reutilização de serviços sem uma espécie de "centro de excelência SOA" em conjunto de um repositório controlado de serviços? Esse repositório deve garantir algumas coisas: Ser de uso comum a analistas de negócios e de TI, ser configurável para a definição de políticas de uso, possuir mecanismos de controle de acesso, possuir facilidades que controlem o ciclo de vida dos serviços além de outras coisas mais.
Outras funcionalidades (não ligadas diretamente a tecnologia) para a tomada de decisão de uma suite de BPM incluem frameworks de indústria que podem ajudar como "templates" para a aceleração da implementação de processos (por exemplo, a indústria de telecomunicações, cada vez mais, utiliza padrões estabelecidos mundo afora), metodologias de implementação de tais suites e também um "ecossistema" no mercado de desenvolvedores, técnicos e analistas.
Naturalmente, nenhum cliente precisa disso tudo num primeiro momento de suas iniciativas de BPM. Seria como pensar em se ter uma aperalhagem completa de cozinha para fazer ovo frito, não é verdade? O que considero como sendo um dos pontos mais importantes para avaliação de uma suite, do ponto de vista técnico, é sua modularização e facilidades de integração entre módulos. Isso me garantirá um início mais barato além de garantias para o crescimento dos meus projetos.
Luiz Phelipe Souza
"SOA não é um programa de computador a ser instalado e que vai resolver todos os problemas de TI. SOA é um estilo de arquitetura tecnológica com o objetivo de dar agilidade ao negócio das empresas. Sendo um estilo, ela tem traços marcantes: componentização para reuso, a modelagem e coreografia de processos, etc, já discutidos aqui. Mas quais são as melhores práticas para a materialização desses conceitos? O que a experiência tem mostrado como sendo o caminho mais efetivo?"
