rea Temtica: Gesto de Tecnologia da Informao Ttulo do Trabalho: Controlando a Integrao de Sistemas no Ambiente do Governo Resumo A integrao de sistemas

de informao ocorre quando dois ou mais sistemas trocam informaes eletronicamente para atender as necessidades de um ou mais usurios. Trata-se, para o governo eletrnico, de um importante passo para a disponibilizao de servios eletrnicos ao cidado atravs de uma nica janela de acesso. Porm, ao construir um sistema de informao que precisa se integrar a outro sistema de informao, de outro rgo do governo, surge uma questo desafiadora, interessante e pouco explorada: Como controlar este complexo ambiente? Este trabalho modela o processo de controle do ambiente de integrao de sistemas de um rgo pblico referncia em tecnologia da informao (as is), implanta trs novos processos de controle (to be) e avalia seus resultados. So contribuies chave deste artigo: (1) Identificao que a mudana de requisitos o fator mais problemtico para as fases de projeto fsico das integraes; (2) Proposta de um modelo de controle preparado para minimizar retrabalhos decorrentes da mudana de requisitos; (3) Apresentao de um modelo que promove padronizao, comunicao sistemtica, gesto de conhecimento, diviso de responsabilidades e melhoria contnua. Abstract Information systems integration occurs when two or more systems exchange information electronically to meet the needs of one or more users. It is, for the electronic government, an important step for the provision of electronic services to citizens through a single access window. However, control the complex environment in a construction of an information system that integrates with other systems owned by different government agencies is challenging, interesting and little exploited. This paper models the control process of systems integration environment (as is) in a Brazilian public agency that is reference in information technology, deploys three new control processes (to be) and evaluates its results. The key contributions in this paper are: (1) identification that changing requirements is the most problematic factor for physical design phases of integrations; (2) proposal of a control template prepared to minimize rework resulting from change of requirements; (3) presentation of a model that promotes standardization, systematic communication, knowledge management, Division of responsibilities and continuous improvement. Palavras chave: Sistemas de Informao, Integrao de Sistemas, Governo Key words: System Information, System Integration, Government

Introduo

A prtica de Integrao de Sistemas no governo contribui para a resoluo de problemas como redundncia e inconsistncia de dados, servios com responsabilidades compartilhadas, interconectividade entre aplicaes, no coordenao interdepartamental, privacidade e segurana de dados do cidado, padres de compartilhamento de dados, alto custo de manuteno de sistemas heterogneos, integridade e qualidade de dados, no interoperabilidade entre sistemas de informao e falta de viso uniforme do cidado (Kamal & Themistocleous, 2006). Por outro lado, barreiras gerenciais como a falta de capacidade de gerenciar projetos de Tecnologia de Informao (TI) de larga escala, falta de convico por parte da alta e mdia administrao, conflitos entre expectativa e realidade, dvidas e resistncia dos lderes, oposio por unio ou interesses profissionais, frameworks obsoletos para inovao, gesto inadequada da informao, relutncia de compartilhamento entre departamentos e uso inadequado de dados relevantes desafiam as organizaes pblicas no alcance do Governo Eletrnico (Huang & Bwoma, 2003). Por tudo isso, e em especial nos casos de servios de governo eletrnico que necessitem de interoperao entre mais de um sistema de informao para satisfazerem as necessidades de acesso do cidado, compreender como controlar as integraes entre sistemas de informao no governo contribui para a superao de barreiras gerenciais e promove a efetividade na produo de servios de governo eletrnico. Alm disso, conhecer como controlar a Integrao de Sistemas promove a efetividade do prprio governo na busca por todas as vantagens que decorrem do uso de Sistemas de Informao. Por isso, traou-se o seguinte objetivo de pesquisa: Na construo de um Sistema de Informao que integre diversas funes organizacionais, analisar como controlar as integraes que este sistema ter com os demais sistemas de informao existentes na organizao. um objetivo complementar deste artigo demonstrar como um rgo pblico superou parte das citadas barreiras gerenciais que dificultam a prtica da integrao de sistemas. 2 2.1 Marco Terico Processos Organizacionais

Em organizaes, existem processos que cumprem determinadas funes de negcio. Processo de negcio um conjunto de atividades que, quando executadas juntamente, produzem um resultado de valor para o cliente (Hammer & Champy, 1993). A Workflow Management Coalition define processo de negcio como um conjunto de uma ou mais atividades ligadas que, coletivamente, realizam um objetivo de negcio ou atendem uma poltica. Esta realizao normalmente se desenvolve no contexto de uma estrutura organizacional, define regras e estabelece relacionamentos entre as estruturas funcionais da organizao (WfMC, 1999). Em sntese, processos de negcio so executados por atores que se seguem regras particulares, consomem recursos e produzem outros. As atividades do processo podem ser engatilhadas por eventos e podem gerar eventos. Os atores operam em um contexto com fronteiras organizacionais e em atividades que podem depender da realizao de outras

atividades. As organizaes, por sua vez, executam funes especficas de negcio e as regras do suporte a essas funes (Mili et al., 2010). Na viso Taylorista, considera-se o negcio como uma organizao hierrquica que reflete uma cadeia de comando e uma decomposio funcional dos servios e produtos da organizao. Diferentes departamentos se especializam em funes especficas de negcio. Os indivduos ou departamentos subordinados aos primeiros se especializam em funes derivadas das funes de negcio. O processo de atendimento de um cliente, por exemplo, pode atravessar a fronteira de vrios departamentos: o de vendas recebe os pedidos, outro departamento planeja a viagem do produto at o cliente, outro se encarrega da produo, outro do transporte e, ainda, outro departamento pode ficar encarregado da cobrana (Mili et al., 2010). As primeiras teorias gerenciais focam no trabalho que ocorre na hierarquia e no gerenciamento de suas divises (cadeia de comando, workflow, gesto do custo, comunicao, etc.), mas com foco em cada diviso isoladamente (Hammer & Champy, 1993). Com o advento da chamada Reengenharia dos Processos de Negcio, uma nova forma de pensar tomou lugar: em vez do foco em cada funo de negcio separadamente, portanto no questionadora da estrutura total que apoia o processo de negcio, pesquisadores comearam a advogar que algum deveria olhar para o processo como um todo na organizao, entendendo, tratando e simulando a transao de negcio de ponta a ponta, bem como procurando por maneiras de aperfeioar o processo de negcio como um todo (Hammer, 1990; Hammer & Champy, 1993). Nesta viso, diferentes processos de negcio no necessariamente cruzam as mesmas fronteiras organizacionais ou no as atravessam da mesma maneira, abrindo espao para novas formas de estruturao organizacional. Representam, neste caso, as referidas novas formas a estrutura orientada a projetos e a estrutura em forma de matriz (Mili et al., 2010). A Reengenharia de Processos de Negcio renovou o interesse na modelagem de processos de negcio como pr-requisito para o processo de anlise e melhoria. O advento do comrcio eletrnico amplificou ainda mais o interesse pela melhor compreenso e modelagem de processos organizacionais (Mili et al., 2010). Parte da motivao para a reengenharia dos processos de negcio advm da evoluo das novas tecnologias, onde se busca a mudana dos processos de negcio com vistas em aproveitar a capacidade dos computadores no desempenho de atividades onde os seres humanos so pobres executores (Hammer & Champy, 1993). Podemos distinguir os processos das organizaes em trs tipos: corao, suporte e gesto. Nesta distino, os processos corao so os que atendem aos clientes. Os processos de suporte apoiam os empregados que executam processos corao. Por fim, os processos de gesto gerenciam tanto os processos corao quanto os de suporte (Ould, 1995). De maneira ampla, melhorar processos corao representa melhorar a satisfao do cliente, melhorar processos de suporte representa melhorar a eficincia da organizao e melhorar processos de gesto representa melhorar a estrutura da organizao (Ould, 1995). Em muitos cenrios a evoluo de processos e a implantao de Sistemas de Informao ocorre de maneira improvisada (Hammer, 1990). Tanto neste contexto, quanto no de reengenharia de processos com vistas em aproveitar as capacidades computacionais, as

organizaes acabam desenvolvendo ntimas relaes entre os processos de negcio e os Sistemas de Informao participantes. Portanto, avaliar e medir os impactos nos processos de negcio sobre o qual se pretende realizar integraes entre sistemas tende a aumentar as chances de sucesso na realizao destas. 2.2 Sistemas de Informao e Organizaes Pblicas

Organizaes pblicas so sistemas complexos, com alta aplicao de burocracia no funcionamento, e que no apresentam garantias quanto rapidez, boa qualidade e custo acessvel para os servios prestados aos cidados ou a seus clientes internos (Saraiva & Capelo, 2000). Um problema que se sobressai que a insatisfatria qualidade na prestao dos servios pblicos reduz a expectativa em relao ao potencial destes servios. Consequentemente, cria-se um ciclo onde a falta de satisfao alimenta a reduo na expectativa do ciclo seguinte, gerando, como efeito, a frustrao de gerentes e usurios (Pires & Macdo, 2006). De forma geral, caractersticas marcantes das organizaes pblicas so: a fidelidade s regras e rotinas; a supervalorizao da hierarquia; apego ao poder; paternalismo das relaes. Tais caractersticas refletem na postura dos recursos humanos, nas crenas organizacionais, na definio dos processos internos e na forma da organizao lidar com inovaes e mudanas (Rosseto, Orth, & Rosseto, 2004). Diversas iniciativas tm sido adotadas com vistas em melhorar a eficincia das organizaes pblicas. Estratgias como a criao de agncias semiautnomas, introduo de medidas de desempenho, administrao gerencial baseada no estilo de negcio do setor privado, nfase na qualidade e em servios pblicos orientados para o cidado, entre outras, tem sido aplicadas em diversos pases (Seabra, 2001). O uso de Sistemas de Informao no setor pblico tem promovido o aumento da transparncia da gesto e tem sido visto como um importante mecanismo primrio para criar servios melhores nas organizaes (Laudon, 2009; B Rocheleau, 2000). Alm da grande preocupao com a transparncia, observa-se nos Sistemas de Informao do governo acentuada complexidade em funo de preocupaes como a prestao de contas e a grande quantidade de leis que regem o setor (Bruce Rocheleau & Wu, 2002). No caso dos sistemas crticos, a quantidade de informao dos processos e a natureza poltica da tomada de deciso tambm corroboram para o aumento da complexidade, bem como torna os sistemas volteis. Outro fator que acentua a complexidade a necessidade de segurana jurdica do cidado e igualdade de direitos (Looff, 1996). Por conta da natureza que liga os Sistemas de Informao aos negcios, tanto nas empresas privadas quanto nas pblicas, ocorrem manutenes com vistas em aperfeioar processos e corrigir problemas decorrentes da volatilidade do ambiente externo (Laudon, 2009). Nestes cenrios, os motivos das manutenes de Sistemas de Informao nas empresas pblicas muitas vezes se distinguem das organizaes privadas por decorrerem de

reorganizaes administrativas e mudanas na legislao. Em contrapartida, as organizaes privadas evoluem com maior agilidade e frequncia na busca por competitividade (Looff, 1996). Em muitos cenrios de mudana em Sistemas de Informao, a mudana precisa ser realizada de forma acelerada, muitas vezes induzindo ao erro por ausncia de testes exaustivos que demandariam tempo alm do que se poderia esperar (Bruce Rocheleau & Wu, 2002). 2.3 Integrao de Sistemas

A Integrao de Sistemas um fenmeno que ocorre quando mais de um sistema de informao colaboram eletronicamente para atender um objetivo comum. Estas integraes podem ocorrer entre Sistemas de Informao diferentes ou ainda entre mdulos de um nico sistema quando este muito grande, como, por exemplo, sistemas ERP (Sommerville & Melnikoff, 2003). Summerville (2003) destaca que uma das dificuldades da Integrao de Sistemas reside nos testes de integrao. Nestes testes, localizar os erros ocorridos durante o processo de integrao uma tarefa complexa porque, quando as interaes entre os componentes do sistema resultam em uma sada anmala, a origem do erro poucas vezes fica em evidncia. Uma abordagem que pode ser utilizada para facilitar a localizao dos erros , inicialmente, integrar uma configurao mnima do sistema e test-lo. Em seguida, so adicionados componentes a essa configurao mnima, que testada depois de cada componente adicionado. Entretanto, a realidade raramente to simples. Os recursos do sistema podem estar distribudos em uma srie de componentes. Testar um recurso, portanto, pode exigir a interao de diversos componentes diferentes. O teste pode revelar erros nas interaes entre esses componentes individuais e em outras partes do sistema. Reparar erros pode ser difcil, porque isso afeta todo o grupo de componentes que implementam o recurso do sistema. Alm disso, quando um novo componente integrado e testado, isto pode modificar o padro de interaes prvias de componentes, j testadas. Podem ser revelados erros que no haviam sido detectados nos testes de configurao mais simples (Sommerville & Melnikoff, 2003). Quando temos ainda diferentes funes organizacionais responsveis por diferentes componentes do sistema, a resoluo de problemas de integrao se torna muito mais ampla, extrapolando questes sintticas e envolvendo a anlise de frameworks estratgicos para a colaborao, a reengenharia de processos de negcio, o tratamento da resistncia mudana, a segurana e privacidade dos dados, a poltica de interoperabilidade, o expertise de gerentes em integrao de sistemas e os investimentos em TI (Kamal & Themistocleous, 2006). 3 Mtodo da Pesquisa

No rgo pblico estudado, foi localizado um ambiente onde ocorra a integrao de sistemas. A partir deste ambiente, foi observada a pgina de internet oficial da empresa para mapear a estrutura organizacional que se relaciona com esse ambiente especfico. A partir desta descrio de ambiente, foi mapeado, atravs de observao participante e consulta de intranet da empresa, o processo de controle das integraes nesse ambiente (verso as is). Foram destacadas oportunidades de melhoria e, a partir destas, elaborou-se

uma proposta de processo de negcio para controlar as integraes (verso to be) neste sistema. Na referida proposta se apresentou um plano para a execuo da mudana e, por fim, realizou-se uma avaliao ps-implantao com o objetivo de identificar os resultados e lies aprendidas. 3.1 Objeto de Estudo

Esta pesquisa se desenvolveu em uma empresa pblica responsvel pela administrao da tecnologia da informao de dezenas de rgos governamentais. A empresa foi criada a mais de trs dcadas e integra vrios sistemas e bases de dados de diferentes fornecedores espalhados pelas diversas esferas do governo. So algumas das caractersticas: a) b) c) d) e) f) g) h) Atende rgos de mais de um estado brasileiro Mais de trs mil empregados Experincia em aes integradoras da administrao pblica federal Experincia em iniciativas de governo eletrnico Mais de quinhentos servidores de baixa plataforma Possui ambiente de alta plataforma Mltiplos bancos de dados Mais de um centro de dados

Dentro da empresa pblica, a pesquisa estudou um sistema de informao integrado e que estava em etapa de construo. O foco estudo do estudo foi identificar como o profissional responsvel pela concluso das integraes atuava para que as implementaes atingissem aos objetivos do projeto. Neste ambiente, cada mdulo do sistema integrado em construo era um projeto separado, ou seja, com lder prprio e equipe de analistas de sistemas para especificao e implementao de funcionalidades. Neste ambiente se previu, ao trmino da construo, a descontinuao de alguns Sistemas Legados, recebendo o Sistema Integrado em construo a responsabilidade pelo dado mantido pelo Sistema Legado. Tambm por esse motivo se previu que alguns Sistemas Legados no descontinuados passassem a acessar o Sistema Integrado em construo para obter tais dados. No estudo foram observados os controles aplicados sobre mdulos que se integravam a outros mdulos do sistema em construo, bem como os controles aplicados sobre mdulos que se integravam a sistemas legados. Alm disso, tambm foram observados os processos organizacionais que subordinavam a equipe de desenvolvimento. 4 Descrio do Ambiente O rgo pblico estudado est estruturado em diretorias funcionais. Entre elas, existe uma diretoria responsvel pelo relacionamento com clientes e outra especializada no desenvolvimento de solues de tecnologia da informao. Subordinada a diretoria especializada no relacionamento com clientes, existem superintendncias responsveis por diferentes carteiras de clientes. Cada cliente, a depender do rgo pblico em que trabalha e de seu core business, fica sob a gesto de unidades de atendimento de uma superintendncia. Estas unidades possuem especialistas no negcio do

cliente. Esses especialistas em negcio encaminham demandas de construo ou manuteno de sistemas s equipes especialistas em engenharia de software. Na diretoria responsvel pelo desenvolvimento de solues de tecnologia da informao ficam as equipes especializadas em engenharia de software. Estas equipes ficam subordinadas a uma superintendncia especializada na execuo dos processos de engenharia. A superintendncia conta ainda com o apoio de outra superintendncia (na mesma diretoria) responsvel por instituir arcabouos tecnolgicos que viabilizem e aumentem a produtividade nos processos de engenharia executados pela primeira. Na superintendncia especializada na execuo dos processos de engenharia o trabalho dividido entre departamentos, sendo que os departamentos possuem analistas especializados em anlise de requisitos, projeto fsico de sistemas, programao e teste de software. Os analistas ficam agrupados em sees no formato pool de especialistas ou em equipes especializadas em determinados sistemas de informao (legados ou em construo). O ambiente desta pesquisa exatamente uma das equipes especializadas em um determinado sistema de informao em construo. Especificamente, o sistema de informao em construo o mdulo de um sistema de informao integrado maior e que contm mais de trs outros mdulos. 5 5.1 Anlise dos Resultados O processo inicialmente encontrado

O processo de controle da integrao de sistemas inicialmente encontrado (verso anterior mudana) se subordina a dois processos corporativos maiores: um especializado no processo de negcio da empresa e; um especializado no desenvolvimento de sistemas de informao. Ao processo especializado no negcio cabe registrar o atendimento a solicitao de um cliente, administrar o andamento de demandas derivadas do atendimento e promover solues. Ao processo especializado no desenvolvimento de sistemas cabe, entre outras responsabilidades, realizar as etapas de engenharia de software que implementam as integraes a serem homologadas pelo cliente. Quando uma nova integrao (ou conjunto de integraes) solicitada por um cliente, primeiramente a solicitao de atendimento registrada. Registram-se tambm as aes relevantes do atendimento e como ele foi finalizado. Tambm mantido um registro de controle sobre o perfil do cliente. Com base no registro da solicitao do atendimento, na anlise da satisfao do cliente e na avaliao de um analista de negcio, so identificadas oportunidades de melhorias. O tratamento das melhorias negociado com o cliente e tratado sob a forma de uma demanda de servio. Na empresa, toda integrao de sistemas ocorre em um projeto de software que nasce de uma demanda de servio. Uma demanda pode precisar de mais de um projeto de software para ser atendida. Um projeto de software pode englobar a construo de mais de uma integrao. Quando a demanda concluda, busca-se identificar novas oportunidades de negcio, registrando em atas as negociaes que subsidiaro o planejamento da empresa na aquisio e

alocao de hardware e software. Periodicamente aferida a satisfao do cliente atravs de pesquisas de satisfao e checagem das ferramentas da empresa que interagem com o cliente. A demanda gerenciada entre sua abertura e fechamento. Nesta gesto ocorrem interaes com as equipes de desenvolvimento de sistemas. Quando uma demanda de integrao aberta, a equipe de desenvolvimento envolvida deve entender, avaliar a pertinncia e conceber a soluo. Alm disso, o esforo de trabalho tambm deve ser estimado e o atendimento realizado. Neste atendimento de demanda ocorre seu acompanhamento, a modelagem do negcio do cliente, a elaborao de um plano de negcio, a homologao e a implantao da soluo. Implantada a soluo ocorre ento a concluso do atendimento da demanda. O atendimento da demanda o ponto onde o negcio se integra com a engenharia de software. A demanda cria solicitaes de servio que justificam a criao de projetos de software. Estes projetos de software, durante as etapas de planejamento e acompanhamento, envolvem especialistas em desenvolvimento de software de modo a, no final do projeto, produzir um produto que atender as necessidades do cliente, permitindo a concluso da demanda. A figura 1 ilustra as principais etapas ocorridas no processo. Existe ainda uma importante etapa de testes integrados que ocorre aps a concluso da integrao entre os sistemas. Entretanto, o processo de teste no foi mapeado por ser gerido por uma equipe separada e porque o objetivo dos testes detectar erros antes dos clientes. Por isso, o ideal que o produto chegue sem erros na etapa de testes integrados.

Figura 1 Processo inicialmente encontrado (antes da mudana)

5.2

Dificuldades e Oportunidades de Melhoria

As dificuldades e oportunidades de melhorias foram indicadas com base nas seguintes caractersticas encontradas no ambiente: 1. Mdulo do Sistema de Informao em construo com integrao a mais de 30 outros sistemas externos 2. Equipe composta por mais de 12 especialistas em desenvolvimento de sistemas (sendo pelo menos dez especialistas em projetos fsicos e pelo menos dois especialistas em requisitos de sistemas de informao). 3. A maior parte dos projetistas realizavam tambm atividades de implementao. Atravs de entrevistas no estruturadas aos integrantes da equipe, foram encontradas as seguintes dificuldades: 1. Dificuldade em identificar servios (de sistemas legados e de outros mdulos do sistema integrado em construo) que podem ser reutilizados na implementao de mais de uma especificao de requisitos. Eventuais retrabalhos em decorrncia desta dificuldade. 2. As mudanas de requisitos, a necessidade de conhecer detalhes do negcio do cliente, a quantidade de integraes a serem implementadas e a necessidade de conhecimentos organizacionais (da prpria empresa) e tcnicos (de engenharia de software) por parte dos especialistas em desenvolvimento de software dificultam identificar aes relevantes para avanar no andamento de integraes especficas, bem como reportar estes avanos de maneira padronizada e objetiva. Estes fatores geram dificuldades no acompanhamento das integraes, conflitos entre expectativas e realidades de gesto e problemas de comunicao/gesto das informaes relevantes sobre as integraes. 3. Dificuldade no rastreamento de impactos em projetos fsicos decorrentes de mudanas de requisitos nas integraes 4. Dificuldade na localizao de documentaes referentes aos servios de integrao entregues. 5. Mudana de requisitos em paralelo com a execuo de projeto fsico de integrao j descartado pelo cliente. Retrabalho em decorrncia desta dificuldade 6. Longa espera pela disponibilizao dos servios de integrao. 5.3 O Processo Prescrito

Mediante os problemas detectados, prescreveu-se a criao de trs grupos de processos, responsveis pelo efetivo controle dos servios de integrao: gesto de mudana de requisitos e solicitao de servios (GMRSS); gesto de consumo dos servios (GCOSE); e gesto de atendimento a solicitaes de servios (GASS). Ao processo de gesto de mudana de requisitos e solicitao de servios, exposto na figura 2, cabe garantir que uma necessidade de integrao no deixar de ser solicitada a equipe de desenvolvimento responsvel pela disponibilizao do servio de integrao (Service Provider). Tambm cabe a este processo garantir que uma integrao descartada no deixe de ser comunicada s partes interessadas.

Figura 2 Processo GMRSS J o processo de gesto de consumo dos servios, exposto na figura 3, tem como responsabilidade garantir que os servios retornados no deixem de ser priorizados, projetados e integrados a todos os casos de uso (especificaes de requisitos) que os consomem. Cabe tambm a este processo a responsabilidade de comunicar ao Service Provider impedimentos, em especial os tecnolgicos e de requisitos, que impossibilitam a realizao da integrao. Deste modo, busca-se que servios disponibilizados que no atendam a necessidade das especificaes de requisitos sejam rapidamente notificados aos Service Providers sobre necessidade de ajustes para a integrao atender aos requisitos do projeto.

Figura 3 Processo GECOSE O processo de gesto de atendimento a solicitao de servios (figura 4), por sua vez, tem como responsabilidade garantir que servios que devam ser disponibilizados pelo prprio

projeto sejam implementados em alinhamento com a rea de negcios da empresa, garantindo que no sejam construdos, pelo mdulo construo, servios com baixa prioridade, bem como garantindo que servios prioritrios no tenham sua fase de planejamento esquecidas. Deste modo, busca-se priorizar a ordem de execuo dos esforos de integrao de acordo com as necessidades do Sistema Integrado em construo e dos Sistemas Legados em produo, identificando quando a disponibilizao de determinados servios por parte do mdulo em construo possui importncia maior do que a implementao do consumo de servios por parte deste mesmo mdulo.

Figura 4 Processo GASS Em sntese, as integraes so solicitadas pelo processo GMRSS. To logo elas sejam disponibilizadas (atravs de servios, por exemplo), o processo GECOSE d andamento para que elas sejam concludas. Caso ocorram mudanas de requisitos durante a fase de projeto fsico, o processo GMRSS novamente acionado, dando incio a um novo ciclo de integrao. Quando o mdulo que est em construo deve prover um servio aos sistemas externos, o controle feito pelo processo GASS. 5.5 Plano de Implementao e Organizao do Projeto de Mudana

Para implantar os processos, estabeleceu-se, como estratgia, a criao de um perfil Gestor Tcnico das integraes. Entre as atribuies do gestor tcnico estiveram: (1) Busca de contato e apoio poltico de pessoas capazes de influenciar positiva e negativamente a mudana (exemplo: lderes); (2) Audies com pessoas envolvidas na mudana; (3) Ajuste fino do plano de mudana, sensibilizao e conscientizao de envolvidos; (4) Conduo da implantao; (5) Treinamentos on the job; (6) Avaliao peridica do andamento da mudana; (7) Gesto das resistncias; (8) Cobrar as mudanas. Tambm foi importante para o projeto de mudana a construo de uma ferramenta de apoio, responsvel por automatizar tarefas repetitivas, gerar eletronicamente relatrios e promover o prosseguimento do fluxo de trabalho estabelecido para o avano das integraes. 5.6 Avaliao Ps Implantao da Mudana

Para avaliar os resultados da implantao do projeto, uma pesquisa foi disparada para a equipe de desenvolvimento do mdulo do sistema integrado em construo. A pesquisa questionou a frequncia do uso da ferramenta de apoio ao processo, a finalidade do uso, o perfil dos utilizadores, as barreiras percebidas na integrao de sistemas e as oportunidades.

Entre os respondentes: (1) Todos respondentes informaram praticar elaborao de projetos fsicos de sistema; (2) Cinco respondentes informaram praticar implementao de projetos fsicos; (1) Um respondente informou praticar anlise de requisitos. Em relao quantidade de respostas e frequncia de uso da ferramenta de apoio ao processo: (1) Dez profissionais responderam; (2) todos utilizam a ferramenta pelo menos duas vezes ao ms; (3) dois utilizam pelo menos cinco vezes ao ms; (4) quatro utilizam pelo menos nove vezes ao ms; (1) um utiliza pelo menos 15 vezes ao ms. Alm disso: (1) Nove respondentes passaram a usar a ferramenta para consultar reuso de solues de projeto, incluindo consulta de entradas e sadas esperadas de servios de integrao; (2) Seis respondentes passaram a utilizar a ferramenta para verificar o histrico e a evoluo das integraes; (3) Quatro dos respondentes passaram a utilizar a ferramenta para rastrear o impacto de integraes nas mudanas de requisitos; (4) Todos os respondentes passaram a utilizar a ferramenta para avanar na projeto fsico e implementao das integraes. Foram dificuldades percebidas para a integrao de sistemas: (1) Quatro respondentes indicaram regras de negcio que mudam durante ou aps a fase de projeto fsico; (2) Trs respondentes indicaram a falta de documentao adequada; (3) Trs respondentes indicaram a realizao de testes integrados; (4) Dois respondentes indicaram a indefinio da tecnologia durante a fase de projeto fsico; (5) Um respondente indicou a realizao de integraes que dependem de outras integraes; (6) Um respondente indicou a concorrncia de atividades dentro do projeto; (7) Um respondente indicou a elaborao do projeto fsico antes do servio de integrao estar disponvel; (8) Um respondente indicou a falta de equipes dedicadas para integraes; (9) Um respondente indicou a ausncia de boas prticas de engenharia de software nas integraes. Foram sugestes de melhorias indicadas para a integrao de sistemas: (1) Trs respondentes indicaram realizar o projeto fsico do caso de uso somente quando a maior parte ou a totalidade dos servios de integrao estiverem disponveis; (2) Cinco respondentes indicaram a necessidade de observar novas variveis (tipo de tecnologia, prazo total, homologao da tecnologia pela empresa, nomes fsicos em integraes por gatilho de banco, relaes de integraes que dependem de outras e especificao de cenrios de integrao em pseudo cdigo); (3) Um respondente indicou a sistematizao do processo de comunicao da disponibilidade de servios para a integrao ou mudana nas interfaces; (4) Um respondente sugeriu o estabelecimento de compromisso entre equipes em relao a prazos; (5) Um respondente indicou treinamento especfico sobre processos de integrao; (6) Dois respondentes indicaram que o problema maior a mudana de requisitos, que inerente ao processo de integrao. 5.7 Resultados

O processo prescrito trouxe para o ambiente melhor controle das pendncias de integrao nos mbitos do atendimento a equipes externas, da solicitao de servios e da realizao interna do consumo de servios. Este controle padronizou a forma de comunicao da evoluo das integraes, aumentou a disponibilidade do lder de projeto para outras atividades, simplificou a delegao de atividades de integrao, aumentou a disponibilidade dos especialistas em

desenvolvimento para execuo de tarefas tcnicas no lugar de administrativas (em funo do repasse das atividades administrativas a um novo perfil responsvel pela gesto tcnica). Alm disso, dentro da equipe se criou uma comunicao sistemtica que diminuiu a latncia de tempo na divulgao de evolues em integraes especficas a seus respectivos stakeholders. A gerao sistemtica de histrico contribuiu para anlises de melhoria contnua e apurao de causas referentes a resultados indesejados. Outra contribuio da implantao do fluxo se refere minimizao de impactos com empregados que saem de frias, sofrem acidentes de trabalho ou mudam de funo, gerando melhoria na gesto do conhecimento. 6 Concluso

O estudo permitiu identificar que, conforme viso de Huang & Bwoma, gerenciar projetos de grande escala poder ser bastante desafiador no governo. Conflitos entre expectativas e realidades podem acontecer nesses ambientes e, neste sentido, treinamentos, a definio e divulgao de um processo que atenda as necessidades do projeto e uma ferramenta de apoio para acompanhamento podem se mostrar teis na promoo da transparncia no exerccio da integrao entre sistemas. Alm disso, corroborando tambm com as colocaes de Huang & Bwoma, em ambientes como o estudado pode ser bastante desafiador gerenciar a informao e trat-la de maneira correta. Neste sentido, e na promoo de uma comunicao sistemtica, um sistema de informao como ferramenta de apoio permite a automao de tarefas repetitivas, sistematiza e padroniza a comunicao e ajuda a diferenciar as informaes que requisitam tratamentos especiais. No ambiente estudado, a maior parte das dificuldades decorre de mudana de requisitos. Eliminar completamente essas mudanas complexo, desafiador e visto com descrdito por desenvolvedores e pesquisadores que advogam a favor das metodologias geis de desenvolvimento de software. De qualquer forma, o estudo apresenta evidncias de que a especificao de integraes quando desacompanhada de acordos entre especialistas da equipe que disponibiliza os servios e especialistas da equipe que consome os servios de integrao pode se tornar ainda mais complexa e custosa de ser tratada durante a fase de projeto fsico e de implementao. Entretanto, ainda permanece como um desafio o tratamento da seguinte questo: Em um projeto de larga escala no governo, com diversas equipes geograficamente distribudas, com sistemas legados que recebem frequentes demandas de manuteno, com integraes com diversos sistemas que sofrem suas prprias presses polticas e de mercado, como lidar com equipes que no conseguem, por diversas dificuldades, disponibilizar as integraes no tempo necessrio para o projeto cumprir seus objetivos? Este trabalho sugere uma resposta para esta pergunta atravs da proposta de trs processos que ordenam em uma sequencia lgica e com foco nos resultados na perspectiva organizacional e tcnica. Estes processos no observam questes polticas, de poder, nem jogos organizacionais, at mesmo porque competio entre departamentos de uma mesma organizao sabidamente prejudicial para sua sobrevivncia.

Em referncia a elaborao de projetos fsicos em momento anterior a disponibilizao de servios de integrao por parte das equipes externas, percebeu-se que, alm dos aspectos semnticos, os aspectos relacionados tecnologia dos servios disponibilizados tambm causam reflexo nos produtos entregues. Enfim, o processo proposto promove avanos no ambiente, entretanto no a bala de prata. Novas variveis no processo de integrao podem ser observadas e, ainda assim, a execuo de testes integrados ser uma etapa desafiadora. As sugestes obtidas na pesquisa corroboram com a concluso deste trabalho de pesquisa e so oportunidades de melhoria a serem consideradas em prximas evolues do processo das integraes. Por fim, ferramentas podem apoiar no processo de controle das integraes, entretanto fatores como o mtodo de trabalho e a maturidade no processo devem ser observados para que os resultados das integraes de sistemas atinjam 100 % de eficincia, crescente aumento na eficcia e alta satisfao das partes envolvidas. Referncia Bibliografia A Empresa. (2012). Retrieved June 13, 2012, from https://www.serpro.gov.br/conteudooserpro/a-empresa-1 Hammer, M. (1990). Reenginering work: Dont automate, obliterate. Harvard Bus.Rev., (July-Aug., 104-112. Hammer, M., & Champy, J. (1993). Reenginering the Corporation. Harper Business, New York. Huang, Z., & Bwoma, P. O. (2003). An overview of critical issues of E-government. Issues of Information Systems, 4(1), 164170. Retrieved from http://iacis.org/iis/2003/HuangBwoma.pdf Kamal, M. M., & Themistocleous, M. (2006). A conceptual model for EAI adoption in an egovernment environment. Information Systems, 1-11. EMCIS2006. Retrieved from http://dspace.brunel.ac.uk/handle/2438/4018 Laudon, K. C. L. & J. P. (2009). Sistemas de informaao gerenciais. Looff, L. A. D. (1996). IS outsourcing by public sector organizations. Advanced IT Tools (Proceedings of the IFIP World Conference on IT Tools, 14th WCC (pp. 8996). London: Chapman & Hall. Retrieved from http://www.acs.org.au/president/1996/ifip96/i96iso.htm Mili, H., Tremblay, G., Jaoude, G. B., Lefebvre, E., Elabed, L., & Boussaidi, G. E. (2010). Business process modeling languages: Sorting through the alphabet soup. ACM Computing Surveys (CSUR), 43(1), 4. ACM. Retrieved from http://dl.acm.org/citation.cfm?id=1824799 Ould, M. A. (1995). Business Process: Modelling and Analysis for Reengineering and Improvement. Wiley, New York.

Pires, J. C. S., & Macdo, K. B. (2006). Cultura organizacional em organizaes pblicas no Brasil. RAP Rio de Janeiro, 40(1), 81105. SciELO Brasil. Retrieved from http://www.scielo.br/pdf/rap/v40n1/v40n1a05.pdf Revoluo Governamental. (2012). Retrieved June 13, 2012, from http://www.modulo.com.br/pdf/case/revista-08sr-2006-case-serpro.pdf Rocheleau, B. (2000). Prescriptions for public-sector information management. The American Review of Public Administration. Retrieved from http://arp.sagepub.com/content/30/4/414.short Rocheleau, Bruce, & Wu, L. (2002). Public versus private information systems. The American Review of Public . Retrieved from http://arp.sagepub.com/content/32/4/379.short Rosseto, A. M., Orth, D., & Rosseto, C. R. (2004). Implicaes de variveis organizacionais na adoo de inovaes tecnolgicas em organizaes pblicas: estudo de caso de implantao de sistema de informaes geogrficas em prefeitura de mdio porte. Revista da Administrao Pblica, 38, 109-36. Saraiva, L. A. S., & Capelo, L. G. F. (2000). A nova administrao pblica e o foco no cidado: burocracia X marketing? * Luiz Alex Silva Saraiva **, 1-9. Seabra, S. N. (2001). A nova administrao pblica e mudanas organizacionais; The new public management and organizational changes. Rev. adm. pblica, 35(4), 1943. Fundao Getlio Vargas. Retrieved from http://app.ebape.fgv.br/comum/asp/dsp_frm_login.asp Sommerville, I., & Melnikoff, S. (2003). Engenharia de software. Retrieved from http://scholar.google.com.br/scholar?hl=ptBR&as_sdt=0&q=engenharia+de+software+sommerville#1 WfMC. (1999). Workflow management coalition. Terminology and glossary, document WfMC-TC-1011. Retrieved from http://www.wfmc.org/standards/docs/TC1011_term_glossary_v3.pdf