Particularidades na execução de projetos com integrações – Parte Final

Nos dois primeiros posts (disponíveis em 1 e 2), tratamos particularidades da gestão/execução e práticas metodológicas para bons resultados em projetos envolvendo integrações.

Para fechar esta série de artigos, hoje descreveremos alguns riscos importantes e fatores críticos de sucesso (FCS) nestes projetos, para que recebam a devida atenção e, se necessário, tratamento.

Em resumo, grande parte dos riscos e FCS se referem à comunicação e à integração das equipes do projeto, dado que muitas das informações e necessidades de trabalhos desta natureza envolvem algum tipo de compartilhamento.

Desta forma, listamos abaixo alguns itens que consideramos relevantes:

  • O primeiro ponto quem sabe até não seja o mais importante, mas certamente é um dos mais frequentes. Durante testes do sistema, quando ocorrem problemas, costumamos dizer: “até que se prove o contrário, a ‘culpa’ é da integração”. E pode-se dizer que até é um fato lógico. Quando uma das equipes realiza algum teste e não vê o resultado esperado acontecendo na outra “ponta”, naturalmente a primeira desconfiança é de algum defeito ou inconsistência na integração, que justamente faz a “ligação” entre os dois sistemas. Porém, esquece-se que a integração não é uma peça de software isolada, e sim um pequeno sistema formado pela origem, destino e o meio, que é a integração em si. E em qualquer um destes componentes pode ocorrer erro. Assim, é importante tanto alinhar as expectativas das equipes (inclusive para evitar desgastes) quanto definir um processo de teste e avaliação de problemas tecnicamente adequado para o cenário do projeto e dos sistemas envolvidos.
  • Boa parte das etapas de desenvolvimento e testes será realizado de maneira simbiótica por todas as equipes envolvidas (equipe do sistema que será integrado, de integrações e dos legados). Desta forma, uma prática bastante importante é a apresentação destas equipes, visando sua aproximação e integração. Com isto, espera-se que todos se conheçam, saibam os papéis de cada um e a quais responsabilidades respondem, quais os conhecimentos de cada integrante quando precisarem de apoio, etc. Além disso, a própria integração pessoal da equipe auxilia na pró-atividade e facilidade da comunicação.
  • Apesar da metodologia de desenvolvimento normalmente contemplar e se adequar a boa parte do escopo, como as integrações são o meio e dependem da forma como as “pontas” são desenvolvidas e entregues, é fundamental avaliar as eventuais modificações necessárias na metodologia, bem como apresentá-las às equipes. As responsabilidades também devem ficar muito claras. Além disso, é mandatório registrar estas mudanças em algum local, para consulta. Esta preocupação é essencialmente importante pois é muito comum (para não dizer que acontece sempre) que se confundam sobre o que cada equipe deve fazer e até onde sua autonomia vai. Isto pode gerar conflitos e desgastes desnecessários, perda de produtividade ou até problemas mais graves, que se refletem apenas quando o projeto já está em um estágio mais avançado.
  • É comum em um projeto com integrações existirem documentações compartilhadas, nas quais uma equipe preenche parte do documento, e outra(s) o completa(m). Assim, é importante esclarecer com todos quais tópicos cada um é responsável e definir uma política de armazenamento e versionamento adequadas.
  • A comunicação entre as equipes durante a análise e os testes é outro fator crítico. É fundamental definir um fluxo adequado e claro de comunicação entre os integrantes das equipes, de acordo com as responsabilidades no projeto. E, claro, esta definição depende de uma avaliação criteriosa dos estilos e da disposição física das equipes, do ambiente de trabalho e dos recursos de comunicação disponíveis.
  • Por fim, um ponto bastante simples, mas que pode facilitar muito a identificação de problemas. À medida que integrações forem codificadas e estejam razoavelmente estáveis, podem ser disponibilizadas para uso pelas demais equipes. Claro, dependendo do planejamento do projeto e da metodologia utilizada, elas nem serão acionadas antes dos testes integrados. Mas, caso as equipes das “pontas” já estejam prontas para realizar testes com o uso das integrações, isto pode antecipar alertas relevantes sobre inconsistências e defeitos.

Com este artigo, fechamos esta série dedicada especialmente a dicas, boas práticas e cuidados com projetos envolvendo integrações, que possuem particularidades que os tornam especialmente desafiadores.

Fiquem à vontade para opinar e sugerir outras práticas interessantes.

Esperamos que tenham gostado!

Nos falamos em futuros artigos. Até lá!

Particularidades na execução de projetos com integrações – Parte 2

No primeiro post (disponível aqui), iniciamos uma avaliação de particularidades da gestão e execução de projetos envolvendo integrações, com foco nas dependências técnicas e gerenciais.

Hoje, a ideia é “conversarmos” sobre algumas práticas metodológicas importantes para minimizar riscos e conduzir o trabalho de maneira organizada.

Apesar de podermos citar um grande número de práticas, algumas são especialmente relevantes para o sucesso deste tipo de projeto, a saber:

  • Definição de uma arquitetura do projeto. O básico do básico, mas por vezes esquecido. É fundamental definir uma arquitetura de comunicação, tecnologias a serem utilizadas e padrões de implementação no projeto, especialmente para as integrações. Outro ponto muitas vezes negligenciado – não adianta ter, tem que comunicar. Se for necessário, imprima a arquitetura e cole no monitor dos integrantes da equipe. Cada um precisa ter a arquitetura na cabeça, sem exceções. Criar uma página tipo wiki também pode ser simples e eficiente.
  • Implementação de mocks na etapa inicial de desenvolvimento ou arquitetura. Como citado no primeiro post, a definição e construção de mocks é uma prática que facilita a formalização da comunicação entre os componentes do sistema (principalmente quando estes estão divididos entre vários fornecedores) e auxilia o paralelismo de atividades. Uma outra avaliação é bastante importante – o comportamento interno do mock. Se por um lado um artefato que simplesmente devolve “vazio” é fácil e rápido de implementar, por outro ele não auxilia os testes unitários, por exemplo. Se implementarmos algumas regras, os testes unitários podem ser mais efetivos, mas é um trabalho que posteriormente será descartado. Assim, é fundamental avaliar qual a complexidade e conteúdo dos mocks a ser desenvolvido para cada caso e requisitos do projeto.
  • Testes unitários com componentes já desenvolvidos. Conforme o segundo item, a validação das regras de negócio das integrações não depende apenas das interfaces (assinaturas, contratos, etc) dos componentes chamados por estas, e sim principalmente de sua implementação interna. Desta forma, assim que possível é importante a substituição dos mocks pelos componentes definitivos, o que já ajuda, e muito, na avaliação de eventuais problemas de integração dos dados e até de análise. Porém, um alerta. Caso os componentes ainda estejam em uma fase incipiente de desenvolvimento, podem conter bugs que mais prejudicarão do que ajudarão durante a implementação das integrações. Assim, é necessário avaliar a qualidade dos componentes das “pontas” quando estes forem usados.
    • Revisão periódica de serviços ou componentes que vão ficando prontos. Item relacionado ao tópico anterior. Defina um meio de acompanhar e comunicar quais componentes das “pontas” da integração (serviços que serão chamados, por exemplo) estão prontos e disponíveis para uso no decorrer do projeto. É bastante comum esquecermos disto por vários dias e perdermos a oportunidade de aproveitar os ganhos do tópico acima.
  • Teste de arquitetura com “integração piloto”. Uma prática que resolve várias dores de cabeça e antecipa problemas do desenvolvimento é validar a arquitetura definida para o desenvolvimento das integrações com a implementação de uma “integração piloto”. Aproveite este momento para questionar e validar as diretrizes arquiteturais para o restante do projeto. Claro, nem sempre isto é simples, visto que muitos projetos incluem integrações com “n” formas de implementação e utilização de recursos. Mas, na medida do possível, é uma prática muito vantajosa.
  • Mapa de dependências entre componentes. Prática simples e muito útil. Organize um mapa com todos os componentes do projeto e quem depende de quem. Não use textos – faça o mapa de forma gráfica. Aí temos uma vasta gama de ferramentas que podem ser usadas – aplicativos de mind mapping, de desenho, de modelagem, etc. E use a criatividade. Pinte componentes de cada tecnologia com uma cor diferente, separe-os por equipe responsável, por desenvolvedor, e assim por diante.
  • Repositório único de contratos. É realmente muito importante definir um repositório que armazene a versão oficial de contratos de serviços e demais componentes que são dependência para outros no projeto. Assim, todas as equipes sabem onde consultar a versão a ser utilizada, evitando ruídos de comunicação. Claro, se alguma alteração é feita, deve ser comunicada a todos – e isto deve estar contemplado no Plano de Comunicação do projeto. Este repositório deve estar sempre atualizado.
  • Organizar a análise e desenvolvimento das integrações por assunto. É bastante comum em projetos envolvendo integrações que estas estejam separadas por assuntos de negócio tratados pelo sistema. Por exemplo: ao desenvolver integrações de um ERP com sistemas legados, organizar os profissionais que vão analisar e implementar as integrações por cada módulo do ERP. Nem sempre isto é possível – alguns processos são transversais e passam por vários módulos – mas claramente auxilia o entendimento das integrações pelo conhecimento de negócio que cada profissional adquire. Claro, isto incide em alguns riscos bastante relevantes. Se um profissional, seja analista ou desenvolvedor, sai da equipe, um grande conhecimento pode ir com ele. Uma forma de contornar isto é envolver o líder técnico e um analista líder em pontos-chave da análise e desenvolvimento de todas as integrações, a fim de que possa responder pelo conhecimento destas.
  • Definição de cenários de testes entre as equipes. Um ponto chave do projeto, difícil de gerenciar e que frequentemente enfrenta grandes problemas, é o teste integrado do sistema, principalmente quando existem diferentes equipes envolvidas. Uma sugestão muito interessante é a reunião dos responsáveis das equipes para elaboração de cenários de teste integrados. Veja, a ideia não é detalhar cada cenário neste momento, e sim definir quais são os cenários a serem executados para validar a integração dos sistemas de ponta a ponta. Após, cada equipe detalha seus cenários individualmente, que são validados ao final, novamente entre todos.

No próximo post, que encerra esta série, trataremos de riscos e pontos de atenção em projetos com integrações, visando auxiliar principalmente seu planejamento e gestão. Até lá!

BPMS: como as etapas do ciclo BPM geram segurança no processo automatizado

A automatização de processos através de BPMS (Business Process Management Suites) tem sido frequentemente adotada nas organizações num esforço para otimizar seus processos. No post Benefícios da Automação de Processos do nosso blog, já discutimos os principais benefícios intrínsecos à automatização de processos.

Neste post, iremos falar de uma situação recorrente no mercado em projetos de automatização de processos: a automatização que é feita sem uma etapa de análise e redesenho e processos efetuada previamente.

Idealmente, em qualquer projeto de implementação de BPM, o ciclo BPM a ser seguido inclui a análise (AS IS) e o redesenho (TO BE) dos processos, antes de seguir para a etapa de implementação (TO DO). Desta forma, garante-se que o cenário atual do processo na organização foi adequadamente estudado, e todas as necessidades de melhoria no processo foram devidamente contempladas. Porém, é comum encontrar empresas que investem em projetos que simplesmente “pulam” as etapas de análise e redesenho, seguindo diretamente para a etapa de implementação.

Na maioria das vezes em que isso ocorre, tratam-se de processos de negócio razoavelmente definidos que estão sendo ativamente executados dentro da organização. Para estes processos são identificadas necessidades de melhoria, e aqui está o grande diferencial em relação a um processo que está passando por um ciclo típico de BPM: as necessidades de melhoria identificadas, ao menos na percepção dos responsáveis por aquele processo, estão relacionadas diretamente aos sistemas que apoiam a execução do processo. Ou seja, em tese os processos estão bem definidos, mas não estão sendo apoiados adequadamente por um sistema. Abaixo alguns dos motivos mais frequentes que levam a automatização direta dos processos:

-O processo é executado em papel, que é um dos casos mais comuns. Com a automatização, busca-se então substituir os formulários em papel por formulários eletrônicos melhorando o fluxo e o gerenciamento da informação;

-O processo é executado com suporte de sistemas, porém são diversos sistemas que precisam ser utilizados. Isto força os usuários a precisar alternar entre os sistemas para executar o processo. Com a automatização, busca-se a integração destes sistemas de maneira automática, passando até mesmo pela criação de um front-end único para a execução do processo pelos usuários (desta forma desativando alguns ou todos os sistemas existentes);

-O processo é executado com suporte de sistemas, porém em diversos pontos os usuários são requisitados a manter documentos/planilhas em repositórios na rede da organização, dificultado a manutenção e auditoria dos mesmos. Com a automatização, busca-se a integração automática destes documentos ao BPMS, controlando o seu ciclo de vida, utilizando o repositório nativo do BPMS ou uma solução de ECM (Enterprise Content Management).

Embora “economize” etapas (e consequentemente custos) do ciclo BPM, a abordagem de automatizar o processo diretamente tem seus riscos. O mais intangível, e não menos importante, é o desperdício de oportunidade: não aproveitar que está sendo direcionado tempo e recursos para melhorar o processo pode prover uma visão míope do mesmo durante a análise para automação, focando única e exclusivamente nas necessidades de sistema. Desta forma, corre-se o risco de deixar passar outras oportunidades de melhoria importantes e impactantes para o processo como um todo.

Outro risco bastante frequente desta abordagem é a possibilidade de “automatizar o erro”, ou seja, pegar um processo que não está bem documentado (conhecimento na cabeça das pessoas), pouco otimizado, por vezes definido incorretamente, com várias lacunas e desperdícios, e simplesmente automatizá-lo. Neste caso, a automatização de processos está longe de ser a solução mágica para todos os problemas: ao se automatizar um processo com erros, o que normalmente se obterá é… um processo com erros automatizado. 🙂

Esta situação é muitas vezes alimentada por uma necessidade de provar a tecnologia dentro da organização. Como a aquisição de um BPMS por si não soluciona o problema – é necessário implementar a automatização do processo para que então o produto se faça provar como bom investimento para a empresa, o projeto acaba sendo “um piloto, mas que vai à produção”. A estratégia é arriscada e o tiro pode sair pela culatra: se o processo com problemas for automatizado as is, as falhas continuarão existindo e poderão ser potencializadas, gerando rejeição do uso do sistema pelos participantes do processo e outros resultados insatisfatórios, que poderão desacreditar a adoção do BPMS como solução.

É como construir uma casa sem um projeto arquitetônico, em que se possa analisar a ideia do imóvel e planejar melhorias antes de começar a levantar as primeiras paredes. Pode ser rápido, e pode dar certo, mas as chances de desperdiçar material e chegar ao final com um resultado insatisfatório são bastante elevadas.

O caminho mais seguro é investir em um ciclo completo, porém em partes, gerando quick wins e demonstrando que a gestão por processos com apoio de um bom BPMS pode resultar em excelente retorno para o investimento da organização.

Estudo de Caso: Automatizar o processo (ou não)? Eis a questão!

Recentemente um de nossos leitores nos escreveu sobre seu entusiasmo em iniciar uma experiência prática em BPM. Ele compartilhou conosco um desenho de processo (que discutiremos neste artigo, com a permissão do leitor) cujo objetivo era ser automatizado com dois propósitos: servir como base para a monografia e também validar o BPMS como tecnologia para automatizar processos na empresa de varejo no qual atua na área de TI.

O argumento da escolha do Processo de Pré-venda para esta primeira experiência foi: que fosse pequeno (poucas atividades) para viabilizar a automação no curto tempo para a monografia, mas que ao ser desenvolvido seria usado como piloto para provar a tecnologia na empresa e, dando certo, o processo evoluiria para as etapas seguintes da venda. Portanto, havia uma expectativa de que a automatização dele pudesse demonstrar bons resultados para a organização, a ponto de convencê-los que valeria a pena investir na adoção da solução e a implementação do restante do processo (e eventualmente de expandir a iniciativa para todos os processos da organização).

Embora ter processos executados e controlados por um BPMS (ou um motor de workflow) possa ser parte do ciclo da gestão por processos, não significa que a empresa tenha adotado Business Process Management como filosofia de gestão. Mas, dependendo do contexto organizacional, muitas vezes a iniciativa nasce dentro da TI, em situações como esta.

A questão é: seria este um bom processo para demonstrar resultados iniciais que possam alavancar uma iniciativa maior BPM (e em uma monografia, apresentar resultados satisfatórios)?

É aqui que este artigo realmente começa 🙂

A notação BPMN é excelente para representar atividades de um processo de negócio. Mas a especificação não esclarece exatamente o que é o escopo de um processo de negócio, e nem o nível de granularidade, ou mesmo um método de uso. Apenas dispõe os elementos e as regras de uso visando uma padronização no entendimento de um processo mapeado.

Analisamos juntos o processo e percebemos que este diagrama não é um processo de negócio. É apenas uma parte dele, praticamente o fluxo de ações de uma atividade.

Os benefícios típicos da automatização aparecem quando o processo de negócio :
– Envolve mais de uma área da empresa (melhoria da comunicação)
– Permite extrair indicadores que demonstrem o desempenho do processo (melhoria do controle)
– Deve ser controlado para que sua execução siga integralmente o fluxo modelado
-Possibilita  apresentar informações de tempo do processo que possam apoiar as decisões que levarão à sua evolução (quanto tempo o processo leva hoje e quais atividades devem sofrer alguma melhoria para que esse tempo possa ser reduzido).
[Veja mais sobre benefícios típicos da automação de processos no artigo de Paulo Capiotti, Benefícios da Automação de Processos]

Ao analisar o diagrama, desaconselhamos a sua automatização, pois a mesma não obterá nenhum benefício significativo. Justificamos isto apontando alguns argumentos que usamos quando estamos avaliando a viabilidade/ganho ao se automatizar um processo para um cliente:

I. Este processo tem apenas um usuário. No diagrama original há duas lanes, a do vendedor e a do cliente, mas o fato é que o único a interagir diretamente com a interface humana do BPMS, neste caso, será o vendedor. Se ajustarmos o diagrama para representar apenas as atividades que serão automatizadas (conforme abaixo) e colocando o cliente em uma outra pool (já que ele não irá interagir diretamente com o BPMS) isto se torna bastante visível:

II. Todos estes passos acontecem em um curto espaço de tempo. Pelas tarefas mapeadas, percebe-se que elas ocorrem com o cliente ali, na frente do vendedor. Neste caso, ao automatizar cada uma destas tarefas separadamente, poderá gerar um impacto negativo no aspecto da interface, porque para cada “passo” o usuário (vendedor) terá que: procurar a tarefa na lista de trabalho, clicar para abrir, realizar as ações necessárias na tela, finalizar a tarefa (para que o BPMS registre que aquela tarefa foi concluída e verifique qual a nova tarefa, criando um novo item na lista de trabalho), aguardar o refresh da lista de trabalho e então realizar novamente estes passos para cada uma das atividades do fluxo. Em termos de usabilidade, isso se torna desgastante para o usuário porque faz com que ele tenha que dar inúmeros cliques para fazer uma sequência de ações que possivelmente poderia ser condensada em uma única tela. Em outras palavras, esta sequência de ações poderia compor um Caso de Uso (artefato típido da análise de sistemas tradicional).

III. Além disso, se este processo já é executado manualmente, possivelmente há alguma flexibilização na ordem em que estas tarefas ocorrem (por exemplo, em algum caso o vendedor poderia verificar o cadastro do cliente antes de incluir os itens de compra). É importante considerar isso, pois ao automatizar o fluxo no BPMS, ele sempre será executado como foi modelado. Isso implica que nada pode ser feito antes nem depois do previsto – tudo tem que seguir a ordem das tarefas no diagrama. O que é tradicionalmente um benefício da automatização de processos (garantia da integridade da execução), neste caso poderia ser um aspecto negativo, pois não é o engessamento das etapas que queremos (e toda vez que algo precisar ser levemente diferente os usuários dirão que não é possível porque “o sistema não permite”).

Então percebemos que o processo escolhido é, na verdade, apenas uma atividade de um processo de negócio muito maior.

Fica fácil nesta análise perceber que o sucesso de projetos pilotos para a adoção de um sistema de gestão de processos não depende apenas da qualidade do produto, mas também da escolha de um processo com tarefas que possam efetivamente demonstrar bons resultados.

Ao leitor, sugerimos ampliar um pouco mais a abrangência do processo – o que não significa necessariamente que será mais trabalho. Para um piloto como este, recomendamos mapear, em um nivel macro, todo o processo (não apenas esta etapa da pré-venda), e como primeiro esforço de automação identificar pontos de controle que poderiam ser automatizados (seis ou sete tarefas onde o processo muda de status ou há alguma alteração na rota do fluxo).

Alguns desses pontos de controle podem até ser obtidos de sistemas que já existem hoje na empresa, o que demonstraria ainda mais benefícios na automatização do processo. Por exemplo, no sistema que controla os pedidos, fazer com que o processo siga adiante quando a entrega for despachada. Poderia ser agregado ao processo uma tarefa de serviço para buscar essa informação no sistema.

Com um piloto assim, os indicadores podem demonstrar informações muito mais significativas para a organização do que conhecer, por exemplo, quantos minutos está levando a pré-venda. Será possível identificar onde ocorrem os gargalos, que estapas são críticas e estão atrasando o processo, possivelmente até instigar a empresa em investir na análise,  melhoria e medições mais abrangentes, e quiçá em adotar por completo uma filosofia de gestão por processos.

Caso de Sucesso – Aumento da produtividade e efetividade nos negócios do SICREDI com a adoção de SOA e BPM

Marcio Lermen, gerente de tecnologia do Sicredi

Durante o Oracle Open World 2012 em São Paulo, Marcio Lermen, gerente de tecnologia do Sicredi, apresentou como caso de sucesso a adoção da suíte de SOA e BPM da Oracle para a automação dos processos da organização e o uso do Oracle Exalogic como plataforma de hardware e software para dar alta performance a esta suíte.

De acordo com Marcio, a escolha destas tecnologias foi feita dado o desafio que o Sicredi tinha quanto a decisões e processos manuais em um cenário de negócio complexo, em que os processos estão distribuídos entre as cooperativas do sistema. A adoção destas tecnologias viabilizou o redesenho e automação dos processos, apresentando excelentes ganhos no controle da execução dos processos.

Dentre os benefícios obtidos com esta adoção, foi mencionado o ganho de tempo na execução de um processo. Em alguns casos, a automação de um processo (que antes era ad-hoc e feito via envio de e-mails e trocas de telefonemas) fez com que o ciclo de vida do mesmo, que costumava levar vários dias, pudesse ser realizado no mesmo dia. Além disto, foi mencionado o ganho de desempenho com o uso do Oracle Exalogic, que chegou na ordem de 4 a 6 vezes. Segundo Márcio, para conseguir esta performance foi preciso que todos os serviços envolvidos estivessem dentro do Exalogic.

Como pontos importantes apresentados por ele, foram citados os seguintes fatores:

  • o mapeamento e desenho do processo as-is e to-be antes da automação do mesmo;
  • a definição dos pontos onde serão gerados indicadores (que serão enviados ao BAM na execução) durante a definição do processo;
  • a quebra do processo principal em subprocessos menores, inclusive para facilitar o controle de versão e o desenvolvimento;
  • governança SOA, contendo uma arquitetura bem definida, além da necessidade de uma garantia de que a mesma será utilizada dentro dos projetos.

Foram mostrados alguns exemplos de processos criados utilizando Oracle BPM, sendo que muitos deles foram mapeados e criados em parceria com a iProcess.

É um orgulho para nós poder fazer parte de cases de sucesso em BPM do sicredi.

Um guia para iniciar estudos em BPMN (III): Eventos de Início e Fim

Este é o terceiro artigo de uma série dedicada ao estudo da notação BPMN básica, ou nível descritivo. No artigo anterior, descrevemos um importante elemento na representação de processos nesta notação, os gateways.

Este artigo é dedicado ao esclarecimento de outro importante componente de fluxo em BPMN: os eventos.

Eventos (Events) são elementos utilizados para representar a ocorrência de fatos em um processo.

Eventos podem representar a espera de que um fato aconteça para iniciar/prosseguir a execução o processo ou então sinalizar que o processo produzirá a ocorrência de um fato durante ou ao término de sua execução.

Os eventos são sinalizados no processo através de um círculo, e dependendo do ponto do processo onde ocorrem podem ser sinalizados de forma diferente:

  • Eventos de início (Start events) marcam o ponto onde o processo inicia e são representados por um círculo de linha simples.
  • Eventos intermediários (Intermediate events) marcam ocorrência de eventos no decorrer do processo e são representados por um círculo de linha dupla.
  • Eventos de fim (End events) marcam o ponto onde o processo termina e são representados por um círculo de linha grossa.

Eventos que aguardam fatos e possuem uma causa são chamados “catch”.

Eventos que produzem fatos e possuem um resultado são chamados “throw”.

A causa ou resultado do evento é chamado “trigger” (gatilho) e sinalizado através de um símbolo dentro do elemento. Os tipos de gatilho variam de acordo com cada tipo de evento.

 

Evento de início (Start Event)

O evento de início marca o ponto onde deve-se iniciar a leitura ou a execução de um processo.

O evento de início será sempre do tipo catch, pois deve aguardar a ocorrência de um evento para realizar o disparo (início da execução) do processo.

É recomendável que todo o processo tenha um evento de início para facilitar a leitura do diagrama, possibilitando a quem lê identificar por onde começa o fluxo de atividades.

Os tipos de evento de início mais comuns são:

None
O processo é iniciado sem a definição de um fato específico que gere o seu início.
Não possui símbolo.

 

Timer
O processo é iniciado pela ocorrência de um fato temporal, como a chegada de uma data específica (ex. 01 de janeiro) ou relativa (ex. primeira terça-feira do mês).
É simbolizado por um relógio.

 

Message
O processo é iniciado com a chegada de uma comunicação de qualquer tipo (um documento, uma mensagem, um telefonema, etc).
É simbolizado por um envelope branco (catch).

 

Conditional
O processo é iniciado quando uma determinada condição torna-se verdadeira. É simbolizado por um desenho de página com linhas representando as condições.

 

Evento de fim (End event)

O evento de fim marca o término onde deve-se iniciar a execução de um processo.

O evento de fim será sempre do tipo throw, marcando que o processo termina com a geração de um fato.

É recomendável que todo o processo tenha ao menos um evento de fim. É possível entretanto simbolizar términos diferentes para o processo usando mais de um evento de fim.

Os tipos de evento de fim mais comuns são:

None
O processo termina sem gerar nenhum fato específico.
Não possui símbolo.

 

Message
O processo é finalizado com o envio de uma comunicação de qualquer tipo (um documento, uma mensagem, um telefonema, etc). É usado para iniciar um outro processo ou fornecer um resultado a uma comunicação começada no início ou decorrer do processo.
É simbolizado por um envelope preto (throw).

 

Terminate
O processo é terminado finalizando por completo, mesmo que existam atividades em fluxos paralelos em execução. Caso existam atividades em execução quando um dos fluxos existentes atinja o evento de fim terminate, as tarefas pendentes são canceladas e o processo é dado como completamente finalizado.
É simbolizado por um círculo preto preenchido.

 

No exemplo acima, o evento de fim “Processo arquivado” é do tipo terminate. Se a tarefa “Arquivar processo” for concluída antes das atividades do fluxo paralelo, o processo chegará ao evento terminate e as tarefas que ainda estavam em execução serão interrompidas. Mas se a tarefa “Anexar documentos pendentes” terminar antes de “Arquivar processo”, o processo finalizará com todas as atividades executadas, pois diferente do evento terminate o evento do tipo none não interrompe a execução de atividades no fluxo paralelo.

Embora o uso de eventos de início e fim não sejam obrigatórios, são considerados uma boa prática, fundamental para a obtenção de um processo bem mapeado, claro e legível a todos os participantes do processo.

Há porém uma regra na especificação que deve ser observada: se for utilizado um evento de início no processo, deve  obrigatoriamente haver ao menos um evento de fim. Da mesma forma, se for adicionado ao mapeamento do processo um evento de fim, então o processo deve obrigatoriamente possuir ao menos um evento de início.

Existem outros gatilhos para eventos de início e de fim do processo. Estes apresentados, porém, são os mais comumente utilizados e que compõem o nível de componentes do nível descritivo da notação BPMN.

No próximo artigo:
o tema Eventos continua! Estudaremos os principais usos e tipos de eventos intermediários, usados para prever ocorrência de eventos no decorrer da execução dos processos.


Confira todos os artigos deste guia de BPMN Nível 1:

Estimando a duração de processos II – processos não lineares

Em um artigo anterior sobre a estimativa da duração de processos, concluímos que a duração do processo é a soma da duração das suas atividades e dos tempos de espera entre elas. Esta fórmula se aplica para processos em que todas as atividades acontecem de forma linear. Entretanto, muitos processos de negócio precisam prever no seu fluxo de atividades caminhos alternativos ou paralelos, o que certamente agrega complexidade a esta avaliação.

Este artigo visa buscar um aprofundamento um pouco maior sobre como estimar a duração de processos nestes casos. Está longe de ser uma referência que cubra todos os cenários possíveis, mas o publicamos com a expectativa de apoiar o processo de compreensão sobre a variabilidade da duração de processos.

Alguns dos principais aspectos de variação em tempos de processos que precisam ser considerados em uma análise de duração são:

  • A ocorrência de fluxos paralelos
  • A ocorrência de fluxos alternativos
  • Repetições (loops)
  • Paradas por espera de eventos externos

 I. Fluxos paralelos
A duração de um conjunto de atividades executadas em fluxos paralelos não pode ser estimada com a simples soma das suas durações e os handoffs, uma vez que elas ocorrem paralelamente, ou seja, podem iniciar ao mesmo tempo. Nestas situações, é necessário estimar-se a duração de cada fluxo paralelo. A duração deste conjunto de atividades é dada pela duração do caminho com a duração maior (já que as atividades dos outros fluxos são executadas dentro deste período).

 II. Fluxos alternativos
A duração de um processo que apresenta a possibilidade de fluxos alternativos terá uma duração variável. A duração do processo poderá variar para mais ou para menos, de acordo com o fluxo que a instância do processo seguir quando o mesmo for executado.

 III. Repetições (loops)
A duração de um processo que apresenta atividades passíveis de repetição também irá variar, com acréscimo da duração desta atividade tantas vezes quantas ela se repetir.

IV. Eventos externos
Processos que dependam da ocorrência de eventos externos para que parte de suas atividades sejam executadas também podem apresentar variações no seu resultado. Neste caso, a variação dependerá do tempo que o processo levará para receber o retorno sobre a ocorrência externa (como aguardar a resposta de um cliente ou fornecedor, esperar um determinado horário programado, etc) para cada instância.

Ao calcular-se a duração de processos, é importante considerar que podem existir cenários em que há, inclusive, a combinação destes aspectos, o que requer uma análise ainda mais cuidadosa.

Partindo -se do entendimento de como estes aspectos podem promover variação do tempo do processo além da simples soma de duração de atividades e esperas em handoffs, podemos perceber que, nestes casos, o processo poderá ter uma estimativa de duração variável, de acordo com os caminhos que cada instância do processo poderá seguir.

Assim, cabe ao analista definir que critério utilizará para identificar qual, afinal, é a duração do processo:

  • Estimativa do caminho crítico (o caminho do processo que executa todas as atividades críticas para o atingimento do bom resultado do processo).
  • Estimativa do caminho padrão (o caminho que é executado no processo na maior parte das vezes).
  • Estimativa do caminho feliz (o caminho no qual o processos é executado no seu melhor caso, com o mínimo ou nenhuma exceção do negócio).
  • Estimativa do melhor caso (a duração mínima esperada da execução do processo).
  • Estimativa do pior caso (quando todas as exceções de negócio possíveis podem ocorrer, gerando o resultado mais negativo possível).

Em um processo não-linear, cada uma destas opções irá possivelmente apresentar um resultado diferente no cálculo da duração.

Técnicas de diagramas de precedência e rede e métodos de análise do caminho crítico, muito comuns no gerenciamento de projetos por exemplo, podem ser empregadas para a realização da estimativa de duração dos processos.

Implantação de BPMS não substitui os sistemas da empresa

Num artigo anterior deste blog, procuramos abordar as diferenças entre BPM e Workflow, com a intenção de minimizar a confusão existente com relação a este dois termos. Neste sentido, achamos interessante continuarmos a desmitificar outros mitos que se referem a BPM no que tange o aspecto da tecnologia.

Hoje, vamos falar de um dos mitos que mais escutamos durante os nossos projetos: a idéia de que a implementação de BPM irá “substituir” total ou parcialmente os sistemas atuais, e passar eventualmente a ser o repositório central das informações da organização. Ou, como já ouvimos algumas vezes, que o BPMS vai passar a ser o “ERP” da organização!

Em uma iniciativa BPM, uma organização automatiza processos para aumentar seu nível de controle e monitoramento na execução dos processos. Neste sentido, 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. Mas então, vem a pergunta: quem é o dono da informação numa automação de processos? Vamos primeiramente analisar 2 dos cenários mais frequentes de automação de processos.

1) Automação de processos que originalmente eram executados em papel, pouco/nenhum apoio de sistemas:

Neste caso, a organização não dispõe de sistemas para apoiar a execução destes processos, ou dispõe de sistemas que atendem apenas a uma parte do processo.

Normalmente são criados formulários eletrônicos que são responsáveis pelo início e execução do processo (ex: num processo de solicitação de viagem, o formulário inicial conteria os dados da viagem desejada pelo usuário). Durante a execução destes processos, usualmente existem pontos de integração com sistemas existentes na empresa (ex: sistema financeiro, contábil, etc). Neste cenário, eventualmente o BPMS poderá servir como repositório de algumas informações, normalmente sendo o repositório das “solicitações” em si (ex: solicitações de compra, solicitações de viagem, etc), e não dos dados de negócio de fato. Mas na experiência que temos, com bastante frequência as informações originadas/geradas pelos processos automatizados são enviadas para gravação em sistemas existentes da organização, como por exemplo ERP ou sistemas legados, que são de fato os responsáveis por armazenar e manter aquelas informações.

2) Automação de processos com apoio de sistemas:

Neste caso já existe um ou mais sistemas que apoiam a execução de parte ou todo um processo, mas o fluxo de execução das atividades não é orquestrado e controlado, ou seja, os sistemas e usuários responsáveis por aquele processo estão desconectados uns dos outros, o que gera então a necessidade de automação.

Neste cenário, com frequência as atividades do processo automatizado são executadas nos próprios sistemas, cabendo ao processo automatizado basicamente controlar o início e término das atividades, e a comunidação dos envolvidos nos pontos onde há necessidade de alguma intervenção humana. Assim, as atividades na lista de trabalho meramente direcionam os usuários para os sistemas onde estes deverão efetivamente realizar as atividades. Outro cenário bastante frequente é a busca, pelo processo automatizado, de informações armazenadas em sistemas existentes, de forma a apoiar os usuários na execução dos processos. E, como não poderia deixar de ser, neste cenário é ainda mais frequente e usual a necessidade de, em diversos pontos do processo automatizado, enviar as informações geradas durante a execução do processo para armazenamento em sistemas existentes.

Com base nos cenários visto acima, retomamos então a pergunta. Quem é realmente o dono da informação numa automação de processos?

Note que, em qualquer um dos casos que citamos até agora, normalmente o BPMS não é a fonte principal dos dados sendo manipulados, mas atua principalmente como integrador destas informações, buscando e enviando dados para outros sistemas durante a execução dos processos.

Podemos concluir, então, que a implementação de um processo automatizado de forma nenhuma significa a descontinuidade dos sistemas existentes!

Estimando a duração de processos

Durante a análise de um processo, um dos trabalhos comumente realizados é a estimativa da duração do processo e suas atividades.

Apesar de ser um atributo importante para o entendimento de um processo, o tempo é uma informação  frequentemente avaliada de modo bastante displicente. A estimativa de tempo do processo acaba por ser realizada com base na percepção das pessoas em função do trabalho realizado, em geral na forma de “chute”. O resultado é uma avaliação que não condiz com a realidade – ou porquê foi superestimado, levando a crer que o processo possui um desempenho superior ao seu real potencial, ou subestimado, levando ao entendimento de que o processo não é eficiente pois está sempre atrasado.

Assim, uma avaliação de tempo realizada sem um estudo apropriado tende a impactar em diversas decisões equivocadas de melhoria, já que é um critério essencial para a avaliação do desempenho do processo.

Para se estimar o tempo envolvido na realização de um processo, é necessário compreender os conceitos de: duração, execução e trabalho.

Esquema de espera, execução, trabalho e duração da atividadeO trabalho, ou esforço,  é o tempo que o participante da atividade leva, efetivamente, na realização do trabalho a ser executado. Em uma tarefa, é possível que o trabalho seja realizado em partes antes da mesma ser considerada como concluída.  Por exemplo, o preenchimento de um formulário, a pesquisa de dados adicionais e a complementação do mesmo. Portanto, o tempo de trabalho é a soma do tempo dispendido em ações necessárias para que a tarefa seja concluída.

A execução é o tempo dispendido deste o início do trabalho até o mesmo ser concluído, inclusive o tempo entre as partes do trabalho. Por exemplo, do momento em que a pessoa iniciou o preenchimento do formulário, até o momento em que o mesmo foi completamente preenchido.

A duração é o tempo calculado desde o momento em que a tarefa esteve disponível para o participante responsável pela atividade. Por exemplo, desde o momento que o formulário foi deixado na caixa de entrada do participante,  mais o tempo de espera que levou para que a pessoa tomasse o formulário em mãos para iniciar o trabalho, até o seu completo  preenchimento.

Analisar a execução de um processo requer conhecer o tempo de trabalho, execução e duração de cada atividade envolvida.

Ao se calcular a duração de um processo, entretanto, não basta somar as durações das atividades envolvidas. Em um processo executado manualmente (ou seja, sem o controle por um BPMS), a duração é afetada também pelo handoff, que é a espera dispendida no transporte das informações do processo entre os participantes das atividades.

Esquema de espera, execução, trabalho e duração de processo manual

Um exemplo clássico do tempo de espera em transporte é, por exemplo, o tempo levado para que um formulário preenchido em uma atividade seja disponibilizado para o participante da próxima atividade.

Assim, a duração do processo é a soma da duração das atividades mais a soma das esperas entre atividades.

Estimar corretamente os tempos de um processo pode levar a várias ações de melhoria, como:

  • Definir níveis de serviço (SLA) realistas;
  • Definir indicadores que apoiem na identificação de gargalos em atividades, baseados no tempo de espera que uma atividade leva para ser iniciada;
  • Melhorar a distribuição de recursos para realizar as atividades de acordo com o volume de trabalho;
  • Melhorar as ferramentas utilizadas pelos participantes das atividades a fim de agregar velocidade à realização do trabalho;
  • Avaliar melhoria de desempenho simplificando-se ou removendo-se tempos de transporte (handoffs), ou mesmo buscando métodos de transporte mais eficazes.

A automatização de processos é uma alternativa para a busca de desempenho e solução para o transporte das informações entre as atividades. Em geral, há dois benefícios comumente identificados na automatização relacionados ao tempo de execução do processo:

  1. Eliminação do tempo de handoff, já que o motor do processo disponibiliza as informações ao próximo participante imediatamente após a conclusão da atividade anterior;
  2. Eliminação do tempo de espera em atividades executadas pelo sistema (como serviços de busca ou gravação de informações, por exemplo), já que a execução das mesmas é realizada imediatamente  quando a atividade é disponibilizada.

Esquema de espera, execução, trabalho e duração de processo automatizado

Seja executado por controles manuais ou automatizado com um BPMS, compreender a análise dos tempos na avaliação da duração de atividades e processos é uma ferramenta de gestão fundamental rumo à melhoria do desempenho dos processos da organização.


Leia mais sobre o cálculo da duração de processos no artigo complementar Estimando a duração de processos II – processos não lineares.

Avaliando o real custo-benefício de BPMS livres ou de baixo custo

No nosso último post falamos sobre os motivos que tornam a escolha de uma plataforma de BPMS tão difícil (veja aqui).

Aprofundando a questão da seleção de plataformas, um equívoco muito comum está no fato dos profissionais acreditarem que soluções de BPMS livres ou de baixo custo são sempre mais baratas do que as ferramentas pagas. Por vários fatores que veremos a seguir esta premissa nem sempre é verdadeira, sendo fundamental que os seguintes fatores sejam analisados:

  1. Investimento total na ferramenta no longo prazo: Nem sempre o custo de licenciamento é o maior custo na aquisição de uma solução BPMS, principalmente quando visto a médio ou longo prazo. Muitas vezes, o custo de um contrato de suporte e manutenção de uma ferramenta gratuíta é significativamente maior ao final de 3 ou 5 anos do que a soma dos custos de licenciamento e contrato de manutenção de outras ferramentas, de modo que este custo não pode ser analisado somente no primeiro ano.
  2. Requisitos disponibilizados pela ferramenta: Para evitar que o barato saia caro, analise o quanto a solução escolhida é aderente às necessidades da sua empresa. Caso existam requisitos obrigatórios ou opcionais que ela não atenda, verifique qual será o impacto da solução escolhida não ter estas funcionalidades.
  3. Benefícios (reais) de uma solução Open Source: A escolha de uma solução open source (quando o fabricante disponibiliza o acesso ao código fonte do produto) nem sempre traz o benefício esperado pela organização. Via de regra, fornecedores que dão suporte e manutenção às suas ferramentas não permitem, durante o período de vigência do contrato, que seus clientes alterem o seu código fonte, pois isso inviabilizaria o contrato de suporte.
  4. Características do suporte oferecido pelo fabricante: É fundamental verificar como é o nível de suporte fornecido pelo fabricante: Questões como a existência de suporte no país, a língua em que é prestado o atendimento, a possibilidade de se obter um atendimento no local, a disponibilidade 24×7, a existência ou não de um limite de abertura de chamados e o tempo de atendimento à produção devem ser analisados de modo a verificar se o suporte irá atender às expectativas.
  5. Existência de mão de obra qualificada: Uma ferramenta de BPMS, por si só, é uma caixa vazia: não tem nenhuma utilidade enquanto os processos não forem desenvolvidos. Assim, a disponibilidade de mão de obra capacitada para realizar este desenvolvimento torna-se um fator crucial.
  6. Esforço para a formação de um profissional apto a operar com a plataforma: Uma alternativa para uma eventual falta de mão de obra qualificada é a organização investir na formação de pessoal capacitado. Aqui, torna-se fundamental avaliar qual a complexidade desta formação: Quais os pré-requisitos mínimos de conhecimento de um profissional que venha a se capacitar? Como é a qualidade do material de capacitação fornecido pelo fornecedor? Existem instrutores disponíveis para realizar esta formação? Ou existe uma material de auto-estudo que permita esta capacitação? O quão rico é este material?
  7. Verifique o custo da mão de obra especializada: De nada adianta a organização economizar em licenciamento e gastar muito mais a cada projeto de automação que for realizar. Desta forma, é importante que se avalie qual o custo da mão de obra especializada em operar a ferramenta de BPM.
  8. Qual a produtividade oferecida pela plataforma: Finalmente, a produtividade também é um fator essencial na análise de custo entre plataformas distintas. Semelhante à questão do custo da mão de obra, uma plataforma que render uma produtividade significativamente superior às outras pode ter o seu custo de licenciamento pago rapidamente ao final de um primeiro ou segundo projeto de automação.