Você está na página 1de 41

Captulo

4
Gerenciamento de Processos de Negcio e Aplica-
bilidade na Sade e na Robtica

Lucinia Heloisa Thom

Resumo

O gerenciamento de processos de negcio (BPM) proporciona no apenas a reduo


de custos, tempo, erros e redundncia na execuo dos processos, mas tambm maior
controle sobre estes. Assim tem-se o incremento da qualidade dos processos, de seus
resultados e da organizao como um todo. A busca por maior padronizao e eficincia
na execuo dos processos tm aumentado o interesse das organizaes pela tecnologia
de workflow. BPM vm sendo utilizado em diversos domnios de aplicao, tais como o
domnio da sade, envolvendo processos que requerem sistemas de workflow com suporte
adaptao dinmica e o domnio da robtica e automao, onde os processos carecem
de maior padronizao. Neste captulo so apresentados conceitos fundamentas sobre
BPM e workflow. Em particular, introduzida a notao para modelagem de processos de
negcio (BPMN), alm dos principais padres de workflow existentes. O captulo inclui
ainda a discusso de tpicos sobre a aplicabilidade de BPM em processos da sade e
robtica.

Abstract

Business Process Management (BPM) allows not only the reduction of costs, time, er-
rors and process replication, but mainly it increases the control over process execution.
Therefore, both process execution and organization quality improves. Organizations have
showed an increasing interest by the workflow technology due to their need for more
standardization and efficiency in process execution. BPM has been applied in many ap-
plication domains such as the health domain presenting processes which require dynamic
adaptation and flexibility in their execution as well as the robotics and automation do-
mains including processes that need more standardization. This chapter presents basic
concepts on BPM and workflow. In particular, it introduces the business process mod-
elling notation (BPMN) and core existent workflow patterns. Finally, the chapter dis-
cusses specific topics regarding the use of BPM in the health and robotics domain.
1.1. Introduo
Para manterem-se competitivas em meio as frequentes variaes de mercado, para mel-
hor interagir com clientes e parceiros de negcio e para garantir qualidade aos servios
oferecidos as organizaes privadas e pblicas buscam maior padronizao e eficincia na
execuo de seus processos de negcio. O gerenciamento de processos de negcio (Busi-
ness Process Management - BPM), atravs da automatizao dos processos de negcio
executados na organizao, proporciona no apenas a reduo de custos, tempo, erros e
redundncia na execuo dos processos, mas tambm maior controle sobre estes e ca-
pacidade de adequao a situaes inesperadas, o que leva ao incremento da qualidade
dos processos, de seus resultados e da organizao como um todo.
Sistemas de workflow tem sua origem na automao de escritrios. As primeiras
iniciativas surgiram no MIT (Massachusetts Institute of Technology), na Universidade
de Pensilvnia, por volta de 1968. O objetivo era reduzir a complexidade da interface
com usurio, controlar o fluxo de informao e melhorar a eficincia dos escritrios. Em
1976 surge o primeiro prottipo para automao de escritrios desenvolvido por William
Newman, Tim Mott e outros do grupo de pesquisa da Xerox Palo Alto Research Center
(PARC). A ferramenta apresenta suporte para criao e gerncia de documentos (GED)
com nfase na interface homem-mquina. O usurio pode, visualmente, manipular for-
mulrios, ler emails ou documentos. J em 1977, Michael Zismans prope o SCOOP
(System for Computerization of Office Processing) [Ellis and Nutt 1980]. A partir do
SCOOP um escritrio visto como um sistema e no como um conjunto de tarefas iso-
ladas. Aps, outras ferramentas surgiram, tais como a ICN (Information Control Net),
Lotus Notes, Oracle Workflow e, em 1993 surge a Workflow Management Coalition,
rgo padronizador da tecnologia de workflow [Fischer 2001]. Mais recentemente surgiu
a Notao para Modelagem de Processos (BPMN). Mais de 60 ferramentas de workflow
suportam a BPMN, visto que um padro aberto mantido pela OMG [OMG 2009].
Um sistema de workflow oferece solues para incrementar a qualidade e eficin-
cia do gerenciamento dos processos de negcio executados nas organizaes. A tecnolo-
gia de workflow um instrumento tecnolgico decisivo para a Gesto da Informao,
na medida em que registra ativamente e em detalhes todas as informaes referentes ao
funcionamento e a estrutura dos processos de negcio [Zhao 1998].
O desenvolvimento de um sistema de workflow passa pelas etapas de projeto,
modelagem, execuo e monitoramento [Weber et al. 2008]. Neste contexto, um dos
problemas que pode surgir durante a anlise de requisitos so eventuais resistncias cul-
turais, por parte dos usurios do sistema. As resistncias ocorrem, principalmente, devido
s alteraes que o workflow provoca na maneira como o trabalho deve ser realizado na
organizao. Alm disso, eventuais conflitos de linguagem entre os projetistas de work-
flow e usurios, podem gerar erros na fase de modelagem do processo, comprometendo a
fidelidade do processo de workflow modelado ao processo de trabalho, de fato, executado
na organizao. Em [Thom 2000] proposta uma metodologia para auxiliar na identifi-
cao e tratamento de resistncia humana durante o projeto de workflow. Mais recente-
mente Thom prope uma metodologia para a criao de ontologias apartir de modelos de
processo [Thom 2012].
O gerenciamento de processos de negcio e workflow vm sendo aplicados em
diversos domnios de aplicao: na automao de escritrios, onde os processos so mais
estticos e com poucas variaes; na sade que inclui processos dinmicos e que portanto
precisam de solues flexveis e adaptveis; na robtica, onde os processos requerem
padronizao e documentao que facilite seu reuso e entendimento compartilhado. Mas,
ainda que em domnios diferentes, as solues de workflow compartilham objetivos co-
muns tais como: maior padronizao dos processos, melhoria na execuo, qualidade e
rapidez na execuo das atividades.
As demais sees deste artigo esto organizadas como segue: Na Seo 2 so ap-
resentados diversos conceitos sobre gerenciamento de processos de negcio e workflow.
Na Seo 3 so discutidos tpicos relacionados a modelagem de processos de negcio.
A seo apresenta o ciclo de vida de um projeto de workflow e detalha as fases de elic-
itao de requistos e modelagem. Na Seo 4 introduzida a principal Notao para
Modelagem de Processos (BPMN). Nesta seo so apresentados os principais elementos
de modelagem, alm de exemplos de modelos de processos em BPMN. A Seo 5 apre-
senta os principais padres de workflow, tais como padres de controle de fluxo, dados,
alm de padres de atividade de workflow. Na Seo 6 so feitas consideraes sobre o
gerenciamento de processo da sade e robtica. Por fim, a Seo 7 conclui o artigo com
consideraes finais.

1.2. Fundamentos em Gerenciamento de Processos de Negcio e Workflow


Um processo de negcio consiste de uma srie de atividades relacionadas, as quais so
realizadas para atingir um determinado objetivo de negcio [Weske 2007]. Tais objetivos
incluem melhor documentao e padronizao do processo de trabalho, alm de eficincia
e qualidade na execuo dos processos. Um modelo de processo a representacao grfica
de um processo de negcio. A Figura 1.1 apresenta um exemplo simplificado de um
processo para conectar uma mo mecnica a um brao robtico. Observe que foi utilizada
uma notao especfica para o desenho deste processo. O processo inicia verificando se
j existe alguma mo mecnica conectada. Se existir, a mo deve ser desconectada. Se a
tarefa estiver concluda o processo finalizado, caso contrrio uma nova mo mecnica
escolhida e, aps conectada ao brao robtico.
Workflow a automatizao de processos de negcio, durante a qual, documentos,
informaes e/ou atividades so passadas de um participante a outro, a fim de que sejam
tomadas aes, de acordo com um conjunto de regras e procedimentos.
Os principais conceitos inerentes a BPM e workflow so: atividade e subprocesso,
controle de fluxo, participante e papel, instncia de atividade e de processo, item e lista
de trabalho [Fischer 2001], [Specification 1999]. Um sistema de gerncia de workflow
(WFMS) permite, a seus usurios, a definio, criao e gerncia da execuo de pro-
cessos de workflow. capaz de interpretar a definio do processo de negcio, interagir
com os participantes e, quando necessrio, invocar ferramentas e aplicaes de sistemas
de informao. O WFMS responsvel por controlar o andamento do processo, seguindo
rigorosamente a ordem definida pelas dependncias entre as atividades, respeitando as
regras de consistncia especificadas.
Figure 1.1. Processo para conectar uma mo mecnica a um brao robtico

1.2.1. Atividade e Subprocesso


Uma atividade ou tarefa um fragmento de trabalho que contribui para o cumprimento de
um processo. No processo ilustrado na Figura 1.1, cada retngulo indica uma tarefa (ex.:
Mo mecnica est conectada?). Uma tarefa pode ser manual ou automatizada. Tarefas
manuais no podem ter sua execuo controlada pelo sistema de gerncia de workflow
(ex.: uma exame mdico sendo realizado pelo mdico em um paciente ou a reviso de
um artigo realizada por um pesquisador). J as tarefas automatizadas tm sua execuo
controlada pelo sistema de gerncia de workflow. Todas as tarefas no processo da Figura
1.1 so automatizadas, ou seja, ou so executadas por um rob ou pelo prprio sistema de
workflow.
Um modelo de processo, alm de tarefas pode incluir subprocessos (que podem
ser entendidos como um tipo de atividade complexa). Sub-processos permitem a mode-
lagem hierrquica do processo. Um subprocesso uma atividade composta que pode ser
incluida dentro de um processo. No Processo (Pai), o subprocesso visto como um nico
elemento de modelagem que tem um nome identificador. O subprocesso detalhado em
um diagrama parte (Filho) e pode conter subprocessos e atividades. Neste contexto,
quando o subprocesso embutido ele no pode ser reusado, ou seja, s existe dentro do
processo pai. A Figura 1.2 apresenta um processo para posicionar um kit de montagem
em uma mesa de trabalho. O process ilustrado na Figura 1.1 um subprocesso deste pro-
cesso de posicionamento, ou seja, inicialmente uma mo mecnica deve ser conectada a
um brao robotico para que as tarefas (isto , tarefas pegar kit e posicionar kit na mesa de
trabalho) de posicionamento possam ser executadas.

Figure 1.2. Processo para posicionar um kit de montagem em uma mesa de


trabalho, incluindo um suprocesso de conexo de uma mo mecnica a um brao
robotico
1.2.2. Controle de Fluxo
Controles de fluxo definem a ordem de execuo das atividades. Conforme Crownston
[Crowston 2000], quanto maior o grau de dependncia entre atividades e recursos, mais
complexos so os mecanismos necessrios para controlar tais dependncias. Atualmente,
existem certa de 43 padres de controle de fluxo propostos em [van der Aalst et al. 2003].
Porm, os principais controles de fluxo, implementados por ferramentas de modelagem e
implementao de processos so: sequencial, AND-Split, AND-Join, OR-Split, OR-Join e
XOR-Split e XOR-Join [Specification 1999].

Sequencial: aps a execuo da atividade (tarefa) predecessora, a prxima ativi-


dade no processo pode ser executada. A Figura 1.3 ilustra um controle de fluxo
sequencial. Aps a execuo da atividade A, a atividade B inicia a execuo se-
quencialmente.

Figure 1.3. Controle de fluxo sequencial

AND-Split: Em um ponto de ramificao, todos os fluxos de sada so ativados


simultaneamente. A Figura 1.4 ilustra o controle de fluxo AND-Split. Aps a
execuo da atividade A, as atividades B e C so ativadas para execuo.

Figure 1.4. Controle de fluxo AND-Split

AND-Join: Em um ponto de convergncia de fluxos, esperado que todos os cam-


inhos de entrada completem, antes de disparar o fluxo de sada. A Figura 1.5 ilustra
o controle de fluxo AND-Join. Aps as atividades B e C concluirem a execuo, a
atividade D ativada para execuo. Observe que mesmo concluindo em tempos
diferentes, existe o sincronismo antes da atividade D para garantir sua execuo,
apenas a concluso das atividades predecessoras.
OR-Split: um ponto de ramificao, aps avaliar condies, um ou mais cam-
inhos so ativados. A Figura 1.6 ilustra o controle de fluxo OR-Split. Aps a
execuo da atividade A, so avaliadas as condies vinculadas a cada brao que
conecta a atividade A as atividades B e C, respectivamente. Aquelas braos cujas
condies forem validadas para verdadeiro, tero as respectivas atividades ativadas
para execuo.
Figure 1.5. Controle de fluxo AND-Join

Figure 1.6. Controle de fluxo OR-Split

OR-Join: Em um ponto de convergncia de fluxos, se espera que todos os fluxos de


entrada ativos tenham completado para ativar o fluxo de sada. A Figura 1.7 ilustra o
controle de fluxo OR-Join.A atividade D s ser ativada quando todas as atividades
predecessoras, cujas condies forem validadas para verdadeiro estiverem com a
execuo concluda.

Figure 1.7. Controle de fluxo OR-Join

XOR-Split: Em um ponto de ramificao, selecionado exatamente um caminho


de sada dentre as alternativas existentes. A Figura 1.8 ilustra o controle de fluxo
XOR-Split. Aps a execuo da atividade A, ou a atividade B ou a atividade C ser
atividada para execuo, mas no ambas as atividades.

XOR-Join: Em um ponto de convergncia, basta a execuo completa de um brao


de entrada para que seja ativado o fluxo de sada. A Figura 1.9 ilustra o controle de
fluxo XOR-Join. A atividade D atividada para execuo quando a atividade B ou
C conclurem a execuo.
Figure 1.8. Controle de fluxo XOR-Split

Figure 1.9. Controle de fluxo XOR-Join

1.2.3. Participante e Papel


Participante, ator ou agente o responsvel pela execuo de uma ou mais atividades
pertencentes ao processo. Pode ser um ser humano, tal como um funcionrio da empresa
ou um software (microsoft outlook) ou, ainda, um equipamento (ex.: torno com controle
numrico).
Papel uma abstrao criada em torno de um conjunto de atores, os quais compar-
tilham caractersticas semelhantes, a fim de se evitar que, nomes de usurios faam parte,
explicitamente, do modelo de workflow. Por exemplo, no processo de desenvolvimento
de software os responsveis pela anlise de requisitos assumem o papel de analista e, os
responsveis pela codificao assuem o papel de programador. Um ator pode assumir
mais de um papel. Por exemplo, se determinado ator responsvel pela anlise de requi-
sitos e, tambm, pela codificao, o mesmo assume os papis de analista e programador,
respectivamente.
A Figura 1.10 traz o processo ilustrado na Figura 1.1 com os respectivos papis e
participantes associados as atividades.

1.2.4. Instncia de Atividade e Instncia de Processo


Quando um processo iniciado, o WFMS cria uma instncia de processo. Cada instncia
de processo gera uma srie de instncias de atividades. No exemplo da Figura 1.1, sem-
pre que o processo for iniciado gerada uma instncia do processo de conexo da mo
mecnica ao brao robtico. No necessariamente todas as atividades incluidas em um
processo sero instanciadas. Controles de fluxo do tipo OR e XOR podem implicar na
execuo de uma ou outra atividade, dependendo do contexto de execuo do processo.
Figure 1.10. Processo para conectar uma mo mecnica a um brao robtico a
respectivos papis e participantes associados as atividades

No processo ilustrado na Figura 1.1, se a atividade Mo mecnica est conectada resultar


em No, apenas as atividades Escolher mo mecnica e Conectar mo mecnica a brao
mecnico sero instanciadas.

1.2.5. Item de Trabalho e Lista de Trabalho


Para o participante do sistema de workflow, as atividades so apresentadas como uma
coleo de itens de trabalho. Cada item de trabalho o resultado da instanciao de uma
atividade. O mesmo contm uma descrio textual da atividade, alm dos documentos e
aplicaes associadas. importante observar que apenas atividades manuais geram itens
de trabalho para a lista de trabalho de um participante humano do processo.

1.3. Modelagem de Processos de Negcio


O processo de desenvolvimento de sistemas de workflow inclui quatro etapas principais:
projeto e elicitao de requisitos, modelagem, execuo e monitoramento. As etapas de
elicitao de requisitos e modelagem so consideradas fundamentais e crticas, pois so
nestas fases que os processos executados na organizao so identificados e modelados
pelo projetista. Na fase de elicitao, o analista deve entender bem o domnio de aplicao
para facilitar a identificao dos requisitos para a modelagem dos processos. Na maioria
dos casos, so identificados indivduos-chave na organizao (ex., especialistas, diretoria)
os quais so entrevistados pelo analista, alm do estudo, pelo analista, de documentos or-
ganizacionais, alm da literatura relacionada ao domnio de aplicao. A identificao dos
requisitos e posterior modelagem dos processos uma tarefa complexa devido a diversos
fatores: problemas de comunicao entre o analista e os usurios, falta de documentao
e padronizao dos processos, boicote por parte dos usurios que muitas vezes resistem
em descrever suas tarefas dirias temendo a perde de controle da execuo destas ou a
identificao de uma carga de trabalho reduzida.

1.3.1. Arquitetura Orientada a Servios


Na Arquitetura Orientada a Servios (SOA), servios so programas de software, fisica-
mente independentes, que do suporte obteno de objetivos estratgicos. Cada Servio
possui um conjunto de capacidades, as quais so expressas atravs de um contrato de
servio (tal como uma API). Uma composio de servios consiste em um agregado de
servios [Thomas 2009].
Um servio encapsula uma funo de negcio reutilizvel. Cada servio in-
stanciado de um nico repositrio e invocado remotamente por todas as aplicaes que o
usam. No existe herana ou dependncias fortes entre servios. Cada servio criado
(build) uma vez, mas pode ser instanciado (deployed) para todos os sistemas que dele
necessitem.
A orientao a servios proporciona vantagens importantes tais como: reutiliza-
o de software, um pacote de cdigos que constitui um servio pode ser reutilizado em
um novo aplicativo; aumento de produtividade, a reutilizao de servios pode agilizar o
desenvolvimento dos projetos, possibilitando que uma mesma equipe de projeto trabalhe
em mais de uma projeto paralelamente. A arquitetura orientada a servios tambm ap-
resenta vantagens que incluem: melhor alinhamento com o negcio da organizao, a
arquitetura considerada o panorama geral de todos os processos de negcio da organiza-
o, ou seja, o pessoal de negcio pode visualizar como a empresa construda em termos
de tecnologia; uma maneira melhor de vender arquitetura para o negcio, reutilizao,
maior produtividade e agilidade em TI e uma infra-estrutura de software ajustada para
processos de negcio aumentam o interesse das organizaes por SOA. Porm, impor-
tante observar que organizaes pequenas ou extremamente descentralizadas talvez no
consigam justificar uma equipe centralizada de gerentes de projeto, arquitetos e desen-
volvedores.
A Figura 1.11 apresenta um esquema simplificado de SOA. Inicialmente os aplica-
tivos de cada departamento da organizao so identificados. Aps, so verificadas partes
de cdigo ou mdulos de funes comuns a todos os aplicativos. Apartir disso, feita
uma generalizao para se obter solues de software de uso comum a todos os departa-
mentos. As principais vantagens deste procedimento so a reutilizao de cdigo fonte,
integrao com sistemas de informao e identificao de cdigo que pode ser simplifi-
cado e/ou eliminado 2 .

1.3.2. Ciclo de Vida de um Projeto de Desenvolvimento de Workflow


Um ciclo de vida tpico de processo de desenvolvimento de sistema de workflow inclui
as seguintes fases [Weber et al. 2009]: projeto, modelagem, execuo e monitoramento
(veja Fig. 1.12).

Projeto e Elicitao de Requitos. A descrio de um processo de negcio, em


alto nvel de abstraao, primeiramente uma tarefa de gerenciamento guiada por
objetivos de negcio. A traduo desta descrico para um modelo de processo
concreto, i.e., executvel um pr-requisito fundamental para o sucesso de qualquer
sistema de workflow.
Modelagem. Nesta fase, geralmente a descrio do processo obtida na fase de
projeto traduzida para um modelo de processo em notao especfica, tal como
BPMN ou diagrama de atividades da UML ou ainda diretamente para uma lin-
guagem de execuo, tal como a Business Process Execution Languagem (BPEL).
2 Fonte: ilustrao adaptada de http://www.youtube.com/watch?v=f9lOMGvTUVo
Figure 1.11. SOA e aplicativos existentes na organizao

Execuo. Flexibilidade na execuo de modelos de processos fundamental para


a realizao de processos dinmicos. Alm da execuo do modelo de processo,
esta fase inclui o tratamento de excees, assim como possveis alteraes no pro-
cesso.

Monitoramento. Atravs do monitoramento, deadlocks, livelocks, assim como


melhorias no processo podem ser identificadas.

As fases de modelagem e melhoria de processos tm recebido uma ateno espe-


cial das comunicades acadmicas e profissionais. Nos ltimos anos diversos metamod-
elos, notaes e linguagens foram propostas para auxiliar a etapa de modelagem. Com
relao a melhoria de processos, cada vez mais as organizaes esto enfrentando presso
para melhorar o desempenho dos seus processos em termos de custo, tempo, qualidade
e flexibilidade. Conforme [Vanwersch 2011] o redesenho de processos de negcios po-
dem contribuir significativamente para este objetivo. Porm, os projetos de redesenho
de processos so caracterizados por alto risco de falha, visto que existe uma carncia
de metodologias eficientes para reengenharia. Em vista disso, em [Vanwersch 2011]
proposto um mtodo que auxilia profissionais da sade na modelagem de novas alterna-
tivas de processos que possma colaborar para a melhoria do processo atual. A pesquisa
proposta tambm objetiva identificar fatores crticos de um processo de redesenho, ini-
cialmente no domnio da sade. Neste contexto, em [Reijers and Limanmansar 2005]
apresentado um framework para redesenho de processos de negcio para descrever os
elementos que podem ser candidatos ao redesenho. Estes elementos incluem: clientes,
produtos, processos de negcio (com foco na viso operacional e comportamental), orga-
nizao (com foco na populao e estrutura), informao, tecnologia e ambiente externo.
Em [Gassen 2012] apresenta uma abordagem, cujo principal objetivo auxil-
iar e melhor a qualidade a modelagem de processos utilizando ontologias. A idia
definir nomes para os elementos de processo (ex. atividades) tendo como base termos que
aparecem na ontologia. Alm disso, utilizar a ontologia na identificao de restries nos
Figure 1.12. Ciclo de vida do desenvolvimento de sistemas de workflow

relacionamentos entre os termos (por exemplo, verificar se determinado participante est


apto ou atuorizado a executar uma tarefa especfica).

1.3.3. Elicitao de Requisitos e Modelagem de Processos de Negcio


Conforme [Knight 2005] um dos grandes desafios da elicitao de requisitos garantir
que os requisitos de sistema estejam alinhados com as necessidades de negcio da orga-
nizao. Os autores enfatizam que requisitos representando apenas a perspectiva de um
usurio individual do sistema, parcialmente analisados e que no consideram o ambiente
em que esto inseridos podem colaborar para sistemas que no refletem as necessidades
da organizao.
Na fase de elicitao e anlise de requisitos, os engenheiros de software trabal-
ham com os clientes e os usurios finais do sistema para aprender sobre o domnio de
aplicao, quais os servios o sistema deve fornecer, o desempenho esperado do sistema,
ssim como, restries de hardware [Sommerville 2003]. No desenvolvimento de sistemas
de workflow, a elicitao e o entendimento dos requisitos dos usurios finais so par-
ticularmente difceis por vrias razes [Thom 2000]: diversificao na forma de realizar
o trabalho e falta de documentao, dificuldade pelo analista de entender o domnio de
aplicao e assim focar nas questes mais relevantes necessrias para a modelagem dos
processos e boicote dos usurios que podem resistir no repasse de informaes temendo
o controle que o sistema de workflow enfora execuo do trabalho.
As fontes de informao para o desenvolvimento de qualquer software, durante
a fase de requisitos, incluem documentao, usurios de sistema e especificaes de sis-
temas similares. Para o sistemas de worflow, existem outras fontes de informao, tais
como ISOs, ontologias, procedimentos disponibilizados na iliteratura e web que tambm
podem contribuir para a elicitao dos requisitos. Em [Thom et al. 2006a] apresen-
tada uma abordagem interessante relacionando aspectos da estrutura organizacional (ex.
centralizao na tomada de deciso em chefias e diretorias) e funes especficas dos
processos de negcio (hierarquia de aprovaes).
Em [Knight 2005] apresentada uma aboradagem bastante interessante, na qual
um conjunto de modelos so utilizados para a identificao de requisitos de negcio. Tais
modelos incluem modelo organizacional, modelo de localizao, modelo de objetivos,
modelo de processo e modelo de atividade.
O modelo organizacional apresenta unidades organizacional (ex.: departamento
de tecnologia de informao), papis (ex.: programador) e seus relacionamentos, ou seja,
qual ator pertece a qual unidade organizacional. J o modelo de localizao ilustra a
maneira como a organizao est distribuda, as relaes entre as unidades organiza-
cionais e sua localizao geogrfica. O modelo de objetivos, por sua vez, apresenta os
objetivos de negcio da organizao e as relaes hierrquicas entre estes. Demonstra
como um objetivo dividido em subobjetivos, os quais podem ser atingidos atravs da
execuo dos processos de negcio. O modelo de processo representa todos os modelos
de processo e sua estrutura hierrquica. Representa, ainda, as atividades e respectivas
ordens parciais de atividades que compem os processos. Por fim, o modelo de atividade
representa as atividades do processo e relacionamentos com os respectivos participantes
do processo, responsveis pela execuo das atividades. Tambm apresenta quais even-
tos so disparados ou disparam determinada(s) atividade(s). A adordagem utiliza estes
modelos como fonte de informao para a anlise de requisitos, principalmente para a
modelagem dos processos executados em uma organizao.
Em [Thom 2000] apresentada uma tcnica para suporte ao projeto de workflow,
a partir do conhecimento de aspectos das estruturas organizacionais, e um primeiro con-
junto de regras de mapeamento entre aspectos especficos de uma organizao e seus
modelos de processo. Alm disso, os resultados do trabalho induzem percepo de que
possvel utilizar projetos de workflow como documentao complementar ao estudo da
prpria estrutura de uma organizao.

1.4. Introduo Notao para Modelagem de Processos de Negcio


A notao para modelagem de processos (BPMN) foi desenvolvida sob a coordenao do
Objetct Management Group (OMG). O principal objetivo da BPMN prover uma notao
fcil de ser entendia por todos os usurios de negcio, incluindo analistas que capturam
as primeiras definies do processo (i.e., na fase de projeto), desenvolvedores tcnicos re-
sponsveis pela implementao do PAIS que ir executar o processo e, finalmente aqueles
que iro gerenciar e monitorar o processo [Weske 2007]. Atualmente, diversas ferramen-
tas para modelagem de processos esto sendo desenvolvidas com base na BPMN (ex.:
Intalio, Oryx Editor, IDS-Scheer Aris). Outro objetivo da BPMN assegurar que lingua-
gens XML desenvolvidas para a execuo de processos de negcio, tais como a BPEL
possam ser visualizadas com uma notao orientada a processos (veja, [OMG 2009]).
A BPMN uma Notao baseada em diagrama de fluxo para definio de processo
que inclui um mecanismo para a gerao de um processo executvel (BPEL) a partir de
um diagrama de processo. A verso atual da BPMN est traduzida para pelo menos 10
idiomas, o que colabora para a disseminao e adoo da notao. A BPMN apresenta
um conjunto mnimo de elementos de modelagem que inclui quatro categorias principais:
ojetos de fluxo, objetos de conexo, raias e artefatos.

1.4.1. Objetos de Fluxo


Objetos de fluxo incluem atividades, eventos e gateways (roteamentos). Uma atividade
um trabalho realizado dentro do processo de negcio. Uma atividade na BPMN pode
ser de execuo atmica (tarefa) ou no-atmica (subprocesso) (veja Figura 1.13). Uma
atividade de qualquer tipo pode ser executada uma nica vez ou executar mltiplas vezes
em um lao definido internamente. Uma atividade do tipo tarefa pode ser especializada
de vrias formas e marcas ou cones podem ser adicionados tarefa. Um subprocesso
uma atividade composta que pode ser includo dentro de um processo, possibilitando a
modelagem hierrquica do processo. A Figura 1.14 apresenta os tipos de subprocessos
suportados pela BPMN. Suprocesso de loop indica que o suprocesso repetido em look.
J o subprocesso multiplas-instncias indica que sero criadas mltiplas instncias de um
mesmo subprocesso. Um subprocesso ad-hoc significa que um subprocesso no segue
uma ordem formal. Por fim, um subprocesso de compensao realiza aes de compen-
sao, por exemplo, quando necessrio desfazer ou anular um conjunto de aes em
resposta a uma situao de erro.

Figure 1.13. Atividade simples, loop, subprocesso e multiplas-instncias

Figure 1.14. Tipos de subprocesso na BPMN

Um evento algo que ocorre durante a execuo de um processo do negcio.


Eventos afetam o fluxo do processo e tm geralmente uma causa (trigger) ou um impacto
(result). A Figura 1.15 apresenta um resumo dos principais tipos de eventos e respectivo
propsito do evento, ou seja, iniciar, interromper ou concluir um processo. Um evento de
incio marca o incio do processo. Eventos intermdios ocorrem no decorrer do processo
e um evento de fim marca a concluso do processo.
Gateways so utilizados para controlar as divergncias e convergncias no fluxo.
A Figura 1.16 resume a semntica dos principais gateways ou desvios suportados pela
BPMN. Dentre estes os principais so Sequncia, AND-Split e AND-Join, OR-Split e
OR-Join, SOR-Split e XOR-Join os quais j foram introduzidos na seo 2.2.

Figure 1.15. Tipos de Eventos na BPMN (Fonte: BPMN notation)

1.4.2. Objetos de Conexo


Objetos de conexo incluem fluxo de sequncia, fluxo de mensagem e conexo de associ-
ao. Fluxo de sequncia define a ordem de execuo das tarefas. Fluxo de mensagem
simboliza fluxos de informao que transpem fronteiras internas e externas de uma or-
ganizao. So utilizados para trocas de mensagens entre pools diferentes, ou seja entre
participantes do processo. Podem ser conectados a Pools, atividades ou eventos de men-
sagem. Conexo de associao usada para associar dados, texto, e outros artefatos com
os objetos de fluxo. As associaes so usadas para mostrar as entradas e as sadas das
atividades.
Na Figura 1.17 tem-se fluxos de sequncia entre diversas atividades (ex.: a ativi-
dade escolher mo-mecnica est conectada a conectar mo-mecnica a brao robtico
atravs de um fluxo de sequncia.
Figure 1.16. Tipos de Desvios na BPMN (Fonte: BPMN notation)

1.4.3. Raias
Raias esto divididas entre pools (piscina) e lanes (faixa). As pools so usadas para
representar diferentes entidades num processo (ex.: diferentes organizaes). As lanes
so usadas para particionar uma pool e permitem representar diferentes departamentos
numa organizao. A figura 1.17 apresenta um exemplo de processo em BPMN para
conectar uma mo mecnica a um brao robtico. Veja que neste processo utilizada
apenas uma pool, visto que todas as atividades do processo so executadas por um nico
rob chamado conector.
A Figura 1.18 traz um processo de negcio para emisso de uma ordem de com-
pra. O processo inclui trs pools que representam os participantes cliente, vendas e en-
tregador. O processo inclui dois subprocessos (Processar pedido e Fazer entrega), alm
de fluxos de sequncia (ex: Fazer pedido Enviarpedido)e f luxosdemensagem(ex. :
Enviarordemdeentrega Receberordemdeentrega).

1.4.4. Artefatos
Artefatos podem ser objetos de Dados, Repositrio de Dados, Grupo e Anotao (veja
Figura 1.19). Um Objeto de Dados representa informao que transita ao longo do pro-
cesso, tal como documentos, correio eletrnico ou cartas. Repositrio de Dados o local
onde o processo pode ler e escrever dados como, por exemplo, uma base de dados ou um
Figure 1.17. Processo para conectar uma mo mecnica a um brao robtico
modelado em BPMN

sistema de arquivos. O repositrio de dados persiste, alm do tempo de vida da instncia


de processo que o acessa. Grupo utilizado para organizar elementos de um processo e
no afeta a execuo do processo. Anotaes so mecanismos para fornecer informaes
adicionais para o leitor de um diagrama de processo.

1.5. Padres de Workflow para Modelagem de Processos de Negcio


A definio e execuo de processos de negcio pode envolver diversas perspectivas de
processos tais como contole de fluxo, dados, recursos, atividades, tratamento de excees,
conformidade, interao de servios e alterao de processos. Recentemente, diversas
abordagens tm sido propostas relacionando estas perspectivas a padres de workflow.
Neste captulo, um padro de workflow definido como uma estrutura recor-
rente de processo relacionada a alguma perspectiva de negcio (veja Figura 1.20). Ex-
emplos de padres de workflow incluem: controle de fluxo [Russell et al. 2006b], da-
dos [Russell et al. 2005a], recursos [Russell et al. 2005b], exceo [Russell et al. 2006c],
alterao de processos [Weber et al. 2008], interao de servios [Barros et al. 2005a],
padres SOA [Comite 2006], atividades [Thom et al. 2009a]. Nesta seo estes padres
so revisados.

1.5.1. Padres de Controle de Fluxo


Os padres de controle de fluxo tm sido os mais utilizados no apenas por terem sido
os primeiros a serem propostos, mas principalmente porque a maioria das ferramentas de
modelagem e execuo de processos implementa padres bsicos de controle de fluxo, tais
como sequncia, AND-Split, AND-JOIN, OR-Split, OR-Join e XOR-Split e XOR-Join.
A ferramenta Yet Another Workflow Language uma das nicas ferramentas que inclui a
maioria dos padres de controle de fluxo [Russell and ter Hofstede 2009]. A linguagem
suportada por um sistema de software que inclui um motor de execuo, um editor grfico
e um gestor de lista de tarefas. O sistema est disponvel em cdigo aberto com a licena
LGPL.
Figure 1.18. Processo para uma ordem de compra modeldo em BPMN (Fonte:
processo adaptado de [Santos 2010])

1.5.2. Padres de Dados


Padres de dados capturam maneiras para representar e utilizar dados em workflow. Es-
to classifificados em padres de visibilidade que representam como dados podem ser
definidos e utilizados; padres de interao para representar as formas em que os dados
podem ser passados de um componente de processo para outro; padres para transfern-
cia de dados que capturam aspectos mais detalhados, tais como acesso exclusivo ao dado
do componente que o est recebendo; e padres para roteamentos baseados em dados.
A Figura 1.21 apresenta exemplos de padres de visibilidade de dados; padro de
roteamento, onde na atividade A definido um parmetro de sada R, o qual utilizado
na execuo da atividade B, ou seja, R pr-condio para a atividade B; e padro de
interao, onde dados so definidos em uma tarefa A e passados como parmetro para
serem utilizados em outras atividades B e C, respectivamente.

1.5.3. Padres de Recurso


Recurso uma entidade capaz de executar um trabalho (item de trabalho). Um recurso
pode ser um humano ou uma mquina/software. Padres de recurso incluem padres
de criao, padres push, padres pull, padres deteour, padres de auto-inicializao,
Figure 1.19. Tipos de Artefatos

Figure 1.20. Tipos de Padres de Workflow

padres de visibilidade, padres de recursos mltiplos.


A Figura 1.22 apresenta um exemplo de padro de recurso com o propsito de
associar participantes (papis) a execuo das atividades ou tarefas.

1.5.4. Padres para Tratamento de Excees em Workflow


Uma exceo um evento inesperado que ocorre durante a execuo de um processo e
para o qual no existe, na maioria dos casos, um tratamento previsto. As causas das ex-
cees so diversas: deadline para execuo do item de trabalho expirado, falta de acesso
a recurso utilizado na execuo do item de trabalho, violao de regras e restries. Rus-
sell [Russell et al. 2006b] prope uma framework para classificao de padres com base
em tratamento de excees em sistemas de workflow. O framework vem sendo utilizado
para verificar a habilidade de sistemas de workflow para o tratamento de excees. Os
padres de exceo identificados foram validados em ferramentas, linguagens e notaes
de workflow, tais como WebSphere MQ 3.4 (IBM), BPEL 1.1 e BPMN 1.0. Como a
maioria das ferramentas, linguagens e notaes investigadas apresentavam mnimo su-
porte para o tratamento de excees, os autores prope um conjunto de primitivas para
tratamento de excees durante a execuo de workflows e um mecanismo para integrar
tais primitivas na modelagem de processos (veja Fig. 1.23).
A Figura 1.24 apresenta um processo para atendimento de pedidos. Neste pro-
cesso, apartir de ordens de compra de clientes, so verificados os itens de compra e estes
Figure 1.21. Exemplos de padres de dados

so obtidos do depsito. Ao mesmo tempo verificado o crdito do cliente e a entrega dos


itens preparada. Quando todas estas etapas forem concludas uma nota fiscal preparada
e os produtos so empacotados para serem entregues ao cliente. Neste contexto, algumas
excees que podem ocorrer durante a verificao de crdito do cliente. Por exemplo, no
caso da quantidade solicitada ser menor do que 100 reais. Neste caso, a solicitao (item
de trabalho) deve ser suspensa e o prximo item deve ser selecionado para execuo.

1.5.5. Padres de Alterao de Processos


Conforme [Weber et al. 2008] o sucesso de uma organizao depende de sua habilitade
para reagir as mudanas em seu ambiente de maneira rpida e eficiente. As causas para
tais mudanas podem ser a introduo de novas leis ou alterao no comportamento dos
clientes. Neste contexto, em [Weber et al. 2008] so propostos 18 padres relacionados
a alterao de controle de fluxo, dividos em padres de adaptao, os quais possibilitam
adicionar, remover atividades do processo em caso de excees e padres para alteraes
Figure 1.22. Exemplos de padres de recurso

em regies especficas de um processo que possibilitam ao usurio adicionar informaes,


em tempo de execuo, sobre partes especficas do processo. Sao definidas regras para
partes especficas dos processos que podem ser alteradas. Tais padres foram identifica-
dos com base na anlise de diversos modelos de processos dos domnios automotivo e
sade. Aplicam-se no nvel de modelagem e de instncia. Os padres garantem maior
flexibilidade a modelagem de processos. A Figura 1.25 apresenta um resumo dos padres
identificados em [Weber et al. 2008].
Considere um paciente que requer um teste de alergia adicional devido a uma in-
compatibilidade a um medicamento especfico. Considere ainda que este teste adicional
no estava previsto no modelo de processo original, o qual precisa ser adaptado. Para
resolver este problema de modelagem, o padro de insero pode ser utilizado. O prob-
lema relacionado a este padro como inserir uma nova atividade no processo, a qual no
estava prevista no modelo original. Veja Figura 1.25.

1.5.6. Padres de Interao de Servios


Em [Barros et al. 2005b] so propostos padres de interao entre de servios. A Ora-
cle BPEL Process Manager prope uma biblioteca de padres de workflow. Com base
em requisitos especficos do negcio, o usurio escolhe o melhor padro disponvel na
biblioteca. Os padres propostos em [Barros et al. 2005b] incluem single-transmission
bilateral, onde um servio envia/recebe uma mensagem e como resposta recebe/envia
uma mensagem. Este padro inclui interaes bilaterais one-way e round-trip; single-
transmission non-routed patterns, onde uma parte pode enviar ou receber mltiplas men-
sagens, mas para/de diferentes partes; multi-transmission (non-routed) interactions, neste
Figure 1.23. Primitivas para tratamento de excees

caso uma parte pode enviar ou receber mltiplas mensagens, mas para/de uma nica parte.
A Figura 1.27 ilustra estes padres.

1.5.7. Padres de Atividade


Processos de negcio e respectivos modelos de workflow freqentemente incluem uma
variedade de funes de negcio (ex.: aprovao, notificao, solicitao de execuo de
tarefa). Em particular, uma funo recorrente em processo de negcio pode ocorrer diver-
sas vezes em uma mesma definio de processo [Thom et al. 2006b], [Thom et al. 2006a].
Durante a execuo do processo, por sua vez, diferentes cpias de uma mesma funo po-
dem apresentar tanto os mesmos valores de parmetros como valores diferentes.Como
exemplo, considere o processo ilustrado na Fig. 1.28, o qual inclui as seguintes ativi-
dades: a) obter informaes sobre o paciente; b) preencher prescrio; c)calcular doses
dos medicamentos; d)verificar doses dos medicamentos; e) produzir medicamentos. Ob-
serve que as atividades a, b e c, respectivamente so executadas no prprio hospital, en-
quanto as atividades d e e so executadas na farmcia do hospital. Tais atividades podem
ser relacionadas a funes de negcio, tais como solicitao de informao (atividade a);
tarefa unidirecional (atividade e), onde uma solicitao para execuo de uma atividade
feita, porm o sistema no aguarda por uma resposta e tarefa bi-direcional (atividades b, c
e d), onde feita uma solicitao e o sistema de workflow aguarda pela resposta, antes de
iniciar execuo. Por exemplo, a atividade Calcular doses dos medicamentos, executada
pelo mdico bi-direcional, pois este s poder preencher calcular as doses, aps saber
quais medicamentos devem ser preescritos ao paciente.
Figure 1.24. Processo para atendimento de pedidos e respectivas estratgias de
tratamento de excees

Em [Thom et al. 2009a] estas funes so relacionadas a padres de atividade de


workflow. Um padro de atividade a descrio de uma funo de negcio frequente-
mente encontrada em processos de negcio. Cada padro de atividade caracterizado por
uma descrio, exemplo, problema, opes de modelagem (variantes do padro), padres
relacionados e implementao do padro. A abordagem em [Thom et al. 2009a] inclui
um conjunto de 7 padres de atividade:

Aprovao: um objeto (ex.: documento) deve ser aprovado por um ou mais papis
organizacionais. Em um processo de ordem de compra pode incluir uma atividade
de autorizao da compra pelo cliente (ex.: verificando se este possui renda sufi-
ciente para o parcelamento).

Pergunta-Resposta: durante a execuo de um processo, um ator pode ter dvidas,


antes da execuo do processo ou durante a execuo de uma atividade, em partic-
ular. O padro pergunta-resposta possibilita elaborar uma questo, identificar um
papel organizacional que esteja apto a responder, direcionar a questo para o ator
correspondente e aguardar a resposta. Por exemplo, enquando desenvolvendo um
programa em java, um programador no especialista pode ter uma dvida especfica
sobre a linguagem, a qual reportada a um especialista na linguagem java.

Performativo Unidirecional: um remetente solicita a execuo de uma atividade a


um receptor (ex.: humano, agente) participante do processo. O remetente continua
a execuo de sua parte no processo imediatamente aps ter enviado a solicitao.
Por exemplo, em um processo de entrada de paciente em um hospital, o tratamento
pode iniciar em paralelo ao cadastro do paciente na recepo (sendo feito por um
familiar).

Performativo Bi-direcional: um remetente solicita a execuo de uma determi-


nada atividade a um determinado paper (ex.: humano ou agente) participante do
Figure 1.25. Tipos de padres de adaptao de processo

Figure 1.26. Exemplo de padro para alterao de processo


Figure 1.27. Exemplos de padres de interao de servios

processo. O remetente aguarda at o receptor notific-lo de que a tarefa foi execu-


tada. Por exemplo, o resultado final de um processo de reviso de artigos s pode
ser finalizado aps todas as revises forem concludas.

Notificao: O status ou resultado da execuo de uma atividade comunicada a


um ou mais participantes do processo. Por exemplo, o resultado de um processo de
reviso de artigos deve ser notificado aos autores.

Solicitao de Informao: Um ator solicita certa informao a um participante do


processo. Ele continua a execuo do processo apenas aps receber a informao
desejada. Por exemplo, em um formulrio de viagem o passageiro deve informar
seus dados para que a passagem seja comprada.

A Figura 1.29 apresenta o padro aprovao modelado na notao BPMN 2.0.


Observe que existem trs variantes do padro aprovao: aprovao simples, onde a
aprovao feita uma nica vez por um participante do processo; aprovao iterativa,
onde diversas aprovaes so realizadas em sequncia conforme a hierarquia organiza-
cional e aprovao em paralelo, onde diversos participantes do processo executam a tarefa
de aprovao em paralelo. A Figura 1.30 apresenta o padro de notificao em duas
variantes: notificao simples, onde apenas um participante recebe a notificao (single-
notification e multipla notificao, onde o padro instanciado para diversos participantes
do processo (multi-notification). Os demais padres identificados tambm apresentam
variaes, tais como instncia simples e mltipla. Uma reviso completa dos padres est
reportada em [Thom et al. 2009a] e [Thom et al. 2011].
Geralmente, mltiplos padres de atividade podem compor um modelo de pro-
cesso em conjunto com outros padres de workflow, tais como padres de controle de
fluxo [Russell et al. 2006a]. Para confirmar a existncia dos padres de atividade foram
analisados mais de 200 modelos de processo reais relacionados a diferentes domnios
de aplicao e executados em diversas organizaes [Thom et al. 2009b]. Os resultados
Figure 1.28. Processo para manipulao de medicamentos na farmcia de um
hospital e respectivas funes de negcio

desta anlise mostraram que os modelos de processo analisados deixam-se modelar com
os padres de atividade, ou seja, o conjunto de padres de atividade necessrio e sufi-
ciente para modelar os processos analisados pelo menos em um determinado nvel de ab-
strao. Com o objetivo de melhor definir os padres de atividade, em [Thom et al. 2008b]
e [Ferreira et al. 2011] apresentada uma ontologia dos padres de atividade. A on-
tologia objetiva possibilitar o armazenamento e consulta dos padres e suas respectivas
propriedades, restries na modelagem de processos. A ontologia torna o relacionamento
entre os padres mais explcito, provendo informaes teis para serem utilizadas durante
a modelagem de processos. Para atingir uma semntica mais precisa, os padres tambm
esto formalizados em Clculo Pi [Thom et al. 2008a]. Mais recentemente, os padres
foram modelados na BPMN 2.0 [Thom et al. 2011]. Por fim, os padres de atividade vm
sendo utilizados em diversas abordagens como na modelagem de organizaes virtuais
[Priego 2012] e em mtodos para integrao de processos de negcio em colaboraes
B2B [Lazarte et al. 2011].
Figure 1.29. Padro aprovao e suas variantes na notao BPMN
Figure 1.30. Padro notificao e suas variantes na notao BPMN

1.6. Consideraes sobre o Gerenciamento de Processos da Sade e Robtica


Industrial
O gerenciamento de processos de negcio e workflow tm recebido grande ateno no
apenas da indstria, mas da academia e em diferentes domnios de aplicao. Existem
pesquisas sendo realizadas para aprimorar as notaes, linguagens e ferramentas de BPM,
mas tambm pesquisas onde BPM e workflow tm sido aplicados, tais como na educao,
unidades governamentais, sade e robtica. A aplicabilidade de BPM tem sido principal-
mente para a documentao e padronizao de processos. Domnios mais completos, tais
como da sade requerem o uso integrado de ontologias. Nesta seo discutimos alguns
aspectos relacionados ao uso de BPM na sade e na robtica industrial.

1.6.1. Gerenciamento de Processos de Negcio na Sade


Em hospitais, o trabalho de mdicos e enfermeiros afetado por diversas tarefas clnicas
e organizacionais. Procedimentos mdicos devem ser planejados, consultas agendadas
e resultados e avaliaes clnicas obtidas. Geralmente, o processo de tratamento ou di-
agnstico de um paciente envolve diferentes unidades mdicas. Para um paciente em
tratamento no departamento de medicina interna, por exemplo, so necessrios testes e
procedimentos realizados no laboratrio e departamento de radiologia. Alm disso, o pa-
ciente precisa ser transportado, mdicos de outras unidades mdicas possivelmente tero
que visitar o paciente e relatrios sobre o estado da sade do paciente devem ser escritos,
enviados e avaliados. Dessa forma, a cooperao entre unidades mdicas e entre mdi-
cos uma tarefa vital e nem sempre fcil de ser realizada. Os processos de tratamento
da sade apresentam complexidade e durao diferentes (ex.: meses). Podem existir
processos organizacionais, de menor complexidade, tal como a entrada de um paciente
no hospital ou a elaborao de relatrio com resultados de um exame radiolgico, mas
tambm processos complexos e longos como o tratamento de um paciente em quimioter-
apia [Dadam et al. 2000]. Diariamente, mdicos precisam decidir quais intervenes so
necessrias ou no, considerando a perspectiva de custos e invasividades. Vrios proced-
imentos requerem medidas preparatrias, muitas vezes de alta complexidade. Antes de
uma cirurgia ser realizada, por exemplo, o paciente submetido a inmeros exames pre-
liminares, sendo que para cada um destes, preparaes adicionais podem ser necessrias.
Enquanto alguns destes exames so conhecidos previamente, outros podem ser solicitados
dinamicamente, dependendo do estado da sade do paciente. As tarefas clnicas devem
ser executadas em certa ordem e, em alguns casos, com um tempo mnimo ou mximo de
execuo.
Geralmente, mdicos coordenam manualmente tarefas relacionadas ao tratamento
de seus pacientes, considerando todas as dependncias existentes entre estas. A sim-
ples alterao da data de consulta de um paciente, por exemplo, requer esforo (mdico
precisa estar disponvel para novo agendamente) e tempo de comunicao. Para determi-
nados tratamentos, mdicos de diversas unidades trabalham juntos. Ou seja, devem ser
definidas sries coerentes de consultas e encontros mdicos . Alm disso, para cada etapa
do tratamento mdico, informaes atualizadas e adequadas sobre o paciente devem ser
disponibilizadas. Cada mdico pode ser responsveis por vrios pacientes e, ao mesmo
tempo, deve prover tratamento eficiente para estes. Finalmente, tarefas mdicas so crti-
cas para o tratamento mdico e mesmo pequenos erros podem resultar em conseqncias
desastrosas.
Neste contexto, mdicos e enfermeiros devem ter liberdade para reagir a situ-
aes inesperadas e so treinados para tal. Em casos de emergncia, por exemplo, os
mdicos coletam informaes sobre o paciente por telefone e continuam o processo, sem
aguardar por um relatrio escrito (eletrnico); ou seja, as atividades de um workflow de-
vem ser dinamicamente omitidas ou adaptadas para evitar discrepncias entre o processo
real e o processo automatizado (workflow). Por exemplo, um determinado procedimento
mdico deve ser interrompido se o estado da sade do paciente piorar ou um dos seus pr-
requisitos no for atendido (ex.: paciente apresenta alergia a um medicamento especfico).
Tais desvios dinmicos (ou excees) do processo pr-planejado so freqentes e formam
uma parte chave para a flexibilidade em processos da sade [Han et al. 2006].

1.6.2. Excees em Processos da Sade


Excees so frequentemente caracterizadas como aes ou eventos, os quais no so
fazem parte do processo AS IS [Luo et al. 2000]. Ainda que a funo da automatizao
de processos seja diminuir o tempo de execuo das tarefas, assim como esforo-humano
para execut-las, excees so frequentes em sistemas de informao para a sade. So
situaes inesperadas, as quais podem afetar a execuo do processo, causando desvios
no comportamento deste [Casati and Pozzi 1999]. Considere, por exemplo, um processo
de solicitao de medicamentos na farmcia de um hospital (veja Fig. 1.31). O pro-
cesso inclui a seguinte ordem parcial de atividades: a) primeiramente, so obtidas infor-
maes sobre o paciente; b) o mdico deve, ento, preencher a prescrio; c) com base
nos medicamentos selecionados, so calculadas as doses de cada medicamento a serem
utilizadas no tratamento do paciente e; d) o farmacista verifica as doses solicitadas; e)
os medicamentos so produzidos. Este processo, embora simples inclui diversos desvios
ou situaes adversas. Por exemplo, se a solicitao para produo dos medicamentos
no chegar na farmcia antes das 11 horas da manh, a farmcia no poder produzi-los.
Neste caso, o hospital pode produzir os medicamentos internamente (vejaFig. 1.31. No
caso de erro no material coletado do paciente (ex.: sangue ao invs de urina) o hospital
tambm autorizado a produzir os medicamentos internamente. O mesmo se aplica para
o caso onde o estado da sade do paciente altera (ex.: quadro da sade melhora). Neste
caso, a produo dos medicamentos abortada.
Sistemas de gerenciamento de processos podem ser afetados por diversas ex-
cees, as quais so geralmente classificadas na literatura como previstas e no previstas
[Luo et al. 2000],[Casati and Pozzi 1999], [Mouro and Antunes 2007]. Alm destas, ex-
istem diversas outras abordagens para classificao de excees [Sadiq and Orlowska 2000],
[Russell 2006], [Strong and Miller 1995]. O tratamento de excees na automatizao de
processos de negcio uma tarefa complexa e geralmente cara [Sadiq and Orlowska 2000].
Tratar a exceo e ao mesmo tempo garantir flexibilidade tem sido um desafio na autom-
atizao de processos de negcio. Processos da sade, em particular requerem a cooper-
ao de diversas unidades organizacionais e disciplinas mdicas, as quais so tratadas di-
namicamente por mdicos e enfermeiros [Lenz and Reichert 2007]. Tais processos sofrem
alteraes freqentes e incluem diversas excees (tais como as ilustradas na Fig. 1.31).
Dessa forma, importante o sistema de healthcare no restringir mdicos e enfermeiros
e, ao mesmo tempo garantir certo controle e assistncia.
Entender as causas das excees em processos da sade fundamental para o
8 desenvolvimento de sistemas da sade mais flexveis e aceitos pelos profissionais da
sade. Sem conhecer estas causas e como mdicos e enfermeiros tratam as excees na
prtica, o projetista de workflow no ter plenas condies de implement-las no sistema
da sade. Em [Thom et al. 2006c] foi proposta uma abordagem onde foram analisados
diversos processos de tratamento de cncer, obtidos junto a um hospital da mulher na
Alemanha. A partir deste estudo, foi verificado que as excees podem ser causadas
por eventos variados tais como: a) erro mdico; b) eventos relacionados ao paciente; c)
restries organizacionais e; e) problemas tcnicos.

Excees relacionadas ao Paciente: Esta categoria compreende circunstancias es-


pecficas envolvendo o paciente, as quais podem resultar em excees. Por exem-
plo, alteraes no estado da sade do paciente ou a recusa do paciente em iniciar
ou continuar determinado tratamento pode levar interrupo de determinado trata-
mento ou, ainda, que este seja iniciado.

Excees relacionadas a restries organizacionais:processos organizacionais (ex.:


admisso e alta do paciente) geralmente seguem determinados protocolos. No en-
tanto, em situaes de emergncia aplicado. Por exemplo, durante a admisso de
um paciente no hospital, o paciente deve fornecer diversas informaes pessoais,
assim como assinar formulrios consentido com o exame mdico. Caso o estado da
sade do indivduo seja grave, estas informaes pessoais ser obtidas com algum
membro da famlia, enquanto o exame mdico realizado. Outras possveis causas
das excees so: a no-observncia de horrio limite para solicitar a produo de
medicamentos na farmcia do hospital; ou a solicitao de uma anlise laboratorial,
a qual normalmente realizada pela manha, mas em casos excepcionais deve real-
izada tarde.
Figure 1.31. Exemplos de excees em um processo para solicitao de manip-
ulao de medicamentos na farmcia de um hospital

Excees relacionadas a problemas tcnicos: eventualmente, problemas tcnicos


podem ocorrer durante um processo da sade. Por exemplo, uma maquina de lab-
oratrio parar durante a realizao de uma anlise. Neste caso a mquina ter que
ser reiniciada e a anlise realizada novamente. Contingncias durante o transporte
de medicamentos tambm podem causar excees.

Excees relacionadas a Erros Mdicos: Erros na medicina no so raros e po-


dem resultar em conseqncias severas [Blaser et al. 2004]. A falta de qualidade
nas cartas de alta do paciente, por exemplo caracteriza uma das causas de erros
mdicos. A falta de informao, assim como informaes inconsistentes e incorre-
tas em tais cartas podem levar a diagnsticos e tratamentos errneos. Alm disso,
o no seguimento das regras de tratamento mdico, assim como protocolos tam-
bm pode resultar em erros mdicos. Com certeza, situaes inesperadas tambm
iro ocorrer, mesmo que os protocolos mdicos sejam rigorosamente seguidos. No
entanto, conforme [Nguyen and Nguyen 2005] a eficincia dos protocolos estab-
elecida atravs de estudos clnicos, os quais comprovam a baixa da mortalidade e
morbidade. Tais protocolos tambm podem contribuir para a seleo mais correta
de medicamentos para um paciente ou evitar discrepncias entre o medicamento
recebido pelo paciente e o medicamento prescrito [Bates 2000].

1.6.3. Suporte Computacional ao Tratamento de Excees em Processos da Sade


Nos ltimos anos, pesquisas sobre suporte computacional para processos de healthcare
tm crescido [Dadam et al. 2000], [Lenz and Reichert 2007],[Han et al. 2006]. Processos
da sade podem ser divididos em processos organizacionais (ex.: entrada de um paciente
no hospital) e de tratamento mdico (ex.: procedimentos de diagnstico). Diferentes de-
safios emergem no contexto destes dos tipos de processos. Com relao aos processos
organizacionais, um dos principais desafios inclui a integrao de aplicativos e o suporte
cooperao. Processos de tratamento mdico apresentam desafios interessantes refer-
entes tomada de deciso mdica. Apesar de resultados importantes j terem sido obtidos
nestes contextos, ainda existem questes importantes a serem pesquisadas: a) quais so as
principais caractersticas dos processos da sade, as quais podem contribuir para a mel-
hor definio e automatizao destes? b) como prover suporte tecnolgico para processos
de healthcare executados em diferentes unidades organizacionais; c) quais so as princi-
pais excees que ocorrem em processos da sade e como os participantes do processo
(ex.: mdicos, enfermeiros, assistentes) tratam estas excees? d) qual a natureza, causas
destas excees e como prover suporte tecnolgico efetivo a estas?
Diversos estudos tm demonstrado efeitos positivos de sistemas de informao de
healthcare [Huynh and Agnihothri 2000]. Em particular, a preveno de eventos adversos
(ou seja, situaes inesperadas) na medicina pode aumentar com o uso da tecnologia
da informao.Sistemas de Informao para sade, no entanto, tem o potencial de reduzir
significantemente a taxa de eventos adversos, pois tais sistemas aprimoram a comunicao
entre mdicos, alm de fornecer informaes precisas e necessrias para cada estgio do
tratamento mdico.
A melhoria e automatizao de processos da sade no deve restringir o trabalho
de mdicos e enfermeiros. Variaes no curso de uma doena ou tratamento so comuns
na medicina. Sendo assim, qualquer sistema de informao com o propsito de auxiliar
mdicos e enfermeiros em suas tarefas dirias deve propiciar a autonomia necessria a
estes. O sistema deve ser fcil de operar, auto-explicativo e, principalmente seu uso em
situaes excepcionais no deve consumir mais tempo que uma simples chamada tele-
fnica ao mdico ou enfermeiro adequado; caso contrrio, o sistema no ser aceito por
seus usurios.
Em ambientes dinmicos como da sade, os processos devem ser continuamente
adaptados, porm sem afetar os resultados esperados. Recentemente, diversas abordagens
tm sido propostas relacionadas ao gerenciamento de processos mais flexvel (ex.: geren-
ciamento de processos adaptativos, case handling, processos declarativos e workflow ori-
entado a dados). Todas estas abordagens garantem certo nvel de flexibilidade ao pro-
cesso, ainda que no tenham sido aplicadas no contexto da sade [Lenz and Reichert 2007]],
[Becker and Janiesch 2008]. So necessrias pesquisas mais detalhadas sobre a origem,
causas das excees em processos da sade (tais como as ilustradas na Fig. 1.31), assim
Table 1.1. Resumo das caractersticas dos processos de tratamento de cncer analisados

como seu tratamento por mdicos e enfermeiros. Estes tipos de pesquisas so de grande
importncia para o desenvolvimento de sistemas de sade mais aceitveis e flexveis. Tal
conhecimento tambm fundamental para auxiliar o projetista do sistema na definio
do melhor esquema computacional a ser utilizado durante a automatizao (ex.: case-
handling, padres de exceo [Russell et al. 2006b], padres de alterao de processos
[Weber et al. 2008]).
Considerando esta necessidade em [Thom et al. 2006c] descrito um estudo de
caso, onde foram analisados cerca de 10 modelos de processos relacionados ao trata-
mento de cncer em um hospital da mulher na Alemanha. O objetivo da anlise foi iden-
tificar excees e com base na literatura de medicina e em entrevistas com especialistas e
relacionar tais excees com as causas descritas na seo 6.2. A Tab. 1.1 resumi as car-
actersticas dos processos analisados. A tabela 1.2 apresenta a classificao das excees
identificadas.
Para ilustrar, considere a exceo Alterao no estado da sade do paciente. Esta
exceo tem como causa natureza o estado da sade do paciente melhora ou piora du-
rante um tratamento quimioterpico e como possveis reaes i)interromper o tratamento
e respectivas consultas mdicas; ii)cancelar produo de medicamentos para o trata-
mento do paciente e; iii) o paciente deve passar a noite no hospital.

1.6.4. Gerenciamento de Processos de Negcio na rea de Robtica Industrial


A rea de robtica e automao, assim como da sade inclui terminologia complexa,
onde o entendimento dos termos crucial para o desenvolvimento de qualquer soluo
tecnolgica. Um dos principais requisitos para a comunicao de qualquer tipo de rob,
ou seja, comunicao entre robs ou de robs com humanos a existncia de um vo-
Table 1.2. Classificao das excees identificadas

cabulrio comum com conceitos bem definidos [Schlenoff 2012]. Esta foi a motivao
para a criao do grupo Ontologies for Robotics and Automation (ORA) da IEEE-RAS.
Ou seja, criar uma ontologia para as reas de robtica e automao, a qual possibilite a
definio mais precisa de conceitos utilizados pelas reas, assegure um entendimento co-
mum sobre estes termos entre as comunicades envolvidas e facilite a integrao de dados
e a tranferncia de informaes entre sistemas robticos.
Conforme a ORA a construo de uma ontologia para os domnios da robtica e
automao uma tarefa complexa devido a grande diversidade de termos existentes nestes
domnios. Para facilitar a tarefa de construo da ontologia, o grupo est estruturado
em sub-grupos tais como Upper Ontology/Methodology responsvel pela criao de uma
ontologia de base e os subgrupos relacionados a domnios especficos tais como, Robtica
Autonoma, Robtica de Servios e Robtica Industrial.

1.6.5. Introduo Metodologia para Criao de Ontologias apartir de Modelos de


Processo
Processos da sade so extremamente complexos no apenas pela sua variedade, neces-
sidade de flexibilidade durante a execuo, mas principalmente porque requerem o con-
hecimento de termos de domnio especficos, os quais podem gerar problemas de interpre-
tao, ambiguidades entre o analista de processo e o especialista [Becker and Janiesch 2007],
[Weber et al. 2008], [Thom et al. 2006a]. Em diversos domnios da sade, o gerencia-
mento do conhecimento mdico necessrio para: aprimorar o tratamento de um paciente,
melhorar a sade pblica, analisar e comparar processos da sade e comparar prescries
mdicas. Neste contexto, o uso de ontologias pode ser bastante til para a obteno de
informaes.
Com base nestes aspectos, foi desenvolvida uma metodologia a qual possibilita
construir ontologias de aplicao utilizando informaes de modelos de processos. Aps,
esta ontologia pode ser utilizada para suportar a modelagem de novos modelos de proces-
sos. Tal abordagem pode reduzir problemas de entendimento entre o analista de processo
e o especialista de domnio, facilitando e aperfeioando a modelagem de processos.
Em particular, termos chave so extrados do processo. Tais termos so utiliza-
dos para a construo da ontologia. Tanto o modelo de processo como a ontologia ficam
armazenados em repositrios. Dessa forma, quando um novo processo precisa ser mod-
elado, inicialmente o repositrio pesquisado e, caso nenhum processo semelhante seja
localizado um novo processo modelado.
Para tanto, o repositrio de ontologias tambm pesquisado, pois caso exista uma
ontologia de aplicao similar ao processo sendo modelado esta pode ser utilizada. A
ontologia pode ser utilizada para aprimorar o modelo de processo. Ou seja, os termos
utilizados no processo podem ser revistos conforme a ontologia de aplicao. Alm disso,
com base em vrias ontologias de aplicao se pode obter ontologias de domnio. A
Figura 1.32 ilustra os passos da metodologia sendo proposta.

Figure 1.32. Metodologia para criao de ontologias apartir de modelos de processos

1. Entender o domnio do processo: nesta fase o analista de processo estuda o


domnio de aplicao relacionado aos processos de negcio. Para tanto, o analista
estuda a documentao disponvel na organizao e na literatura, focando em infor-
maes relevantes relacionadas aos processos a serem modelados, isto , o analista
tenta identificar fragmentos de processos e respectivos papis organizacionais re-
sponsveis pela execuo das atividades dos processos. A idia reduzir o nmero
de interaes com os especialistas de domnio realizando entrevistas apenas para
complementar o estudo e validar as primeiras verses dos processos. Com base nas
informaes obtidas nesta fase, uma consulta feita no repositrio de processos
para verificar a existncia de processos ou fragmentos de processos semelhantes, os
quais possam ser reutilizados.
2. Modelagem do processo: com base no estudo realizado na fase 1, o analista de pro-
cesso pode modelar o processo apartir do zero ou simplesmente adaptar o modelo
de processo obtido do repositrio de processos. A modelagem geralmente com-
pletada atravs de entrevistas realizadas com os especialistas de domnio. Como
ilustrado na Figura 1.32 no caso da consulta resultar em um modelo de processo
para ser reutilizado, o analista de processo deve decidir por: i) utilizar o processo
sem realizar modificaes; ii) se alteraes forem necessrias, decidir se o pro-
cesso ser salvo no repositrio de processos sem ser duplicado ou; iii) se aterado
o processo ser duplicado no repositrio de processos. Caso a consulta resulte em
nenhum modelo, um novo processo dever ser modelado. No caso da opo ii) ou
iii) serem selecionadas, o repositrio de processos ser atualizado.

3. Identificao de termos bsicos para a ontologia: nesta fase, o projetista da on-


tologia ou o analista de processo iro analisar o processo e extrair termos chave
para a construo da ontologia considerando elementos de processo, tais como la-
bels de atividades e participantes do processo. Com base na seleo de termos
especficos selecionados, uma consulta ser realizada no repositrio de ontologias
para verificar se existe uma ontologia adequada para ser reutilizada. Esta etapa
realizada de maneira manual, mas os autores j esto investigando maneiras de
semi(automatiz-la).

4. Criao da ontologia: nesta fase, se uma ontologia adequada existir no repositrio


ela ser adaptada conforme as caractersticas de contexto. Caso contrrio, uma nova
ontologia ser criada. Se existir uma ontologia no repositrio para ser reutilizada,
o projetista da ontologia deve decidir: i) se a ontologia pode ser reutilizada sem
a necessidade de qualquer alterao; ii) se a ontologia ser adaptada conforme o
modelo de processo ou; iii) se uma nova ontologia ser criada. Se uma ontologia
for adaptada ou criada a fase 4 da metodologia ser executada e o repositrio deve
ser atualizado. Caso contrrio, o passo 5 ser imediatamente executado com base
na ontologia resultante da consulta ao repositrio. Quando uma nova ontologia
criada, os termos extrados do processo so o ponto inicial para a criao da
ontologia. O projetista da ontologia ir completar esta ontologia adicionando novos
termos, relacionamentos, atributos e restries.

5. Melhoria do processo: Nesta fase, o modelo de processo obtido na fase 2 da


metodologia pode ser revisado com a assitncia da ontologia de aplicao corre-
spondente. O processo pode incluir labels de atividade mais apropriados utilizando
os conceitos da ontologia. Conforme [Galatescu and Greceanu 2003] ontologias
podem facilitar o trabalho em equipe (virtual), fornecendo um vocabulrio de en-
tendimento comum.

1.6.6. Aplicando a Medologia de Extrao de Termos do Processo na Construo de


Ontologias para a Robtica
A Figura 1.33 apresenta um processo para posicionar um kit robtico em uma mesa de tra-
balho. O processo inicia com a execuo do subprocesso para atachar uma mo-mecnica
a um brao robtico (veja Fig. 1.10). O brao robtico pega o kit posiciona o kit na
mesa de trabalho. Este um dos processos da rea de robtica que podem ser modelados
atravs da BPMN. Apartir deste processo e da modelagem de subprocesso relacionados
possvel aplicar a metodologia apresentada na Seo 6.5, contribuindo para os objetivos
de padronizao da ORA.

Figure 1.33. Modelo de processo para posicionar um kit robtico em uma mesa
de trabalho

Alguns termos chave que poderiam ser extrados apartir dos modelos de processo
para conectar uma mo-mecnica a um brao robtico e do processo para posicionar
um kit robtico em uma mesa de trabalho so os substantivos: tarefa, mo-mecnica,
brao-robtico, rob, mesa de trabalho, kit-tray e conector; e os verbos: conectar, de-
sconectar, est conecatada, est concluda, escolher, pegar, posicionar. Apartir disso,
possvel estabelecer alguns relacionamentos com a criao da ontologia. Os substantivos,
por exemplo, podem ser mapeados para classes da ontologia, enquanto os verbos para
associaes [Gassen 2012].

1.7. Consideraes Finais


Este captulo apresentou diversos aspectos referentes ao gerenciamento de processos de
negcio e sua aplicabilidade na sade e na robtica. Inicialmente foram apresentados os
principais conceitos inerentes a BPM, os quais so padronizados pela Workflow Manage-
ment Coalition e utilizados na prtica por pesquisadores e profissionais das reas de BPM
e workflow. Alm disso, estes conceitos so a base para o desenvolvimento de diver-
sas ferramentas de modelagem e implementao de workflow, tais como Bizagi e Oracle.
Tambm foram revisados os principais elementos da Notao para Modelagem de Proces-
sos. Seu uso foi exemplificado atravs de diversos exemplos de processos apresentados ao
longo do captulo. O ciclo de vida de um projeto de workflow foi discutido, enfatizando-
se a importncia das fases de elicitao de requisitos/modelagem e monitoramento, na
qual melhorias para o processo podem ser identificadas e implementadas. Aps, foram
introduzidos os principais tipos de padres de workflow existentes na literauta. Entre
estes, padres pra controle de fluxo esto entre os mais utilizados. J os padres de ativi-
dade de workflow esto sendo aplicados em diversas abordagens, ainda que no tenham
sido implementados em nenhuma ferramenta de wofkflow at o presente. Finalmente, o
captulo discute o uso de BPM e Workflow nas reas da sade e robtica. Em ambas as
reas BPM tem sido utilizado como forma de padronizar e documentar os processos. Na
sade, em especial, devido a necessidade de adaptao dinmica e flexibilidade, o trata-
mento de excees em nvel de modelagem e execuo fator crtico para a qualidade
dos modelos de processo e sua utilizao quando implementados. J na robtica, a cri-
ao de ontologias de grande importncia e tem sido sido explorado pela academia. A
criao de ontologias com base em modelos de processo parece ser um desafio que pode
no apenas facilitar a criao de ontologias, mas principalmente proporcionar ontologias
com informaes mais detalhadas e precisas sobre os domnios de aplicao para os quais
modelos de processo precisam ser modelados.
As principais contribuies deste captulo so: a reviso de conceitos fundamen-
tais inerentes a gerenciamento de processos, workflow, arquitetura orientada a servios e
a notao para modelagem de processos. Este resumo poder ser utilizado como guia por
acadmicos e profissionais das reas de BPM e Workflow. Considerando que uma grande
variedade de padres de workflow, focando aspectos diversos foram propostos nos lti-
mos anos, uma reviso detalhada sobre principais padres de workflow existentes na liter-
atura foi apresentada. Tais padres referem-se a perspectivas diferentes de processos (ex.:
controle de fluxo, dados, recurso, servios, alterao de processos e atividades), sendo
que podem ser utilizados de maneira isolada ou em combinao (ex.: padres de ativi-
dade e padres de controle de fluxo). A discusso sobre as principais problemticas, hoje
existentes, na modelagem e automatizao de processos da sade e robtica, indicando
como BPM e Workflow podem contribuir para minizar tais dificuldades (ex.: identifi-
cao e tratamento de excees em processos da sade, proporcionando maior adaptao
dinmica e flexibilidade aos sistemas) pode motivar o desenvolvimento de pesquisas com-
plementares nesta rea.

1.8. Agradecimentos
A autora deste captulo agradece a Coordenao de Aperfeioamento de Pessoal de Nvel
Superior (CAPES), em especial ao Programa Nacional de Ps-Doutorado (PNPD).

References
[Barros et al. 2005a] Barros, A. P., Dumas, M., and ter Hofstede, A. (2005a). Service
interaction patterns. In Business Process Management, pages 302318.
[Barros et al. 2005b] Barros, A. P., Dumas, M., and ter Hofstede, A. H. M. (2005b). Ser-
vice interaction patterns. In van der Aalst, W. M. P., Benatallah, B., Casati, F., and
Curbera, F., editors, Business Process Management, volume 3649, pages 302318.
[Bates 2000] Bates, D. (2000). Using information technology to reduce rates of medica-
tion errors in hospitals. British Medical Journal, 320(7237):788791.
[Becker and Janiesch 2007] Becker, J. and Janiesch, C. (2007). Restrictions in process
design: A case study on workflows in healthcare. In Business Process Management
Workshops, pages 323334.
[Becker and Janiesch 2008] Becker, J. and Janiesch, C. (2008). Restrictions in process
design: a case study on workflows in healthcare. In Proceedings of the 2007 interna-
tional conference on Business process management, BPM07, pages 323334, Berlin,
Heidelberg. Springer-Verlag.
[Blaser et al. 2004] Blaser, R., Schnabel, M., Mann, D., Jancke, P., Kuhn, K. A., and
Lenz, R. (2004). Potential prevention of medical errors in casualty surgery by us-
ing information technology. In Proceedings of the 2004 ACM symposium on Applied
computing, SAC2004, pages 285290, New York, NY, USA. ACM.

[Casati and Pozzi 1999] Casati, F. and Pozzi, G. (1999). Modeling exceptional behaviors
in commercial workflow management systems. In Proceedings of the Fourth IECIS
International Conference on Cooperative Information Systems, COOPIS 99, pages
127, Washington, DC, USA. IEEE Computer Society.

[Comite 2006] Comite, O. (2006). Reference model for service oriented architecture.
Technical report, OASIS.

[Crowston 2000] Crowston, K. (2000). Process as theory in information systems re-


search. In Proceedings of the IFIP TC9 WG8.2 International Conference on Home
Oriented Informatics and Telematics,: Information, Technology and Society, HOIT
00, pages 149166, Deventer, The Netherlands, The Netherlands. Kluwer, B.V.

[Dadam et al. 2000] Dadam, P., Reichert, M., and Kuhn, K. (2000). Clinical workflows -
the killer application for process-oriented information systems? In Proc. 4th Interna-
tional Conf. on Business Information Systems (BIS00), pages 3659. Springer.

[Ellis and Nutt 1980] Ellis, C. A. and Nutt, G. J. (1980). Office information systems and
computer science. ACM Comput. Surv., 12(1):2760.

[Ferreira et al. 2011] Ferreira, D. R., Alves, S., and Thom, L. H. (2011). Ontology-based
discovery of workflow activity patterns. In Daniel, F., Barkaoui, K., and Dustdar, S.,
editors, Business Process Management Workshops (2), volume 100 of Lecture Notes in
Business Information Processing, pages 314325. Springer.

[Fischer 2001] Fischer, L. (2001). Workflow Handbook. Workflow Management Coali-


tion.

[Galatescu and Greceanu 2003] Galatescu, A. and Greceanu, T. (2003). Enterprise in-
formation systems iv. chapter Ontologies supporting business process re-engineering,
pages 186193. Kluwer Academic Publishers, Hingham, MA, USA.

[Gassen 2012] Gassen, J. B., P. J. M. T. L. H. M. A. (2012). Ontology support for home


care process design. In 14 Internacional Conference on Enterprise Information Sys-
tems (ICEIS), Wroclaw, Polnia. ICEIS Press. Aceito para publicao.

[Han et al. 2006] Han, M., Thiery, T., and Song, X. (2006). Managing exceptions in the
medical workflow systems. In Proceedings of the 28th international conference on
Software engineering, ICSE 06, pages 741750, New York, NY, USA. ACM.

[Huynh and Agnihothri 2000] Huynh, M. and Agnihothri, S. (2000). Healthcare infor-
mation systems. chapter Healthcare process redesign: a case study, pages 2749. IGI
Publishing, Hershey, PA, USA.

[Knight 2005] Knight, Dbora Mac ; Araujo, R. M. d. . B. M. R. S. (2005). A systematic


approach for identifying system requirements from the organizations business model.
In Simpsio Brasileiro de Sistemas de Informao, pages 110, Florianpolis.
[Lazarte et al. 2011] Lazarte, I. M., Villarreal, P. D., Chiotti, O., Thom, L. H., and Iochpe,
C. (2011). An mda-based method for designing integration process models in b2b
collaborations. In Zhang, R., Cordeiro, J., Li, X., Zhang, Z., and Zhang, J., editors,
ICEIS (3), pages 5565. SciTePress.

[Lenz and Reichert 2007] Lenz, R. and Reichert, M. (2007). It support for healthcare
processes - premises, challenges, perspectives. Data Knowl. Eng., 61(1):3958.

[Luo et al. 2000] Luo, Z., Sheth, A., Kochut, K., and Miller, J. (2000). Exception han-
dling in workflow systems. Applied Intelligence, 13(2):125147.

[Mouro and Antunes 2007] Mouro, H. and Antunes, P. (2007). Supporting effective
unexpected exceptions handling in workflow management systems. In Proceedings of
the 2007 ACM symposium on Applied computing, SAC 07, pages 12421249, New
York, NY, USA. ACM.

[Nguyen and Nguyen 2005] Nguyen, A. and Nguyen, D. (2005). Learning from medical
errors: legal issues. Number No 576 in Learning from Medical Errors: Legal Issues.
Radcliffe.

[OMG 2009] OMG (2009). Business process modeling notation (bpmn) version 1.2.
Technical report, OMG.

[Priego 2012] Priego, L.M., T. L. H. F. A. R. D. M. J. (2012). Business process design


from virtual organization intentaional models. In 24th International Conference on
Advanced Information Systems Engineering CAiSE.

[Reijers and Limanmansar 2005] Reijers, H. and Limanmansar, S. (2005). Best practices
in business process redesign: an overview and qualitative evaluation of successful re-
design heuristics. Omega, 33(4):283306.

[Russell 2006] Russell (2006). Exception Handling Patterns in Process-Aware Informa-


tion Systems. Technical report.

[Russell et al. 2006a] Russell, N., ter Hofstede, A., van der Aalst, W., and Mulyar, N.
(2006a). Workflow control flow patterns: A revised view. Technical report, BPM
Center.

[Russell and ter Hofstede 2009] Russell, N. and ter Hofstede, A. H. M. (2009). newyawl:
Towards workflow 2.0. T. Petri Nets and Other Models of Concurrency, 2:7997.

[Russell et al. 2005a] Russell, N., ter Hofstede, A. H. M., Edmond, D., and van der Aalst,
W. M. P. (2005a). Workflow data patterns: Identification, representation and tool sup-
port. In Delcambre, L. M. L., Kop, C., Mayr, H. C., Mylopoulos, J., and Pastor,
O., editors, ER, volume 3716 of Lecture Notes in Computer Science, pages 353368.
Springer.

[Russell et al. 2006b] Russell, N., van der Aalst, W., and ter Hofstede, A. H. M. (2006b).
Exception handling patterns in process-aware information systems. Technical report,
BPM Center.
[Russell et al. 2006c] Russell, N., van der Aalst, W. M. P., and ter Hofstede, A. H. M.
(2006c). Workflow exception patterns. In Dubois, E. and Pohl, K., editors, CAiSE,
volume 4001 of Lecture Notes in Computer Science, pages 288302. Springer.

[Russell et al. 2005b] Russell, N., van der Aalst, W. M. P., ter Hofstede, A. H. M., and
Edmond, D. (2005b). Workflow resource patterns: Identification, representation and
tool support. In Pastor, O. and e Cunha, J. F., editors, CAiSE, volume 3520 of Lecture
Notes in Computer Science, pages 216232. Springer.

[Sadiq and Orlowska 2000] Sadiq, S. W. and Orlowska, M. E. (2000). On capturing ex-
ceptions in workflow process models.

[Santos 2010] Santos, R. (2010). Bpmn v. 1.2 business process modeling notation.

[Schlenoff 2012] Schlenoff, Craig; Prestes, E. M. R. G. P. L. H. B. s. K. T. M. E. (2012).


An IEEE Standard Ontology for Robotics and Automation. Springer-Verlang.

[Sommerville 2003] Sommerville, I. (2003). Engenharia de Software. Addison Wesley,


So Paulo, SP, 6 edition.

[Specification 1999] Specification, W. M. C. (1999). Workflow Management Coalition,


Terminology and Glossary (Document No. WFMC-TC-1011). Workflow Management
Coalition Specification.

[Strong and Miller 1995] Strong, D. and Miller, S. M. (1995). Exceptions and exception
handling in computerized information processes. ACM Transactions on Information
Systems, 13(02):206233.

[Thom 2000] Thom, L. H., I. C. V. S. G. I. (2000). Processo de modelagem de workflow


considerando fatores humanos e a anlise da dinmica organizacional. In International
Synposium on Knowlegment Management / Document Management (ISKM-DM), Cu-
ritiba.

[Thom 2012] Thom, L. H.; Oliveira, J. P. M. d. G. J. (2012). Towards an ontological


process modeling approach. Technical report, Universidade Federal do Rio Grande do
Sul, Porto Alegre. A ser publicado.

[Thom et al. 2006a] Thom, L., Iochpe, C., Amaral, V., and Viero, D. (2006a). To-
wards Workflow Block Activity Patterns for Reuse in Workflow Design, pages 249260.
WfMC Workflow Handbook 2006. Lighthouse Point : Future Strategies, FL, USA.

[Thom et al. 2006b] Thom, L., Iochpe, C., and Mitschang, B. (2006b). Applying block
activity patterns in workflow modeling. In Proc. da International Conference on En-
terprise Information Systems (ICEIS), pages 457460, Paphos, Chipre.

[Thom et al. 2008a] Thom, L., Iochpe, C., Reichert, M., Weber, B., Droop, M., Nasci-
mento, G., and Chiao, C. M. (2008a). On the support of activity patterns in prowap:
Case studies, formal semantics, tool support. Revista Brasileira de Sistemas de Infor-
macao (iSYS), 01:2753.
[Thom et al. 2009a] Thom, L., Reichert, M., and Iochpe, C. (2009a). Activity patterns in
process-aware information systems: Basic concepts and empirical evidence. Interna-
tional Journal of Business Process Integration and Management (IJPIM), 4(2):93110.
[Thom et al. 2009b] Thom, L., Reichert, M., and Iochpe, C. (2009b). On the support of
workflow activity patterns in process modeling tools: Purpose and requirements. In
Brazilian Symposium on Multimedia and the WEB (Webmedia 2009), 3rd Workshop
on Business Process Management (WBPM 2009).
[Thom et al. 2011] Thom, L. H., Lazarte, I. M., Iochpe, C., Priego, L.-M., Verdier, C.,
Chiotti, O., and Villarreal, P. D. (2011). On the capabilities of bpmn for workflow
activity patterns representation. In Dijkman, R. M., Hofstetter, J., and Koehler, J.,
editors, BPMN, volume 95 of Lecture Notes in Business Information Processing, pages
172177. Springer.
[Thom et al. 2008b] Thom, L. H., Reichert, M., Chiao, C. M., Iochpe, C., and Hess,
G. N. (2008b). Inventing less, reusing more and adding intelligence to business process
modeling. In Proceedings of the 19th international conference on Database and Expert
Systems Applications, DEXA 2008, pages paperpages, Berlin, Heidelberg. Springer-
Verlag.
[Thom et al. 2006c] Thom, L. H., Reichert, M., Iochpe, C., and Moreira, J. P. (2006c).
Why rigid process management technology hampers computerized support of health-
care processes? In Proceedings of the X Workshop on Medical Informatics, pages
15221531, Belo Horizonte, Brazil. Computer Brazilian Society.
[Thomas 2009] Thomas, E. (2009). SOA Princpios de Design de Servios.
[van der Aalst et al. 2003] van der Aalst, W., ter Hofstede, A., Kiepuszewski, B., and
Barros, A. P. (2003). Workflow patterns. Distributed and Parallel Databases, 14(1):5
51.
[Vanwersch 2011] Vanwersch, R.J.B. ; Shahzad, K. V. K. G. P. P. L. M. J. v. M. G. R. H.
(2011). Methodological support for business process redesign in healthcare: A litera-
ture review protocol. International Journal of Care Pathways, 15(4):119126.
[Weber et al. 2008] Weber, B., Reichert, M., and Rinderle-Ma, S. (2008). Change pat-
terns and change support features - enhancing flexibility in processaware information
systems. Data Knowledge Engineering, 66(3):438466.
[Weber et al. 2009] Weber, B., Sadiq, S., and Reichert, M. (2009). Beyond rigidity -
dynamic process lifecycle support: A survey on dynamic changes in process-aware
information systems. Computer Science - Research and Development manuscript,
23(2):4765.
[Weske 2007] Weske, M. (2007). Business Process Management: Concepts, Languages,
Architectures. Springer.
[Zhao 1998] Zhao, J. L. (1998). Knowledge management and organizational learning in
workflow systems. In Proceedings of AIS 98, pages 1416.