Qual a principal diferença entre BPM e BPEL?

Você está pesquisando sobre produtos para gestão de processos, e ouviu falar em BPEL. Mas também ouviu outros produtos falarem em BPM. Afinal, o que há de diferente entre eles?

Enquanto BPEL (Business Process Execution Language) é um dos padrões tecnológicos usados para implementação de processos automatizados, BPM (Business Process Management) é muito mais do que isto. BPM é toda uma disciplina de administração de negócios, que trata de muitos níveis e temas relacionados à gestão por processos de negócio, desde a descoberta de processos, passando pela análise e melhoria de processos de negócio, implementação de processos de negócio (com ou sem suporte tecnológico) e muito mais, sob uma perspectiva organizacional. Não se deixe enganar pela sopa de letras – apesar de estarem relacionadas a “Business Process”, BPM e BPEL são coisas diferentes.

Dentro da disciplina de BPM há uma área de conhecimento que estuda como a tecnologia pode apoiar a análise, execução e controle dos processos de negócio, onde encontramos muitos produtos, comumente denominados de BPM Suítes (BPMS), tais como Oracle BPM, IBM BPM, Tibco, Pega e outros (http://bpm-directory.omg.org/). Acreditamos que aqui é onde muitas pessoas acabam confundindo-se sobre o que BPM realmente é – quando fornecedores usam a expressão “BPM” para simplesmente se referir a seus produtos.

Estes produtos de BPM, que são os BPM Suítes, usam diferentes padrões para automatizar processos. Alguns executam processos usando BPEL (Business Process Execution Language), outros executam processos interpretando BPMN (Business Process Model and Notation), e ainda há outros usam sua própria linguagem de workflow para automatizar e controlar processos.

Qual a melhor solução dependerá de uma série de questões que precisam ser avaliadas em conjunto quando sua empresa for selecionaro BPMS a ser adotado pela organização. Confira no artigo A difícil tarefa de escolher uma plataforma BPM que cuidados recomendamos para fazer uma boa escolha.

Respondendo dúvidas em BPMN: Desenhar processo na vertical ou horizontal?

A definição sobre a orientação vertical ou horizontal para diagramas na notação BPMN, sempre foi, desde sua criação, um dos aspectos mais questionados pelos analistas e modeladores de processos.

Um de nossos leitores recentemente enviou a seguinte questão:

“Sei que a boa prática é desenhar o processo da esquerda para a direita, correto?
Porém estou me deparando com alguns processos longos que vão dar muito trabalho fazer nesta ordem e acredito que ficará mais fácil visualizar de cima para baixo.
O que vocês acham sobre isso? Há alguma regra? O que vocês orientam?”

Embora não seja obrigatório em BPMN, swimlanes (pools e lanes) são muito utilizadas pois possibilitam a estruturação visual do fluxo, de forma a apoiar a interpretação do mesmo. Através delas, é possível identificar facilmente quem é responsável por executar cada tarefa, quem são os atores do processo e que participantes externos colaboram com o processo.

Em nosso blog, já falamos sobre pools e lanes em postagens como:

A especificação da notação (http://www.omg.org/spec/BPMN/2.0/PDF/) define o uso de swimlanes como não obrigatório, e que estes elementos podem ser usados para organizar o processo visualmente tanto na horizontal quanto na vertical.

Muitas vezes, o analista que realiza a modelagem de processo já utilizou alguma outra notação ou metodologia com elementos semelhantes às pools e lanes de BPMN, como eEPC e fluxogramas. Nestas duas notações, o processo é comumente representado na vertical. Assim, é mais natural para estes profissionais elaborar o processo nesta visão.

Entretanto, a maior parte dos exemplos que encontramos na bibliografia e na web sobre BPMN utiliza a representação na horizontal. Isto se dá porque na cultura ocidental temos o reflexo da leitura da esquerda para a direita. É uma percepção ligada à compreensão da sequência de ações. Assim, a distribuição do processo em uma estrutura de pool e lanes horizontal permite uma melhor distribuição das tarefas nesta visão

Um exemplo bastante simples de processo modelado com swimlanes na horizontal. À medida que se agreguem novas atividades ao processo, há a uma tendência de aumento do diagrama para a esquerda. Em um diagrama com colaboração, outras pools podem ser adicionadas, geralmente abaixo e acima da pool que contém o processo.

O mesmo processo do exemplo acima, representado com swimlanes verticais. A leitura do fluxo navega para a esquerda mas em alguns momentos precisa ir na "contra-mão" da leitura normal. A tendência de aumento é para baixo, mas novas lanes podem ser agregadas aumentando sua largura. Em um diagrama com colaboração, outras pools podem ser agregadas, geralmente nas laterais da pool que contém o processo.

Existe ainda uma abordagem de fluxo limpo do processo, em que pools e lanes não são utilizadas. Essa abordagem é mais usual quando o processo é modelado com visão de orquestração, por exemplo, em que suas atividades são na verdade uma sequência de processos, ou sub-processos. Neste nível de visão sobre o processo de negócio, é mais relevante identificar os processos e como estão relacionados do que quem são os envolvidos nestas tarefas, já que os atores já estarão claros nos diagramas dos respectivos processos.

Apesar da flexibilidade oferecida pela especificação oficial da notação, em geral recomenda-se a documentação do processo com pool e lanes na horizontal, seja pelo aspecto do conforto natural da leitura do fluxo ou mesmo por restrições de ferramentas (alguns produtos amplamente utilizados no mercado para representar diagramas de processos não permitem desenhar pools e lanes verticais, apenas horizontais).

Se o diagrama do processo tende a se tornar grande, a resposta não está na definição vertical ou horizontal do diagrama, mas na capacidade de abstrair tarefas em conjuntos através de subprocessos. Com isso, o modelo talvez acabará ganhando um ou dois níveis a mais, mas ao mesmo tempo temos com isso um diagrama com visão mais objetiva sobre o processo de negócio (veja mais sobre esta abordagem neste artigo, em orquestração de processos).

Independente da escolha, nossa principal recomendação é que esta definição deve fazer parte do guia de estilos de modelagem da organização, ou seja: vertical ou horizontal – o importante é manter um padrão a ser adotado em todos os diagramas de processos  de negócio documentados para a empresa.

 


Aprenda a utilizar todo o potencial da notação BPMN em exercícios práticos e avançados com nossos instrutores!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br

Desafios de Projetos: Mapeamento Conduzidos por Facilitadores das próprias Áreas de Negócio

Dando andamento ao assunto apresentado no artigo Vale a Pena Mapear Todos os Processos da Organização? gostaríamos de falar um pouco sobre uma iniciativa que tem aparecido como alternativa para as empresas que desejam mapear os seus processos sem a necessidade de realizar um investimento pesado em consultoria: a busca pela capacitação dos lideres funcionais de suas área de negócio com o objetivo de habilitá-los ao mapeamento de seus processos!

Não há dúvidas que esta abordagem tem um apelo bastante interessante sob vários aspectos, pois ela consegue com uma única iniciativa não só capacitar seus principais recursos como também economizar algumas centenas ou milhares de horas de consultoria com o uso da sua própria força de trabalho. Além disso, ninguém melhor do que os colaboradores das próprias áreas de negócio para saber quem deve ou não ser entrevistado, se o processo foi todo mapeado e se as informações que estão ali documentadas correspondem à realidade. Para completar, o projeto desta natureza tende a se tornar bastante ágil dado o paralelismo que podemos alcançar ao capacitar um recurso de cada área de negócio.

Mas nem tudo são flores, e este tipo de iniciativa está coberto de uma série de desafios muitas vezes desconhecidos ou ignorados pelos seus gestores. Longe de serem fatores de impedimento, tais desafios representam riscos significativos para o sucesso deste tipo de projeto, e se não forem corretamente mitigados, podem levar à perda de toda a iniciativa de processos dentro da organização. Confira a seguir alguns destes pontos de atenção:

  1. Capacitar as áreas de Negócio nas ferramentas e habilidades do mapeamento de processos: Este aqui é um dos maiores riscos deste tipo de projeto. Na maioria das vezes, vemos as empresas preocupadas em capacitar os seus colaboradores no uso das ferramentas e notações para o mapeamento de processos. Contudo, fazendo uma analogia, muitas vezes esquecemos que saber escrever é bastante diferente de saber redigir: uma pessoa que sabe escrever não tem, necessariamente, a habilidade de fazer uma redação. Na escola, levamos um ano aprendendo a escrever e passamos outros 8 anos aprendendo a redigir! A mesma situação ocorre com o mapeamento de processos: O aprendizado de uma notação não garante que este colaborador saberá expressar adequadamente a realidade dos processos de negócio. Assim, tão ou mais importante que o treinamento sobre a notação ou ferramenta deverá ser o treinamento das habilidades necessárias para que o colaborador possa expressar corretamente o seu processo de negócio!
  2. Garantir que todos os envolvidos descreverão os processos num mesmo nível de detalhe: Apesar de muito semelhante à questão anterior, este tópico merece uma atenção especial por ser complementar às habilidades necessárias. Mesmo em situações em que toda a equipe está capacitada para o mapeamento de processos, faz-se necessário garantir que todos irão documentar os seus processos no nível de detalhes esperado pelo projeto. Se tal preocupação já é fundamental com uma equipe de analistas de processos “profissionais”, torna-se ainda mais importante quando capacitamos uma série de pessoas com experiências profissionais e acadêmicas distintas que não estão habituadas a fazer este tipo de trabalho. O exemplo abaixo demonstra um pouco do que queremos dizer: o mesmo processo, documentado em níveis de detalhe diferentes.
  3. Evitar que as discordâncias do dia-a-dia de trabalho atrapalhem o mapeamento: À medida que envolvemos pessoas que estão inseridas dentro do próprio processo, é muito provável que este ganho de conhecimento seja acompanhando do que chamamos de perda da isenção. Esta perda pode se refletir de duas formas. A primeira está no risco do facilitador mapear uma única visão do processo, considerada por ele correta, em detrimento a outras visões. E a segunda é o risco de que conflitos históricos entre os envolvidos no processo apareçam de forma negativa, prejudicando ou inviabilizando o trabalho. Estas situações obviamente podem também aparecer com um facilitador externo ao processo, mas este costuma ter mais flexibilidade ao gerenciá-las à medida que esta pessoa está isenta do dia-a-dia e dos problemas do processo.
  4. Avaliar como será feito o mapeamento intra-departamental: Dada a natureza transversal dos processos, é natural que um determinado processo passe por diferentes áreas de negócio. Nesse sentido, deve-se evitar que a escolha de facilitadores por área de negócio acabe hierarquizando o processo de acordo com o organograma da organização. Para evitar estas situações, sugere-se adotar inicialmente uma abordagem top-down de mapeamento, de modo a identificar desde o início as áreas envolvidas, os responsáveis por cada etapa e como ocorrerá a unificação deste trabalho. Ou, numa outra abordagem, pode-se também delegar a um único facilitador a responsabilidade por mapear todo o processo, independente das áreas em que ele passe, mesmo que para isso ele tenha que contar com o apoio dos facilitadores de cada área de negócio envolvida.
  5. Garantir disponibilidade para o trabalho: Este é outro típico desafio de qualquer projeto de modelagem, mas que torna-se mais crítico quando os próprios usuários é que mapeiam os seus processos. Se muitas vezes já é difícil arranjar tempo para que os colaboradores descrevam o seu processo para um consultor externo, quem dirá em situações em que este consultor é um colega de trabalho! Neste quesito é importante que os gestores de cada área de negócio entendam a importância da iniciativa de mapeamento e se comprometam a exigir um prazo da sua equipe para evitar que este trabalho entre num ciclo de postergação infinita.
  6. Evitar que informações deixem de ser mapeadas: O que pode ser considerado um dos grandes benefícios do mapeamento de processos ser realizado por alguém de fora da área de negócio, na abordagem interna pode tornar-se um dos principais riscos: o de que, tendo a própria área de negócio o controle do que será ou não documentado, a mesma só represente no processo aquilo que, a seu critério, não compromete a análise sobre o seu desempenho. Para minimizar esta possibilidade é fundamental que a organização comunique claramente aos os seus colaboradores que o mapeamento não tem por objetivo achar culpados, mas sim alcançar o auto-conhecimento de modo que ela possa buscar maior eficiência e eficácia nas operações.
  7. Escolher adequadamente os Facilitadores: Para minimizar alguns dos desafios apresentados, a escolha adequada dos facilitadores de cada área de negócio é fundamental. Neste quesito, critérios como o conhecimento sobre o negócio tendem a ficar em segundo plano se comparados à capacidade de ouvir e negociar do facilitador. De igual importância deverá estar a habilidade deste facilitador em mapear estes processos, pois de nada adiantará um facilitador que entenda como o processo é feito e que não tenha habilidade de documentá-lo. Neste sentido, se desejável, uma boa prova pós treinamento é de grande valia para mitigar este risco.

Apesar dos inúmeros desafios, este artigo busca trazer à tona questões que devem ser acompanhadas por aqueles que buscam nesta forma de trabalho o sucesso para o mapeamento e documentação de seus processos de negócio.

Oracle BAM – Monitoramento instantâneo do negócio

Algumas tecnologias viram moda tão rapidamente que muitas empresas as adotam antes mesmo de o pessoal de negócios aprender o significado das siglas que as denominam. Este é sem dúvida o caso do BAM (Business Activity Monitoring) que muitas pessoas confundem com outras ferramentas como BI (Business Intelligence) e CEP (Complex Event Processing).

Mas o que é BAM e para que serve?

Business Activity MonitoringBAM é uma ferramenta de monitoramento da atividade do negócio através do acompanhamento em tempo real de indicadores. Isso possibilita a tomada de decisão de forma ágil a partir da análise desses indicadores assim como a execução de planos de contingência baseado em gatilhos previamente definidos, seja através do envio de alertas, execução de webservices, ou outras ações. Nesse artigo, vamos apresentar um visão geral do Oracle BAM.

 

Oracle BAM é um produto da suite Oracle Fusion Middleware que permite integração flexível com outros sistemas através de ODI (Oracle Data Integrator), webservices e conexões a diferentes bancos de dados, entre outras formas.

Uma grande vantagem do Oracle BAM é seu poder de manipulação de grandes volumes de dados, através do ADC (Active Data Cache), que podem ser capturados de diferentes bases de dados, de processos BPM e diversas outras fontes de informação.

Traduzindo todas estas informações e mudanças em elementos visuais, relatórios e alertas, o Oracle BAM tem sido utilizado por muitas empresas para monitorar desde ocorrências operacionais em ambientes de TI e infraestrutura (Service Desk, por exemplo), acompanhamento do volume de transações comerciais, alertas em desvios de processos de negócios, controle e execução de prazos de projetos complexos, entre muitos outros casos de sucesso.

A ferramenta foi idealizada para permitir a separação entre níveis de operação e acesso. Assim, suas funcionalidades principais são divididas basicamente em três visões:

BAM Architect é a interface onde o arquiteto de dados cria e gerencia os objetos de dados que contém as informações utilizadas nos gráficos e relatórios. Os objetos de dados são uma representação virtual das diversas origens de informações possíveis de forma consolidada. Também permite a utilização de cálculos de baixa e média complexidade sobre os dados, facilitando a apresentação e agrupamento das informações de interesse para o negócio.

 

BAM Active Studio é um ambiente de desenho onde os gráficos, os alertas, as conexões com webservices e o agendamento do envio de relatórios são realizados. A personalização da interface não é um ponto forte da ferramenta, mas o uso dos diversos templates e a combinação de diferentes estruturas existentes garantem, em conjunto, sua utilização em projetos de todos os tamanhos e para qualquer tipo de necessidade.

 

 

BAM Active Viewer é a ferramenta para a visualização dos relatórios e gráficos. É o painel de monitoramento propriamente dito, onde é realizado o controle de acesso por usuário, por relatório, por pasta de relatórios, etc.

 

 

Além da limitação de acesso a determinados relatórios por usuário, inclusive de forma integrada a servidores LDAP, o Oracle BAM permite ainda restringir a visualização de dados dos relatórios por usuário ou pelos grupos dos quais o mesmo faz parte. Assim, é possível permitir que um gerente acesse o mesmo relatório da direção da empresa, porém exibindo somente as informações da sua filial ou região.

Duas grandes funcionalidades que merecem destaque são o envio agendado de relatórios por email e o disparo de alertas, com diversas ações associadas (envio de relatórios e informações por email, invocação de serviços externos para objetivos específicos, execução de cenários ODI, etc), periodicamente ou atendendo à condições específicas previamente definidas (quando determinado índice atinge um nível mínimo, por exemplo).

Essa pró-atividade e resposta instantânea às mudanças sensíveis ao negócio são os instrumentos de gestão que conferem a agilidade e assertividade na tomada de decisões, bem como a execução de planos de contingências no momento apropriado.