Controle do Ambiente de Integrao de Sistemas em um

rgo Pblico
Wellington M. Anastcio
1
, Edmir P. V. Prado
1
, Violeta Sun
1
, Marcelo Fantinato
1

1
Escola de Artes, Cincias e Humanidades Universidade de So Paulo (USP)
Rua Arlindo Bttio, 1000 CEP: 03828-000 So Paulo SP Brazil
wellingtonmontefusco@usp.br, eprado@usp.br, violeta@usp.br,
m.fantinato@usp.br
Abstract. Control systems integration (IS) information is, to the electronic
government, a challenging, interesting and little explored issue in Brazil. This
case study explores this environment in a public agency of Brazil that is
reference in information technology. Key contributions of this paper are: (1)
presenting a model of IS control process that promotes standardization,
systematic communication, knowledge management, division of
responsibilities, continuous improvement and; (2) identification that changing
requirements is the most problematic issue for physical design phases of
integrations.
Resumo. Controlar a integrao de sistemas (IS) de informao , para o
governo eletrnico, uma questo desafiadora, interessante e pouco explorada
no Brasil. Este estudo de caso explora a questo em um rgo pblico
brasileiro referncia em tecnologia da informao. So contribuies chaves
desse artigo: (1) apresentao de um modelo de processo de controle de IS
que promove padronizao, comunicao sistemtica, gesto de
conhecimento, diviso de responsabilidades e melhoria contnua; (2)
identificao que a mudana de requisitos o fator mais problemtico para as
fases de projeto fsico das integraes.
1. Introduo
A prtica da IS no governo contribui para a resoluo de problemas de redundncia e
inconsistncia de dados. Outros problemas comumente destacados so servios com
responsabilidade compartilhada, falta de conectividade entre aplicaes, falta de
proteo aos dados do cidado, alto custo de operao de sistemas, alto custo de
manuteno de sistemas e falta de integridade nos dados [Kamal e Themistocleous
2006].
Por outro lado, muitas barreiras desafiam as organizaes pblicas na
implantao de servios de governo eletrnico. Huang e Bwoma (2003) destacam a falta
de capacidade de gerenciar projetos de tecnologia de informao, conflitos entre
expectativa e realidade, resistncia dos empregados da organizao, frameworks
obsoletos para inovao, gesto inadequada da informao e uso inadequado de dados
relevantes.
Compreender como controlar a IS de informao em rgos pblicos contribui
para a superao de barreiras gerenciais, promove a efetividade na produo de servios
de governo eletrnico e auxilia no dimensionamento de esforos referentes a sistemas
de informao.
Dentro desse contexto, este artigo tem como objetivo analisar os processos de
controle relacionados s atividades de IS. A pesquisa foi desenvolvida por meio de um
estudo de caso em um rgo pblico. Espera-se que os resultados possam contribuir
para o conhecimento e aperfeioamento dos processos de controle da IS no governo
brasileiro.
2. Fundamentao Terica
Organizaes pblicas so sistemas complexos e com alta aplicao de burocracia no
funcionamento [Saraiva e Capelo 2000]. Rossetto, Orth, e Rossetto (2004) destacam
que organizaes pblicas apresentam fidelidade s regras e rotinas, supervalorizao
da hierarquia, apego ao poder e paternalismo nas relaes.
Essas caractersticas se refletem na postura dos empregados, gerando reflexos na
forma da organizao lidar com inovaes, mudanas e processos internos [Santos et al.
2012]. Por isso, e pelos objetivos desta pesquisa, compreender como controlar a IS nas
organizaes pblicas requer o valimento dos processos organizacionais que a
subordinam.
2.1. Processos Organizacionais
Nas organizaes existem processos que cumprem determinadas funes de negcio.
Esses processos de negcio representam um conjunto de atividades que, quando
executadas juntamente, produzem um resultado de valor para o cliente [Hammer e
Champy 1993].
A WfMC (1999) define processo de negcio como um conjunto de atividades
que realizam um objetivo de negcio ou atendem uma determinada poltica. Essas
atividades normalmente se desenvolvem no contexto da estrutura organizacional e
estabelecem relacionamentos entre as estruturas funcionais da organizao.
Mili et al. (2010) sintetizam que processos de negcio so executados por atores
que seguem regras particulares, consumindo recursos e produzindo 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.
Inicialmente, as teorias administrativas gerenciavam as divises de uma cadeia
de comando hierarquizada, com tratamento de custo, fluxo de trabalho e forma de
comunicao de cada diviso de maneira isolada. Com o redesenho de processos de
negcio, o foco administrativo mudou para o processo como um todo, tratando,
simulando e procurando formas de aperfeioamento na transao de negcio de ponta a
ponta [Hammer e Champy 1993].
Mili et al. (2010) consideram que diferentes processos de negcio podem cruzar
diferentes fronteiras organizacionais de diferentes formas, abrindo margem para
estruturas organizacionais inovadoras, tais como as organizaes orientadas a projetos e
as organizaes em estrutura matricial.
De qualquer forma, o redesenho dos processos de negcio, a evoluo de novas
tecnologias e o comrcio eletrnico renovaram o interesse na modelagem de processos
como pr-requisito para a melhoria contnua. Assim, processos de negcio passaram a
priorizar a execuo computacional nas atividades em que os seres humanos
executavam de maneira menos eficiente [Hammer e Champy 1993].
Hammer (1990) ressalta que em muitos cenrios a evoluo dos processos e dos
sistemas de informao ocorrem de maneira improvisada, criando ntimas relaes com
a organizao. Por isso e por todos os potenciais benefcios do redesenho de processos
de negcio, avaliar e medir impactos nos processos de negcio no qual uma IS se
proponha a gerar melhorias contribui para o alcance do objetivo.
2.2. Integrao de Sistemas
A IS um fenmeno que ocorre quando mais de um sistema de informao colaboram
eletronicamente para atingir um objetivo. Segundo Sommerville e Melnikoff (2003),
essa colaborao pode ocorrer entre sistemas de informao diferentes ou ainda entre
mdulos de um nico sistema quando este muito grande, tal como os sistemas ERP.
Sommerville e Melnikoff (2003) destacam que uma das dificuldades da IS reside
nos testes de integrao. Nestes testes, quando as interaes entre os componentes do
sistema resultam em sadas anmalas, raramente a origem do erro fica em evidncia.
Assim, mesmo utilizando abordagens como testar uma configurao mnima e, em
seguida, adicionar componentes at a localizao do erro, testar as integraes pode ser
muito complexo.
Componentes dispersos podem ser necessrios para testar um nico recurso. Os
testes podem revelar erros nas interaes entre esses componentes e em outras partes do
sistema. O reparo pode afetar ou colocar em evidncia erros em componentes
dependentes do reparado. Novos componentes que so integrados e testados podem
modificar o padro das interaes j testadas. Erros que no haviam sido detectados nos
testes de configurao mais simples podem surgir [Sommerville e Melnikoff 2003].
Alm disso, diferentes funes organizacionais podem ser responsveis por
diferentes componentes do sistema, tornando a resoluo de problemas de IS muito
mais ampla. Nesse caso, Kamal e Themistocleous (2006) considera que a resoluo de
problemas extrapola questes sintticas, passando a envolver a anlise de frameworks
estratgicos de colaborao, redesenho de processos de negcio, tratamento da
resistncia mudana, poltica de interoperabilidade e a expertise de gerentes em IS.
2.3. Apresentao da Empresa
Esta pesquisa se desenvolveu em uma empresa pblica brasileira responsvel pela
administrao da TI em dezenas de rgos governamentais. Esta empresa foi criada h
mais de trs dcadas e integra vrios sistemas e bases de dados de diferentes
fornecedores, atendendo diversas esferas do governo. Ela possui mais de trs mil
empregados, e realizou inmeras aes integradoras na administrao pblica federal e
em iniciativas de governo eletrnico.
O parque computacional instalado dessa empresa significativo. Ela possui mais
de quinhentos servidores de baixa plataforma, alm de ambiente de alta plataforma. Os
dados esto armazenados em mltiplos bancos de dados, espalhados em mais de um
centro de processamento de dados.
A empresa est estruturada em diretorias funcionais. Entre elas, destacam-se
para o objetivo desta pesquisa a diretoria responsvel pelo relacionamento com clientes
e a diretoria especializada no desenvolvimento de solues de TI. Subordinada
primeira h superintendncias responsveis por carteiras de clientes. Cada cliente, a
depender do rgo pblico em que trabalha e de sua atividade principal, fica sob a
gesto de unidades de atendimento de uma superintendncia. Estas unidades possuem
especialistas no negcio do cliente, que encaminham demandas de construo ou
manuteno de sistemas s equipes especialistas em engenharia de software.
Na diretoria responsvel pelo desenvolvimento de solues de TI ficam as
equipes especializadas em engenharia de software. Estas equipes ficam subordinadas a
uma superintendncia especializada na execuo dos processos de engenharia. Nessa
superintendncia, o trabalho dividido entre departamentos, sendo que os
departamentos possuem analistas responsveis pela anlise de requisitos, projeto fsico
de sistemas, programao e teste de software.
3. Mtodo da Pesquisa
Esta pesquisa busca analisar os processos de controle relacionados s atividades de IS,
estudando eventos contemporneos de difcil controle em laboratrio. Como
consequncia, a estratgia de estudo de caso se mostra apropriada [Yin 2005].
Os procedimentos metodolgicos desta pesquisa podem ser agrupados em seis
fases:
a) Reviso bibliogrfica. A pesquisa bibliogrfica possibilitou a elaborao de
um roteiro de anlise para as fases subsequentes e precedeu ao levantamento de fatos e
documentos. Esta fase ocorreu entre julho de 2010 e janeiro de 2011.
b) Escolha do objeto de estudo. A partir da estrutura organizacional da empresa
e das informaes sobre projetos de IS foi selecionada uma rea especfica, na qual se
desenvolvia um projeto de construo de sistema integrado com caractersticas
alinhadas aos objetivos da pesquisa.
c) Mapeamento dos processos institucionais de IS. A partir do projeto
selecionado, por meio de consulta a documentos institucionais e entrevistas no
estruturadas, foi mapeado o processo de controle da IS nesse ambiente. As entrevistas
envolveram o lder (gestor) do projeto, dois profissionais de anlise de requisitos e dois
profissionais de anlise de projeto fsico, que validaram o modelo. Esta etapa ocorreu
em fevereiro de 2011, na cidade de So Paulo.
d) Mapeamento e padronizao dos processos empricos de IS. Atravs de
entrevistas no estruturadas envolvendo o lder do projeto, dois analistas de requisitos e
dois analistas de projeto fsico, foram identificadas dificuldades e oportunidades de
melhoria. Considerando estas e o objetivo de alcanar um modelo mais rico para o
controle da IS, elaborou-se um modelo complementar ao institucional, documentando e
padronizando atividades de IS anteriormente realizadas de forma ad hoc. Tambm se
elaborou um plano para execuo da mudana. O modelo complementar e o plano de
mudana foram validados pelos entrevistados e, por fim, uma ferramenta de apoio,
concentradora das informaes de controle da IS, foi desenvolvida. Esta etapa ocorreu
entre maro e maio de 2011, na cidade de So Paulo.
e) Avaliao dos resultados. Aps sete meses da implantao do modelo
complementar, avaliou-se o uso do modelo, da ferramenta de apoio e as lies
aprendidas. A avaliao considerou a consulta do histrico de eventos de IS na
ferramenta de apoio, a aplicao de questionrio, entrevistas no estruturadas e a
observao. O questionrio perguntou sobre as dificuldades na IS, as oportunidades de
melhoria e o uso da ferramenta. As respostas do questionrio foram tratadas atravs de
anlise temtica do contedo. Esta etapa ocorreu em dezembro de 2011, na cidade de
So Paulo.
f) Relatrio final: Foram discutidos os resultados obtidos e feitas as
consideraes finais. Esta etapa ocorreu em janeiro de 2012.
As fases a, b, c e d envolveram a participao de um pesquisador
mestrando em sistemas de informao e um pesquisador doutor em administrao. As
fases e e f contaram com dois pesquisadores adicionais, um doutor em cincia da
computao e outro em administrao.
3.1. Objeto de Estudo
O objeto de estudo na organizao pblica em questo um sistema de informao
integrado e que estava em etapa de construo. Esse sistema tinha integrao com mais
de 30 sistemas externos. Cada mdulo desse sistema integrado foi desenvolvido por um
projeto em separado, ou seja, cada mdulo possua um lder e uma equipe de analistas
de sistemas para especificao e implementao de funcionalidades. Estava previsto, ao
trmino da implantao do sistema de informao integrado, a descontinuao de alguns
sistemas legados. Alm disso, outros sistemas legados, no descontinuados, passariam a
acessar o novo sistema de informao integrado.
A equipe era composta por mais de 12 especialistas em desenvolvimento de
sistemas, sendo dez especialistas em projetos fsicos e dois em requisitos de sistemas de
informao. Alm disso, a maior parte dos projetistas realizavam tambm atividades de
implementao.
As observaes se focaram nos controles aplicados sobre os mdulos do sistema
em construo que se integravam, bem como nos 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. Anlise dos Resultados
Esta seo apresenta: mapeamento dos processos institucionais de IS; dificuldades e
oportunidades de melhoria; mapeamento e padronizao dos processos empricos de IS
e; resultados.
4.1. Mapeamento dos Processos Institucionais de IS
O processo de controle da IS inicialmente encontrado se subordinava a dois processos
corporativos maiores:
a) Processo de negcio da empresa. Este tem a finalidade de registrar o
atendimento solicitao de um cliente, administrar o andamento de demandas
derivadas do atendimento e promover solues.
b) Desenvolvimento de sistemas de informao. Este tem a responsabilidade
de realizar as etapas de engenharia de software que implementam as integraes a serem
homologadas pelo cliente.
Quando uma nova integrao solicitada por um cliente, primeiramente a
solicitao de atendimento registrada. Registram-se tambm as aes relevantes ao
atendimento e um registro de controle referente ao perfil do cliente.
Com base na solicitao de atendimento, na anlise da satisfao do cliente e na
avaliao de um analista de negcio so identificadas oportunidades de melhoria. Essas
oportunidades so negociadas com o cliente e tratadas sob a forma de uma demanda de
servio.
Quando essa 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 por meio de pesquisas de satisfao e verificao das ferramentas que
interagem com o cliente.
A demanda gerenciada entre sua abertura e fechamento. Durante esse perodo,
ocorrem interaes com as equipes de desenvolvimento de sistemas. Quando uma
demanda de integrao aberta, a equipe de desenvolvimento envolvida deve avaliar a
pertinncia e conceber a soluo. Essas atividades envolvem estimar o esforo de
trabalho a ser realizado, modelar o negcio do cliente, elaborar um plano de negcio,
homologar e implantar a soluo.
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.
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. Essa etapa tem como objetivo antecipar a deteco de erros que poderiam
ocorrer nos ambientes de homologao e produo, reduzindo, assim, os custos de
manuteno. Optou-se por no incluir esta etapa no mapeamento porque, na perspectiva
tcnica, ela repete execues que supostamente j deveriam ter sido tratadas pelos
implementadores. Maiores exploraes podem se mostrar interessantes em trabalhos
futuros.
4.2. Dificuldades e Oportunidades de Melhoria
Os seguintes fatores foram identificados como dificuldades e oportunidades na IS:
a) identificao de servios de sistemas que podem ser reutilizados na
implementao de mais de uma especificao de requisitos;
b) regras de negcio que mudam durante ou aps a fase de projeto fsico;
c) requisitos que mudam durante ou aps a execuo de projeto fsico de
integrao;
d) necessidade de conhecimento da organizao e do negcio por parte dos
especialistas em desenvolvimento de software durante projeto fsico das integraes;
e) falta de documentao adequada referente aos servios de integrao
entregues;
f) realizao de testes integrados;
g) longa espera pela disponibilizao dos servios de integrao;
h) desvios de comunicao na evoluo dos trabalhos de IS.
Figura 1. Processo institucional
4.3. Mapeamento e padronizao dos processos empricos de IS
Considerando os problemas detectados e os objetivos desta pesquisa, elaborou-se um
modelo complementar ao processo institucional, transparecendo e padronizando
atividades de IS anteriormente realizadas de forma ad hoc. Este modelo passou a ser, na
perspectiva dos integrantes da equipe, responsvel pelo controle efetivo da IS no
ambiente especfico do projeto em estudo.
Assim, foram prescritos trs processos: gesto de mudana de requisitos e
solicitao de servios (GMRSS); gesto de consumo dos servios (GECOSE) e; gesto
de atendimento a solicitaes de servios (GASS).
a) Gesto de mudana de requisitos e solicitao de servios (GMRSS). O
processo GMRSS, apresentado na figura 2, retrata as atividades necessrias para
garantir que uma necessidade de integrao no deixe de ser solicitada equipe de
desenvolvimento responsvel pela disponibilizao do servio de integrao (Service
Provider). Tambm cabe ao processo garantir que uma integrao descartada no deixe
de ser comunicada s partes interessadas. Podemos ilustrar o uso deste processo da
seguinte maneira: Quando uma especificao de requisitos sofre uma mudana,
possvel que essa mudana tenha impacto nas integraes. Quando h impacto, o gestor
tcnico necessitar comunicar as partes interessadas o impacto (por exemplo: se um
analista de projetos fsicos estiver trabalhando em uma integrao na qual o analista de
requisitos determinou que ser substituda por outra, ao saber dessa notcia o analista de
projetos fsicos pode suspender os esforos nessa atividade, evitando o trabalho
desnecessrio). O analista de requisitos deve avisar o gestor tcnico que alguns
documentos de requisitos precisam ser reavaliados. Caso ele esquea, a auditoria
semanal identificar arquivos que sofreram modificaes. Assim, o gestor tcnico
poder interagir com esses analistas, identificando modificaes e possveis impactos
nas integraes. Quando existe o impacto (novas integraes, integraes descartadas
ou mudana nas interfaces), um catlogo de servios gerado, informando todas as
partes interessadas envolvidas nas mudanas.
Figura 2. Processo GMRSS
b) Gesto de consumo dos servios (GECOSE). O processo GECOSE,
apresentado na figura 3, retrata os passos essenciais para garantir que os servios
disponibilizados por sistemas de informao externos no deixem de ser priorizados,
projetados e integrados a todas as funcionalidades especificadas pelos analistas de
requisitos. Mais de uma funcionalidade pode consumir um mesmo servio. 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 comunicar sistematicamente o Service
Provider de modo que ele possa reavaliar os ajustes necessrios para atender as
necessidades explcitas nas especificaes de requisitos. Podemos ilustrar o uso do
processo da seguinte maneira: Quando um sistema de informao disponibiliza um
servio de integrao, este servio encaminhado ao gestor tcnico. Este solicita
documentos que auxiliem na compreenso semntica e tcnica do servio. Caso o
analista de projeto fsico detecte que o material disponibilizado insuficiente para
prosseguir com a integrao, ele comunica ao gestor tcnico que se encarregar de
interagir com a equipe que disponibilizou o servio at que os ajustes necessrios sejam
concludos. Em alguns casos os servios disponibilizados podem requerer parmetros de
entrada no previstos. Nestes casos, os analistas de requisitos devem reavaliar a
integrao porque novas integraes podem se mostrar necessrias. Em outros casos,
integraes especificadas na documentao de requisitos podem se mostrar
desnecessrias. Isto pode ocorrer especialmente quando o backlog de atividades dos
analistas de requisitos estiver sobrecarregado. Assim, o gestor tcnico mantm a
integrao como suspensa, alertando os analistas de projetos a no dedicarem esforos
nesta atividade. Por fim, quinzenalmente o gestor tcnico revisa se existem servios que
foram disponibilizados, porm com pendncia de tratamento. Caso existam, os analistas
de projeto fsico so comunicados sobre os servios com tratamento pendente, devendo
informar ao gestor tcnico assim que conclurem a integrao. Caso no haja um
analista responsvel, o lder notificado para alocar um recurso na atividade assim que
possvel. Nos casos em que possvel alocar um recurso imediatamente, o gestor
tcnico repassa a atividade para o recurso.
Figura 3. Processo GECOSE
c) Gesto de atendimento a solicitaes de servios (GASS). O processo
GASS, apresentado na figura 4, representa os passos essenciais para garantir que
servios que devam ser disponibilizados pelo sistema integrado em construo tenham
ordem de implementao em acordo com a rea de negcios demandante do projeto.
Assim, evita-se o empenho da equipe na construo de servios com baixa prioridade,
bem como o esquecimento da implementao de servios prioritrios. Promove-se
ainda que as discusses referentes s prioridades, tanto da equipe do sistema em
construo quanto das equipes que desenvolvero servios para integrao, ocorra
unicamente em nvel de anlise de negcio. Podemos ilustrar o uso do processo da
seguinte maneira: Quando a equipe de outro sistema de informao pede que um servio
do sistema em construo/manuteno seja disponibilizado, o gestor tcnico verifica se
existe alguma especificao de requisitos (prevista ou em fase de construo) para o
servio. Caso exista, a previso de atendimento informada. Caso no exista, o gestor
tcnico verifica se existe demanda da rea de negcio da empresa solicitando os
esforos necessrios. Quando existe a demanda, o lder do projeto planeja o atendimento
da integrao e o gestor tcnico posiciona a previso de atendimento para a equipe do
sistema de informao solicitante do servio. Quando no existe a demanda, o pedido de
disponibilizao do servio encaminhado para a rea de negcio da empresa que, aps
avaliar a solicitao, decidir pelo no atendimento ou pela criao de uma demanda.
Para evitar que haja esquecimento em atender solicitantes de servios, o gestor tcnico
levanta pendncias de atendimento quizenalmente e as informa ao lder.
Figura 4. Processo GASS
Em sntese, as integraes so solicitadas pelo processo GMRSS. To logo elas
sejam disponibilizadas (atravs de, por exemplo, servios), 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.
Foram desenvolvidas duas aes para facilitar a implantao desses trs grupos
de processos. A primeira foi a criao da funo de Gestor Tcnico das integraes. As
principais atribuies da funo foram a gesto das partes interessadas, ou seja, a busca
de apoio de pessoas capazes de influenciar o processo de mudana, a sensibilizao e
conscientizao dos envolvidos, e treinamentos on the job.
A segunda ao para facilitar a implantao foi 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.
4.4. Resultados
Foi constatado, durante a etapa de avaliao dos resultados, uso frequente da ferramenta
de apoio: dez profissionais (cerca de 60% da equipe) responderam utilizar a ferramenta
pelo menos duas vezes ao ms. Entre os dez profissionais, quatro responderam utilizar
pelo menos nove vezes ao ms. Alm disso, nove dos respondentes passaram a usar a
ferramenta para consultar reuso de solues de projeto referentes s integraes. Os
respondentes indicaram, ainda, utilizar a ferramenta para rastrear impactos das
mudanas de requisitos e acompanhar o histrico de integraes de interesse.
Foi constatado ainda que, para os analistas de projeto fsico, a mudana de
regras de negcio durante ou aps a fase de anlise foi interpretada com a barreira de
maior destaque. Alm desta, e nesta ordem, receberam destaque a falta de
documentao adequada, a realizao de testes integrados e a indefinio da tecnologia
do servio de integrao antes da fase de anlise.
Por outro lado, observou-se no histrico de eventos da ferramenta que cerca de
70 novas integraes foram declaradas como concludas fazendo uso do modelo
complementar, mais do que o dobro de integraes que haviam sido concludas antes da
implantao deste.

Entre as sugestes de melhoria, trs integrantes da equipe citaram a realizao
do projeto fsico de uma especificao de requisitos somente quando a maior parte ou a
totalidade dos servios de integrao estiverem disponveis. Dois integrantes citaram
que a dificuldade mudana de requisitos inerente ao processo de integrao. Outros
integrantes citaram ainda que observar variveis como tipo de tecnologia, homologao
da tecnologia pela empresa, relaes de integraes que dependem de outras e
especificao de cenrios de integrao em pseudocdigo podem se mostrar teis.
Por essas consideraes possvel sugerir que o modelo complementar e a
ferramenta de apoio aprimoraram o controle da IS no ambiente. O uso frequente da
ferramenta e a concluso de cerca de 70 novas integraes mostra que o modelo
eficaz, entretanto fatores como a padronizao e a comunicao sistemtica podem ser
responsveis por uma boa parte desses crditos.
Outra discusso est na mudana da forma de trabalho da equipe, posta em
evidncia pela criao do perfil gestor tcnico. Este passou a concentrar atividades
que antes estavam a cargo do lder e dos especialistas. Assim, no mnimo, mudou-se a
forma de distribuio das atividades essenciais na IS. Apenas esta mudana poderia
impactar na reduo de improvisaes na IS, gerando reflexos como diminuio de
retrabalho.
Nas devidas propores, cada fator pode ter colaborado tambm para a
observada diminuio na latncia de tempo para divulgao s partes interessadas
(stakeholders) das evolues na IS. Casos excepcionais de desvio de comunicao
anteriores ao modelo complementar passavam de trs semanas de latncia at a parte
interessada. No se observou na ferramenta de apoio, mesmo em casos excepcionais,
latncia de comunicao superior a dez dias.
Outra discusso pertinente que a gerao sistemtica de histrico passou a
representar, no mnimo, um insumo para apurao de causas de resultados indesejados.
Este fator aliado padronizao do processo de controle promove a gesto de
conhecimento, ou seja, um novo empregado pode acessar o contexto passado e presente
de uma integrao, mesmo que, por exemplo, o gestor tcnico esteja de frias.
5. Concluso e trabalhos futuros
Por esses resultados, sugere-se a potencial melhoria de eficincia na IS em funo da
implantao do modelo complementar e da ferramenta de apoio.
Sugere-se ainda que, dadas as dificuldades apontadas pelos respondentes da
pesquisa de avaliao, especificar uma integrao antes do fechamento de acordos entre
os especialistas da equipe que disponibilizam os servios de integrao e os
especialistas da equipe que consomem esses servios pode representar uma prtica mais
complexa e custosa do que a de no especificar a integrao enquanto os acordos entre
equipes no forem fechados no nvel lgico e tcnico.
Recomenda-se, em trabalhos futuros, investigar a utilizao dos mecanismos
aqui apresentados em outras empresas pblicas, de esfera municipal, estadual ou federal
para, principalmente, avaliar a validade externa dos resultados obtidos neste caso.
interessante que o profissional que exercer a funo de gestor tcnico tenha
capacitao tcnica, viso gerencial e disponibilidade integral para a prtica do intento.

Alm disso, tambm interessante que o lder da equipe (gestor) acompanhe de perto as
mudanas e tenha equipe receptiva inovao.
Esta pesquisa analisou os processos de controle relacionados s atividades de IS.
Foi possvel constatar as dificuldades de gerenciar projetos de IS em rgos do governo,
onde h conflitos entre expectativa e realidade. Nesse sentido, a implementao de um
processo que atenda s necessidades do projeto e de uma ferramenta de apoio para
acompanhamento se mostraram teis.
Referncias
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 e-government environment. Information Systems, 1-11. EMCIS2006. Retrieved
from http://dspace.brunel.ac.uk/handle/2438/4018
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
Rossetto, A. M., Orth, D., & Rossetto, 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.
Santos, H. , Santana, A., Alves, C. (2011) Anlise de Fatores Crticos de Sucesso da
Gesto de Processos de Negcio em Organizaes Pblicas, VIII Congresso
Brasileiro de Sistemas de Informao SBSI 2012, So Paulo, Brasil.
Saraiva, Luiz, & Capelo, Luiz (2000). A nova administrao pblica e o foco no
cidado: burocracia X marketing? Revista da Administrao Pblica, 32, 55-77.
Sommerville, I., & Melnikoff, S. (2003). Engenharia de software. Retrieved from
http://scholar.google.com.br/scholar?hl=pt-
BR&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/TC-
1011_term_glossary_v3.pdf.
Yin, R. K. (2005) Estudo de caso planejamento e mtodos, 3 edio. Porto Alegre:
Bookman.