1

Os Sistemas de Informação no Planejamento Estratégico Empresarial - Um Roteiro Básico(*)

1. INTRODUÇÃO
2. METODOLOGIAS BÁSICAS DE PLANEJAMENTO
2.1 FCS - Fatores Críticos de Sucesso
2.2 PSN - Planejamento do Sistema de Negócios
3. FATORES DECISIVOS NO PLANEJAMENTO DE SI
3.1 Necessidades de Mudança Organizacional
3.2 Controle Centralizado ou Descentralizado
3.3 Agilidade Organizacional
3.4 Globalização e Questões Internacionais
4. INVESTIMENTOS, CUSTO/BENEFÍCIO E RISCOS
4.1 Portifólio de Projetos
4.2 Alocação de Recursos
4.3 Custo/Benefício
4.4 Benefícios Tangíveis e Intangíveis
4.5 Tendência para Negligenciar Custos
4.6 Timing de Custos e Benefícios
4.7 Riscos
5. CONCLUSÃO
REFERÊNCIAS

Premissas básicas para seleção de nossas Informações

Alinhamento com a missão dos nossos processos - Definimos, claramente a missão de todo os
processos objetivos da organização, que estão desdobrados nas suas respectivas gestões; esta
providencia é fundamental para que para que nosso sistema de informação não opere no vazio e
permita se aferir o que é efetivamente relevante.

Identificação dos Indicadores críticos - A identificação de indicadores críticos aponta que problemas
existem, mas não os resolve. Para tanto, possuímos um sistema que possa coletar, processar e exibir
(em tela) as informações pertinentes dando conta do Status da produção no ambiente On-line.

Que dados devem ser coletados ?

Onde e como tais dados serão coletados ?
Como tais dados serão transmitidos ?
Como tais dados serão processados e armazenados ?
Que aplicações farão uso de tais dados ?
Como estas aplicações se relacionarão com a organização como um todo ?

Apesar da Arquitetura de Informação (AI) ser considerada como uma questão técnica, na realidade ela é
uma forma de visualizar de forma gerencial e estratégica como opera a organização. No contexto das
aplicações de telecomunicações, por exemplo, Peter Keen afirma que a arquitetura de informação é a
estratégia (5). Portanto, as questões sobre a AI devem ser resolvidas com base numa combinação de
considerações técnicas e organizacionais.
A especificação de uma nova AI é tarefa de grande porte, que normalmente só é realizada em função da
expectativa de grandes revisões na organização. Para desenvolver uma AI, a metodologia do PSN deve
ser seguida por 14 etapas seqüenciais, devidamente identificadas num manual específico da IBM (6).
Com o propósito de se entender a idéia básica dessa metodologia, basta considerar suas principais
cinco etapas:
 2

ETAPA 01 IDENTIFICAÇÃO DOS PROCESSOS DE NEGÓCIOS.

Esta etapa requer uma verificação cuidadosa em cada uma das áreas funcionais da organização, tais
como produção, vendas e marketing. Dentro de cada uma dessas áreas deve ser bem identificado e
devidamente os seus processos-chave Por exemplo: na área de vendas os processos-chave podem
incluir o gerenciamento de contas, a determinação de preços e o prognósticos de vendas. Cada
processo-chave deve ser definido e descrito de forma a se conseguir um consenso sobre que atividades
são desenvolvidas rotineiramente na área. Dentro de cada área analisada todas os níveis de atividade
devem ser cobertas, do planejamento estratégico ao controle de tarefas.

ETAPA 02 IDENTIFICAÇÃO DOS DADOS DE NEGÓCIO. Nesta etapa deve ser realizada uma análise
completa e minuciosa dos processos de negócio mapeados na etapa anterior, com vistas aos dados
utilizados por esses processos, procurando agrupá-los em classes de dados. Esta classificação visa
identificar os principais grupos de dados que são gerados ou utilizados pelos processos de negócio. Nos
processos de negócios para determinação de preços, por exemplo, as calsses de dados utilizados
podem incluir os prognósticos de mercado e os históricos de preços.

ETAPA 03 IDENTIFICAÇÃO DA ARQUITETURA DE INFORMAÇÃO. Esta etapa tem início com o

mapeamento das correlações entre as classes de dados, os processos de negócios e os sistemas de
informação. O sprocedimentos para se analisar estas informações estão detalhadamente descritos no
manual do PSN (6). Por exemplo, para realizar a correlação entre classes de dados e processos de
negócio, o analista deve montar uma matriz com os processos na horizontal e as classes de dados na
vertical, como é utilizado em empresas de manufatura. Ali deve ser observado as marcaçõpes de alguns
cruzamentos na matriz, que são fatores-chave para o projeto da AI.

ETAPA 04 IDENTIFICAÇÃO DE AMBIENTE E OBJETIVOS DE NEGÓCIO. Esta etapa consiste

essencialmente de entrevistas com os altos executivos que possam explicar quais são os objetivos e
estratégias da organização, e de como esses fatores poderão mudar no futuro. Questões-chave da
organização, como tendências e desafios de mercado, posicionamento competitivo e áreas mais
problemáticas, devem ser exploradas nas entrevistas, de forma a se ter uma idéia clara de para onde
caminha a organização e de quais sistemas de informação podem se ajustar às estratégias executivas.
Aqui podem ser utilizadas as abordagens da metodologia FCS vistas acima, de forma a coletar e
alinhavar algumas das informações pretendidas.

ETAPA 05 RECOMENDAÇÃO DE NOVA ARQUITETURA DE INFORMAÇÃO. Aqui se trata de decidir

como se mudar da atual AI para uma futura AI mais adequada para dar suporte mais eficiente aos
objetivos de negócio da organização. Assim sendo, os projetistas da nova AI devem indicar claramente a
direção de mudança e a seqüência apropriada das fases de projeto para que tal mudança possa ocorrer
adequadamente, sempre minimizando a perda de oportunidades e rupturas desgastantes para a
organização.
A metodologia PSN pode ser de grande utilidade em duas situações: quando a organização está
iniciando um processo de automação de seus sistemas e serviços, ou quando ela está empreendendo
uma revisão importante de seus sistemas e serviços. Os resultados do PSN deve constar de um quadro
compreensível no qual os novos sistemas revisados devem se encaixar. Isto devidamente feito, deverá
surgir naturalmente, e por longo prazo, um fator de encorajamento para o desenvolvimento contínuo dos
sistemas.
O tempo de aplicação da metodologia PSN deve levar não mais de seis a oito semanas pois, caso
contrário, o ânimo eventual da alta gerência da organização pode esmorecer e criar desmotivação, já
que ao PSN demanda a participação ativa de cinco ou seis níveis gerenciais por todo este período (7).
Em geral, esta intensa participação é difícil de se conseguir, principalmente por parte de executivos que
já se sentem supersolicitados e até mesmo estressados. A metodologia PSN somente funcionará se a
alta gerência estiver motivada, disponível e desejosa de participar intensamente e de se submeter a uma
 3
análise radical em benefício da eficácia organizacional. Portanto, a metodologia PSN de ser
empreendida quando o alto staff da organização der seu aval irrestrito e mesmo apadrinhar sua
aplicação através de fortes recomendações. O ideal seria que um dos membros da alta direção da
organização desempenhe positivamente o papel de sponsor da aplicação do PSN.
As metodologias FCS e PSN podem dar importante suporte em diversos aspectos do planejamento dos
sistemas de informação que fará parte do planejamento estratégico da organização. A metodologia FCS
está enfocada na identificação das informações e dos sistemas cruciais para o sucesso dos negócios, ao
passo que a metodologia PSN está enfocada no entendimento de como as informações e os sistemas se
encaixam e se ajustam para formar os sistemas de informação para viabilizar o sucesso dos negócios da
organização. As ideias que sustentam as metodologia FCS e PSN são procedentes e prioritárias, mas
não são as únicas que darão suporte a um sistema de informação na prática organizacional, onde outros
fatores complementares, como as características da organização e seu ambiente de negócios, deverão
ser também considerados no planejamento dos sistemas de informação.

3. FATORES DECISIVOS NO PLANEJAMENTO DE SISTEMAS DE INFORMAÇÃO

O planejamento de sistemas de informação deve estar firmemente vinculado aos planejamentos de
negócios da organização e deve refletir claramente os meios de como ela opera atualmente e como ela
deverá operar no futuro. Portanto, o plano de sistemas de informação deve envolver fatores decisivos
tais como as necessidades de mudança organizacional, o balanço entre centralização e
descentralização, a agilidade da organização para absorver e gerenciar novos sistemas, e as questões
internacionais relacionadas aos sistemas.

3.1 Necessidades de Mudança Organizacional

Muitos observadores privilegiados, como Peter Drucker, acreditam que nos anos finais da década de
1990 deverão ocorrer mudanças rápidas, e mesmo bruscas, nas práticas de negócios das organizações
(1, 8). Nessa linha, o planejamento dos sistemas de informação deve reconhecer a existência de
mudanças rápidas e de competição feroz entre as organizações. que deverão persistir nesse período.
Portanto, temas prioritários que devem ser considerados no planejamento dos sistemas de informação
incluem:

REENGENHARIA DE PROCESSOS
REDUÇÃO DE PORTE (DOWNSIZING)
TERCEIRIZAÇÃO E QUARTEIRIZAÇÃO
PARCERIAS E ALIANÇAS

REENGENHARIA - Trata-se de um re-projeto radical de mudança nas práticas de trabalho da

organização, dado que as atuais práticas de trabalho estão entrando em obsolescência e não irão
satisfazer os objetivos de negócios nas futuras operações organizacionais, previstas em seu
planejamento estratégico. Um interessante case study de reengenharia é relatado por Michael Hammer,
relativo a uma grande empresa de seguros norte-americana (9). Ali trabalhavam 19 pessoas em cinco
departamentos para análise da cada pedido de seguro e, depois de uma reengenharia de processos,
apenas uma única pessoa, auxiliada por um sistema de informação integrado, tornou-se suficiente para
desempenhar todas as funções necessárias. Deve ser sublinhado que a reengenharia parte do princípio
que qualquer sistema existente pode ser radicalmente mudado para tornar-se mais efetivo e mais
simples. A reengenharia enfoca mais o "porque" dos processos existentes, mais do que o detalhe de
"como" os processos ocorrem, daí sua radicalidade característica. Esta abordagem analítica pode
impedir que a organização venha a automatizar processos ou sistemas inócuos. Para tanto, a
organização deve destacar um de seus diretores ou executivo de alto escalaão para atuar como sponsor
do programa de reengenharia, o qual deverá coordenar um grupo de acompanhamento denominado de
steering comitee (10).

DOWSIZING - Trata-se de uma redução drástica, tanto no número de membros do staff gerencial como
no número de camadas gerenciais da organização, feita não somente pela redução óbvia de custos
operacionais mas também para a redução do tempo de retorno/resposta às necessidades dos clientes.
 4
Aqui entra o papel polivalente dos sistemas de informação, que deve ser considerado no seu
planejamento: por um lado tornando as informações prontamente disponíveis, e portanto dispensando a
gerência intermediária, e por outro lado melhorando a execução de tarefas através da integração
interdepartamental, assim dispensando gerentes que se ocupavam em sumariar e transmitir as
informações.

TERCEIRIZAÇÃO - Trata-se de um importante aspecto relacionado aos sistemas de informação quando

da ação de dowsizing em algumas organizações. Visando redução de custos e/ou aumento de eficiência,
muitas organizações decidem subcontratar total ou parcialmente suas operações de computação e de
sistemas de informação com empresas especializadas (11). A idéia aqui é dar prioridade aos recursos
materiais e humanos da organização que estejam voltados às áreas em que ela compete nos negócios,
tais como tecnologia de manufatura nas empresas industriais, ou desempenho de tarefas jurídicas, como
a redação e execução de contratos. Um caso interessante foi o da Pan American Airways, que em 1991
negociou com diversos de seus fornecedores um acordo de terceirização no valor de US$ 500 milhões,
envolvendo a movimentação de todo seu hardware e software,e cerca de 500 de seus funcionários (12).
Com a consolidação da terceirização como processo de agilização empresarial, surgiu a Quarteirização,
que trata de terceirizar o gerenciamento das terceirizações de uma mesma organização (13).

PARCERIAS - Trata-se de arranjos e alianças de negócios cooperativos entre duas ou mais

oragnizações com competências complementares (14). É comum, nos Estados Unidos, o exemplo de
mercearias que formam parcerias com empresas financeiras visando aumentar a conveniência de seus
fregueses através da compra por meio de transferência eletrônica de fundos. Nas parcerias, os sistemas
de informação podem exercer impactos positivos ou negativos. Se forem cuidadosamente projetados e
gerenciados, os sistemas de informação podem tornar as estratégias de parceria mais eficientes através
da automação da troca de informação entre os parceiros. Por outro lado, se forem mal projetados, os
sistemas de informação podem se transformar num obstáculo tornando as estratégias de parceria
ineficientes e embaraçosas.
A reengenharia, o downsizing, a terceirização e as parcerias, junto com a melhoria de oferta de produtos
aos clientes, são fatores predominante no clima de negócios dos anos 1990. O planejamento de
sistemas de informação que ignorar estes fatores de oportunidades de negócios não dará o necessário
suporte ao planejamento estratégico das organizações. Além disso, o planejamento de sistemas de
informação devem também refletir o balanço organizacional entre centralização e descentralização dos
controles.

3.2 Controle Centralizado ou Descentralizado

A gradação de balanço entre as necessidades de centralização e descentralização é um fator
determinante no sucesso dos sistemas de informação. Da mesma forma que outros empenhos
organizacionais, a supercentralização pode resultar num verdadeiro engessamento e enrigecimento dos
sistemas, de tal modo que eles perdem a capacidade de manejar as situações locais e departamentais.
Por outro lado, a excessiva descentralização pode dar origem a sistemas que manejam com agilidade os
problemas localizados, mas que não apresentam capacidade de integração interdepartamental para dar
suporte à solução de situações mais amplas da organização. As decisões envolvendo centralização ou
descentralização freqüentemente acabam por desaguar em debates sobre eficiência e eficácia, aquela
lembrando o uso do mínimo recurso para uma dada produção, e esta lembrando apenas a produção
correta independente dos recursos.

A centralização dos processos e controles é aparentemente mais eficiente porque elimina os esforços e
recursos eventualmente redundantes. Admitindo-se que a descentralização seja tecnicamente viável, ela
pode ser mais efetiva já que permite aos recursos humanos tomarem as decisões mais adequadas às
situações locais.
 5
Na problemática do gerenciamento de sistemas de informação, o termo "processamento distribuido" é
frequentemente usado para descrever a dispersão localizada dos sistemas e dos controles. As
organizações que têm mais processamento distribuido, em conseqência também têm uma função mais
descentralizada de seus sistemas de informação. Nessa linha, a Figura-2 procura indicar os fatores
decisivos no balanço entre centralização e descentralização. Aqui alguns fatores devem ser levados em
conta: a localização do hardware e dos dados, os padrões e o controle dos sistemas de informação.

Fig.2 - Matriz comparativa entre centralização e descentralização de sistemas de informação

Localização do Hardware e dos Dados - Numa organização os computadores podem estar localizados
em um ou mais dos seguintes níveis: matriz da corporação, centros regionais de processamento de
dados, centros de processamento locais (em unidades fabris ou escritórios de filiais), processadores
departamentais, processadores de trabalho em grupo (groupware), e estações de trabalho individuais
(15). A condição de maior centralização é a de um centro único de processamento (CPD) ligado por
telecomunicação a terminais distribuídos em outras localidades. Por outro lado, a condição de maior
descentralização é a de alocar microcomputadores e estações de trabalho aos recursos humanos da
organização, e deixar que cada um desempenhe e controle seus próprios processamentos. Muitas
organizações de grande porte, entretanto, escolhem uma configuração intermediária, combinando uma
central geral de computação com processadores localizados e PCs individuais.
Na distribuição de dados, a situação mais centralizada é manter todos os bancos de dados em um
mesmo local da organização. A situação menos centralizada é permitir que os recursos humanos
mantenham seus próprios sistemas de dados. As configurações intermediárias empregam uma base de
dados central, que pode ser acessada por qualquer ponto da organização, além de bases de dados de
acesso local ou individual. As bases de dados centralizadas são usadas para: contabilidade corporativa,
inventário de estoques corporativos, e outros dados que devem ser controlados pelo mais alto nível
organizacional mas que podem ser acessados amplamente. Muitas organizações adotam um
compromisso entre a conveniência e a acessabilidade de bases locais, com o controle e a
manutebilidade de bases centralizadas, e assim o fazem através do download de partes relevantes da
base de dados centralizada para os usuários locais. Em consequência, muitas organizações
desemvolveram vastas redes de telecomunicação para a movimentação de dados entre as bases locais
e as bases distribuidas.

Padrões e Controle dos Sistemas - O estabelecimento de padrões corporativos é essencial para a

eficiência organizacional, mesmo que o hardware e as bases de dados estejam totalmente
descentralizados. Os padrões corporativos é que irão determinar que hardware e que software deverão
ser adquiridos pela organização e que procedimentos deverão ser adotados na instalação e operação
dos sistemas de informação. Os padrões estabelecidos para o hardware e para as bases de dados
facilitam aos recursos humanos compartilharem suas informações e suas tarefas. Os padrões são
também necessários em economia de escala na compra de equipamentos, no treinamento dos recursos
humanos, e na utilização das bases de dados. Sem os padrões, os departamentos e setores da
organização podem comprar seus hardware e software de forma independente, de sorte que venham a
se instalar sistemas incompatíveis entre si., inviabilizando o trabalho compartilhado.
Independente de onde residem o hardware e os dados, sobressai a questão delicada do controle dos
sistemas. Por exemplo, quem deve controlar o sistema de prognóstico de vendas de uma empresa, se o
gerente do departamento de marketing ou o gerente dos sistemas de informação. Numa abordagem
centralizadora, um departamento central de marketing poderá deter o controle de todos os sistemas de
informação, e qualquer demanda para se mudar um sistema será processado neste departamento
centralizador. Por outro lado, numa abordagem descentralizadora, fica evidente que quem detiver o
controle dos prognósticos de venda deterá também o controle dos sistemas de informação. O controle
centralizado pode parecer mais interessante, mas certamente não atenderá com plenitude todas as
características de desempenho desejadas pelos usuários dos sistemas. De qualquer forma, o tradicional
balanço organizacional entre abordagens centralizadoras e descentralizadoras será apenas um dos
 6
fatores que afetam a agilidade da organização para absorver e gerenciar competentemente seus
sistemas de informação.

3.3 Agilidade Organizacional

O planejamento de sistemas de informação só será bem sucedido se a organização apresentar aptidão e
agilidade na implantação dos sistemas previstos, e se o seu staff estiver preparado para o
desenvolvimento e a manutenção dos mesmos, o que dependerá da experiência e do histórico da
organização no tratamento e na utilização de sistemas de informação. Nessa linha, dois fatores devem
ser considerados: os estágios de implantação e as equipes de desenvolvimento dos sistemas de
informação.

Estágios da Implantação de Sistemas de Informação - Conforme demonstra Richard Nolan, as

organizações enfrentam uma sequência de seis estágios típicos da implantação de sistemas de
informação, que devem ser considerados no seu planejamento (16, 17). Estes estágios estão ilustrados
na Figura-3. Os três primeiros estágios cobrem o processo de proliferação dos sistemas de informação, o
reconhecimento de sua importância e a constatação de que eles devem ser gerenciados com eficiência.
No estágio de início, ou iniciação, a introdução de novas tecnologias leva ao reconhecimento de que as
mesmas podem melhorar significativamente a forma operaracional dos negócios da organização. No
estágio de

contágio, os sistemas de informação entram em uso generalizado mas com muita experimentação,
apresentando sucessos parciais e algumas falhas. No estágio de

controle, responde pelo alto custo resultante do uso excessivo da nova tecnologia, função do uso
indiscriminado, descontrolado e redundante dos sistemas de informação. Neste terceiro estágio, os
investimentos nas tecnologias de informação são feitos cuidadosamente, verificando-se com clareza se
eles se justificam pela sua qualidade, se são compatíveis com as já existentes e se atendem plenamente
os padrões organizacionais.
Os três estágios finais cobrema as questões relativas ao custo/benefício dos sistemas, através da
introdução de diversas abordagens gerenciais para que se possa atingir o máximo benefício dos
sistemas de informação com o controle cerrado de seus custos (18, 19). No estágio de integração,
aplicações já existentes são melhoradas e desenvolvidas para prover benefícios através da integração
dos sistemas ao longo da estrutura organizacional. No estágio de administração de dados, DBMS (data
base managent systems) e outras metodologias são introduzidas nos sistemas de informação para o
eficiente gerenciamento dos recursos de dados e para o adequado balanço entre centralização e
descentralização. Aqui é atingido um novo nível de cooperação entre o staff técnico e os usuários. No
estágio final de maturação, os sistemas de informação são desenvolvidos em escala de maior
importância, com maior amplitude de usuários, e já integrados interdepartamentalmente na organização.

Fig. 3 - Os estágios típicos da implantação de sistemas de informação

Esse modelo teórico de estágios foi desenvolvido no início da década de 1970, procurando descrever o
início da introdução de sistemas computadorizados (mainframes) nas organizações. Apesar disso, suas
idéias básicas continuaram atuais quando da introdução dos microcomputadores na vida organizacional,
ocorrida em meados da década de 1980. Em termos da agilidade organizacional, o ponto básico é o fato
de que o planejamento de sistemas de informação deve reconhecer a agilidade da organização para
absorver qualquer sistema em particular. O uso pela organizaão de algumas tecnologias mais complexas
e amplas, como o processamento de transações, só poderá se verificar no estágio de maturação e não
antes, ao passo que outros tipos de tecnologias, como sistemas especialistas, já podem ocorrer no
estágio de contágio dos sistemas. Portanto, oplanejamento de sistemas de informação deverá
necessáriamente incluir o planejamento dos staffs, o planejamento dos resursos e o planejamento dos
suportes, para poder levar em conta estes tipos de diferença.
 7

Equipes Necessárias ao Desenvolvimento dos Sistemas - Para que o planejamento de sistemas de

informação seja bem sucedido, como em qualquer planejamento, é preciso que ele seja consistente com
as capacitações e coma cultura profissional dos recursos humanos que serão usuários e gestores dos
sistemas na organização. Nessa linha, o staff dos sistemas de informação deve estar disposto e
capacitado para desempenhar as tarefas de desenvolvimento e manutenção demandadas pelo
planejamento. Alem disso, os usuários deveraõ estar desejosos e habilitados a absorver as mudanças
organizacionais exigidas pelo planejamento dos sistemas.
Organizações intensivas em informação, tais como as empresas financeiras e bancárias, torna-se
fundamental a manutenção de staffs especialmente capacitados para o gerenciamento e
desenvolvimento de sistemas de informação altamente competitivos. Por outro lado, em organizações
pouco intensivas em informação, torna-se mais efetivo, até por questões de custo/benefício, a utilização
de pacotes tecnológicos disponíveis no mercado. Esta última abordagem é certamente menos
desafiadora e menos atrativa para o staff dos sistemas de informação. Uma equipe que apenas instala
pacotes já desenvolvidos pode prestar serviços significativos à organização, mas estará pouco apta a
desenvolver um sistema de informação competitivo quando for necessário.
O casamento bem sucedido entre o planejamento dos sistemas de informação e as habilidades e
aspirações do staff torna-se, freqüentemente, uma questão-chave. Com a finalidade de reter e manter na
organização uma equipe altamente competente de programadores e analistas, torna-se geralmente
necessário que o planejamento de sistemas de informação contemple alguns projetos de substanciais de
desenvolvimento. De forma geral, analistas e programadores ambiciosos acham que o desenvolvimento
de novos sistemas é uma questão de desafio e reconhecimento profissional somado a um grande prazer
pessoal.
Finalmente. cabe lembrar que as questões relativas à agilidade organizacional são especialmente
complexas no caso de organizações geográficamente dispersas, cujas unidades operações geralmente
se encontram em diferentes estágios de assimilação dos sistemas de informação. Essas questões
podem ser bastante agravadas no caso de organizações que trespassam fronteiras, como as grandes
empresas transnacionais.

3.4 Globalização e Questões Internacionais

Na medida que as organizações e os negócios se globalizam e a competição organizacional toma
âmbitos internacionais, torna-se cada vez mais necessário que os sistemas de informação trespassem
as fronteiras nacionais. É o caso, por um lado, dos sistemas de controle e gerenciamento interno de
grandes empresas multinacionais. Por outro lado, é o caso de dos sistemas de ligação entre empresas
em um país com seus clientes, representantes e fornecedores em outros países. Para ambas as
situações, a importância dos sistemas de telecomunicações e informações internacionais cresce
vertiginosamente, dada a rápida globalização que caracteriza a década de 1990.
Essa crescente importância se dá porque aqueles sistemas provêem formas competentes de se dirimir
os obstáculos geográficos e temporais. Uma empresa multinacional de petróleo exemplifica bem alguns
dos principais problemas com os sistemas internacionais. Com cerca de 40 unidades de negócios
espalhadas pelo mundo, a empresa autorizou despesas de telecomunicação para cada uma até 1 milhão
de dólares por ano, mas frustou-se significativamente pela sua inabilidade em conectar eficientemente as
unidades através de um sistema padronizado (20).
As questões internacionais que afetam os sistemas de informação são muito amplas, podendo envolver
aspectos técnicos, tais como a compatibilidade de padrões, aspectos econômicos, tais como as tarifas
diferenciadas de pais para pais, e aspectos socio-políticos, tais como a diferença de idiomas e de
controle alfandegário. Onde os padrões são incompatíveis entre países, torna-se necessário a
reformatação de dados toda vez que se cruzam as fronteiras. Apesar de um organização isoladamente
não poder influenciar os padrões escolhidos por um determinado país, ela poderá estabelecer seus
próprios padrões e globalizá-los em suas redes internacionais de sistemas de informação.
As questões econômicas que afetam os sistemas de informação internacionais são óbvias para qualquer
executivo que faz uma chamada telefônica internacional. Fazer chamadas da Europa ou do Brasil para
os Estados Unidos é surpreendentemente mais caro do que chamadas na direção inversa. No início da
 8
década de 1980, um gerente de sistemas de telecomunicações de uma organização multinacional,
descobriu que as chamadas telefônicas da Espanha para a Alemanha eram seis vezes mais caras do
que as feitas em uma rede equivalente nos Estados Unidos (21). Isso significa que as estruturas de
taxas e tarifas devem ser analisadas cuidadosamente para avaliação de redes globais de sistemas de
informação.
As questões sociais e políticas que afetam os sistemas internacionais começam com as enormes
diferenças idiomáticas e culturais, que podem causar confusão e ineficiência significativas na interação
dos sistemas. Além disso, os negócios são regulamentados diferentemente de país para país, como por
exemplo as relações trabalhistas, as normas empregatícias e as normas contábeis, podem fazer com
que um determinado sistema de informação seja praticável em um país e impraticável em outro.
Finalmente, muitos países legislam formas de como se transbordar fluxos de dados pelas suas
fronteiras, particularmente dados concernentes a nomes de pessoas e à privacidade individual. A
França, por exemplo, em 1989 proibiu que a Fiat francesa continuasse a enviar dados sobre seus
operários franceses para a Fiat italiana, porque as legislações sobre privacidade nos dois países não
apresentam padrões compatíveis (22). Qualquer organização transnacional que dejese transmitir
internacionalmente registros pessoais, dados sobre cartões de crédito, e dados sobre clientes, deverá
examinar cuidadosa e comparativamente as legislações nacionais que podem ser afetadas.

4. INVESTIMENTOS, CUSTO/BENEFÍCIO E RISCOS

Até aqui o enfoque foi em uma análise de alto nível de planejamento para o ajuste das prioridades e para
a identificação de direcionamentos prático dos sistemas de informação. O próximo passo consiste na
tomada de decisão a nível de investimentos, através da determinação de como e de quais projetos
específicos constantes do planejamento devem ser empreendidos. Isso pode ser feito em dois estágios.
No primeiro, a gerência dos sistemas de informação procura alocar tentativamente seus recursos
disponíveis em diferentes tipos de projetos. No segundo, baseando-se nessas alocações, é tomada a
decisão de quais projetos serão empreendidos. Torna-se então conveniente que a organização
mantenha um adequado portifólio de projetos para seus sistemas de informação.

4.1 Portifólio de Projetos

O Portfólio de projetos de sistemas de informação de uma organização consiste no conjunto de projetos
que são projetados e devem ser executados. Esses projetos podem variar desde projetos sobre a mera
extensão de sistemas rotineiros já existentes, até projetos que tentam implantar novas idéias sobre
sistemas de informação. Podem incluir correção de defeitos, melhoramentos de sistemas, novas
aplicações importantes, projetos de infra-estrutura de informação, projetos de pesquisa, e projetos de
suporte aos usuários. Desde que os sistemas existentes necessitam de atualização na medida em que
as condições de negócio mudam e que os usuários identificam novos meios para usar a informação, os
portfolios típicos incluem de 60% a 80% de manutenção de sistemas. Manutenção pode significar
principalmente melhoramentos de sistemas, mas inclui também conserto de defeitos. Uma análise
sucinta sobre os diferentes tipos de projeto pode aclarar os principais dilemas relacionados aos portfolios
de projetos de sistemas de informação.

Correção - Consistem em projetos de conserto de sistemas existentes, e pode ser dividido em categorias
priorizadas. Defeitos que impedem os usuários de realizar suas tarefas ou os departamentos da
organização de operar com eficiência, recebem a maior prioridade. Os defeitos que provocam problemas
menores aos usuários recebem prioridade menor, e são realizados oportunamente. Nessa linha, defeitos
superficiais nos sistemas muitas vezes sequer sofrem conserto.

Melhorias - Consistem em projetos direcionados a melhorar a função de sistemas existentes sem a

mudança de seus conceitos fundamentais de operação. Os usuários ativos familiarizados com o perfil
operacional os sistemas, em geral têm muitas sugestões úteis de melhoria a fornecer. a listagem de
sugestões objetivas normalmente cresce na medida em que os usuários aprendem o que os sistemas
podem e não podem fazer em sua forma rotineira, e na medida em que os mesmos imaginam novas
formas de usar os sistemas com mais vantagem competitiva. Muitos gerentes de sistemas de informação
 9
podem designar programadores para checar os melhoramentos sugeridos pelos usuários, e vão
verificar que eles raramente fazem um repara na listagem de sugestões.

Novas Aplicações - Consistem em projetos que prover novos tipos de capacitação de grande porte para
os sistemas de informação, e não pequenas melhorias reclamadas pelos usuários. Esses projetos
podem ser de dois tipos: o primeiro tipo consiste de projetos que requerem novas tecnologias, novos
conhecimentos e novas metodologias, e o segundo tipo inclui sistemas para os quais o conhecimento
existente é suficiente. Os do primeiro tipo em geral apresentam maiores riscos na execução do que os
que aqueles que utilizam abordagens rotineiras. Para se reduzir a probabilidade de que muitos projetos
de alta visibilidade no portifólio venham a falhar, apenas um número limitado de projetos de alto risco
deve ser empreendidos ao mesmo tempo.

Infra-Estrutura de Informação - Consiste em projetos que estabelecem as ferramentas e as metodologias

que devem ser utilizadas no desenvolvimento de novas aplicações dos sistemas de informação. Projetos
típicos de infra-estrutura incluem a instalação de novas bases de dados, novas redes, softwares de
desenvolvimento, e novos tipos de hardware. Um exemplo típico e muito interessante é dado por Max
Ropper numa análise de caso sobre a rede da American Airlines que permite acesso a todos os seus
funcionários para a obtenção de qualquer dado específico necessário ao desempenho eficiente da
organização (23).

Pesquisa - Consiste em projetos de avaliação crítica de novas metodologias e novas tecnologias, a fim
de se determinar como elas devem ser utilizadas apropriadamente. São, em geral, projetos importantes,
pois permitem a inovação e as mudanças competitivas. Os projetos de pesquisa podem envolver a
busca de novas ferramentas, a sua exprimentação tentativa, e a realização de estudos-piloto sobre as
mesmas junto a usuários particularmente interessados e desejosos de inovações e de novas aplicações
dos sistemas da organização. Um gerência de sistemas de informação que não desenvolve projetos de
pesquisa, certamene estagnará mais cedo ou mais tarde.

Suporte a Usuários - Consiste em projetos de auxílio aos usuários com aplicações desenvolvidas pelo
staff dos sistemas de informação da organização, com aplicativos adquiridos de fornecedores, ou no
desempenho de tarefas individuais em computadores pessoais. As tarefas individuais típicas envolvem
geralmente ferramentas tais como planilhas eletrônicas, processadores de texto, pequenas bases de
dados e apresentações gráficas. Dada a crescente demanda interna dos projetos de suporte a usuários,
muitas organizações acoplam aos sistemas de informação staffs especiais para o atendimento exclusivo
às necessidades dos usuários de desenvolver e manter suas aplicações próprias. Nesse sentido, a
contribuição da gerência de sistemas de informação é a de reduzir custo e aumentar a eficiência através
da padronização de alguns softwares e hardwares, do treinamento adequado dos usuários, e do auxílio
na análise e solução de seus problemas.

4.2 Alocação de Recursos

A questão é decidir como deve uma organização distribuir e alocar seus recursos de sistemas
informação nos diferentes projetos previstos no planejamento. Uma ênfase demasiada em projetos de
manutenção pode levar a nada no longo prazo. Excessiva ênfase em projetos de novos
desenvolvimentos pode vir a solapar a manutenção de sistemas existentes. Pouca ênfase em projetos
de suporte a usuários pode pôr a perder os benefícios e retornos de investimentos anteriores feitos nos
sistemas.
Não existe uma fórmula ideal para a alocação de recursos. Em muitos departamentos de sistemas de
informação, pode-se dobrar o staff e ainda não se satisfazer todo o trabalho demandado pelos usuários.
Na prática, os departamentos de sistemas de informação alocam um percentual do seu tempo disponível
para cada categoria de projeto. Com 60% a 80% para os projetos de manutenção, pouco resta para
outras categorias de projeto. Isso explica a tendência para aplicações produzidas por fornecedores e por
usuários.
Uma questão central sobre o portifólio de projetos é como ele reflete o setor de atuação em que a
organização realmente se encontra e qual a estratégia da organização com relação a esse setor. Numa
 10
organização intensiva em informação, como os bancos e as financeiras, a falta de desenvolvimento de
novos sistemas certamente provocará falhas em aspectos estratégicos de preço, serviços e qualidade.
As organizações que escolhem permanecer atrasada em matéria de sistemas de informação, devem
procurar outras áreas para vencer nos negócios.

4.3 Custo/Benefício
Cada projeto do portifólio é normalmente avaliado em termos de seus custos, seus benefícios e seus
riscos. Uma análise Custo/Benefício compara seus custos atuais ou projetados com seus benefícios
atuais ou projetados, e pode também enumerar seus riscos previsíveis. A análise Custo/Benefício pode
ser usada de muitas formas. A primeira é ser utilizada como uma ferramenta de planejamento para
ajudar na alocação de recursos escassos entre demandas competitivas. A segunda é ser usada como
uma ferramenta de auditagem para determinar o quanto um determinado projeto atingiu ou não seus
objetivos (24).
Apesar da aparência lógica da análise Custo/Benefício ela apresenta importantes limitações. Na
realidade ela é apropriada para os casos onde os sistemas visam o aumento de eficiência. Quando o
objetivo é o de provocar transformações na organização, os custos e os benefícios se tornam difíceis de
se estimar. Além do mais, já que a análise Custo/benefício é normalmente feita para se justificar uma
solicitação de alocação de recursos, os seus números podem ser tendenciosos. Além disso, a análise
Custo/Benefício pode ignorar ou desprezar os riscos previsíveis do projeto em questão. Para se entender
melhor essa análise, deve-se considerar as questões racionais em maior detalhes.

4.4 Benefícios Tangíveis e Intangíveis

Os benefícios, assim como os custos, podem ser classificados como tangíveis e intangíveis. Os
Benefício Tangíveis são os que podem ser mensurados de forma direta para se avaliar o desempenho
dos sistemas de informação, como por exemplo a redução de tempo por chamada telefônica, melhoria
dos tempos de resposta, e redução de taxas de erro, lembrando sempre que os benefícios tangíveis
podem ou não ser medidos em termos monetários. Entretanto, colocados em uma estrutura de
custo/benefício, os benefícios tangíveis passam a exigir que os aumentos de desempenho sejam
traduzidos em termos monetários, para que possam finalmente ser comparados aos custos. Os
Benefícios Intangíveis são aqueles que afetam o desempenho mas que são difíceis de serem
mensurados, já que se referem a conceitos vagos. Exemplos de benefícios intangíveis são as seguintes
melhorias:
na supervisão
no gerenciamento
na motivação
na informação para a tomada de decisão
no aprendizado organizacional
na habilidade para reagir a situações inesperadas
na habilidade de avaliar mais alternativas de competitividade
Apesar desses objetivos serem de grande valor, são também de mensuração complexa. Mesmo que se
consiga medi-los, seria muito difícil expressá-los em termos monetários para compará-los com os custos.
cabe lembrar que na grande maioria dos casos, os custos de um projeto são tangíveis, ao passo que os
benefícios são intangíveis. Mesmo assim, os benefícios intangíveis são por demais importantes e não
devem ser ignorados de forma nenhuma. Na prática, a maioria dos benefícios dos sistemas de
informação são intangíveis.

4.5 Tendência para Negligenciar Custos

Uma das falhas mais comuns nas análises de Custo/Benefício é o negligenciamento de certos custos
dos sistemas de informação. Uma análise pouco cuidadosa envolve normalmente os custos de
hardware, de software e de programação, mas pode omitir outros custos menos óbvios dos sistemas,
como treinamento por exemplo. Para evitar esse tipo de omissão, a listagem de referência para detecção
 11
de custos de sistemas de informação pode ser muito útil. Nela pode-se observar como os custos de
gerenciamento e de staff aparecem em quatro diferentes estágios dos projetos, e como a interação com
usuários, o treinamento, e a coleta de dados são parte do custo do sistema. para a maioria dos sistemas,
o treinamento, a implementação e as correções absorvem tanto tempo e esforço que seus custos podem
exceder de muito os de hardware e software.

4.6 Timing de Custos e Benefícios

Os fluxos de custo e de benefício dos sistemas de informação ocorrem em tempos diferentes. O caso de
custos e benefícios de um sistema de informação para atendimento de clientes, exemplificado na Figura-
5, é uma demonstração típica de como os custos precedem em tempo os benefícios. Ali pode ser visto
que o formato da curva de custos reflete a variação do número de pessoas envolvidas na implementação
e no desenvolvimento do sistema, mostrando que os benefícios só aparecem a partir do sétimo mês, e
crescem até um máximo quando a implementação termina, e o balanço de custo/benefício só se torna
positivo a partir do 11o mês. Se o desenvolvimento do sistema leva mais tempo do que o planejado, o
benefício esperado só se tornará positivo muito mais tarde.

Fig.5 - Exemplo de fluxos de custo e benefício de um projeto

4.7 Riscos
É surpreendentemente grande o percentual de projetos de sistemas de informação que falham em atingir
seus objetivos ou só atingi-los após muito mais tempo e muito mais esforço do que o inicialmente
planejado. Os desapontamentos mais comuns incluem:
o projeto se completa além do tempo planejado
o projeto ultrapassa o orçamento previsto
os benefícios desejados não são atingidos
o desempenho técnico do sistema é inadequado
os usuários rejeitam o sistema
a inconstância das prioridades reduz a importância do projeto
Desde que o desenvolvimento de sistemas de informação é um esforço arriscado, os riscos devem ser
cuidadosamente considerados enquanto se decide que projetos podem ser iniciados. Quanto mais o
 12
desenvolvimento de um sistema se afasta de sua situação ideal, maiores ficarão seus riscos inerentes.
Isso não quer dizer que somente os sistemas de baixo risco devem ser desenvolvidos, pois as
organizações que só desenvolvem sistemas de baixo risco, acabam sem experiência nessa atividade
essencial e acabam provavelmente atingindo menos e menores benefícios dos sistema do que se
poderia obter (25). Um forma estruturada de se avaliar os riscos de um projeto, é a de identificar
inicialmente os fatores de risco específico, criar um questionário para a avaliação do projeto em termos
de cada fator específico de risco, e então calcular o risco global do projeto através da soma ponderada
da pontuação dos riscos específicos, conforme sugerido por McFarlan (26). Essa abordagem sugere a
montagem de um questionário de avaliação dividindo os riscos do projeto em três classes:
porte do projeto
estrutura do projeto
tecnologia do projeto

O risco de porte pode ser avaliado em termos da previsão de homens-hora feita no planejamento, do
tempo previsto no cronograma para duração do projeto, e do número de departamentos da organização
envolvidos no projeto. O risco de estrutura pode ser avaliado em termos de parâmetros mais complexos,
tais como o grau de mudança envolvido no projeto, a atitude dos usuários finais do projeto, e o grau de
compromisso dos usuários e da alta gerência com o projeto. O risco de tecnologia pode ser avaliado em
termos do grau de inovação do hardware e do software envolvidos no projeto, e o grau de conhecimento
e de preparo dos usuários e da equipe de desenvolvimento do projeto. Cada organização deve fazer
uma avaliação do risco global do seu portifólio de projetos de sistemas de informação, o qual, aliás, pode
ser visto também como um portifólio de riscos, isto é, um perfil de riscos agregados que perpassa a lista
de projetos previstos no portifólio.

5. CONCLUSÃO
À primeira vista pode parecer óbvio que o planejamento de sistemas de informação deve normalmente
fazer parte integrante do planejamento estratégico das organizações. Entretanto, não é o que se verifica
na prática, mesmo em países como os Estados Unidos, onde cerca de 95% das empresas afirmam
manter sistemas de informação regulares, mas metade das quais ainda não contemplam o planejamento
dos mesmos dentro de seus planejamentos de negócios, segundo levantamento feito por Martino entre
as 334 maiores empresas norte-americanas (27). Muitas organizações apenas mantem um enfoque
tecnológico com relação aos seus sistemas de informação, preocupando-se tão somente em planejar
projetos de hardware e software, raramente inserindo-os nas questões de negócios. Apenas 8% inserem
com precisão o planejamento dos sistemas em seus planejamentos de negócio. Em levantamento mais
recente feito por Goff e Puttre, apenas 35% das empresas afirmaram que os seus sistema de informação
davam suporte efetivo às suas atividades de negócio (28). Trata-se de abordagem moderna ainda em
absorção pelas organizações que, somente mediante as crescentes pressões da competividade e da
globalização que caracterizam a década de 1990, começam a incorporar efetivamente o planejamento
de seus sistemas de organização em seu planejamento estratégico.
REFERÊNCIAS
(1) CAMPOS FILHO, M.P. Os Sistemas de Informação e as Modernas Tendências da Tecnologia e dos
Negócios, RAE, v.34, n.6, Nov./Dez.1994, pp.33-
(2) ROCKART, J.F. e CRESCENZI, A.D. Engaging Top Management in Information Technology, Sloan
Management Review, MIT Press, Summer 1984, p.3
(3) ROCKART, J.F. Chief Executive Define Their Own Data Needs, Harvard Business Review, Mar-Apr
1979, p.81
(4) BOYNTON, A.C. e ZMUD, R.W. An Assessment of Critical Sucess Factors, Sloan Management
Review, Summer 1984, p.17
(5) KEEN, P.G.W. Competing in Time: Using Telecommunications for Competitive Advantage, Ballinger
Publishing, Cambridge-MA, 1986
(6) IBM. Business System Planning: Information System Planning Guide, Manual Number GE20-527-4,
1984
(7) FLATEEN, P.O. e outros. Foundations of Business Systems, The Dryden Press, Chicago, 1989
(8) DRUCKER, P. The New Organization of the 1990s, Harvard Business Review, Jan-Feb 1988, p. 45
 13
(9) HAMMER, M. Reengineering Work: Don't Automate, Obliterate, Harvard Business Review, Jul-Aug.
1990, p.104
(10) CORDENONSI, J.L. Planejamento Estratégico de Sistemas de Informação Utilizando Reengenharia
de Processos, Dissertação, Mestrado em Informática, Puccamp, 20 de novembro de 1995
(11) LEITE, J.C. Terceirização em Informática, Makron Books do Brasil Ed., S. Paulo, 1994
(12) PASTORE, R. PanAm To Go Outsourcing Route, Computerworld, Apr.8, 1991, p.1
(13) MELLO, C.G. Quarteirização: Um Novo Modismo Gerencial ?, RAE Light, v.2, n.1, Jan/Fev 1995,
p.12
(14) DIVERSOS. O Que Eles Pensam Sobre Parceria, RAE Light, v.2, n.1, Jan/Fev 1995, p.31
(15) McNURLIN, B.C. e SPRAGUE, R.H. (Ed.) Information Systems Management in Practice, Prentice-
Hall, Englewood Cliffs-N.J., 1989
(16) GIBSON, C.F. e NOLAN, R. Manging the Stages of EDP Growth, Harvard Business Review, Jan-
Feb 1974, p. 80
(17) NOLAN, R. Managing the Crisis in Data Processing, Harvard Business Review, Mar-Apr 1979, p.115
(18) DRURY, D.H. An Empirical Assessment of the Stages of Data Processing Growth, MIS Quarterly,
vol.7, June 1983, p.59
(19) KING, J.L. e KENNETH, L.K. Evolution of Organizational Information Systems: An Assessement of
Nolans's Stage Model, Communications of ACM, May 1984, vol.27, n.5, p.446
(20) KEEN, P.G.W. An International Perspective on Managing Information Technology, Briefing Paper,
The International Center for Information Technology, 1987
(21) BUSS, M.D.J. Managing International Information Systems, Harvard Business Review, Sept.-Oct.
1982, , p.153
(22) MARKOFF, J. Europe's Plan on Privacy Upset Business, New York Times, Apr. 11, 1991, p. A1
(23) HOPPER, M.D. Rattling SABRE: New Ways to Compete on Information, Harvard Business Review,
May/June 1990, p.118
(24) KING, J.L. e SCHREMS, E.L. Cost-Benefits Analysis in Information Systems Development and
Operation, Computing Surveys, v.10, n.1, March 1978
(25) ALTER, S. Implementation Risk Analysis, TIMS Studies in the Management Sciences, v.13, 1979
(26) McFARLAN, F.W. Portfolio Approach to Information Systems, Harvard Business Review, Sept-Oct
1981, p.142
(27) MARTINO, C.A. Information System Planning to Meet Business Objectives, sumarizado por
SPRAGUE, R.H. e McNURLEN, B.C. (eds.) em Information Systems Management in Practice, Prentice-
Hall, N. York, 1986, pp.73
(28) GOFF, L. e PUTTRE, M. Business Strategies Misaligned with MIS Resources, MIS Week, Nov.
1989, pp.38-43

Autoria : * Maurício Prates