Organização Federativa de Sistemas de Informação

Autor:

A idéia de integrar sistemas como uma federação não é nova. Davis em seu livro [3] diz explicitamente:

"Integrated processing is accomplished by an overall system plan. The system is usually designed as a federation of subsystems rather than a single system... "

Apesar disso, Davis não detalha como esta federação funcionaria. Segundo Davis, ainda assim seria necessário um plano de sistemas geral. É justamente nesse ponto que nossa proposta é diferente. No nosso conceito de federação, não existe um plano inicial, nem regras definidas para cada subsistema, que para nós são na verdade sistemas. A organização federativa, por nós proposta, objetiva principalmente manter a autonomia dos sistemas a serem integrados.

Buscamos a analogia de federação, principalmente no direito [8]. Este princípio organizacional tem funcionado não só como forma de governo, mas em outras situações, desde a organização de cooperativas até a organização de times de futebol. O princípio fundamental desse conceito é o da independência dos órgãos federados, que concordam com um objetivo comum e de interesse de todos.

Nas seções seguintes discorreremos sobre o papel da informática na organização, a dificuldade da visualização de um sistema de informações e a organização federativa de sistemas de informação. Concluiremos, discorrendo sobre o efetivo emprego desse conceito em grandes organizações.

2 A Informática e a Organização

Sistemas computacionais de apoio a organizações podem tanto servir de apoio às atividades fins de uma empresa como às atividades meios. Os sistemas de maior complexidade são aqueles que além de operacionalizarem essas atividades, também fornecem apoio gerencial. Portanto, estes sistemas computacionais são subsistemas de um sistema maior que envolve pessoas, grupos organizados formalmente ou informalmente, procedimentos, políticas, máquinas e meios de comunicação.

O entendimento de que sistemas computacionais de apoio à organização são elementos de um conjunto maior, constantemente afetados pelas mudanças nesse meio, é de fundamental importância. Estes sistemas computacionais são parte do que chamamos sistemas de informação. Portanto, estes sistemas devem tratar, entre outros, de aspectos ligados à própria organização, suas necessidades, sua organização, atores envolvidos, fluxo de informações, cultura organizacional, satisfação no trabalho, padronização, métodos e procedimentos, infra-estrutura.

Portanto, a função da informática, na grande maioria das empresas, lida com duas partes distintas. Uma é a referente às arquiteturas de sistemas de informação, e outra referente às arquiteturas de sistemas computacionais de apoio a sistemas de informação [5]. Assim sendo, a função da informática numa organização passa a ter uma amplitude muito maior, envolvendo não só aspectos técnicos e organizacionais, como aspectos políticos no que se refere à decisão sobre emprego de tecnologias a serviço de sistemas de informação.

Neste quadro, é importante salientar a diferença, que julgamos essencial [5], entre sistemas de informação e engenharia de software. Enquanto sistemas de informação têm uma preocupação global, a engenharia de software tem uma preocupação centrada para o software que será um dos componentes de um sistema de informação. Esta distinção não é clara na literatura, o que leva a tratar a parte como o todo. As diferenças se manifestam tanto nas técnicas a serem utilizadas, como na formação do pessoal especializado.

Fundamentalmente, deve-se entender que o âmago da questão do desenvolvimento e operação de sistemas computacionais de apoio a organizações está na complexidade de tal tarefa. A década de 60 e princípio da década de 70 mostraram a inviabilidade da idéia do sistema de informação global para toda uma organização.

A despeito dos grandes avanços tecnológicos, várias organizações passaram pela desagradável experiência de terem altíssimos gastos em processamento de dados e, contrariamente ao esperado, terem acumulado grandes insucessos na implantação de ambiciosos sistemas de informação, os quais englobariam toda a organização.

Um sistema de informação não é como muitos acreditavam e, infelizmente, alguns ainda acreditam, um sistema puramente técnico. A visão tecnicista, oriunda, principalmente, do enfoque racional tecnológico da maioria dos gerentes responsáveis pela função de processamento de dados, detecta um sistema de informação como meramente uma obra de engenharia. Nada mais longe da realidade.

Um sistema de informação é um sistema onde aspectos técnicos são de fundamental importância, mas para que o sistema tenha sucesso deve ser socialmente aceito pela organização onde ele irá atuar. Ser socialmente aceito implica que a organização trabalhe com aquele sistema como parte do seu dia-a-dia. Portanto, é imprescindível que o arquiteto de um sistema de informação esteja atento a aspectos sociais da organização [4].

Apesar da idéia, de que sistemas de informação são sistemas que devem levar em conta aspectos sociais não ser nova [7] [6] [1], poucas organizações de informática praticam seus princípios. Acreditamos que grande parte dos problemas de integração são justamente oriundos dessa dificuldade dos profissionais de sistemas lidarem com problemas que permeiam e desafiam sua formação eminentemente técnica.

A seguir, discutiremos o problema de integração em sistemas de informação. Descreveremos alguns aspectos técnicos, mas realçaremos o aspecto social como fator preponderante em qualquer arquitetura de integração.

3 Problemas na Integração de Sistemas de Informação

Certamente executivos de informática ou profissionais mais experientes, já se encontraram numa situação em que diferentes setores de uma organização utilizavam diferentes sistemas com grande redundância de dados e operações. Esta situação é muito mais comum do que se pode imaginar e proliferou rapidamente quando do surgimento de plataformas de hardware de custo mais acessível. Não é raro encontrar organizações em que o sistema de orçamento do marketing é totalmente desacoplado do sistema de orçamento da empresa, ou em que a contabilidade de custos não se utiliza dos dados da contabilidade geral.

Na maioria das vezes, casos como esses são vistos como problemas. Uma abordagem puramente técnica acreditará que houve um mau planejamento por parte dos arquitetos dos sistema , que deveriam ter feito um estudo mais aprofundado da situação, ou deveriam ter utilizado padrões. Em algumas circunstâncias, é verdade que por falha técnica, sistemas apresentam redundâncias desnecessárias. É preciso, no entanto, que fique claro que muitas vezes esses problemas ocorrem não por falta de planejamento, mas sim por características inerentes ao contexto social em que esses sistemas estão envolvidos.

Não obstante esta visão social, o objetivo de integração deve ser sempre perseguido por arquitetos de sistemas de informação. Um dos grandes desenvolvimentos na área de informática, os sistemas gerenciadores de banco de dados, tem sido uma das ferramentas mais poderosas para que se procure integrar sistemas. No rastro desse desenvolvimento, modelos conceituais de grande expressividade têm sido propostos para modelar os dados de uma organização [2].

Apesar dos gerenciadores de banco de dados serem um avanço considerável, ainda assim o maior problema técnico na integração de sistemas é o que diz respeito a dados. Diferentes padrões de armazenamento dificultam a integração de sistemas desenvolvidos em distintas plataformas de software. Hoje, muitos dos grandes bancos de dados já oferecem a facilidade de importar dados com formatos de outros fabricantes. Além do problema de dados, outro grande freio à integração diz respeito a protocolos de comunicação entre computadores distintos.

No que se refere à tecnologia organizacional, os maiores problemas de integração de sistemas de informação têm suas raízes na falta de padronização das informações e na falta de padronização de processos. As soluções administrativas para implementar integrações através de retreinamento e recodificação são geralmente de alto custo.

Os aspectos técnicos descritos acima são para integração a posteriori, isto é, integração de sistemas já existentes. A integração planejada, conforme advogam vários autores de sistemas de informação, seria a integração ideal, isto é, aquela em que aspectos de interfaceamento entre sistemas podem ser pensados antes que estes sistemas sejam implementados. Cabe ressaltar, no entanto, que o planejamento não altera nossas observações quanto ao aspecto social. Em muitos casos, mesmo podendo-se planejar com antecedência, ainda assim motivos sócio-políticos podem fazer com que uma suposta perfeita integração não se concretize.

Em seguida, propomos um meta-modelo em que procuramos levar em consideração o contexto social no aspecto de integração de sistemas. Este meta-modelo é baseado na idéia de federação.

4 A Organização Federativa de Sistemas de Informação

Deixamos claro, na seção anterior, a necessidade de integração de sistemas de informação com os argumentos já conhecidos, referentes à redundância, custo associado e qualidade das informações. No entanto, observamos que o enfoque tradicional, aquele que procura resolver os problemas sob a ótica técnica, muitas vezes não consegue auferir seus objetivos. Nossa proposta procura mesclar aspectos técnicos com aspectos de análise do contexto social.

4.1 Definição Geral

Entendemos federação de sistemas de informação como um acoplamento fraco entre sistemas de informação dentro de uma organização. São quatro as características desse acoplamento:

• os sistemas de informação federados são independentes;

• os sistemas de informação federados são autônomos;

• os sistemas de informação federados são governados por um conselho no qual cada sistema de informação federado tem um representante;

• ao conselho da federação cabe o governo das relações de interdependência entre os sistemas e sua relação com sistemas de informação externos à empresa.

O ponto-chave deste tipo de organização é justamente o que diz respeito à independência e autonomia dos sistemas. Muitas vezes uma autonomia de um sistema pode, em termos gerais, acarretar uma necessidade de duplicação de dados e de tarefas que a princípio seriam alvo certo de uma integração. No entanto, deve-se levar em consideração se uma mudança com vistas à integração não levaria a custos muito maiores do que o custo de duplicação.

Na maioria das vezes quando uma proposta de integração é sugerida, não se leva em consideração custos escondidos. Vejamos um exemplo. A empresa X2 opera dois sistemas de informação bastante semelhantes. Um controla a parte financeira de projetos e outro a parte física desses projetos. Um desses sistemas está implementado em um mainframe, enquanto o outro roda numa rede de micros. Um desses sistemas é operado por gerentes de projetos enquanto o outro é operado pelos executores dos projetos. Os dois sistemas praticamente não se falam, apesar da fonte geradora dos dados ser basicamente a mesma.

Uma solução técnica óbvia seria a de fazer uma entrada comum, por exemplo. No entanto, ao se observar com detalhe a organização do trabalho, se verificará que toda a rotina dos executores é feita com base em contratos com prestadores de serviço, e é o contrato o centro das atenções, apesar de que um contrato está ligado a um projeto. Por outro lado, o gerente de projeto trabalha com a noção de projeto e suas metas, inclusive financeiras, e portanto olha o contrato como um dos componentes do projeto. A solução de uma entrada comum nesse caso, apesar de óbvia, teria grandes problemas de funcionamento, principalmente em função da cultura sedimentada dos executores.

Este caso é um exemplo típico da necessidade de uma integração onde a autonomia dos sistemas seja mantida, apesar da duplicidade, visto que o custo para se fazer uma integração técnica seria muito maior que a de manter os sistemas autônomos3. Com base nessa constatação, a integração deve procurar soluções negociadas levando-se em conta esses custos escondidos.

4.2 Frentes de Atuação

O princípio básico da integração federativa é obter ganhos globais e, portanto, deve atuar em quatro frentes:

• qualidade da informação;

• troca de informações;

• segurança e

• custos de processamento.

No que diz respeito à qualidade da informação, a integração federativa deve, principalmente, utilizar a redundância de dados existentes como o fator primordial para detectar problemas de coerência4. Sistemas autônomos podem apresentar dados, que apesar de formato diverso, representam um mesmo fato da realidade. Esta oportunidade deve ser explorada como um mecanismo para validação das informações armazenadas nesses sistemas. Cabe à federação a definição de procedimentos para que este mecanismo de comparação seja usado de maneira eficaz.

No que diz respeito à troca de informações, a federação deve incentivar o escambo entre seus federados, isto é, incentivar a troca de informações com base no benefício mútuo. Pode parecer estranho que dentro de uma mesma organização haja setores que não queiram ceder suas informações. Uma atitude técnica decretaria que este era simplesmente um problema de acatar ordens, isto é, a informação tem que ser compartilhada. No entanto, profissionais mais experientes sabem que estes problemas não se resolvem por decreto, mas sim por um processo de negociação. A troca de informações, portanto, envolveria aspectos técnicos, principalmente no que diz respeito à formatação de dados. Software de tradução de formato são de especial importância nesses casos.

A segurança das informações deve ter atenção especial da federação. Sistemas federados têm dados que são confidenciais e que devem manter esse status. Normas de integração devem respeitar essa confidencialidade. A integração também deve-se precaver no que diz respeito ao acesso às bases de dados e à segurança física dos dados. Caso não haja uma política de segurança em sistemas federados, a federação deve cuidar para que essa prática se modifique.

Em termos de custo de processamento, a federação deve desenvolver estudos comparativos para que aponte para seus federados melhores alternativas de processarnento. Uma vez dispondo-se de experiências diversas, há oportunidade para que comparações ocorram, principalmente no que diz respeito a custos de processamento. Técnicas que são sucesso em alguns sistemas podem ser testadas em outros. Também com o convívio da federação, os sistemas, através de seus representantes, podem identificar processos de integração que reduzam os custos de cada federado.

4.3 Aspectos Gerenciais

Conforme exposto acima, a federação deve ser governada por um conselho, mas deve ter um pessoal próprio para ajudar a operar a federação. A integração desse conceito junto ao órgão responsável pela informática numa empresa deve ser feito de uma maneira cuidadosa. É importante ressaltar que a federação não tem atribuições de mando na estrutura da empresa. A alocação de pessoal técnico a este conselho tem por objetivo facilitar as tarefas técnicas de integração.

Entendendo-se a federação como um conselho, no que diz respeito à organização da função informática, leva a comparações com outras propostas, como por exemplo a do comitê de usuários [4]. No caso da federação, a organização de informática deve ter participação ativa, mas os representantes dos federados devem ser usuários, preferivelmente aqueles que têm forte ligação com o sistema. A presidência da federação seria por votação, cabendo ao pessoal de informática assento na federação, isto é, sem representar um sistema federado em particular.

É claro que a implementação de tal organização não é tarefa simples. Nosso objetivo nesse artigo é o de divulgar a idéia. A implementação de um esquema como o proposto dependerá de um estudo de cada organização em particular.

5 Conclusão

Neste artigo apresentamos uma visão diferente para o problema de integração de sistemas. Levamos em consideração, principalmente, o acervo de sistemas já desenvolvidos nas organizações e a dificuldade de se traçar um plano global para sistemas de informação.

Nossa visão federativa procura conciliar sistemas de informação autônomos sem forçar soluções técnicas para sua interligação. Nossa proposta baseia-se fundamentalmente no processo de negociação entre os federados.

A implementação de uma visão federativa numa organização não é tarefa simples. Cada empresa é um caso, sendo que existem também casos de empresas, que, por terem um caráter mais burocrático, conseguem integrações mais acopladas. Nossa proposta é útil para aquelas empresas em que o dinamismo de suas várias partes leva a uma independência maior entre os sistemas. Na nossa visão, a solução da integração não está num grande plano, mas sim na evolução dos sistemas.

Notas:

1. A idéia de um governo federativo é base da constituição do Estados Unidos e teve em Madison o seu principal idealizador. A confederação Helvécia (Suíça) é também um excelente exemplo de um estado federativo.

2. O presente exemplo é extraído de um caso real numa grande empresa.

3. No caso da empresa X haveria necessidade de mudar uma cultura existente em centenas de profissionais.  lsto demandaria um investimento vultoso de treinamento e negociação.

4. Coerência é a propriedade que observa se os dados armazenados espelham a realidade.

Referências Bibliográficas:

1. BIO, S.R. Sistemas de informação: um enfoque gerencial. São Paulo: Atlas, 1987.

2. BRODIE, M.; MYLOPOULOS, J.; SCHMIDT, J. On conceptual modelling: perspective from AI, databases and programming languages. New York: Spring-Verlag, 1984.

3. DAVIS, G.; OLSON, M. H. Management information systems. /S. I./ McGraw-Hill, 1984.

4. LEITE, J. C. S. P. O enfoque social na análise de sistemas. In: CONGRESSO NACIONAL DE INFORMÁTICA, 16, 1983, São Paulo. Anais... São Paulo: SUCESU, 1983. p. 272-274.

5. LEITE, J.C.S.P. Sistemas de informação e engenharia de software: o elo gerencial. In: CONGRESSO NACIONAL DE INFORMÁTICA, 24, 1991, São Paulo. Anais ... São Paulo: SUCESU, 1991. p. 98-105.

6. KLING, R.; SCACHI, W. Recurrent dilemmas of computer use in complex organizations. AFIPS Conference, 48, 1979. Proceedings. /S. n. t./ p. 107-115.

7. MARKUS, M. L. Systems in organizations: bugs + features. /S. I./ Pitman, 1984.

8. NAÚFEL, J. Dicionário jurídico brasileiro. /S. I./ Ed. Naúfel, 1984.

bb@celepar.gov.br