Webinar – O que a automatização pode fazer pelos seus processos de negócio?

Neste webinar, apresentado por Eduardo Britto em 12/08/16, compartilhamos nosso expertise e experiência sobre benefícios que podem ser obtidos no gerenciamento de processos de negócio com a utilização de soluções de tecnologia.

Aos que participaram da transmissão ao vivo, um muito obrigado em nome do time da iProcess!

Os slides utilizados na apresentação também estão disponíveis no SlideShare:
http://www.slideshare.net/iProcessBPMeSOA/webinar-iprocess-o-que-a-automao-pode-fazer-por-seus-processos

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

Qual a diferença entre BPMS e workflow?

Resposta: Workflow é um dos conceitos de tecnologia para processos mais antigos, com mais de 30 anos de uso no mercado. É a tecnologia que propicia o controle de fluxos de trabalho de forma automatizada, gerenciando a execução sequenciada de tarefas executadas por pessoas e por sistemas. Com o amadurecimento da disciplina de gestão por processos de negócio, novas tecnologias foram agregadas ao simples gerenciamento de tarefas. Assim, uma suíte BPM (ou BPMS) é uma ferramenta mais completa, que também incorpora um motor de processos (workflow) incorporando outros componentes como: modelador gráfico de processos, gerenciamento de regras de negócio, gerenciamento de interação com outros sistemas e pessoas, recursos de gestão proativa do processo entre outros.
Sugerimos a leitura do artigo abaixo, que fala mais sobre o tema:
BPM e Workflow – qual a diferença? 

 

Qual a ferramenta usada para os exemplos de automação?

Resposta: A iProcess trabalha hoje com diversos BPMS, tais como Oracle BPM, Lecom BPMS, Sydle, Orquestra, BizAgi e Oracle PCS. As telas dos exemplos da apresentação forem retiradas de alguns destes produtos.

 

Qual a ferramenta sugerida  para simulação?

Resposta: Existe diferentes produtos pagos no mercado que permitem a realização de simulação de processos. Contudo, o mais conhecido e que sugerimos que seja avaliado numa primeira iniciativa é a funcionalidade de simulação do BizAgi, por ser um software hoje gratuíto, acessível para a maioria das pessoas, e que possui bons recursos de simulação. Vocês podem conhecer um pouco mais do simulador do BizAgi no Webinar Simulação como Ferramento de Análise de Processos de Negócio.

Convite para webinar: O que a automatização pode fazer pelos seus processos de negócio?

Sobre este webinar:
O amadurecimento da gestão por processos invariavelmente chega até a TI, com a necessidade de preparar e adequar sistemas e soluções que apoiem no controle das informações e das ações realizadas pela organização para produzir e entregar seus produtos e serviços.
Neste webinar, apresentaremos as atividades de modelagem, automação, execução e medição com plataformas de BPM – soluções de tecnologia criadas especificamente para apoiar as organizações neste controle, e como obter os melhores resultados na automatização de processos.

Como funciona?
É simples: inscreva-se no webinar através do link do evento e você receberá um e-mail de confirmação.
(Atualização: evento concluído. Assista a gravação e respostas às perguntas enviadas em no post Webinar – O que a automatização pode fazer pelos seus processos de negócio?)

Na data e horário do evento, acesse o link indicado no e-mail usando um computador com fones e aguarde a seção começar.

Importante: chegue um pouco antes para garantir sua participação. O número de participantes assistindo ao vivo é limitado a 100 pessoas, e os lugares são disponibilizados por ordem de chegada!
Durante a apresentação, você poderá interagir com o instrutor enviando perguntas via chat, que serão respondidas ao final do seminário.

Webinares anteriores:
Confira os vídeos dos últimos webinares realizados pela iProcess em 2014 e 2015!

Webinar – Erros & Acertos do uso de BPMS no Brasil

Esta é a gravação do primeiro Webinar da série lançada este ano pela iProcess, através do qual compartilhamos nosso expertise e experiência em gestão por processos.
Aos que participaram da transmissão ao vivo, um muito obrigado em nome do time da iProcess!

 

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

Assisti a uma palestra há algumas semanas onde a abordagem quanto ao termo de automação foi questionado, ou seja, a tendência é não utilizarmos mais o termo devido às plataformas atuais: celular, sistemas legados, workflow etc. Qual a sua opinião sobre essa colocação, um pouco superficial, mas que preocupa?

Resposta: De parte da iProcess, não nos preocupa se o termo a ser utilizado é automação, automatização, digitalização, … e sim que possamos viabilizar a melhoria de processos através da tecnologia. 

Como saber qual é a melhor área para fazer um protótipo de modelagem?

Resposta: Certamente a escolha do prirmeiro processo a ser modelado ou redesenhado na organização é muito importante para o sucesso da continuidade destas iniciativas. Convido a vocês a assistirem a um webinar em que falamos do assunto: Webinares iProcess 2014 – Primeiros Passos em BPM: Os desafios do primeiro projeto e Webinares iProcess 2014 – Primeiros Passos em BPM: da Venda Interna ao Primeiro Processo.

A base de automação é via BPA?

Resposta: O BPA é uma solução para a modelagem de processos pelo escritório de processos onde são armazenados os processos na visão de negócio. A partir desta visão o processo precisa ser detalhado para um modelo orientado à automação para que possa ser implementado em uma ferramenta de BPMS.

Eduardo, você tem como demonstrar um contexto referente ao item 11? De fato, esse é um problema quando você apresenta uma solução para o cliente?

Resposta: O item “#11 Achar que o processo irá substituir as aplicações” traz uma situação muito comum nas organizações de acreditarem que o BPMS compete com o sistema legado. A grande confusão acontece quando pensamos no BPMS substituindo pequenos formulários e cadastros que existem em sistemas periféricos, pois esta substituição pode até se mostrar viável tecnicamente. Contudo, quando falamos de sistemas mais robustos, como um sistema de RH, financeiro, de planejamento da produção, … normalmente fica mais claro para o cliente que o BPMS tem o objetivo de orquestrar a tramitação dos processos e não de substituir funcionalidades como a emissão de uma nota fiscal ou o cálculo de uma folha de pagamento.

Existe alguma ferramenta que permita modelar o processo e os DADOS que fluem no processo?

Resposta: Todas as ferramentas de automação trabalham com o conceito de modelar o processo e, ao mesmo tempo, modelar os dados que vão trafegar no processo. O que difere uma da outra é a forma como esta modelagem é feita. Algumas tem a parte de modelagem de dados bastante explícita e separada de outras etapas do processo de desenvolvimento (praticamente a definição de tabelas de dados relacionadas ao processo), já em outras esta associação é mais sutil, onde são definidos objetos simples de dados.

O mapeamento dos processos são utilizados pelo sistema de automação? Percebi que todos os desenhos foram feitos no Bizagi, tendo os processos no visio é fácil fazer essa conversão?

Resposta: Sim, a base inicial em toda ferramenta de automação de processos é ter o processo modelado dentro da ferramenta. Em muitas delas, existem recursos de importação de processos de outras ferramentas, então é possível modelar o processo em uma ferramenta (ex: Visio) e importar o mesmo na ferramenta de automação.

Você citou que a iProcess tem uma relação de requisitos (centenas) para implementação de BPMS. Essa relação pode ser compartilhada aqui?

Resposta: Esta relação é um dos produtos de consultorias que a iProcess oferece no mercado. Estamos lançando, inclusive, neste mês de agosto um pacote de seleção de plataformas que permitirá que as empresas interessadas na seleção de uma plataforma de BPMS sejam preparadas para esta seleção através de um curso EAD, conheçam esta planilha e recebam diversas soluções conhecidas de mercado já avaliadas pela iProcess.

É possível termos acesso a um case ou a uma empresa para a qual a iprocess implantou uma solução desde o levantamento até a modelagem e “automação”? Gostaria de ter uma visão mais aprofundada sobre essa solução, principalmente, sobre usar um Bizagi na modelagem e usar uma ferramenta BPMS.

Resposta: Teremos o maior prazer de compartilhar cases da iProcess sobre projetos que foram da modelagem até a automação, entre em contato conosco que poderemos conversar a respeito.

De forma geral, você acha que o mercado Brasileiro tem maturidade para automação de Processos?

Resposta: Com certeza. Na verdade já existem empresas brasileiras automatizando processos há muitos anos, desde o tempo em que as ferramentas de automação de processos eram mais simples, chamadas simplesmente de Workflow. E cada vez mais empresas procuram esta iniciativa para facilitar a execução e controle dos processos. Porém, o que acontece é que algumas empresas acham que a automação de processos é a solução para todos os seus problemas, e isso nem sempre é verdade. A realização de etapas de modelagem, análise (para identificar os pontos fracos) e melhoria de processos deveriam sempre ser realizadas antes da automação, sendo que a automação só poderia ser executada diretamente se o processo já é conhecido, correto e está funcionando bem, apenas com oportunidades de melhorar sua eficiência com o uso da tecnologia.

Das 30 ferramentas, quais você considera mais eficiente, com alta usabilidade e que colabora para uma melhor visualização do desenho do processo?

Resposta: As soluções hoje de mercado tem diferenças de funcionalidade muito significativa. Não existe uma ferramenta que se destaque em relação a outras como temos, por exemplo, um Microsoft Word que é preferido pela maioria das pessoas quando o assunto é editor de texto. Por isso que é fundamental a avaliação de quais os requisitos que a empresa tem necessidade, para que somente depois a seleção da plataforma seja realizada.

As ferramentas de BPM oferecem suporte para análise das métricas ou é necessário a compra de uma ferramenta de análise a parte?

Resposta: Normalmente as ferramentas de BPM já vem com um conjunto de indicadores e dashboards padrões, que permitem o monitoramento e acompanhamento da eficiência do processo, como por exemplo tempo médio de execução do processo e atividades, as atividades e usuários que são os maiores gargalos, dentre outros. Dependendo da ferramenta, é possível criar relatórios/dashboards customizados, para indicadores específicos de negócio da organização. Além disso, algumas plataformas oferecem ainda a possibilidade de adquirir uma ferramenta epecífica de BAM (Business Activity Monitoring), voltada especificamente para o monitoramento de indicadores em tempo real.

O que você pode comentar acerca da utilidade de uso da modelagem com BPMN para apresentar a orquestração de web services?

Resposta: Se estamos falando especificamente de modelagem de processos, BPMN pode ser usada para representar quaisquer processos ou situações de negócio desejados. Existem elementos da notação que servem para representar integrações e chamadas de serviços, neste sentido a notação poderia sim ser utilizada para repreentar um processo puramente de orquestração de web services. Além disso, existe outros diagramas presente na versão 2.0 da notação, que é o Diagrama de Coreografia, que se aplica também para representar orquestração de serviços.

Como obter informações adicionais sobre o curso de modelagem para automação?

Resposta: Por favor, acesso a página da iProcess Education (www.iprocesseducation.com.br) e conheça os nossos cursos.

O levantamento de requisitos para automação é próximo ao levantamento de requisitos para implantação de sistemas?

Resposta: Com certeza. Ambos compartilham conceitos e metodologia de levantamento. O que difere é a definição dos requisitos da solução, que no caso de automação de processos é guiada sempre pelo levantamento e modelagem do processo, enquanto que no levantamento convencional é guiado através de casos de uso e necessidades específicas de aplicação.

Como é comercializado o produto citado por vocês, de relação de requisitos para adoção de um BPMS?

Resposta: Trabalhamos tanto com uma consultoria de seleção de plataformas sob medida para a sua organização como também através de um pacote contendo um curso de seleção, a planilha preenchida e uma série de ferramentas já avaliadas.

Processos com integração com outros sistemas os campos de integração e e os mock ups devem ser feitos antes de implementar no sistema as entidades ?

Resposta: É fundamental que no momento que se identifique a necessidade e viabilidade de uma determinada integração do processo com um sistema, que a assinatura desta integração seja acordada entre a equipe de processos e a equipe do sistema. Neste caso, caberá a equipe do sistema garantir que a assinatura acordada pode ser disponibilizada, mesmo que ainda existam pendências técnicas do lado do sistema para a sua disponibilização.

 

Convite: Webinar Automação de Processos com BPMS no Brasil – Erros e Acertos

iProcess e Lecom convidam para o webinar:

A opinião do sucesso da automação de processos no Brasil está muito ligada à experiência vivida por quem a acompanhou. Aspectos como a forma como foi conduzido o projeto de automação, a maturidade do processo escolhido ou a capacidade da ferramenta em entregar as funcionalidades desejados são apenas alguns dos motivos que fazem que estas opiniões variem muito.

Com uma atuação de 16 anos em automação de processos em clientes de diferentes tamanhos, a iProcess acompanhou muitas destas iniciativas e experiências. Nesta apresentação, avaliaremos as características dos projetos de automação no Brasil e os principais aspectos que as levaram ao sucesso – ou fracasso.

Participe deste webinar, realizado em conjunto pela iProcess e Lecom BPM, com apresentação de Eduardo Britto, Consultor de Processos com 18 anos de experiência, Diretor da iProcess, Mestre em automação de processos, CBPP, OCEB, PMP.

Quando?
28/07/2016 às 11:00

Duração:
1 hora

Inscreva-se agora (a participação é gratuita!):
https://www.eventials.com/lecom/automacao-de-processos-com-bpms-no-brasil-erros-e-acertos/

Como documentar funcionalmente o processo de negócio como requisito de software

Na automação de processos, os processos de negócio são definidos e otimizados a fim de serem executados sobre uma arquitetura de sistemas informatizada.

No artigo Benefícios da Automação de Processos do blog da iProcess, tratamos dos benefícios e vantagens da automação de processos, estabelecendo uma visão dos ganhos obtidos quando se automatiza um processo. Porém, alguns cuidados devem ser tomados para escolher um processo a ser automatizado e estabelecer o nível de detalhamento necessário do processo para tal, tendo como objetivo automatizar processos com tarefas que possam efetivamente demonstrar bons resultados. Em Estudo de Caso: Automatizar o processo (ou não)? Eis a questão! exploramos esta questão através de um estudo de caso.

As etapas de modelagem na transformação de um processo

Nos projetos 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.

O artigo BPMS: como as etapas do ciclo BPM geram segurança no processo automatizado aborda este tema, incluindo aí os riscos envolvidos em um projeto em que se parte diretamente para a etapa de implementação (TO DO), sem passar pelas demais. Isto porque é na etapa de TO BE, em que há a proposição de melhorias no processo e são definidos os requisitos de software que irão compor a solução automatizada. Já falamos sobre esta ligação no artigo O que BPM tem a ver com requisitos de software? Tudo!, enfatizando que os requisitos de software são identificados a partir do processo.

Documentando a modelagem do processo para automação (TO DO)

Passadas todas estas fases, chega a hora da implementação do processo. O processo e os requisitos de software complementares serão detalhados funcionalmente (TO DO) e implementados pela equipe de desenvolvimento. E aí entra em cena a Especificação Funcional do processo. Ela especifica o fluxo a ser automatizado no BPMS e sua estrutura de dados, regras para identificação de participantes e comportamento de cada componente.Resumidamente, a Especificação Funcional deve atender aos seguintes objetivos:

  • Concentrar as informações do processo de negócio necessárias para a automação do processo;
  • Utilizar linguagem que deve ser de fácil compreensão pelo público-alvo;
  • Fornecer informações suficientes para que o projetista possa desenvolver a especificação técnica do processo;
  • Servir de referência para o desenvolvimento e homologação da solução.

Temos encontrado, ao longo dos projetos de automação de processos em que a iProcess atua, alguns clientes que já possuem uma metodologia, utilizam ferramentas e templates para documentar processos automatizados, enquanto outros não possuem nada definido. Nas organizações que já tenham adotado uma metodologia de desenvolvimento com documentação funcional dos requisitos, é comum encontrarmos documentos como Casos de Uso, Especificações de Interface, Especificações de Serviço ou de Regras de Negócio. Nos projetos de automação de processos, é comum que os requisitos se estendam além da programação do fluxo no BPMS, envolvendo o desenvolvimento ou customização de componentes adicionais ao processo, como aplicações de apoio, cadastros de backoffice e serviços de integração com outros sistemas. Para estes requisitos, os documentos já adotados pela TI continuam sendo bastante apropriados. 

 Assim, a Especificação Funcional do Processo (o modelo TO DO) vem para complementar a documentação do sistema definindo funcionalmente o processo de negócio, e requer um detalhamento de como o fluxo do processo se comportará ao ser automatizado. São informações importantes neste modelo:

  • Diagrama do processo automatizado;
  • Modelo de dados do processo;
  • Identificação de usuários ou grupos de usuários participantes do processo (Papéis);
  • Formulários do Processo;
  • Especificação dos componentes do processo, que são eventos, tarefas humanas e automáticas, notificações/envios de email, controles de tempo, gateways, subprocessos, regras de negócio e sensores de indicadores;
  • Definições de interface para as atividades humanas;
  • Referências a serviços de outros sistemas;

Esta especificação deve ser realizada por um Analista de Processos e Sistemas, ou um analista de sistemas que tenha desenvolvido uma visão de processos, horizontal aos sistemas, e que conheça as capacidades de implementação do BPMS adotado pela empresa

O Analista de Processos e de Sistemas, pode encontrar alguma dificuldade em estabelecer a melhor forma de como escrever utilizando uma linguagem de fácil compreensão pelo usuário e ainda assim fornecer informações suficientes para que sirva de referência para a elaboração da especificação técnica e o posterior desenvolvimento da solução. Uma sugestão nesta situação é o alinhamento com os responsáveis pela aprovação do documento no cliente, para estabelecer qual será o nível de detalhamento da Especificação Funcional do processo, a fim de definir se haverá necessidade de utilizar documentos complementares mais técnicos para a equipe de desenvolvimento, ou em mais alto nível para a equipe de negócio.

Temos observado que, às vezes, o cliente opta por realizar uma “tradução” da especificação para a área de negócio ou absorver para si a aprovação do documento. Quanto mais precisa for a Especificação Funcional do processo, menos problemas de entendimento tendem a ocorrer entre a expectativa do cliente e o que está sendo desenvolvido. Isto porque as etapas de desenvolvimento e homologação dos processos vão utilizar estas informações, garantindo assim, que o que foi definido e aprovado pelo cliente seja entregue.

Cabe aqui salientar que a Especificação Funcional do processo, assim como de sistemas, não fica “congelada”, sem receber as atualizações que ocorrerem no escopo do projeto durante o seu ciclo de vida. Ajustes na documentação funcional podem ser necessários após a finalização da etapa de especificação funcional por diversos motivos e devem ser realizados, sempre que necessário, para que se mantenha a consistência entre o que foi especificado e o que foi desenvolvido. E neste caso, a gestão de mudanças do projeto é que tratará desta atualização.

Se este assunto lhe interessou, no nosso curso iPE03 – Modelagem de Processos para Automação, reservamos um capitulo inteiro para tratar deste assunto, inclusive com exercícios práticos.

Você está pronto para o exame CBPP? Conheça o simulado da iProcess e prepare-se!

CBPP – Certified Business Process Professional é uma certificação concedida pela ABPMP para profissionais de Gestão por Processos de Negócio.

Para ser um profissional certificado, além de experiência é preciso demonstrar conhecimento em BPM  (nós já falamos sobre esta certificação aqui no blog ;).
O Exame CBPP é uma prova de conhecimento que envolve questões baseadas no BPM CBoK, o Corpo Comum de Conhecimento em Gestão por Processos de Negócio.

De acordo com os resultados da Pesquisa Nacional em Gerenciamento de Processos de Negócio no Brasil publicada em 2015 pela revista BPM Global Trends, 77% das organizações que responderam à pesquisa enxergam a certificação CBPP como um diferencial ao contratar profissionais para a sua equipe.

Você está preparado?

Para apoiar profissionais que estão se preparando para a certificação, a iProcess preparou um kit de exames simulados com mais de uma centena de questões objetivas com respostas comentadas!

Aproveite esta oportunidade para verificar seus conhecimentos e reforçar seus estudos!

Assinando este pacote de simulados você terá acesso a:

  • Simulados na Plataforma Digital da iProcess Education por 1 mês, podendo realizar os testes na ordem que desejar e quantas vezes quiser.
  • Acesso aos fóruns de discussão exclusivos da iProcess Education sobre cada área de conhecimento do BPM CBoK, podendo verificar dúvidas comuns de outros participantes e enviar suas dúvidas.
  • Guia de Referência Rápida BPMN 2.0 da iProcess, na versão digital.


Avaliação de Produtos: Oracle Process Cloud Services (Oracle PCS)

No mercado de automação de processos há mais de 20 anos, a Oracle acaba de lançar uma solução para automação de processos simples, leve e que roda em ambiente na nuvem: o Oracle Process Cloud Service, ou Oracle PCS.
Com o foco na automação de processos, o produto possui recursos interessantes para a modelagem e execução de processos, todos disponibilizados em um ambiente simples de boa usabilidade que permitem tanto o usuário de negócios com a área de TI realizarem a automação de seus processos.

 

Na lista abaixo analisamos como a plataforma atende a alguns dos principais requisitos de BPMS:
  • Modelagem com BPMN: Possui suporte tanto a nível de modelagem como a nível de implementação e execução de grande parte dos recursos oferecidos pela notação BPMN.

    Modelagem do processo com BPMN

  • Modelagem de Formulários: Com o uso da tecnologia Webforms, permite o desenvolvimento de formulários em ambiente visual de forma fácil e rápida com os recursos de arrastar e soltar. É possível definir um formulário para cada atividade ou reaproveitar um mesmo formulário em várias atividades, agilizando o desenvolvimento da automação.

    Editor de formulário visual (WYSIWYG)

  • Regras de Negócio em Formulários: Possui uma linguagem nativa de script que manipulam as propriedades dos elementos dos formulários. A linguagem permite a configuração de regras de negócio básicas e avançadas, mas de acordo com o que se deseja fazer, um conhecimento e familiaridade com programação começa a se fazer necessário.
  • Integração com Sistemas: Possui nativamente a chamada de serviços. Contudo, como o ambiente está em ambiente cloud e não existe hoje formas de se estabelecer uma VPN ou um túnel privado com o cliente, faz-se necessário que os serviços estejam disponíveis em ambiente público na web.

    Configuração de acionamento de serviços pelo processo

  • Orquestração de Sistemas: Apesar de não ter recursos mais poderosos para a implementação de processos de natureza sistêmica, o PCS se integra naturalmente com outro produto da Oracle chamado ICS – Integration Cloud Service – que permite a configuração de um barramento de serviços em ambiente de nuvem, facilitando a orquestração deste tipo de necessidade.
  • Gestão de Conteúdo: De forma similar como resolve as necessidades de processos sistêmicos, o PCS se integra de forma nativa com o Oracle Documents, plataforma de gestão de documentos na nuvem da Oracle que permite o compartilhamento, colaboração, visualização, controle de versão e trâmite dos documentos ao longo dos processos.
  • Motor de Regras: Possui um ambiente próprio para a configuração de regras de negócio que são consumidas por atividades do processo através da configuração de tabelas de decisão.

    Criação de Regras de Negócio

  • Ambiente de Execução: Bastante prático e funcional, possui uma lista de trabalho onde são executadas as atividades humanas. Permite a criação de filtro para a seleção de atividades e a consulta de onde está um determinado processo e qual o seu histórico de execução.

    Ambiente de execução do processo

  • Mobile: Possui aplicativo próprio para iOS eAndroid para a execução de processos em ambiente mobile.
  • Indicadores e Relatórios: Disponibiliza uma série de relatórios e dashboards pré-prontos que permitem o acompanhamento de qualquer processo modelado na plataforma. Contudo, possui nativamente poucos recursos de customização destes indicadores.

    Indicadores e relatórios do Oracle PCS

Nesta solução de BPM, a Oracle provê todo o ambiente e infraestrutura do produto, tendo um modelo de licenciamento baseado na compra de créditos que podem ser utilizados o licenciamento por usuário, com valores distintos de acordo com o tipo de usuário: Administrador, Participante e Invocador.

 

Na avaliação da iProcess…

… o Oracle PCS chega como um bom produto para a implementação de processo de baixa e média complexidade, sendo uma plataforma bastante produtiva para o desenvolvimento dos processos a que se propõem e tendo um bom custo x benefício para empresas que querem rapidamente implementar muitos processos com predominância de atividades humanas na sua organização.
É uma solução de rápida adoção, visto que podem ser adquiridos poucos usuários a um custo acessível e que o ambiente em algumas horas já estará disponível para as áreas de Ti e negócios dada a facilidade da automação na nuvem.
Como pontos a melhorar está a necessidade dos serviços do cliente terem que estar expostos na web para serem evocados e pouca customização de relatórios e indicadores.

 

Para conhecer um pouco mais do Oracle PCS, assista aos vídeos abaixo.

 

Vídeo 1: Os benefícios da automação de processos com o Oracle Process Cloud Services

Vídeo 2: Demonstração de utilização do Oracle Process Cloud Services

Para mais informações, fale com a iProcess ou entre em contato com a gente no email contato@iprocess.com.br.

Tratamento de falhas em processos automatizados no Oracle BPM

Processos automatizados com a utilização de Suítes de BPM (BPMS) podem trazer grandes benefícios para a organização através do controle e gerenciamento da execução das atividades, além da possibilidade de acionar ações em outros sistemas de informação da organização, como gravar ou obter dados importantes para as tarefas do processo.

Na implantação de uma solução automatizada, um dos aspectos técnicos mais importantes a serem planejados está relacionado ao gerenciamento das falhas que podem acontecer no decorrer da execução do processo.

Isto é fundamental para garantir que, em caso de falhas, o problema possa ser resolvido ou mitigado, evitando que o processo fique parado.

No Oracle BPM, existem situações em que você poderá encontrar problemas inesperados que levam seu processo automatizado a falhar. Uma destas situações são erros de sistemas na execução de um processo.

Erros de sistema são consequências de uma falha no software ou hardware onde o BPMN está rodando. Pode ser ocasionado por várias causas. Alguns exemplos de causas de erros de sistemas são:

  • Falha na conexão com o Banco de dados
  • Perda de conectividade
  • Problema com o disco rígido
  • Indisponibilidade de serviço sendo invocado

Para recuperar os erros de sistema é possível utilizar no Enterprise Manager a opção de recuperação de falhas.

Neste post será descrito um exemplo de como definir a política de erros para processos com problemas, que permitem intervenção de usuário.

Neste exemplo, é definida uma política de falhas onde a mesma será recuperada manualmente pelo Administrador. Por exemplo,  em um processo de compras, o usuário cadastra o orçamento solicitado pelo cliente informando os dados do cliente (endereço, cep, CPF/CNPJ) e dados da compra (produtos desejados e quantidades). Neste momento todos os itens solicitados no orçamento estão em estoque. O usuário envia este orçamento ao cliente e aguarda o retorno positivo ou negativo. Caso o retorno seja positivo, o processo segue seu fluxo normal. Uma tarefa de serviço automática é chamada para verificar se ainda existem os itens solicitados em estoque. Porém, o serviço que faz a validação do estoque estava fora do ar no momento em que o processo precisou. Com isso, gerou-se uma falha no fluxo do processo.

No Oracle BPM, são necessários dois arquivos para definir o que deve acontecer quando ocorre um erro na execução do processo BPMN:

  • fault-policies.xml
  • fault-bindings.xml

O uso destes arquivos devem ser configurados no composite do processo BPM e adicionados no diretório do processo.

No Oracle BPM 11g…

No Oracle BPM 11g, basta criar manualmente os dois arquivos dentro do diretório do processo (conforme figura abaixo).

Diretório - arquivos

Exemplo da configuração no composite.xml:

<component name="PocAprovadores">
    <implementation.bpmn src="processes/PocAprovadores.bpmn"/>
    <property name="oracle.composite.faultPolicyFile">fault-policies.xml</property>
    <property name="oracle.composite.faultBindingFile">fault-bindings.xml</property>
</component>

A ação de intervenção de usuário é definida com a tag ora-humam-intervention no arquivo fault-policies.xml. Sem a política de falhas, as instancias BPMN não irão gerar falhas recuperáveis:

<faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <faultPolicy version="1.0" id="DefaultPolicy"
                xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
                xmlns:xs="http://www.w3.org/2001/XMLSchema"
                xmlns="http://schemas.oracle.com/bpel/faultpolicy"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <Conditions>
      <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
                  name="bpelx:bindingFault">
           <condition>
               <action ref="ora-human-intervention"/>
           </condition>
       </faultName>
       <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
                  name="bpelx:remoteFault">
           <condition>
               <action ref="ora-human-intervention"/>
           </condition>
       </faultName>
       <faultName xmlns:task="http://xmlns.oracle.com/bpel/workflow/taskService"
                  name="task:operationErroredFault">
           <condition>
               <action ref="ora-human-intervention"/>
           </condition>
       </faultName>
       <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
                  name="bpelx:selectionFailure">
           <condition>
               <action ref="ora-human-intervention"/>
           </condition>
       </faultName>
       <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
                  name="bpelx:runtimeFault">
           <condition>
               <action ref="ora-human-intervention"/>
           </condition>
       </faultName>
       <faultName>
           <condition>
               <action ref="ora-human-intervention"/>
           </condition>
       </faultName>
   </Conditions>
   <Actions>
           <Action id="ora-human-intervention">
               <humanIntervention/>
           </Action>
           <Action id="ora-rethrow-fault">
                <rethrowFault/>
           </Action>
           <Action id="ora-terminate">
                <abort/>
           </Action>
           <Action id="ora-replay-scope">
                <replayScope/>
           </Action>
           <Action id="ora-retry">
               <retry>
                   <retryCount>5</retryCount>
                   <retryInterval>10</retryInterval>
                   <exponentialBackoff/>
                   <retryFailureAction ref="ora-human-intervention"/>
               </retry>
           </Action>
   </Actions>
   </faultPolicy>
</faultPolicies>

Onde “retryCount” é a quantidade de vezes que vai tentar recuperar o erro, “retryInterval” é o tempo programador de intervalo entre as tentativas de recuperação do erro, “retryFailureAction“ é a ação que será tomada se todas as tentativas de recuperação de erros falharem.

O arquivo fault-bindings associa a política de falhas definidas no arquivo fault-policies.xml ao composite do processo:

<faultPolicyBindings version="1.0"
                    xmlns="http://schemas.oracle.com/bpel/faultpolicy"
                    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <composite faultPolicy="DefaultPolicy"/>
</faultPolicyBindings>

Uma vez definida a intervenção de usuário como ação, é possível recuperar as falhas no Enterprise Manager.

NO ORACLE BPM 12c…

No Oracle BPM 12c, existe uma nova opção da criação do arquivo fault-policies pelo JDeveloper.  Toda vez que é criado um arquivo fault-policies pelo editor, você basicamente está criando um novo arquivo XML com a política de falhas padrão. Ou seja, criando o arquivo fault-policies.xml na pasta do processo.

Através do JDeveloper, este arquivo pode ser configurado pelo editor de forma amigável.

Fault-Policies Oracle 12 c As falhas são categorizadas na seção “Fault Handler” em “System faults” – bindings faults, mediator faults and remote faults – e “Service Faults” – uma lista de falhas definidas pelo WSDL que seu composite utiliza.

Para cada tratamento de exceção é possível selecionar uma ação padrão, da lista de ações definidas.

Nota: assim como no 11g, para que o processo identifique e use o tratamento de erros, é preciso criar manualmente o arquivo fault-bindings.xml e relacionar a política criada.

Também é preciso configurar manualmente os arquivos de tratamentos de falhas no composite.xml.


Referências:

10 pontos chave a considerar na hora de estimar um projeto com BPMS

Com um largo know-how em automação de processos e já tendo realizado algumas centenas de implementações nas mais diversas ferramentas, a estimativa de esforço para a automação de um processo é quase que uma prática diária na iProcess.

Como somos muito questionados sobre como fazemos isso, e neste artigo indicamos algumas diretrizes para auxiliar nossos clientes a fazer avaliar a sua estimativa.

1. Estimativa de implementação é somente uma parte da Estimativa do Projeto

Falaremos neste artigo sobre o esforço direto de um programador para pegar um processo desenhado e detalhado funcionalmente e implementa-lo em uma ferramenta de BPMS. Contudo, isso costuma ser menos da metade do esforço de um projeto!
Um projeto de automação bem elaborado precisa que se faça o levantamento do processo, sua modelagem para automação, projeto técnico, roteiro de testes, preparação de dados de sistemas legados, execução e ajustes da sua validação, homologação com o usuário, elaboração de documentação, elaboração de planos de instalação, instalação em ambiente de homologação e produção, acompanhamento em produção, suporte dos primeiros dias, gerência de projeto, gerência de configuração, gestão de requisitos, entre outros!
Evidentemente que tudo isso é um mundo a parte, e dependerá das características do processo, da cultura da organização e do seu processo de desenvolvimento. Contudo, são atividades que não podem ser desprezadas, pois garante a qualidade do resultado da entrega da automação.

2. Estimativa de Processos não é Estimativa de Software

A estimativa de software convencional utiliza métodos como Pontos de função (PF) ou Unidades de Casos de Uso (UCP) para realizar a estimativa de esforço. São técnicas que utilizam como referência a complexidade da interface de usuário. Na automação de processos é diferente, pois a complexidade está ligada diretamente aos elementos BPMN que compõem o seu processo e a complexidade em implementá-los​ no BPMS adotado​. Logo, estas técnicas não tem aplicação direta para estimar esforço de automação de processos.

3. Você deve conhecer o seu processo (ou projetar como ele deveria ser)

Não tem jeito: você não tem como estimar um processo que você não​ o​ conhece. O esforço de implementação de um processo está ligado diretamente às suas características, elementos necessários e respectivas complexidades. Logo, você precisará levantar o processo.
Caso não haja esta possibilidade, você deverá inferir esta complexidade e assumir o risco no momento da automação de ter que realizar ajustes para mais ou para menos.

4. Cada ferramenta de automação possui uma produtividade diferente

Não existe um número mágico que traga o esforço de implementação de um processo em todas as ferramentas. Cada ferramenta possui suas peculiaridades: algumas são mais produtivas, outras são mais completas e outras são mais complexas. Em algumas uma atividade humana é feita com muita facilidade, mas uma integração com um webservice ou um banco de dados dá muito trabalho.
Por isso, você deve antes de mais nada escolher a ferramenta em que será feita a automação para somente depois avaliar o seu esforço.

5. Identifique o modelo de dados do Processo

O que diferencia uma instância de processo de outra em execução são os dados em que elas manipulam. Cada processo tem atrelado a si um modelo de dados específico, que determina quais informações são manipuladas, incluídas ou consultadas ao longo do processo.
A complexidade do modelo de dados de um processo está ligado diretamente ao número de informações que são manipuladas e as suas características: se existem dados mestre-detalhe, se é feita a manipulação de arquivos, entre outros fatores.
A estimativa de esforço deve levar em consideração este montante e complexidade para projetar o esforço de manipulação destas informações ao longo do processo.

6. Identifique os elementos de processo que são implementados na sua ferramenta

O esforço de automação de um processo está ligado diretamente aos elementos que ele possui. Um processo com 2 atividades humanas e 2 gateways tende a ser 4x mais rápido de ser desenvolvido do que um processo com 8 atividades humanas e 8 gateways por exemplo.
A estimativa de automação de processos está ligada diretamente ao número de elementos que o seu processo possui, e é por isso que você deve conhecê-lo para poder estimá-lo.

7. Identifique os fatores de complexidade de cada elemento

Contudo, somente identificar os elementos não é o suficiente, pois um mesmo elemento pode ter uma implementação fácil ou complexa. Por exemplo, você pode ter
um gateway que somente testa se na atividade anterior houve uma aprovação ou reprovação (simples) ou um gateway que valida uma complexa regra de negócio;
Uma integração que passa o número do CNPJ e recebe o nome do cliente ou o cadastro de uma nota fiscal ​e seus itens ​em um ERP;
Uma atividade humana que informa ao solicitante que seu pedido chegará em 20 dias ou uma atividade distribuída para o ator mais produtivo entre uma série​,​ que possui um SLA rígido, controle de prazos e alertas e escalonamento caso a mesma não seja realizada em até 3 dias úteis antes do prazo final do processo.
Para mapear estas condições, você deve criar critérios de complexidade e atribuir um esforço para cada nível de complexidade.

8. Classifique o seu processo de acordo com estes fatores

Uma vez entendido os fatores para a projeção de complexidade de implementação de um processo, o processo escolhido deverá ser classificado: seus elementos contados, a complexidade de cada elemento avaliada e o esforço da sua implementação calculado.

9. O desenvolvimento das telas das atividades são parte significativa do esforço

​Mesmo com estes cuidados, as coisas não são tão fáceis como parecem, e apesar de estarmos falando de desenvolvimento de processos, eles possuem um componente importante chamado de interface de usuário das atividades humanas.
Na iProcess estimamos que o desenvolvimento de interfaces exige em média um esforço de 40% a 70% do esforço de desenvolvimento de um processo e depende muito dos recursos visuais e da linguagem de programação que cada ferramenta disponibiliza para a implementação das suas interfaces.
Existem soluções de BPMS cuja interface é “engessada” (no sentido que você define poucas coisas em termos de layout e comportamentos) enquanto que outras você pode fazer tudo o que qualquer linguagem moderna de programação web permite.
Por isso, você deve também mapear a complexidade de desenvolver cada interface e realizar uma contagem exclusiva para as mesmas.

10. Elabore uma planilha para calcular o esforço

Se você chegou até aqui, deve ter visto que são muitas variáveis e informações a serem consideradas. Em processos de complexidade média ou alta, com dezenas de atividades e subprocessos, levantar e calcular todas estas informações à mão torna-se quase impossível.
Logo, sugerimos que você elabore uma planilha com todos estes cálculos e utilize-a como ferramenta para realizar a estimativa do seu processo.

Provando o Valor da Equipe de Processos

Área de Processos, Escritório de Processos, Engenharia de Processos, Governança de Processos. A equipe de profissionais que cuidam dos processos de negócio nas organizações pode ter vários nomes, e às vezes até se mistura com outras áreas de gestão (como a de projetos, de planejamento estratégico ou de TIC, por exemplo). Na prática, é o grupo de profissionais com habilidades aplicadas em atividades como modelagem, análise e documentação de processos.

Mas como a organização envolve estes profissionais? Como é esta relação da equipe de profissionais de processos com as demais na sua organização?

  • Só são chamados para criar diagramas BPMN dos processos afetados por algum sistema que está em implantação.
  • Só são chamados para criar diagramas e manuais para formalizar os processos junto a órgãos fiscalizadores ou reguladores, mas na prática o que é formalizado nem sempre é seguido.
  • São envolvidos quando alguma área de negócio percebe que sua operação está caótica e precisa de alguma organização, pedindo apoio para mapear o fluxo de atividades, documentar suas atividades e criar um manual, que acaba desatualizado e indo pra gaveta em poucos meses.

Bem, se a área de processos na sua organização só faz isso (e acredite, essa é uma realidade comum em muitas organizações brasileiras), talvez esteja na hora de rever seus conceitos!

Quando a equipe de processos é vista apenas como um grupo de pessoas que formaliza como os processos acontecem, ela é um centro gerador de custo. Consome tempo e recursos destes profissionais e também dos profissionais que executam as atividades de negócio, para gerar uma documentação que poderá trazer alguns pequenos benefícios na organização do trabalho, mas em geral pouco significantes no resultado da empresa. Não raro, organizações cuja principal atuação do escritório de processos se baseia nestas atividades, quando têm mudança na sua liderança executiva, acabam tendo sua equipe sendo descartada – porque não é vista como geradora de lucro, e sim de custo.

Estes profissionais, entretanto, têm uma responsabilidade muito maior! Em tempos de crise, as organizações precisam repensar seu negócio e a equipe de processos deveria ser estratégica para isso. É através dos processos que a empresa faz o negócio. Logo, a revisão de processos é a melhor forma de torná-los mais eficiente – e a área de processos é quem domina os conhecimentos, habilidades e ferramentas para isto.

O papel da equipe de processos passa então de um simples grupo de pessoas que documentam processos para geradores de valor na organização. Através da análise dos processos, identificará os problemas e proporá soluções que poderão trazer resultados para a empresa como redução de custos, eliminação de desperdícios, otimização de tempo e recursos e uma operação mais ágil e inteligente.

Mas como associar os resultados obtidos ao trabalho realizado pela equipe de processos?

Através do cálculo de Retorno de Investimento!

A equipe precisa se organizar no estudo do processo, gerando medições antes e depois da implantação das transformações do processo. É comparando os custos da transformação com resultados obtidos que o escritório de processos consegue provar sua efetividade!

Por isso, se você faz parte de uma equipe de processos, lembre-se que a medição de desempenho dos processos e do negócio não é útil apenas para que o dono ou gerente do processo ou da área avalie como está indo sua atividade. Ela é fundamental para que também a área de processos justifique a sua existência dentro da organização!

Esta e outras discussões sobre transformação de processos, monitoramento de desempenho de processos por indicadores e cálculo de retorno do investimento são parte do programa de capacitação Ciclo BPM: Da Estratégia à Medição, realizado pela iProcess Education. Participe desta capacitação e faça a diferença na sua organização! Mais informações no site:
www.iprocesseducation.com.br/ipe00