Análise de componentes da tecnologia de Business Process Management System (BPMS) sob a perspectiva de um caso prático

Análise de componentes da tecnologia de Business Process Management System (BPMS) sob a perspectiva de um caso prático

Business Process Management Systems technology components analysis

José Osvaldo De Sordi^I; Andrea Giovanni Spelta^II

^IUniversidade Católica de Santos, Brasil

^IIUniversidade Imes-Scsul e EAESP-FGV, Brasil

^{Endereço para correspondência}

RESUMO

A tecnologia da informação que corrobora com a implementação da abordagem administrativa da gestão por processos denomina-se Business Process Management System (BPMS). Os principais componentes do framework da solução BPMS são: repositório de definição do processo, repositório de instâncias do processo, gerenciador de transação, framework de conectores, motor do processo e middleware. Neste artigo, são definidos e caracterizados os componentes que constituem o framework da solução tecnológica BPMS, bem como o papel e a importância de cada um destes. O método adotado para abordar estes tópicos foi o estudo de caso, que apresenta e analisa a implementação da solução BPMS em uma empresa de seguros: Chubb do Brasil. No estudo do caso, o processo "Tratar ocorrência de sinistro com resseguro" é descrito e caracterizado, bem como os componentes da solução BPMS adotados e implementados pela Chubb do Brasil para sua gestão.

Palavras-chave: Gestão por Processos; Processo de Negócio; Sistema de Gestão por Processos de Negócios; BPMS; Segmento de Seguros.

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

UM BREVE HISTÓRICO DA TECNOLOGIA DA INFORMAÇÃO APLICADA AOS NEGÓCIOS

Nas décadas de 60, 70 e 80 predominou o desenvolvimento de sistemas de informação sob medida, voltado ao atendimento de necessidades específicas de cada organização. A grande maioria destes sistemas era transacional, denominados como sistemas OLTP (on-line transaction processing) ou TPS (transaction processing system), ou seja, transações de negócios eram realizadas sob a responsabilidade de uma determinada área funcional da empresa (LAUDON e LAUDON, 2002, p. 40). Isto é perceptível analisando as denominações atribuídas aos sistemas desse período, 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 produção.

Na década de 80, as software-houses desenvolveram um novo produto, denominado workflow, que objetivava atender os fluxos de trabalhos não contemplados no conjunto de algoritmos dos sistemas TPS. As ferramentas workflow apresentavam como principais características: a facilidade de permitir que cada usuário definisse as atividades que compõem o fluxo de trabalho; a seqüência de execução destas (roteirização); eventos de início, término, suspensão e cancelamento de cada atividade. O grande inconveniente do tradicional workflow dessa época era o esforço exigido para agregar algoritmos de softwares já existentes; praticamente tudo que fosse instrução de código (software) para execução e gerenciamento do processo era desenvolvido dentro da própria ferramenta workflow. Na prática, aproveitava-se muito pouco das instruções já existentes na organização na forma de software.

A partir do início da década de 90, passou a predominar o modelo da compra e implementação de sistemas desenvolvidos por software-houses, projetados objetivando atender o maior número possível 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 mídias que o armazenavam, acondicionados em caixas, expostas nas prateleiras das áreas de informática das empresas usuárias. Os pacotes também foram projetados para atender os trabalhos ou parte deles desempenhados por uma ou mais áreas funcionais.

É importante ressaltar que os sistemas de informação, tanto os desenvolvidos sob medida quanto os "pacotes", acompanharam historicamente a estrutura organizacional e a abordagem administrativa predominante da época do seu desenvolvimento. Nestes cinqüenta anos de tecnologia da informação aplicada aos negócios, a modificação organizacional mais profunda ocorreu em meados da década de 90, quando Hammer e Davenport propuseram uma nova abordagem administrativa: a gestão por processos de negócios ou business process management (BPM) (HAMMER, 1994; DAVENPORT, 1993). O método inicialmente proposto para implementação da gestão por processos nas organizações - a reengenharia - não se mostrou adequado por diversas razões. Em um segundo momento, ela foi introduzida por outros métodos não tão radicais quanto o primeiro, destacando-se o método contínuo e gradual de redesenho de processos.

A gestão por processos de negócios está inserida em um novo contexto empresarial constituído pelas organizações horizontais (flat organizations) que trabalham em redes colaborativas e apresentam como características: maior nível de autonomia aos funcionários ("enpowerment"), menor quantidade de níveis hierárquicos separando os grupos de funcionários, redução das interferências e impedâncias entre áreas funcionais por meio de trabalhos organizados e geridos por meio de equipes multifuncionais, entre outras características (OSTROFF, 1999). As principais características diferenciais entre as empresas organizadas por processos e as demais, organizadas por funções, estão descritas na Tabela 1.

A percepção do trabalho atravessando as diversas áreas funcionais para executar um macro-processo (também denominado de processo de negócio), trouxe uma nova demanda aos que implementam a tecnologia da informação nas organizações: como integrar os diversos programas e sistemas de informação existentes nas áreas funcionais, a fim de operarem em sincronia com a arquitetura dos novos processos de negócios, da nova visão de gestão requerida pelas organizações?

Na prática, os principais componentes lógicos por trás desse desafio são muito similares aos utilizados no desenvolvimento da lógica do workflow na década de 80. A maior diferença está na existência hoje de ferramentas para integração de softwares, que permitem a comunicação 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 são utilizadas para composição de plataformas padrão para integração entre sistemas de informação, que conciliam diferentes técnicas de comunicação, como: troca de mensagens, chamadas a programas (remote procedure call), troca de arquivos, replicação de dados e transformação de dados (CHAPPELL, 2004, p. 1).

A recente conjunção dos algoritmos existentes nas ferramentas para integração entre softwares (EAI e middleware) e daqueles disponíveis nas ferramentas de gerenciamento e controle dos fluxos de trabalho (workflow) foi o evento motivador para constituição de uma nova ferramenta para gestão dos extensos, complexos, duradouros e dinâmicos processos de negócios, denominada de Business Process Management System (BPMS) (FISCHER, 2004, p. 304).

Por ser uma ferramenta tecnológica bastante recente, o BPMS ainda é pouco compreendido pelos profissionais de informática e, conseqüentemente pelas próprias organizações (BURLTON, 2001, p.1). Tal dificuldade é a motivação 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 gestão dos processos de negócios, os quais proliferam rapidamente, não apenas no contexto interno das organizações, mas também nas cadeias colaborativas.

METODOLOGIA DA PESQUISA

A discussão e apresentação dos conceitos e principais componentes da tecnologia BPMS neste artigo dar-se-ão em dois estágios: na próxima seção de texto apresentar-se-á a fundamentação teórica da tecnologia BPMS e, nas seções seguintes, será a vez de uma experiência prática ocorrida em uma organização, para que facilite a exposição e descrição dos componentes da arquitetura tecnológica da ferramenta BPMS.

Para conceituação da tecnologia BPMS e discussão dos componentes de sua arquitetura, utilizaram-se dois métodos científicos: a pesquisa bibliográfica e a análise de um caso prático. O primeiro para descrever os conceitos da tecnologia BPMS e o segundo como meio de ilustrar a aplicação prática dos diversos componentes da tecnologia BPMS operando de forma integrada na execução de trabalhos concretos do dia-a-dia de uma grande organização.

Duas razões justificam o método de estudo de caso adotado para apresentar e discutir os componentes da arquitetura de software BPMS: o entendimento de que ele é mais atraente e compreensível ao público leitor; segundo, porque o tema BPMS apresenta-se carente, tanto em dados como em teorias, o que conforme Yin (1994) constitui indicação para uso do método de pesquisa de estudo de caso.

A busca por uma empresa que estivesse em estágio avançado de implantação de um BPMS foi realizada através de consultas à rede de contatos acadêmicos e profissionais dos pesquisadores. Identificada a primeira empresa, entrou-se em contato com a administração da área de informática, que concordou em prestar as informações necessárias. A coleta de dados foi realizada através de um conjunto de três entrevistas com executivos e profissionais da área de informática da empresa. As duas primeiras entrevistas não foram estruturadas e buscaram identificar o contexto da empresa, as características do sistema BPMS utilizado e as mudanças produzidas nos processos da empresa pela sua implantação. A última entrevista, por intermédio de um protocolo, visou esclarecer inúmeros detalhes sobre os processos suportados pelo sistema BPMS e os benefícios obtidos com a implantação. As entrevistas foram gravadas e transcritas para análise detalhada pelos pesquisadores. O texto final do relatório da pesquisa foi enviado aos profissionais de informática da empresa e validado por meio de contatos telefônicos.

A ARQUITETURA DO BUSINESS PROCESS MANAGEMENT SYSTEM (BPMS)

Um importante aspecto conceitual é diferenciar a abordagem administrativa da gestão por processos, aquela praticada pelas organizações horizontais, denominada de business process management (BPM), da tecnologia que apóia sua implementação: 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 usuário projetar, executar e gerenciar um completo processo de negócio, 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 solução BPMS. A apresentação desta arquitetura se inicia com a importância da disponibilidade de um eficaz ambiente para integração entre sistemas de informação.

O modelo conceitual do BPMS valoriza os investimentos já realizados em softwares pelas organizações envolvidas com o processo de negócio, diferentemente da estratégia da reengenharia de uma década atrás, que apregoava o descarte e substituição dos sistemas de informação legados pelo sistema ERP. No modelo conceitual BPMS, os sistemas de informação legados, hospedados em diferentes ambientes computacionais, continuam a executar as operações necessárias ao processo de negócio, conforme se pode observar na camada "ambientes computacionais" da Figura 1. Estes sistemas legados são coordenados ("orquestrados") pelo ambiente de gestão do processo (AGP) do BPMS. O modelo conceitual do BPMS não está fundamentado na "construção de softwares ou de módulos de sistemas de informação, mas na junção e orquestração de partes de softwares já disponíveis" (AALST, 2004).

O acionamento ou cancelamento de um sistema de informação legado via BPMS ocorre segundo as regras do processo de negócio embutidas no AGP, utilizando-se de conectores e adaptadores para comunicação com os sistemas de informação. Os conectores e adaptadores estão disponíveis no ambiente de integração tecnológica (AIT).

Uma pesquisa recente analisou mais de cem sistemas BPMS disponíveis no mercado e apontou três aspectos que os diferenciam substancialmente: a capacidade de monitoramento, a capacidade de automação e a capacidade de integração entre sistemas de informação. Estas diferenças são tão evidentes, que são utilizadas inclusive para delimitarem as diferentes categorias de sistemas BPMS (WORTHEN, 2004).

A capacidade de monitoramento e automação do BPMS destacadas por Worthen (2004) é melhor explicitada pela arquitetura BPMS desenvolvida pelo Business Process

Management Initiative (BPMI.org), descrita na Figura 2. O BPMI.org é constituído por empresas da área de tecnologia da informação e institutos de pesquisa que estão interessados no desenvolvimento da tecnologia BPMS. A missão do BPMI.org é promover, desenvolver e disseminar o BPMS, estabelecendo padrões, desenvolvendo especificações abertas e dando assistência às empresas desenvolvedoras de ferramentas, técnicas e metodologias.

A arquitetura do BPMS desenvolvida pelo BPMI.org abrange todo o ciclo de vida do processo de negócio, desde sua descoberta, seus ciclos de aprimoramento até o seu descarte. O Quadro 1 descreve as funcionalidades necessárias ao BPMS segundo a arquitetura da solução BPMS considerada pelo BPMI.org.

A arquitetura descrita pelo BPMI.org não é muito esclarecedora quanto à conexão 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 Gestão do Processo (AGP) está muito encapsulado, tratado em um nível de detalhamento muito maior na arquitetura BPMS desenvolvida pelo BPMI.org.

Os conceitos apresentados até aqui permitem um entendimento geral dos fundamentos, da proposição e da arquitetura do BPMS. Para entendimento e discussão de alguns aspectos críticos do BPMS, é necessário compreender a operação interna da ferramenta BPMS. Para isso, pede-se um maior nível de detalhamento de cada um dos seus componentes internos do BPMS, que serão analisados na seção cinco. Para subsidiar o detalhamento e explanação dos componentes do BPMS no nível de detalhamento necessário, na próxima seção do texto, será exposto um estudo de caso que ilustrará a apresentação e o desenvolvimento das análises dos componentes BPMS a ser realizado na seção cinco.

ANÁLISE DO CASO DE IMPLEMENTAÇÃO DO SISTEMA BPMS

A empresa Chubb no Brasil

A Chubb é uma das maiores seguradoras norte-americanas, está presente em 33 países e opera 132 escritórios. Fundada em 1882, em Nova York, EUA, oferecia inicialmente seguros marítimos, mas logo passou a oferecer também seguros comerciais e pessoais Em 1967, a empresa abriu seu capital e formou uma holding denominada The Chubb Corporation, com sede em Nova Jersey, EUA. No Brasil, as operações foram iniciadas em 1973, com a aquisição do controle acionário da mais antiga seguradora na América Latina, a Argos Fluminense. Em 1992, a Argos passou a denominar-se Chubb do Brasil Cia de Seguros. No texto utilizaremos a denominação Chubb do Brasil. Atualmente, a operação Brasil tem sua matriz em São Paulo, com sucursais em Belo Horizonte, Brasília, Curitiba, Rio de Janeiro e Porto Alegre, operando com seguros pessoais e comerciais. Na linha de seguros pessoais, o foco são os seguros de: automóveis de alto valor, embarcações, jatos executivos e patrimônio pessoal, como obras de arte, antiguidades e coleções. O portifólio de seguros comerciais abrange: operações marítimas, 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 funcionários 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 início ao projeto Seis Sigma, que gerou diversas iniciativas voltadas à melhoria de seus processos. Neste mesmo período, a Chubb dos Estados Unidos concluía um estudo sobre as possibilidades oferecidas pela tecnologia de Business Process Management System (BPMS) na operação, suporte e melhoria de processos. Deste estudo, derivou-se a recomendação corporativa pela utilização dos softwares BPMS, que culminou com a homologação de uma solução 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 aquisição de licenças do software e-Work às diversas unidades da Chubb que julgassem oportuno sua implementação.

O principal foco do projeto Seis Sigma era a área de Operações da Chubb. Na estrutura organizacional da empresa, esta área fazia parte da Diretoria de Operações e Tecnologia, também responsável pela adoção de novas tecnologias. Isso facilitou muito a visualização de oportunidades de uso da tecnologia BPMS, bem como sua implementação e evolução, pois a área responsável pela implementação da solução era também a principal área usuária.

Entendendo que a tecnologia BPMS tinha grande potencial para impulsionar as iniciativas de melhoria de processos almejadas pelo projeto Seis Sigma, a Diretoria de Operações 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 "cotação de seguros". A experiência foi muito bem-sucedida e motivou a criação de um programa para implementação 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 própria iniciativa do projeto Seis Sigma. Em agosto de 2005, dez processos já haviam sido aprimorados com o auxílio da tecnologia BPMS e outros oito processos estavam com implementação em andamento, com término previsto para o final de 2005.

Abordagem para seleção de processos a serem aprimorados via BPMS

Havia a necessidade de se definir critérios para seleção dos processos a serem trabalhados pela equipe do projeto Seis Sigma, considerando-se que os bons resultados alcançados pelo projeto piloto despertaram o interesse de diversos grupos internos da organização. Os critérios adotados pela Chubb foram: a) a iniciativa de aprimoramento do processo deveria assegurar alto retorno financeiro ou alterações significativas no ambiente de negócios (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 abrangência do processo à medida que resultados positivos fossem alcançados. Portanto, a estratégia de melhoria de processos adotada foi a de implantar melhorias graduais, ao invés de promover mudanças radicais e de amplo escopo.

Descrevemos, a seguir, o processo "Tratar ocorrência de sinistro com resseguro", que já foi aprimorado com o auxílio da tecnologia de BPMS. Além de descrever a finalidade, a operação do processo, e os pontos em que a tecnologia BPMS foi aplicada, também se descrevem os principais ganhos, tanto qualitativos quanto quantitativos, resultantes para o negócio da Chubb do Brasil.

O processo "Tratar ocorrência de sinistro com resseguro"

A legislação 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 exigência, as seguradoras repassam ao IRB um percentual do prêmio pago pelo segurado, que é variável conforme o valor e o tipo do item segurado. Em caso de sinistro, em contrapartida, o IRB é solidário com a seguradora, assumindo a responsabilidade por um percentual da indenização 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 obtém dados mais completos sobre o sinistro, reúne documentos e realiza os pagamentos da indenização ao segurado, o que pode acontecer em uma ou várias 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 execução do processo "Tratar ocorrência de sinistro com resseguro".

O objetivo principal da implementação da tecnologia BPMS no processo "Tratar ocorrência de sinistro com resseguro" foi reduzir o tempo para envio de notificações ao IRB, tanto da ocorrência do sinistro como da realização de um pagamento ao segurado. Em conseqüência, dois benefícios seriam proporcionados: primeiro, a Chubb não estaria sujeita às multas aplicadas pelo IRB quando a notificação 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 importância deste processo é percebida pela total de ocorrências em um mês: uma média de 80 a 100 avisos de sinistro por dia, sendo que 10% destes possuem resseguro junto ao IRB, ou seja, aproximadamente 180 sinistros por mês com resseguro.

Apresenta-se, a seguir, a descrição detalhada das atividades realizadas pelo processo "Tratar ocorrência de sinistro com resseguro". Para facilitar o entendimento do processo, suas atividades foram subdivididas em dois sub-processos: "Notificar ocorrência 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.

Os atores do sub-processo "Notificar ocorrência de sinistro ao IRB", seus eventos percebidos, a seqüência de ocorrência destes, bem como o tempo entre eventos, estão descritos no diagrama de interação apresentado na Figura 4. Os textos a seguir são identificados por letras, estabelecendo assim uma relação 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 ocorrência de sinistro é recebido pelo departamento responsável 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. Após análise preliminar do Departamento de Sinistros, os dados referentes ao seguro e ao sinistro são 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 instância de processo para cada um dos sinistros;

d. Uma vez registrado uma instância de sinistro no Sistema BPMS, cria-se automaticamente na lista de trabalho ("To do List") do profissional da área responsável pelo seguro, departamento conhecido internamente pelo acrônimo OSD (Operational Services Department), uma tarefa que consiste em verificar o status do resseguro, ou seja, se há ou não um contrato de resseguro para aquele sinistro;

e. Caso haja resseguro, o valor do percentual a ser restituído pelo IRB é informado ao Sistema BPMS via uma interface gráfica homem-máquina ("tela de sistema"), desenvolvida no próprio ambiente de ferramentas para interação do Sistema BPMS. Caso não haja resseguro, a instância do processo criada no Sistema BPMS, conforme descrita na atividade "C", é assinalada como encerrada;

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 notificação ao IRB seja efetuada;

g. O Departamento de Resseguros notifica o IRB, através da digitação de dados do sinistro em um sistema de informação do próprio IRB - Sistema IRB - disponível via Internet (web application);

h. O Sistema IRB devolve ao Departamento de Resseguros da Chubb um número de protocolo que comprova a data e horário da notificação do sinistro;

i. O Departamento de Resseguros digita no Sistema BPMS o número 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 seqüência de ocorrência destes, bem como o tempo entre eventos, estão descritos no diagrama de interação apresentado na Figura 5. Os textos a seguir são identificados por letras, estabelecendo, assim, uma relação 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 indenização 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 criação de instâncias de pagamentos a serem realizados;

m. Um Software Agente extrai da base de dados do Sistema de Contas a Pagar os pagamentos que estão 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, através do encaminhamento de um dossiê sobre este por meio de um mensageiro (remessa física de documentos);

p. A recepção do IRB fornece um número de protocolo que registra formalmente a notificação feita por meio da entrega dos documentos;

q. O Departamento de Resseguros digita no Sistema BPMS o número do protocolo de entrega informado pelo IRB quando da entrega do dossiê.

Ganhos proporcionados ao processo "Tratar ocorrência de sinistro com resseguro"

A Chubb do Brasil constatou diversos benefícios no processo "Tratar ocorrência de sinistro com resseguro" em decorrência da adoção da tecnologia BPMS no suporte a sua operação. O ganho mais expressivo foi na redução dos prazos para notificação do IRB da ocorrência de sinistro com resseguro. Na Figura 6, nota-se a expressiva redução neste prazo, de 107 dias para 27 dias. Na situação anterior à introdução da tecnologia BPMS, havia riscos de perda das fichas em que eram registrados os dados sobre o sinistro e não havia controle preciso sobre a situação de cada sinistro. O processo era muito burocrático, havia documentos circulando com carimbos e assinaturas e as várias áreas envolvidas mantinham planilhas particulares de controle.

Outro benefício percebido foi o relativo à redução das multas aplicadas pelo IRB em função da emissão do Aviso de Ocorrência de Sinistro após o prazo regulamentar. A redução dessas despesas com multas, acrescidas dos ganhos financeiros em função de se ter a restituição do IRB mais cedo, proporcionou um ganho aproximado de R$ 200 mil por ano.

Aprimoramento contínuo 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 informações instantâneas sobre o total de instâncias pendentes em cada atividade, total de instâncias já processadas, caminho crítico, entre outras. Estas informações são utilizadas para definição 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 informações tornam todos mais bem informados e comprometidos com relação ao processo; em conseqüência disso, observou-se uma sensível melhoria do processo.

EXEMPLIFICANDO OS COMPONENTES DO SISTEMA BPMS A PARTIR DO CASO ANALISADO

Para discussão dos componentes do sistema BPMS, adotou-se o framework proposto por Krafzig, Banke e Slama (2004), o qual está retratado na Figura 7.

Como uma ferramenta de gerenciamento e não de execução do processo, o sistema BPMS desempenha o papel de organizador e controlador. Tal característica 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 saídas do sistema BPMS, declaradas nas figuras 4 e 5, estão relacionadas à organização e gestão do trabalho: informação "D" da Figura 4, notifica pessoal do OSD sobre a necessidade de verificar se há resseguro para um determinado sinistro; informação "F" da Figura 4, notifica pessoal do Departamento de Resseguros que estes precisam comunicar ao IRB sobre a ocorrência de um sinistro com resseguro; informação "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 informações estão armazenadas no componente do BPMS denominado "repositório de definição de processo". Neste componente, estão descritas as atividades, as seqüências de trabalho possíveis de ocorrerem, as regras para identificação de início e término de cada atividade, entre outras informações importantes à "orquestração" do processo. Todas essas informações são introduzidas no sistema BPMS pelo analista de negócios, que deve concentrar-se nos aspectos do processo e do ambiente de negócios, mesmo que não seja um profundo conhecedor de linguagens de programação e dos demais recursos de tecnologia da informação. O analista de negócios insere no sistema BPMS as informações relativas ao controle do processo de negócio por meio de diagramadores, também conhecidos como "ferramentas de desenho", conforme descrito na Figura 7 que apresenta os diversos componentes do sistema BPMS.

As "ferramentas de desenho" são fundamentais para desenvolver a especificação da lógica do processo de negócio. Diagramas de processo, como o retratado na Figura 3; diagramas de interação, Figuras 4 e 5, são alguns exemplos disponíveis nas ferramentas BPMS. Descrição de regras de negócios, eventos e ações 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 necessário para o seu "disparo". As ferramentas de desenho armazenam e manipulam dados do "Repositório de definição de processo".

Das instruções de controle do processo, inseridas pelo analista de negócios via diagramadores e demais facilidades gráficas oferecidas pelo sistema BPMS, gera-se o código executável (software) a ser utilizado pelo sistema BPMS no acompanhamento do processo. O código fonte gerado segue os padrões da tecnologia BPMS e denomina-se business process modeling language (BPML). As rotinas de software BPML são constantemente interpretadas e executadas pelo "motor do processo", parte integrante do sistema BPMS, conforme descrito na Figura 7.

O sistema BPMS também permite facilidades para interação de pessoas. Já foram descritas várias informações 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: informação "E" da Figura 4, o departamento OSD informa o valor percentual do total do seguro a ser restituído pelo IRB; informação "I" da Figura 4, o departamento de Resseguros informa o número de protocolo fornecido pelo IRB quando do envio da notificação da ocorrência de sinistro com resseguro; informação "Q" da Figura 5, o departamento de Resseguros informa o número do protocolo fornecido pelo IRB quando da entrega do dossiê do sinistro. Todas essas informações são armazenadas no componente do BPMS denominado "Repositório de instâncias do processo", também descrito na Figura 7.

Os softwares que desempenham o papel do "motor do processo" são processados diretamente sobre os dois repositórios de dados da solução BMPS: "Repositório de instâncias do processo" e "Repositório de definição de processo", conforme descrito no framework do sistema BPMS apresentado na Figura 7. Deve-se isso à forte dependência do "motor do processo" em ter acesso aos dados dessas duas bases de dados para efetivamente poder controlar o processo. Exemplificaremos tal dependência, analisando um exemplo prático do caso estudado. Inicialmente descrevemos as operações necessárias ao encaminhamento e controle do processo e, posteriormente, apresentamos os conteúdos manipulados nos dois repositórios.

Descrição de algumas operações necessárias ao encaminhamento e controle do processo:

"Uma vez criada uma instância de sinistro no sistema BPMS, evento percebido pela chegada da informação "C" (descrita na Figura 4), deve-se notificar um dos profissionais do departamento OSD para que se verifique a existência ou não de um contrato de resseguro para aquele sinistro. A regra para seleção do profissional do OSD a realizar a consulta é rotativa, ou seja, será sempre o funcionário que está há mais tempo sem receber uma solicitação. A solicitação encaminhada ao profissional do OSD está caracterizada pelo envio da informação "D" da Figura 4. Caso o funcionário do OSD que recebeu o pedido de verificação não responda em 24 horas, um e-mail de alerta será emitido à caixa postal eletrônica do funcionário. Após isso, contam-se mais 24 horas e, em ainda não havendo um retorno, será emitida uma notificação ao superior do funcionário 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 ocorrência de sinistro é assinalada como passível de resseguro e o Departamento de Resseguros será acionado para recuperar o valor junto ao IRB".

No "Repositório de definição de processo" estão armazenados os valores de vários parâmetros necessários para o controle do processo. O sistema BPMS apresenta ao analista de negócios, de forma gráfica e intuitiva, uma lista de variáveis a serem preenchidas para definição de uma regra de negócio, desde o evento que a inicia até a sua conclusão. No exemplo descrito, a chegada da informação "C" ao sistema BPMS é monitorada pela regra de negócio "tratar nova ocorrência de sinistro". Assim que uma nova ocorrência for identificada, a regra deve "imediatamente" enviar um e-mail ao profissional do OSD. Ao invés de "imediatamente" poderia ser "após 24 horas" ou "todo dia 15 do mês" ou qualquer outra menção temporal que é definida através de uma variável armazenada no "Repositório de definição de processo". Em termos de estrutura de dados, há um detalhamento e especialização bastante grande para que o software consiga tratar toda complexidade possível de ser requerida. No exemplo, a definição de enviar um e-mail ao funcionário após 24 horas sem resposta, a especificação do período de tempo é feita pelo assinalamento do valor numérico "24" para a variável "tempo de espera" e o conteúdo "H" para variável "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 após 24 horas sem resposta de um funcionário, envolve variáveis que também estão com seus valores armazenados no "Repositório de definição de processo".

A definição das configurações (ou parametrizações) do sistema BPMS ocorre por meio do componente instalação e configuração descrito na Figura 7. É a partir destes componentes que dados são inseridos, alterados ou excluídos do "repositório de definição de processo". A arquitetura BPMS, desenvolvida pelo BPMI.org, também cita tal componente, no entanto, sem qualquer menção à estrutura de dados, conforme pode se observar na Figura 2.

No "Repositório de instâncias do processo" está assinalado o caminho já percorrido por cada uma das instâncias. No exemplo citado, uma instância de ocorrência de sinistro pode ser percebida pelo sistema BPMS e estar em um dos seguintes estágios, ou seja, posição de processamento dentro do fluxo do processo:

• 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 não haver resseguro;

• aguardando notificação junto ao IRB;

• aguardando pagamento do IRB;

• encerrada por ter havido pagamento do IRB.

Cada informação que chega ou sai do BPMS tem seus fatos básicos apontados (gravados) no "Repositório de instâncias do processo". Ao se ter o número identificador de uma determinada instância, rapidamente se sabe sua situação dentro do processo, bastando acessar a última ocorrência gravada no "Repositório de instâncias do processo". Pode-se afirmar que o "Repositório de instâncias do processo" trata dos dados necessários para operação e gerenciamento do processo (runtime).

Assim como acontece com a estrutura de dados do "repositório de definição de processo", a arquitetura BPMS desenvolvida pelo BPMI.org não cita a estrutura de dados utilizada para armazenar os dados do "repositório de instâncias do processo", conforme pode se observar na Figura 2. Nas conclusões finais, desenvolve-se uma análise sobre a importância dos profissionais envolvidos com a gestão por processos (BPM) em compreenderem as estruturas de dados dos dois repositórios envoltos com a solução BPMS.

Retornando à descrição 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 compõem, com a exibição do throughput, lead time, caminho crítico entre outros indicadores importantes para o gestor do processo. Não se trata de um mero desenho estático, mas, sim, de uma representação dinâmica e real do ambiente produtivo. Um exemplo bastante simplista, mas ilustrativo, seria a criação de um indicador no BPMS para acompanhar o prazo médio transcorrido entre os eventos "D" (cria tarefa de verificação 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 instância, para todas as instâncias tratadas no mês, ou em outros agrupamentos que sejam de interesse do gestor.

O acompanhamento dinâmico do processo permite tratar a interação software-software, software-pessoa e pessoa-pessoa. Para o conjunto de interação software-software, há uma grande complexidade do ponto de vista tecnológico no que se refere ao tratamento das diversidades tecnológicas, seja entre plataformas computacionais, entre linguagens, entre meios de armazenamento ou entre protocolos de comunicação. O "framework de conectores" e o "middleware" descritos como componentes da tecnologia BPMS na Figura 7, são fundamentais à integração e transparência necessárias ao BPMS sobre os avanços de uma instância do processo, em uma determinada atividade implementada e executada por meio de um software e pode ou não estar no mesmo ambiente computacional do sistema BPMS.

Partindo do pressuposto de que as empresas estão organizadas cada vez mais de forma colaborativa e que os processos estão mais e mais estruturados e organizados de forma intensiva, é de se esperar o envolvimento de diversos sistemas de informação, softwares e aplicativos, sendo estes processados ("hospedados") em diferentes plataformas computacionais, ou seja, várias e diferentes da utilizada pelo sistema BPMS.

No estudo de caso analisado, nota-se muita interação entre software-pessoa e algumas poucas software-software. Por não haver na infra-estrutura computacional da Chubb a estrutura de middleware, a comunicação software-software, quando necessária, ocorre de forma tradicional, por exemplo, por meio de softwares agentes: fluxo de informação "C" da Figura 4 que conectou o Sistema BPMS ao sistema SIN e o fluxo de informação "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 organização ou mesmo fora dela, maior a capacidade de gerenciamento dos processos de negócios, ou seja, da execução de uma solução abrangente de BPMS. Essa situação é percebida pelo uso intensivo dos componentes "framework de conectores" e "middleware"; situação que não foi encontrada no caso estudado. Nas situações em que ocorre tal fato, o sistema BPMS deve ter um controle rigoroso do status da execução da instância de interesse ao processo de negócio, no contexto de cada um dos softwares acionados via "middleware". Para isso, o Sistema BPMS utiliza-se do componente "gerenciador de transação". O status de uma instância em processamento pode ser: em processamento, processamento suspenso e sua justificativa, processamento cancelado e sua justificativa, processamento concluído, entre outros.

Conforme o status do processamento de uma instância em determinado software, apontado pelo "gerenciador de transação", o software BPMS pode, a partir das regras do processo de negócio armazenadas no "repositório de definição de processo", tomar as decisões cabíveis ao bom andamento da instância do processo de negócio: acionar outro software, avançar para outra atividade do processo de negócio e deixar parte do trabalho em suspenso no aguardo do retorno do sistema, notificar o gestor do processo, notificar o responsável 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 à configuração e parametrização do processo de negócio, quanto os referentes à gestão das instâncias do processo de negócio cuja operação está sendo monitorada pelo BPMS. Estes são armazenados respectivamente no "repositório de definição de processo" e no "repositório de instâncias do processo".

Aspectos Críticos de serem Considerados na Implementação da Tecnologia BPMS

A importância de se conhecer cada um dos componentes da arquitetura do sistema BPMS pode ser justificada de diferentes formas. Primeiro, por ser útil para compreensão dos fundamentos e propósitos do sistema BPMS, ainda pouco difundido inclusive entre os especialistas em informática; segundo, ter fundamentos para avaliar a adoção 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): simulação, automação, monitoramento, controlador de versão, entre outras. Nesta última opção, os diversos softwares interagem por meio do middleware, ou seja, o próprio processo de gestão de processos de negócios é construído, operado e gerenciado a partir da mesma arquitetura de software e componentes a ser utilizada nos demais processos de negócios da organização.

A compreensão do componente estrutura de dados do "repositório de definição de processo" e estrutura de dados do "repositório de instâncias do processo" é fator crítico para o sucesso de aglutinação de diversas ferramentas ou módulos que formarão o BPMS composto. O atendimento desta necessidade é muito crítica para implementação de um amplo BPMS, considerando-se que as poucas ferramentas que se propõem a suportar todo o ciclo de vida do processo de negócio ainda são imaturas, o que caracteriza a inexistência 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 discussão o amplo e complexo assunto da discussão da ontologia dos sistemas BPMS diretamente atrelado aos dois componentes do BPMS que caracterizam os repositórios de dados.

Outro aspecto importante de ser observado, quando da introdução da tecnologia BPMS nas organizações, são as características dos conectores disponibilizados pelos BPMS para conexão com os sistemas legados que irão realizar as atividades operacionais. Deve se observar não apenas a coleção de sistemas de informação da organização, observando se há conectores disponíveis para os "pacotes" em uso, e também 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 não sejam obrigatórios na introdução do sistema BPMS, proporcionam ganhos ao desenvolvimento e manutenção dos processos de negócios. Assim, a empresa do caso estudado se favorece de diversas facilidades proporcionadas pelo sistema BPMS à gestão de processos, porém, 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 informática, fazendo com que estas ganhem agilidade no atendimento da enorme demanda existente por novos softwares nas organizações?

(b)Como alterar, evoluir o crescente conjunto de softwares já existentes nas organizações, de forma rápida e segura?

Os ganhos proporcionados pelos componentes de integração (middleware e framework de conectores) são perceptíveis a médio e longo prazo, quando se torna evidente a praticidade da reutilização e da alteração dos conectores de integração. 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 código (lógica) de um sistema de informação, sejam utilizados por diversos processos de negócios, a partir de um único conector, acelerando significativamente o processo de construção e operação de novos processos de negócios via o sistema BPMS. Outra facilidade percebida ao longo do tempo são os ganhos na manutenção e evolução dos processos de negócios geridos pelo sistema BPMS, sobretudo na facilidade de substituição ou alteração dos recursos de tecnologia da informação acionados ao longo dos processos de negócios, como tabelas, filas e sistemas de informação (softwares).

É importante destacar que o sistema BPMS pode proporcionar resultados significativos mesmo quando não implementado em sua totalidade. No caso da empresa analisada, a Chubb do Brasil, bons resultados administrativos foram alcançados com uma única ferramenta BPMS, mesmo não utilizando de todos os componentes como, por exemplo, os que permitem a integração dos softwares legados, os componentes middleware e framework de conectores. A tecnologia BPMS está disponível às organizações em diferentes espectros; cabe ao profissional da gestão 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 organização.

Andrea Giovanni Spelta

Docente-Pesquisador na Universidade IMES-SCSUL

e Doutorando em Administração de Empresas na EAESP-FGV

Av. Nove de Julho, 2029 - Bela Vista, São Paulo/SP, CEP 01313-902

Tel.: [phone]

Fax: [phone]

e-mail: [e-mail]

Recebido em: 18/04/2006

Aprovado em: 30/08/2006

• 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 Indianápolis: Editora SAMS, 2001.
• CHAPPELL, D.A. Enterprise Service Bus Sebastopol: O'Reilly Media Inc, 2004.
• CHUBB DO BRASIL. Conheça a Chubb Disponível em: <http://www.chubb.com/international/brasil/> . Acesso em: 11 out. 2005a.
• ____________. Seis Sigma: Métricas do projeto de Recuperação de Resseguro 2005b.
• DAVENPORT, T.H. Process Inovation Boston: Harvard Business School Press, 1993.
• DE SORDI, J.O. Gestão por Processos : uma abordagem da moderna administração São 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 Janeiro: 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.
• LAUDON, K.C.; LAUDON, Jane P. Managemet Information System 7. ed. New Jersey: Prentice Hall, 2002.
• MONTEIRO, J.M. Da Organização Vertical para a Organização Horizontal. 2005. Dissertação (Mestrado em Gestão de Negócios) - Universidade Católica 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 Practitioner's 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: John 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. Endereço eletrônico: http://www.bpmi.org/library.esp
• 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.

Datas de Publicação

• Publicação nesta coleção
  17 Out 2011
• Data do Fascículo
  2007

Histórico

• Aceito
  30 Ago 2006
• Recebido
  18 Abr 2006