Processos, Pessoas e Transformação Digital

O que será que acontece quando colocamos, numa mesma mesa, um especialista em Processos, outro em Internet das coisas e um terceiro em coach pessoal e profissional?

Como o avanço da tecnologia irá impactar a vida das pessoas? Como processos e tecnologias podem se integrar? Como “coisas”, processos e pessoas trabalharão juntas? Como ficam as pessoas diante de um cenário de profunda de transformação?

Estes entre outros assuntos são discutidos  no programa de rádio #Inovação, conduzido Debora Vilella, que entrevista Eduardo Britto, Diretor da iProcess e especialista em Gestão por Processos; Giovanni Comunello, CEO da iTinvent e especialista em Internet das Coisas (IOT) e Ana Paula Thiesen, Diretora da Insight Desenvolvimento e  Master Coach Pessoal & Profissional.

E se você deseja se preparar para liderar a transformação digital na sua organização, conheça o curso de TRANSFORMAÇÃO DIGITAL ORIENTADA A PROCESSOS,

um programa de treinamento à distância criado para formar os profissionais que conduzirão as organizações para transformar os seus processos com o uso da tecnologia, aliando inovação a eficiência.

Inscreva-se na lista de contatos da iProcess para receber notícias sobre cursos, treinamentos, novas publicações no blog e datas dos próximos webinares! Basta preencher o formulário de contato no site da iProcess: http://www.iprocess.com.br/contato

 

Problemas comuns na modelagem de processos em BPMN – I – Atividades de transferência do processo

Vamos iniciar hoje uma série de artigos que pretendemos publicar ao longo dos próximos meses, falando especificamente de erros, problemas e inconsistências básicas de modelagem, comuns de ocorrer quando começamos a modelar processos e ainda não conhecemos muito bem a notação BPMN.

Pra começar, vamos falar de uma questão muito frequente, que se refere ao encaminhamento de um papel do processo para outro. Vamos imaginar um processo de Viagens, que foi descrito pela área de negócio da seguinte forma:

  1. Um colaborador solicita a viagem
  2. Solicitação de viagem é encaminhada (atenção especial ao uso desta palavra) para uma área interna chamada “Administrativo”, que tem a responsabilidade de pesquisar e mandar cotações da viagem para o solicitante
  3. Cotações são então encaminhadas de volta para o Solicitante avaliar
  4. Se a cotação for aprovada, processo é direcionado novamente para setor Administrativo comprar os tickets, do contrário processo é direcionado de volta para o setor Administrativo refazer as cotações

Agora veja como o modelador decidiu, inicialmente, representar este processo:

Note que no caso da primeira transferência do processo, do papel “Solicitante” para o papel “Administrativo”, foram criadas 2 atividades:

  • Uma atividade na raia do “Solicitante”, chamada “Encaminhar Viagem para Cotação para Administrativo”
  • Uma atividade na raia do “Administrativo”, chamada “Receber Viagem para Cotação do Solicitante”

O mesmo comportamento foi modelado posteriormente, na transferência do papel “Administrativo” para o papel “Solicitante”, com as atividades “Encaminhar Cotações para Solicitante” e “Receber Cotações do Administrativo”, respectivamente.

Este trecho do processo não está errado do ponto de vista da notação BPMN. Mas o que temos aqui, no entanto, são atividades que na prática não precisariam existir. O modelador optou por explicitar a passagem de bastão de um papel a outro através de atividades de transferência do processo, mas isso não é necessário: em BPMN, o próprio fluxo de sequencia já tem o papel de representar/realizar esta transferência de responsabilidade dentro do processo. Neste caso, como ficaria o desenho do processo ajustado? Veja a seguir:
Perceba que com esta mudança, deixamos o processo mais simples e limpo, ao mesmo tempo mantemos o comportamento esperado.

O conceito de utilizar apenas fluxos de sequência para representar a transferência de atividades dentro do processo costuma se aplicar mesmo que exista, de fato, um encaminhamento físico sendo realizado. Por exemplo, este processo de viagens poderia ser realizado em papel, implicando que o solicitante tivesse que levar fisicamente a solicitação impressa e assinada para o setor Administrativo. Mas mesmo neste caso não seria necessário modelar as atividades de transferência. Caso fosse necessário ressaltar este aspecto de encaminhamento físico de algo, poderiam ser utilizados outros recursos para representar, como adicionar uma anotação ao processo ou documentar esta característica do processo nos procedimentos das atividades.

Um cenário em que poderia ser necessária uma atividade para encaminhar ou receber o processo seria num caso em que as atividades são reconhecidamente manuais, realizadas no plano físico, e que possuem procedimentos adicionais, como protocolar a chamada do documento esperado, carimbar, etc. Por exemplo, num processo logístico poderíamos ter uma atividade da área de “Recebimento” chamada “Enviar material para Estoque”, onde “Estoque” é uma área da organização:

Note que, em linhas gerais, continuamos falando do mesmo exemplo citado no Processo de Viagens: a passagem de bastão de uma área para outra. Se o ato de encaminhamento físico do material de um lugar para outro envolve procedimentos adicionais e tem um tempo de execução relevante (vamos imaginar neste caso uma grande planta industrial, em que seria necessário percorrer a distância entre um setor para outro), ou seja, a atividade consome efetivamente recursos, então neste caso faria mais sentido criar uma atividade de transferência.

Fique ligado para outros artigos desta série no futuro! ;-)

Do processo analógico ao digital: como as novas tecnologias digitais impactarão os processos da sua organização

Neste webinar, Eduardo Britto, Diretor de Consultoria da iProcess, mostra como as empresas podem vencer seus desafios culturais ou organizacionais para transformar os seus processos analógicos em experiências digitais para os seus clientes.

Aqui você assiste ao vídeo gravado do evento apresentado em parceria com a Oracle, ao vivo pela internet para centenas de profissionais, no dia 10/10/2017.



Confira abaixo as respostas para perguntas enviadas por nossos participantes durante o evento:

Pergunta: Qual é a solução de BPMS demonstrada? Oracle BPM?
Resposta: O Oracle BPM é a solução on premise para automação de processos da Oracle, mas neste webinar demonstramos o processo automatizado com o produto Oracle PCS (Oracle Process Cloud Services), que é uma solução que roda totalmente em um ambiente de nuvem.

Pergunta: A ferramenta apresentada é personalizada ou seria uma plataforma da oracle para automatização de processos?
Resposta: O Oracle PCS é uma plataforma de desenvolvimento de processos; a partir dela é possível automatizar todo tipo de processo, como um processo de sinistro (demonstrado no vídeo) até um processo de compras, ou então um processo de viagens, ou de recrutamento e seleção… É tudo uma questão de você planejar como usar a plataforma para buscar a melhoria e a transformação dos seus processos.

Pergunta: Gostaria de saber como vocês fazem a abordagem das empresas para prestação de serviços? como a empresa deve proceder para iniciar a conversa sobre o mesmo?
Resposta: Diríamos que o mais importante é avaliarmos como seriam os nossos processos. Certamente um processo analógico (não digital) tem um grande potencial de ganho com a automação. Então o primeiro ponto é olhar e refletir como agora trabalhar com esses processos em uma visão digital. E a base para isso deve ser a experiencia o seu cliente. Você deve chamar o que dizemos em BPM de “outside in” – olhar na experiência do cliente no contato com seu processo e avaliar como pode torná-la mais inovadora e fácil para seu cliente e a partir daí pensar na automação. Evidentemente, a partir daqui precisará pensar em conjuntos de integrações e em como automatizar ao máximo o que for possível em seu processo.

Pergunta: Como elaborar uma mudança do ERP em Cliente Servidor para ERP na Nuvem?
Resposta: Podemos fazer um gancho aqui com o tema da primeira pergunta, podemos integrar os processos com ERP tanto on premise como na nuvem; e entendemos que em breve praticamente todos os sistemas estarão na nuvem, o que reduz bastante os custos de manter uma infraestrutura própria só para manter as informações. Mas ainda no cenário atual, grande parte dos ERPs já possuem serviços para integração e utilização pelos processos automatizados.

Pergunta: Estou envolvido em um processo de automação de uma empresa de terceirização de serviços, e gostaria de saber se existe algum pattern para auxiliar na automação deste processo. Mesmo considerando a complexidade de cada domínio.
Resposta: Podemos dizer que existem duas situações – processos já prontos e experiências de boas práticas de diversas organizações. Na iProcess já trabalhamos em centenas de processos nestes 17 anos. Nesses projetos, muitas vezes esses processos se repetiram, e foram discutidos, e identificamos o que era bom e o que não era bom e como poderiam gerar ganhos. Hoje elaboramos um pacote de 40 processos que vão de processos administrativos como processos voltados para áreas de negócio específicos, como esteira de crédito, ou processos jurídicos de avaliação de contratos, que podem servir como um ponto de partida para construir uma visão customizada com base na experiência da iProcess e que possibilitam entregar ganhos muito mais ágeis para cada cliente.

  • Inscreva-se na lista de contatos da iProcess para receber notícias sobre cursos, treinamentos, novas publicações no blog e datas dos próximos webinares!
    Basta preencher o formulário de contato no site da iProcess:
    http://www.iprocess.com.br/contato

Seja o profissional que vai liderar a Transformação Digital nos negócios da sua empresa

A equipe da iProcess orgulhosamente apresenta o curso de
TRANSFORMAÇÃO DIGITAL ORIENTADA A PROCESSOS,
um programa de treinamento à distância criado para formar os profissionais que conduzirão as organizações para transformar os seus processos com o uso da tecnologia, aliando inovação a eficiência.

Participe desta experiência que alia a teoria à prática, com dezenas vídeo aulas, artigos e cases alinhados com demonstrações de ferramentas e exercícios práticos de modelagem e automação em soluções de diferentes fornecedores, formando conhecimento através de uma vivência que facilitará o desenvolvimento da transformação digital na sua organização.

  • Conheça os conceitos da transformação digital, as tecnologias que viabilizam esta transformação e os benefícios da sua aplicação.
  • Entenda como as plataformas de processos podem se integrar aos sistemas de informação da organização.
  • Aprenda como fazer esta transformação, estudando e aplicando técnicas e ferramentas de redesenho tecnológico, que multiplicam a eficiência dos processos com o uso da tecnologia.
  • Compreenda os principais problemas e desafios e prepare-se para a jornada da transformação digital, analisando como as áreas de negócio podem liderar este movimento.
  • Saiba como aplicar uma metodologia ágil de transformação que traga ganhos rápidos, crescentes e constantes.

Conheça mais, inscreva-se e participe!

Quero me inscrever agora

A parceria entre os processos automatizados e os sistemas já existentes em uma organização

Podemos dizer, a partir da experiência da equipe iProcess em automação de processos, que os processos automatizados e os sistemas informatizados das organizações não competem entre si, eles formam uma parceria, se complementam. Dizemos isto porque são nos sistemas já existentes nas organizações que os processos obtém as informações necessárias para a execução dos fluxos de trabalho, utilizando-se para isto de uma camada de integração. Daí o motivo de acreditarmos que ambos se complementam.

Os sistemas já existentes, que também chamamos de legado, não são descontinuados ao serem integrados ao processo automatizado. O processo será responsável pela conexão entre estes sistemas e os usuários do processo. Através do BPMS (Business Process Management Suite ou System), uma organização automatiza processos para aumentar seu nível de controle e monitoramento na execução dos processos. Assim, um BPMS atua como orquestrador da execução dos processos entre pessoas e sistemas, definindo o fluxo do trabalho e da informação entre estes participantes.

Desta forma, os sistemas se preocupam com o cadastro, atualização e consulta das informações armazenadas em base de dados e os processos com a sua distribuição, tendo o foco na sequência de etapas, prazos, distribuição das atividades, integridade do processo e em fornecer o melhor ambiente possível para que as atividades sejam executadas. Em alguns casos, se faz necessário o armazenamento das informações ao longo do processo, mas são informações específicas para o contexto das instâncias do processo, que servem para controle de estado do fluxo e logs de atividades, por exemplo.

Quando se automatiza um processo, na etapa de levantamento das informações, é que verificamos como a parceria entre os sistemas já existentes na empresa e o processo utilizando BPMS se dará. Algumas das informações levantadas nesta etapa são:

  • Informações consumidas e informações geradas pelo processo, isto é, quais as informações que deverão ser recebidas pelo processo oriundas de sistemas e quais as informações que eventualmente deverão ser enviadas para gravação em sistemas existentes da organização, como, por exemplo, ERP, sistemas contábeis ou cadastros corporativos.
  • Pontos de integração, isto é, em quais atividades do processo deverão ser obtidas/geradas informações que alimentam os sistemas legados.
  • Como que o processo e os sistemas legados conversarão entre si, que normalmente ocorre através da camada de integração, utilizando serviços especialmente construídos para isto.

A implementação de BPMS nas organizações não deve ser orientada a substituir total ou parcialmente os sistemas atuais esperando-se que passe eventualmente a ser o repositório central das informações da organização. O BPMS não é a fonte principal das informações que estão sendo manipuladas, mas atua principalmente como integrador delas, buscando e enviando informações para outros sistemas durante a execução dos processos.

A iProcess disponibiliza em sua plataforma EAD mais informações sobre este assunto, através do Curso TDP – Transformação Digital Orientada a Processos.

Convite para webinar: Do processo analógico ao digital

A iProcess apresenta, em parceria com a Oracle, o webinar:
Do processo analógico ao digital:
Saiba como as novas tecnologias digitais impactarão
os processos da sua organização.

 Com o uso cada vez mais presente em nosso dia-a-dia de tecnologias como Mobile, Internet das Coisas (IoT), computação na nuvem e redes sociais, a digitalização dos processos tornou-se uma exigência do mercado consumidor, que busca formas mais fáceis de interagir com as organizações.

A oferta de soluções cada vez mais amigáveis e próximas ao negócio, oferecidas em ambiente cloud, está tornando a transformação dos processos para o mundo digital cada vez mais acessível a organizações de todo porte.

Neste webinar, Eduardo Britto, Diretor de Consultoria da iProcess, mostrará como as empresas podem vencer seus desafios culturais ou organizacionais para transformar os seus processos analógicos em experiências digitais para os seus clientes.

Participe, o evento é gratuito e será transmitido online ao vivo pela internet!


Apresentado por:
Eduardo Britto, Diretor de Consultoria da iProcess

Data:
10 de outubro de 2017
Horário: 10h (BRT)

Vagas limitadas. Inscreva-se já:

Em que nível devo modelar meu processo?

Uma das principais atividades na transformação de um processo é a sua modelagem. Seja no princípio do projeto, para representar a sua situação atual (AS IS), a criação de modelos para simulação ou comparação de variações, a definição da sua visão de futuro (TO BE) ou o fluxo a ser implementado para automação, a modelagem é importante na representação do processo que está sendo detalhado ou melhorado.

A representação visual do modelo utilizando uma notação gráfica como BPMN é um dos seus aspectos chave da modelagem. O nível de detalhe das atividades no diagrama de processos, entretanto, é frequentemente tema de debate entre os profissionais de Processos.

A notação BPMN, apesar de poderosa e de ter uma gramática bem definida quanto ao uso dos seus elementos, não estabelece qual seria o nível ideal de modelagem do processo. Ela define formalmente que “uma atividade representa um trabalho”. Mas devemos ir por uma abordagem mais alto nível do significado de trabalho (o “trabalho” é aquilo feito por uma área inteira?) ou mais baixo nível (o “trabalho” é cada ação realizada por alguém para atender ao resultado objetivo do processo?).

Não há uma regra para isso, e na verdade cada tipo de modelo pode requerer um nível de detalhe diferente no mapeamento do processo, de acordo com o propósito para que serve aquele modelo.

Por exemplo, em uma reunião no qual estamos buscando um entendimento amplo sobre o processo, com uma visão ponta a ponta em que possamos identificar suas principais etapas, um nível alto seria o mais apropriado.
Mas e quando vamos mapear um processo que será usado como material de treinamento, num manual de processos ou para descrever o trabalho de uma determinada etapa?

Existem alguns critérios que podem ser interessantes de serem questionados pela equipe ao definir o nível de modelagem do processo que estamos criando.

Como oportunidade de reflexão, um de nossos leitores contribuiu recentemente com dois exemplos de processos. Vamos tomar por base então o seguinte exemplo:

1) Nesse fluxo, podemos perceber que o mapeamento está em nível de procedimento, não de trabalho. O trabalho seria, por exemplo, “Avaliar baixa”, que envolve esta sequência de procedimentos: Consultar arrecadações, selecionar arrecadação, …, até confirmar baixa manual. Embora exista uma sequência entre eles, pode ser uma sequência flexível, em que a ordem dos itens pode eventualmente mudar na operação da pessoa no sistema. Esse nível de detalhe é bem comum de ver em processos modelados por profissionais de TI. Cuidado para não confundir o fluxo de trabalho com o fluxo de interação com sistema. Para esse segundo, devemos utilizar UML (Diagrama de sequência ou diagrama de atividades ou até mesmo passos de um Caso de Uso).

2) Pensando no por quê modelamos processos no nível de operação, geralmente fazemos isso para entender o processo e ter um parâmetro para avaliar o seu desempenho, certo? Assim, normalmente as tarefas são utilizadas para determinar o trabalho do processo, onde podemos medir o tempo e custo da sua realização. Neste sentido, será que realmente interessaria para a organização mensurar detalhadamente quanto tempo leva para executar cada um desses passos? Ou é mais importante entender quanto tempo, dentro da dinâmica do processo, um profissional leva para realizar a análise e a baixa, de uma forma consolidada?

3) Geralmente quando mapeamos nesse baixo nível, fica mais difícil representar as exceções. Por exemplo, no caso em que qualquer um desses passos seja possível o ator voltar atrás em alguma ação. Nesse fluxo, teríamos que desenhar também todas as possibilidades de voltar e refazer algum passo. Ou seja, após ele selecionar o ingresso, ele terá que selecionar uma parcela. Mas se ao selecionar a parcela ele se der conta que escolheu o lançamento errado, ele poderia voltar pra selecionar outro lançamento?

4) Um outro fator a considerar é a manutenibilidade do processo. Queremos dizer com isso que qualquer mínima alteração nas ferramentas podem fazer com que você tenha que criar uma nova versão do seu diagrama de processo, tornando a manutenibilidade da documentação mais custosa e também dando mais chance para ela se tornar rapidamente obsoleta.
Se você tem uma tarefa “Avaliar baixa” e nela descreve os procedimentos, e a sua organização mudar do sistema XPTO para o sistema MEGAXPTO, o trabalho feito pela organização continuará sendo o mesmo, que é avaliar a baixa. O processo não mudou, o que mudou foi a ferramenta. Assim, no nível de mapeamento do trabalho, a manutenção fica mais fácil porque não precisará mudar o fluxo, apenas atualizar o procedimento (passos realizados naquela atividade, que podem ser descritivos complementares ao desenho do fluxo).

Se o plano for automatizar o processo, esses critérios podem ser ainda mais relevantes, porque o motor de processos é muito literal na interpretação do modelo. Confira uma outra reflexão semelhante que já fizemos sobre o assunto aqui no Blog da iProcess no artigo: Estudo de Caso: Automatizar o processo (ou não)? Eis a questão!

 

Como representar exceções no fluxo do processo em BPMN?

Com alguns anos de experiência participando de projetos e treinamentos envolvendo processos de negócio, percebemos situações recorrentes quanto à aplicação de exceções na lógica do fluxo do processo de negócio que está sendo desenhado e documentado. A boa modelagem de processos de negócio em BPMN é o resultado do domínio da notação (estudo e compreensão dos elementos), mas para uma modelagem que represente corretamente uma situação de negócio, não basta saber aplicar as regras da notação BPMN, conhecer seus símbolos e o que cada um significa. É preciso também entender os detalhes da lógica do processo de negócio em questão.

Vou aproveitar o tema para repassar as regras da notação BPMN relacionadas à representação de exceções durante a execução de atividades, apresentar algumas ilustrações, de forma a esclarecer algumas dúvidas e confusões comuns quanto à representação da lógica do negócio.  

Como já tratado em outros artigos, atividades retratam o comportamento ou trabalho realizado em um contexto do processo, gerando uma transformação (resultado) ao final deste trabalho. Atividades que podem gerar mais de um resultado normalmente são testadas, pois levam o fluxo por caminhos diferentes (alternativos ou paralelos). Para contextualizar, usarei como exemplo um processo fictício de liberação de crédito, representado abaixo. 

No exemplo, o Processo de Liberação de Crédito realiza dois trabalhos para identificar se o crédito pode ou não ser aprovado. O Processo consiste em analisar se comprador possui restrições de crédito e limite para liberação de crédito.

O processo possui duas tarefas que analisam se o solicitante pode receber o crédito solicitado. A primeira tarefa Consultar situação de crédito (Tarefa de Usuário) analisa se solicitante está em situação de inadimplência ou sem débitos. Caso a tarefa resulte por situação de crédito por inadimplência, o processo é automaticamente finalizado por solicitação reprovada. Se não houver débito(s) o processo segue para verificação do limite. A segunda tarefa Verificar limite de crédito (Tarefa de Serviço) analisa se o solicitante possui limite para liberação de crédito solicitado. Caso o limite de crédito esteja dentro do limite solicitado, o processo é finalizado por solicitação aprovada. Se o limite de crédito estiver abaixo do solicitado, o processo é automaticamente finalizado por solicitação reprovada.

Mapeando exceções nas atividades do fluxo do processo

Descrevi acima um fluxo típico de processo de liberação de crédito, onde a situação de negócio está bem explícita em cada uma de suas tarefas, tanto no que consiste o trabalho realizado, quanto suas saídas (possíveis resultados). Porém algumas situações fora do comum, que não se espera que aconteçam (mas que podem acontecer) foram ignoradas. Estas situações são conhecidas também por exceções. Vejamos algumas situações que deverão ser representadas no fluxo do processo de liberação de crédito.

Situação 1

A tarefa Consultar situação de crédito deve conter um prazo para execução e, caso o prazo seja excedido, uma notificação deverá ser disparada para o responsável.

Situação 2

Caso uma informação de referência da tarefa Consultar situação de crédito estiver incorreta (ex. cpf inválido) e não for possível finalizar a tarefa, deverá ser realizado um tratamento para correção da informação.

Situação 3

Caso o serviço utilizado na tarefa Verificar limite de crédito estiver indisponível ou apresentar erro na sua execução impossibilitando a finalização da tarefa, uma notificação deverá ser disparada para o responsável, finalizando o processo por indisponibilidade no sistema.

Imagine que em nível de negócio todas estas situações devem ser previstas e representadas no fluxo do processo. Como representar estas situações? Qual seria a forma mais adequada de representá-las, levando em conta a lógica do processo e as regras da especificação BPMN 2.0?

Começaremos avaliando, neste artigo, apenas a Situação 1.

Antes de apresentar a solução, mostraremos uma confusão na hora de desenhar esta situação. Um erro bastante comum que presenciamos ao corrigir os exercícios dos alunos nos nossos cursos e por vezes também identificado em processos de melhoria, é a forma como é aplicado o controle de prazos nas tarefas, que geralmente é representado com um evento intermediário diretamente no fluxo do processo, posicionado logo após a tarefa que deveria ser controlada (já vimos casos que o prazo também havia sido posicionado antes da tarefa).

Aqui começa a primeira confusão: o evento que controla o prazo deve ser representado como uma exceção à saída da tarefa. Veremos mais abaixo, nas regras de especificação da notação, que este tipo de situação deve ser representado por um evento anexado a borda da tarefa a ser controlada, e não diretamente no fluxo do processo. Neste caso o evento de tempo deve ser acionado somente se a tarefa não tiver sido executada dentro do prazo e nunca obrigar, como modelado no exemplo abaixo, que o fluxo aguarde sempre por um período de tempo, desta forma paralisando o fluxo. Outro erro, também demonstrado na imagem abaixo, está no gateway que testa a situação de crédito. Veja que foi incluída uma nova saída Em atraso que deverá ser acionada caso a tarefa seja executada após o prazo. Da forma como o fluxo acima foi modelado, a tarefa Consultar situação de crédito não possui, de fato, um controle de tempo. Ela deve ser necessariamente executada para que o fluxo prossiga. Após a conclusão da tarefa é apresentado um controle de tempo contido diretamente no fluxo do processo, que obriga ao processo uma parada no fluxo, por dois (2) dias.

Vejam que o processo acima é válido do ponto de vista da notação BPM. Porém ele não representa corretamente a situação do negócio proposto na situação 1, pois não deveria obrigar a parada do fluxo, e sim controlar o tempo da tarefa Consultar situação de crédito.

Solução proposta para Situação 1:

  1. A tarefa deverá possuir uma condição de tempo associada à sua execução.
  2. A tarefa, mesmo em atraso, poderá ser executada (não deverá ser cancelada).
  3. A tarefa, caindo em atraso, deverá executar um fluxo de exceção para disparo de uma notificação de atraso para o responsável.

Regras da especificação BPMN 2.0:

  • Segundo a especificação oficial da notação BPMN 2.0, quando uma atividade possui prazo para execução, deve ser representado através do elemento Evento Intermediário do tipo Tempo (Timer), conectado à borda da atividade.
  • No momento que a atividade for iniciada, o evento será monitorado e controlado seu tempo.
  • Se o evento for disparado, o fluxo mapeado a partir do evento é executado.
  • A interrupção da tarefa é representada através do desenho da borda do evento. Neste caso, deve conter a borda tracejada, que demonstra que a tarefa, mesmo em atraso, poderá ser executada. A borda contínua representa que, ao ser disparado o evento de tempo, a tarefa seria cancelada.

Levando em conta a lógica desejada para o processo e as regras da especificação BPMN, apresentamos abaixo a solução mais adequada para a situação 1:  O controle do prazo para execução da tarefa está representado corretamente pela exceção – neste caso o evento intermediário de tempo anexado a borda da tarefa. Como já dito, assim que a tarefa é iniciada, o evento passa a controlar seu tempo e caso a tarefa não seja executada e finalizada em até dois (2) dias, o evento de tempo é disparado e o fluxo segue para o próximo ponto onde dispara uma notificação de atraso ao responsável.

Continuaremos em um próximo artigo o assunto, falando a respeito da segunda e terceira situações, bem como as confusões mais comuns na hora de desenhá-las. Fique ligado!

 

 

Mais um editor BPMN free: Modelador do Bonita BPM

Em nosso artigo sobre 7 Ferramentas Gratuitas para Criar Diagramas de Processos com BPMN deixamos de fora o modelador do Bonita BPM por se tratar de uma ferramenta integrada ao BPMS da Bonitasoft. Porém, devido ao grande número de sugestões para que incluíssemos esse modelador em nossa análise, decidimos exibir aqui uma breve apresentação.

Em primeiro lugar, como já foi dito, a suite Bonita BPM Community deve ser instalada completamente para que se possa testar o modelador. Após a instalação padrão (que não permite nenhuma personalização além do diretório de instalação) você abre a aplicação e é exibida a tela de boas-vindas do BPMS. Ao clicar no item de menu <New Diagram>, o modelador de processos do Bonita BPM é exibido.

Bonita BPM Process Modeler

Modelador de processos do Bonita BPM

Como as demais ferramentas de modelagem, o modelador do Bonita BPM é composto por um barra de menu (contendo itens padrão), uma paleta de elementos BPMN, a área de modelagem e um conjunto de guias para documentação e configuração dos elementos dos modelos de processos.

A paleta de elementos, que foi um dos focos da nossa investigação, não contém todos os elementos da notação. Sentimos falta, por exemplo, das atarefas manuais (manual task) e tarefas de regra de negócios (business rule task), assim como os subprocessos embutidos/incorporados (embbeded): se você quiser fazer hierarquização de processos, abstraindo conjuntos de atividades relacionadas, terá de usar subprocessos reusáveis, que na ferramenta são identificadas como Call Activities.

Muitos outros elementos não estão presentes, mas pensando em automação de processos não fazem tanta falta – considere nosso artigo Um BPMN para cada propósito de modelagem de processos onde citamos o artigo de Muehlen e Recker intitulado “How Much Language is Enough?”.

Em resumo, na modelagem de processos para automação (que é a finalidade da ferramenta) o conjunto de elementos implementados pelo Bonitasoft parece ser suficiente, mas se você deseja usar o modelador para fazer modelos de negócio com todo o poder de expressão da BPMN 2.0, vai sentir falta de muitos elementos.

Quanto à usabilidade do software, nossa avaliação é de que o modelador de processos do Bonita BPM é eficaz, pois apesar da limitação dos elementos indisponíveis da notação a ferramenta permite modelar os processos com resultado similar às demais ferramentas já avaliadas. Também se mostrou uma ferramenta eficiente, com fluidez na tarefa de modelagem dos processos, especialmente no que se refere aos atalhos para outros elementos (figura abaixo) e ao alinhamento automático e manual dos fluxos de sequência, o que confere uma boa produtividade ao software.

Imagem dos atalhos para outros elementos

Atalhos para outros elementos

Como resultado, a satisfação com o uso do modelador só não é maior pela falta dos componentes da BPMN e pela falta de atributos de documentação dos modelos presentes em outras ferramentas.

Nossa conclusão é que se você pretende testar ou adotar o Bonita BPM, não precisará de outro modelador de processos como acontece com outros BPMS do mercado (ciente da ausência de muitos elementos da notação). Se, por outro lado, você não vai utilizar o Bonita BPM como BPMS e ainda assim quiser utilizar seu modelador para documentar processos de negócio, terá algum trabalho extra para modelar situações que seriam mais simples com os elementos BPMN faltantes.

De qualquer modo, a instalação é rápida, intuitiva, a versão Community é muito completa e é uma ferramenta que vale a pena conhecer. Mesmo que seja por puro benchmark.

BPMS na nuvem – uma visão geral

Por muito tempo as ferramentas de BPMS só poderiam ser utilizadas após serem instaladas no ambiente da organização. Era necessária então a instalação do software em um servidor, após esta instalação era disponibilizada uma URL para os usuários acessarem o ambiente através de um navegador Web (normalmente para execução e acompanhamento dos processos automatizados). Também era comum a necessidade de instalar algum software no computador dos usuários (normalmente para fins de modelagem e automação). Fornecedores de ferramentas costumam referenciar isto como a versão “on premises” (local) da ferramenta de BPMS.

Assim, mesmo que o objetivo fosse apenas realizar testes rápidos de usabilidade e recursos da ferramenta, existia um caminho tortuoso que precisava ser seguido:

  • Fazer o download da ferramenta, onde os arquivos de instalação em muitos casos eram grandes, exigindo uma boa conexão com a internet e um considerável tempo de download;
  • Disponibilizar um servidor em que a ferramenta pudesse ser instalada e configurada, onde normalmente são exigidas máquinas mais parrudas, com múltiplos processadores e grande quantidade de memória;
  • Realizar o  processo de instalação, que por vezes era desafiador, exigindo pessoas com conhecimento técnico (muitas vezes não existente na organização, então um treinamento ou auto-estudo era necessário), incluindo a disponibilização de um banco de dados existente, que a ferramenta possa utilizar para armazenar as informações.

Depois destes passos é que, finalmente, a ferramenta se encontrava disponível para utilização pelos usuários.

Note que os passos acima se referem apenas a disponibilização de um ambiente de desenvolvimento/testes. A situação fica mais complicada se estivermos falando de instalação em ambiente de produção, em que outros fatores devem ser levados em consideração e onde costuma ser necessário:

  • Mensurar o hardware adequado para suportar a utilização atual (e futura) da ferramenta na organização;
  • Avaliar questões relativas a backup/restore;
  • Avaliar estabelecimento de máquinas em cluster e ambiente de pronta disponibilidade;
  • Avaliar regras de acesso ao ambiente de fora da organização;
  • Definir Regras de segurança, SSL;
  • Avaliar critérios e regras para aplicação de patches e novas versões;
  • Etc.

Parece complicado, não? De fato é. E este cenário ainda é uma realidade em várias ferramentas existentes no mercado.

Mas o que acontece então se a organização não tem os recursos (humanos/tecnológicos/financeiros) para viabilizar a instalação local de uma ferramenta? Significa que a adoção de uma ferramenta de BPMS, na prática, só se aplica a grandes organizações, que dispõe de mais recursos e capacidade de investimento?

A boa notícia é que com a popularização de BPM, um novo tipo de ferramenta está sendo oferecido no mercado, como alternativas ao modelo “local” (on premises) tradicional. Estamos falando aqui de soluções de BPMS na nuvem.

Uma solução de BPMS oferecida na nuvem tem como principais características:

  • Nenhuma instalação local é necessária no ambiente da organização e nos computadores dos usuários;
  • O ambiente de BPMS é disponibilizado pelo fabricante em seus próprios servidores, onde normalmente são oferecidos critérios de alta disponibilidade, segurança, redundância e backup;
  • Todo o acesso à ferramenta é feito via internet através de um browser;
  • A configuração de usuários é normalmente feita dentro da área de administração da ferramenta. Dependendo da ferramenta, existem possibilidades de integração com repositórios de usuários da organização;

Mas quais seriam os benefícios que podemos ter com a adoção de uma solução em nuvem? Vejamos alguns dos principais:

  •  Baixo investimento inicial para adquirir a solução, visto que não é necessário disponibilizar uma infraestrutura interna para instalação e manutenção da solução, bem como não existe um produto a ser “comprado” (o que existe é um modelo de subscrição);
  • Patches de correção e melhorias da ferramenta são garantidas e executadas automaticamente pelo fornecedor, enquanto durar o licenciamento;
  • O licenciamento costuma ser por usuário, o que pode ser bastante interessante e gerar economia, dependendo da quantidade de usuários que irão utilizar a ferramenta;
  • Camadas mais claramente separadas da lógica do negócio e dos sistemas de informação, visto que em se tratando de ferramenta disponibilizada em ambiente web, normalmente temos uma solução mais amigável e menos técnica. Isto incentiva um maior envolvimento da área de negócio em todo o ciclo de modelagem e implementação de processos. Podendo chegar, inclusive, na  possibilidade das próprias áreas modelarem e automatizarem processos (veja aqui o post em que discutimos esta questão);
  • Projetos de implementação evolutivos, em que um processo pode ser rapidamente colocado para ser executado, permitindo que ao longo do tempo novas melhorias e integrações sejam disponibilizados;
  • O conceito “Quick wins” (ganhos rápidos) são potencializados na utilização de uma solução em nuvem: como não existe a preocupação com disponibilização e manutenção de infraestrutura, pode-se partir diretamente para os projetos, gerando resultados mais rapidamente.

Parece bom, não? Mas, como nem tudo são flores, achamos importante destacar também algumas das possíveis limitações deste formato:

  •  Com a solução em nuvem, existe a perda de controle em relação ao ambiente e aos dados  informados, podendo levar a questões relacionadas à auditoria e à segurança das informações, e onde os dados serão armazenados. Dependendo das políticas adotadas pela organização, isso pode até inviabilizar a contratação da solução;
  • Normalmente não existe acesso direto aos servidores da solução, então a capacidade de visualizar os logs pode ser limitada, o que leva a mais dificuldades para avaliar e solucionar problemas na execução dos processos, em relação a uma solução instalada localmente;
  • A aplicação automática de patches e evoluções pelo fornecedor pode eventualmente gerar problemas de compatibilidade em processos/projetos existentes;
  • Dependendo da quantidade de usuários que forem utilizar a solução, o licenciamento por usuário poderá elevar o valor da contratação, podendo inclusive a chegar a valores similares a contratação tradicional (on premises);
  • Nos casos das ferramentas de BPMS que também oferecem a versão on premises, a versão em nuvem costuma ser menos robusta e com menos recursos disponíveis (ao menos neste momento). As capacidades de integração dos processos com sistemas existentes também costumam ser mais restritas (normalmente se encontra disponível integração via webservices);
  • Como estamos falando do conceito de subscrição, não existe a opção de ser “dono” da solução e poder assumir totalmente a ferramenta no futuro, algo que pode ser importante para algumas organizações.

Dados os prós e os contras, será que devo adotar uma solução em nuvem? Não existe uma resposta definitiva sobre isto. No final das contas cabe a cada organização fazer uma auto avaliação, pesar os pontos positivos e negativos, e avaliar que tipo de solução atende mais as suas necessidades, seja uma solução em nuvem ou local.

O que podemos afirmar é que a disponibilização de solução de BPMS em nuvem é um caminho sem volta. Grande parte dos fabricantes já oferece ou está procurando oferecer a sua versão da solução em nuvem, justamente pelo apelo e facilidade de utilização.

A tendência é de uma evolução e uma maturidade cada vez maiores das soluções de BPMS ofertadas na nuvem, oferecendo mais opções de escolha para as organizações, e por fim permitindo a um universo maior de organizações poderem desfrutar dos benefícios de BPM!