Revista de Gesto da Tecnologia e Sistemas de Informao

Journal of Information Systems and Technology Management

Vol. 4, No. 1, 2007, p. 71-94
ISSN online: 1807-1775
_____________________________________________________________________________________
Recebido em/Manuscript first received: 18/04/2006 Aprovado em/Manuscript accepted: 30/08/2006

Endereo para correspondncia/ Address for correspondence
Jos Osvaldo De Sordi, Universidade Catlica de Santos, Docente-pesquisador do programa de mestrado
em Gesto de Negcios, Rua Dr. Carvalho de Mendona, 144, Santos/SP, CEP 11070-906, Tel.: (13)
3226-0504 Fax: (13) 3226-0500, e-mail: [Link]@[Link]
Andrea Giovanni Spelta, Docente-Pesquisador na Universidade IMES-SCSUL e Doutorando em
Administrao de Empresas na EAESP-FGV, Av. Nove de J ulho, 2029 - Bela Vista, So Paulo/SP, CEP
01313-902, Tel.: (11) 3281-7700 Fax: (11) 3284-1789, e-mail: [Link]@[Link]


ISSN online: 1807-1775
Publicado por/Published by: TECSI FEA USP 2007

ANLISE DE COMPONENTES DA TECNOLOGIA DE
BUSINESS PROCESS MANAGEMENT SYSTEM (BPMS)
SOB A PERSPECTIVA DE UM CASO PRTICO
BUSINESS PROCESS MANAGEMENT SYSTEMS TECHNOLOGY COMPONENTS
ANALYSIS


Jos Osvaldo De Sordi
Universidade Catlica de Santos, Brasil
Andrea Giovanni Spelta
Universidade Imes-Scsul e EAESP-FGV, Brasil

______________________________________________________________________
ABSTRACT
The information technology that supports the implementation of the business process
management appproach is called Business Process Management System (BPMS). The main
components of the BPMS solution framework are process definition repository, process
instances repository, transaction manager, conectors framework, process engine and middleware.
In this paper we define and characterize the role and importance of the components of BPMS's
framework. The research method adopted was the case study, through the analysis of the
implementation of the BPMS solution in an insurance company called Chubb do Brasil. In the
case study, the process "Manage Coinsured Events"" is described and characterized, as well as
the components of the BPMS solution adopted and implemented by Chubb do Brasil for
managing this process.
Keywords: Process Management; Business Process; Business Process Management System;
BPMS; Insurance Sector

RESUMO
A tecnologia da informao que corrobora com a implementao da abordagem administrativa
da gesto por processos denomina-se Business Process Management System (BPMS). Os
principais componentes do framework da soluo BPMS so: repositrio de definio do
De Sordi,J.O., Spelta,A. G.
Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management
72
processo, repositrio de instncias do processo, gerenciador de transao, framework de
conectores, motor do processo e middleware. Neste artigo, so definidos e caracterizados os
componentes que constituem o framework da soluo tecnolgica BPMS, bem como o papel e a
importncia de cada um destes. O mtodo adotado para abordar estes tpicos foi o estudo de
caso, que apresenta e analisa a implementao da soluo BPMS em uma empresa de seguros:
Chubb do Brasil. No estudo do caso, o processo Tratar ocorrncia de sinistro com resseguro
descrito e caracterizado, bem como os componentes da soluo BPMS adotados e
implementados pela Chubb do Brasil para sua gesto.
Palavras-chave: Gesto por Processos; Processo de Negcio; Sistema de Gesto por Processos
de Negcios; BPMS; Segmento de Seguros.

UM BREVE HISTRICO DA TECNOLOGIA DA INFORMAO APLICADA
AOS NEGCIOS

Nas dcadas de 60, 70 e 80 predominou o desenvolvimento de sistemas de
informao sob medida, voltado ao atendimento de necessidades especficas de cada
organizao. A grande maioria destes sistemas era transacional, denominados como
sistemas OLTP (on-line transaction processing) ou TPS (transaction processing
system), ou seja, transaes de negcios eram realizadas sob a responsabilidade de uma
determinada rea funcional da empresa (LAUDON e LAUDON, 2002, p. 40). Isto
perceptvel analisando as denominaes atribudas aos sistemas desse perodo, que
recebiam o nome de uma rea funcional, como os sistemas de recursos humanos,
materiais e contabilidade, ou de um subgrupo de atividades realizadas por uma dessas
reas, como o sistema de folha de pagamento ou de planejamento e controle da
produo.
Na dcada de 80, as software-houses desenvolveram um novo produto,
denominado workflow, que objetivava atender os fluxos de trabalhos no contemplados
no conjunto de algoritmos dos sistemas TPS. As ferramentas workflow apresentavam
como principais caractersticas: a facilidade de permitir que cada usurio definisse as
atividades que compem o fluxo de trabalho; a seqncia de execuo destas
(roteirizao); eventos de incio, trmino, suspenso e cancelamento de cada atividade.
O grande inconveniente do tradicional workflow dessa poca era o esforo exigido para
agregar algoritmos de softwares j existentes; praticamente tudo que fosse instruo de
cdigo (software) para execuo e gerenciamento do processo era desenvolvido dentro
da prpria ferramenta workflow. Na prtica, aproveitava-se muito pouco das instrues
j existentes na organizao na forma de software.
A partir do incio da dcada de 90, passou a predominar o modelo da compra e
implementao de sistemas desenvolvidos por software-houses, projetados objetivando
atender o maior nmero possvel de empresas. Estes softwares foram denominados
como pacotes ou softwares de prateleira (on-the-shelf software), por serem
reproduzidos em quantidade e terem seus manuais e as mdias que o armazenavam,
acondicionados em caixas, expostas nas prateleiras das reas de informtica das
empresas usurias. Os pacotes tambm foram projetados para atender os trabalhos ou
parte deles desempenhados por uma ou mais reas funcionais.
importante ressaltar que os sistemas de informao, tanto os desenvolvidos
sob medida quanto os pacotes, acompanharam historicamente a estrutura
Anlise de Componentes da Tecnologia de Business Process Management System (BPMS) sob a
Perspectiva de um Caso Prtico


Vol.4, No. 1, 2007, p. 71-94
73
organizacional e a abordagem administrativa predominante da poca do seu
desenvolvimento. Nestes cinqenta anos de tecnologia da informao aplicada aos
negcios, a modificao organizacional mais profunda ocorreu em meados da dcada de
90, quando Hammer e Davenport propuseram uma nova abordagem administrativa: a
gesto por processos de negcios ou business process management (BPM) (HAMMER,
1994; DAVENPORT, 1993). O mtodo inicialmente proposto para implementao da
gesto por processos nas organizaes a reengenharia no se mostrou adequado por
diversas razes. Em um segundo momento, ela foi introduzida por outros mtodos no
to radicais quanto o primeiro, destacando-se o mtodo contnuo e gradual de redesenho
de processos.
A gesto por processos de negcios est inserida em um novo contexto
empresarial constitudo pelas organizaes horizontais (flat organizations) que
trabalham em redes colaborativas e apresentam como caractersticas: maior nvel de
autonomia aos funcionrios (enpowerment), menor quantidade de nveis hierrquicos
separando os grupos de funcionrios, reduo das interferncias e impedncias entre
reas funcionais por meio de trabalhos organizados e geridos por meio de equipes
multifuncionais, entre outras caractersticas (OSTROFF, 1999). As principais
caractersticas diferenciais entre as empresas organizadas por processos e as demais,
organizadas por funes, esto descritas na Tabela 1.

caractersticas analisadas
organizao functional
(vertical)
organizao por processos
(horizontal)
alocao de pessoas
agrupadas junto aos seus
pares em reas funcionais
times de processos envolvendo
diferentes perfis e habilidades
autonomia operacional
tarefas executadas sob rgida
superviso hierrquica
fortalece a individualidade dando
autoridade para tomada de decises
avaliao de desempenho
centrada no desempenho
funcional do indivduo
centrada nos resultados do processo
de negcio
cadeia de comando
forte superviso de nveis
hierrquicos superpostos
fundamentada na negociao e
colaborao
Capacitao dos indivduos
voltada ao ajuste da funo
que desempenham /
especializao
dirigido s mltiplas competncias
da multi-funcionalidade /
empowerment
escala de valores da organizao
metas exclusivas de reas
geram desconfiana e
competio entre as reas
comunicao e transparncia no
trabalho gerando clima de
colaborao mtua
estrutura organizacional
estrutura hierrquica,
departamentalizao / vertical
fundamentada em equipes de
processos / horizontal
medidas de desempenho
foco no desempenho de
trabalhos fragmentados das
reas funcionais
viso integrada do processo de
forma a manter uma linha de
agregao constante de valor
natureza do trabalho repetitivo e com escopo bastante diversificado, voltado ao
De Sordi,J.O., Spelta,A. G.
Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management
74
bastante restrito / mecanicista conhecimento / evolutivo-
adaptativo
Organizao do trabalho
em procedimentos de reas
funcionais / mais linear
por meio de processos
multifuncionais / mais sistmico
Relacionamento externo
pouco direcionado, maior
concentrao no mbito
interno
forte incentivo por meio de
processos colaborativos de
parcerias
Utilizao da tecnologia
sistemas de informao com
foco em reas funcionais
integrao e orquestrao dos
sistemas de informao
Fonte: adaptado de Monteiro (2005)
Tabela 1 Caractersticas diferenciais entre organizaes horizontais e verticais

A percepo do trabalho atravessando as diversas reas funcionais para executar
um macro-processo (tambm denominado de processo de negcio), trouxe uma nova
demanda aos que implementam a tecnologia da informao nas organizaes: como
integrar os diversos programas e sistemas de informao existentes nas reas funcionais,
a fim de operarem em sincronia com a arquitetura dos novos processos de negcios, da
nova viso de gesto requerida pelas organizaes?
Na prtica, os principais componentes lgicos por trs desse desafio so muito
similares aos utilizados no desenvolvimento da lgica do workflow na dcada de 80. A
maior diferena est na existncia hoje de ferramentas para integrao de softwares, que
permitem a comunicao entre os diversos softwares existentes nas reas funcionais.
Entre essas ferramentas destacam-se: o Enterprise Application Integration (EAI) e o
middleware (RUH, 2001), as quais so utilizadas para composio de plataformas
padro para integrao entre sistemas de informao, que conciliam diferentes tcnicas
de comunicao, como: troca de mensagens, chamadas a programas (remote procedure
call), troca de arquivos, replicao de dados e transformao de dados (CHAPPELL,
2004, p. 1).
A recente conjuno dos algoritmos existentes nas ferramentas para integrao
entre softwares (EAI e middleware) e daqueles disponveis nas ferramentas de
gerenciamento e controle dos fluxos de trabalho (workflow) foi o evento motivador para
constituio de uma nova ferramenta para gesto dos extensos, complexos, duradouros e
dinmicos processos de negcios, denominada de Business Process Management
System (BPMS) (FISCHER, 2004, p. 304).
Por ser uma ferramenta tecnolgica bastante recente, o BPMS ainda pouco
compreendido pelos profissionais de informtica e, conseqentemente pelas prprias
organizaes (BURLTON, 2001, p.1). Tal dificuldade a motivao do presente artigo,
que tem por objetivo: discutir e apresentar os componentes do software BPMS,
pretendendo gerar maior clareza e entendimento sobre os potenciais dessa nova
ferramenta em colaborar com a gesto dos processos de negcios, os quais
proliferam rapidamente, no apenas no contexto interno das organizaes, mas tambm
nas cadeias colaborativas.

Anlise de Componentes da Tecnologia de Business Process Management System (BPMS) sob a
Perspectiva de um Caso Prtico


Vol.4, No. 1, 2007, p. 71-94
75
METODOLOGIA DA PESQUISA

A discusso e apresentao dos conceitos e principais componentes da
tecnologia BPMS neste artigo dar-se-o em dois estgios: na prxima seo de texto
apresentar-se- a fundamentao terica da tecnologia BPMS e, nas sees seguintes,
ser a vez de uma experincia prtica ocorrida em uma organizao, para que facilite a
exposio e descrio dos componentes da arquitetura tecnolgica da ferramenta
BPMS.
Para conceituao da tecnologia BPMS e discusso dos componentes de sua
arquitetura, utilizaram-se dois mtodos cientficos: a pesquisa bibliogrfica e a anlise
de um caso prtico. O primeiro para descrever os conceitos da tecnologia BPMS e o
segundo como meio de ilustrar a aplicao prtica dos diversos componentes da
tecnologia BPMS operando de forma integrada na execuo de trabalhos concretos do
dia-a-dia de uma grande organizao.
Duas razes justificam o mtodo de estudo de caso adotado para apresentar e
discutir os componentes da arquitetura de software BPMS: o entendimento de que ele
mais atraente e compreensvel ao pblico leitor; segundo, porque o tema BPMS
apresenta-se carente, tanto em dados como em teorias, o que conforme Yin (1994)
constitui indicao para uso do mtodo de pesquisa de estudo de caso.
A busca por uma empresa que estivesse em estgio avanado de implantao de
um BPMS foi realizada atravs de consultas rede de contatos acadmicos e
profissionais dos pesquisadores. Identificada a primeira empresa, entrou-se em contato
com a administrao da rea de informtica, que concordou em prestar as informaes
necessrias. A coleta de dados foi realizada atravs de um conjunto de trs entrevistas
com executivos e profissionais da rea de informtica da empresa. As duas primeiras
entrevistas no foram estruturadas e buscaram identificar o contexto da empresa, as
caractersticas do sistema BPMS utilizado e as mudanas produzidas nos processos da
empresa pela sua implantao. A ltima entrevista, por intermdio de um protocolo,
visou esclarecer inmeros detalhes sobre os processos suportados pelo sistema BPMS e
os benefcios obtidos com a implantao. As entrevistas foram gravadas e transcritas
para anlise detalhada pelos pesquisadores. O texto final do relatrio da pesquisa foi
enviado aos profissionais de informtica da empresa e validado por meio de contatos
telefnicos.


A ARQUITETURA DO BUSINESS PROCESS MANAGEMENT SYSTEM (BPMS)

Um importante aspecto conceitual diferenciar a abordagem administrativa da
gesto por processos, aquela praticada pelas organizaes horizontais, denominada de
De Sordi,J.O., Spelta,A. G.
Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management
76
business process management (BPM), da tecnologia que apia sua implementao: o
business process management system (BPMS). Segundo Schick (2006, p.4), BPM a
habilidade de entender e controlar as muitas partes de um processo complexo. Segundo
Hedge III (2005, p.52), o BPMS uma plataforma de software que permite ao usurio
projetar, executar e gerenciar um completo processo de negcio, na sua ntegra
utilizando-se de um nico motor.
Antes de apresentar e discutir em profundidade os componentes do BPMS -
objeto central da pesquisa - importante compreender a arquitetura da soluo BPMS.
A apresentao desta arquitetura se inicia com a importncia da disponibilidade de um
eficaz ambiente para integrao entre sistemas de informao.
O modelo conceitual do BPMS valoriza os investimentos j realizados em
softwares pelas organizaes envolvidas com o processo de negcio, diferentemente da
estratgia da reengenharia de uma dcada atrs, que apregoava o descarte e substituio
dos sistemas de informao legados pelo sistema ERP. No modelo conceitual BPMS, os
sistemas de informao legados, hospedados em diferentes ambientes computacionais,
continuam a executar as operaes necessrias ao processo de negcio, conforme se
pode observar na camada ambientes computacionais da Figura 1. Estes sistemas
legados so coordenados (orquestrados) pelo ambiente de gesto do processo (AGP)
do BPMS. O modelo conceitual do BPMS no est fundamentado na construo de
softwares ou de mdulos de sistemas de informao, mas na juno e orquestrao de
partes de softwares j disponveis (AALST, 2004).
O acionamento ou cancelamento de um sistema de informao legado via BPMS
ocorre segundo as regras do processo de negcio embutidas no AGP, utilizando-se de
conectores e adaptadores para comunicao com os sistemas de informao. Os
conectores e adaptadores esto disponveis no ambiente de integrao tecnolgica
(AIT).
Uma pesquisa recente analisou mais de cem sistemas BPMS disponveis no
mercado e apontou trs aspectos que os diferenciam substancialmente: a capacidade de
monitoramento, a capacidade de automao e a capacidade de integrao entre sistemas
de informao. Estas diferenas so to evidentes, que so utilizadas inclusive para
delimitarem as diferentes categorias de sistemas BPMS (WORTHEN, 2004).
Anlise de Componentes da Tecnologia de Business Process Management System (BPMS) sob a
Perspectiva de um Caso Prtico


Vol.4, No. 1, 2007, p. 71-94
77
















Fonte: adaptado de DE SORDI (2005)
Figura 1 Principais entidades do modelo conceitual do BPMS

A capacidade de monitoramento e automao do BPMS destacadas por Worthen (2004)
melhor explicitada pela arquitetura BPMS desenvolvida pelo Business Process

Management Initiative ([Link]), descrita na Figura 2. O [Link]
constitudo por empresas da rea de tecnologia da informao e institutos de pesquisa
que esto interessados no desenvolvimento da tecnologia BPMS. A misso do
[Link] promover, desenvolver e disseminar o BPMS, estabelecendo padres,
desenvolvendo especificaes abertas e dando assistncia s empresas desenvolvedoras
de ferramentas, tcnicas e metodologias.
A arquitetura do BPMS desenvolvida pelo [Link] abrange todo o ciclo de
vida do processo de negcio, desde sua descoberta, seus ciclos de aprimoramento at o
seu descarte. O Quadro 1 descreve as funcionalidades necessrias ao BPMS segundo a
arquitetura da soluo BPMS considerada pelo [Link].
De Sordi,J.O., Spelta,A. G.
Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management
78

















Fonte: LACHAL (2004)
Figura 2 Arquitetura do BPMS segundo o [Link]

A arquitetura descrita pelo [Link] no muito esclarecedora quanto
conexo dos sistemas legados com o sistema BPMS; isto fica mais evidente no modelo
conceitual de De Sordi (2005). Por outro lado, o que De Sordi (2005) denominou de
Ambiente de Gesto do Processo (AGP) est muito encapsulado, tratado em um nvel de
detalhamento muito maior na arquitetura BPMS desenvolvida pelo [Link].
Os conceitos apresentados at aqui permitem um entendimento geral dos
fundamentos, da proposio e da arquitetura do BPMS. Para entendimento e discusso
de alguns aspectos crticos do BPMS, necessrio compreender a operao interna da
ferramenta BPMS. Para isso, pede-se um maior nvel de detalhamento de cada um dos
seus componentes internos do BPMS, que sero analisados na seo cinco. Para
subsidiar o detalhamento e explanao dos componentes do BPMS no nvel de
detalhamento necessrio, na prxima seo do texto, ser exposto um estudo de caso
que ilustrar a apresentao e o desenvolvimento das anlises dos componentes BPMS a
ser realizado na seo cinco.

Descoberta, Especificao e Projeto do processo: a descoberta significa tornar evidente como o
processo funciona, identificando a lgica dos softwares envolvidos (engenharia reversa de algoritmos de
software) e os processos manuais envolvidos. Alteraes do projeto precedidas por simulaes, permitem
empresa analisar e aprender sobre as possibilidades do processo, remodelando-o, quando conveniente.
O projeto deve permitir reestruturar rapidamente os processos em resposta presso competitiva e s
Ferramentas de
Identificao,
Especificao e
Projeto do Processo
Ferramentas de
Configurao e
Instalao do
Processo
Ferramentas de
Monitoramento,
Anlise e
Aprimoramento do
Processo
Ferramentas de
Gerenciamento
Workflow
Softwares e
Aplicaes
da Empresa
Usuria do
BPMS
EAI
Gesto de
Contedo
Motor de Execuo dos Processos
B
P
M
S
Anlise de Componentes da Tecnologia de Business Process Management System (BPMS) sob a
Perspectiva de um Caso Prtico


Vol.4, No. 1, 2007, p. 71-94
79
oportunidades de negcio. Composio e decomposio de processos uma caracterstica muito
importante ao BPMS, assim como a capacidade de reutilizao de processos, atravs de estruturas de
generalizao e especializao.
Configurao e Instalao do processo: significa entregar rapidamente e de forma fcil o novo processo
para todos os envolvidos, pessoas, aplicaes e outros processos. Bons sistemas BPMS devem ser
capazes de entregar o novo processo, com pouca ou nenhuma necessidade de programao atrelada.
Monitoramento, Anlise e Aprimoramento do processo: significa identificar pontos de melhoria no
processo, olhar para o processo em toda sua extenso, inclusive a que extrapola os limites da empresa,
apontando gargalos, situaes conflitantes e inconsistncias do processo. Em termos de manuteno
fundamental permitir alteraes dos limites do processo, quanto ao que se considera sub-processo pblico
ou privado, permitindo alterar o escopo de interao das pessoas dentro do escopo do processo. As
manutenes do processo devem ocorrer de forma transparente para os usurios, sem interrupes no
fluxo de trabalho.
Gerenciamento do processo: significa realizar as medies do processo, identificando o seu
desempenho. A anlise prov uma viso ampla dos recursos envolvidos nos processos da empresa.
Ferramentas analticas podem indicar oportunidades de melhoria do processo. Uma das principais
caractersticas do gerenciamento do processo a capacidade de identificar a ocorrncia de excees do
processo.
Execuo do processo: significa assegurar que o processo executado por todos os participantes
pessoas, outras organizaes, sistemas e outros processos. Envolve o gerenciamento das transaes
distribudas, utilizando-se de novos e antigos sistemas de informao, atravs de processos complexos e
encadeados. A execuo no deve ser afetada por distrbios ocorridos em aplicaes complementares ou
em tecnologias adjacentes. O processamento distribudo deve ocorrer independente de ambiente
tecnolgico das aplicaes.
Quadro 1 Fases do ciclo de vida do processo suportadas pelo BPMS (SMITH, 2002)

ANLISE DO CASO DE IMPLEMENTAO DO SISTEMA BPMS

A empresa Chubb no Brasil

A Chubb uma das maiores seguradoras norte-americanas, est presente em 33
pases e opera 132 escritrios. Fundada em 1882, em Nova York, EUA, oferecia
inicialmente seguros martimos, mas logo passou a oferecer tambm seguros comerciais
e pessoais Em 1967, a empresa abriu seu capital e formou uma holding denominada
The Chubb Corporation, com sede em Nova J ersey, EUA. No Brasil, as operaes
foram iniciadas em 1973, com a aquisio do controle acionrio da mais antiga
seguradora na Amrica Latina, a Argos Fluminense. Em 1992, a Argos passou a
denominar-se Chubb do Brasil Cia de Seguros. No texto utilizaremos a denominao
Chubb do Brasil. Atualmente, a operao Brasil tem sua matriz em So Paulo, com
sucursais em Belo Horizonte, Braslia, Curitiba, Rio de J aneiro e Porto Alegre,
operando com seguros pessoais e comerciais. Na linha de seguros pessoais, o foco so
os seguros de: automveis de alto valor, embarcaes, jatos executivos e patrimnio
pessoal, como obras de arte, antiguidades e colees. O portiflio de seguros comerciais
De Sordi,J.O., Spelta,A. G.
Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management
80
abrange: operaes martimas, transportes (todos os modais), seguros de vida em grupo,
riscos empresariais diversos, seguros massificados, entre outros. A Chubb do Brasil
conta com cerca de 250 funcionrios e vem constando repetidamente na lista publicada
anualmente pela revista Exame, como uma das melhores empresas para se trabalhar no
Brasil (CHUBB DO BRASIL, 2005a).

Origens da iniciativa de melhoria de processos por meio do BPMS na Chubb do
Brasil

Em 2003, a Chubb do Brasil, para aumentar sua competitividade, deu incio ao
projeto Seis Sigma, que gerou diversas iniciativas voltadas melhoria de seus
processos. Neste mesmo perodo, a Chubb dos Estados Unidos conclua um estudo
sobre as possibilidades oferecidas pela tecnologia de Business Process Management
System (BPMS) na operao, suporte e melhoria de processos. Deste estudo, derivou-se
a recomendao corporativa pela utilizao dos softwares BPMS, que culminou com a
homologao de uma soluo corporativa: o sistema BPMS denominado e-Work,
desenvolvido pela empresa inglesa Metastorm. Um contrato corporativo foi firmado
entre a Chubb e a Metastorm oferecendo facilidades para aquisio de licenas do
software e-Work s diversas unidades da Chubb que julgassem oportuno sua
implementao.
O principal foco do projeto Seis Sigma era a rea de Operaes da Chubb. Na
estrutura organizacional da empresa, esta rea fazia parte da Diretoria de Operaes e
Tecnologia, tambm responsvel pela adoo de novas tecnologias. Isso facilitou muito
a visualizao de oportunidades de uso da tecnologia BPMS, bem como sua
implementao e evoluo, pois a rea responsvel pela implementao da soluo era
tambm a principal rea usuria.
Entendendo que a tecnologia BPMS tinha grande potencial para impulsionar as
iniciativas de melhoria de processos almejadas pelo projeto Seis Sigma, a Diretoria de
Operaes e Tecnologia da Chubb do Brasil, iniciou em 2003, um projeto piloto para
aprimoramento de processo por meio da tecnologia BPMS que teve como finalidade
maior o processo cotao de seguros. A experincia foi muito bem-sucedida e
motivou a criao de um programa para implementao da tecnologia BPMS em outros
processos. O sistema BPMS passou a ser entendido como o principal habilitador para
aprimoramento de processos, confundindo-se muitas vezes com a prpria iniciativa do
projeto Seis Sigma. Em agosto de 2005, dez processos j haviam sido aprimorados com
o auxlio da tecnologia BPMS e outros oito processos estavam com implementao em
andamento, com trmino previsto para o final de 2005.

Abordagem para seleo de processos a serem aprimorados via BPMS

Havia a necessidade de se definir critrios para seleo dos processos a serem
trabalhados pela equipe do projeto Seis Sigma, considerando-se que os bons resultados
alcanados pelo projeto piloto despertaram o interesse de diversos grupos internos da
organizao. Os critrios adotados pela Chubb foram: a) a iniciativa de aprimoramento
Anlise de Componentes da Tecnologia de Business Process Management System (BPMS) sob a
Perspectiva de um Caso Prtico


Vol.4, No. 1, 2007, p. 71-94
81
do processo deveria assegurar alto retorno financeiro ou alteraes significativas no
ambiente de negcios (ganhos qualitativos); b) o processo deveria ser curto e de baixa
complexidade ou, caso fosse um processo extenso e complexo, que pudesse ser
implementado em etapas, ampliando gradativamente a abrangncia do processo
medida que resultados positivos fossem alcanados. Portanto, a estratgia de melhoria
de processos adotada foi a de implantar melhorias graduais, ao invs de promover
mudanas radicais e de amplo escopo.
Descrevemos, a seguir, o processo Tratar ocorrncia de sinistro com
resseguro, que j foi aprimorado com o auxlio da tecnologia de BPMS. Alm de
descrever a finalidade, a operao do processo, e os pontos em que a tecnologia BPMS
foi aplicada, tambm se descrevem os principais ganhos, tanto qualitativos quanto
quantitativos, resultantes para o negcio da Chubb do Brasil.

O processo Tratar ocorrncia de sinistro com resseguro

A legislao brasileira que regulamenta a atividade de companhias seguradoras
exige que os seguros de alto valor sejam realizados em conjunto com uma entidade de
mbito federal, chamada Instituto de Resseguros do Brasil (IRB). Devido a essa
exigncia, as seguradoras repassam ao IRB um percentual do prmio pago pelo
segurado, que varivel conforme o valor e o tipo do item segurado. Em caso de
sinistro, em contrapartida, o IRB solidrio com a seguradora, assumindo a
responsabilidade por um percentual da indenizao prevista pelo seguro. Assim, quando
ocorre um sinistro com resseguro, a seguradora deve informar ao IRB do ocorrido, para
que o instituto se prepare financeiramente para fazer os pagamentos devidos
seguradora. Posteriormente, a seguradora obtm dados mais completos sobre o sinistro,
rene documentos e realiza os pagamentos da indenizao ao segurado, o que pode
acontecer em uma ou vrias parcelas. A cada pagamento efetuado, o IRB deve ser
informado para que efetue os pagamentos dos percentuais devidos seguradora. A
Figura 3 apresenta um diagrama de processo que descreve as atividades realizadas para
execuo do processo Tratar ocorrncia de sinistro com resseguro.
O objetivo principal da implementao da tecnologia BPMS no processo Tratar
ocorrncia de sinistro com resseguro foi reduzir o tempo para envio de notificaes ao
IRB, tanto da ocorrncia do sinistro como da realizao de um pagamento ao segurado.
Em conseqncia, dois benefcios seriam proporcionados: primeiro, a Chubb no estaria
sujeita s multas aplicadas pelo IRB quando a notificao de sinistro ocorresse fora do
prazo regulamentar estipulado; segundo, seria reduzido o prazo para recebimento do
valor devido pelo IRB, resultando em ganhos financeiros Chubb. Para a Chubb, a
importncia deste processo percebida pela total de ocorrncias em um ms: uma
mdia de 80 a 100 avisos de sinistro por dia, sendo que 10% destes possuem resseguro
junto ao IRB, ou seja, aproximadamente 180 sinistros por ms com resseguro.
Apresenta-se, a seguir, a descrio detalhada das atividades realizadas pelo
De Sordi,J.O., Spelta,A. G.
Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management
82
processo Tratar ocorrncia de sinistro com resseguro. Para facilitar o entendimento do
processo, suas atividades foram subdivididas em dois sub-processos: Notificar
ocorrncia de sinistro ao IRB e Resgatar valor do resseguro. As atividades descritas
foram resultantes dos trabalhos de aprimoramento de processos por meio da tecnologia
BPMS.













Figura 3 Diagrama do processo Tratar ocorrncia de sinistro com resseguro

4.4.1 Atividades do sub-processo Notificar ocorrncia de sinistro ao IRB


Os atores do sub-processo Notificar ocorrncia de sinistro ao IRB, seus eventos
percebidos, a seqncia de ocorrncia destes, bem como o tempo entre eventos, esto
descritos no diagrama de interao apresentado na Figura 4. Os textos a seguir so
identificados por letras, estabelecendo assim uma relao entre os eventos do sub-
processo descritos na Figura 4 e os textos que o descrevem.

a. O processo inicia-se quando um aviso de ocorrncia de sinistro recebido pelo
departamento responsvel por sinistros (Departamento de Sinistros); isso pode
ocorrer de diferentes formas: via telefone, via fax e via e-mail. Tal evento
caracterizado pela atividade A da Figura 4;
b. Aps anlise preliminar do Departamento de Sinistros, os dados referentes ao seguro
e ao sinistro so digitados no Sistema de Controle de Sinistros (Sistema SIN)
processado em um ambiente computacional de grande porte (plataforma
mainframe);
c. Diariamente, no final do dia (evento temporal), um software agente copia para a
base de dados do Sistema BPMS os dados de sinistros registrados no Sistema SIN,
criando uma instncia de processo para cada um dos sinistros;
s
e
g
u
r
a
d
o
s
e
g
u
r
a
d
o
r
a

C
h
u
b
b
acatar
notificao
de sinistro
notificar
pagamento feito
ao segurado
I
R
B
d
e
p
t
o
s
i
n
i
s
t
r
o
d
e
p
t
o
O
S
D
d
e
p
t
o
r
e
s
s
e
g
u
r
o
verificar se
h contrato de
resseguro
notificar
sinistro com
resseguro
coletar
dados do
sinistro
autorizar
pagamento
do segurado
encaminhar
documentos
do sinistro
acompanhar
pagamento
do resseguro
informar
ocorrncia
sinistro
provisionar
recurso
financeiro
tratar
reembolso
seguradora
recepcionar
documentos
do sinistro
Anlise de Componentes da Tecnologia de Business Process Management System (BPMS) sob a
Perspectiva de um Caso Prtico


Vol.4, No. 1, 2007, p. 71-94
83
d. Uma vez registrado uma instncia de sinistro no Sistema BPMS, cria-se
automaticamente na lista de trabalho (To do List) do profissional da rea
responsvel pelo seguro, departamento conhecido internamente pelo acrnimo OSD
(Operational Services Department), uma tarefa que consiste em verificar o status do
resseguro, ou seja, se h ou no um contrato de resseguro para aquele sinistro;
e. Caso haja resseguro, o valor do percentual a ser restitudo pelo IRB informado ao
Sistema BPMS via uma interface grfica homem-mquina (tela de sistema),
desenvolvida no prprio ambiente de ferramentas para interao do Sistema BPMS.
Caso no haja resseguro, a instncia do processo criada no Sistema BPMS,
conforme descrita na atividade C, assinalada como encerrada;


















Figura 4 Diagrama de interao sub-processo Notificar ocorrncia de sinistro ao IRB

f. Em havendo o contrato de resseguro, o Sistema BPMS cria automaticamente uma
tarefa na lista de trabalho do Departamento de Resseguros para que a notificao ao
IRB seja efetuada;
g. O Departamento de Resseguros notifica o IRB, atravs da digitao de dados do
sinistro em um sistema de informao do prprio IRB Sistema IRB - disponvel
via Internet (web application);
SISTEMA
BPMS
informa
sinistro (A)
DEPTo. OSD
cria tarefa de verificao
de resseguro (D)
informa status do
resseguro (E)
DEPTo.
RESSEGUROS
cria tarefa de notificao do IRB (F)
DEPTo.
SINISTROS
SISTEMA
SIN
SISTEMA
IRB
A
T
O
R
E
S
E
V
E
N
T
O
S

&

T
E
M
P
O
S
informa dados sobre o
sinistro (B)
notifica (G)
informa percentual de resseguro (J)
informa nmero protocolo do
aviso encaminhado ao IRB (I)
SOFTWARE
AGENTE
Horas
Dias ou
semanas
Segundos
LEGENDA
Escala de
Tempo:
Horas
Dias ou
semanas
Segundos
LEGENDA
Escala de
Tempo:
... cria instncia (C)
mmero
protocolo (H)
consulta dados e ... (C)
CLIENTE
CHUBB
De Sordi,J.O., Spelta,A. G.
Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management
84
h. O Sistema IRB devolve ao Departamento de Resseguros da Chubb um nmero de
protocolo que comprova a data e horrio da notificao do sinistro;
i. O Departamento de Resseguros digita no Sistema BPMS o nmero do protocolo
recebido pelo IRB;
j. Finalizando o sub-processo, o Departamento de Resseguros digita o percentual do
resseguro no sistema SIN.

Atividades do sub-processo Resgatar valor do resseguro

Os atores do sub-processo Resgatar valor do resseguro, seus eventos
percebidos, a seqncia de ocorrncia destes, bem como o tempo entre eventos, esto
descritos no diagrama de interao apresentado na Figura 5. Os textos a seguir so
identificados por letras, estabelecendo, assim, uma relao entre os eventos do sub-
processo descritos na Figura 5 e os textos que o descrevem.

k. O processo inicia-se quando o Departamento de Sinistros digita no Sistema SIN o
valor da indenizao a ser paga ao segurado, que poder ocorrer por meio de uma
ou mais parcelas;
l. Diariamente, o Sistema SIN gera um arquivo contendo dados sobre pagamentos de
sinistros a serem efetivados, utilizado como insumo (input) pelo Sistema de Contas
a Pagar para criao de instncias de pagamentos a serem realizados;
m. Um Software Agente extrai da base de dados do Sistema de Contas a Pagar os
pagamentos que esto sendo realizados no dia e os insere no Sistema BPMS;
n. O Sistema BPMS calcula o valor a ser recuperado pelo resseguro e cria uma tarefa
no To do list do Departamento de Resseguros, para que este notifique o IRB;
o. O Departamento de Resseguros notifica ao IRB sobre a necessidade da contrapartida
financeira dessa entidade, para o pagamento do sinistro, atravs do encaminhamento
de um dossi sobre este por meio de um mensageiro (remessa fsica de
documentos);
p. A recepo do IRB fornece um nmero de protocolo que registra formalmente a
notificao feita por meio da entrega dos documentos;
q. O Departamento de Resseguros digita no Sistema BPMS o nmero do protocolo de
entrega informado pelo IRB quando da entrega do dossi.
Anlise de Componentes da Tecnologia de Business Process Management System (BPMS) sob a
Perspectiva de um Caso Prtico


Vol.4, No. 1, 2007, p. 71-94
85

















Figura 5 Diagrama de interao do sub-processo Resgatar valor do resseguro

Ganhos proporcionados ao processo Tratar ocorrncia de sinistro com resseguro

A Chubb do Brasil constatou diversos benefcios no processo Tratar ocorrncia
de sinistro com resseguro em decorrncia da adoo da tecnologia BPMS no suporte a
sua operao. O ganho mais expressivo foi na reduo dos prazos para notificao do
IRB da ocorrncia de sinistro com resseguro. Na Figura 6, nota-se a expressiva reduo
neste prazo, de 107 dias para 27 dias. Na situao anterior introduo da tecnologia
BPMS, havia riscos de perda das fichas em que eram registrados os dados sobre o
sinistro e no havia controle preciso sobre a situao de cada sinistro. O processo era
muito burocrtico, havia documentos circulando com carimbos e assinaturas e as vrias
reas envolvidas mantinham planilhas particulares de controle.

SISTEMA
BPMS
DEPTo.
RESSEGUROS
DEPTo.
SINISTROS
SISTEMA
SIN
SISTEMA
CONTAS A
PAGAR
A
T
O
R
E
S
E
V
E
N
T
O
S

&

T
E
M
P
O
S
informa dados sobre
pagamento sinistro (K)
RECEPO
IRB
SOFTWARE
AGENTE
cria pagamento (L)
... insere pagamento (M)
calcula pagamento e cria
tarefa de recuperao (N)
solicita pagamento via
envio fsico do dssie (O)
nmero protocolo (P)
informa nmero protocolo do
aviso encaminhado ao IRB (Q)
Horas
Dias ou
semanas
Segundos
LEGENDA
Escala de
Tempo:
Horas
Dias ou
semanas
Segundos
LEGENDA
Escala de
Tempo:
consulta dados e ... (M)
De Sordi,J.O., Spelta,A. G.
Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management
86
Periodo
N
r
o

d
e

d
i
a
s
2
0
0
5
-
0
7
2
0
0
5
-
0
6
2
0
0
5
-
0
5
2
0
0
5
-
0
4
2
0
0
5
-
0
3
2
0
0
5
-
0
2
2
0
0
5
-
0
1
2
0
0
4
-
1
2
2
0
0
4
-
1
0
2
0
0
4
-
0
9
2
0
0
4
-
0
8
2
0
0
4
-
0
7
2
0
0
4
-
0
6
2
0
0
4
-
0
5
2
0
0
4
-
0
4
2
0
0
4
-
0
3
400
300
200
100
0
107,1
27,4
Periodo
N
r
o

d
e

d
i
a
s
2
0
0
5
-
0
7
2
0
0
5
-
0
6
2
0
0
5
-
0
5
2
0
0
5
-
0
4
2
0
0
5
-
0
3
2
0
0
5
-
0
2
2
0
0
5
-
0
1
2
0
0
4
-
1
2
2
0
0
4
-
1
0
2
0
0
4
-
0
9
2
0
0
4
-
0
8
2
0
0
4
-
0
7
2
0
0
4
-
0
6
2
0
0
4
-
0
5
2
0
0
4
-
0
4
2
0
0
4
-
0
3
400
300
200
100
0
107,1
27,4

Fonte: CHUBB DO BRASIL, 2005b
Figura 6 Prazo para notifcar o IRB antes e depois da implantao do sistema BPMS
Outro benefcio percebido foi o relativo reduo das multas aplicadas pelo IRB
em funo da emisso do Aviso de Ocorrncia de Sinistro aps o prazo regulamentar. A
reduo dessas despesas com multas, acrescidas dos ganhos financeiros em funo de se
ter a restituio do IRB mais cedo, proporcionou um ganho aproximado de R$ 200 mil
por ano.
Aprimoramento contnuo do processo outro fator percebido como resultante da
tecnologia BPMS. A maior visibilidade operacional do processo obtida por meio das
listas de tarefas (To do list), bem como da visibilidade gerencial das atividades
operacionais que acontece por meio das listas de controle (Watch list). Esta ltima lista
produz informaes instantneas sobre o total de instncias pendentes em cada
atividade, total de instncias j processadas, caminho crtico, entre outras. Estas
informaes so utilizadas para definio de eventos que podem acionar regras que
podem resultar, por exemplo, no disparo de envio de mensagens de alertas aos
executores e aos gerentes (ROSS, 2003). Tais informaes tornam todos mais bem
informados e comprometidos com relao ao processo; em conseqncia disso,
observou-se uma sensvel melhoria do processo.

EXEMPLIFICANDO OS COMPONENTES DO SISTEMA BPMS A PARTIR DO
CASO ANALISADO

Para discusso dos componentes do sistema BPMS, adotou-se o framework
proposto por Krafzig, Banke e Slama (2004), o qual est retratado na Figura 7.
Anlise de Componentes da Tecnologia de Business Process Management System (BPMS) sob a
Perspectiva de um Caso Prtico


Vol.4, No. 1, 2007, p. 71-94
87
Como uma ferramenta de gerenciamento e no de execuo do processo, o
sistema BPMS desempenha o papel de organizador e controlador. Tal caracterstica faz
com que muitos denominem o sistema BPMS como orquestrador do processo,
fazendo uma analogia direta ao importante trabalho desempenhado pelo maestro em
uma orquestra. Corroborando com essa perspectiva, temos que no caso estudado todas
as sadas do sistema BPMS, declaradas nas figuras 4 e 5, esto relacionadas
organizao e gesto do trabalho: informao D da Figura 4, notifica pessoal do OSD
sobre a necessidade de verificar se h resseguro para um determinado sinistro;
informao F da Figura 4, notifica pessoal do Departamento de Resseguros que estes
precisam comunicar ao IRB sobre a ocorrncia de um sinistro com resseguro;
informao N da Figura 5, notifica Departamento de Resseguros que a Chubb j
pagou o valor do seguro ao cliente, sendo, portanto, o momento de se cobrar a
contrapartida do IRB.
As regras que comandam o sistema BPMS a disparar cada uma das informaes
esto armazenadas no componente do BPMS denominado repositrio de definio de
processo. Neste componente, esto descritas as atividades, as seqncias de trabalho
possveis de ocorrerem, as regras para identificao de incio e trmino de cada
atividade, entre outras informaes importantes orquestrao do processo. Todas
essas informaes so introduzidas no sistema BPMS pelo analista de negcios, que
deve concentrar-se nos aspectos do processo e do ambiente de negcios, mesmo que no
seja um profundo conhecedor de linguagens de programao e dos demais recursos de
tecnologia da informao. O analista de negcios insere no sistema BPMS as
informaes relativas ao controle do processo de negcio por meio de diagramadores,
tambm conhecidos como ferramentas de desenho, conforme descrito na Figura 7 que
apresenta os diversos componentes do sistema BPMS.
As ferramentas de desenho so fundamentais para desenvolver a
especificao da lgica do processo de negcio. Diagramas de processo, como o
retratado na Figura 3; diagramas de interao, Figuras 4 e 5, so alguns exemplos
disponveis nas ferramentas BPMS. Descrio de regras de negcios, eventos e aes
podem ser especificados para diversos objetos dos diagramas, por exemplo, pode-se
definir para cada seta da Figura 3 input de um processo e output de outro o evento
necessrio para o seu disparo. As ferramentas de desenho armazenam e manipulam
dados do Repositrio de definio de processo.
Das instrues de controle do processo, inseridas pelo analista de negcios via
diagramadores e demais facilidades grficas oferecidas pelo sistema BPMS, gera-se o
cdigo executvel (software) a ser utilizado pelo sistema BPMS no acompanhamento do
processo. O cdigo fonte gerado segue os padres da tecnologia BPMS e denomina-se
business process modeling language (BPML). As rotinas de software BPML so
constantemente interpretadas e executadas pelo motor do processo, parte integrante
do sistema BPMS, conforme descrito na Figura 7.
De Sordi,J.O., Spelta,A. G.
Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management
88















Fonte: KRAFZIG, BANKE, SLAMA, 2004
Figura 7 Framework dos componentes da soluo tecnolgica BPMS

O sistema BPMS tambm permite facilidades para interao de pessoas. J
foram descritas vrias informaes do sistema para as pessoas/departamentos, faltando
descrever o fluxo inverso, das pessoas/departamentos para o sistema BPMS. Nas figuras
4 e 5, temos os seguintes fluxos: informao E da Figura 4, o departamento OSD
informa o valor percentual do total do seguro a ser restitudo pelo IRB; informao I
da Figura 4, o departamento de Resseguros informa o nmero de protocolo fornecido
pelo IRB quando do envio da notificao da ocorrncia de sinistro com resseguro;
informao Q da Figura 5, o departamento de Resseguros informa o nmero do
protocolo fornecido pelo IRB quando da entrega do dossi do sinistro. Todas essas
informaes so armazenadas no componente do BPMS denominado Repositrio de
instncias do processo, tambm descrito na Figura 7.
Os softwares que desempenham o papel do motor do processo so
processados diretamente sobre os dois repositrios de dados da soluo BMPS:
Repositrio de instncias do processo e Repositrio de definio de processo,
conforme descrito no framework do sistema BPMS apresentado na Figura 7. Deve-se
isso forte dependncia do motor do processo em ter acesso aos dados dessas duas
bases de dados para efetivamente poder controlar o processo. Exemplificaremos tal
dependncia, analisando um exemplo prtico do caso estudado. Inicialmente
descrevemos as operaes necessrias ao encaminhamento e controle do processo e,
posteriormente, apresentamos os contedos manipulados nos dois repositrios.
Descrio de algumas operaes necessrias ao encaminhamento e controle do
processo:
Repositrio de
Definio do
Processo
Repositrio de
Instncias do
Processo
Motor do Processo
(interpretadores BPML, BPEL4WS)
Gerenciador de
Transao
Framework de
Conectores
G
e
r
e
n
c
i
a
d
o
r

d
e

P
r
o
c
e
s
s
o
Aplicaes Transacionais
Middleware
Ferramentas
de Desenho
Instalao &
Configurao
Monitoramento
e Gerenciamento
Repositrio de
Definio do
Processo
Repositrio de
Instncias do
Processo
Motor do Processo
(interpretadores BPML, BPEL4WS)
Gerenciador de
Transao
Framework de
Conectores
G
e
r
e
n
c
i
a
d
o
r

d
e

P
r
o
c
e
s
s
o
Aplicaes Transacionais Aplicaes Transacionais
Middleware
Ferramentas
de Desenho
Ferramentas
de Desenho
Instalao &
Configurao
Instalao &
Configurao
Monitoramento
e Gerenciamento
Monitoramento
e Gerenciamento
Anlise de Componentes da Tecnologia de Business Process Management System (BPMS) sob a
Perspectiva de um Caso Prtico


Vol.4, No. 1, 2007, p. 71-94
89
Uma vez criada uma instncia de sinistro no sistema BPMS, evento percebido pela
chegada da informao C (descrita na Figura 4), deve-se notificar um dos
profissionais do departamento OSD para que se verifique a existncia ou no de um
contrato de resseguro para aquele sinistro. A regra para seleo do profissional do OSD
a realizar a consulta rotativa, ou seja, ser sempre o funcionrio que est h mais
tempo sem receber uma solicitao. A solicitao encaminhada ao profissional do OSD
est caracterizada pelo envio da informao D da Figura 4. Caso o funcionrio do
OSD que recebeu o pedido de verificao no responda em 24 horas, um e-mail de
alerta ser emitido caixa postal eletrnica do funcionrio. Aps isso, contam-se mais
24 horas e, em ainda no havendo um retorno, ser emitida uma notificao ao superior
do funcionrio e o sinistro a ser pesquisado ser transferido a um outro analista do
departamento OSD. Caso o departamento OSD informe haver contrato de resseguro,
aquela ocorrncia de sinistro assinalada como passvel de resseguro e o Departamento
de Resseguros ser acionado para recuperar o valor junto ao IRB.
No Repositrio de definio de processo esto armazenados os valores de
vrios parmetros necessrios para o controle do processo. O sistema BPMS apresenta
ao analista de negcios, de forma grfica e intuitiva, uma lista de variveis a serem
preenchidas para definio de uma regra de negcio, desde o evento que a inicia at a
sua concluso. No exemplo descrito, a chegada da informao C ao sistema BPMS
monitorada pela regra de negcio tratar nova ocorrncia de sinistro. Assim que uma
nova ocorrncia for identificada, a regra deve imediatamente enviar um e-mail ao
profissional do OSD. Ao invs de imediatamente poderia ser aps 24 horas ou
todo dia 15 do ms ou qualquer outra meno temporal que definida atravs de uma
varivel armazenada no Repositrio de definio de processo. Em termos de estrutura
de dados, h um detalhamento e especializao bastante grande para que o software
consiga tratar toda complexidade possvel de ser requerida. No exemplo, a definio de
enviar um e-mail ao funcionrio aps 24 horas sem resposta, a especificao do perodo
de tempo feita pelo assinalamento do valor numrico 24 para a varivel tempo de
espera e o contedo H para varivel unidade de medida, representando que se trata
de horas a quantidade de tempo informada. O encaminhamento do fluxo do processo,
por exemplo, do que fazer aps 24 horas sem resposta de um funcionrio, envolve
variveis que tambm esto com seus valores armazenados no Repositrio de definio
de processo.
A definio das configuraes (ou parametrizaes) do sistema BPMS ocorre
por meio do componente instalao e configurao descrito na Figura 7. a partir
destes componentes que dados so inseridos, alterados ou excludos do repositrio de
definio de processo. A arquitetura BPMS, desenvolvida pelo [Link], tambm cita
tal componente, no entanto, sem qualquer meno estrutura de dados, conforme pode
se observar na Figura 2.
No Repositrio de instncias do processo est assinalado o caminho j
percorrido por cada uma das instncias. No exemplo citado, uma instncia de ocorrncia
de sinistro pode ser percebida pelo sistema BPMS e estar em um dos seguintes estgios,
ou seja, posio de processamento dentro do fluxo do processo:
De Sordi,J.O., Spelta,A. G.
Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management
90
aguardando parecer do profissional do OSD;
aguardando parecer do profissional do OSD h mais de 24 horas;
aguardando parecer do profissional do OSD h mais de 48 horas;
encerrada por no haver resseguro;
aguardando notificao junto ao IRB;
aguardando pagamento do IRB;
encerrada por ter havido pagamento do IRB.
Cada informao que chega ou sai do BPMS tem seus fatos bsicos apontados
(gravados) no Repositrio de instncias do processo. Ao se ter o nmero identificador
de uma determinada instncia, rapidamente se sabe sua situao dentro do processo,
bastando acessar a ltima ocorrncia gravada no Repositrio de instncias do
processo. Pode-se afirmar que o Repositrio de instncias do processo trata dos
dados necessrios para operao e gerenciamento do processo (runtime).
Assim como acontece com a estrutura de dados do repositrio de definio de
processo, a arquitetura BPMS desenvolvida pelo [Link] no cita a estrutura de
dados utilizada para armazenar os dados do repositrio de instncias do processo,
conforme pode se observar na Figura 2. Nas concluses finais, desenvolve-se uma
anlise sobre a importncia dos profissionais envolvidos com a gesto por processos
(BPM) em compreenderem as estruturas de dados dos dois repositrios envoltos com a
soluo BPMS.
Retornando descrio dos componentes BPMS conforme framework proposto
por Krafzig, Banke e Slama (2004), retratado na Figura 7, observa-se o componente
monitoramento e gerenciamento. Este componente permite o acompanhamento e
gerenciamento do processo de diversas formas. Uma das mais interessantes e utilizadas
o painel de controle do processo, em que se observa o status de cada uma das
atividades que o compem, com a exibio do throughput, lead time, caminho crtico
entre outros indicadores importantes para o gestor do processo. No se trata de um mero
desenho esttico, mas, sim, de uma representao dinmica e real do ambiente
produtivo. Um exemplo bastante simplista, mas ilustrativo, seria a criao de um
indicador no BPMS para acompanhar o prazo mdio transcorrido entre os eventos D
(cria tarefa de verificao de resseguro) e E (informa status do resseguro), descritos
na Figura 4, com o intuito de monitorar a agilidade do departamento OSD. O painel de
controle pode apresentar este indicador por instncia, para todas as instncias tratadas
no ms, ou em outros agrupamentos que sejam de interesse do gestor.
O acompanhamento dinmico do processo permite tratar a interao software-
software, software-pessoa e pessoa-pessoa. Para o conjunto de interao software-
software, h uma grande complexidade do ponto de vista tecnolgico no que se refere
ao tratamento das diversidades tecnolgicas, seja entre plataformas computacionais,
entre linguagens, entre meios de armazenamento ou entre protocolos de comunicao. O
framework de conectores e o middleware descritos como componentes da
tecnologia BPMS na Figura 7, so fundamentais integrao e transparncia
necessrias ao BPMS sobre os avanos de uma instncia do processo, em uma
determinada atividade implementada e executada por meio de um software e pode ou
no estar no mesmo ambiente computacional do sistema BPMS.
Partindo do pressuposto de que as empresas esto organizadas cada vez mais de
forma colaborativa e que os processos esto mais e mais estruturados e organizados de
Anlise de Componentes da Tecnologia de Business Process Management System (BPMS) sob a
Perspectiva de um Caso Prtico


Vol.4, No. 1, 2007, p. 71-94
91
forma intensiva, de se esperar o envolvimento de diversos sistemas de informao,
softwares e aplicativos, sendo estes processados (hospedados) em diferentes
plataformas computacionais, ou seja, vrias e diferentes da utilizada pelo sistema
BPMS.
No estudo de caso analisado, nota-se muita interao entre software-pessoa e
algumas poucas software-software. Por no haver na infra-estrutura computacional da
Chubb a estrutura de middleware, a comunicao software-software, quando necessria,
ocorre de forma tradicional, por exemplo, por meio de softwares agentes: fluxo de
informao C da Figura 4 que conectou o Sistema BPMS ao sistema SIN e o fluxo de
informao M da Figura 5 que conectou o Sistema BPMS aos Sistema de Contas a
Pagar.
Quanto maior a flexibilidade para se acessar os softwares j existentes na
organizao ou mesmo fora dela, maior a capacidade de gerenciamento dos processos
de negcios, ou seja, da execuo de uma soluo abrangente de BPMS. Essa situao
percebida pelo uso intensivo dos componentes framework de conectores e
middleware; situao que no foi encontrada no caso estudado. Nas situaes em que
ocorre tal fato, o sistema BPMS deve ter um controle rigoroso do status da execuo da
instncia de interesse ao processo de negcio, no contexto de cada um dos softwares
acionados via middleware. Para isso, o Sistema BPMS utiliza-se do componente
gerenciador de transao. O status de uma instncia em processamento pode ser: em
processamento, processamento suspenso e sua justificativa, processamento cancelado e
sua justificativa, processamento concludo, entre outros.
Conforme o status do processamento de uma instncia em determinado software,
apontado pelo gerenciador de transao, o software BPMS pode, a partir das regras do
processo de negcio armazenadas no repositrio de definio de processo, tomar as
decises cabveis ao bom andamento da instncia do processo de negcio: acionar outro
software, avanar para outra atividade do processo de negcio e deixar parte do trabalho
em suspenso no aguardo do retorno do sistema, notificar o gestor do processo, notificar
o responsvel pelo sistema em demora ou suspenso, entre outras alternativas.
O framework de componentes BPMS desenvolvido por Krafzig, Banke e Slama
(2004) muito importante por apresentar e discutir os dados manipulados pelo BPMS,
tanto os referentes configurao e parametrizao do processo de negcio, quanto os
referentes gesto das instncias do processo de negcio cuja operao est sendo
monitorada pelo BPMS. Estes so armazenados respectivamente no repositrio de
definio de processo e no repositrio de instncias do processo.

Aspectos Crticos de serem Considerados na Implementao da Tecnologia BPMS

A importncia de se conhecer cada um dos componentes da arquitetura do
sistema BPMS pode ser justificada de diferentes formas. Primeiro, por ser til para
compreenso dos fundamentos e propsitos do sistema BPMS, ainda pouco difundido
De Sordi,J.O., Spelta,A. G.
Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management
92
inclusive entre os especialistas em informtica; segundo, ter fundamentos para avaliar a
adoo de um sistema BPMS, seja na forma de um pacote fornecido por apenas uma
software-house (pure-play BPMS) ou compondo o sistema BPMS por meio da compra
de diversos softwares que implementem suas diversas funcionalidades (BPMS
composto): simulao, automao, monitoramento, controlador de verso, entre outras.
Nesta ltima opo, os diversos softwares interagem por meio do middleware, ou seja, o
prprio processo de gesto de processos de negcios construdo, operado e gerenciado
a partir da mesma arquitetura de software e componentes a ser utilizada nos demais
processos de negcios da organizao.
A compreenso do componente estrutura de dados do repositrio de definio
de processo e estrutura de dados do repositrio de instncias do processo fator
crtico para o sucesso de aglutinao de diversas ferramentas ou mdulos que formaro
o BPMS composto. O atendimento desta necessidade muito crtica para
implementao de um amplo BPMS, considerando-se que as poucas ferramentas que se
propem a suportar todo o ciclo de vida do processo de negcio ainda so imaturas, o
que caracteriza a inexistncia de ferramentas que possam ser classificadas como pure-
play BPMS (LACHAL, 2004, p.9). O estudo de viabilidade de trabalho conjunto entre
diferentes ferramentas BPMS traz para discusso o amplo e complexo assunto da
discusso da ontologia dos sistemas BPMS diretamente atrelado aos dois componentes
do BPMS que caracterizam os repositrios de dados.
Outro aspecto importante de ser observado, quando da introduo da tecnologia
BPMS nas organizaes, so as caractersticas dos conectores disponibilizados pelos
BPMS para conexo com os sistemas legados que iro realizar as atividades
operacionais. Deve se observar no apenas a coleo de sistemas de informao da
organizao, observando se h conectores disponveis para os pacotes em uso, e
tambm a qualidade dos conectores fornecidos. Construir novos conectores ou ter de
refinar os conectores fornecidos reduzem a produtividade e os ganhos da tecnologia
BPMS.
Os componentes middleware e framework de conectores, embora no sejam
obrigatrios na introduo do sistema BPMS, proporcionam ganhos ao
desenvolvimento e manuteno dos processos de negcios. Assim, a empresa do caso
estudado se favorece de diversas facilidades proporcionadas pelo sistema BPMS
gesto de processos, porm, sem o uso dos componentes citados, continuar sem
respostas a parte dos problemas da crise de software (PRESSMAN, 2001) aqui
caracterizada por duas perguntas:
(a) Como dar flexibilidade s reas de informtica, fazendo com que estas ganhem
agilidade no atendimento da enorme demanda existente por novos softwares nas
organizaes?
(b) Como alterar, evoluir o crescente conjunto de softwares j existentes nas
organizaes, de forma rpida e segura?
Os ganhos proporcionados pelos componentes de integrao (middleware e
framework de conectores) so perceptveis a mdio e longo prazo, quando se torna
evidente a praticidade da reutilizao e da alterao dos conectores de integrao. Os
conectores permitem, por exemplo, que os dados de uma tabela ou que a mensagem de
uma fila de um sistema de mensagens, ou que o cdigo (lgica) de um sistema de
informao, sejam utilizados por diversos processos de negcios, a partir de um nico
Anlise de Componentes da Tecnologia de Business Process Management System (BPMS) sob a
Perspectiva de um Caso Prtico


Vol.4, No. 1, 2007, p. 71-94
93
conector, acelerando significativamente o processo de construo e operao de novos
processos de negcios via o sistema BPMS. Outra facilidade percebida ao longo do
tempo so os ganhos na manuteno e evoluo dos processos de negcios geridos pelo
sistema BPMS, sobretudo na facilidade de substituio ou alterao dos recursos de
tecnologia da informao acionados ao longo dos processos de negcios, como tabelas,
filas e sistemas de informao (softwares).
importante destacar que o sistema BPMS pode proporcionar resultados
significativos mesmo quando no implementado em sua totalidade. No caso da empresa
analisada, a Chubb do Brasil, bons resultados administrativos foram alcanados com
uma nica ferramenta BPMS, mesmo no utilizando de todos os componentes como,
por exemplo, os que permitem a integrao dos softwares legados, os componentes
middleware e framework de conectores. A tecnologia BPMS est disponvel s
organizaes em diferentes espectros; cabe ao profissional da gesto por processo
buscar o entendimento da demanda organizacional e, fundamentado no conhecimento
da arquitetura e dos componentes da tecnologia BPMS, definir o projeto BPMS mais
adequado para cada organizao.


REFERNCIAS

AALST, W.M.P. Business Process Management: a Personal View. Business Process
Management Journal, Bradford, v.10, n. 2, p. 135-139, 2004.
BURLTON, R. Business Process Management: Profiting from Process.
Indianpolis: Editora SAMS, 2001.
CHAPPELL, D.A. Enterprise Service Bus. Sebastopol: OReilly Media Inc, 2004.
CHUBB DO BRASIL. Conhea a Chubb. Disponvel em:
<[Link] Acesso em: 11 out. 2005a.
____________. Seis Sigma: Mtricas do projeto de Recuperao de Resseguro.
2005b.
DAVENPORT, T.H. Process Inovation. Boston: Harvard Business School Press,
1993.
DE SORDI, J .O. Gesto por Processos : uma abordagem da moderna
administrao. So Paulo: Saraiva, 2005.
FISCHER, L.J . Workflow Handbook 2004. Lighthouse Point: Future Strategies Inc,
2004.
HAMMER, M.; CHAMPY, J . Reengenharia Revolucionando a empresa, 15. ed. Rio
de J aneiro: Campus, 1994
HEDGE III, A.J . Business Process Management: Management Tools. AIIM E - Doc
Magazine, Silver Spring, v.19, n.4, p. 52-53, jul/aug 2005.
KRAFZIG, D.; BANKE, K.; SLAMA, D. Enterprise SOA: Service-Oriented
Architecture Best Practices. Indianapolis: Prentice Hall, 2004.
LACHAL, L. The technology maze. KM World, Camden, v.13, n.5, p. 8-10, may 2004.
De Sordi,J.O., Spelta,A. G.
Revista de Gesto da Tecnologia e Sistemas de Informao/Journal of Information Systems and Technology Management
94
LAUDON, K.C.; LAUDON, J ane P. Managemet Information System. 7. ed. New
J ersey: Prentice Hall, 2002.
MONTEIRO, J .M. Da Organizao Vertical para a Organizao Horizontal. 2005.
Dissertao (Mestrado em Gesto de Negcios) Universidade Catlica de Santos,
Santos, 2005.
OSTROFF, F. The Horizontal Organization : What the Organization of the Future
Actually Looks Like and How it Delivers Value to Customers. Oxford University
Press, 1999.
PRESSMAN, R.S. Software Engineering: A Practitioners Approach. 5. ed.
McGraw-Hill, 2001.
ROSS, R.G. Principles of the Business Rule Approach. Boston: Addison-Wesley,
2003
RUH, A.W.; MAGINNIS, F.X. BROWN, W.J . Enterprise application integration.
Nova York: J ohn Wiley & Sons, 211 p., 2001.
SCHICK, S. Edmonton power company rewrites billing system. Computing Canada,
Willowdale, v.32, n.3, p. 4, mar. 2006.
SMITH, Howard. Computer Sciences Corporation. The Emergence of Business
Process Management, jan. 2002. Endereo eletrnico: [Link]
WORTHEN, B. A New Glue Or The Old Soft Shoe? CIO, Framingham, v.18, n.4, p.
10, nov. 2004.
YIN, R.K. Case study research: design and methods. 2. ed. California: Sage
Publications Inc., 1994.