Abordagem sistêmica para integração entre sistemas de informação e sua importância à gestão da operação: análise do caso GVT

Systematic approach for the integration of information systems and its implications in operations management: analysis of the GVT case

Abordagem sistêmica para integração entre sistemas de informação e sua importância à gestão da operação: análise do caso GVT

Systematic approach for the integration of information systems and its implications in operations management: analysis of the GVT case

José Osvaldo De Sordi^I; Gildo Medeiros Júnior^II

^IPrograma de Mestrado em Gestão de Negócios da Universidade Católica de Santos, Rua Dr. Carvalho de Mendonça, 144, CEP 11070-906, Santos, SP, Brasil, e-mail: [e-mail]

^IIGlobal Village Telecom, GVT Telecom, Rua Lourenço Pinto, 299, CEP 80520-480, Curitiba, PR, Brasil, e-mail: [e-mail]

RESUMO

Este artigo descreve e analisa o caso de uma empresa brasileira de telecomunicações, a GVT, na aplicação de recursos de tecnologia da informação no suporte à integração de seus processos de negócio, em especial, aqueles relacionados à sua operação. O caso contempla as fases de planejamento, desenvolvimento e operação de uma solução para integração entre sistemas de informação (SI), por meio de uma camada integradora, habilitada por um sistema de gerenciamento de mensagens de dados. A solução em questão, além de integrar SIs, coordena o encaminhamento e seqüenciamento automático das mensagens, a fim de atender às necessidades operacionais dos processos de negócio. Neste contexto mais amplo, esta solução denomina-se Business Process Integration (BPI). O artigo agrega valor no sentido de descrever e analisar uma das poucas experiências significativas ocorridas no Brasil sobre implementação de solução BPI. Por significativa entendemos: um caso corporativo, ou seja, realiza a integração de diversos SIs complexos e críticos à operação do negócio e, por já terem decorrido dois anos de sua implementação, permite um distanciamento de tempo suficiente para análises mais consistentes.

Palavras-chave: processos de negócio, integração entre sistemas, gestão de processos.

ABSTRACT

This article describes and analyzes the case of a Brazilian telecommunications company, GTV, in the application of information technology resources to support the integration of its business processes, particularly those related to its operation. The case study involves the planning, developmental and operational phases of a solution for integrating information systems (IS) environments by means of an integration layer that incorporates a data message management system. The solution in question integrates ISs and coordinates the automatic sequencing and sending of messages, thereby meeting the operational requirements of the business processes. In this broader context, this solution is called Business Process Integration (BPI). This paper adds value by describing and analyzing one of the few significant Brazilian experiences in BPI implementation. By significant we mean a real corporate case, i.e., one that has integrated a variety of complex and critical ISs into the business, and whose implementation occurred two years ago, allowing sufficient time for more consistent analyses.

Keywords: business processes, systems integration, business process management.

1. Introdução

Presenciamos, durante a última década, a proliferação dos sistemas de informação computadorizados (SI) nas organizações. Ter integrações eficazes entre SIs tornou-se um dos aspectos críticos para operação dos ambientes de negócios, sobretudo àqueles de natureza altamente colaborativa. Este crescente desafio do ambiente de negócios motivou a indústria de tecnologia da informação (TI) a desenvolver novos conceitos, técnicas e softwares direcionados exclusivamente à questão da integração entre SIs. A aplicação dessa nova prática ocorre por meio de equipe especializada e pelo uso da abordagem sistemática para integração entre SIs.

O presente artigo tem por objetivo retratar os aspectos diferenciais da abordagem sistemática para integração entre SIs, atendo-se principalmente às questões inovadoras em comparação à abordagem tradicional praticada pela grande maioria das organizações. Para descrição desses aspectos, optou-se pelo desenvolvimento de um estudo de caso em uma empresa que apresentasse, entre seus SIs, integrações complexas e críticas à operação dos negócios e que fossem desenvolvidas e gerenciadas por meio da abordagem sistemática.

A integração entre SIs requerida atualmente, caracterizada por amplo escopo, alta complexidade e grande relevância para o ambiente de negócios, compõe um dos maiores desafios da administração contemporânea com relação à gestão dos recursos de TI (Meehan, 2002). Nesse contexto, o método de estudo de caso apresenta-se bastante adequado ao objeto a ser estudado – o ambiente de integração entre SIs – considerando-se sua demanda no contexto das organizações e da premente necessidade de tratamento gerencial desse objeto:

Em geral, os estudos de caso representam a estratégia preferida quando se colocam questões do tipo "como" e "por quê", quando o pesquisador tem pouco controle sobre os acontecimentos e quando o foco se encontra em fenômenos contemporâneos, inseridos em algum contexto da vida real. (Yin, 2005, p. 19, grifo nosso).

Corroborando na escolha da metodologia adotada, Bonoma (1985, p. 207) ressalta o uso do método de estudo de caso quando um fenômeno não pode ser estudado fora do contexto no qual ele naturalmente ocorre. Consideração válida para a presente pesquisa, devido à dificuldade de caracterização da importância dos ambientes de integração entre SIs sem a análise de sua aplicação prática no ambiente de negócios por meio de estudos de casos reais.

A apresentação dos resultados do caso estudado ocorre por meio de quatro capítulos apresentados a seguir. No próximo capítulo, o segundo, são discutidos os diversos aspectos do ambiente de negócios atual que explicam as razões para o contínuo crescimento do portifólio de SI das organizações, bem como os motivos que exigem eficazes integrações entre eles. Devido à atualidade do tema e da pouca existência de literatura nacional a seu respeito, recorreu-se ao método de pesquisa bibliográfica em periódicos acadêmicos internacionais. Para tal, realizaram-se pesquisas bibliográficas nas bases de dados digitais de periódicos dos provedores de serviços Pro-Quest e EBSCO.

No terceiro capítulo, são descritos os desafios relativos à integração entre SIs no contexto específico da empresa analisada. Relata-se a situação no momento da constituição da empresa no Brasil, ocorrida em 1999, das exigências legais e operacionais que implicavam o desenvolvimento de complexas integrações dos seus SIs corporativos, além de outros fatores que motivaram a organização a adotar a abordagem sistemática para integração dos seus SIs. Para o desenvolvimento dessa parte do estudo de caso, utilizou-se de entrevista com pessoas da organização, envolvidas no processo de constituição da empresa e da leitura de documentos da época.

No quarto capítulo, é descrita a evolução do ambiente de integração entre SIs da empresa estudada e sua utilização para operação de um dos mais importantes processos de negócios da empresa, demonstrando como a eficaz integração é fundamental para o sucesso do processo e conseqüentemente da própria organização. Os dados relativos a esse aspecto do estudo de caso foram obtidos diretamente junto aos profissionais da empresa. Foram realizadas entrevistas e reuniões com os profissionais da equipe de TI, mais especificamente, com aqueles que compõem a equipe de "Arquitetura e Intefaces", notórios conhecedores da solução, não só pelo envolvimento atual com a solução, mas por estarem envolvidos neste projeto desde sua origem.

No quinto e último capítulo, são desenvolvidas as conclusões finais, ou seja, as lições aprendidas a partir do caso estudado. As conclusões finais foram desenvolvidas a partir da experiência relatada pela empresa, conciliadas com a pesquisa bibliográfica realizada e a experiência técnica dos autores com relação ao tema. As análises finais foram estruturadas considerando-se: as empresas que estejam analisando a possibilidade de iniciar um projeto para constituição de um ambiente profissional para integração entre SIs, as que já se decidiram e se preparam para iniciar tal projeto, bem como análise do potencial de evolução do ambiente para aquelas que já o implementaram.

2. O Desafio da integração entre SIs nas corporações

Presenciamos nos últimos anos um forte crescimento do portifólio de sistemas de informação (SI) existentes nas corporações e, citando apenas alguns, dos mais difundidos, temos: gestão empresarial integrada (enterprise resource planning/ERP); gestão do relacionamento com clientes (customer relationship management/CRM); gestão do relacionamento com fornecedores (suppliers relationship management/SRM); gestão da cadeia de suprimentos (supply chain management/SCM); gestão do desenvolvimento colaborativo de produtos (product life-cycle management/PLM); compra de materiais indiretos (e-procurement); compra de materiais diretos (e-sourcing); mais outros tantos sistemas colaborativos via Internet pré-fixados pela letra e (eletronic); e sistemas de automação de processos (workflow). Estes são apenas alguns dos nomes que compõem o vasto elenco de SI das corporações.

A avaliação e seleção dos melhores SIs para cada aspecto do negócio já não estão mais entre os grandes desafios da agenda do gestor de TI aplicada aos negócios, função desempenhada pelo Chief Information Officer (CIO). O desafio atual é desenvolver um ambiente de comunicação, que permita aos diversos SIs da organização trocar dados de forma eficaz, atendendo à crescente demanda dos processos de negócio por comunicação instantânea, ou seja, em tempo-real (Murphy, 2003). O desempenho operacional das corporações está diretamente associado à qualidade da arquitetura de integração de seus SIs, uma vez que os processos de negócio estão cada vez mais dependentes de funções desempenhadas por softwares.

Há diversas formas técnicas de se integrar sistemas. A demanda crescente de soluções nesta área trouxe inovações, uma delas é a integração entre sistemas por meio de camada integradora (Cummins, 2002). Em vez de termos diversas integrações, sistema a sistema, um a um, temos apenas um ambiente lógico central, em que os sistemas colocam e recebem os seus dados, se integram. Este condutor central de dados, denominado aqui de camada integradora, é disponibilizado por softwares para gerenciamento de mensagens, cuja implementação ocorre por meio de projetos de Integração de Processos de Negócio ou Business Process Integration (BPI). A solução BPI tem como principais funcionalidades: o transporte e a transformação de informações entre uma ou mais aplicações, a disponibilidade de regras de seqüenciamento e tempo, que governam quando o transporte e a transformação devem acontecer, além do tratamento de restrições da integridade das informações que determinam o sucesso ou falha de uma integração executada (Hasselbring, 2000).

Como o aspecto central da pesquisa são os ambientes para integração entre SIs, apresentamos, na Tabela 1, um resumo dos principais recursos utilizados para integração entre SIs, classificados a partir de três principais mecanismos: chamadas ou call interface, mensagens ou messaging e transferência entre arquivos ou data acess/file transfer (Butler, 1999).

Projetos típicos de integração entre aplicações, freqüentemente, empregam uma mescla de todos os mecanismos de integração descritos. Esta mescla de alternativas é determinada pela disponibilidade e serventia de interfaces das aplicações a serem integradas e pelas exigências específicas de cada conexão, por exemplo, se demanda sincronismo ou não. As necessidades de integração são determinadas pelo fluxo de trabalho dos processos de negócio e pelos SIs utilizados em cada uma de suas atividades, que podem envolver vários passos de integração por meio de fontes de informação díspares (De Sordi, 2003).

O desafio tecnológico de integrar ambientes de SI, altamente interdependentes e com um volume cada vez maior de sistemas a serem integrados, fez dos projetos de BPI uma das prioridades constantes dos CIOs nos últimos anos. A demanda por soluções de integrações tem crescido principalmente em função de movimentos operacionais e administrativos. Descrevemos a seguir algumas das razões que geram demanda por soluções BPI (Ruh et al., 2001; Bell e Koslowski, 2002):

• Diversidade de SI - as organizações têm optado pela estratégia

  best of breed, ou seja, buscar o melhor SI para cada finalidade, o que eleva a variedade de bases de dados e aplicações;

• Opção pela compra de sistemas prontos - as empresas têm preferido comprar aplicações prontas ao invés de desenvolver sistemas sob medida. O desenvolvimento sobre demanda criava e testava as comunicações necessárias (interfaces) do novo sistema com os demais SIs da organização. Em algumas situações, optava-se por aumentar o escopo do novo sistema de forma a desativar sistemas menores ou periféricos que apresentariam dificuldades de integração;

• Fusão e aquisições de empresas - cresce o ativo de plataformas tecnológicas e de SIs da empresa. As fusões acabam por mesclar diferentes sistemas e plataformas das empresas envolvidas; e

• Entrega de serviços consolidados aos clientes - melhoria de processos requer relacionamento único com os clientes, ou seja, integração de serviços e sistemas. Um extrato ou uma tela para o atendimento de tele-marketing ou suporte deve apresentar dados sintéticos de diversos serviços, cuja operação e gerenciamento ocorrem por meio de diferentes bases de dados e sistemas.

Há muitas formas de classificação dos recursos de integração. Isto ocorre principalmente pela diversidade de locais ou pontos do ambiente computacional nos quais ocorrem as ações de integração entre SIs. Esta complexidade requer pessoas, ferramentas e procedimentos específicos, para composição de um ambiente propício à gestão das integrações. Este ambiente começou a ser delineado nos últimos 4 anos, sendo hoje uma realidade nas organizações de vanguarda, sobretudo naquelas que atuam em ambientes altamente colaborativos, com forte envolvimento de fornecedores, clientes e demais interlocutores com troca intensiva de dados e informações. Para evidenciar a evolução que representa a formação de ambientes específicos para integração entre SIs, descrevemos a seguir a abordagem tradicional e a abordagem sistemática de integração (Gartner, 2003).

Na abordagem tradicional, o trabalho de integração entre SIs é realizado pontualmente, como uma fase do projeto de desenvolvimento e implementação de um novo sistema. Cada nova necessidade de integração é considerada como um problema local e único (Ruh et al., 2001). O analista de sistemas responsável pelo novo sistema analisa, especifica e gerencia o desenvolvimento das integrações requeridas. Estas são entregues, na maioria das vezes, na forma de software que são adicionados à nova aplicação e que estabelecem um forte vínculo com a outra ponta da integração - sistemas legados – os quais passam a estar integrados com a nova aplicação. Isto gera uma situação indesejada, que se denomina "perpetuação do legado". Cada novo sistema que referencia diretamente um antigo sistema torna mais custoso, trabalhoso e arriscado o processo de substituição deste sistema legado, devido ao impacto em todos os demais sistemas, inclusive os mais recentes.

O uso da abordagem tradicional ao longo dos anos gera a "integração do tipo espaguete", em que há diversas integrações (interfaces) confusamente entrelaçadas, como se fossem os fios de uma macarronada, com o objetivo de atender à demanda de conexão entre os diferentes SIs. Puschmann e Alt (2001) apresentaram uma fórmula bastante simples para estimar a demanda de interfaces entre SIs num determinado ambiente computacional. Considerando "N" o número de sistemas de informação e "I" o número total de interfaces, tem-se a seguinte equação:

A fórmula apresentada retrata o cenário mais crítico, em que todos os sistemas integram-se com todos os demais. Embora não tão realística, é um meio interessante para representar a quantidade total de esforços exigidos pelo ambiente tradicional, muito superior ao demandado quando se aplica a abordagem sistemática.

Uma proposta tecnológica recente e promissora para integração entre SIs ocorre por meio do desenvolvimento de componentes de integração. O componente é uma abstração lógica que pode representar um programa, base de dados ou fila de mensagem, ele facilita a interação de qualquer outro software com a entidade que ele representa. Quando da alteração ou mesmo da substituição do programa, fila de mensagem ou base de dados que está acessível via componente, não há ocorrência de trabalhos adicionais junto aos diversos sistemas que os acessam; o único ponto a ser alterado é o próprio componente do objeto que está sendo alterado. Assim, a tecnologia de componentes torna-se um facilitador para todas as de integração disponíveis (Sprott, 2000).

Na abordagem sistemática para integração entre sistemas de informação há conceitos, profissionais, técnicas, ferramentas, metodologia de trabalho e profissionais especializados na integração entre SIs, aglutinados em torno de um centro de competência integração de sistemas (CCIS). Este centro é responsável pela administração do ambiente de integração. Os profissionais do CCIS estudam a demanda de integração trazida pelas equipes de projeto de cada novo SI, analisando a tecnologia e a ferramenta mais apropriada para desenvolver os elementos de integração necessários. O gerenciamento contínuo e a evolução de cada elemento de integração é responsabilidade do CCIS (Gartner, 2003).

O conceito da tecnologia de componentes é intensivamente explorado na abordagem sistemática; ele é empregado para apresentar os diversos recursos computacionais como serviços disponíveis em um ambiente de integração. Seja uma fila de mensagens, uma tabela, um programa, todos se disponibilizam e se tornam acessíveis por meio de componentes. A utilização do ambiente de integração organiza e disciplina a comunicação entre esses diversos recursos, que é a antítese à "integração do tipo espaguete".

A análise das demandas tecnológicas e de negócio, possíveis de serem atendidas pelos modernos ambientes de integração, indica alguns dos principais benefícios da abordagem sistemática para integração entre SIs. Estruturando e explicitando estes benefícios, temos as seguintes declarações:

• a integração dos SIs reduz o retrabalho e favorece a automação de atividades. Redigitação de dados de um SI para outro é uma das atividades eliminada quando da integração entre sistemas. Ambos passam a acessar o mesmo dado ou transportam dados de um sistema para outro sem esforços humanos;

• o recebimento de dados num determinado SI pode representar um evento de negócio, a passagem direta e íntegra de um sistema para outro, amplia a oportunidade de se identificar e monitorar eventos de negócio. Quanto maior a abrangência dos eventos de negócio tratados, menores serão as exceções a serem tratadas pelos funcionários bem como os custos para operação do processo;

• cresce a capacidade da empresa em adaptar seus processos de negócios, que, tradicionalmente, envolvem grande número de SIs, tanto internos quanto externos à empresa. O ambiente de integração permite alterar de forma rápida, segura e com menores custos, os SIs utilizados para implementação de um novo processo de negócio;

• torna viável a expansão da empresa de forma consistente, por exemplo, ao permitir a empresa consolidar amplos conjuntos de SIs decorrentes de fusões e aquisições de outras empresas;

• viabiliza novos modelos de negócios, pela facilidade de incorporar e integrar novos SIs, por exemplo, facilitando a integração dos diversos

  softwares necessários à empresa que deseja implementar uma estratégia de gestão de relacionamento;

• maior agilidade e capacidade da empresa em atender às regulamentações do mercado, evitando expor a empresa às penalidades pela não observância de novas leis e regulamentações; e

• habilita a empresa para gestão de seus processos de negócio, ao prover-lhe facilidades para medição, automação, revisão, planejamento e evolução do processo, por intermédio da integração dos diversos

  softwares utilizados para operação e gerenciamento do processo.

Descrevemos, a seguir, a experiência do projeto de BPI implementado na empresa Global Village Telecom (GVT).

3. O desafio da integração entre sistemas na GVT

A GVT é uma empresa holandesa, composta por três grandes grupos internacionais de investimentos: 60% de capital europeu, por meio do Magnum Group; 28% de capital israelense, do IDB Group, e 12% de capital norte-americano, por meio do Merrill Lynch Group. No mercado brasileiro, a GVT atua desde 1999, quando obteve autorização da Agência Nacional de Telecomunicações - ANATEL - para operar na área de telefonia. No Brasil, a GVT tem 160 estações de rádio base, 1.000 Km de fibra óptica, gerenciadas por 1.400 funcionários. Esta estrutura é utilizada para o atendimento de 270.000 usuários de telefonia fixa. A empresa apresenta um forte ritmo de crescimento, com a venda de 1.000 linhas de telefones por dia (dados relativos a março de 2003).

Os serviços de telefonia fixa da GVT atendem 54 cidades brasileiras, distribuídas por dez Estados: Rio Grande do Sul, Santa Catarina, Paraná, Goiás, Distrito Federal, Mato Grosso, Mato Grosso do Sul, Acre, Tocantins e Rondônia. Além dos serviços de telefonia fixa, a GVT também presta serviços de acesso Internet e transmissão de dados.

A GVT considerou a importância estratégica da TI para sua operação desde o planejamento de sua estruturação inicial. Foi dada grande importância ao estabelecimento de uma arquitetura de SI funcionalmente eficaz e integrada. Esta arquitetura proposta foi disponibilizada em outubro de 2000 e destacava os seguintes sistemas corporativos:

• Sistema de gerência do relacionamento com clientes (

  CRM) – objetivando permitir que a empresa atue de forma bastante próxima e estratégica no relacionamento com os clientes. Para implementar estas funcionalidades, a

  GVT implantou a solução

  CRM da Siebel;

• Sistema de faturamento (

  billing) – visando ter uma plataforma robusta e confiável de suporte aos processos de faturamento. Para a implementação destas funcionalidades, a

  GVT adotou a solução Arbor, desenvolvida pela empresa CSG Systems;

• Sistema de provisionamento – voltado à administração do inventário da rede interna. Para implementar estas funcionalidades, a

  GVT implantou a solução Metasolv;

• SI geográfica (

  geographic information system/

  GIS) – voltado ao controle de inventário da rede externa. Para implementar estas funcionalidades, a

  GVT implantou a solução SAGRE, desenvolvida pela empresa CPqD; e

• Sistema de gerenciamento de equipes – objetivando coordenar a programação e atividades da equipe de técnicos de campo. Para implementar estas funcionalidades, a

  GVT implantou a solução

  Workforce Management - SGE, desenvolvida pela empresa CPqD.

A forte interdependência lógica entre estes sistemas fez a equipe da GVT apontar a solução a ser adotada para integração entre sistemas como sendo um componente de alto risco para o ambiente informacional. Este risco à época, janeiro de 2000, era caracterizado por:

• tempo exíguo para planejar, montar e disponibilizar a solução de integração. A empresa necessitava ter os processos de venda, instalação e faturamento operando de forma integrada e automatizada, por meio da interação eficaz dos novos SIs implementados em outubro de 2000;

• pouco conhecimento técnico da equipe e dos profissionais de TI sobre as inovadoras soluções para integração entre sistemas; neste período, estas soluções eram centradas em

  softwares EAI (

  Enterprise Application Integration). O projeto de

  BPI da

  GVT está entre os primeiros casos brasileiros em termos de abrangência de escopo e complexidade;

• os SIs a serem integrados eram todos críticos ao negócio, com influência direta na percepção do cliente em relação aos serviços da empresa e com implicações direta no resultado financeiro da empresa; e

• além de prazo exíguo, do risco do desconhecido e complexo, da natureza crítica dos sistemas envolvidos, a equipe de TI ainda compartilhava seu tempo no suporte a outros dezessete projetos de TI em andamento. Estes eram conduzidos por diversas equipes de trabalho, que envolviam 250 profissionais.

Na Figura 1, podemos observar que há dois meios principais empregados para troca de dados na arquitetura de SI da GVT: os principais sistemas corporativos trocam dados entre si por uma seta bidirecional, que representa o software para gerenciamento de mensagens da Vitria, solução adotada pela GVT para compor o ambiente de troca de dados via mensagens. As demais integrações ocorrem por programas de chamada ou call interface, representadas por uma seta fina, conforme descrito na legenda do gráfico.

Das razões administrativas apresentadas como causas para a forte demanda por soluções BPI, quase todas se aplicaram ao contexto da GVT, com exceção da integração por motivo de ampliação do portifólio de sistemas por fusões e aquisições de empresas. A GVT optou pela estratégia best of breed, tanto que não há um sistema que seja preponderante sobre os demais; pode-se observar isto pela descrição da solução ERP na Figura 1, ela abarca apenas algumas funcionalidades. Também se priorizou a compra de sistemas prontos ("pacotes"). Todos os representados na Figura 1, por meio de um retângulo com cor de fundo branco, representam os sistemas internos de posse da GVT: estes são SIs comercializados por fornecedores de softwares nacionais e internacionais que estão entre as líderes nos seus segmentos de software. A entrega de serviços consolidados aos clientes também foi um forte motivador da solução, conforme poderemos notar no exemplo do processo de negócio analisado neste artigo.

4. O projeto de BPI da GVT

O projeto de BPI da GVT teve origem na idéia de se criar um ambiente de integração para os SIs corporativos e críticos à operação do negócio, aqueles voltados aos processos de venda, instalação e faturamento. O objetivo principal deste componente importante da estratégia de TI da GVT, na época denominado de solução EAI, foi de evitar problemas tecnológicos para troca de dados entre sistemas. Esta demanda tecnológica, ou seja, camada integradora via EAI, foi descrita por meio dos seguintes requisitos:

• integrar sistemas por meio de arquitetura de comunicação baseada em mensagens;

• evitar integrações isoladas ou individuais entre dois sistemas;

• trabalhar com os adaptadores pré-construídos e disponibilizados pelas camadas integradoras (

  softwares EAI) para os principais SIs comercializados, evitando assim esforços para integração entre sistemas;

• ter uma central de controle para acompanhamento de processos de negócio que envolva passos, executados por múltiplos

  softwares em diversas plataformas tecnológicas;

• assegurar que os objetos da camada de integração (componentes de integração, regras para tratamento de eventos) sejam flexíveis o suficiente para atender ao dinamismo do ambiente de negócios, permitindo, por exemplo, reutilização e modularidade; e

• tratar a troca de dados entre as diferentes gerações de sistemas:

  real-time, e-business, on-line e batch.

A integração entre os SIs corporativos selecionados se deu em fases, em momentos distintos, para eventos distintos e com ações específicas. As integrações por meio do ambiente BPI ocorreram ao longo do tempo, à medida que a camada integradora era configurada para reconhecer e tratar os diversos eventos de negócios que requeriam interação entre sistemas. A evolução cronológica da camada integradora da GVT ocorreu em versões:

• A

  versão um foi entregue em novembro de 2000 e tinha como foco principal a integração entre os sistemas de faturamento,

  CRM, provisionamento, gerenciamento de equipes e

  GIS. Neste estágio, havia dois ambientes de integração: a camada de integração do Vitria e o ambiente de integração CORBA. O primeiro ambiente tratava da conexão de três eventos de comunicação da área de engenharia: sistema de provisionamento, SI geográfica e gerenciamento da força de trabalho. O segundo ambiente tratava de treze eventos de comunicação da área comercial, que ocorriam entre os sistemas de faturamento e

  CRM. Não havia comunicação entre estes dois grupos de sistemas. A existência de dois ambientes de integração ocorreu em função da urgência de sua disponibilidade e a incompatibilidade com os prazos estimados para aquisição e aculturamento no ambiente Vitria. Assim, optou-se por iniciar a construção do ambiente de integração no CORBA, que já estava disponível e era de domínio da equipe

  GVT;

• A

  versão dois foi entregue em fevereiro de 2001, com o objetivo de integrar na plenitude as comunicações entre os sistemas comerciais e os da engenharia. Neste estágio, ainda coexistiam as duas camadas de integração, que juntas tratavam de 26 eventos de negócios;

• A

  versão três foi entregue em setembro de 2001, com o objetivo de a camada integradora abranger o tratamento de outras Ordens de Serviços, como mudança de endereço e adição de serviços. Neste estágio, todos os eventos passaram a ser integrados por meio do ambiente Vitria, que tratava de 48 eventos de negócios; e

• A

  versão quatro foi entregue em novembro de 2001, com o objetivo de integrar por meio da camada os eventos de comunicação com sistema

  SWITCH, que é a própria central de comutação. Após a liberação desta versão, a camada integradora passou a tratar de 50 eventos de negócio.

Para melhor compreensão dos esforços necessários para implementação de uma solução BPI, é apresentado, na Tabela 2, o total de recursos humanos especializados para se disponibilizar cada uma das fases da solução da GVT. Estes recursos foram utilizados para configurar o ambiente para tratamento de eventos da camada integradora e para construção de componentes de integração dos sistemas que se comunicam via camada integradora. Esta última demanda foi reduzida devido à maioria dos sistemas serem amplamente difundidos no mercado e já possuírem componentes (drivers) incorporados ao ambiente Vitria.

Para cada evento de negócio que gere interação entre SIs, há a necessidade de se executar um conjunto de atividades de forma que esta interação possa ocorrer via camada de integração. A seguir, é apresentada a metodologia empregada pela equipe do projeto, descrevendo suas fases e as técnicas empregadas em cada uma delas:

A)Análise de requisitos: identifica e analisa as necessidades de negócio junto às diversas áreas da empresa, entrevistando clientes internos da TI, localizados nas diversas áreas de negócio envolvidas com o processo. Esta atividade é conduzida por analistas de negócio e tem como objetivo principal formar um entendimento comum entre os envolvidos com os requisitos do projeto. A abordagem utilizada baseia-se na análise de processos;

B)Projeto funcional da integração: formaliza os requisitos levantados na etapa anterior usando modelos lógicos. As principais técnicas empregadas são o Diagrama de Classe, Diagrama de Evento e o Caso de Uso (use case);

C)Projeto detalhado: refina os modelos lógicos com mais detalhes de implementação. As principais técnicas empregadas são o Diagrama de Colaboração e a Descrição de Eventos;

D)Construção: codificação dos modelos gerados nas fases anteriores em linguagem computacional. As principais técnicas utilizadas nesta fase são: classes Java, classes C++ e CORBA IDL's;

E)Teste de Montagem: testa isoladamente se os eventos de negócio tratados são transmitidos corretamente, ou seja, se os componentes de integração estão se comunicando corretamente. Este tipo de teste é realizado pela própria equipe de desenvolvimento; e

F)Teste Integrado: testa a solução de integração sob a ótica do cliente, ou seja, do processo de negócio (fim a fim). Este tipo de teste é realizado por uma equipe especial de teste integrado que envolve os usuários finais de todas as áreas envolvidas com o processo.

4.1 Exemplos de aplicação prática da solução BPI na GVT

Como exemplo de aplicação prática da camada integradora de SI disponibilizada pela solução BPI, é descrita a utilização desta na integração de diversos softwares utilizados para execução do processo "Atender Solicitação de Instalação de Nova Linha de Telefone". A Figura 2 apresenta um diagrama dos principais eventos de negócio desse processo, que demandam diversas integrações entre SIs, ocorrendo a maioria de trocas de dados por meio de software de gerenciamento de mensagens.

O Processo de Venda se inicia quando um potencial cliente liga para o call center da GVT solicitando a contratação de serviço de uma linha telefônica. Por meio da solução CRM, o atendente abre uma conta para este cliente. Uma conta representa um cliente, contendo suas informações cadastrais. Na seqüência, há a verificação do endereço, se está localizado numa área de cobertura da GVT; para isto, é necessário acessar a base de dados do sistema GIS. A troca de dados entre o sistema CRM e o GIS ocorre por meio de um programa de interação do tipo call interface, que na Figura 2 está denominado como verifica cobertura. Caso a área solicitada não seja atendida pela GVT, o processo é encerrado e o cliente é assinalado como prospect. Para isto, altera-se o valor de um dos atributos que adjetivam a conta. Caso contrário, abre-se uma ordem de serviço (OS) para o cliente em questão. Uma OS representa um pedido do cliente, por exemplo: OS de Instalação de Linha ou OS de Alteração de Endereço.

Depois que as informações do cadastro do cliente (conta) e do pedido (OS) estiverem preenchidas, o atendente solicita ao sistema CRM o provisionamento da OS. Por meio deste evento, o conector da solução CRM com o sistema de gerenciamento de mensagem dispara dois eventos assíncronos: conta criada e OS criada. A solicitação do provisionamento, com o disparo destes eventos, caracteriza o encerramento do Processo de Venda e o início do Processo de Instalação.

Assim que a camada integradora detecta a recepção de uma nova mensagem de conta criada, o sistema de gerenciamento de mensagem, por meio de seu ambiente de regras para tratamento de eventos, verifica as ações pré-programadas para tratar este tipo de evento. Neste caso, a lógica da camada integradora é disparar o evento cria conta serviço, que é uma transmissão de dados para o sistema de provisionamento de serviços. Da mesma forma, quando a camada integradora percebe o recebimento de uma nova mensagem de OS criada, o sistema de gerenciamento de mensagem irá disparar:

• o evento

  abre OS, que transmitirá dados para o sistema de

  provisionamento; e

• o evento

  aloca facilidade irá transmitir dados ao sistema

  GIS, responsável por reservar a facilidade. O termo

  facilidade, no âmbito das telecomunicações, significa o recurso físico que possibilita o acesso do cliente assinante à rede de telecomunicações fixa. Para cada telefone fixo deve existir uma

  facilidade disponível.

Uma vez que o sistema GIS informe à camada integradora que a facilidade foi alocada, esta irá disparar o evento ativa serviço. A camada envia dados que permitem ao sistema SWITCH, a central de comutação, fazer a ativação automática do serviço da linha telefônica na central da GVT. A camada integradora, ao receber uma resposta do sistema SWITCH, confirmando que a linha telefônica foi ativada na central, dispara o evento cria BA, que transmite dados para o sistema de gerenciamento de equipes, e lhe permitirá abrir um boletim de atividade (BA). Este documento contém todas as informações necessárias para que o técnico de campo possa realizar a instalação da linha telefônica. O tempo decorrido, entre o preenchimento dos dados da OS pela atendente até a geração do BA, está na escala de minutos. Antes da implementação da camada de integração entre sistemas, este tempo girava em torno de dias e a ocorrência de inconsistências nas bases dos sistemas era elevada.

Depois que o evento cria BA é gerado, a camada integradora aguarda até o encerramento do BA, pela identificação do evento BA fechado. Este é gerado pelo sistema equipes após alguns poucos dias, quando do informe dos técnicos de campo que a linha telefônica está instalada e testada no local indicado pelo cliente. Quando da ocorrência deste evento, a camada integradora dispara alguns eventos:

• Ocupa facilidade: este evento solicita ao

  GIS a ocupação da facilidade que fora previamente alocada pelo evento

  aloca facilidade. Após o

  GIS alterar o status da facilidade de reservado para ocupado, este sistema informa a camada de integração que a facilidade já está designada, para isto, dispara o evento

  facilidade ocupada; e

• Ativa elementos: remete dados ao sistema

  CRM, informando que os serviços solicitados pelo cliente e descritos na OS já foram realizados. O sistema

  CRM ao receber estes dados, atualiza seus dados internos e dispara o evento

  instância ativada.

De forma objetiva, uma instância representa um ponto de acesso à rede de telecomunicações, ou seja, uma linha telefônica. A detecção do evento instância ativada pela camada integradora, significa que a linha telefônica foi instalada com sucesso, podendo-se iniciar o Processo de Faturamento. Para isto, a camada integradora dispara os eventos:

• Cria conta cobrança, que remete informações cadastrais de faturamento para o sistema de

  faturamento, ou seja, a camada integradora solicita a abertura de uma conta de cobrança no sistema de

  faturamento; e

• Cria instância: com este evento, a camada integradora solicita ao sistema de

  faturamento a criação de uma instância de serviço. A partir deste momento, o sistema de

  faturamento está apto a gerar a fatura para o cliente.

Quando o sistema GIS informa à camada integradora que a facilidade já está ocupada, por meio do evento facilidade ocupada, a camada dispara o evento Status OS, que envia dados para o sistema de provisionamento, atualizando sua base de dados e interage, via call interface, com o sistema CRM. Na Figura 2, esta interface está denominada como completa OS. Este evento indica que a OS foi aprovisionada completamente, ou seja, que todos recursos de rede necessários para o serviço solicitado pelo cliente foram alocados, configurados e ativados. Este evento encerra o Processo de Instalação.

Quando um sistema é acionado por um conector da camada integradora, o sistema acionado irá transmitir o status da operação solicitada de volta à camada integradora. Por exemplo, se o sistema de provisionamento não conseguir realizar sua transação, este retornará à camada integradora um sinal de ocorrência de problema, que será comparado com os acionadores de evento disponíveis e disparará as ações pertinentes. Todos os eventos possuem tratamento de erros, que foram omitidos visando a não dificultar o entendimento do exemplo com volumes excessivos de informações.

A utilização do ambiente de integração de processos de negócio no suporte à execução do processo "Atender Solicitação de Instalação de Nova Linha de Telefone Fixo" trouxe ganhos qualitativos e operacionais. Descreveremos a seguir alguns indicadores do processo:

• tempo para ativação do serviço solicitado pelo cliente reduziu de dias para minutos;

• os esforços manuais para provisionamento de serviços reduziram em 60%; e

• as reclamações do cliente devido a inconsistências do processo reduziram em 80%.

5. Conclusões

As conclusões finais foram desenvolvidas a partir da experiência relatada pela empresa GVT, conciliadas com a pesquisa bibliográfica e experiência técnica dos autores em relação ao tema. As análises finais foram estruturadas considerando-se: as empresas que estejam analisando a possibilidade de iniciar um projeto de BPI, as que já se decidiram e se preparam para iniciar tal projeto, bem como análise do potencial de evolução da solução para aquelas que já o implementaram.

5.1 Do preparo prévio da organização para implementação de soluções BPI

Um importante questionamento que o administrador de SI deve fazer antes de decidir iniciar um projeto BPI é se a empresa, mais especificamente sua equipe de TI, está preparada tecnicamente para o desafio. Um dos principais parâmetros utilizados para mensurar o preparo desta equipe é a análise das tecnologias e técnicas empregadas pela organização na integração de seus SIs.

Ter domínio das tecnologias de componentes para integração entre sistemas é fundamental às organizações que pretendam implantar uma solução BPI. Como observado no caso GVT, já havia expertise na integração via componentes, tanto que as versões um e dois da camada integradora contemplava integrações via CORBA. Desta forma, uma importante recomendação para os administradores de SI que pretendam implantar solução BPI é assegurar que a equipe já tenha domínio da tecnologia de interfaces via componentes. Caso não haja este expertise, é importante desenvolvê-lo; para isto, não há necessidade de investimentos em softwares específicos, os componentes podem ser criados utilizando-se softwares disponíveis na infra-estrutura básica dos ambientes computacionais.

5.2 Do planejamento e condução do projeto BPI

Considerando que a empresa já domine a cultura de interface via componentes, o próximo passo é planejar o projeto de implementação da solução BPI. Há alguns aspectos importantes a serem observados durante o planejamento. Para isto, são referenciados os conhecimentos gerados a partir da experiência prática do caso GVT. Entre as principais lições aprendidas pela equipe GVT, sobre a implementação de uma solução BPI, destacam-se:

• antes de iniciar um projeto BPI é essencial que a equipe tenha um profundo conhecimento e domínio da ferramenta e das técnicas a serem empregadas para o gerenciamento e operação da camada de integração. No caso da

  GVT, a equipe de projeto selecionou a ferramenta Vitria, a qual era baseada em computação distribuída, tecnologia Java e orientação a objetos. A combinação destes conceitos contribui para construção de arquiteturas modulares eficazes. Entretanto, para obter resultados efetivos desta combinação, é essencial que o profissional de TI tenha uma formação acadêmica adequada e esteja plenamente capacitado. Realizar treinamento ao longo do projeto pode ser arriscado. A equipe base de desenvolvimento da

  GVT era composta de 3 mestres em informática aplicada, 3 especialistas em computação, 2 engenheiros de computação e 3 cientistas de computação, o que foi decisivo para o sucesso do projeto;

• mesmo se empregando as modernas ferramentas de BPI, há a necessidade de se programar e construir códigos de programas. No início do projeto, havia a expectativa de se ter a maioria das necessidades de integração resolvida por componentes,

  softwares pré-construídos e já disponibilizados pelo

  software que implementaria a camada de integração. Entretanto, observou-se que a customização destes inúmeros componentes de

  software exigiu níveis mais elevados de programação do que o previsto, principalmente para acessar as APIs proprietárias dos sistemas. Conseqüentemente, houve maior necessidade de

  expertise e esforço da equipe para desenvolver e gerenciar o código excedente;

• a ferramenta BPI deve ter mecanismos eficazes para o tratamento de erros no processo. Como o ambiente de execução dos SIs e os próprios processos de negócio são de natureza complexa, é inevitável a ocorrência de erros, tais como falhas de

  software,

  hardware e atividades manuais que geram dados inconsistentes. Assim, a camada integradora deve monitorar permanentemente todos processos de sistema, gerando antecipadamente alertas para potenciais problemas, além de disponibilizar planos de contingência como recuperação de

  back-ups, reexecução de processos, redisparo, balanceamento e priorização de eventos de negócio; e

• é muito importante que a solução de integração tenha facilidades para disponibilizar informações sobre a execução dos processos de negócio implementados por meio dela. Desta forma, decisões gerenciais podem ser tomadas em função do desempenho de determinadas áreas de negócio, por exemplo: quantas Ordens de Serviço de Instalação foram abertas nas últimas 24 horas. A visibilidade das informações além de servir como indicador de

  performance pode ser útil para diagnosticar eventuais falhas como, por exemplo, a ausência de eventos

  cria conta pode significar uma possível falha de algum componente da solução.

5.3 Das tendências para evolução da solução BPI

As pesquisas bibliográficas realizadas, bem como a análise da expectativa de evolução do próprio caso pesquisado, identificou a tendência de evolução da solução BPI visando à gestão de processos de negócio. Esta expansão da solução BPI está sendo denominada de Business Process Management (BPM). Entre as principais funcionalidades incorporadas à solução BPI que a promove ao status de solução BPM estão (McCormack e Johnson, 2001):

• existência de um ambiente de representação lógica do processo, por meio de diagramas gráficos que auxiliem no projeto do processo, na sua simulação, no seu acompanhamento e operação e nas alterações necessárias para sua evolução;

• o gestor do processo pode acompanhar a execução deste em tempo real, observando o status da operação: gargalos,

  throughput, caminho crítico, tempos médios de cada atividade envolvida;

• facilidades para criação de interfaces que permitam a interação humana ao longo do processo, por exemplo, um passo que solicite o parecer de um profissional;

• qualquer instância pode ser pesquisada a qualquer momento, podendo se obter a previsão de tempo para seu término, status atual ou o detalhamento das atividades já executadas;

• facilidades para publicação do processo via Internet, permitindo aos gestores discutir e aprimorar o processo - neste caso, os diagramas da estrutura do processo - para que os executores possam interagir com sua execução e monitoramento; e

• o gestor do processo pode prever ações corretivas na ocorrência de gargalos, por exemplo, boletins de atividade abertos há mais de dois dias devem ser informados ao supervisor da equipe de técnicos de campo e ao representante comercial responsável pela conta.

O estágio atual das propostas e modelos administrativos para gestão de processos, bem como a maturidade tecnológica dos softwares e ferramentas que atendam de forma cada vez mais abrangente e integrada aos diversos requerimentos da gestão de processos, já constituem um ambiente que habilita as soluções BPI evoluírem para gestão de processos, isto é, para uma solução de BPM (Burlton, 2001). A adoção deste ambiente de negócios, fundamentado em TI, passa obrigatoriamente pelo domínio e eficácia das integrações entre SIs. Neste sentido, o domínio das melhores estratégias, técnicas e ferramentas para integração entre sistemas, passa a ter uma prioridade ainda maior na agenda dos CIOs, devido a seu valor estratégico em habilitar inovações na gestão de processos.

Recebido em 03/12/2004

Aceito em 29/11/2005

• BELL, B. S.; KOZLOWSKI, S. J. A typology of virtual teams: Implications for effective leadership. Group & Organization Management, Thousand Oaks, v. 27, n. 1, p. 14-49, jan./mar., 2002.
• BONOMA, T. V. Case Research in Marketing: Opportunities, Problems, and Process. Journal of Marketing Research, Chicago, v. 22, n. 2, p. 199-208, mar./may 1985.
• BURLTON, R. Business process management Indianápolis: SAMS publishing, 2001.
• BUTLER. Butler Group. Application integration management guide: strategies and technologies Hull: Butler Group Limited, 1999.
• CUMMINS, F. A. Enterprise integration: an architecture for enterprise application and systems integration New York: John Wiley & Sons, 2002.
• DE SORDI, J. O. Tecnologia da Informação Aplicada aos Negócios São Paulo: Atlas. 2003.
• GARTNER. Going beyond IT ROI – Estimating the business value of process integration solutions Stanford: Gartner Group, 2003.
• HASSELBRING, W. Information system integration. Association for Computing Machinery - Communications of the ACM, New York; v. 43, n. 6, p. 32-38, jun. 2000.
• McCORMACK, K., JOHNSON, B. Business process orientation, supply chain management, and the e-corporation. IIE Solutions, Norcross, v. 33, n. 10, p. 33-37, out. 2001.
• MEEHAN, M. IT Managers Make EAI Projects a Top Priority. Computer World, Framingham, v. 36, n. 6, p. 14, feb. 2002.
• MURPHY, C. Tying it all together. Information Week, Manhasset, n. 931, p. 34-38, mar. 2003.
• PUSCHMANN, T., ALT, R. Enterprise Application Integration: The Case of Robert Bosch Group. In: INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES, 34^th, 2001. Hawaii. Proceedings Hawaii: IEEE, 2001.
• RUH, A. W.; MAGINNIS, F. X.; ROWN, W. J. Enterprise application integration New York: John Wiley & Sons, 2001.
• SPROTT, D. Componentizing the Enterprise Application Packages. Association for Computing Machinery - Communications of the ACM, New York, v. 43, n. 4, p. 63-69, apr. 2000.
• YIN, R. K. Estudo de Caso: planejamento e métodos 3. ed. Porto Alegre: Bookman, 2005.

Datas de Publicação

• Publicação nesta coleção
  12 Jun 2006
• Data do Fascículo
  Abr 2006

Histórico

• Aceito
  29 Nov 2005
• Recebido
  03 Dez 2004