dicas | Blog da iProcess
Desmistificando tipos de tarefas em BPMN: Tarefa Abstrata, Tarefa de Usuário e Tarefa Manual
Kelly Sganderla - 19 de março de 2014
Em sua riqueza de elementos para a representação de processos de negócio, a notação BPMN traz uma classificação de tipos de tarefas.
Elas ajudam a identificar a forma como a tarefa deve ser executada:
Estes elementos e seus comportamentos esperados estão descritos na especificação BPMN (disponível em https://www.omg.org/spec/BPMN/Current). Apesar disto, a identificação de quando usar cada tipo de tarefa ainda é alvo de alguma ambiguidade.
Em uma série de três artigos, trataremos estes tipos de tarefas com mais detalhes para esclarecer as dúvidas comuns. Para facilitar o entendimento, trataremos os tipos de tarefa de acordo com seu propósito (essa divisão não é oficial):
Tarefa abstrata: abstract task (neste artigo)
Tarefas de interação humana: user task e manual task (neste artigo)
Tarefas de execução de rotinas automáticas: service task, script task e business service task
Tarefas de comunicação: send task e receive task
Tarefa abstrata
A tarefa abstrata (abstract task) é a tarefa sem tipo específico.
Tarefa abstrata (abstract task)
Sobre ela, a especificação diz:
"Uma tarefa sem nenhum tipo de especificação é chamada tarefa abstrata (Abstract Task) (ela era referenciada como None Task em BPMN 1.2)." (pag. 154)
Ou seja, a tarefa abstrata (abstract task) pode ser utilizada em modelagens cujo tipo de tarefa ainda não está definido ou em casos onde a tipificação da tarefa simplesmente não se faz necessária. É o caso dos processos executados manualmente.
Um processo de negócio modelado com tarefas abstratas.
Tarefas de interação humana
Para representar tarefas cuja execução envolve a atuação de pessoas em um processo, BPMN sugere dois tipos de tarefa: a user task (tarefa de usuário) e a manual task (tarefa manual).
Tarefa manual (manual task) e Tarefa de usuário (user task)
O que a especificação diz sobre estes tipos de tarefa:
"Uma Tarefa de Usuário (User Task) é uma tarefa típica de "workflow" onde um ator humano desempenha a tarefa com a assistência de uma aplicação de software e é disponibilizada através de uma lista de de trabalho ou outra forma de gerenciamento semelhante. " (pág 160)
"Uma Tarefa Manual (Manual Task) é uma tarefa que é esperada que seja executada sem o suporte de nenhuma aplicação de execução de processos de negócio ou outra aplicação. Um exemplo disso pode ser um técnico de telefonia instalando um telefone no endereço de um cliente." (pág 161)
"10.3.4.1 Tarefas com o envolvimento humano
Em muitos fluxos de trabalho, o envolvimento humano é necessário para executar certas tarefas especificadas no modelo de fluxo de trabalho. BPMN especifica dois tipos de tarefas com o envolvimento humano, a Tarefa Manual (Manual Task) e a Tarefa de Usuário (User Task).
A tarefa de usuário é executada e gerenciada por um motor de execução de processos de negócio. Atributos relativos ao envolvimento humano, como as pessoas envolvidas e a renderização de interfaces de usuário (UI) podem ser especificados em grande detalhe.(…)
Uma tarefa manual é uma tarefa que não é gerenciada por qualquer mecanismo de processo de negócio. Ela pode ser considerada como uma tarefa não gerenciada, não gerenciada no sentido de que o motor de processos de negócio não acompanha o início e o fim de tal tarefa.
Um exemplo disso poderia ser uma instrução de papel como base para um técnico de telefonia instalar um telefone em um local do cliente." (pág 165)
Ou seja, uma user task (tarefa de usuário) é a tarefa que é executada através de uma aplicação e gerenciada por uma lista de trabalho(1). Em outras palavras, é a tarefa realizada através de uma aplicação, como um BPMS (Business Process Management Suite), uma aplicação de workflow, uma ferramenta de gestão de cronograma ou qualquer outro sistema que apoie o controle do processo.
Já as tarefas manuais (manual task) são aquelas executadas no mundo físico, sem o controle por parte de uma aplicação.
Aqui há uma confusão comum na interpretação do "uso de uma aplicação", inclusive replicada em literatura. Para entender claramente a diferença entre elas, é preciso compreender que o que define se uma tarefa é user ou manual task não é se usamos alguma ferramenta para executá-la, e sim se há um sistema controlando a sua execução.
Isto quer dizer que, se temos por exemplo um processo de venda de produtos que é todo executado manualmente, mas em uma determinada atividade uma planilha eletrônica é usada para calcular o valor a ser cobrado do cliente, e um e-mail é enviado ao cliente com o orçamento do produto, ainda assim (apesar de usar uma aplicação de planilha e o software de e-mail para o trabalho) esta será uma tarefa manual, pois não há controle nem gestão sobre quem faz, quando iniciou e quando concluiu a tarefa.
Mesmo utilizando ferramentas como planilha eletrônica e email, ainda assim a tarefa "Apresentar orçamento" neste processo é manual.
Numa modelagem de processo que não será automatizado, e que portanto são pessoas que lerão e interpretarão o modelo, não faz muito sentido essa diferenciação, já que as pessoas, ao lerem a documentação do processo, têm condições de interpretar o modelo mesmo que os tipos de tarefas não estejam esclarecidos.
Na modelagem para automatização, entretanto, isso é muito importante. A tarefa de usuário é aquela em que o processo deve aguardar que um usuário informe o resultado do trabalho, registrando que a mesma foi concluída para então dar seguimento ao fluxo do processo. Já sobre a tarefa manual o sistema não tem nenhum controle, então mesmo que ela seja incluída no modelo, ele "passará batido" por ela.
Considere novamente o processo de atendimento de chamado, no qual há uma atividade para um técnico de telefonia para realizar uma visita técnica ao cliente, e que este processo terá sua execução controlada por uma aplicação (por exemplo um BPMS).
Neste processo, podemos ter dois cenários:
Cenário 1: O Técnico acessa uma lista de tarefas, com todos os chamados a realizar, identifica o chamado que está executando e finaliza a tarefa. Com isso, o sistema identifica que a mesma foi concluída e segue o fluxo disponibilizando a próxima tarefa ao respectivo ator responsável. Neste caso, a tarefa está sendo controlada pelo sistema (seu início e fechamento), portanto é modelada como uma tarefa de usuário.
Cenário 2: O Técnico não acessa o sistema. Ele pode, por exemplo, receber ao início do dia uma lista impressa com todos os clientes a visitar. A cada visita, o cliente assina o papel confirmando que o atendimento foi realizado. Ao fim do dia, quando o técnico retorna para a empresa, ele entrega a lista ao Atendente, que então verifica se o atendimento foi realizado e registra no sistema o resultado do atendimento. Neste caso, a tarefa do técnico é modelada como uma tarefa manual, para que fique visível aos que olham o modelo em que momento o mesmo realiza seu trabalho (e que, do ponto de vista do processo de negócio, existe uma dependência da tarefa de "Verificar resultado do serviço" em relação à "Realizar visita técnica", mas o sistema não controla o início nem o fim do trabalho realizado.
Assim, concluímos que, na modelagem com a notação BPMN, o tipo de tarefa não é definido pelo uso de sistemas para realizá-la, e sim se há alguma aplicação sendo utilizada para controlá-la.
(1) Processos podem ser controlados por aplicações de diferentes tipos. Isto já foi tema deste blog no artigo Gerenciando a execução de processos com (ou sem) um BPMS.
Aprenda a dominar a notação BPMN utilizando as melhores práticas com nossos instrutores, em um curso repleto de exercícios e um laboratório prático de modelagem de um processo de negócio de ponta a ponta!
Tags: BPMN, BPMN 2.0, BPMN avançado, BPMN task, Diagramas BPMN, dicas, erros comuns BPMN, mapeamento de processos, melhores práticas BPMN, modelagem de processos
Oracle SOA Suite – Build e Deploy multi-ambiente utilizando scripts ANT
Eduardo Barra Cordeiro - 25 de março de 2013
Depois de alguns anos de experiência utilizando o Oracle SOA Suite 11g em diferentes projetos, a iProcess elaborou uma solução para build e deploy dos projetos BPEL e BPM utilizando scripts ANT customizados que, em parte, são disponibilizados pela própria Oracle e, em partes, foram adaptados pela empresa. O post de hoje apresenta essa solução, além de disponibilizar um pacote de scripts de exemplo.
Antes, porém, vamos 'chover no molhado' e conceituar simplesmente build e deploy. Vimos, pela experiência de projeto, que nem sempre isso é claro para todos.
build: é o ato de 'empacotar' o projeto. Todo o projeto será incluído num único arquivo (basicamente um ZIP) que, posteriormente, será enviado para o servidor onde será feita a disponibilização.
deploy: é o ato de disponibilizar o projeto 'empacotado' no servidor. Para isso, obviamente, serão necessárias as informações do servidor de destino. Note que o nosso post irá tratar bastante desse assunto, já que existem possibilidades de deploy customizados para diferentes ambientes.
Ainda, antes de apresentarmos a solução, queremos responder à pergunta: por que criamos essa opção utilizando scripts ANT? Não seria mais simples continuar realizando o build + deploy via JDeveloper?
Vamos relacionar algumas justificativas:
deploy em vários ambientes: é comum em projetos de integração e automação de processos a necessidade de trabalharmos com diferentes ambientes (desenvolvimento, testes, homologação, produção). O projeto é o mesmo. O que mudam são os enpoints dos serviços e informações específicas de conexões, JCA's, etc. Nesses casos a utilização de arquivos de configuração que contenham as informações dos enpoints e dos outros dados personalizados por ambiente simplifica a vida da pessoa responsável por instalar o projeto nos vários destinos (homologação/produção), bastando selecionar o ambiente destino e realizar o deploy para ele.
faça o build uma vez e o deploy muitas vezes: promover o mesmo build para vários ambientes é algo extremamente valioso. Isso dá a garantia de que exatamente o mesmo projeto que foi testado no ambiente X será testado nos ambientes Y, Z… Caso contrário, se algo tiver que ser alterado no projeto depois de já tê-lo testado em algum ambiente (mesmo que essa informação seja o endpoint de algum serviço) sempre existirá a possibilidade de algo estar diferente (inclusive um novo defeito), colocando em risco todos os testes que já foram realizados até então.
Feito. Vamos ao que interessa. Abaixo está descrito o padrão utilizado pela iProcess para build/deploy dos projetos no SOA Suite. A descrição inclui o uso de projetos BPM e HumanTasks. Agradecemos ao Rafael Andrade pela grande contribuição na organização desse material.
A estrutura de diretórios abaixo tem como objetivo permitir que projetos SOA/BPM sejam preparados, desde o seu desenvolvimento, para serem migrados entre os diversos ambientes existentes (desenvolvimento, homologação, produção, etc) sem a necessidade de efetuar ajustes nos projetos durante o build/deploy em cada ambiente específico. Será mais simples ver a descrição desses tópicos com o projeto em mãos. Clique aqui para realizar o download.
|    |-- ear
|    |-- templates
|    |     |-- form_application
|    |     |     |-- application.xml
|    |     |     |-- build.xml
|    |     |     |-- build-wars.xml
|    |     |     |-- local_build.properties
|    |     |-- form_project
|    |     |     |-- build.xml
|    |     |-- soa_project
|    |     |     |-- build-customize.xml
|    |-- war
|    |-- .adf
|    |     |-- META-INF
|    |     |    |-- adf-config.xml.seed.local
|    |     |    |-- adf-config.xml.seed.server
|    |-- build_ENV.properties
|    |-- custom-build.xml
|    |-- custom-build-app.xml
|    |-- custom-build-app-common.xml
|    |-- custom-build-app-mod.xml
|    |-- custom-build-app-mod-common.xml
|    |-- custom-build-common.xml
|    |-- developer_build.properties
|    |-- global_build.properties
|    |-- forms
|    |      |-- <aplication 1>
|    |      |      |-- <project 1>
|    |      |      |-- <project 2>
|    |      |-- <aplication 2>
|    |      |      |-- <project 1>
|    |      |      |-- <project 2>
|    |-- soa
|    |      |-- <project 1>
|    |      |-- <project 2>
|    |-- mds
|    |    |-- apps
|    |    |    |-- <project name>
|    |    |    |      |-- fault-policies
|    |    |    |      |    |-- <fault policies files>
|    |    |    |      |-- xsd
|    |    |    |      |    |-- <directories and XSD files>
|    |-- build.xml
|    |-- local_build.properties
|    |-- shared.jpr
sca: diretório raiz dos projetos SOA/BPM. Este diretório e toda a sua estrutura interna deve ser criado no sistema de controle de versões do projeto.
bin: diretório onde estão localizados os scripts de build/deploy e os arquivos de configuração
ear: arquivos utilizados na geração do EAR que representa a aplicação Java contendo os módulos web com os formulários das human tasks do projeto. Tanto a estrutura de diretórios interna quanto os arquivos existentes nela são apenas utilizados na geração do EAR, não devendo ser alterados.
templates: diretório contendo os templates de arquivos que devem ser copiados para os projetos de acordo com a situação
form_application: arquivos que devem ser copiados para o diretório da aplicação Java que conterá os formulários das human tasks. Alguns arquivos devem ser customizados, conforme descrito abaixo.
application.xml: arquivo que descreve os módulos da aplicação Java. Deve ser copiado para a pasta raiz de cada aplicação Java, devendo ser customizado a medida que os projetos dos formulários forem sendo criados.
build.xml: arquivo que deve ser copiado para a pasta raiz de todas as aplicações Java. Este arquivo contém os imports e referencias para que seja possível fazer build e deploy de cada aplicação.
build-wars.xml: arquivo que deve ser copiado para a pasta raiz de todas as aplicações Java, devendo ser customizado a medida que os projetos dos formulários forem sendo criados para conter uma chamada para o build de cada um dos projetos que compõe a aplicação.
local_build.properties: arquivo de properties que deve ser copiado para a pasta raiz de todas as aplicações Java, devendo ser customizado para conter o nome da aplicação que deve ser criada. O nome informado neste arquivo deve ser o mesmo informado na tag display-name do arquivo application.xml.
form_project: arquivos que devem ser copiados para o diretório dos projetos de formulários das Human Tasks. Alguns arquivos devem ser customizados, conforme descrito abaixo.
build.xml: arquivo que deve ser copiado para a pasta raiz do projeto de formulário da Human Task. Este arquivo contém os imports e referencias para que seja possível fazer build e deploy de cada projeto de formulário.
local_build.properties: arquivo de properties que deve ser copiado para a pasta raiz do projeto de formulário da Human Task, devendo ser customizado para conter o nome do módulo web que deve ser criado.
soa_project: arquivos que devem ser copiados para o diretório dos projetos SOA/BPM. Alguns arquivos devem ser customizados, conforme descrito abaixo.
build.xml: arquivo que deve ser copiado para a pasta raiz de todos os projetos SOA/BPM. Este arquivo contém os imports e referencias para que seja possível fazer build e deploy de cada projeto
build-customize.xml: arquivo que deve ser copiado para a pasta raiz dos projetos SOA/BPM quando for necessário fazer algum tipo de customização (replace de TOKENS) no configuration plan do projeto. Nestes casos, o arquivo deve ser copiado e atualizado, sendo adicionadas as tags de replace necessárias. Por padrão, os tokens @managed.server.host, @managed.server.port e @partition.name são automaticamente substituidos pelos valores do hostname, porta e partition, respectivamente, buscando dados dos arquivos build_ENV.xml e global_build.properties. Deste modo, o arquivo build-customize.xml só precisa ser criado caso algum outro token adicional precise ser substituido. Por exemplo: nome de filas, caminhos de diretórios, endereço de serviços externos invocados, etc.
local_build.properties: arquivo de properties que deve ser copiado para a pasta raiz dos projetos SOA/BPM quando for necessário definir alguma property específica para este projeto. Normalmente este arquivo é necessário quando apenas o configuration plan deste projeto precisa ser customizado com alguma informação que ainda não exista nos demais arquivos de properties e que faça sentido apenas para este projeto.
war: arquivos utilizados na geração do WAR que representa cada um dos módulos web contendo os formulários das Human Tasks. Tanto a estrutura de diretórios interna quanto os arquivos existentes nela são apenas utilizados na geração do WAR de cada projeto, não devendo ser alterados.
.adf/META-INF: diretório que simula o diretório de uma aplicação SOA/BPM. Neste diretório estão os arquivos necessários para acessar o MDS. Os dois arquivos contidos nesse diretório são templates que o script de deploy utiliza como base (faz uma cópia) para criar o arquivo contendo as informações que efetivamente serão utilizadas para acessar o MDS durante o deploy.
adf-config.xml.seed.local: arquivo contendo o template de configurações necessárias para acessar o MDS local na máquina do desenvolvedor.
adf-config.xml.seed.server: arquivo contendo o template de configurações necessárias para acessar diretamente o MDS do servidor.
build_ENV.properties: arquivo de properties que contém as informações específicas de cada ambiente (desenvolvimento, homologação, produção, por exemplo). Deve ser criado um arquivo de properties por ambiente, sendo o nome ajustado de acordo (build_dev.properties, build_hom.properties, build_prod.properties, por exemplo). Os valores internos também devem ser ajustados para refletirem os valores de cada ambiente. Utilize o arquivo build_ENV.properties como template para construção dos arquivos específicos de cada ambiente.
custom-build.xml: script ANT que contém os targets que são expostos para os projetos SOA/BPM. É uma espécie de wrapper para o arquivo custom-build-common.xml, expondo apenas os targets adequados para build e deploy dos projetos.
custom-build-app.xml: script ANT que contém os targets que são expostos para as aplicações Java. É uma espécie de wrapper para o arquivo custom-build-app-common.xml, expondo apenas os targets adequados para build e deploy das aplicações.
custom-build-app-common.xml: script ANT que contém todos os targets necessários para build e deploy de aplicações Java.
custom-build-app-mod.xml: script ANT que contém os targets que são expostos para os projetos de formulários das Human Tasks. É uma espécie de wrapper para o arquivo custom-build-app-mod-common.xml, expondo apenas os targets adequados para build e deploy dos projetos.
custom-build-app-mod-common.xml: script ANT que contém todos os targets necessários para build e deploy dos projetos de formulários das Human Tasks.
custom-build-common.xml: script ANT que contém todos os targets necessários para build e deploy de projetos SOA/BPM.
developer_build.properties: arquivo que contém properties específicas do ambiente de desenvolvimento de cada desenvolvedor. Após baixar toda a árvore de diretórios do sistema de controle de versões, cada desenvolvedor deve customizar este arquivo de acordo com as suas opções de builde e deploy.
global_build.properties: arquivo que contém as properties globais do projeto. Neste arquivo estão armazenadas as propriedades que são comuns a todos os componentes do projeto e que não variam de acordo com o ambiente.
projects: este diretório irá conter todos os diretórios de projetos SOA/BPM criados, bem como as aplicações e projetos Java criado para os formulários das Human Tasks. Deverão ser armazenados nele os diretórios de projeto com toda a estrutura de pastas criada pelo jDeveloper. Apenas os diretórios de projetos devem ser armazenados, não devendo ser armazenado nele o diretório da aplicação. No caso da aplicação Java que conterá os formulários das atividades humanas, o diretório criado não é o diretório da Application criado pelo jDeveloper, mas apenas um diretório simples para organizar os projetos dos formulários, com so arquivos necessários para o seu build/deploy, de modo que o diretório da application criado pelo jDeveloper não deve ser armazenado.
forms: diretório que irá conter as aplicações e projetos Java dos formulários das Human Tasks.
<APLICACAO 1>: diretório de uma aplicação Java, com os arquivos de build e deploy copiados do template
<PROJETO 1>: diretório de um projeto de formulário de Human Task
<PROJETO 2>: diretório de um projeto de formulário de Human Task
<APLICACAO 2>: diretório de uma aplicação Java, com os arquivos de build e deploy copiados do template
soa: diretório que irá conter os projetos SOA/BPM.
<PROJETO 1>: diretório de um projeto SOA/BPM
<PROJETO 2>: diretório de um projeto SOA/BPM
shared: diretório que contém um projeto especial onde são armazenados os arquivos comuns (policies, wsdls e xsds) que serão importados para o MDS e compartilhados pelos diversos projetos.
mds/apps: diretório que representa a mesma estrutura interna do MDS onde devem ser armazenados os arquivos a serem compartilhados.
<NOME DO PROJETO/CLIENTE/AREA>: diretório com o nome do projeto/cliente/área, utilizado apenas para organizar os arquivos compartilhados. Em vez de apenas um diretório, pode ser uma árvore inteira de diretórios e arquivos. A estrutura interna desde diretório pode ser criada de acordo com as necessidades do projeto.
build.xml: script ANT que contém todos os targets necessários para build e deploy de arquivos compartilhados no MDS.
local_build.properties: arquivo de properties específico para customizar o build/deploy dos arquivos compartilhados no MDS.
shared.jpr: projeto jDeveloper criado para permitir que os desenvolvedores acessem os arquivos compartilhados de maneira fácil de dentro da ferramenta de desenvolvimento. Basta abrir o projeto dentro da aplicação criada no jDeveloper para ter acesso a estrutura de diretórios dos arquivos compartilhados.
Muito bem! E agora? Como fazemos pra usar tudo isso?
Para cada novo projeto SOA que for criado, um arquivo build.xml precisa ser copiado do diretório /sca/bin/template para o diretório raiz do projeto;
Se for necessário realizar algum tipo de customização do build/deploy, os arquivos build-customize.xml e local_build.properties também precisam ser copiados;
Os scripts ANT necessitam obrigatoriamente que o configPlan seja criado para cada projeto. Esse arquivo de config plan deverá ter o mesmo nome do composite mais o sufixo "_configPlan" e será utilizado como modelo/template para gerar as informações específicas dos configPlans por ambiente.
Para criar o config plan, no JDeveloper clique com o botão direito sobre o arquivo composite.xml e selecione a opção "Generate Config Plan". Aceite o nome padrão sugerido.
Substitua no arquivo de configPlan os dados que deverão ser personalizados para cada ambiente por tokens. Estes serão trocados durante o build/deploy pelas informações contidas nos arquivos de properties.
Os scripts ANT utilizam o build-customize.xml em conjunto com comandos de pesquisa/substituição para gerar o configPlan customizado para cada um ambiente. Se o seu projeto precisa de qualquer tipo específico de configuração por ambiente, copie esse arquivo do diretório /sca/bin/template para o diretório raiz do projeto. Em seguida, atualize-o com todas as informações de busca/substituição necessárias para o seu projeto.
Crei uma instrução de busca/substituição para cada token criado no configPlan.
Se você possui qualquer propriedade no seu projeto que precise ser personalizada por ambiente, copie o arquivo local_build.properties do diretório /sca/bin/template para o diretório raiz do projeto e inclua nele todas as propriedades personalizadas.
Uma vez que toda a estrutura de arquivos estiver criada e configurada, é possível rodar os scripts ANT diretamente dentro do JDeveloper. Veja um exemplo abaixo:
Resultado do build e Deploy
Para concluir, relacionamos abaixo alguns assuntos que não foram tratados nesse posts e que podem ser utilizados em projetos para aperfeiçoar o uso do build + deploy:
repositório de arquivos: o diretório sca e seus sub-diretórios podem ser gerenciados usando qualquer tipo de sistema de repositório de arquivos, como SVN, CVS, TFS, GIT, etc. Contudo, normalmente os arquivos da "SOA Application" não são salvos no repositório, já que cada desenvolver deverá criar uma "SOA Application" vazia e incluir na aplicação os projetos que desejar, que estarão disponíveis no repositório (pasta /sca/projects). Também, quando um novo projeto for criado no JDeveloper, é importante cuidar para que ele seja salvo na pasta do repositório (/sca/projects).
atualização dos configPlan: atenção com os arquivos de configPlan: eles deverão ser atualizados cada vez que o projeto for alterado e novos dados sensíveis forem incluídos (exemplos comuns de dados sensíveis são hostname, porta e nome da partição do servidor para onde será feito o deploy ou então as informações de hostname e porta dos serviços externos).
uso do DVM para controle dos endpoints: uma opção ao uso dos arquivos de properties é a utilização do DVM do próprio SOA Suite para armazenar os endpoints. Isso é totalmente possível e já foi utilizado em projetos desenvolvidos pela iProcess.
na minha máquina funciona: o uso de um produto como o Hudson, Maven, etc para centralizar as tarefas de build e deploy é totalmente recomendável. É possível criar tarefas específicas de build e outras de deploy. No caso do build, ele pode ser configurado, inclusive, para buscar as informações diretamente no repositório de dados (SVN, GIT, etc), aumentado a confiança no código desenvolvido e o controle sobre as versões que são implementadas nos vários ambientes. Vai evitar situações do tipo "na minha máquina funciona".
MDS: se esse assunto é novo para você, caro leitor, sugiro dar uma navegada no nosso blog, específicamente nesse artigo que trata desse assunto.
Esperamos ter contribuído para a melhoria dos seus processos de build e deploy no SOA Suite 11g.
Tags: bpel, BPM, dicas, integração de sistemas, Oracle BPEL, Oracle BPM, SOA
Encontre a turma de BPM e SOA na rede
Kelly Sganderla - 25 de fevereiro de 2013
Business Process Management (BPM) e Service Oriented Architecture (SOA) são temas de discussões em diversos canais de redes sociais.
Facilitamos a sua vida reunindo aqui links para algumas destas comunidades virtuais:
É o principal forum de BPM no Brasil, com mais de 1700 inscritos. Abrange desde tópicos altamente voltados à filosofia BPM aplicada aos negócios até questões relacionadas a tecnologia:
https://br.groups.yahoo.com/group/BPM-Forum
AN.br
Esse fórum é de Analistas de Negócios, mas eventualmente são levantadas questões relacionadas a BPM:
https://groups.google.com/group/an-br?pli=1&hl=pt
Grupos no Linkedin
BPM Forum: https://www.linkedin.com/groups/BPM-Forum-161666
BPM Group: https://www.linkedin.com/groups?gid=73876
BPMN: https://www.linkedin.com/groups/BPMN-111271
BPMN 2.0 and beyound: https://www.linkedin.com/groups?gid=115356
Business Process Management Professionals Group: https://www.linkedin.com/groups/Business-Process-Management-Professionals-Group-41075
Profissionais de BPM: https://www.linkedin.com/groups?gid=3659934
Profissionais de BPM: https://www.facebook.com/groups/profissionaisdebpm
Comunidade BPM: https://www.facebook.com/ComunidadeBPM
BPM (Pega, lombardi, filenet, WPS, OracleBPM): https://www.facebook.com/groups/142199002526862
FreeBPM
Fórum brasileiro sobre plataformas livres de BPM:
https://groups.google.com/group/freebpm?hl=pt
BPM: https://www.bpminstitute.org
SOA: https://www.soainstitute.org
E é claro, você pode acompanhar atualizações de conteúdo da iProcess através dos seguintes canais:
Youtube – Vídeos sobre BPM/SOA: https://www.youtube.com/iprocessbpm
Twitter – comunicados sobre atualizações e novidades: https://twitter.com/iprocessbpm
Facebook: https://www.facebook.com/iprocesseducation
https://www.linkedin.com/company/iprocess-solucoes-em-tecnologia e
https://www.linkedin.com/company/iprocess-education
Tags: BPM, dicas, SOA
Estudo de Caso: Automatizar o processo (ou não)? Eis a questão!
Kelly Sganderla - 4 de fevereiro de 2013
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.
Tags: automação de processos, benefícios da automação de processos, BPMN, BPMS, Business Process Management, Business Process Management System, dicas, modelagem de processos, plataformas de BPM, soluções de BPM