Lesões por Esforços Repetitivos Uma freqüente forma de adoecimento.
PLANEJAMENTO DA FUNCÃO DE UM ESTUDO DE CASO … · mencionada como a de uso mais freqüente: a...
292
PLANEJAMENTO DA FUNCÃO DE SISTEMAS DE INFORMACÃO UM ESTUDO DE CASO SERGIO DE MAGALHIES BORDEAUX RêGO TESE SUBMETIDA AO CORPO DOCENTE DO INSTITUTO DE PõS-GRADUACIO E PESQUISA EM ADMINISTRACiO DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO, COMO PARTE DOS REQUISITOS À OBTENCÃO DO GRAU DE MESTRE EM CiêNCIAS (M. Se.). APROVADA POR /' PROF. PREe:tOENTE PROF. CESAR GONCALVES NETO 7 PROF. MOACIR SANCOVSCHI PROF. ANT NIO ROBERTO NOGUEIRA RIO DE JANEIRO, RJ - BRASIL FEVEREIRO DE 1992
Transcript of PLANEJAMENTO DA FUNCÃO DE UM ESTUDO DE CASO … · mencionada como a de uso mais freqüente: a...
PLANEJAMENTO DA FUNCÃO DE
SISTEMAS DE INFORMACÃO
UM ESTUDO DE CASO
SERGIO DE MAGALHIES BORDEAUX RêGO
TESE SUBMETIDA AO CORPO DOCENTE DO INSTITUTO DE PõS-GRADUACIO
E PESQUISA EM ADMINISTRACiO DA UNIVERSIDADE FEDERAL DO RIO DE
JANEIRO, COMO PARTE DOS REQUISITOS NECESS~RIOS À OBTENCÃO DO
GRAU DE MESTRE EM CiêNCIAS (M. Se.).
APROVADA POR
/'
PROF. PREe:tOENTE
PROF. CESAR GONCALVES NETO
7 PROF. MOACIR SANCOVSCHI
PROF. ANT NIO ROBERTO NOGUEIRA
RIO DE JANEIRO, RJ - BRASIL FEVEREIRO DE 1992
P1Mne.J_mento
Zn"'Ol""'mau:tiCo
4..-92 ..
da FuncSo d_ ml.tema$ o.
Um E.~udo d. e .. _o. COPPEAD/UFA~~
Unl ......... ldad. F_d ....... l dc~
~ 51_tem_m de Xn"'Q"'m_c~O x. COPPEAD/UFR~ XX T(tu~o <s4 ... 1.>.
L
A MEUS PAIS (IN MEMORIAM), À MINHA
ESPOSA VIRGINIA E AOS MEUS FILHOS
ROMULO E ANNA PAULA.
I I I
AGRADECIMENTOS
o trabalho de pesquisa para defesa de tese
representa uma árdua tarefa, principalmente para aqueles que,
em decorrência das exigências do horário de trabalho,
precisam Impor I Imitações ao tempo dlsponlvel para o lazer e
dedicação à famll la, que acaba por sofrer aqueles sacrifícios
que deveriam ser apenas do autor.
Por esta razão, minhas primeiras palavras de
agradecimento são dirigidas à minha esposa e meus fi lhOS,
pelo estImulo que me proporcionaram durante todo o tempo em
que me dediquei a este empreendimento, aceitando com
benevol8ncla os sacrifícios a que foram submetidos.
Aos professores e
especial atenção com que fui
pelo Interesse e empenho
funcionários da COPPEAD, pela
permanentemente distinguido e
que demonstraram, para me
proporcionar o apoio técnico e o tempo necessários e
Indispensáveis à consecução dos nossos objetivos acadêmicos;
a eles manifesto o meu sincero reconhecimento.
Aos professores Donaldo de Souza Dias e Roberto
Nogueira, que dedicaram multas horas de trabalho para ler,
analisar, criticar, comentar, corrigir, enfim, orientar os
rumos da pesquisa que nos propusemos empreender, e dos quais
pude assimilar Inúmeros ensinamentos.
Aos professores Gesar Gonçalves Neto e Moacir
Sancovschl, que me honraram com suas presenças na banca
examinadora, e dos quais 05 alunos da GOPPEAD sempre colheram
ensl namentos va II osos, como tantos outros pOderão
testemunhar.
A prOfessora Heloisa M. G. B. Leite, que com seu
entusiasmo sempre me Incentivou à realização deste trabalhO.
A EMBRATEL, por ter-me concedido o afastamento que
p r o p I c i o u a r e a I I z a ç ã o d o me 5 t r a do.
Aos colegas de trabalho, que contribuíram com
críticas, revisões e multo Incentivo.
Finalmente, não poderia deixar de agradecer a
colaboração dOS companheiros Marcos Antonio Marinho GObbl,
Haroldo Ribeiro de Oliveira e Silva, Tania Rezende, Eda
Felske e Zulelka Hermont Gosta, que tornaram possível a
edição deste trabalho.
v
RESUMO DA TESE APRESENTADA
REQUISITOS NECESSARIOS À
CI~NCIAS (M. Sc.).
À COPPEAD/UFRJ COMO
OBTENCÃO DO GRAU DE
PARTE
MESTRE
PLANEJAMENTO DA FUNCAO DE
SISTEMAS DE INFORMACAO
UM ESTUDO DE CASO
SERGIO DE MAGALHÃES BOROEAUX RêGO
FEVEREIRO/1992
ORIENTADORES: PROF. DONALDO DE SOUZA DIAS
E
PROF. ROBERTO NOGUEIRA
DOS
EM
Este estudo constitui uma monografia cujo objetivo
é estabelecer um mOdelo de referência para avaliação de
metodologlas de Planejamento da Função de Sistemas de
Informação; segue-se a apreciação de uma metodologia de
Planejamento de Função de Sistema em confronto com o modelo
de referência proposto.
Esse modelo foi construrdo com base em conceitos
estabelecidos pelos diversos pesquisadores citados na revisão
de literatura. A seguir, descreveu-se o caso de Planejamento
da Função de Sistemas de Informação ocorrido em
de telecomunicações brasileira, para que os
encontrados fossem comparados com o referencial
I I teratura.
uma empresa
resultados
deduzido da
05 I nstrumentos de col eta de dados uti II zados foram
05 relat6rlos que descreveram a experiência vlvenclada pela
empresa em questão.
o confronto entre o referencial deduzido da
literatura e os resultados encontrados proporcionou Indícios
de que os elementos representados no referencial deduzido são
necessários à consecução de um Planejamento da Função de
Sistemas de Informação.
Com o objetivo de esclarecer a uti I Ização do
referencial proposto selecionamos dentre um conjunto de
metodologlas, Identificadas na literatura, aquela que é
mencionada como a de uso mais freqüente: a metodologia
Buslness Systems Plannlng <BSP) proposta pela IBM em 1975 e
que já foi objeto de estudo tanto no país como no exterior,
e, submetemos a uma avaliação em confronto com o referencial
deduzido da literatura.
v I I
Os estudos conduziram à conclusão de que os
resultados encontrados podem se constituir numa contribuição
para a conceituação ampla e precisa do Planejamento da Função
de Sistemas de Informação, além de proporcionar uma
perspectiva das metodologlas, técnicas e ferramentas
aplicáveis ao exercício deste Planejamento.
-.VTII ~.
ABSTRACT OF THE THESIS PRESENTEO TO COPPEAO/UFRJ AS PART OF
THE REQUIREMENTS FOR THE OBTENTION OF THE MASTER OEGREE IN
SCIENCE (M.Se.>.
PLANNING OF THE INFORMATION
SYSTEMS FUNC~ION
A CASE STUDY
SERGIO DE MAGALHlES BOROEAUX RêGO
FEBRUARY/1992
CHAIRMEN: PROF. OONALOO DE SOUZA DIAS
ANO
PROF. ROBERTO NOGUEIRA
Thls study eonslsts of a monograph, the purpose of
whlch Is to establlsh a model of referenee for the evaluatlon
of methodologles for Plannlng of the Informatlon Systems
Funetlon. Conslderatlons on one speelflc methodOlogy for
Plannlng of the Informatlon Systems Functlon, In comparlson
wlth the proposed referenee model, 15 Ineluded In the study.
Ix
lhe mode lhas been bu II t up based on the concepts
establshed by several researchers mentloned In the Ilterature
revlew. A case on the Plannlng of the Informatlon SY6tem6
Functlon whlch occured In a Brazl I lan lelecomunlcatlons
Company 16 descrlbed and compared to the reference model
Inferred from the Ilterature.
Data collectlon waa based on reports of the
Brazl I lan company descrlblng It's experlence In the plannlng
processo
lhe comparlaon between the reference model Inferred
from the I Iterature and the results obtalned In the cese
atudy has Indlcated that the elements represented In the
model of reference are necessary for the accompllshment of
the Plannlng of the Informatlon Systems Functlon.
For elucldatlng the use of the suggested reference
model, we have selected among a eet of methodologles
Identlfled In the Ilterature, one whlch 15 mentloned as belng
the most commonly used: the Buslness Systems Plannlng <BSP)
methodology, proposed by IBM In 1975 and already studled not
on I y In th la country, but a 150 abroad. In the present study
thls methodology Is compared to tne reference model Inferred
from the II terature.
Our study has led to the concluslon that the
achleved results may contrlbute to
comprehenslve model for the Plannlng
an
of
accurate and
the Informatlon
Systems Functlon ~s wel I supply an overvlew of methodologles,
technlques and tools used In the Plannlng of the Informatlon
Systems Functlon.
x I
FIGURAS
Figura Título Pág.
2.1 Estrutura de Sistema de Planejamento e
Controle ....•......................•........... lO
2.2 Planejamento Estratégico de Sistemas
de Informação ................................. 2.3 PI anej amento de Sistemas de Informação .....••.. 15
2.q Planejamento da Função de Si .......•..•........ 16
2.5 Modelo para Comparar Métodos de
E n g e n h a r I a d a I n f o r ma ç ã o ..•.•.................. 23
2.6 Articulação dos Processos de Planejamento
da Função de SI 27
2.7 Processo de Ava I I ação e Se I eção de Sistemas ... 29
2.8 Escala de Avaliação de Aplicações .............. 35
2.9 Possibilidade de Centralização e
2.10
2.11
Descentra II zação ............................... 36
Manipulação de Dados x linguagens de
Programação
Grau de Estruturação ............•.............
ql
q.l Estrutura de Articulação das Decisões, Dados,
Processos e Funções .........••................ 85
Q.2 Modelo de Arquitetura de Rede ...•.........•... 105
5.1 Modelo de Anthony e o Planejamento da
F u n ç ã o de Si................................... 1 23
5.2 Modelo de Klng (Adaptado) e o Planejamento
da Função de Si ................................. 125
5.3 Estrutura Simplificada do Referencial para
Planejamento da Função de SI ................•.. 126
5.4 Relação Reflexiva do Referencial para
Planejamento da Função de SI ................... 127
5.5 Estrutura do Referencial para Planejamento
da Função de 5 I ................................ 128
5.6 Referencial para Planejamento da Função
de 5 I (LI teratura) ..........•.................. 130
x I I I
QUADROS
Quadro Título Pág.
2.1 Estrutura das Decisões de Planejamento
Corporatl vo .................................... 18
2.2 Estrutura dos Mecanismos de Decisão ............ 19
2.3 Estrutura das Decisões de Planejamento
da Função de Si................................ 21
2.4 Modelo para Comparar Métodos de
Engenharia da Informação - Legenda - 24
2.5 Anál I~e de Problemas •...........•.....•........ 32
2.6 Sistemas de Informação x Estrutura da
Organ I zação .•.....•........................... 38
2.7 Perfil dos Modelos de Gerência de Projetos 46
4.1 Escala para Avaliação de Metodologlas de
Planejamento de Sistemas de Informação 83
5.1 Referencial para Planejamento da Função
de SI (Literatura) ............................. 131
5.2 Referenc I ai Genera II zado para PI anej amento
da Função de Si ........••...................... 134
5.3 Telecomunicações S.A Planejamento da
Função de Si ...................•.............. 137
5.4 BSP: Planejamento da Função de Si ....•..•..•... 142
VOLUME ::u:
CAPITULO 1
1 . 1
1.2
CAPITULO 2
SUMÁRIO
TEXTO
Pág.
I NTRODUI; lO. . . . . . . . . . . . . • . . . . . . . . . . . . .. 001
Importância e Justificativa '" ........ 003
Objetivo .............. ~ ............... 005
REVISiO OE LITERATURA .................. 007
2.1 O Conceito de Sistema de Planejamento
2.1.1
2.1. 2
2.1.3
2.1."1
2.1. 5
2. 1 .6
da Função de Sistemas de Informação ... 009
O conceito de Sistema de Planejamento 009
O conceito de Informação 013
O conceito de Sistema de
Informação ............................ 013
O conceito de Sistema de Planejamento
da Função de Sistemas de Informação .. 014
componentes das Estruturas do Sistema
de Planejamento Corporativo .......... 017
Componentes das Estruturas do
Planejamento da Função de SI 020
2.2 O Processo de Planejamento da Função
2.2.1
2.2.2
2.2.3
de Si ................................. 026
seleção e Prlorlzação de Sistemas .... 028
Centra Ilzação x Descentra Ilzação ..... 035
Se I eção de Software .................. 039
xv
2.2.4 Avaliação de Risco ................... 042
2.2.4.1 A Manifestação do Risco •............ 042
2.2.4.2 As Dimensões do Risco ............... 043
2.2.5 A Gerência do Projeto de
Sistemas de Informação ............... 045
CAPITULO 3 PERGUNTA OE PESQUISA E METODOLOGIA 048
3.1 Objetivos do Estudo e Pergunta de
Pesqu Isa ....................•......... 050
3.2 O Método de Pesquisa Utilizado ........ 053
3.3 Seleção da Empresa e da Metodologia
3.4
CAPITULO 4
4.1
4.2
4.3
4.4
4.4.1
4.4.2
4.4.2.1
4.4.2.2
4.5
a ser Confrontada com o Referenc I a I 057
Coleta de Oados ........•.............• 057
DESCR I CIO DO CASO ..................... 059
Antecedentes .............•........•... 061
Definindo o Problema .................. 068
Identificação e Selecão de Metodologia
de Planejamento da Função de Si ....... 080
Definição de Diretrizes .....••........ 096
A I I I RECOR .......................... 096
Decisões Complementares ........•..... 113
Unificação das Propostas para
Arquitetura de Aplicações ........... 114
Outras Dec I sões ..................... 116
Alternativas de Projeto 117
CAPITULO 5
5. 1
5.1 . 1
5.1.2
5.2
5.3
5.4
CAP nULO 8
RESULTADOS ....•.....•.•.•......•...... 119
Modelo de Referência para Planejamento
da Função de Si ....................... 121
Modelo de Referência Derivado
da Revisão de literatura •....•....... 121
Modelo de Referência Generalizado .... 133
Va II dação do Referenc I a I 138
Avaliação da Metodologia BSP em
Confronto com o Referencial Proposto 141
Outros Resultados ..................... 147
CONCLUSõES .....•..•................... 150
BIBLIOGRAFIA ..................................•........ 158
AP@NDICES . . . . . . . . • . . . . . . . . . . . . . . • . . . . . . . . . . . . . . . • • .. 1 83
AP@NDICE I Sistema de Planejamento de Neg6clos -
Sumário Executivo (BSP) .......... 165
AP~NDICE II Cicio de Vida dos Sistemas de
Informação ...•...•.....•........•..... 195
AP@NDICE 111 Classes de Dados/Processos ............ 212
AP@NDICE IV Outras Dec I sões ....•....•............. 214
AP@NDICE V pr I nc I pa I s Resu I tados do Pro J eto ...... 247
xv I I
CAP:i'.TULO :1.
INTRODUCÃO
no desenvolvimento das aplicações da Informática é um fator
de transformação da organização econômica e social e do modo
de vida: convém que a nossa sociedade esteja em condição, ao
mesmo tempo, de o promover e de o controlar para COlocá-lo a
serviço da democracia e do desenvolvimento humano. n
(Valéry Glscard O' Estalgn) [Nora et ai, 1980]
2
1.1 Importância e Justificativa
A crescente dlversld~de de recursos tecnológicos
disponíveis para dar suporte à aquisição, registro (Inclusão,
alteração, exclusão), transporte, armazenagem, processamento,
recuperação e exibição de Informações, tem produzidO efeitos
na produtividade e na competltlvldade das empresas, alterando
significativamente suas condições de desenvolvimento e
sobrevivência.
Automação Industrial, automação de escrlt6rlos,
sistemas de apolo à decisão, automação de transações,
sistemas convencionais, sistemas Inteligentes, processamento
centralizado, processamento descentralizado, software
operac lona I, II nguagens de programação, gerenc I adores de
arquivos, gerenciadores de bancos de dados, circuitos
dedicados e/ou comutados de comunicações de dados, redes
locais, micros, minis, malnframes, etc. Uma Infinidade de
posSlbl1 Idades e recursos a serem selecionados e combinados
para atender, de forma mais eficaz e eficiente, aos objetivos
da empresa.
A opção pela Informática além de conduzir ao
aumento de capacitação, conduz também a Investimentos e
despesas operacionais significativas.
Identificar oportunidades de utlll zação dessa
tecnologia que proporcionem vantagens competitivas, ou que
3
possam se constituir ameaças aos objetivos da empresa,
selecionar as oportunidades de uso que proporcionem o
fortalecimento da presença da empresa no mercado, mobilizar
os recursos que possibilitem a Implementação das utilizações
pretendidas, ou seja, estabelecer os objetivos e as
diretrizes para o uso adequado da Informática se torna
Imperativo para o êxito da empresa moderna.
Inúmeras Iniciativas procuram estabelecer condutas
que auxiliem a formulação do Plano de Utilização de
Tecnol09ia de Informação pelae empresas, [IBM, 1975 ... 198Q),
[Carlson. 1979),
[Holland, 19861.
[Pereira et ai, 1979) , [Martln, 1982) ,
A Importância do Planejamento da Função de Sistema
fo I "destacada pe I a pr Ime I ra vez quando estudos real I zados
nos E.U.A. [McFarlan, 1973) mostraram que empresas que
planejam as atividades de processamento de Informação e
aferem os resultados pelo plano através de controles e
auditoria são mais bem sucedidas que as que nem planificam o
processamento de Informações nem aferem os resultados" [Wysk,
1982) .
Apesar da Importância do Planejamento da Função de
Sistema, "multas dificuldades têm sido enfrentadas para
Implementar as metodol091as de Planejamento da Função de
Sistema propostas por diferentes autores" [Lederer et ai,
1988).
Estas ~Iflcul~a~es têm motlva~o que, ~esde 1982, na
literatura sobre sistemas de Informação ~emonstrou maior
preocupação com a aval lação ~e meto~ologlas de Planejamento
~a função de Sistema" [Wysk, 1982J.
Um resultado
determinação do alcance
metodologlas pesqulsa~as.
Importante dessas
e das limitações
aval I ações é a
das diferentes
1.2 Objetivo
Nossa pesquisa tem como objetivos:
estabelecer um referencial completo para Planejamento da
função de Sistemas de Informação,
verificar a consistência deste referencial com base na
descrição de um caso,
demonstrar a utilidade do referencial através de um
exercício de avaliação da
Plannlng - <BSP)n [IBM,
metodologia "Buslness
198~J (ver Apêndice I).
Systems
Para alcançar
pesqu I sa b I b \I ográf I ca
Informações necessárias
esses objetivos
orientada para
à construção
realizamos
proporcionar
da estrutura
uma
as
do
referencial. Em seguida definimos a pergunta ~e pesquisa e
descrevemos o méto~o adotado na condução da pesqUisa.
5
Continuando, apresentamos a descrição de um caso
que põe em evidência o processo de planejamento da função de
sistema adotado por uma empresa brasileira de
telecomunicações. Finalmente explicitamos a proposta do nosso
referencial, evidenciamos a correspondfincla entre a estrutura
do referencial e a estrutura de procedimentos e
cons I de rada pe I a emp resa foca I I zada no estudo
rea I I zamos a ava I i ação da (BSP) e apresentamos os
e conclusões da pesquisa.
6
resultados
de caso,
resultados
CAP-xTULO 2:
REVIS~O DE LITERATURA
7
nCada pensador nos apresenta a sua própria I d ~ I a ( . . . )
gostariam de mostrar-nos os fatos e nada mais. Mas a sua
Interpretação da evidência empírica cont~m desde o Início uma
afirmação arbitrária - e essa arbitrariedade torna-se cada
vez mais patente à medida que a teoria aumenta e assume um
aspecto mais perfeito e eXlgente n .
(Ernst Casslrer)
8
Esta rev I são de II teratura fo I rea II zada com o
objetivo de Identificar e selecionar conceitos e proposições
que nos permitissem descrever a estrutura completa de Sistema
de Planejamento da Função de Sistemas de Informação. Para
alcançar este Objetivo, é necessário colocar em evidência os
conceitos de Sistema de Planejamento, Informação e Sistema de
Informação. Em Seguida, relacionamos estes conceitos e
enunciamos o modo pelo qual o conceito de Sistema de
Planejamento da Função de Sistemas de Informação será
considerado neste texto. Finalmente, após termos Identificado
as estruturas que constituem a estrutura global de Sistema de
Planejamento da Função de Sistemas de Informação, orientamos
nossos esforços no sentido de Identificar, por analogia com o
que é feito para os Sistemas Corporativos, todos os
elementos, ou pelo menos os mais significativos, que estão
contidos nestas estruturas.
2.1 O conceito de Sistema de Planejamento da Função de
Sletemas de Informação
2.1.1 O conceito de Sistema de Planejamento
Os conceitos de Planejamento e Controle são
indissociáveis, conforme assinalado no trabalho que
estabe I eceu o mode I o para aná I I se dos Sistemas de
Planejamento e Controle [Anthony, 1965J. Deste modo, ao
mencionarmos ftSlstema de Planejamento da Função de Sistemas
de Informação ft , estamos nos referindo ao conjunto de
9
Informações que suporta todas as decisões de planejamento e
controle em uma empresa.
o modelo básico que apropriamos como referência
para Sistemas de Planejamento foi o concebido por Anthony em
1965, ajustado por Eln-Dor e Segev [Eln-Dor et ai, 1978l pela
superposição de uma dimensão associada a técnicas de tomada
de decisão (programáveis e não programáveis) sugerida por
Slmon [Slmon, 1977]. A figura a 2.1 resume a estrutura deste
modelo. Os conceitos enunciados a seguir colaboram para o
entendimento da figura 2.1:
DECISÕIlES NÃO
PRO(;Ritl1itDIIIS
DECISflõES
PRO(;RIII"ADAS
ES TRUTlJRA DE S I S TEnA DE PLitNEJlIIl1ENTO E CONTROLE
PLIIINE.JIIII1ENTO ESTRIIITÊ(; ICO
,J.,. CONTROLE (;ERENClitL
" "
,.. h
-----------.Jt-- ------------'J CONTROLE DE " OPERIIICflõES : "-
'1/ , , OPERACiliES t. ....
;1 r,
PROCESSOS EHTERNÁI1ENTE
ORIENTADOS
CONTAR I LI DADE " FINANCEIRA "
rio;:!. 2.1
10
11 111 N I P U L 111 C
" o D 111
I N F O R 11 A C .. O
Planejamento Estratégico - é o processo de decisão sobre os
objetivos da organização, sobre as mudanças a serem
feitas nesses objetivos e sobre as pol rticas que devem
reger a aquisição, o uso e a disposição de recursos.
Controle Gerenciai - é o processo pelo qual 05 gerentes se
asseguram de que os recursos são obtidos e usados
eficaz e eficientemente na consecução dos objetivos da
organização.
Controle de Operações - é o processo para assegurar que as
tarefas específicas são executadas eficaz e
eficientemente.
Operações - é o processo que assegura a execução correta das
tarefas específicas.
Contabl I Idade Financeira - é o processo de tornar pública a
Informação financeira a respeito da organização.
Manipulação da Informação é o processo de coletar,
manipular e transmitir Informação, qualquer que venha a
ser o seu uso.
É Importante Observar que, para Anthony, a palavra
sistema tem muitos significados,
·Uma unidade complexa formada na maioria das vezes
por diversas partes sujeitas a um plano comum ou servindo a
um prop6slto comum. Há duas Idéias essenciais nessa
definição, (1) as partes Individuais de um sistema são
freqüentemente diversas, e (2) a COleção de partes forma uma
1 1
unidade - ou uma totalidade
sujeitas a um plano comum ou
propósito comum. Uma definição
ou porque as partes são
porque elas servem a um
de um sistema biológico
também é relevante: Uma reunião de partes ou órgãos de
tecidos Iguais ou similares, ou relacionados com a mesma
função, Isto é, o sistema nervoso, o sistema digestivo. Um
sistema de planejamento e controle, então, consiste de
diversas partes que servem a um propósito comum n [Anthony,
1965] .
Também, para Anthony, é Importante distinguir
sistema e processo:
nEm resumo, um sistema facilita um processo; ele é
o melo no qual o processo ocorre. O sistema descreve o que a
estrutura é, enquanto o processo descreve o modo como a
estrutur~ funciona. Nós estamos Interessados em ambos,
estrutura e processo, desde que a estrutura possa ser melhor
entendida em termos de como ela funclona n [Anthony, 1965].
Finalmente Anthony nos alerta para o fato de que o
projeto de sistemas deve ser dlstlngüldo do processo de
decisões com respeito à estrutura da organização e divisão de
responsablll dades.
12
2.1.2 O conceito de Informação
Para Eln Dor: ndados são representações originais e
detalhadas (do estado) de entidades no mundo físico e
Informações são representações do resultado apurado pelo
processo de Identificar as relações existentes entre dados
correspondentes a entidades diferentes ou estados diferentes
da mesma entl dade n . [EI n-Dor et a I, 1978),
Apesar da questão de entender o modo pelo qual as
representações mentais nreproduzemn o
Psiquismo do Indivíduo pensante ser multo
que o sugerido pela definição acima,
mundo exterior no
mais complexa do
conforme podemos
depreender da leitura da IntrOdução à Lógica Dialética [Prado
Junior, 1979), consideraremos a simplificação enunciada acima
suficiente para nossos propÓSitos Imediatos.
2.1.3 O conceito de Sistema de Informação
nSlstema de Informação à administração é um sistema
para a coleta, armazenamento, recuperação e processamento de
Informações que é usado, ou desejado, por um ou mais
administradores no desempenho de seus deveres n [Eln-Dor et
a I, 1978).
Slmon [Slmon, 1977) considera que nadmlnlstração é
um sinônimo virtual de tomada de decisões. O trabalho do
administrador consiste em reconhecer as circunstâncias que
13
requerem decisões, Identificando a ação apropriada e,
finalmente, escolhendo a ação mais eficaz· [Slmon, 1977).
Para Anthony "sistemas de planejamento e controle
são usados para facl I Itar a tomada de decisão" [Anthony,
19651. Somos ai ertados, entretanto, para o fato de que as
decisões são tomadas por pessoas e não por sistemas"
[Anthony, 1965).
2.1.4 O conceito de Sistema de Planejamento da Função de
Sistemas de Informação
Para conceituar Sistema de Planejamento da Função
de Sistemas de Informação, daqui por diante desl9nado por
Planejamento da Função de SI, Iremos relacionar os conceitos
de Sistema de Planejamento, Informação e Sistema de
Informação.
Para Klng [Klng, 1978), o modo pelo qual devemos
estabelecer esta relação está representado na figura 2.2.
E!;.tratE'gi .. Cu F<l"at i ~ ...
• t1i~
. ct,jet i vre. I?
t1E'tCIE-
_ E!;.trat6gi a
Feml?: K ire, 19'1B
PrOCI?5.eD IE- PI in' ja'emo EE.tratf9i ro
IE- 5i E-tE'r<6 IE- I nf[na;~,
, ) ,
EE.tratf9l .. It:e. 5i E-tel'lae· IE- Infrna;~
_ ct.jet I '-I:lS IÊI KI?a IE- Si s.too=
IE- I nforra;;~
. PoI it i [CIE- IÊI KI?a IE- Si E-tE!f'1C6
IE- I nforra;;~
_ ~'JJi tetlTa IÊI I nforra;;~
Um outro modo de estabelecer esta relação é o
sugerido por Lederer CLederer et ai, 19881, que representamos
a seguir,
o E o E [" F O R " ~ C A O
PROCESSO PROOUTI] I FQnto.: Lede N!~, I ~33.
flq-. 2.3
Estes relacionamentos sugeridos por Klng e Lederer,
determinam o reconhecimento de três componentes no sistema de
relações: dois domínios e um operador que relaciona os dois
domínios. A principal diferença entre estas duas
representações de sistemas de relações reside no fato de que
para o domínio Insumo, proposto por Lederer, os elementos que
o constituem são recursos (mão de obra, dinheiro, tempo
etc.), enquanto que para o modelo proposto por Klng o domínio
correspondente a Insumo determina que o recurso a ser
considerado seja exclusivamente Informação, ou seja, o
conjunto de dados (e/ou variáveis) ao qual os gerentes
recorrem durante o processo de decisão.
Observemos que processo de planejamento, no sentido
em que foi proposto por Klng CKlng, 1978J, descreve o modo
pelo qual o administrador decide, ou seja, escolhe uma entre
as diversas alternativas Identificadas
Considerando que além das Informações relativas aos
15
Neg6clos da Empresa (Missão, ObJetivos, Estratégias) o
processo de Planejamento da Função de Sistema precisa
considerar Informações relacionadas com o estado da arte da
tecnologia da Informação, e com o ambiente de modo geral; e
que o processo de planejamento além de oferecer resultados a
nível estratégico, também os produz nos níveiS de controle
gerenciai, controle de operações e operações [Anthonv, 1965)
[Eln-Oor et ai, 1978), e considerando, ainda, a necessidade
de relacionar as Informações do ambiente e dos neg6clos da
empresa com as I nformações que exp II c I tam o produto de
planejamento, podemos generalizar a representação
estabelecida por Klng [Klng, 1978] conforme a figura 2.4.
[n t'~ rm.o::Q.S do
.utlient.! • dos
n.~Q~iQs d.a.
E",~s.a.
"ODO [IE OPERAR A OEC [SAO ~------------------~ \
1----___ ----,,,/ DE PlAftEJA"EftTO "
Font.!s: Kin'1, 1~7a .. l.d.~r. 1983, fi '1 2,4
[n f'. rm.o::Q .. :i :iQb ~
d.~i:iQ.s d. P l.a.neJ,Uf.mt.J d ..
Si st..ems de [n fo rm.o::.a.o
Tomando como referência o modelo de relacionamento
representado acima e os conceitos de Sistema de Planejamento
e Controle, Informação e Sistema de Informação descritos
anteriormente, enunciamos a conceituação de Planejamento da
Função de Sistema que resulta da associação entre êstes
conceitos:
Podemos conceituar o Sistema de Planejamento da
Função de Sistemas de Informação como sendo aquele que a
16
partir das Informações do ambiente e dos negócios da empresa
(Insumo) os manipula (processo) gerando decisão sobre o
direcionamento da Função de Sistemas de Informação (produto).
A seguir, com a final Idade de tornar mais clara a
compreensão da estrutura global do Planejamento da Função de
SI, e, com base na compreensão estabelecida acima, passaremos
a descrever os elementos que participam de cada estrutura de
Informação (domínios: Insumo e produto) e da estrutura dos
operadores que relacionam estes domínios (modelos e/ou
mecanismos e/ou processos para tomada de decisão).
Considerando que tomamos como referência para a
conceituação da estrutura global do Planejamento da Função de
SI a estrutura global do Planejamento Corporativo,
descreveremos Inicialmente os componentes das estruturas
correspondentes ao Planejamento Corporativo, para, a seguir,
por analogia, descrever os componentes das estruturas do
Planejamento da Função de Sistema.
2.1.5 Componentes das Estruturas do Sistema de Planejamento
Corporativo
Para Anthony [Anthony, 1965),
participam da estrutura das decisões
corporativo se organizam
quadro 2.1.
conforme
17
o
os elementos que
de planejamento
representado no
ES TRU'"TURÃI DÃlS PLÃlHE..JllÃlHEHTO
PLAMEJAIfEMTO COMTROLE
ESTRAT€G ICO GEREMCIAL
DECIS6ES DE CORPORÃTIUO
OPERAC6ES OPERAC6ES
COMTROLE DE I I ~:========1F========1~~
• se lec ionat" objet ivos da COt"POt" a~lio
• ot~gan i z:at~ a corpot"a~lio
• es tabe I eceo" po I it icas pat"a:
· pessoal
· finanças
· n~o"ket ingl
· pesquisa • 'Selecionar noYas I iohas de po"odutos
• adqu it" i t" noyas empt-esa'S
• es tabe I ecet" despesas de capital nlio t·ot ine iras
Dec i s8"es pat" a :
• f Ot"h\U I at" orçamentos
• orglanizar niyeis de assessorantento
• fOt"rilU lat" prãt icas de pessoal
• planeja0" cap i ta I de gI ;0"0
• f Ot"nlU I ao" prOglO" a~s de po"opaglanda
• es tabe I ecet" elenco de projetos de pesquisa
• Ot" ientao" me Ihot" i a de pt"odu to
• orientar reorglanizaçlio da planta
• dec id io" sobt"e despesas de capita I rot ine h"as
• f orroo I ar reglr as de dec i sU-o pa."a conto"o le de operaç8'es nted it" • aYa I i ar e apet-t" e i çoat·
performance glerencial
Dec is8"es pat"a:
• conto"o lar salãrios
• i n", I emen tat" as po I it icas
• contro lat" a elfltenslio de credito
• contt"o I ao" a elflecu~3"o da propaglanda
• pt"Oglt"arttao" a produçlio
• con to"O I ar" e-s.'to"lue'S
• n..ed ir. aya I iat" e aperfe içoat" eficiOncia dos trabalhadores
Fonte: Anthon~, 1865" Quadl'"o 2"1
18
Dec i s8"es pat" a :
• aceita~3"o ou o"e je i ",U-o de pedido de c I iente en, deb i to
· reje i tar documento de pagantento COM eOTO de po"eench i nten to
• t"ecusat" ordem de seo"v iço COh' etTo
· providenciar ."ecupet" aç3"o de fa lha ehl equ i par"",n to
A estrutura simplificada dos mecanismos de tomada
de decisão corporativa pode ser elaborada segundo o modelo
representado no quadro 2.2 [SlmOn, 1977].
ESTRUTURA DOS MECAHISMOS DE DEC S~O
J/ns ~E ~EC I )~ES
I' FtO eiRAII flD A:5
D"ci~~es roti-
A ~r gari'; z a~:to desen"olve pro-ces~o~ espE!'C í-f i c o s para I i-dar co. dec i .. lI .. ~.
tai ..
D,,< i~~es dE!' p~líti<a~ novas, .al estruturadas, dE!' poalpib
I'ara I i dar co. e .. ~a~ d,,< i~6e .. ~:Jo u .. ados proc e-'5 5.<1 50 C o.un 50
para .. olu~:to dE!' d .. pro" le.a ..
Fon te: SiM r., 1977.
TRAD IC 101UII:5
1, Hillito
~, R~tina de escritõri~ Procedi.e~t~~ Operac ionai~ Padr:t~
3, Estrutura Or!!aon izao,,:lo: E j[pE!'Ctat i vas tl. sist".a :5 IIIl.e tas
da
Canais de I~rorna~:to
1lE!'. dE!'rinido~
1, JIII!Ja.e~to, intui~:to
e criati"idadE!'
3, :5"IE!',,:Jo e treina.E!'nto de el<ecuti"os
Quaclro Z.Z
19
1, I'E!'SqUisa5 dE!' ~PE!'ra,,~es Anãli .. e Mat".ãti<a Mod~ I 05 :5i.llla,,:lo por <o.putador
~, I'roces~a.E!'nto Eletr6-nico de dados
Técni< .. ~ heuri~ticas de solu~:to de probleo.a5 ap I i c alias a:
a, treina ... nto de to."d~
rE!'5 dE!' decisaE!'5 ~1I.ano5
b, constru~:to dE!' progra.a~ d .. conput .. dor heurísticos
2.1.6 Componentes das Estruturas do Planejamento da Função de
SI
Conforme mencionado anteriormente, estabeleceremos
a analogia entre as estruturas de decisões de planejamento e
de mecanismos de decisão concebidas por Anthony e Slmon,
respectivamente, para o Sistema de Planejamento Corporativo e
estruturas slmll ares que derl varemos da II teratura para o
Planejamento da Função de SI como será enfatizado no
capitulo 5.
A estrutura de decisões de Planejamento da Função
de SI de acordo com as visões de diversos autores, [Bowman et
ai, 19811, [Kugler et ai, 1984J, [Bakos et ai, 1986J e
[Porter et ai, ... J,
quadro 2.3.
pode ser
20
representada conforme o
ESTRUTURA DE DECISõES DE PLANEJAMENTO DA FUNC~O DE 5 I
PLANEJAMENTO
ESTRATE:GICO
AIJAlIAeM DAS ESTRATE<iIAS E 08JET IUOS EItPRESAIIIII 15 · anD i ente dos negõc ios • tend@ncias futuras • novas tecnologias • novas oportun idades • estrutura organiza
cional • IDEIIT IF ICAÇlIO DAS OPORTU-
H IDADES DE USO DE SISTEIIAS DE IHF~ PARA IHeORPORAÇlIO DE UAHJ ACiEHS COIIPETil lUAS
I DEIIT IF I CACl(O DOS PR lHe I-M I 5 <iIIIlPOS RE lU IIID ICAHTES E SBJS 08JET I UOS
• AJUSTE DA "I S5lIO DA ÃREII DE SISTEM DE IHFORIIACXO • objetivos
• Sl!1~lIo de oportunidadI!s
• ãreas em potenc i a I • restriçl!es
• capacidade atual • estratégias
• ""ai i~30 do ..... ientel • novas oprtunidades • negõc i os correntes • novas tecnologias • ap I ic~1lI!s correntes • i magem da na de
Sistemas de Informa~
• matur idade dos profissionais da ftri!a de Sistemas
• capacidade profis-sional
• AUAlIACM DAS HECESS IDADES DE IHF~ DA EIIPRESA • identific~30 da arquite
tura global dos sistemas de infOT1llaÇ:30
• identific~ das necessidades de inf~ correntes
• necess i dades de inf ornaçI!es pro jetadas
• AJUSTE DE POl iTlCAS. OBJET IUOS E ESTRATE<iIAS DA ftIIEA DE S ISTEIIAS DE IHFORI1IIÇM • estrutura organiZai: lonal • foco tecno lõgico • diretrizes para aloc~30
de recursos • proced imentos gerenc iais • estabelecer objetivos de
capacidade • fixar estratégias
CONTROLE
GERENCIAL
CONTROLE DE
OPERAC6ES
• 0R<iAII1 ZAClro DO PUIHO I1ESTRE • DESEHUOlU II1EHTO DE SISTEIIAS DE DESEHUOlUII1EHTO • Controlar o desenvolyi-• Oefini~ do Projeto di! III!Ilto do projeto lõgico
Sistl!lDilS di! Inf~ • Controlar o desl!nYOlvi-• Estabelecer rel~30 de III!flto do projeto apera-
proced@nc i a entre os ci ona I projetos • Controlar o desl!nvoIYi-
• Progr~ do 0esI!nY01- IIII!flto do projeto ffsico y i IDl!flto p lur i anual • Contro I ar a progr~
Pl.JlNEJAKEllTO DA ALOCAÇlIO DE RECURSO • ldentific~ de tend@n-
cia • Plano de Hardware • Plano di! Software • Planejan!llto de capacida-
de • Plano de Rede • Plano de Telec01lllllicac;1!es • • Plano de Fac i lidades • Plano de Pessoal • Plano de TrI! lnaJIII!IIto • Plano Financeiro
di! ap I i c~1!es • Controlar a DocUlll!!tltaç:So
di! S istl!lllaS • Administrar bases de da
dos • Treinar e dar assis1:@ncia
ao usuãrio • Controlar a ftanut~ de
Sistemas
I""'-AHT ACM • Equ ipiMJlelltos • Software • Aplic~
• PRODIIÇM • Controlar a uti I iz~lIo de
equ i PaIIII!fltos e per i fer icos
• PlIIHEJAllEHTO DE SEGUIIAHCIl
AUDITORIA DE SISTEIIAS E DADOS
• DOCIIIEHTACM E HORI1AS
• PR06RA!1A DE AC8ES E RESPONSABILIDADES
Quadro 2.3
21
• Contra lar Te lecDtlUfl ica-~I!es
• Controlar acesso a bancos di! dados
• Controlar Fitotecas • Contro I ar Exped iG:lIo • Contro I ar 5eqü@nc i a de Exec~ de Sistemas
• Prov idenc iar ajustes nos equipiIIIII!rltos
• Bloquear acessos indevidos
• Recusar sol icit~ incorretas
Os mecanismos para tomada de decisões relativas à
utl I Ização da tecnologia da Informação serão focalizados de
modo a evidenciar duas estruturas de extrema relevância: a
estrutura dos mecanismos que dão suporte ao processo de
elaboração conceptual dos sistemas (ou opções de solução) e a
estrutura dos mecanismos de tomada de decisão pr6prlamente
ditos.
Quanto aos mecanismos de tomada de
seleção de alternativas de construção de
decisão para
sistemas de
Informação, a estrutura é Idêntica à considerada para os
mecanismos de decisão corporativa (ver Item 2.1.5).
Quanto à estrutura dos mecanismos que dão suporte
ao processo de elaboração conceptual dos sistemas, uma
Importante contribuição foi oferecida por CHackathorn et ai,
19BBl no artigo ·Um modelo para comparar métodos de
engenharia da Informação·. Nesse trabalho, os mecanismos que
dão suporte ao processo de elaboração conceptual são
classificados segundo um referencial que considera dois
parâmetros básicos: o primeiro parâmetro é a amplitude do
processo de desenvolvimento da arquitetura de sistemas de
Informação coberta pelo método, o segundO parâmetro é a
profundidade com que o método disciplina ou dirige a criação
e a necessidade de avaliação da arquitetura de sistemas de
Informação.
A figura 2.5, extraída do artigo, expllclta a
classificação:
22
... o .. o
l(rODOloi"
o TlCIUCl Z => ... o '" o.
F[lUIIIEIfTA
MODELO PARA COMPARAR MÉTODOS DE ENGENHARIA DA INFORMAÇÃO
m
( [.UI '\
... ( CSF 1'\
I) ,,. • UT
B1AIT
PLElIPUII
.tu'USE ORlAllllZACIOM&l. TR""FORUçlo UTIlATtS"oIlECU'10ADE
PLANEJAMENTO
r-?-i;:;t ....
U"
.. ~
txC[
'--"
PRO~ETO LÓGICO
SO
uso 0·0
.... IRE.
")
CAIE lOOO
TA1IIIFORIU.ç10 LÓ&lCO-f(SICA
PROJETO
" . 1100S
" O",
.."
IIIIPLEIIIEIlTAÇio
IMPLEMENTAÇÃO
AMPLITUDE
Fonte Hacltoltlorn • 1998.
FI Q. 2.5
, IIU'CA - Ul/VO
MODELO PARA COMPARAR MÉTODOS DE ENGENHARIA DA INFORMAÇJO
TíTULO
ACG BIAIT
BSP CAPO
CASE 2000 CSF O-O
- LEGENDA -
NOME
Automatlc Code Generatlon (Blosser, 1975) Buslness Info. Analy. & Integratlon Tech.
(Carlson, 1979) Buslness systems Plannlng (IBM, 1975) Computer-Alded Proces6 Organlzatlon
(Karlml, 1986-87) Case 2000 (Nastec, 1985) Corpo Criticai Success Factors (Rockart, 1982) Data Deslgner (Database Deslgn Inc., 1981)
DATA DICl Data Olctlonarles OSSO Data Structured System Oevelopment
(Warnler, 1981) E-R Entlty-Relatlonshlp Model (Chen, 1976) EXCEL Excelerator (Index Technology Corp., 1986)
EWIM
ISA
ISDOS
M-W PLEXPLAN PSL PSA
RDM SADT
SAST
SD
SOM
SREM
SST STRADIS
TAXIS
Enterprlse-Wlde Info.Management (Benson and Parker, 1985)
Informatlon Systems Archltecture
( I nmo n, 1986) Info.Sys.Deslgn and Optlmlzation
(Telchroew and Hershey, 1977) Methodware (APpleton, 1985) PLEXPLAN (Mclntyre, 1986) Problem Statement Lang. & Analyzer
(Telchroew and Hershey, 1977) Relatlonal Data Model (Codd. 1970) Structured Analysls & Deslgn
Technlque (Ross, 1985) Strateglc Assumptlon Surfaclng &
Testlng (Mason and Mltrol I, 1987) Structured Deslgn (Yourdon and
Constantlne, 1979) System Development Methdology
(AGS Management Systems, 1985) Software Requlrement Eng.
(Metodology (Alford, 1985) Strategy Set Transformatlon (Klng, 1978) Str Anal, Deslgn. & Implementatlon of IS
(Gane, 198"1) TIIXI<: (Mvlnnnulas et ai HIRn)
Fonte: Hackathorn Quadro 2."1
2"1
VENDEDOR
IBM
Nastec
Data Deslgner
Ken Orr & Assoc.
Index Technology
Amer.Mgt. Systems ISDOS, Inc.
D. Appleton
ISOOS, Inc.
AGS Mgt. Systems TRW
McAuto ISI
o primeiro parâmetro organiza os métodos segundo
uma ordem de precedência lógica, ou seja, as saídas ou
resultados alcançados durante uma fase de aplicação de método
podem ser utl I Izados nessa mesma fase ou em uma fase
sUbseqüente; caracteriza, portanto, as etapas do processo de
desenvolvimento de sistemas de Informação.
descrição
Para o segundo parâmetro
proporCionada pOde ser
a forma da
em parte ou
análl se ou
no todo
conceptual (metodologia), procedural (técnica) ou por
processamento eletr6nlco (ferramenta).
Cada um desses métodos, considerados no sentido da
análise organizacional para a Implementação, aborda em uma
seqüênCia progreSSivamente mais detalhada a representação dos
dados e dos processos de maniPUlação de dados, transformando
o tratamento em nível de linguagem formal ou formatada,
normalmente utl Ilzado na fase de planejamento, em tratamento
em linguagem formatada, necessário à Implementação
conforme o sugeridO no livro "Strateglc Plannlng,
Analysls and Oatabase Deslgn" (Glllenson et ai, 19841.
f í s I c a ,
Systems
As etapas do processo
sistemas de Informação sugeridas por
de desenvolvimento de
Hackathorn (Hackathorn
et ai, 1988J devem ser complementadas para oferecer uma visão
completa do cicio de vida dos Sistemas de Informação. Para
Glllenson (Glllenson et ai, 1984J o ciCiO de vida dos
25
Sistemas de Informação compreende as seguintes etapas:
.análise organizaCional, análise de necessidades, análise de
viabilidade, plano de projeto, projeto lógico, projeto
administrativo, projeto físico, projeto de programação,
tre I namento, Imp I ementação e testes,
operação e, manutenção.
revisões e ajustes,
o apêndice I I estabelece o conceito de cada uma das
etapas do cicio de vida dos sistemas de Informação, na visão
de d I versos autores [G I II enson et ai, 19841, [Torres, 19B91 e
[Fellclano, et ai, 19BBl.
Devemos observar que cada etapa do cicio de vida
cor responde a uma categoria de processos e que para cada
categoria de processos podemos recorrer a diferentes métodos
conforme foi mostrado por Hackathorn [Hackathorn, 19BBl
A compreensão da estrutura de processos, e dos
métodos a êles associados, afeta tão profundamente a
compreensão da estrutura dO referencial para Planejamento da
Função de SI que apresentamos, a seguir, uma visão articulada
destes processos e a complementação da conceituação de alguns
deles.
2.2 O Processo de Planejamento da Função de SI.
Apresentamos na figura 2.6 uma visão articulada dos
processos que contribuem para a formulação do Plano de
26
r--
-
Sistemas (Adaptada de (Torres, 1989J
ARTICULAC~O DOS PROCESSOS DE PLANEJAHENTO DÁ FUNC~ODE SI
CÁPÁCITAC~O EH TECNOLOGIÁS DE INFORHÁC~O
J. ÁNÃLISE ORGÁNIZÁCIONAL E DIRETRIZES PÁRA o USO DE
TECNOLOGIAS DE INFORHACÃO
-1 ÁNÃLISE DE NECESSIDÁDES E
DEFINICÃO DA ARQUITETURÁ GLOBAL DOS SISTEHAS DE
INFORHÁC~O
J. PROJETO LóGICO GLOBÁL ANÃLISE DE UIABILIDADE DEFINICÃO DO CONTEHTO
DETERHINÁCÃO DO PROJETO , DIAGRAHÁ DE FLUHO DE DADOS Á SER DESENUOLUIDO HODno DE DADOS
FIHÁCÃO DE OBJETIUOS ,
E HETAS
-1 " J PROJETO DE HARD-'ÁRE , "
CENTRAL I ZACÃO I .. JER"E·US " OESCENTRALIZAC~O • SEGURÁNCÁ E ÁUDITORIÁ DE
Eau I FAMENTO'!:!· SISTEHÁS E PROCESSAHENTO FjECIE'$. OE o I STR I BU I Giõ5iO · NORHÁS PARÁ DOCUHENTA-DE PF;OCE":·SC1'5. C~O
TEL..ECC.t-1LIN I CAc::a:ES · NORHÁS PÁRÁ DESENUOLVI-1 NF'RAE"STRl.ITI...IRA ri HENTO
J. SELECÃO DE LINGUÁGENS E , /"
SOFTHARE OPERACIONAL ,.- , ',j
E DE ÁPOIO J
ÁVÁLIÁCÃO DE RISCO
J. ' . ALTERNATIUAS PARA PROGRAHA DE TRE I NAHENTO
ÁQUISICÃO DE HÁRD-'ÁRE E - ORGÁNIZÁCÃO DÁS EQUIPES SOFTHARE ESTRUTURÁ FUNCIONÁL
J. ÁNÃLISE ECON6HICO-
FINÁNCEIRA DO PROJETO
.l. ELÁBORÁCÃO DO PLÁNO
Fot,t.e: Tot-re-s :a 1888_ DE SISTEHAS
27
Há quase coincidência entre o conjunto de processos
contidos nessa estrutura articulada e o conjunto de processos
subentendidos na estrutura do cicio de vida dos sistemas de
Informação; os processos contidos nessa Interseção coincidem
nominal e conceitualmente. Entretanto, alguns processos
contidos na estrutura articulada, e não Incluídos no conjunto
Interseção, Influenciam tão fortemente a determinação das
diretrizes para utl I Ização da tecnologia de Informação que é
relevante evidenciá-los. Esses processos são os seguintes:
- Seleção e prlorlzação de sistemas
- Centra I I zação x Oescentra I I zação de Sistemas
- Seleção de Software
- Escolha de Software Gerenciador de Banco de Dados (SGBO>
- Avaliação de Risco
- Métodos de Gerenciar Projetos de Sistemas de Informação
A seguir detalhamos cada uma destas etapas.
2.2.1 Seleção e Prlorlzação de Sistemas
o processo de seleção
recorre ao mesmo conjunto de
e prlorlzação
critérios. A
de sistemas
seleção é o
processo de escolha entre alternativas orientadas para o
mesmo obJetivo. A prlorlzação é o processo de estabelecer a
ordem de precedência para o desenvolvimento dos sistemas de
modo a otimizar a utl I Ização dos recursos dedicados aos
Sistemas de Informação.
28
A figura 2.7 (adaptada de Torres, 1989], sintetiza
o processo de avaliação e seleção (ou priorlzação) de
sistemas.
RELACAO DE S(STEMS
POTE"CrArS
RELACAO DE S[STEMS
SELECIOnADOS (ORDE" DE
PR [OR [DAOE ) Fan.: a~I'olS,
PROCESSO DE A~ALrACAO E SELECAO DE SrSTE"AS
figo 2.7
[ l
D["E"SAO ESTRATE6[CA D["E"SAO ECO"OH[CA D["E"SAO OR6A"rZACrO"Al D[nEnSAO FU"C[OnAL D["E"SAO CAPAC[TACAO D["E"SAO DE"A"DA E~ERI
A dimensão estratégica determina o modo pelo qual o
sistema afeta a competltlvldade e sobrevivência da empresa. A
dimensão econômica determina as economias de custos elou os
ganhos financeiros decorrentes da adoção do sistema. A
dimensão organizacional determina o ganho global da empresa
em aspectos como comunicações, capaCitação, integração etc.
A dimensão funcionai determina os ganhos em comunicação,
capaCitação, Integração etc. sobre uma determinada área da
empresa. A dimensão capaCitação determina o nrvel de
atual ização a ser observado com relação às tecnologias de
29
Informação de modo a estabelecer posslbl I Idade de uso dessas
tecnologias se as condições do mercado assim exigirem. A
dimensão demanda externa determina o desenvolvimento ou
modificações de sistemas para satisfazer o Interesse de
agentes externos tais como governo, matriz etc ..
Cada uma dessas dimensões, é afetada por um
conjunto de fatores, tais como os sugeridos abaixo:
fatores que condicionam a dimensão estratégica:
- aumento na competltlvldade da empresa,
- redução da dependência em relação a terceiros,
- aumento da dependência de cl lentes em relação à empresa,
- melhor qual Idade para produtos e serviços,
- melhoria da Imagem Institucional.
fatores que condicionam a dimensão econômica:
- reduções de custos
- aumento de produtividade e eficiência,
- ganhos de tempo,
- ganhos econômicos, em termos de fluxo de caixa.
fatores que condicionam as
organizacional/funcionai:
- Integração entre sistemas,
- melhor comunicação,
- base para capacitação futura,
- aperfeiçoamento profissional,
30
dimensões,
- melhor performance de pessoal,
- o dado como um bem comum.
fatores que condicionam a dimensão capacitação:
- treinamento em novas tecnologias,
- acesso a hardware e software mais potentes.
fatores que condicionam a dimensão demanda externa:
- mudanças na legislação,
- exigências governamentais,
- exigências da matriz.
Um cr I tér I o para ava II ar cada um dos sistemas
propostos pode ser construído atribuindo a cada uma das
dimensões propostas uma nota variando de
Posteriormente estabelece-se pesos para cada
1 a
uma
10.
das
dimensões, de acordo com a Importância que se atribui a cada
uma delas, e, realiza-se a ponderação de todas as notas de
cada sistema, obtendo-se o total de pontos correspondente.
uma outra conduta para a ordenação de
das aplicações é a oferecida pela BSP (IBM, 1975
prioridade
198"1).
Nesse caso a ordenação das primei ras aplicações deve ser
baseada principalmente em uma análise de valor resultante de
entrevistas realizadas com gerentes das diversas áreas da
empresa. Para facilitar essa análise devem ser utilizados os
achados e conclusões decorrentes das entrevistas e as fOlhas
de análise de problemas conforme modelo a seguir (transcrito
31
de BSP - Informatlon systems Plannlng Gulde).
ANÁLISE DE PROBLEMAS
Ent. Causa Resultado Valor Processo Classe SOlução do do de Dados
NQ Problema Problema Afetado Afetada Sugerida
X Imposslbl- Não podemoe Médio: PlaneJa- - Modelo I idade de Identificar acima mento de Flnan-analisar alternatl- de Investi- c e I r o alternati- vas de ní- $1xl06 mento de vas aele- vel ótimo Capital quadas ao de Investl-planeja- mento de mento dos capital negócios
X Oesconhe- Não podemos Multo - Dados de Sistema cer o medir a A I to : custos de Con-custo de contrlbul- aumen- dos pro- tabll 1-nossos ção para o to de dutos dade de Drodutos lucro por lO" do Custos
produto e lucro, eliminar os acima produtos de $10xl06 baixa con-trlbuicSn
Fonte: IBM, 1984
Quadro 2.5
A classificação das fOlhas de análise pela causa do
problema Indica o processo que deve ser suportado pela
aplicação que auxilia a solução do problema.
32
Se a classificação é realizada pelo Processo
Afetado as ap I I cações podem ser re I ac I onadas a todos os
problemas que ela ajuda a resolver e assim aos benefícios
der I vados. Cada ap I I cação é então ava I I ada por um con J unto de
critérios para determinar o seu valor para o negócio.
As tarefas a serem rea I I zadas para aJ ustar as
prioridades são:
Determinar o critério de seleção
Aplicar o critério e relacionar as aplicações
Documentar ou descrever as aplicações recomendadas
Considerar as opções de Implementação
Para a BSP as dimensões a serem consideradas na
determinação das prioridades são:
Benefícios Potenciais
Impactos sobre o negócio
Probabilidade de Sucesso
Demanda
Cada uma dessas dimensões é afetada pelos seguintes
fatores:
Benefícios Potenciais:
Economias de curto prazo
Retorno sobre o Investimento no longo prazo
Vantagens competitivas
Impactos sobre o negócio:
33
Tendências econômicas do negócio
Fatores críticos de sucesso
Número de problemas registrados
Problemas Importantes resolvidos
Probablll dade de Sucesso:
Clima Pol ítlco
Complexidade Técnica e Organizacional
Pré-requisitos
Dimensão da Implementação
Riscos
Recursos Disponíveis
Demanda:
Valor das aplicações existentes
Re I ação com outras ap I I cações
Harmonia política
Número de usuários
Exigências legais
O critério sugerido para avaliação das aplicações é
a atribuição de graus em uma escala variando de 1 a 10 para
cada uma das dimensões mencionadas acima. Uma representação
gráfica desses graus pode
figura 2.8, para ajudar
Implementação.
ser então
a determinar
desenhada, conforme
a sequ~ncla de
F'F:05RAt1AÇÃO DA F'RODU''';ÃO
Bener i c i o";;.
18t"1, 1884.
Demanda L:· ••• :· ......... : •.•• :,: .......... : .......... : •..• :.~ ....... :·· ... :·4 r·.. " ............. \ ....... ' .. J
ligo 2.8
Periodicamente a avaliação deve ser repetida com o
objetivo de verificar eventuais modificações na seqüência de
ordenação das aplicações decorrentes de mudanças ocorridas no
ambiente da empresa.
2.2.2 Centralização l< Descentralização
A questão da centra I Ização e descentra Ilzação, como
ap I I cada ao processamento de dados, tem estado na vanguarda
de multas discussões.
Para alguns autores, a diferença entre ser
centra I Izado ou descentra Ilzado se resume a uma questão de
controle. Devem ser consideradas, fundamentalmente, duas
dimensões de controle, a física e a lógica, que determinam um
espaço no qua I se man I festam quatro poss I b I II dades, conforme
o representado na figura 2.9 (Glllenson et ai, 19841.
35
40
I
POSSIBILIDADES DE
CENTRAL ZAC.O E DE~CENTRALIZAC.O
F r c • I CO
.=> = = ry
CENTRAL IZiIIDO DESCENTRAL IZiIIDO
Contt"o le Centt"a I Contt"o le Indi ... idual
de Todas as Fac i I idades (Tinle-sha."ing)
a b
Contt"o le Centt"a I Contt"o le Indi ... idual
com hal"dHat"e independente conl hal"dHal"e independente
(P."ocessanlen to Dist .... ibuido) (Pt"ocessarilE'n to PI" i ... a t i "'0 )
c d
L6GICO
Para esses autores a questão de centra I I zar ou
descentral Izar é muito complexa para que tOdos os aspectos
sejam racionalmente considerados. Sugerem que a escolha, em
última análise, pode Independer de qualquer preocupação com
rac lona I Idade; nesse caso, o estilo de cada organização
determinará a tendência com relação às soluções extremas, e,
todas as considerações técnicas podem ser Irrelevantes"
A conclusão de Norberto [Torres, 1989J não difere
mu I to da de G I I I e n s o n [G I I I e n s o n e t a I , 1984J; também para
Norberto a decisão da alta administração não é uma decisão
somente técnica; depende da estrutura da empresa e da
fi losofla administrativa, dos sistemas gerenciais e de
controle, de sua conceituação organizacional etc.
Para Lelfer [Lelfer, 1988J, entretanto, existe uma
correlação estreita entre o tipo de estrutura organizacional
e as categorias de Sistemas de Informação com base em
computadores. O quadro 2.6 a seguir, transcrito de Lelfer,
sintetiza a correlação existente entre estas duas dimensões.
37
\Categoria do Siste-\ ma de Informa,30
\ , \
\ \
Estrutura da \ Organ i za,,30 \
Estrutura Simples (pequena, jovem, central izada, pou-ca formal i zação, controle pelo propr i etãr i o)
Burocracia Mecani-zada(velha,grande, central izada, forma-I izada, func ional, burocrãt i ca, padroni zaç30 do trabalho)
Burocr acr i a Profissional (pouca formal izaç3o, padronizaç~o buro-crãt ica de habi I ida-des descentral iza-da.alta especial iza-,,30 de habilidades)
Forma Divisional i-Zada A (velha,grande,divi-são em mãquina bu-rocrãtica de entra-da para mercados, padron iza,3o de sai das, fracamente acoplada á administraç3o)
Forma Divisionali-zada B (grande,divis30 bu-rocrãtica ou org!-nica orientada para necessidades estrei-tamente acopladas ã administrac30 por forte cultura)
Adhocracia (jovem, descentral izada, pouca formal i za-ç~oJPQquQna,coor-denada por ajuste mü'tuo, orglln i ca, alta especial i-za,30 de hab i I idades)
Fonte: Leifer, 1988.
SISTEMA DE INFORMAC~O
X
ESTRUTURA DA ORGANIZAC~O
Suporte Isolado por Computador Pessoal (Siste-ma Alone PC's) Processadores em Comun i ca,30
Supor t e par a os proprietãrios, com final idade I imitadora da capac idade de processamento
Sistemas Centra-lizados (Computa-dor Central com terminais sem intel igência)
Necessidade de controle financei-ro e oper ac i ona I central izado.Roti-nas para proces-samento de dados e/ou de transa.3o
Acesso á capaci-dade de proces-samento central bases de dado .. ou bibl iotecas, time sharing.
Necessidade intra divis6es e caracter ist icas idênt icas á burocrac ia me-canizada.
Quadro 2.6
38
Sistemas Distri-buidos (Computa-dor Central liga-do com terminais intel igentes, comun i ca<;30 mui tos para um)
Processamento local individual para suportar ne-cessidades indi-viduais açopla-das a bases de dados espec i a I i-zadas ou grandes
Processamento das divis6es acoplada ás unidades admi-nistrat ivas do processador cen-trai iZado,pouca comunica,30, in-terdivis3o, ne-cessidade de con-trole pela admi-nistraç30 central
Sistemas Descen-trai izados( I iga-,30 independen-te entre term i-nai s ou proces-sadores, comuni-ca,,30 mui tos para um)
Grande quantida-de de informa.30 part ida, acesso a bases de dados descentral i za-das,capacidade de processamento da informaç3o hor izontal e verticalmente
Definir alta ca-pacidade de pro-cessamento par a Guportar a equ;PQ funcionando,pos-sibi I itar grupos centrais para re-parti,30 e coorde naç30 de prOble-mas espec ificos. Suporta tabelas complexas que conduzem a rela-cionamentos,comu-nicaç6es inter-pessoais rãpidas
Para Lelfer [Lelfer, 1988) o problema da unidade de
aná I I se assoe I ada à centra I I zação (ou descentra I I zação) de
sistemas não está ainda bem estudado. Sugere entretando
do ponto de vista estrutural a unidade de análise
que
seja
definida pelos mecanismos que Influenciam as comunicações
atuais ou potenciais entre 05 membros da organização.
2.2.3 Seleção de Software
A seleção de software deve ser iniciada pela
decisão do tipo de ambiente de processamento de dados que se
pretende estabelecer.
o ambiente de processamento de dados é um espaço de
posslbl I Idades definido por duas dimensões: a tecnologia de
adml n I stração (armazenagem, atua II zação e recuperação) de
dados e a II nguagem de programação.
A tecnologia de administração de dados é
classificada do seguinte modo [Martln, 1983), [furtado et ai,
1979), [Torres, 1989):
- Arquivos - As aplicações fazem uso de arquivos de dados
separados, projetados pelos analistas e
programadores durante a criação da aplicação.
I I - Banco de Dados de Aplicação - As aplicações fazem uso de
gerenciadores cUJo alcance se restringe aos
39
arquivos da aplicação.
I I 1- Banco de Dados Independentes - Os dados são projetados e
armazenados Independentemente da função para
a qual serão utilizados. Os dados para
c I i entes, produto ou pessoa I estão assoe lados
e representados num banco de dados
comparti I hado.
IV - Sistemas de Informação - Banco de dados organizados,
para pesquisa e recuperação rãplda de
Informações, ao Invés de operações de
produção para grande volume.
As linguagens de programação são classificadas do
seguinte modo [Torres, 1989J:
- Linguagem de máquina - tíPica do próprio hardware e
específica para cada equipamento.
II - Assembl y (11 nguagem montadora) el aborada para
facl I Itar a memorização e o trabalho do
programador. Para cada Instrução de mãqulna
existe uma correspondente em assembly.
I I 1- Linguagens de terceira geração - visam facl Iltar ainda
mais a compreensão do sentido da Instrução
(COBO L, FORTR AN, PL -1, C, 8AS I C, etc).
IV - Linguagens não procedurais ou de quarta geração
dispensam o projetista de expll citar todos
os procedimentos necessários à composição de
uma função. Na linguagem de quarta geração a
especificação é feita praticamente no nível
da função desejada. Essas II nguagens
favorecem o aprendizado e a utl I Ização por
usuários sem especialização em processamento
de dados.
Definidas as estruturas das duas dimensões que
afetam o ambiente de processamento de dados, somos conduzidos
ao seguinte espaço de posslbl I idades:
SISTEMAS M D DE INFOR-A E MACIO N I D BANCO DE P A DADOS I NU D DEPENDENTE L O A S C BANCO DE I DADOS DE O APLICACIO
ARQUIVO
MANIPULACID DE DADOS x LINGUAGENS DE PROGRAMACIO
MÁQUINA ASSEMBLY 30 GERACIO 40 GERACÃO
LINGUAGENS Fonte: Furtado, 1979.
flg.2.10
41
>
A definição do ambiente deve ser complementada com
as seguintes decisões:
seleção de sOftware de apolo, tais como processadores
gráficos, planl lha eletrônicas, processadores de texto,
sistemas de segurança de dados, etc.
seleção de software de teleprocessamento - necessário para
promover a comunicação entre processos ou entre as unidades
de processamento e os periféricos que participam de uma
mesma rede. Determinada a performance de
haja vista as questões relacionadas
todo
com o
o sistema,
nível de
aproveitamento dos canais de comunicação, segurança, etc.
seleção de sistema operacional necessáriO para
administrar o processamento multiusuário, as facl I Idades de
acesso, a segurança de dados, etc. O sistema operacional
deve suportar o ambiente projetado, o software de apoio e o
software de teleprocessamento.
As alternativas selecionadas para exame, deverão
ser submetidas a testes no ambiente operacional mais próximo
àquele que a empresa pretende Implementar (benchmark).
2.2.4 Avaliação de Risco
2.2.4.1 A Manifestação do Risco
Admitindo-se que se tenha estabelecido o elenco de
projetos a ser desenvolvido, e que este seja perfeitamente
adequado às necessidades da empresa, os gerentes devem
aval lar os riscos associados às expectativas geradas pelo
empreendimento.
Risco é a exposição a éonseqüênclas tais como
[McFarlan, 1981J:
falha em obter todos, ou mesmo qualquer, dOs benefícios
pretendidos,
custos de Implementação que superam consideravelmente os
níveis planejados,
tempo de Implementação multo maior que o esperado,
performance técnica dos sistemas resultantes multo abaixo
da esperada,
Incompatlbl I Idade dos sistemas com o hardware e o software
selecionado.
2.2.4.2 As Dimensões do Risco
Pelo menos três dimensões Influenciam o risco de um
projeto [Mc Farlan, 19811:
1 - O tamanho dO projeto: valor global do projeto, número de
departamentos afetados pelo projeto, estimativa de tempo
para desenvolvimento do projeto, número de pessoas
envolvidas no desenvolvimento do projeto.
2 - Experiência com a tecnologia: hardware, sistema
operacional, manipulação de bases de dados, linguagens de
projeto de apll cações.
3 - Estrutura dO projeto: quando os resultados dos projetos
43
estão definidos completamente, desde o momento da
concepção, pela natureza das tarefas, os projetos são
considerados estruturados. Nesse caso, os resultados são
fixos e não sujeitos a mudanças durante o tempo de vida
do projeto. No caso contrário os projetos são
considerados não estruturados.
Definindo dois valores em cada uma destas três
dimensões estabelecemos oito posslbl I idades para os níveis de
risco de um projeto, conforme representado na figura 2.11.
GRAIJ elE
E-=. TR'_'TL'RAC;::;;CI
ESTRUTURADO 14100 ESTRUTURADO
RISCO PEQUEHO E 6 H RISCO PEQUEHO (HUITO AFETADO POR GRAHDE P R T E DESVIO 6EREHCIAL) A R A " I A ~ H M M RISCO HUITO PEQUEHO H C D O I RISCO HUITO (HUITO AFETADO POR PEQUEHO A E
PEQUEMO DESVIO 6EREMCIAL) C D O O H
T E P RISCO HEDIO RISCO "UITO ALTO GRAHDE C P M O R o o L U J O E G C T I O
A A RISCO "ED 10 .... RISCO ALTO PEQUEMO
PEQUEHO
Font.e: ~1C FARLAN. '188'1
li'2l. 2.'11
44
2.2.5 A Gerência do Projeto de Sistemas de Informação
A contribuição de diferentes métodos de administrar
projetos de sistemas de Informação, varia amplamente em
função das características do projeto [McFarlan, 1981).
Quanto às características dos projetos, com relação
ao risco, já descrevemos as oito posslbl I Idades decorrentes
do critério de classificação sugerido por McFarlan.
Quanto aos métodos de gerenciar projetos, são
Identificados quatro tipos principais,
Mecanismos de Integração Externa - Incluem dispositivos de
organização e comunicação que articulam as equipes de
projeto aos usuários nos níveis gerenciai e operacional.
Mecanismos de Integração Interna - asseguram que a equipe
opere como uma unidade Integrada.
Mecanismos de Planejamento Formal - auxl I Iam a estruturar a
seqüência de tarefas e a estimativa de tempo, recursos
financeiros e recursos técnicos que a equipe necessitará
para executar o projeto.
Mecanismos de Controle Formal Aux III am os gerentes a
aval lar o progresso e a Identificar desvios potenciais de
modo a estabelecer ações corretivas.
No quadro 2.7 reproduzimos o quadro Perfi I dos
Métodos de Gerência de Projetos, transcrito do artigo de
McFarlan [McFarlan, 1981).
"5
PERFIL DOS METODOS DE GER~NCIA
DE PROJETOS
INTE6RACKO EXTERNA 11 INTE6RACKO INTERNA
• Sele~ao de usuãrio para gerente de projeto.
• Sele~30 de proficional experiente de processamento de dados para liderar a equipe. Sele~30 de gerente pa-ra conduzir a equipe.
• Cria~30 de Comite de Dire~ao de Usuãrios. Encontros freqüenntes e profundos deste Comi te. Processo de controle de mudan~as gerenciado pelos usuãrios. Distribui~30 freqüente
• Encontros freqüentes
e detalhada das minutas elaboradas pela equipe de projeto para os usuãrios chave.
da equipe. Prepara~ao regUlar e distribui~30 de minutas sobre decisõeschave a respeito da eyolu~ao do projeto. Reyisao regular do estado tecnico do projeto.
• Renoya~30 dos membros da equipe mantida
Sele~ao de usuãrios para membros da equipe. Processo formal de aproya~30 das especifica~ões pelos usuãrios. Relatõrios de progres- • s30 do projeto elaborados para o Comite de Dire~30 Corporativa. USUãri05 r~5PonsãYei5 pelo treinamento e implant~30 dos sistemas. 6er@ncia dos usuãrios sobre as decisões associadas as datas de a~ões chave.
Fonte: HcFar I an, 1981.
baixa em decorr@ncia de a~ao gerencial. Sele~30 dos membros da equipe de modo que grande percentagem jã tenha mantido rela~ões em projetos anteriores. Part ic ipa~ao dos membros da equipe na formula~ao dos objetivos e no estabelecimento das datas de conclus30.
• Assist@ncia tecnica externa.
Rede PERT, caminho critico, etc .. Sele~30 de marcos de fases.
• Padrões. de especifica~ao de sistemas.
• Especifica~ao de estudos de yiabilidade. Processos de aproya~ao de projetos. Procedimentos. de auditoria de projetos.
Quadro 2.7
46
CONTROLE FORMAL I • Relatõrios periõdicos
comparando o estado do projeto com o planejamento Disciplinas de contr81e de mudan~a.
• Encontros regulares para apresenta~30
dos resultados-mar-COS,
· Anãlise dos desvios do plano.
Neste capítulo 2, fizemos uma revisão dos conceitos
que fundamentam a proposição de Modelo de Referência para
Planejamento da Função de 51 que desenvolveremos no capítulo
5. Gomo será visto no capítulo 5, a estrutura do modelo
proposto deriva diretamente dos conceitos estabelecidos,
Anthony, 51mon, Klng e Lederer; ainda no capítulo 5 a
estrutura do modelo proposto foi detalhada e enriquecida,
principalmente, com as contribuições da Bowman, Kugler,
Bakos, Portar, Hackarthorn, Torres, GI I lenson, Lelfer e
MacFarlan.
47
CAP-xTULO 3
PERGUNTA DE PESQUISA
E METODOLOGIA
48
'Se a história da ciência nos ensina algo, é que só os que
fazem perguntas corretas recebem respostas'
(W.P.D. Wlghtman)
49
3.1 Objetivos do Estudo e Pergunta de Pesquisa.
Apesar da reconhecida ImportânCia da tecnologia da
Informação, multas dificuldades têm sido enfrentadas para
implementar as metodologlas de Planejamento da Função de SI
propostas por diferentes autores.
Uma a n á I I se de t a I h a d a de s s a s d I f I c u I da d e s f o I
apresentada no artigo "lhe Implementatlon of Strateglc
Informatlon Systems Plannlng Methodologles" CLederer et ai,
19883, pUblicado no periódiCO MIS Quarterly!september 1988.
Na pesquisa descrita naquele artigo, após
estabelecer uma "definição completa de Planejamento
Estratégico de Sistemas de Informação", os autores descrevem
as metodologias utl I Izadas com maior freqüência e estabelecem
a relação dos problemas mencionados por diversos autores "dos
mais significativos artigos" que foram analisados com essa
f I na I Idade. A segu I r os prob I emas são organ Izados em três
categorias: recursos, processos e prOdutos. A categoria
recursos remete às questões de tempo, dinheiro, pessoal e
gerênc I a. Processos remete às Ilml tações de análl se
proporcionadas pela metodologia. Produtos trata da
Intellglbllldade e propriedade do Plano Final que resulta da
aplicação da metodologia. Finalmente é medida a Intensidade
com que esses problemas se manifestam nas metodologlas
identificadas na pesquisa, e são Investigadas as possíveiS
causas dos problemas.
50
Uma reflexão a respeito dessa pesquisa sugeriu a
seguinte Indagação:
- pOderíamos desdobrar essa pesquisa em duas outras que
i n v e s ti g a s s em os p r o b I ema s I de n t I f I c a dos c om a a p I I c a ç ã o da
metodologia e os problemas Identificados para a apl icação
da metodologia?
A primeira pesquisa Investigaria a adequação da
metodologia às necessidades de Planejamento. A segunda
Investigaria as dificuldades confrontadas para a aplicação.
No caso da primeira pesquisa, pOderíamos adotar o
ponto de vista de John Oewey [Oewey, 1933J segundo o qual
todo problema começa por uma necessidade sentida ou uma
tensão que prec I samos a II v I ar. Encaminhamo-nos para a
50 I ução quando i nte I ectuall zamos "a d I f I cu I dade ou confusão
que foi sentida (experimentada diretamente), formando um
problema a ser resolvido, uma Interrogação para a qual se
deve buscar uma resposta". Assim, a pesquisa deveria acolher
todo tipo de
sentida/dificuldade/confusão)
resposta
possl blll tando
(necessidade
a coleta,
organização e categorlzação dos dados que fundamentariam
nosso conhecimento a respeito dos problemas. Poderíamos,
entretanto, adotar a definição proposta por Kepner e Tregoe
[Kepner et ai, 1980), segundo a qual "um problema é um desvio
entre o que deveria estar acontecendo e o que realmente
51
ocorre e que é suficientemente Importante para fazer com que
alguém pense que o desvio deveria ser corrigido". Para que
adotássemos esse conceito, deveríamos definir o que deveria
estar acontecendo, ou seja, construir
comparar a metodologia com o referencial
desvios.
No caso da segunda pesquisa,
perguntas deveriam acolher todo tipo de
um referenc I a I,
e Identificar 05
necessariamente, as
resposta pois, não
pOderíamos conceber a prlori um referencial que se ajustasse
a todas as necessidades sentidas/dificuldades/confusões.
Diante das pOSSlbi Ildades
decidimos desenvolver um estudo que
estabelecer a expectativa correta do
enunciadas
contrlbulsse
alcance de
acima,
para
uma
metodologia de Planejamento da Função de SI e para orientar o
uso mais eficaz da mesma. Desse modo, optamos pela primeira
pesquisa e pelo conceito de problema enunciado por Kepner e
Tregoe.
As perguntas de pesquisa que orientarão nosso
estudo, são as seguintes:
Qual é a estrutura do referencial para análise de
metodologlas de Planejamento da Função de Sistema?
• É poss í ve I fornecer I nd í c I os da va I I dade deste referenc I a I?
52
A B5P, "Bus I nesa 5ystems P I ann I ng" [I BM, 1984J, satisfaz
suficientemente as condições necessárias para a elaboração
completa do Planejamento da Função de 51?
3.2 O Método de Pesquisa Utl I Izado.
Para solucionar as questões propostas, adotamos o
seguinte procedimento:
1 - com base na revisão de literatura procuramos Identificar
elementos que nos permitam estabelecer um referencial que
se constituirá no padrão de medida do alcance de uma
metodologia. Assim sendo, se e somente se os elementos
proporcionados por uma metodologia atenderem
completamente às exigências estabelecidas pelo padrão
proposto, teremos condições de afirmar que essa
metodologia satisfaz suficientemente às condições
necessárias para a elaboração do Planejamento da Função
de 5 I;
2 - a seguir descrevemos a conduta adotada para a
do Planejamento da Função de 51 de uma
e I ab,oração
empresa de
te I ecomun I cações bras I I e Ira. Com a desc r I ção desse caso
pretendemos reunir Informações que proporcionem Indícios
da validade do referencial
I I teratura;
3 - finalmente confrontamos a
53
construído com base na
metodologia B5P com o
referencial, a fim de obter o conhecimento do alcance
proporcionado pela mesma.
Estamos alertados para o fato de que o padrão a ser
definido reflete o estado da arte, ou seja, reflete, apenas,
conceitos atualmente aceitos por espec I a I I stas de
administração de empresas e processamento de dados.
Outrossim, não pretendemos apreender no referencial todas as
contribuições disponíveis, mas, apenas, um conjunto de
contribuições que posslbl Ilte a construção da estrutura
mínima de Informações e de procedimentos que relacionam essas
informações com a estrutura das decisões que cor responde à
estrutura de Informações contida no Plano de Sistemas de
Informação. Desse modo, a estrutura do referencial conterá
elementos Identificados, por diversos autores, como
necessários ao Planejamento da função de SI, não se podendo
afirmar que o mesmo venha a satisfazer condições de
suficiência ou possa superar a ImpOSição de novas
necessidades decorrentes de Inovação tecnológica. Apesar
dessas I Imitações o referencial deverá ser
amplo para avaliar a condição de suficiência
outras metodologlas disponíveis.
suficientemente
da BSP e de
Observamos, também, que a comparação a ser
realizada objetiva determinar o alcance da metodologia em
confronto com o referencial, não podendo ser utl I Izado para
comprovar a necessidade da mesma, mas simplesmente, os
I Imites de sua suficiência.
54
A abordagem que descrevemos acima recorre ao método
do i!gMm~n1~ ~~~yl1~~ e ao método do ~ft1M~Q ~~ ~ift~.
Para Slmon ·0 princípio do mi1~~~ ~~~M11~Q para
obter conhecimento é que, se A é verdade e se B é verdade,
então sob as mesmas condições especificadas pOde-se
seguramente dizer que C é verdade. Este é o mais simples
tipo de dedução, naturalmente. As cadelas de argumento podem
ser mais longas, mais complexas e probabl I ístlcas, mas mantêm
o mesmo princípio. Note que eu chamei o método dedutivo um
·método de obter conhecimento· do mesmo modo que eu tenho
falado a cerca de vários métodos empíricos de obter
conhecimento. Num sentido empírlcamente estabelecido 05
fatos são mais presumivelmente ·conheclmento· que o que se
conclui dedutivamente, por Isso, sempre que uma dedução e um
fato emplrlcamente estabelecido col idlrem, a dedução deve ser
questionada. Note que dedução não é a mesma coisa que uma
teoria. Teoria é um corpo entrelaçado de conhecimento
sistemático existente, e é Importante exatamente por que é
uma fonte de premissas para dedução. O ~~1M~Q ~~ ki~Q é o
método a ser escolhido quando você quer obter riqueza de
detalhes acerca de algum assunto. Provavelmente você está
querendo tais detalhes quando você não conhece exatamente o
que você está procurando. O estudo de caso é então apropriado
quando você está tentando encontrar Indícios e Idéias para
pesquisas adicionais. A relação entre a pesquisa empírica e o
pensamento especulativo é complexa. Certamente não pode haver
55
ciência sem pesquisa empírica para servir como uma ponte
entre o pensamento c I entí f I co e a rea I idade, como fonte de
especulação e como teste de hipóteses" (5Imon, 1969J.
Para Blalock "a falha do estudo de caso reside na
Imposslbl I Idade de afirmar que o caso escolhido seja um
exemplo típico da realidade. I lustra apenas como a empresa
escolhida procedeu e quais os resultados obtidos, as fontes
a realidade
decodificação
de Informações disponíveis aos pesquisadores
retratada ao lon90 do estudo dependem de sua
dos dados coletados" [Blalock et ai, 1975J.
e
5imon alertou para o fato de que a diferença entre
os dois métodos (experimentação e estudo de casos) é que as
Idéias produzidas pelo estudo de caso não são testadas e
provadas por ele [5Imon, 1969J.
Em resumo, esta pesquisa foi conduzida de modo a:
a - com base no conhecimento existente (e utl I izando o método
dedutivo) deduzir a estrutura do modelo de referência de
Planejamento da Função de 51,
b - desenvolver um estudo de caso objetivando oferecer a
evidência empírica que proporciona o Indício da validade
do modelo de referência deduzido,
c - utilizar o referencial como padrão para aferição do
56
alcance de metodologlas de Planejamento da Função de SI,
especificamente a metodologia BSP.
3.3 Seleção da Empresa e da Metodologia a ser Confrontada com
o Referencial.
A escolha de uma empresa de telecomunicações, como
unidade de análise para essa pesquisa, fundamentou-se na
Importância que os sistemas de Informação assumem para essas
empresas, seja como Instrumento de autogestão, seja como
elemento alavancador de sua cadela de valores.
A escolha da BSP para objeto de estudo dessa
pesquisa foi estabelecida com base na liderança de uso que
essa metodologia revelou na pesquisa sobre implementação de
metodologlas de sistemas de Informação (lederer et ai, 1988].
3.4 Coleta de Dados
A existência de relatórios detalhados, descrevendo
todo o desenvolvimento do "Plano de Informatização dos
Processos de Gestão" da empresa de telecomunicações
selecionada como unidade de análise para a pesquisa,
facl I Itou a coleta dos dados apresentados neste estudo.
Esses relatórios descrevem as Reuniões de
Coordenação do Processo de Planejamento dos Sistemas de
57
Gestão (RECOR) e são desenvolvidos em três partes: temário da
reunião, conclusões alcançadas na reunião e recomendações
enunciadas pelo plenário da reunião.
TodoS os dados utl I Izados na pesquisa foram obtidos
desses relatórios.
A linguagem utilizada nesses relatórios, à
semelhança da utl Ilzada pelos Comitês Internacionais de
Padronização, se refere ao sujeito das orações na terceira
pessoa. Com Isto fica subentendido que o sujeito é o grupo
de trabalho, neste caso o Grupo de Coordenação ao qual se
Incorporou a Assessoria de Informatização (ambos definidos
durante a descrição do caso).
o texto que faz a conexão das diferentes reuniões
resume as condições que determinaram a realização das mesmas.
Em nenhum momento, durante a descrição dO caso, foi
manifestada a opinião do autor deste estudo.
58
CAP:É.TULO -4
DESCRIÇÃO DO CASO
59
"A ciência, embora principie pela observação do particular,
não se refere essencialmente a ele, mas ao geral. Um fato na
ciência, não é apenas um fato, mas um exemplo."
(Bertrand Russel)
60
4.1 Antecedentes
A Telecomunicações S.A., é uma empresa de economia
ml sta que tem suas atr I bu i çõe.s def I n I das em I e I. Sua ml ssão é
implantar, manter e operar o Sistema Nacional de
Telecomunicações. São operados pela empresa os seguintes
sistemas:
. Rede Básica - constituída pelos circuitos Interestaduais de
ml croondas (terrestres e por satéll te) e pel as
centrais de trânsito de telefonia;
Sistema Nacional de Telex constituído pelos circuitos
telegráficos e pelas centrais de comutação
telegráfiCa;
Sistema de Comunicação de Dados
circuitos dedicados e comutados
dados;
constituído pelos
de comunicação de
Sistema Nacional de Televisão - constituído pelos circuitos
de microondas (terrestres e por satélite) e pelos
centros de televisão.
Suportados pelos sistemas mencionados acima são
explorados comercialmente serviços dedicados (privativos) e
comutados (públicos) de comunicação de voz, texto, Imagens e
dados.
00 ponto de vista organizacional
estruturada do seguinte modo:
61
a empresa está
Uma administração central reunindo as diretorias de
Administração, Economia e Finanças, Desenvolvimento,
Operações Nacionais, Operações Internacionais, Presidência.
Compete à diretoria de Administração coordenar os
assuntos relacionados com a gerência de pessoal, material,
serviços e treinamento.
Compete à diretoria de Economia e Finanças a
gerência financeira, o controle do patrimônio, o faturamento
e a cobrança.
A diretoria de Desenvolvimento coordena os projetos
de Implantação e expansão da rede de serviços.
A diretoria de Operações Nacionais coordena com o
auxíl lo de 2 órgãos centrais a manutenção e operação da rede
de serv I ços e a comere I a I I zação e ass I stilnc I a técn I ca
real izadas por 80 centros de operações (Distritos e
Sub-Olstrltos) subordinados a 5 Regiões de Operações que se
estendem por todo o território nacional.
A diretoria de Operações Internacionais coordena a
manutenção e operação dos centros de comunicação
internacional localizados no Rio de Janel ro e São Paulo e a
comercialização dos serviços Internacionais.
Ao Presidente subordinam-se, diretamente, a
62
Assessoria Jurídica, a Assessoria de Comunicações Sociais, a
Assessoria de Planejamento e Controle e os órgãos de
Processamento de Dados da sede da empresa.
Com cerca de 12 ml I empregados, dos quais 3.500
trabalham na sede (Rio de Janeiro), a empresa conduz um
processo administrativo essencialmente central izado; esta
característica Influenciou fortemente a visão dos projetistas
de sistemas da empresa, como veremos mais detalhadamente
adiante.
Por outro lado, o processo produtivo da empresa
ocorre necessariamente de modo descentralizado. Basicamente o
problema operacional da empresa consiste em Implantar, manter
e operar 05 eqUipamentos que suportam 05 serviços oferecidos,
em todo o território nacional. Por manutenção deve ser
entendido o esforço de assegurar o funcionamento de todos os
eqUipamentos da empresa dentro dos padrões de qual Idade e
conflabl I Idade estabelecidos. Internacionalmente. Por operação
entenda-se o esforço de estabelecer ou alterar conexões entre
eqUipamentos de modo a assegurar a qual Idade do fluxo de
comunicações adequada a cada tipo de serviço. A Implantação
decorre do crescimento da rede (expansões) ou da Inclusão
localizada de eqUipamentos para atender os contratos de
serviços (terminais, modens, concentradores, etc.).
o produto da empresa é a prestação de serviços,
cujo cicio de vida típico pode ser descrito do seguinte modo:
63
comere I a II zação da un I dade de serviço, assinatura de
contrato, reserva das facl I idades para atendimento do
contrato, transferência dos equipamentos para os locais onde
serão utll i zados, I nter ligação dos equ I pamentos à rede de
serviços, testes de qualidade, ativação comercial, início do
faturamento, cobrança, manutenção da qualidade do serviço.
Dependendo do tipo de serviço pode haver desconto por
Interrupção, ou por volume de serviço consumido. O serviço
pode ser bloqueado por falta de pagamento e alguns serviços
podem ser bloqueados por solicitação do cliente. Observamos
que nem sempre é possível realizar o atendimento
Imediatamente devido a não dlsponlbl I Idade de um tipo de
equipamento. A não disponibilidade pode ser local ou total, a
ociosidade de recursos é altamente perniciosa, conclui-se
portanto que a I dentl f i cação e loca II zação do componente
necessário é um aspecto crítico do processo de produção.
Devemos notar também que para os serviços dedicados cada
unidade de serviço corresponde a um atendimento diferenciado,
ou seja, o processo produtivo tem a característica da
produção artesanal (cada unidade produzida recebe tratamento
específico) e não da produção em massa (toda unidade
produzida recebe o mesmo tratamento). Outra característica do
produto, e que afeta o processo produtivo, é que uma unidade
de serviço normalmente uti Ilza recursos geograficamente
distribuídos, demandando portanto esforço de produção (na
implantação, manutenção e operação) de mais de uma unidade de
operação. Finalmente, a prestação de serviços ocorre no
doml c í I i o do c I I ente, o que obr Iga o des I ocamento das equ I pes
84
d e a t e n d i me n to. c o n si d e r a n d o que a r e d e de s e r v I ç o s p ú b I I c o s
(não telefônica) atende a centenas de milhares de usuários e
que o número de unidades de serviços dedicados é também de
centenas de milhares de usuários, podemos avaliar a
complexidade deste processo e a Importância da Informação
como recurso de gestão da rede.
A natureza do negócio e a sofisticação tecnológica
I mpõem a I ntervenção de mão de obra a I tamente espec I a I Izada,
com baixa participação de empregados com formação de nível
primário (5~), e expressiva absorção de profissionais de
nível superior (cerca de 2D~).
Predomina no ambiente da empresa a cultura técnica
especificamente orientada para telecomunicações.
D Ingresso da tecnologia de processamento de dados
reflete a emergência dos sistemas digitais. Duas linhas de
desenvolvimento têm sido consideradas pelas pOI ítlcas da
empresa: a nlnformátlca de processo n orientada para sistemas
que suportam serviços de telecomunicações (Centrais de
Processamento Armazenado, Comutação por Pacotes, Transmissão
Digitai, etc.); e a nlnformátlca de gestão n orientada para o
desenvolvimento de aplicações que dão suporte à gestão
empresarial.
Quanto à nlnformátlca de gestão n, tema que motivou
este estudo, a gene ra I I zação do uso vem se dando de fo rma
65
lenta e gradual, tendo havido uma expansão significativa no
qüinqüênio 1980-1985.
Desde sua fundação em 1965 até o Início dos anos 80
o uso do processamento de dados ficou limitado a aplicações
clássicas tais como: folha de pagamento, faturamento de
serv I ços, controle financeiro, apll cações técnico
científicas. Praticamente Inexistiam sistemas que dessem
suporte ao processo de prestação de serviços. O processamento
de dados, na área de operações, restringia-se à transmissão
de dados para faturamento e análise de comportamento de
Serviço de Telefonia. A partir de 1980 diversas Iniciativas
(treinamento, projeto de Rede Ciranda, automação de
escritório, etc.) promoveram a faml I larldade com as técnicas
de processamento de dadOS e estimularam
loca II zado de ap I i cações para suporte
serviços.
o
da
desenvolvimento
prestação de
e poucos
capacidade
Rapidamente cresceu a demanda por microcomputadores
sistemas, parcialmente
dos minicomputadores
Integrados, esgotaram a
Instalados nos Distritos
(originalmente dedicados à transmissão dos dados de tráfego
de telefonia).
Todo este esforço de desenvolvimento foi rea I I zado
desarticuladamente, de modo a cada sistema satisfazer apenas
às necessidades percebidas pelo próprio autor, expandindo
consideravelmente a dispersão de conceitos, a superpOSição de
66
esforços e a incompatlbl I Idade entre resultados que deveriam
satisfazer ao mesmo obJetivo. Simultaneamente diversas outras
aplicações eram desenvolvidas para automatizar, no âmbito dos
Distritos, a entrada de dados que atende a necessidades
gerenciaiS da sede da empresa.
Diversos relatórios caracterizaram os seguintes
conflitos:
ênfase nos sistemas gerenciais na Sede X ênfase nos
sistemas de apoio à produção nos Distritos;
visão de sistemas Isolados para as diversas áreas da
empresa na Sede X visão de sistemas Integrados nos
Distritos;
os Distritos absorvendo o esforço de entrada de dados para
a Sede X 05 sistemas de apoio à produção dos Distritos
gerando os dados utl I Izados pelos sistemas da Sede;
a conservação do desenvolvimento centralizado pela Sede X a
I n s ti tu I ç ã o do de s e n v o I v I me n t o de s c e n t r a I I z a d o p e los
Distritos;
a concentração de recursos de processamento na Sede X a
distribuição dos recursos de processamento pelos Distritos;
ênfase na solução pelo hardware X ênfase na solução pelo
conceito;
diferentes realidades locais produzindo
sistemas diferentes.
67
propostas de
Também desses relatórios foi possível estabelecer
que a situação descrita propiciou alguma Indisciplina; mas
certamente não era esta a questão central. Faltava uma
definição clara dos objetivos e da estratégia a ser
Implementada, não existia compromisso metodológico. A opção
tecnológica não satisfazia à maioria dos usuários.
Este quadro adverso era, entretanto, altamente
compensado pelo conhecimento técnico e pela determinação de
produzir um bom resultado manifestado pelos profissionais
empenhados na solução do problema.
4.2 Definindo o PrOblema
Conhecendo amplamente o ambiente empresarial
descrito no Item anterior, a Assessoria de Informatização (A.
I.), criada pelo Diretor da Área de Operações Nacionais para
administrar o processo de planejamento dos sistemas operados
pelOS Distritos, Identificou duas alternativas para
estabelecer a unificação de conceitos e a Integração dos
esforços:
1! alternativa - . Identificar entre os sistemas existentes,
aqueles que pudessem servir de base para a
solução definitiva.
Motivação: Alguns sistemas já haViam conquistado
grande número de usuários, podendo ser
considerados altamente promissores como
68
Vantagens:
Desvantagens:
núcleos de desenvolvimento.
aproveitamento do aprendizado acumulado
durante o desenvolvimento do sistema;
menor perturbação Introduzida por migração
de sistemas;
poss I blll dade de ml gração rápida para
outro ambiente de hardware em função da
escolha adequada de I I nguagem de
programação (multas soluções foram
descartadas, pois fizeram uso de linguagem
proprietária).
dificuldade de general Izar a sOlução de
modo a satisfazer as necessidades
demandadas pela diversidade de serviços;
documentação dOS sistemas insatisfatória;
necessidade de Investir em melhoria de
performance;
necessidade de Investir para superar a
resistência de usuários.
2ª alternativa - . Ignorar as soluções existentes,
Motivação:
aproveitando a oportunidade para promover
um esforço de Integração de sistemas.
o relativamente baixo nível de
aproveitamento possível de ser realizado e
a expectativa multo provável da
necessidade de migrar do ambiente de
hardware e software disponível nos
69
Vantagens:
Distritos.
orientar o esforço de desenvolvimento em
bases conceituais bem estabelecidas;
propiciar a oportunidade de convergência
de pontos de vista e de comprometimento
com a solução;
apropriar recursos e ferramentas
proporcionados pelo desenvolvimento
tecnológico e pela experiência acumulada
e/ou desenvolvida pelos profissionais da
empresa.
Desvantagens: e x I 9 I r ma i o r e s f o r ç o de
sistemas;
migração de
Iniciar um empreendimento que seguramente
terá que confrontar a reação de correntes
conservadoras.
Como premissa fundamental fOI estabelecido pela
A. I. que a seleção de uma dentre as duas alternativas deveria
ser realizada por um Grupo de Coordenação (G.C.) que
Incluísse profissionais experientes e representativos do
ponto de vista de cada Região de Operação e dos õrgãos
Centrais de Coordenação da Operação e da Comerciai Ização. A
opção pela decisão coletiva não resultou dO estl lo de
gerência (autoritária/liberai) dos coordenadores do projeto
mas sim da
modelagem
compreensão
de sistemas
por parte dos mesmos,
de Informações é
de que a
alcançada,
tecnicamente, atrevés de um processo de construção conceptual
70
que tem no futuro usuário do sistema o principal artesão.
A fim de não polarizar os participantes do Grupo de
Coordenação, a existência das duas alternativas não foi
mencionada pela A. I.; desse modo, as conclusões se
construi ram a parti r de um processo de auto-avall ção col eti va
orientada para a identificação e superação das Insuficiências
conceituais e técnicas.
Para a I cançar a ava II ação desejada, a A. I •
organizou o seguinte temário para a primeira Reunião do Grupo
de Coordenação (I RECOR):
A - Ava I i ação da Situação Ex I stente:
Sistemas em Produção
Sistemas em Desenvolvimento
Recursos Humanos
Hardware e Software
Organização da Rede
B - Exp II c I tação da Situação Pretend I da:
O proJeto pretendido
A Interface entre áreas
A estrutura das bases de dados
As estratégias para: desenvolvimento de
software, Implantação, Integração dos
sistemas,
recursos
técnicos, cooperação Intra-área, cooperação Interáreas,
cooperação com os usuários.
71
c - Exp I I c I tação dos recursos necessár I os à I mp I ementação das
estratégias pretendidas.
D - Explicitação das ameaças ao desenvolvimento pretendido.
E - Exp I I c I tação das oportun Idades contemp I adas com o
desenvolvimento pretendido.
F - Exp I I c I tação dos pontos fortes e das fraquezas
relacionadas com os objetivos projetados.
G - Avaliação da oportunidade de descentra I I za r o
Desenvolvimento e a Manutenção de Sistemas.
A Assessoria de Informatização não tinha a
expectativa de obter, em uma reunião, as respostas para todas
estas questões. Para a A.I. o principal objetivo da reunião
era estabelecer o confronto dos representantes das Regiões e
dos órgãos Centrais com o problema. Arriscava antecipar a
avaliação que este tipo de abordagem superaria as principais
resistências e as posturas radicalmente entrincheiradas em
uma presumida posição de vanguarda.
Para a A. I. a dificuldade do tema, revelaria a
IncapaCidade coletiva de explicitar uma proposta completa,
Integrada, produtiva, consistente e coerente com os objetivos
da empresa como um todo e com as necessidades de cada local.
A dificuldade do tema conduziria ao esforço de
descentralização de ponto de vista que predispõe ao trabalho
cooperativo.
Todos os participantes poderiam dispor do tempo que
72
julgassem necessário à manifestação de suas propostas.
Os resultados do primeiro encontro confirmaram as
expectativas da Assessoria de informatização.
Apresentamos a seguir as principais conclusões e
recomendações.
Conclusões:
A - Situação Existente
A.1 - Os sistemas desenvolvidos no ambiente dos diferentes
Departamentos e Regiões
inconvenientes:
apresentam
superpOSição entre sistemas, Isto
os seguintes
é , sistemas
desenvolvidos em ambientes diferentes Implementando
total ou parcialmente os mesmos processos;
falta de Integração entre os sistemas, isto é, os
resultados produzidOS por um sistema não posslbl I Itam
o aproveitamento por outros sistemas em ambientes
diferentes ou no mesmo ambiente;
dispersão conceptual, Isto é, os conceitos vêm sendo
estabelecidos segundo a compreensão de cada autor em
função do contexto e das necessidades locais.
A.2 - Os sistemas em desenvolvimento em ambientes diferentes
apresentam as seguintes características:
A.2.1 - No ambiente de micro-computadores, Isto é , no
73
ambiente do usuário final: manutenção das tendências
observadas nos sistemas desenvolvidos (em operação).
A.2.2 - No ambiente de mini-computadores, Isto é, no ambiente
com adml n Istração espec I a Ilzada: man I festação de
tendência de desenvolvimento de sistemas parcialmente
integrados, ou seja, Integrado por função, em alguns
Departamentos e Regiões.
A.3 - Recursos Humanos
Em quantidade e qualidade suficientes para produzi r os
sistemas necessários se forem eliminadas as
superpOSições de esforços e for promOVido o treinamento
para o hardware e software a ser Identificado e
selecionado para o futuro.
A.4 - Hardware e Software
A.4.1 - Hardware
A.4.1.a - Ambiente de micro-computadores
expandido para proporcionar a
Devendo
capacidade
ser
de
processamento necessária à sustentação da agi I Idade
operacional. O crescimento do número de máqUinas
não acarretará em perda ou ociosidade de recursos
no futuro, pois todos os eqUipamentos poderão ser
aproveitados no ambiente futuro.
A.4.1.b - Ambiente de mini-computadores capacidade
totalmente esgotada. Necessidade de renovação na
maioria dos ambientes onde se real iza transmissão
de arquiVOS de telefonia, necessidade de seleção de
74
tecnologia mais adequada aos sistemas de gestão em
todos os ambientes [maior velocidade de
processamento, maior capacidade de memória,
arquitetura mais moderna, software de comunicação
(para teleprocessamento), sistema operacional mais
flexível, etc.J.
A.4.2 - Software
A.4.2.a - Ambiente de micro-computadores Acolheu
praticamente todos os produtos disponíveis no
mercado. Oeste modo, os sistemas desenvolvidos, se
suportam nos mais diferentes produtos, dificultando
sobremodo a comunicação entre
divulgação dos bons rsultados. A
sistemas e a
não padronização
dispersou o conhecimento e desencoraJa a migração
das centenas de pequenos sistemas existentes para
produtos padronizados, pois exigiria a I mobll I z a ç ã o
de recursos consideráveis.
A.4.2.b - Ambiente de mini-computadores - Apresentou-se mais
d I se I p II nado. De um modo gera I predoml nou a
utll i zação do COBOl, o que favorece a di sseml nação
dos sistemas e a migração de ambientes. Entretanto,
alguns sistemas Importantes fizeram
linguagens exclusivas do fabricante, ou
uso
mesmo
de
de
linguagens de alto nível desenvolvidas na empresa,
o que torna praticamente Inviável a migração destes
sistemas para o ambiente de outros fabricantes.
75
A.S - Organização da Rede
A multiplicidade de equipamentos e a utlll zação
altamente diversificada dos recursos
formação de redes. MUltiplicam-se,
não
em
favorecem a
um mesmo
diferentes ambiente, terminais dedicados a
processadores, obrigando os usuários a se ajustarem aos
diversos ambientes de processamento.
I nter II gação entre processadores
terminal de uma máquina emule o
máquina. Nenhuma SOlução que
Algumas vezes a
possibilita que o
terml na I de outra
tire partido de
gerenciadores de rede, tornando a comunicação entre
máqUinaS e sistemas transparente para o usuário. As
diretrizes estabelecidas pelos gerentes de
processamento da empresa, no sentido de estimular a
utilização de redes locais, não empolgaram os gerentes
de processamento das áreas usuárias; pois o custo
destas redes e a Insuficiência de software para estes
produtos consumi ria, de forma Improdutiva, os recursos
necessários à Implantação de uma solução em rede.
B - Situação Pretendida
B.' - O Projeto Pretendido
Nenhum participante do encontro foi capaz de oferecer
uma proposta que satisfizesse às expectativas do grupo.
Dois participantes conseguiram estabelecer proJeções
sugestivas. De um modo geral, a primeira alternativa
estabelecida pela equipe coordenadora, Isto é,
selecionar sistemas que pUdessem ser considerados como
76
núcleos de desenvolvimento, foi cons I derada I nv I áve I,
pois exigiria esforços de adaptação que não
compensariam o comprometimento com concepções
desenvolvidas a partir de visões Isoladas.
B.2 - A interface entre as áreas
Não fOi possível definir uma sOlução adequada. Nenhuma
experiência anterior possibilitou estabelecer
expectativas de Integração entre sistemas das
diferentes áreas funcionais.
B.3 - A estrutura das bases de dados
A empresa acumulou multa experiência em sistemas
suportados por Software Gerenciador de Banco de Dados
(SGBD); entretanto, estes sistemas não tiram partido de
toda a potencialidade de um SGBD. As soluções
alcançadas satisfazem às necessidades. departamentais e
não às necessidades corporativas. Desse modo, os dados
não resultam da articulação entre processos, mas sim de
atividades de entrada de dados que se superpõem ao
registro de Informações necessárias
normais de produção. foi considerado
às atividades
Importante fazer
uso de SGBD nos sistemas de apolo à produção.
B.4 - Estratégias
A não definição de um proJeto Invlabi I izou a definição
de estratégias.
77
c, O, E, F - Recursos, Ameaças, oportunidades, Pontos Fortes
e Fracos - sem definição
G - Descentralização do Desenvolvimento e Manutenção
A dimensão da tarefa e a dispersão geográfica dos
recursos humanos,
desenvolvimento e
determinam
manutenção
P I anel amento centra II zado.
uma conduta
descentra I I zados
de
com
Mais Importante do que as conclusões a respeito dos
temas propostos para debate, foram os produtos da auto
ava I I ação co I eti va. A I ncapac I dade de exp I I c i tar uma so I ução
estimulou a reflexão. Não seria possível sustentar a
dispersão conceptual resultante do empenho de antecipar
resultados de forma localizada. Evidenciou-se a necessidade
de elaborar métodos e Identificar ferramentas disponíveis no
mercado. Emergiu à consciência do grupo a necessidade do
esforço coletivo e o compromisso com a iniciativa de
proporcionar à empresa um Sistema Integrado. Desse
compromisso resultaram as seguintes recomendações:
Recomendações:
1 - Selecionar dentre as aplicações existentes aquelas que
satisfizerem de modo mais adequado as necessidades dos
usuários, em todos os Distritos, de modo a possibilitar a
Interrupção Imediata da superposição de desenvolvimento
de sistemas.
2 - Restringir a atividade de desenvolvimento à conclusão de
78
sistemas não redundantes, que representem significativo
apolo às atividades de produção e para os quais a
necessidade de Investir recursos não supere em duas vezes
o I nvestlmento já real I zado.
3 - Limitar a aplicação da mão-de-obra de desenvolvimento e
manutenção às atividades mencionadas nas recomendações 1
e 2 e à manutenção estritamente corretiva, promovendo a
liberação dos recursos necessários ao empreendimento do
novo projeto.
4 - Rever o Plano Diretor de Informática, de modo a eliminar
superposições.
5 - Propor ;lo OI retorl a da empresa a formal I zação de uma
estrutura orientada para o Planejamento e Controle do
Desenvolvimento de Sistemas.
6 - Elaborar uma Metodologia de Planejamento de Sistemas.
7 - Estabelecer um cicio de reuniões que posslbl I Ite:
avaliar o estado das providências determinadas na
reunião anterior;
promover a correção de rumo;
determinar novas providências.
o cicio de reuniões teve por Objetivo manter todo o
grupo comprometido com os resultados alcançados com o
desenvolvimento das providências, posto que todos os
representantes de Departamento Influenciavam efetivamente
estes resultados. As reuniões propiciavam, aos coordenadores
do processo, as condições favoráveis à sustentação da
motivação Indispensável ao andamento das providências. Para
79
início do ciclo deve ser considerada essa primeira reunião.
É Importante observar que as questões a serem
resolvidas já estavam enunciadas na agenda dessa primeira
reunião, e que a dinâmica de trabalho em grupo foi mantida
durante todo o processo de planejamento e desenvolvimento,
como mecanismo de enriquecimento conceptual e comprometimento
com os resultados.
Como veremos a seguir, os temas propostos na
primeira agenda permaneceram em pauta durante os encontros
posteriores. A cada reunião o conjunto de conhecimentos
crescia, o que capacitou o Grupo de Coordenação a empreender
a construção coletiva dO Planejamento da Função de SI.
4.3 - Identificação e Seleção de Metodologia de Planejamento
da Função de SI
Para solucionar a questão metodológica, proposta na
primeira reunião, foi constituído um grupo
com participação de duas Regiões, dos órgãos
especial (G.E.)
de Coordenação
da Sede e de profissionais do órgão de Processamento de Dados
da empresa. (A redução do número de participantes dos
Distritos atendeu à necessidade de redução de custos).
Este grupo especial Imediatamente procurou
Identificar um método que fosse recomendado pela empresa ou
pela holdlng do sistema. Como não havia nenhum método
BO
padronizado, foi estabelecido como objetivo a formulação de
uma metodologia. Entenda-se como formulação o desenvolvimento
completo do método.
Depois de se ter investido algum tempo na
elaboração de um modelo, o G.E. percebeu que a abordagem
pretendida estava desconsiderando todas as contribuições que
se poderia obter no mercado ou na I iteratura especializada.
Então, o G.E. optou pela realização de uma pesquisa com o
objetivo de Identificar propostas metodológicas que pUdessem
ser aval I adas para utll i zação pel a empresa.
FO ram rea I i zados contatos com universidades,
consultorias e bl bllotecas. Em pouco tempo foi possível
IdentIficar os seguintes métodos de Planejamento de Sistemas:
APX(A) [Pereira et aI, 1979), SADT(B) [Softech Inc, 1976),
ISAC(C) [Lundeberg et ai, 1979), MERISE(D) [Metodata, 1986) e
BSP(E) [I BM, 1984).
Identificados os métodos e obtida a documentação
Iniciou-se o processo de seleção.
Pre II ml narmente o G. E. determl nou o que dever I a ser
esperado como resu I tado de uma proj eção rea I I zada com base em
um método de planejamento de sistemas, tendo sido concluído o
seguinte:
1 - o produto final deve ser um esboço global de todos os
sIstemas utl I Izados pela empresa, sem incluir detalhes de
81
desenvolvimento;
2 - cada sistema deve se apresentar como um subconjunto com
contornos nitidamente definidos;
3 - 05 sistemas devem apresentar alta coesão interna e fraca
coesão externa,
estáve I;
de modo a resultar uma construção
q - os sistemas devem estar orientados para a estrutura
funcionai e não para a estrutura organizacional;
5 - os sistemas devem dar suporte aos objetivos da empresa;
B - os sistemas de planejamento, controle e apolo à decisão
não devem sobrecarregar o sistema produtivo, Isto é, os
dados para planejamento e controle, quando originados
pela área de produção, devem ser normalmente
requisitados pelos processos produtivos;
7 - os sistemas devem se articular através da estrutura de
dados.
Além da expectativa associada aos resultados, o
G.E. considerou importante que o método proporcionasse:
8 - compromisso com uma visão slstêmlca de empresa;
9 - procedimentos completamente definidos;
10 - fac I I i dade de I mp I ementação;
11 - procedimentos suficientemente simples, permitindo ampla
difusão na empresa;
12 - base conceptual a ser expandida na fase de
desenvolvimento;
13 - articulação entre função e processo, processo e dado,
dado e decisão, e, decisão e modelo de decisão.
82
Definidas as expectativas com relação aos métodos,
o G.E. construiu uma tabela para registrar, em uma escala de
1 a 5, a Intensidade pela qual cada expectativa se
manifestava em cada método. Esta tabela foi preenchida pelos
participantes do grupo especial e ofereceu o
resultado (quadrO 4.1):
ESCALA PARA AVALIACÃO DE METOOOLOGIAS DE PLANEJAMENTO DE SISTEMAS OE INFORMACÃO
MÉTODOS
( A ) ( B ) (C) (O) (E)
âPX SAOT I c:; Ar. !MFR I c:; F RC:;P
E 1 3,7 2,5 2,7 3,5 4,2
X 2 4,3 3,2 2,8 3,8 4,3
P 3 3,2 3,0 3,4 3,2 4,1
E 4 3,8 2,3 2,1 3,5 4,4
C 5 2,4 1 ,9 2,1 2,5 4,2
T 6 2,1 2,6 2,5 3,1 3,8
A 7 q R , .8 2.4 ;:> 4 4 q
T 8 2,4 2,2 2,3 1 ,9 4,5
I 9 4, 1 1 ,3 4,2 3, 1 4,7
V 10 4,2 2,0 2,3 2,1 3,9
A 1 1 4,3 2,1 1,7 2,5 4,0
S 12 2,8 1,7 2,0 3,0 4,1
,"" q ;:> , .:3 , .8 ;:> n q <;
TOTAL 44,1 27,9 32,3 36,6 54,0
(os valores representam as médias para cada Item)
Quadro 4.1
83
seguinte
o G.E. evidenciou o seguinte:
as metodologlas SACT e ISAG são ferramentas mais
apropriadas à fase de desenvolvimento de sistemas, por Isto
obtiveram a pontuação mais baixa;
com relação à metodologia SACT não foi
documentação completa;
possível obter
a metodologia MERISE, apesar de ajustada ao objetivo de
planejamento, não se apresentou adequadamente documentada;
a metodologia APX quando comparada com a metodologia BSP,
oferece resultados parciais e fundamentação Incompleta.
Gom base nos resultados mencionados acima,
recomendou a utl I Ização da metodologia 8SP.
o G.E.
Após a seleção da metodologia, antes de anunciar a
escolha, o grupo de coordenação (G.G.) decidiu realizar um
teste, para aval iar os Impactos que ocorreriam no ambiente em
decorrência da Implementação da BSP.
o G.G., então, convocou um grupo de usuários ao
qual foi proposto um exercício objetivando avaliar a
fami II ar I zação com 05 conceitos que fundamentam a
estruturação do BSP. Esses usuários atuavam como gerentes em
diferentes segmentos funcionais da empresa (cabe lembrar que
predomina a cultura técnica mesmo entre os empregados que
exercem atividade gerenciai>. O G.G. solicitou a cada
participante desse grupo de usuários que Identificasse as
84
decisões de natureza estratégica, tática e operacional e
estabelecesse a articulação destas decisões com os dados por
elas consultados, com os processos que originam estes dados e
com as funções que suportam estes processos. Para facl I Itar,
cada participante resolveria a questão apenas para as
decisões que afetassem mais diretamente o contexto de sua
área de atuação, bem como para as decisões para as quais sua
área de atuação contribuísse ou originasse.
Em resumo, seria necessário que cada participantes
organizasse tabelas com um formato padronizado, conforme
representado no modelo a seguir (figura 4.1):
NíVEL
ESTRA-TéGICO
TÁTICO
PRODUCÃO
ESTRUTURA DE ARTICUlACÃO DAS DECISõES,
DADOS, PROCESSOS E FUNCõES
DECISÃO DADOS PROCESSO FUNCÃO
flg. 4.1
Para efeito desse exercício, uma decisão pode ser
uma ordem de execução de tarefa, uma solicitação de recurso,
uma definição de produto, etc. Por outro lado, os dados podem
ser produzidos por processos Internos ou externos à empresa
85
ou à área funcionai de atuação do participante do exercício.
Com esse exercício o G.C. pode aferir o ajuste de
conceitos entre gerentes, a visão da articulação entre
funções e entre processos, e, a percepção de cada
participante com relação à origem dos dados que subsidiam
suas decisões.
A realização desse exercício não ocorreu sem
dificuldade. Houve necessidade de se repetir a tarefa algumas
vezes.
A p r i me i r a dificuldade dizia respeito ao
desencontro de conceitos. Apesar de se entender de forma
adequada o alcance de uma decisão, não havia conhecimento
homogêneo, e para alguns participantes nem mesmo
conhecimento, do tratamento formalizado e sistematizado que
os especialistas propõem para a formulação de pol ítlcas e
estratégia empresarial.
Para superar essa dificuldade o G.C. promoveu um
treinamento tomando-se como referência o livro "pol ítlca e
Estratégia de Empresas" (Bethlem, 1981).
Cone I u í do o tre i namento, a rea I i zação do
evoluiu; a dificuldade deslocou-se do desacordo
destino
exercício
conceptual
dos dados, para a miopia com relação à origem elou
isto é, não se sabia Identificar com clareza em que
86
processos, de qual função, um dado era originado, e nem em
que deCisão, de qual função um dado originado viria a ser
utilizado. Para os dados originados e consumidos por
processos de uma mesma área funcionai esta dificuldade era
atenuada. O grupo de usuários percebeu neste momento a
facilidade com que se multiplicam os processos geradores de
dados (o que compromete a Integridade dos sistemas) e, a
extensão dos Impactos que a alteração da estrutura de um dado
produz na estrutura de decisões (o que compromete a
estabi I I dade dos si stemasl. O grupo de usuários foi
aprimorando a visão da estrutura de processos e da estrutura
de dados. A estrutura de dados passou a ser reconhecida como
um recurso comum, do qual todos dependi am e para a qual todos
contribuíam.
A continuidade do exercício aprimorou a
harmonização de conceitos e aprofundOU o conhecimento da
estrutura de processos e da estrutura de dados.
A Interrupção do exercício ocorreu quando, para o
G.C. a expectativa de Incorporar benefícios não compensava os
custos da mobll ização dos recursos humanos. Entretanto, neste
momento, a empresa Já podia contar com um grupo de pessoas
perfeitamente faml I larlzado com os conceitos e a natureza do
problema a ser enfrentado no processo de Planejamento. Este
grupo de pessoas, deliberadamente, Incluía mais de um
representante de cada Departamento e de duas Regiões, e, Iria
constituir o núcleo de Irradiação destes conhecimentos para
87
dentro de suas áreas de atuação (internai Ização de
conhecimentos), e, posteriormente a equipe coordenadora do
processo de planejamento.
Apesar do avanço alcançado com o exercício e o
treinamento, o contexto geral da empresa, em especial a
dispersão geográfica, sugeria ao G.G. que o avanço fosse
conduzido com cautela. Desse modo, foi realizada uma
simulação do processo de planejamento, apl icando-se a BSP.
Gom a simulação o G.C. pretendia verificar se as pessoas após
o treinamento estariam em condições de operacional Izar a
metodologia. Os resultados da simulação foram animadores, a
aplicação do método estabeleu a macro representação da
arquitetura global dos sistemas requisitados pelos usuários.
O G.G. concluiu que era oportuno divulgar a
metodologia e engajar a estrutura no processo. Essa tarefa
exigiria grande esforço, mas, diante dos resultados
alcançados, Já não representava grande risco técnico.
O G.G. programou, então, a I I REGaR, durante a qual
foram debatidos os segUintes temas:
A - Avaliação das providências relativas às recomendações da
I REGaR;
B - Apresentação da MetOdologia de Planejamento de Sistemas
(MPS) selecionada;
G - Debate sobre a MPS;
ss
D - Apl i cação da MPS ao ambl ente da Área de Operações
Nacionais;
E - Determinação dos fatores que Influenciam o Planejamento
estratégico da informatização dos processos de gestão;
F - Determinação das diretrizes para o desenvolvimento do
ambiente de software;
G - Determinação das diretrizes para o desenvolvimento do
ambiente de hardware.
CONCLUSõES:
A - Providências relacionadas com a I RECOR
Superposição e Interseção de Sistemas - Foi apresentada
e debat I da uma re I ação de todas as ap I I cações
existentes, evidenciando-se a superposição elou
i nterseção entre as mesmas ou com ap II cações em
desenvolvimento. Considerou-se que essa relação se
constituía numa referência Importante para difusão do
conhecimento das aplicações existentes, possibilitando
o aproveitamento dos resultados existentes e a
mlnlmlzação da superposição de esforços.
Foi realizada uma estimativa da capacidade de
processamento necessária para suportar todas as
aplicações existentes em todos os ambientes da Área de
Operações Nacionais. Essa estimativa não considerava
mudança de tecnologia ou do elenco de apl icações; tinha
por objetivo oferecer uma primeira aproximação das
89
necessidades globais de recursos para orientar o modo
de conduzir a aquisição de novos recursos.
B - Apresentação da MPS
A apresentação da MPS foi desenvolvida em três etapas,
a - descrição do procedimento de seleção da MPS.
Apresentação da BSP;
b - apresentação dos resultados alcançados pelo grupo de
u suá r los que r e a I I z o u o e x e r c í c I o d e a p I I c a ç ã o da BS P
e da Matriz de Referência (Processos X Classes de
Dados) ;
c - apresentação de um exercício de desenvolvimento, de
dois sistemas da Matriz de Referência, objetivando
oferecer uma antevlsão do conjunto de métodos a serem
utl I Izados nas fases de planejamento e projeto de
sistemas;
C, O - Conclusões dos debates e expectativas com relação à
aplicação da MPS no ambiente da Área de Operações
Nacionais;
Necessidade do envolvimento de todos os Distritos de
modo a promover o adensamento cultural e a percepção
homogênea dos processos operados pela empresa
Institucional Ização urgente da estrutura do grupo de
coordenação e de comissões de Informatização nas
Divisões de Departamentos da Sede e dos Distritos
das Regiões de Operação;
9D
Promoção de treinamento para desenvolver base
conceptual para o processo de planejamento de
sistemas;
Geração da matriz processos X classes de dados a
partir das contribuições originadas em cada
Departamento e Região;
Identificação dos projetos (aplicações) a serem
desenvolvidos em ambiente de nova tecnologia;
Desenvolvimento de Sistemas realizado de forma
de s c e n t r a I i z a da, c om e I I m i na ç ã o de s u p e r p o s I ç õ e s e
maxlmlzação de resultados para os usuários.
E - Aspectos a serem considerados na formulação da estratégia
para Implementação de sistemas de informação
I. Aspectos condicionados pela opção tecnológica:
centra II zação X descentra I I zação de dados;
ambiente de hardware e software;
administração de dados;
tecnologia da rede de teleprocessamento;
estação de trabalho;
SGBD;
pr I or I dade para as ap II cações que
processo produtivo.
suportam
2. Aspectos condicionados pela cultura da empresa:
o
Conduta para transição do ambiente atual hardware
(micros e minis), software (comprometidos com o
91
fabricante de equipamento ou multo disperso) e
apl i cações para o ambi ente futuro;
Restrições à expansão do quadro de pessoa I,
mão-de-obra distribuída geograficamente, tendência à
descentralização do desenvolvimento, tendência à
adoção da BSP pela empresa;
Resistência à mudança da situação de desenvolvimento
isolado para a situação de desenvolvimento
comprometido com a BSP.
3. Treinamento
Programar o treinamento de modo a satisfazer os
se9ulntes objetivos:
ampl iar a capacitação dos prOfissionais de
processamento de dados;
capacitar usuários para o processo de
desenvolvimento de sistemas;
promover o ajuste de expectativas com relação à
conduta de trabalho e obter o comprometimento da
estrutura gerenciai com base nos méritos exibidos
pela metodologia.
f - Diretrizes para o desenvolvimento do ambiente de software
a. Software de Ap I I cação
o planejamento elaborado com base na BSP deve conduzir
92
a uma estrutura de aplicações que ostente as seguintes
propr I edades:
un I versa II dade do proj eto - I sto é, a estrutura das
ap I I cações deve ser ta I que, apesar da di vers Idade
de serviços, um único projeto conceptual deve
satisfazer a todas as situações (Invariância);
modularidade de projeto de modo a poder se
acomodar à diversidade de ambientes de operação;
distributividade do projeto - isto é, os projetos
deverão ser desenvolvidos em locais diferentes.
Observação:
não converter sistemas atuais para ambiente futuro;
novos desenvolvimentos somente nos projetos decorrentes
da BSP.
b. Linguagens de programação para novos desenvolvimentos:
e I I m I n a r o uso d e I I n 9 u a g e n s p r o p r I e tá r I as;
adotar apenas linguagens consagradas pelo mercado.
G - Diretrizes para o desenvolvimento do ambiente de hardware
a. Ambiente existente:
aquisição ou expansão de equipamentos somente com a
finalidade de acolher aplicações já existentes;
expansão no ambiente de micro I Imitado ao número de
93
estações de trabalno compatível com este
equipamento.
b. Ambiente futuro:
subordinar a progressão da Implantação a um modelo
que discipline a prioridade das aplicações e dos
ambientes operacionais. Essa ordenação se faz
necessária em função das I Imitações de Investimento
e recursos numanos;
rede de teleprocessamento ajustada ao fluxo de
comunicações e não aos Interesses de controle;
compatl blll zar os equl pamentos atual s com a rede
futura;
centra I Ização X descentra Ilzação de bases de dados;
promover comunicação entre equipamentos.
Recomendações:
I. Formal Izar a estrutura de Coordenação do processo de
Informatização;
2. Apl icar treinamento para uti Ilzação da BSP;
3. Aplicar a BSP ao problema da empresa (no âmbito dos
Departamentos e Regiões - visões Isoladas);
4. Unificar propostas resultantes da recomendação 3 em
reunião específica.
Os resultados alcançados nessa reunião ao serem
94
comparados com os resultados da I REGOR revelam significativa
mudança de percepção ocorrida entre usuários e profissionais
esboçadas pelo a ser de processamento de dados. Começavam
G.G. novas concepções para uso de software e hardware,
compatíveiS com a estrutura e as necessidades operacionais
das novas aplicações que emergiam. Tornara-se evidente para o
G.C. a necessidade de congelar
equipamentos da tecnologia então
o Investimento
existente e
para
de se
estabelecer uma conduta para minimizar os
transição do ambiente tecnológico existente para
efeitos da
o ambiente
tecnológico que então se esboçava. Emergiam os conceitos de
administração
questionava-se
de
a
dados e
existência
modelagem
de
de dados,
ferramentas
e ,
que
proporcionassem apolo às atividades de desenvolvimento dos
proJetos lógico e físico.
95
4.4 Definição de Diretrizes
4.4.1 A I I I RECOR
A proximidade da data de conclusão da proposta de
recursos orçamentários que subsidia a
planejamento anual da empresa sugeria
programação da I I I RECOR. Era necessário que
elaboração do
Precipitar a
o planejamento
de recursos fosse realizado para dar suporte aos sistemas
determinados pela aplicação da BSP ao ambiente da empresa.
Embora a necessidade de resolver o desafio proposto
pelo temário da RECOR tivesse motivado o esforço de
pesqu i sa na II teratura espec I a II zada e/ou a consu I ta a
fornecedores de equipamentos e software, para o G.C. era
prudente estabelecer o Plano Diretor de Informática, derivado
da BSP, antes que a capacitação dos profissionais que
participavam do processo de planejamento estivesse plenamente
desenvolvida.
O G.C. decidiu, então, realizar uma reunião que
definisse as condições de contorno da solução pretendida.
Essa antecipação de visão da solução pretendida seria
suficiente para posslbl Iltar a orientação do Investimento
durante o tempo de transição entre o ambiente atual e o
ambiente futuro de forma a minimizar a posslbl I Idade de
programar Investimentos que viessem a se revelar
Incompatíveis com o ambiente que estava sendo projetado para
o futuro. Além do Interesse Imediato, o resultado da reunião
permitiria programar outros encontros, para decisões
específicas a partir de uma visão global já estabaleclda.
'l6
A I I I RECOR desenvolveu os seguintes temas:
A - Matriz Processo X Classes de Oados dos sistemas que
afetam a Área de Operações Nacionais;
B - A arquitetura das aplicações na Área de operações;
C - A conduta para o desenvolvimento das aplicações;
O - A estratégia de software
Linguagens de Programação
SGBO
E - A estratégia de desenvolvimento de rede;
F - A estratégia de desenvolvimento de hardware;
G - A estratégia para a transição de ambientes;
H - A conduta para a Implantação da Administração de Dados;
- A conduta para tratamento dos altos volumes de
transml ssão de dados dos bll hetadores.
Antes da apresentação dos temas da reunião foram
aval iadas as providências solicitadas na reunião anterior,
tendo sido concluído o seguinte:
a estrutura de Coordenação do Processo de Planejamento da
Função de SI fora formalizada pelo Diretor da Área de
Operações Nacionais, evidenciando o comprometimento do
mesmo com a conduta estabeleCida;
o treinamento para aplicação da BSP havia sido realizado;
as visões Isoladas, originadas pela aplicação a BSP, no
âmbito das Regiões e Departamentos, haviam SidO
desenvolvidas.
97
Após essa verificação cada representante das
Regiões e Departamentos no Grupo de Coordenação realizou a
apresentação da proposta que elaborara para oferecer a
solução das questões enunciadas no temário. As apresentações
posslbl I Itavam apartes e os debates contribuíam para aumentar
o conhecimento acumulado pelo grupo.
Conclusões:
- Objetivos Gerais
o planejamento de Informática deve ser orientado para dar
suporte aos objetivos da empresa, bem como esta deve
focal izar o processamento de dados e os dados como bens
comuns;
a gerência da Informação deve ser real izada de forma a
posslbl I Itar a utl I ização do dado onde e quando este for
necessário;
a seleção de
produtividade
tecnologias deve
da atividade de
programação de sistemas;
valorizar o aumento de
desenvolvimento e a
a seleção de tecnologias deve valorizar a posslbl I Idade de
reduzir o custo de manutenção de sistemas;
o usuário deve participar nos processos de planejamento,
desenvolvimento e Implantação de sistemas;
98
deve ser estabelecida a Integração dos sistemas das
diferentes áreas funcionais da empresa;
o processo de treinamento deve ser utlll zado para
disseminar o conhecimento dos métodos e ferramentas
selecionadas para Planejamento e desenVOlvimento de
sistemas de modo a capacitar a mão-de-obra necessária à
sustentação do processo de desenvolvimento.
I I - Objetivo EspecífiCO
o objetivo a ser alcançado pela Informatização dos
processos de gestão na Área de Operações Nacionais é o
desenvo I v I mento e I mp I antação dos 51 stemas exp I I c I tados
pela aplicação da metodologia BSP no ambiente dessa Área.
I I I - Diretrizes Básicas (numeradas na ordem do temário e
apresentadas na ordem do debate)
A, B - Foram apresentadas
classes de dados
visões da matriz
desenvolvidas nas
processos
Regiões
Departamentos, a serem unificadas posteriormente;
D - A estratégia de software.
Considerando:
X
e
a. que os Gerenciadores de Banco de Dados e os produtos a
eles associados contribuem para aumentar a produtividade
99
do desenvolvimento e manutenção de sistemas;
b. que os Gerenciadores de Banco de Dados facl I Itam a
Implantação de um modelo de dados concebido com base em
uma visão Integrada;
c. a necessidade de desenvolver simultaneamente sistemas para
suporte da produção, para manipulação de
controle e para apolo à decisão;
Recomenda-se:
Informações de
a. que, no processo de seleção e aquisição de software de
gerência de banco de dados, sejam considerados,
simultaneamente, os seguintes requisitos:
a.1 que o fabricante/fornecedor seja capaz de oferecer
suporte técnico eficiente, Incluindo treinamento,
manutenção, documentação etc.
a.2 que através do uso conveniente dos meios de
teleprocessamento disponíveis, o dado seja disponível
quando e onde for necessário;
a.3 que o software gerenciador, IncluindO a linguagem de
definição, manipulação e controle de dados, seja o mesmo,
qualquer que seja o hardware (micros, supermicros, minis
e malnframes), de forma a que se possa assegurar a
portabilidade necessária a uma rede construída com
equipamentos de capacidade diversificada;
a.4 que seja permitido o desenvolvimento de aplicações de
100
forma flexível, sem restrições quanto a acessos
pré-estabel eel dos de modo a possi blll tar aos usuár I os
finais quaisquer manipulações sobre 05 dados disponíveis;
a.5 que o gerenciador garanta performance adequada a cada
aplicação, principalmente aquelas destinadas ao suporte
dos processos de produção (on-II ne);
a.6 que a relação custo/benefício, Incorporada aos processos
de desenvolvimento/produção, seja adequada às
necessidades da empresa;
a.7 que o software apresente ferramentas adequadas à
comunicação entre processos, estejam esses no mesmo
ambiente ou em ambientes diferentes,
posslbl I idade de comunicão com a RENPAC, e
fac II idades;
incluindo
outras
a.8 que a escolha do SGBD seja estabelecida através de um
comitê, para Isto especialmente formado, composto por
representantes das diversas áreas Interessadas, sob
coordenação do Departamento de Processamento de Dados. 05
critérios de seleção deverão Incorporar:
a.9 testes com aplicações-piloto representativas do conjunto
de aplicações que suportam os processos produtivos e de
a p o I o à d e c I são, I de n t I f I c a dos p e I a a p I I c a ç ã o da BS P ;
a.10 as demais exigências estabelecidas pelos Itens
101.
anteriormente mencionados.
b. que se considere o uso de linguagens de quarta geração
compatíveis com o SGBD escolhido, para
quais este uso possa refletir ganhos de
ap I i cações nas
produtividade,
dando preferência àquelas
compilada;
que apresentem estrutura
c. que haja padronização no uso das linguagens de tercel ra
geração, mantidas as características de aplicação de cada
I i nguagem, reconhecendo-se
técnico-científicas,
processos;
comerciais e
as
de
ap I i cações
controle de
d. que o software para I nter I i gação dos equ I pamentos em rede
satisfaça ao Modelo de Referência para Interconexão de
Sistemas Abertos (RM-OSI) proposto como padrão
internacional pela ISO (International 5tandard
Organ I zati on);
e. que se considere a utl I Ização de software multiusuário
para microcomputadores;
f. que s e c o n s i d e r e a u t I I i z a ç ã o de s o f twa r e p a r a r e d e I o c a I
compatível com o padrão 051-150.
E - Estratégia para desenvolvimento de rede
Considerando:
102
a. que os recursos atuais
finalidades distintas:
são disputados para três
transmissão e tratamento dos dados de bllhetadores (grandes
volumes - batch);
processamento de sistemas de apolo
características locais (on-Ilne);
à produção com
processamento de sistemas de Informações gerenciais de
Interesse geral (batch e on-Ilne);
b. que 05 recursos atuais são agrupados em diversas redes com
consideráveis restrições de Interconexão e acesso;
c. que a conf i ab I11 dade dos equ I pamentos
desgastes operacionais;
tem motivado
d. que o crescente volume do tráfego de transmissão de fitas
sugere a aquisição de equipamentos e software que
posslbl I Item maior velocidade de transmissão;
e. que a unificação das
possl blll tará a redução
diversas redes
do Investimento
provavelmente
e dos custos
operacionais (operação, manutenção e Insumos);
Recomenda-se:
l.03
a. que a diversidade de recursos em uso atualmente seja
reorganizada de modo a se estabelecer uma rede única capaz
de suportar a transmissão e tratamento dos dados de
bllhetadores, o processamento dos sistemas Integrados de
apoio à produção, o processamento de sistemas de
Informações gerenciais de Interesse geral, o que Inclui a
automação de escritório e os sistemas de apolo à decisão;
b. que o projeto da rede, tirando partido da tecnologia
dlsponfvel, seja orientado para alcançar, a médio prazo, a
seguinte estrutura (figura 4.2):
104
----- _._----~~.
MODELO OE ARQUITETURA OE REDE
TE R" I N A I S LOCAIS E DISTANTES
L OCA L 2
REN PAC
PAO l Oc A l. 4
j
LOCAL N LOCAL 3
F lO. 4.2
, O •
c. que os requisitos básicos para a construção da rede sejam:
requisitos técnicos:
elevado grau de serviço;
qualidade;
conflabllldade;
desempenho compatível com as apl icações;
proteção contra violação;
requisitos estruturais:
acesslbl I Idade plena dos terminais às CPU's;
acess i b I I Idade plena das CPU de um mesmo loca I pa ra
as unidades de disco;
crescimento modular das unidades de disco;
crescimento modular de CPU;
posslbl I Idade de conexão com a CPU da sede;
Incorporação de dispositivos de transmissão de
dados a alta velocidade;
d. que o número de miCrocomputadores (PC> Incorporados à rede
corresponda ao número de posições de gerência, como base
para o processo de automação de escritórios e para 05
sistemas de apolo à decisão;
e. que o número de nós da rede seja determinado após a
rea I I zação da aná I I se de trade-off entre os custos de
processamento (hardware, software, Infraestrutura e
manutenção> e os custos de telecomunicações.
106
Obs: Durante a realização dessa análise de
trade-off devem ser Investigados os efeitos da superposição
de diversas redes, principalmente se ocorrerem benefícios
econômicos caso se construa uma rede exclusiva para a
transmissão de dados dos bllhetadores.
F - A estratégia de desenvolvimento de hardware
Gons I derando:
a. a necessidade de restabelecer a conflabl I Idade da rede de
transmissão de dados dos bll hetadores;
b. a necessidade de expandir a capacidade de processamento
dos equipamentos que dão suporte aos
automatizam os processos de gestão;
sistemas que
c. a necessidade de explorar de forma mais eficiente a
capacidade dos microprocessadores que suportam aplicações
Isoladas;
d. a arquitetura das aplicações Identificadas pela BSP e as
di retrlzes para software e para rede explicitadas nessa
reunião;
Recomenda-se:
a. Ambiente da Rede de Transmissão de Dados dos Bllhetadores:
107
restringir a ampliação de capacidade de processamento na
tecnologia atual se a ampl iação for determinada por
processos de gestão;
se ocorrer aumento de
necess i dade de transmi ti r
fOlgas de capacidade
capacidade determinada
dados de bll hetadores,
de processamento, que
manifestarem em decorrência da diferença entre
tecnicamente necessário, deverão
pela
as
se
o
ser acréscimo
utilizadas
ambientes;
com ap I i cações existentes em outros
só serão admitidos recursos complementares (terminais)
para apll cações exl stentes em outros ambi entes, e no
caso de haver
processamento.
b. Ambiente Micro - PC:
di spon I blll dade de capacidade de
I imitar a ampliação do número de equipamentos ao número
de posições de gerência Identificadas pelo projeto do
novo ambiente;
o I Imite estabelecido acima só poderá ser ultrapassado
quando ocorrer a oportunidade de fazer uso de aplicações
já desenvolvidas;
a necessidade de micros de 8 bits, utilizados para
processamento de textos, deverá ser satisfeita pela
aquisição de terminais não Inteligentes acoplados ao PC.
1013
c. Amb I ente do Equ I pamento Centra I:
r e s t r I n g I r o c r e s c I me n t o do n ú me r o
fabricante específico, haja vista a
de terminais
Possibilidade
do
de
estabelecer o acessso através do equipamento selecionado
para os nós da rede:
quando for Inadiável o acréscimo de um terminal, deverá
ser privilegiado o acesso através de um
acoplado a um micro PC disponível.
d. Geral:
terminal
que sei a rea II zado o processo de I dentl f i cação e se I eção
de equipamentos para orientar a realização dos
Investimentos que assegurem a Implementação das
diretrizes para o software e para a rede:
que os Investimentos sejam realizados progressivamente
de modo a garantir a transmissão de dados dos
bll hetadores e a Implantação das ap II cações
identificadas pela BSP, com o mínimo de ociosidade de
recursos de hardware, software e telecomunicações.
C. Conduta para o desenvo I v Imento das ap II cações
Considerando:
que as ap II cações ex I stentes estão comprometi das com v I sões
específicas, de um particular usuário, sem apresentar
potencial para integração com outras aplicações:
109
que as ap I I cações ex Istentes, com poucas exceções, foram
desenvolvidas com I inguagens que não possibilitam a
transposl ção ou conversão das ap I I cações
equ I pamentos (I I nguagens· propr I etár I as ou
para uso específico na empresa);
para outros
desenvolvidas
que a arquitetura de aplicações, os processos e classes de
dados Identificados pela BSP constituem excelente
referência para o desenvolvimento de sistemas Integrados;
a necessidade de liberar anal istas e programadores para
desenvolvimento de sistemas Integrados.
Recomenda-se:
a. restr I ng I r o esforço de desenvo I v I mento de ap I I cações, nos
moldes das práticas anteriores ao processo da BSP, aos
sistemas em fase de conclusão;
b. atribuir a equipes específicas a responsabilidade pelo
desenvolvimento de cada um dos módulos componentes da
arquitetura de sistemas Identificada pela BSP;
c. adotar, durante a fase de proJeto lógico, métodos
adequados ao desenvolvimento de Diagramas de Fluxo de
Dados e do Modelo de Dados dos Sistemas IntegradOS;
d. adotar como mecanismo de Integração a reunião sistemática
H0
entre os coordenadores das equipes de desenvolvimento de
modo a assegurar a Integração dos conceitos, dos processos
e do modelo de dados;
e. assegurar que um único projeto conceituai
diversidade dos serviços da empresa;
satisfaça a
f. que o desdobramento dos processos em outros de menor
n í ve I, seJ a rea II zado ao ponto em que se assegure que a
recomblnação desses processos elementares possa ser
real izada de modo a satisfazer à diversidade dos ambientes
operacionais.
H - A conduta para implantação de Administração de Dados
Considerando:
a. a determl nação de desenvol ver um ambi ente de apll cações
integradas;
b. a determinação de fazer uso de SGBD;
c. a necessidade de manter a Integridade do modelo de dados
dessas ap I i cações;
Recomenda-se:
a. Instituir uma estrutura para Administração de Dados,
iH
subordinada ao órgão Central de Processamento de Dados;
b. estabelecer, via treinamento, a unificação de conceitos
sobre modelagem de dados;
c. estabe I ecer, via treinamento, a unificação
conhecimentos sobre administração de dados;
d. estabe I ecer, via treinamento, a unificação
conhecimentos sobre gerência de bancos de dados.
G, I - TranSição de ambientes e conduta para tratamento
altos volumes de transmissão dos dados
bll hetadores
Incluídas nos outros ítens.
As diretrizes estabelecidas através
recomendações enunciadas nessa I I I REGOR determinam
de
de
dos
dos
das
as
condições de contorno dos objetivos e estratégias que
constituem as decisões estratégicas do Planejamento da função
de SI. A partir dessas diretrizes o processo de planejamento
evoluiu para o aprimoramento da arquitetura dos sistemas de
Informação e para a Identificação e seleção dos componentes
de software e hardware que poss I blll tar I am constru I r as
alternativas de solução a serem apreciadas pela Diretoria.
A dinâmica de trabalho continuou sendo a decisão
coletiva; a composição das equipes, entretanto, foi alterada
de modo a privilegiar a participação (e a Influência sobre a
decisão) de especial istas relacionados com o componente
t é c n I c o s u bme t I d o à a vai I a ç ã o .
Para acelerar o processo decisório, as reuniões
passaram a ser realizadas em paralelo. Ao grupo de
coordenação ficou reservado o papel de Integrar todos os
resu I tados.
4.4.2 Decisões Complementares
Ainda durante a
seguintes atividades:
I I I RECOR foram programadas as
Especificação dos requisitos técnicos para SGBD, elaboração
de procedimentos de aval iação para SGBD, sei eção do SGBD a
ser utlll zado pe I a empresa - atl v I dade a ser rea II zada por
um grupo de especialistas sob coordenação do Departamento
de Processamento de Dados da Sede.
unificação das propostas para Arquitetura de Aplicações,
resu I tantes da ap I i cação da BSP no amb I ente das Regi ões e
Departamentos da Sede - atividade a ser realizada por um
grupo de gerentes usuários (usuários) e gerentes técnicos
(ana I I stas) representantes das v I sões das
Departamentos.
Regiões e
Treinamento orientado para Administração de Dados, Banco de
Dados e Modelagem de Dados, atividade a ser conduzida por
especialistas dO Departamento de Processamento de Dados da
Sede e a ser assistida por usuários e analistas que
constituirão as equipes de desenvolvimento dos sistemas
identificados pela BSP.
Designação das equipes e Início do ciclo de desenvolvimento
- atividade a ser realizada por equipes constituídas por um
gerente usuário, um gerente técnico (analista), analistas e
usuários com experiência no sistema atribuído à equipe.
Elaboração das alternativas de projeto final a ser
rea I i zada pe lo grupo de coordenação,
espec I a listas e/ou fabricante de
assistido
equipamentos.
por
As
alternativas de proJeto final estão descritas no Item Q.5.
Os resultados dessas atividades foram apresentados
e avaliados pelo G.G. nas IV, V e VI REGOR, e, estão
descritos a seguir.
Q.Q.2.1 - Unificação das Propostas para
Ap I I cações
Arquitetura de
A un i f i cação das propostas fo i rea I I zada em uma
REGOR com a participação de representantes (gerentes
usuários) de todos os Departamentos da Sede e das Regiões da
~rea de Operações.
o processo de unificação foi realizado a partir da
experiência adquirida nos exercícios de treinamento para
aplicação da BSP, nas reuniões para apresentação da BSP e no
treinamento e exercícios realizados no ambiente de cada
Departamento/Região. O exercício promoveu o amadurecimento
dos profissionais envolvidos com a atividade possibl I Itando a
explicitação da matriz Processos X Classes de Dados
apresentada no Apêndice I I I.
Essa matriz define a macro-arquitetura dos sistemas
de Informação e determina o objetivo da Informatização dos
processos de gestão.
Além da matriz acumUlou-se multa Informação com
relação aos processos e aos dados operados nas atividades da
empresa; essas Informações constltulram um acervo Importante
para utl I Ização durante a etapa de desenvolvimento.
A única alteração produzida nessa matriz, ainda
antes do Início da etapa de desenvolvimento, foi a Introdução
de um módulo relacionado com a administração de serviços de
apolo.
o fato de não ter havido nenhuma alteração na
estrutura do resultado explicitado na matriz, durante todo o
processo de desenvolvimento, contribuiu para aumentar a
confiança do G.C. na metodologia.
1.15
Outros resultados Importantes foram:
o enriquecimento do conhecimento dos usuários a respeito
dos objetivos e estratégias empresariais;
a identificação de oportunidades de uso de sistemas de
Informação como Instrumento de exacerbação de vantagens
competitivas;
a Identificação dos principais grupos reivindicantes e seus
objetivos;
o comprometimento dOS participantes com 05
Identificados pela metodologia;
objetivos
a atribuição de responsabl I Idade de desenvolvimento dos
sistemas Identificados às Regiões e Departamentos;
~.~.2.2 Outras Decisões
As decisões relacionadas com a seleção de SGBD,
treinamento orientado para administração de dados, banco de
dados e modelagem de dados; e, com a organização das equipes
e diretrizes para elaboração do projeto lógico,
descritas no Apêndice IV.
1i6
estão
4.5 Alternativas de Projeto
Estabelecidos os objetivos e as diretrizes para o
projeto, foi Iniciado o proJeto lógico. O desenvolvimento do
projeto lógico permitiu estabelecer a expectativa do volume
de transações a ser suportado pela rede de computadores.
Nesse caso, adotou-se um método para real Izar a proJeção da
capacidade de equipamentos, que considerou,
resultados medidos nos sistemas em operação.
como base, os
A estrutura do proJeto de alternativas,
pelo G.C., obedeceu ao seguinte esquema:
1 - Modelo Geral dos Sistemas;
definida
2 - Postos de Trabalho por Ambiente
Terminais;
Quantificação de
3 - Quadro de relação entre quantidade de terminais e
quantidade de transações em processamento simultâneo;
4 - Determinação do nível ótimo de descentral ização da rede;
5 - Quantificação das alternativas tecnológicas;
6 - Comparação dos custos de desenvolvimento ambiente SGBD X
ambiente convencionai;
117
7 - Expectativas de Ganhos e Custos;
8 - Determinação de Prioridades;
9 - Análise de Risco do ProJeto;
10 - Composição das Equipes;
11 - Resumo das decisões e providências necessárias.
Descrevemos no Apêndice V os principais resultados
alcançados pelo projeto.
118
CAPÍTULO 5
RESULTADOS
119
"Não podemos mais dizer que o mundo é de um Jeito ou de
outro. Podemos apenas dizer que nossa eKperlêncla até o
momento é melhor representada por um mundo dêste tipo, e que
não sabemos o padrão que melhor representará o mundo de
amanhã, mas temos certeza de que ele coordenará uma eKtensão
maior de conhecimento do que o atual."
(Herbert Dingle)
120
Neste capítulo, com base nos conceitos
Identificados na revisão de I iteratura Iremos desenvolver um
Modelo de Referência para Planejamento da Função de SI. Em
seguida, o modelo de referência derivado da revisão de
literatura será generalizado para poder ser utilizado como
referencial de análise de qualquer estrutura de Planejamento
d a F u n ç ã o de SI. Da n d o p r o s s e 9 u I me n t o à a n á I I se de
resultados, o modelo de referência foi submetido a um
processo de va I I dação obj eti vando estabe I ecer Indícios da
universalidade do referencial. Concluindo, procedemos a uma
ava I i ação da metodo I og i a BSP e desenvolvemos algumas
considerações a respeito do alcance do referencial.
5.1 Modelo de Referência para Planejamento da Função de SI
5.1.1 Modelo de Referência Derivado da Revisão de literatura
Conforme o mencionado no Capítulo 3, nossa revisão
de literatura foi orientada para proporcionar os argumentos
necessários à dedução de um referencial que se constituísse
como padrão de medida do alcance de uma metodologia de
Planejamento da Função de SI.
Nossa argumentação se baseia no seguinte 51 1091smo:
a. o modelo de Anthony [Anthony, 1965),
Eln-Dor e Segev, atende às necessidades
modificado por
do Planejamento
Corporativo, logo é um modelo adequado para descrever o
121
modelo de operar as decisões que orientam a utl I ização
mais eficaz dos recursos da empresa:
b. os dados e as estruturas que transformam os dados em
Informações são recursos da empresa:
c. logo o modelo de Anthony é adequado para orientar o
Planejamento da Função de Sistemas de Informação.
Esta conclusão nos conduz ao modelo representado na
figura 5.1.
122
o MODELO DE ANTHONY E O PLANEJAMENTO
DA FUNC,",O
r---------------------------------------I 1 1
PLAHEJAllENTO -
ESTRIlTEG ICO
\ I
CONTROlE
<iEREHCIAL
\ I
\ CONTROlE ---j, DE
0PERAÇllES
\ I
\
----i OPERAÇ8ES ,
CONT AS I LlDADE
F IIIAHCE 11M
5
I
5
I T
\ E
M
A I
5 \
D
I E
\
I
N
I F
\ O
R
M I
A \
ç
P,
O
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
·1 1 I
\ " 1
,J : 1 1 1 1 1
5 15TEMA DE PLANEJAMENTO
E CONTROLE CORPORAT I VO
Fonte: Ar,thony, 1965.
figo 5.1
123
DE SI
r---------------------------------------1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
5 O B R
PLAHEJAI1EHTO E - - 5
ESTRIlTEGICO I M 5 A T N E I M P
CO/ITROlE A U --i - 5 L
GERENCIAL A O ç E ;a;
O I
\ CONTROlE N D
/ DE ~ F E OPERAÇUES O
R I M N A F ç O
, ;a; R 0PERAÇllES I-- O M
I A ç ;e; O
PLANEJAMENTO DA
FUNç;a;O DE SI
A observação desse modelo nos conduz ao seguinte:
a estrutura do Planejamento da Função de SI é Idêntica à
estrutura do Sistema de Planejamento Corporativo,
se o Planejamento da Função de SI se ajustar perfeitamente
às pol ítlcas, objetivos e metas do Planejamento
Corporativo, então os resultados obtidos no processo de
Planejamento da Função de SI apolam perfeitamente o Sistema
de Planejamento Corporativo,
assim como ao Sistema de Planejamento Corporativo
associa-se uma dimensão correspondente a técnicas de tomada
de decisão, ao Planejamento da Função de SI associa-se uma
dimensão correspondente a metodologias e técnicas de apoio
à decisão relativas à utl I Ização da tecnologia da
Informação,
a estrutura de Manipulação da Informação do Planejamento da
Função de SI opera processos e dados específlcamente
relacionados com a tecnologia de tratamento de Informações.
Em resumo. se o Planejamento da Função de SI se
ajusta perfeitamente aos objetivos da Corporação, e se
recorrermos à representação dO sistema de relações proposto
por King (King, 1978), generalizada como o estabelecido no
item 2.1.4, podemos desenhar os dois sistemas conforme o
proposto na figura 5.2.
124
o MODELO DE KING (ADAPTADO)
E O PLANEJAMENTO DA FUNC~O DE SI
5 11 O A B H R nODELOS PARA I E \ P ELABORAR E SELE-U S L I CIOHAR ALTERNATI A 5 C TUAS DE SISTEI1AS 11 E O 11 DE IHFOR"ACIIO
A
//l D S A
D I E / N / F I / O H / R F 1'1 O A R C 11 11 A O C
iI O
PLANEJAMENTO
DA FUNÇ;2\O DE S I
Fonte: King, 1978.
S I
D S E T C E I 1'1 11 5 A A õ H 5 E I S P D
U E S L I A I 5 C N T 11 F E O O 1'1 R A D 11 5 A A
C D I iI E N O
F I O C H R O F 11 R O A P R C O " 11 R A O A C T 11 I O U
O 5
I
I / 110D@lOS
I I DE TO"ADA
I DE DECI5i10
D E C
DE5ICõES\ I
HilO \}\ ~ PROGRI1AI'IDAS E
5 DECI5õES
C ORPORATIU05 PROGRAI1ADAS C O R P
I
1/ I
I
/ I
I I
I I
l/ 2 T I U A 5
/
PLANEJAMENTO
CORPORATIVO
Fig. 5.2
125
Observemos que os espaços das Informações e das
decisões são domínios cujos elementos se relacionam através
de mecanismos selecionados para a Implementação da tomada de
decisão (seja para formulação de sistemas, seja para a
decisão propriamente dita).
Para obter a configuração global do modelo de
referência que propuzemos deduzi r, Introduzi remos na relação
descrita acima uma dimensão associada às categorias de
decisão propostas por Anthony. Da associação destes conceitos
resulta a estrutura representada na figura 5.3.
ESTRUTURA SIMPLIFICADA 00 REFERENCIAL PARA PLANEJAMENTO DA FUNCAO DE SI
Planejamento Estratégico
Controle Gerenciai
Controle de Operações
Operações
INSUMO PROCESSO PRODUTO
flg. 5.3
Para aumentar a precisão do modelo que estamos
propondo, devemos Introduzir um mecanismo de recorrência
entre as diferentes categorias de decisão, conforme o
sugerido pelo modelo de Anthony. Desse modo, o modelo de
referência que estamos propondo exprime uma relação reflexiva
configurada conforme o representado na figura 5.4.
126
/ /
\ \
RELAC~O REFLEXIUA DO REFERENCIAL PARA
PLANEJAMENTO DA FUNC~O DE SI
, J\ , / \ \
/ \ S / \ " O
11 B IIODELOS / H R
\ / I E
1/ / PARA P U S L I A 5
ELABORAR C T li E O 11
E SELECIONAR / A \ / D S , I A
ALTERNAT lUAS D I E H
DE SISTEMAS F I O H R F
\ DE \
\ IHFORMAClIO
11 O 11 R C " \ li A
\ O ç \ li
\ / O , I
S I S T E
li 11 11 11 H S I P D U E L 11 I ç H li F O O
R D 11 A A
ç I li N O F O C R O 11 R A P C O li R O A
T I U O S
D E
,~------""" C / DECISõES\ I
/ NilO \ \ 6 / IIOD~LOS \ J\ S
/ DE TOMADA PROGRAIIADAS \ E
/
DE DECISKO DECISõES
CORPORATIVOS PROGRAIIADAS
/ /
/ /
/
/ /
/ /
/
;'
5
C O R
ll/ i T I U 11 5
Fonte: Kin9 1878 e Anthony 1865
f i9. 5.4
121
Assim sendo, a configuração global do modelo de
referência é representada pela estrutura descrita na figura
5.5.
ESTRUTURA DO REFERENCIAL PARA PLANEJAMENTO DA FUNClO DE SI
Planejamento Informações Estratégico do Ambiente e ( 1 )
III n " N P. a fi r. i n s
Controle Gerenciai ( 1 ) (2 )
Controle de
Operações ( 1 ) (2 ) ( 3 )
Operações ( 1 ) (2) (3 ) ('I )
INSUMO PROCESSO PRODUTO
flg. 5.5
Os elementos pertencentes a cada subconjunto dessa
estrutura serão representados de forma resumida, isto é,
mencionaremos apenas o nome da classe a que pertence e o
elemento; a menção específica de métodos ou técnicas ocorre
excepcionalmente, quando os mesmos são citados freqüentemente
na literatura.
Os elementos representados no modela de referência
foram identificados nos textos utl I Izados durante a revisão
de II teratura.
128
A figura 5.6 e o quadro 5.1,
exp I I c i tam nossa proposta de mode lo de
a seguir, que
referência para
Planejamento da Função de SI, são dois modos de representar
as mesmas relações entre informações, processos e categorias
de decisão de planejamento. A primeira figura representa
estas relações na forma
(I nsumo - processo
conforme mencionamos
de um espaço de duas
produto x categorias de
anteriormente. A segunda
dimensões
decisão),
figura
representa estas relações na forma de um espaço de duas
dimensões (processo x Insumo = produto = classe de dado), no
qual se representa a Informação (ões) que utilizada (s) por
um processo (esta Informação utlll zada é si nall zada por U)
cr I a uma nova Informação (esta Informação cr I ada é s I na II zada
por C); esta segunda representação será designada por: matriz
processos x classes de dados.
129
O O -~ 'li f-q [( f-\11 UI
O f-Z UI r ~ l UI Z q J ~
J ~ -l) Z UI f( UI ~
UI J O [( f-Z 0 O
tn UI UI J I) OU ~
~ O ~ l) O
\11 IUI lUll ~U 00
[(
REFERENCIAL PARA PLANE~AMENTO DA FUNÇí"líO DE SI
(LITERATURA) INSUI10 PROCESSO PRODUTO
· Mis~ Metodologias para elabora.;:lo de · Aval ia.;:lo das estra-· Pol iticas 1>01 itica e estrategia empresarial tegias e.oI;iietivos · Ut:etr:- i Ze$ ~~icQI9 Bethlem !gor Ansoff) ~Wclals · fe IVOS · s rategla con-pet i Iva (Michàel · I deht i I ca.;:lo dos pr i n-· Me as Poder) cipais grupos reivindi-
(da empresa) · Método prÕp!" io cantes e seus objet i vos
Anãl ise da cadeia de valores · I dent i f i ca.;:lo das ~ter e Mi I lar) apor tlB1 i dades de uso
I ise dos fatores cr it icos de sistemas de i nforll\al;:lo sucesso (Rockart) par a i ncorpor a.;:lo de Método prÕp!"io vantagens compet i t i vas
QJ · Anãl ise dos fatores cr it icos de Aval i a.;llo das neces-sucesso (Rockart) s i dades e i nf orll\al;:lo
+ Or~iZa.;:lo e · Anãl ise do c ic lo de vida de pro- da elfl'(m:
dutos e rectrsos . Arquite tra global me odos vigentes · Métodos de previ~ dos sistemas de na empresa · Têcnicas de O & M i n f orll\al;llo
· Método prõpr i o
· Metodologia para elabora.;llo de · Ajuste da mis~ [TI [2] ~I itica e estratégia emesaria' da ãrea de sistemas · êcnicas de previSllo recursos, i n f orll\al;llo
beneficios, custos, prazos)
[TI [2] ~ · Anã I ise financeira
Anã I ise de riscos (McFar lan) · ~uste de pai iticas, Anãl ise de pr ior idades (Norberto jetivos, dire-
+ I n f orll\al;Õe5 sobre: Torres) tr I zes e metas da hardware, so ftl.lat"e , Método prõpr i o ãrea de sistemas te I ecDmlB1 i Ca.;Õe5 de i n f orll\al;:lo
~ Método de aval i a.;:lo de projetos · Plano mestre de
+ (McFarlan) ~Ivimento · I ano de ai oca.;:lo de
· Métodos de gerª"" i a de projetos CtrSOS I n f orll\al;Õe5 sobre ~arlan) · Pessoal
· hmark · Treinanento · Har~e · T~tes de Capaçidade · Softl.lat"e · Sof ware · Mé odos de projl1Ç::lo de trãfego ~e · Te lecDmlB1 i ca.;13es · Têcnicas de projeto de rede · Capar;: i ta.;:lo do · Têcnicas de programa.;:lo de CtrSOS : Te I ecomun i Ca.;Õe5
pessoal · Anãl ise financeira -· Infraestruttra
· Têcnicas de~ojeto de segurança ~ P I ano de segurança de instala.;
· Métodos segurança fisica de arqs. fisica e làgica + Restri~Õe5 de Acesso · Métodos segurança làgica de arqs.
0 · Métodos de aud i tagem Plano de auditagem
· Têcnicas de documenta.;llo cQ!fPati- P I ano de documenta-[I] 0 veis com os metodos selec ionados ~:lo e normas · Software de apoio (CASE)
~ 0 0 · Métodos de gerênc i a de · Programa de a.;13es e
reojetos resPonsab i I idades · êcn i ca de or~amenta.;llo _ Or~amento
Se I e,::lo de:
~ QJ Têcnlcas de modelagem de proces-
· Plano de desenvolvi-sos e da:los · Métodos de gerênc ia de projetos mento de sistemas · Têcnicas de O & M
m [TI ~ Têcnicas de projeto de arquivo
· T êcn i cas de progr ama;::lo · Softl.lat"e de apoiO
0 0 ~ QD · Têcnicas de programa;::lo da pr~llo · ~~_:lo da pro-
+ Documenta.;::lo 5 i s temas Têcnicas de O & M
Treinamento dos aperadores · Providenciar ajustes
em equ i pama:>tos
m ~ · Recusar so I i c i ta.;13es incorretas
· Bloquear ocessos nllo autor i zados ... etc
flg. 5.6
130
f{)
~
=f>
f{)
~
=f>
=f>
f{)
~ ~
~
=f>
REFERENCIRL PRRR PLRNEJR"ENTO DR FUNÇÃO DE SI (LITERRTURR)
CLASSES DE DADOS
PROCESSOS
_ Metodologia plelaboraç~o de politica e estrategia empresarial (~iricOla Bethlen, Igor ~nsoff)
_ Estrategia compeli iva (Nichael Porter) · Metodo próprio · ~nãlise da cadeia de valores (Porter e Millar) · Análise fatores criticos de sucesso (RocKart) · Metodo próprio
'~ ::l ~ z " ~ o z ~
g: i~
I ... ~
~~ ~f ~;
~ . . ...
c
U
I; :g r~ ~ ;;1 ~
~ g il!il! ~
II li ,I; :111 '11 il! ~
.~ i i~ 'I~ ~;~
! Ili ' !~I ,i i ~ . - . . .
c
· ~nªlise fatores criticos de sucesso (RocKart) · Analise do ciclo de vida de produtos e recursos U · Metodos de previs~o; . Têcnicas de O ~ M
c · Metodo próprio
· Metodol09ia para elabora.~o de politica e es\rategia empresarial
· Tecnicas de previs~o (recursos, beneficios, custos, prazos)
· Anãlise Financeira · Anãlise de riscos (McFarlan) · Anãlise de prioridades (Horberto Torres) · Método próprio · Melodo de aval ia.~o de projetos (McFarlan)
· Método de ger~ncia de projetos (McFarlan) · eenchmarK · Testes de capacidade · Metodos de projeç~o d. trafego · Tecnicas de projeto d. rede · Tecnicas de programaç~o de cursos · Anãlise financeira
1fi~~~r:de projeto d. segurança de instalaçÕes d. segurança fisica de arquivos · de segurança lógica de arquivos
· Metodos de audi\agel
· Metodos de ger~ncia d. projetos · Tecnica de orçamentaç~o
· Tecnicas de modelagem de processos e dados · Melodos de ger~ncia d. projetos · Tecnicas de O ~ M; . Tecnicas projeto arquivo · Tecnicas programaç~o; . Software de apoio
· T~cnicas de progra.aç~o da produç~o · Tecnlcas de O ~ M
· Treinamento dos operadores
~) U U C
:{> U UUC
UIC
U
lU
Quadro 5.1
131
'" ... o u
"
I ! u
Z e ... " ~fi ~ ~u ~ ... ~~
~ ~ =1..,
iil! .. ~I~ I'"
li o ~ ~
i:i cii oz
.~ Iil! I~ "'-:::~~ :::
r' ! :~ I~ . ;;: ~
: = U
u- Classe de dados e insuM do ru.o"u C- Classe de dados e produto do
C
U.
U
U
U
C
'U IC
lu IC
lu lu lu C
lu lu lU U C
, ,
lU
, 'I
U
U
U
mmOLE GERERCIIL
comou DE OPEBaç8ES
11
'u lu U U C lU 11
U ui C lU'
U
Na coluna produto da primei ra representação (classe
de dados na segunda representação) reproduzimos os mesmos
elementos que constituem a estrutura de decisões para
sistemas de informação mencionada no Item 2.1.6 da revisão de
literatura.
Na coluna processo (comum às duas representações)
reproduzimos os métodos elou técnicas elou mecanismos elou
modelos de apolo à tomada de decisão, mencionados nos Itens
2.1.6 e 2.2 da revisão de literatura.
A coluna insumo da primeira representação Inclui a
realimentação dos resultados registrados na coluna produto
acrescida de Informações sobre o ambiente e os negócios da
empresa que, também, foram Incluídas na dimensão classe de
dados da segunda representação.
Os instrumentos específicoS mencionados no
referencial foram transcritos das citações incluídas na
revisão de literatura, e servem, apenas, para II ustrar os
recursos descritos na I iteratura ou em documentos editados
por fornecedores de produtos para planejamento e
desenvolvimento de sistemas.
e Importante observar que durante todo o processo
de planejamento, a Identificação e seleção das Informações,
processos e produtos de planejamento a serem considerados no
desenVOlvimento das atividades de planejamento, refletem o
132
estilo conjunto dos gerentes, pois os mesmos utilizarão a
cada passo o(s) Instrumento(s) que estabeleça(m) o melhor
ajuste da sua decisão (expectativa e risco)
Para simplificar a anál ise dos resultados e o
desenvolvimento das conclusões faremos uso, apenas, da matriz
processos x classes de dados, motivo pelo qual
mais mensão à primeira forma de representação.
5. 1 .2 Mo d e I o d e R e f e r ê n c I a G e n e r a I I z a d o
não faremos
A fim de posslbi I Itar o uso do modelo de referência
de Planejamento da Função de 51, derivado da I iteratura, como
referencial para análise de qualquer estrutura de Informação,
processo e produto, desenvolvida por fornecedores de Sistemas
ou por agentes de Planejamento da Função de 51 para
Implementação durante a elaboração de um Plano de Uti I Ização
da Tecnologia da Informação, é Indispensável transformar o
modelo de referência derivado da I iteratura em um modelo de
referênc I a genera II zado.
Nossa proposta de referenc I a I genera I i zado I nc I u I rã
três novas colunas, associadas aos processos, de modo a
permitir a Identificação do tipo de instrumento ut I I i zado
durante a elaboração de um Plano, conforme o
classificação proposto por Karlml (Hackathorn et
métodologla (M), técnica (T) e ferramenta (F).
critério de
al,1988):
O quadro 5.2 representa o Modelo de Referencial
Generalizado para Planejamento da Função de 51.
133
REFERENCIAL 6ENERALIZADO PARA PLANEdA"ENTO DA FUNC~O DE SI
CATHOm DO
IRSmnmO
CLASSE DE DADOS
· Ana I i sar = LEGENDA = C U estratégia
empresarial
· Analisar oportunidades para sistelas de inforla~~o
· Analisar necessidades a nivel de empresa
· Elaborar estratégia para sistemas de informa~~o
· Definir pro jetos
· Alocar recursos
· Projetar seguran~a
· Projetar audl \agem
· Projetar documenta~~o
· Planejar a~lles
· Or~ar
· Organizar ~rojetos lõgico e flsico
U
U
C
C
u u rc u u lu C
u C
U
U
U- Classe de dados é insumo do processo C- Classe de dados é produto do processo n- Metodologia T- Técnica f- Ferralenta
A PLAHEJanmO 'I ESTRATÉGICO
u
U
C U
u IC • COHTR~LE " 6E8EI lU
U .C U
U U C
U lU lu lu Ic COMTROLE DE OpmCSES
U lu lu lu lu Ic ,
u lu lu lu lu lu Ic \f
lU
· Protlraltar proau~~o lU lu lu C U OPERaçm
· Treinar operadores
Quadro 5.2
134
iU Ui C U'
Um referencial assim constituído não oferecerá
qualquer Indicação da precisão dos produtos resultantes da
Implementação de qualquer Sistema de Planejamento da Função
de SI; entretanto oferece um roteiro completo para orientar a
Identificação dos Instrumentos uti I izados para suporte de
cada processo, a categoria dos Instrumentos, os resultados
proporcionados pelos mesmos, e, se os processos (a serem)
implementados durante a elaboração do Planejamento da Função
de SI reproduzem, completamente, os procedimentos e
resultados Identificados no Modelo de Referência
Generalizado.
Observamos, ainda, que:
a. um Instumento específico pode contribuir para mais de uma
categoria de processo e/ou para produzir mais de uma
categoria de resultado; estas contribuições deverão ser
evidenciadas associando-se o instrumento específico às
diferentes categorias de processo e de resultado para as
quais tiver contribuídO;
b. um processo pode recorrer a Instrumento(s) que
corresponda(m) a uma ou mais das categorias propostas por
Karlml (Hackathorn et ai, 1988), este fato deverá ser
assinalado nessas diferentes categorias.
135
5.2 validação do Referencial
Para validação do referencial, recorremos a empresa
de Telecomunicações S.A., pois a mesma se constitui em uma
unidade de anál ise cuja complexidade determina a utilização
de um amplo espectro de Instrumentos de planejamento.
A operaclonallzação da validação foi
seguinte modo:
rea I I zada do
1 - Identificação, com base na descrição do caso, dos
resultados específiCOS alcançados durante o processo de
planejamento empreendido na Telecomunicações S.A.;
2 - identificação, com base na descrição do caso, dos
instrumentos específiCOS utl I Izados para dar suporte aos
processos de planejamento e desenvolvimento considerados
pela Telecomunicações S.A.;
3 - associação dos resultados específiCOS alcançados e dos
Instrumentos específiCOS utilizados, respectivamente, as
categorias de classes de dados e de processos propostas
n o mo d e I o d e r e f e r ê n c I a g e n e r a I I z a do;
4 - representação gráfica das associações identificadas no
processo desenvolvido pela empresa, na forma da matriz
processos x classes de dados, conforme quadro 5.3.
136
TELECOHUMICAÇ6ES S.R. PLRMEdRHEMTO DR FUMe.O DE SI
CATEGORIA DO
IMSTRUnEMTO
PROCESSOS
CLASSES
DE
DADOS
.Seleç~o instrumento de I ... ~Ianel·amento ,~ •
.Anal isar estrategia empresarial
. BSP [8M.1984l lI!iii
.Politica e estrategia de empresa [Bethlem,1981l I_li,,,,.
.Treinamento 1--
.Analisar oportunidades para siste.as de informaç~o
lIE-_-lIE
.[ B thlem,1981l .Elaborar estrate- ~ .. !T~eic ,p~evls'o(Recursost gia para sistemas !CIO~çustos,prazos} de informaç~o Ise Ilnancelra
ise risco (variação
:~~!~W· c i os ,cus tos lprazos) idades \método )
.Oefinir projetos . [ "cFarlan, 198n
.Alocar recursos
. [ NcF ar I an, 1981l (pessoa I )
.BenchmarK
.Teste capacidade
.Previs~o trãfego(mét.prõ
.Projeto de rede prio)
.PrQg~a.aç~o trejnalento
.Anallse financeira
.Projetar .Avaliação riscos relac.cl segurança segurança fisica e lógica
.Identificar controles PI .Projetar auditagem mini.inar probabilidades
de danos e perdas
.Pro jetar documentação
.Planejar ações
.Orçar
.Especificar descrição sis temas processos e dados .Seleç~o software de apoio
.Técs. gerencia de projeto
.Sele.~o tecnicas de:eode.Organizar projetos lagem de dados/processos, lógico e fisico projeto de arq., progra
oa,ão e software de apoio . [ ncF ar I an, 198n 6er~nc i a projeto
.1 ",'0.0' produção .Técnicas de O &" Treinar" ,g, T •• i
lIElI
lIElI
lu
Quadro 5.3
131
U Ic
U lu Ic U uu iu Ic U U uuule
U uuuuUIC
U U U U
,
comULE GERENCIAL
lu
c "lu UII C lU
Os elementos assinalados com x-x-x não foram
representados pois a empresa, conforme mencionado na
descrição do caso, determina, em suas pol ítlcas, tratamento
específico para a "Informática de processo". No processo de
planejamento da "Informática de processos" são consideradas
as oportunidades de desenvolvimento que convêm à estratégia
da empresa e, portanto, os elementos assinalados com x-x-x
Observando a matriz processos x classes de dados
que representa a estrutura de Planejamento da Função de SI
considerado pela Telecomunicações S.A. devemos evidenciar o
seguinte:
a. alguns procedimentos são associados a mais de uma
categoria de processo, Isto decorre do fato destes
instrumentos Incorporarem diversos sUbprocessos orientados
para mais de uma categoria de decisão (é o caso da BSP que
comentaremos adiante);
b. os resultados, prodUZidOS pelo esforço de Planejamento da
Função de SI empreendido pela Telecomunicações S.A., são
perfeitamente compatíveiS com os prOdutos descritos nas
colunas correspondentes às classes de dados da matriz;
c. os processos considerados pela Telecomunicações S.A.,
durante o desenvolvimento do seu Planejamento da Função de
SI, foram selecionados com base em reuniões de trabalho
durante as quais eram ampl lados os conhecimentos e o
138
comprometimento dos representantes (coordenadores) dos
diversos Departamentos (equipes) com participação no
projeto a ser desenvolvido;
d. a leitura do caso permite concluir que parcela
significativa do eSforço de Planejamento fo I or I entada
para a seleção de processos (métodos, técnicas e
ferramentas).
e. a recorrência a procedimentos sugeridos pela BSP se
I imitou à conduta desenvolvida para determinar as
estratégias, os objetivos empresariais e a arquitetura
global dos sistemas de Informação.
f. a Telecomunicações S.A. durante o processo de Planejamento
não considerou a técnica de determinação de prioridades
suger I da pe I a BSP (ênfase na aná I i se do probl ema assoc lado
a um processo e nos benefícios, impactos, probabilidade de
sucesso e demanda relaclondos com esse processo). Para a
Telecomunicações S.A. os processos foram considerados como
um todo Integrado, pois as dificuldades Identificadas
decorriam da falta de articulação entre sistemas. Para
estabelecer sua estratégia recorreu a técnicas de previsão
(recursos, benefícios, custos e prazos),
financeira, de análise de risco para,
de
em
estabelecer as prioridades e as diretrizes a
observadas durante o desenvolvimento dos sistemas.
139
análise
seguida,
serem
g. da anál ise do modo pelo qual a Telecomunicações S.A.
orientou a decisão a respeito da questão relacionada com a
centra I I zação (ou descentra I i zação) da rede, resu I ta que,
nesse caso, prevalesceram todos os princípios de
engenharia, de redes de comunicação e de tráfego, que
determinam a solução ótima a parti r da especificação da
topologia da rede (em termos de concentração geográfica de
usuários), dos volumes de transações, da urgência das
i n f o r ma ç õ e s, d a ma t r I z de t r á f e 9 o, d a a c e s si b I I i da de, da
qual I dade do si stema, da conf I ablll dade, da segurança, e,
possibilitam prever os custos dos equipamentos, operação,
Infraestrutura, software, energia, comunicações etc. O
trade-off descrito no Item ~.5.~ da descrição do caso foi
determinante no sentido de orientar a decisão da empresa.
Este resultado contribui para fortalecer a hipótese
estabelecida por Lelfer (Lelfer, 1988) segundo a qual, a
determinação do nível ótimo de descentralização, "do ponto de
vista estrutural, se baseia em uma unidade de análise
definida pelos mecanismos que Influenciam as comunicações
atuais ou potenciais entre os membros da organização".
(Lelfer, 1988).
finalmente devemos evidenciar que a transposição
dos resultados (classes de dados) e dos processos utl I Izados
pela Telecomunicações S.A. para o mOdelo de referência
generalizado (matriz processos x classes de dados) ocorreu de
modo Inteiramente consistente, o que proporciona Indícios de
1~O
que os elementos representados no modelo de referência são
necessários para a realização de um Planejamento da Função de
SI completo.
5.3 Avaliação da Metodologia BSP em
Referenc I a I Proposto
Confronto com
Para solucionar nossa terceira pergunta
o
de
pesquisa, reproduzimos as quatro etapas percorridas no
processo de validação do referencial, substituindo os
Insumos, processos e produtos Identificados na descrição do
caso da Telecomunicações S.A. pelos Insumos, processos e
produtos sugeridos pela BSP. A quadro 5.q é a representação
gráfica da projeção da BSP sobre o modelo de referência
genera I i zado.
1 q 1
BSP: PLAHEJA"EHTO DA FUHC_O DE SI
\ \ v>'" '" _w " " \ \ ,,~ " ~
-'" u w \ \ " " " ~
"u ~
\ \ CLASSES "'- " w V>
w" " " w
\ \ "'''' " ~ '" ~ o. - ~ w
\ \ DE ~" " N '" W _
" « ~
\ \ w u w w
~'" " " ~ '" \ \ DADOS ~ w
e~ '" V> '" " \ \ " " .li " ~o. ~ ~ " \ \ w= ~ w V> V>
.,'" ~ .,; w w
\ , .... V> '" '" , " w "
o. o.
\ \ '" " V> " ~ ~
w- _ " w w
\ \ " V> V> ~ " " .. , " V> o. w " wU \ CATEGORIA DO \ ,,- " "
.,,, "" " _U " .. ~ ~~
\ \ .. " ~ ~ o", V> w- " "
~V> o
\ IMSTBUHEMTO \ ~'" V> .. ,~ -" " "o. V> o V>'" ~~ o
\ \ '" w ... ,,- ow ~
~V> U .. U o.~ w
\ \ v>0v> w _w '" ",,, o " " ~'" \ \ " '" w , IHI ;: V> õ! ... '" \ " O" o
Q~!!! " lo! o.'" " \ \ '" u
ou .. o :; w~ V> " PROCESSOS \ \ ",-o " "V> o N
u~ U " " ;; \ \ ,,-V> ~ "' ",V> 0-
-~= " ~ " ... \ \ ... "'w ... "''' V> W " "wv> " ='" "'., ..
"" " .,,, -" '"
CATEGORIA ESPECifICO n T F ,,_w
" ",o. ~o o
. . ..
= LEGEMDA = U- Classe de dados ê insumo do processo
.Anal i sar .ESP lfIiIOIf C C- Classe de dados é produto do processo U estratégia n- Metodologia empresarial .TREIHAnEHTO T- Técnica
F- Ferramenta
.Anal isar .BSPasugere o uso opcional RE (~ PLAMEdAHEMTO
necessidades a anãlise dos fatores U C ESTRATE6ItO U nível elpresa criticos de sucesso)
.~
.Elaborar es- .BSP ~sugere critério para tratégia pa- eterminaç30 de prio-ra sisteoas ridades co. base em lIElIE de informa- benefícios, impactos, ç~o probabilidade de su-
cesso e demanda) U C
(~ COITRn\E GE EMC AL
U
COMTROLE DE I OPEBA'8ES ,
(,
;::/õPER9ÇSES
D Quadro 5.4
142
Para compreender a transposição da metodologia BSP
sobre a matriz processos x classes de dados, é Importante
ana II sar o conj unto de proced Imentos suger i dos pe I a
metodologia BSP.
Dentre estes procedimentos
seguintes:
Estabelecer condições para o estudo
conquistar o envolvimento dos gerentes,
ambiente o cronograma de trabalho .
destacam-se os
que compreende:
preparar equipes,
. Anal isar Objetivos e Ambiente da Corporação.
Identificar os Processos Corporativos, Isto é,
logicamente relacionados de decisões e
os grupos
atividades
demandados pela administração dos recursos da corporação
a Identificação dos processos é suportada pela análise do
ciclo de vida dos recursos.
Identificar as Classes de Dados, Isto é, as categorias de
Informação a respeito de uma entidade - a Identificação das
c i asses de dados é rea li zada pe I a i nvestlgação das
Informações consideradas pelos processos identificados.
Definir Arquitetura de Informação - a definição é realizada
pela articulação entre processos e classes de dadas,
originando uma matriz processos x classes de dados.
1"13
Identificar Sistemas em Uso.
Entrevistar Gerentes tem por objetivo
resultados, Identificar problemas e
associadas com sistemas de Informação
potenciais.
· Definir achados e conClusões.
vali dar os
oportunidades
e benefícios
Dete rmi nar pr i or Idades - a determl nação é rea I i za com base
em benefícios potenciais, Impactos sobre os negócios,
probabi I Idade de sucesso e demanda associados a cada
sistema.
· Organizar Recursos de Gerência de Informação.
· Sintetizar Recomendações e Resultados.
Conhecendo-se os procedimentos Indicados pela
metodo I og I a BSP podemos ava I i ar como a BSP se comporta em
confronto com o referencial:
A - A BSP I ncu I proced I mentos para:
a. a vai I a r am b I e n te, o b j e t I vos e e s t r a t é 9 I as d a c o r p o r a ç ã o e
produz os resultados correspondentes;
144
b. estabelecer arquitetura global de sistemas de Informação
(Identificar Processos Corporativos, Identificar Classes
de Dados, Definir Arquitetura de Informações);
c. determinar prioridades (Entrevistar Gerentes,
Prioridades).
B - A BSP não I nc I u I proced Imentos para:
a. prospecção tecnológica;
b. analisar oportunidades para sistemas de informação;
Definir
c. estabelecer a missão, as diretrizes e as metas para
sistemas de Informação;
d. desenvolver Controle Gerenciai, Controle de Operações e
Treinamento de Operadores.
As principais Insuficiências da BSP estão
relacionadas com a descrição dos procedimentos (excetuando-se
os procedimentos associados à determinação da arquitetura
global de Sistemas), assim sendo, a metodologia não descreve
com clareza a conduta para Identificação de problemas e as
técnicas uti I Izadas para previsão de recursos, benefícios,
custos e prazos. Não determina a recorrência à prospecção
tecnológica, à anál ise flnancel ra ou à análise de risco. Não
menciona qualquer procedimento que suporte a formulação de
145
Controle Gerencial, Controle de Operações ou Treinamento de
Operadores.
Além das observações acima, cabe evidenciar que a
metodologia BSP pressupõe que o ambiente empresarial esteja
conceitualmente preparado para Implementação de um método de
Planejamento da Função de SI, desde que não sugere que seja
realizado treinamento com o objetivo de atualizar (ou
estabelecer) a base conceituai
Sistemas de Planejamento.
para o desenvolvimento de
O resultado da projeção da metodologia BSP sobre o
Referencial de Planejamento da Função de SI nos
concluir que a BSP satisfaz, ainda assim
insuficiente, às condições necessárias apenas
autoriza a
de forma
para o
Planejamento Estratégico de Sistemas de Informação.
Este resultado é compatível com aquele enunciado no
Relatório Técnico nQ 56 da COPPEAO (WYSk,1982) segundo o qual
a BSP é um método de Planejamento da Função de SI com alcance
circunscrito ao nível do planejamento estratégico.
Este resultado também é compatível com o resultado
explicitado em ·Um modelo para comparar métodos de engenharia
de Informação· (Hackathorn et ai, 1988), segundo o qual a BSP
é um Instrumento orientado para a análise organizacional e
para a determinação de necessidades a nível de empresa, o que
coincide com os objetivos de um planejamento estratégico.
146
As Insuficiências identificadas na metodologia BSP
não i ndUz Irão grandes desvios de resultado se os
procedimentos sugeridos pela metodologia forem complementados
por outros Instrumentos sugeridos neste texto, ou
Identificados através de pesquisa de literatura.
Observamos que o texto da BSP admite recorrência a
outras metodologlas, visto que sugere o uso opcional do
método Fatores Críticos de Sucesso (Rockart, 1982).
5.4 Outros Resultados
É importante rea II zar uma comparação entre o método
de ava II ação adotado para se I ec I onar a
Planejamento da Função de SI utl I ,zado pela
metodologia de
Telecomunicações
S.A. (ver Item 4.3) e o método proporcionado pelo modelo de
referência para Planejamento da Função de SI.
No p r I me I r o c a s o, a a vai I a ç ã o f o I procedida pela
construção de uma escala associada a diversos atributos
desejados pelos agentes de planejamento. A seguir, com base
em critérios preponderantemente subJetivos, os agentes de
planejamento atrlbulram um grau a cada atributo. Finalmente
comparou-se a soma total dos graus atribuídos a cada método,
recaindo a escolha no método que acumulou o maior número de
pontos. Este procedlmanto teve como Inconveniente a
recorrência excessiva a valores subjetivos, pois, tanto os
atributos associados aos resultados esperados (Classes de
147
Dados) quanto aqueles associados aos procedimentos
operacionais que dão suporte à obtenção de resultados não se
encontravam adequadamente conceituados o que não
proporcionava aos agentes do planejamento uma visão objetiva
desses atributos. Para superar esta dificuldade a empresa
realizou diversas reuniões de coordenação, durante as quais
foram desenvolvidos e exercitados os mecanismos de decisão
que complementaram os instrumentos oferecidos pela
metodologia BSP.
No caso do modelo de referência recorremos a uma
visão objetiva e completa de toda a estrutura do Sistema de
Planejamento da função de SI, o que oferece ao planejador a
oportunidade de pesquisar, eficiente e eficazmente, o
conjunto completo de Informações, correspondentes às classes
de dados a serem produzidas, e de procedimentos operacionais,
que suportem a obtenção destas classes de dados,
perfeitamente ajustado ao seu estl lo cognitivo. Neste caso a
decisão a respeito dO modo pelo qual deverá ser conduzido o
processo de seleção dos componentes da estrutura de
Planejamento da função de SI continuará afetada pelo estl lo
conjuntivo dos agentes (ou condutores) deste processo,
entretanto, a conceituação objetiva dos resultados a serem
alcançados e dos Instrumentos a serem utl I Izados durante a
real ização do Planejamento da Função de SI não será multo
afetada por conSiderações subjetivas desses agentes.
o modelo de referência, apesar de não oferecer uma
aval iação quantificada, permite determinar a estrutura mínima
de uma estrutura de Planejamento da função de SI, motivo pelo
qual os administradores de Sistemas de Informação devem
manter atualizadas as Informações relativas aos mecanismos
que dão suporte ao processo
mecanismos de tomada de
de elaboração
decisão, e , às
conceitual,
Informações
a05
que
caracterizam o estado da arte relacionado com a conceituação
da estrutura de classes de dados do modelo de referência do
Planejamento da Função de SI.
149
CAP~TULO 6
CONCLus6ES
150
"A mente disciplinada se de I I C I a com o que é
problemático, e trata-o com carinho, até que se encontre
solução que se torne aceita após estudada".
(John Dewey)
151
A motivação básica de nossa
percepção da necessidade de
pergunta de pesquisa
foi a se
expectativa correta do alcance de uma
Planejamento de Função de SI.
estabelecer
metodologia
a
de
Os resultados que construímos a partir da Revisão
de Literatura proporcionaram uma visão objetiva, à luz dos
conceitos de Sistema de Planejamento
por Anthony CAnthony, 1965), dos
e Controle enunciados
insumos, processos e
produtos que intervêm no Planejamento de Função de SI. Para
os que se dedicam à pesquisa sobre Sistemas de Informação,
estes resultados correspondem a uma estrutura de relações
construída com o objetivo de estabelecer
Indivíduos uma representação mental do
exterior que cor responde a um Referencial
no psiquismo dos
objeto do mundo
para Planejamento
de Função de SI, ou seja, cor responde ao conceito de Sistemas
de Planejamento de Função de SI.
Este conceito, desde que aceito pelos pesquisadores
de Sistemas de Informação, nos remeterá sempre à
representação mental do modelo de referência que denominamos
Referencial para Planejamento de Função de SI.
A aceitação deste modelo de referência possibi Ilta
determinar, com precisão, que características devem ser
ostentadas por um método de Planejamento de Função de SI que
esteja sendo submetido à Investigação.
152
Com a ut II Ização deste mode I o, não confund I remos a
ef i các I a de um método com o custo de sua ap I I cação. Não
confundiremos a eficácia de um método com as habilidades de
quem o ut i I Iza. Não confund I remos a ef i các i a de um método com
a conveniência de o mesmo ser utl Ilzado.
Resumidamente, podemos destacar os seguintes
resultados obtidos na vai Idação do modelo de referência e da
ava I i ação da metodo I og i a BSP:
a. a estrutura de decisões Identificada no estudo de caso se
ajusta à estrutura de decisões contida no referencial
proposto;
b. a estrutura e a articulação dos processos Identificados no
estudo de caso cor respondem à estrutura e à articulação de
processos contidos no referencial proposto;
c. é possível caracterizar diferenças entre processos
específicoS identificados no estudo de caso e processos
específicos contidos no referencial proposto; deve ser
observado que os procedimentos específicos apesar de
diferentes na espéCie são Idênticos na categoria e, que as
diferenças específicas atendem a diferenças de estl lo
cognitivo ou a preferências dos agentes de planejamento;
d. a estrutura Insumo-processo-produto, sugerida por Klng em
153
1978 e por lederer em 1988, foi reduzida para uma
estrutura processos x classe de dados porque toda decisão,
a partir do momento em que é gerada, passa a ser Insumo
para outras decisões (produtos do planejamento da função
5 I ) ;
e. a estrutura do referencial proposto (processos x classes
de dados) corresponde à estrutura sugerida pela
metodologia BSP;
f. a metodologia BSP restringe seu escopo ao conjunto de
processos e decisões orientados para o planejamento
estratégico deixando de incluir procedimentos para,
prospecção tecnológica, análise de oportunidades para
sistemas de Informação, determinação da missão, diretrizes
e metas da função de sistemas de Informação, e, para o
Controle Gerencial; Controle de Operações e o Treinamento
de Operadores.
Para os administradores de empresa e profissionais
da Área de Sistemas de Informação, 05 resultados desta
pesquisa oferecem uma perspectiva ampla das metodologlas,
técnicas e ferramentas
Planejamento de função de
apl icávels
SI. Além de
Instrumentos disponíveis no mercado,
ao exercício de
mencionar diversos
nosso estudo
referência aos resultados de pesquisas rea I Izadas
faz
por
diversos autores objetivandO determinar o alcance e as
I imitações de diferentes Instrumentos de planejamento.
15"1
Dentre as I Imitações da pesquisa devemos destacar o
fato de que em apenas uma empresa obtivemos os elementos que
ut i I i zamos como i nd í c los da va II dade dos resu I tados do mode lo
de referência proposto. Seria conveniente Investigar o
comportamento do Referencial para Planejamento de Função de
SI proposto neste trabalho em confronto com os procedimentos
de Planejamento exercitados em outras empresas.
Como sugestão de pesquisas futuras, destacamos a
oferta de subsídios para a Identificação dos fatores que
determinam a probabl I Idade de êxito do empreendimento de um
esforço da Planejamento de Função de SI em uma empresa.
Para os administradores de empresa e profissionais
da área de Sistemas de Informação seria importante conhecer:
as aptidões de uma equipe capacitada ao exercício do
Planejamento de Função de SI;
o perfi I cultural das empresas capacitadas a empreender
com êxito, um esforço de Planejamento de Função de SI.
A Investi gação destes temas pode fazer emergi r o
conjunto de resultados necessários para a determinação da
orientação do esforço de desenVOlvimento humano (Individuai,
empresarial) indispensável ao exercício produtivo das
atividades de Planejamento de Função de SI.
155
BIIBLIOGRAFIo'!'-'Io
156
ANSOFF, H. I 9 o r . São Paulo:
McGraw-HII I do Brasil, 1977.
ANTHONY, Robert N. flânnlns ânR tAnlLAI li~lilªrnli: a framework
for analysls. Harvard Unlverslty, ~LâRYâlª ithAAI Ai
ªYlilnª§§ !grnlnl§lLâl1An. ºl~l§lAn Ai RªliªâLkh~, Boston,
Mass.1965.
BAKOS, J. Yannis and TREACY, Mlchael
technology and corporate stra~egy:
perspectlve. ~Ii qYâLlªLl~, June 1986.
BETHLEM, Agrlcola de Souza. fAll11tâ ª
E.
a
Informatlon
research
ªIDQLªliâli. Rio de Janeiro: Guanabara Dois, 1981.
BLALOCK and BLALOCK. MªlhAQQIAS~ In liQtIâl LªliªâLth. São
Paulo: McGraw Hi I I, 1975.
BOWMAN, Brent: DAVIS, Gordon: WETHERBE, James. Model I n9 for
MIS. nâlâIDâllQn, JUly 1981.
CARLSON, W.M. Buslness information analysls and Integratlon
technlques (BIAIT): the new horlzon. Qâlâ aâli~, 1979.
CHAMBERS, John C.: MULLICK, Sailnder D.: SMITH, Donald D.
Como escolher a técnica de previsão correta. s.n.t. texto
utlll zado no Curso de Métodos Ouantl tati vos em
157
Administração, COPPEAD/UFRJ.
DEWEY, John, tlQ~ ~~ !hln~, New York, D.C.: Heath, 1933.
EIN-DOR, Phl I Ip; SEGEV, EI I. MânâSlns mânâS~m~n! lniQ!mâ!lQn
ft~ftl~mft. D.C.: Heath and Company, 1978.
FURTADO, A.L.; SANTOS, C.S. dos. ll!Sânl~âkªQ g~ QânkQft g~
gâgQft. Rio de Janeiro: Campus, 1979.
GILLENSON, Mark L.; GOLDBERG, Robert. a!!â!~Slk QlânnlnS~
ft~ft!~mft ânâl~ftlft~ âng gâ!âQªft~ g~ftlsn. New York: Wlley,
1984.
HACKATHORN, Richard D.; KARIMI, Jahangir. A l!âm~~Q!~ lQ!
kQmQâLlnS lniQ!mâl1Qn ~nSln~~!lns m~lnQgft. ~l~ ºYªLl~ll~,
June 1988.
HOLLAND, Robert. al1Al~slk ft~ftl~mft Q1AnnlnS i~~f2. 1986.
INTERNATIONAL BUSINESS MACHINE, ªYftln~ftft ft~ftl~mft Qlânnlns:
information systems planning guide (BSP). 1975, 1978,
1981, 1984.
KEPNER, C. H.; TREGOE, B.B. Q Agmlnlft!lâgQl lâklQnâl. 2 ed.
São Paulo: Atlas, 1980.
KING, W. R. Strateglc Plannlng for management Informatlon
158
KUGLER, José Luiz Carlos; FERNANDES, Agulnaldo Aragon.
flsn~lsill~nlQ ~ ~Qnl~Ql~ g~ ftlftl~illªft g~ lniQLillskiQ. Rio de
Janeiro: Livros Técnicos e Científicos Editora, 1984.
LEDERER, Albert L.; SETHI, Vljay. The Implementatlon of
strategic informatlon systems plannlng methodol09ies. ~lâ
QMªLl~Ll~, Sept. 1988.
LEIFER, Rlchard, Matchlng computer based Informatlon systems
wlth organlzatlonal structures. ~12 QMªLl~Ll~, Mar. 1988.
LUNDEBERG, Mats; GOLOKUHL, Gran; NILSSON, Anders.
lniQLillsl1Qn ft~21~m2 WQLK ªng ªnªl~ftlft Q1 ~hªng~2. New
YOrK: Pergamon Press, 1979. (Informatlon Systems vol.4,pp
1 . 12)
plannln9 methodologles.
Engl ewood CllffS, N.J.: Prentlce-Hall, 1982.
RiO de Janeiro: Compucenter sistemas, 1983. Cadernos de
Informática.
MCFARLAN, F. Warren. Portfollo approach to Informatlon
systems. tls~~ª~g eM21n~22 R~~l~w. Sept./Oct., 1981.
159
MCKENNEY, James L.; KEEN, Peter G. W. How manager's mlnds
worK. ~~Y~L~ ªyªln~§ª fi~Yl~~. May/June, vol. 52, 1974.
MÉTHODE de real i sati on I nformatl que avec des sous ensembl es/
Método de Real ização Informática com sUb-conjuntos. São
Paulo: METODATA Informática, 1986.
NELSON, Acáclo Fellciano; HIGA, Wilson; FURLAN,
fns~nh~Ll~ ~~ ln1QLm~~ªQ: metodologia,
ferramentas. São Paulo: McGraw-HI I I, 1988.
José Dav I.
técnicas e
NOGUEIRA, Antonio Roberto Ramos; LOUREIRO, Garcia, Júlio M.P.
P. AY~llª~ªQ ~ ª~l~~iQ Q~ §l§l~mªª: um enfoque de
tecnologia de Informação. Rio de Janeiro: Livros Técnicos
e Científicos, 1987.
NORA, Simon e MINC, Alain. A ln1QLmª11kª~iQ Qª §Qkl~QªQ~. Rio
de Janeiro: Editora da Fundação Getúlio Vargas, 1980.
PEREIRA, Rogério Costa; PERLINGEIRO, J.E. Afli: avaliação e
planejamento de sistemas de Informação. São Paulo:
Blücher, 1979.
PORTER, Mlchael E. ~QmR~1111Y~ §l~ªl~SY: technlques for
analyzing Industrles and competltors. New York: Free
Press, 1980.
MILLAR, Victor E. How Informatlon systems glves vou
160
PRADO JUNIOR, Calo. lnlt~~YkãQ ª lRSlkª ~1ªlil1kª~ 1! ~~~ ~ãQ
fªYIQ~ f~llQtª Htª~lll~n~~~ lalg~
fUk~lMl~ A~i~ lnltQgYkã~ ª QtQstªmªkãQ lln~ªL. Rio de
Janeiro, Livros Técnicos e Científicos, 1977.
REGO, Severino Pompl lho. Modelagem conceituai de dados, da
teoria à prática. In: CONGRESSO NACIONAL DE INFORMÁTICA,
17, 1984. Anais ... 1984
ROCKART, J.F. The changlng role of the Informatlon systems
executlve: a criticai success factor perspective. &lQAn
~ªnªg~m~nl B~~l~~, Fal I 1982.
SETZER, Waldemar. BªnkQ g~ QªQQ~~
s~L~nklªQQt~~~ QtQl~lQ lRSlkQ ª QtQlªlQ il~lkQ~ &ftQ
fªylQ~ Hl~kh~t~ 19ª~~
&l~ºM~ tlªtQ~tl A~ lhª nª~ ~kl~nkª Qi mªnªsgmgnl ggkl~lQn. New
York, Prentlce Hal I, 1977.
SIMON, Jullan L. Hª~lk tg~ªªtkh mªlhQg~ in ~Qklªl ~klgnkª.
New York, Randon House, 1969.
STRUCTURED analysis and deslgn technlque. Sotech, novo 1976.
161
TYLOR, T.H. et ai. Itknlkª~ Q~ ~lmylªkªQ ~m kQmQQ1ªQQL~~' Rio
de Jane i ro: Vozes, 1971.
TORRES, Norberto A. flªn~lªm~nlQ Q~ lniQLmãl1kª nª ~mQL~~ª'
São Paulo: Atlas, 1989.
VATTER, P.A. et ai. Qyªnl11ª11y~ m~lhQQ~ in mªnªg~m~nl: text
and cases. Homewood, I I I.: R. O. Irvln, 1978.
WYSK, R.B • .Q mtlQQQ J2âf: planejamento de sistemas ou análise
de informação? Rio de Janeiro: GOPPEAO/UFRJ, Junho 1982.
(Relatório Técnico, 56).
162
1.6:3
11'~h P 1Ft" N D ]r: c: 11::::: Jr:
164
SISTEMA DE PLANEJAMENTO
DE NEGóCIOS
SUM~RIO EXECUTIVO
165
Sistema de Planejamento de Negócio
Segunda EdiÇão (Julho de 1981)
Requisições de cópias de publicações IBM devem ser feitas a
seu representante IBM ou ao escritório local da IBM que serve
sua local idade.
Comentários relativos ao conteúdo desta publicação devem ser
endereçados para: IBM Corporation, Technlcal Publications
Oept. 824, 1133 Westchester Avenue, White Plalns, New York
10604. I BM pode usar ou di str I bu I r qua I quer das informações
que você forneça, da forma que acreditar apropriada sem
Incorrer em qualquer obrigação. Você pode,
continuar a usar a Informação que forneça.
Direitos reservados por
Corporatlon
Internatlonal
1978,1981
1.66
Buslness
certamente,
Machlnes
Até recentemente, a abordagem típica para o proJeto
de ap I I cações de processamento de dados tem s I do rea I izar-se
cada uma delas por si mesma.
Com cada uma delas rea I I zando ef i cazmente sua
finalidade específica, não tem sido dedicada suficiente
reflexão ao valor potencial que reside no compartilhamento de
I nformações através das fronte I res da ap I i cação ou no
fornecimento das mesmas informações para a Gerência com a
f i na I i dade de um contro I e me I norado. O resultado
freqüentemente tem sido a redundância de dados, uso
execesslvo de recursos de processamento de dados e retorno
insuficiente do Investimento em processamento de dados, pois,
certas necessidades, quanto a Informações dos negócios, têm
sido atendidas incompletamente.
Hoje, contudo, mais e mais executivos de negócios
estão admitindo que dados são um recurso tal qual dinheiro,
materiais, faci I idades e pessoal. Eles estão vendo mais e
mais claramente a necessidade de um Plano de Sistemas de
Informação (1/5) que torne este recurso disponível não apenas
para uma determinada área funcionai mas para toda a
organização. Eles vêem, sob um tal plano, como uma área
funcionai pode beneficiar-se de outra, e como a gerênCia
executiva pode se beneficiar de todas elas ganhando um ponto
de vista abrangendo toda a organização, que pode ser um ativo
na tomada de decisões funcionais cruzadas e no tocar mais
eficaz do negÓCio.
167
Sistema de Planejamento de Negócios (BSP) é uma
abordagem estruturada desenvolvida pela IBM para assessorar
um negócio no estabelecimento de um plano de I/S que
satisfaça suas necessidades de curto e longo prazo quanto a
Informações. Pode ser Igualmente bem aplicado tanto ao setor
públ ico como privado, uma vez que seus
projeto de sistemas de Informação são
requisitos
similares
negócio é usado através deste sumário executivo;
quanto a
(o termo
indica o
modo de tocar uma organização Indiferentemente de seu tamanho
ou finalidades e se pública ou privada).
A BSP se baseia na convicção de que o
qualquer sistema de Informação abrangendo todo
depende de:
sucesso de
o negócio,
Obter o compromisso e o envolVimento dos executivos;
Estabelecer objetivos de I/S que apolem aqueles do negÓCiO;
Entender o negócio do ponto de vista da gerênCia geral;
Adotar uma abordagem do alto para baixo para estudar o
negócio (isto é, trabalhar do global para o nível de
detalhamento) e uma abordagem de baixo para cima na
implementação;
Criar um plano que seja evolucionário, Isto é, um que
construa a partir dos sistemas existentes modularmente até
uma arquitetura Integrada;
Colocar no lugar as Informações quanto a funções de
administração requeridas para adequadamente administrar os
recursos quanto a sistemas de informação.
J 68
o primei ro objetivo da BSP é fornecer um plano que
apole tanto as necessidades de informação de curto e longo
prazo do negócio e que seja Integrado com o plano do negócio.
Além disso a BSP visa prover:
Estabelecimento
Gerência;
imparcial de prioridades de 1/5 pela
Desenvolvimento de sistemas de longa duração baseados em
processos de negócios usualmente não afetados por mudanças
organizacionais;
Um modo de administrar os recuros de processamento de dados
de modo a apoiar os objetivos do negócio mais
eficientemente e efetivamente;
Aumento da confiança de que serão produzidos
sistemas de Informação com alto retorno;
Importantes
Melhoria de relacionamento entre o departamento de sistemas
de informação e os usuários, através de sistemas que
atendam aos requisitos e prioridades dos usuários;
Aumento da consciência de que dados são recursos que devem
ser planejados e controlados de modo a serem usados
efetivamente por todos.
Benefícios Potenciais
A apl icação da metodologia BSP tem ajudado muitos
cl ientes da IBM a formular seus própriOS planos de sistemas
de Informação e seus própriOS mecanismos de controle, e a
169
melhorar o uso que fazem dos recursos de
informação e dados.
processamento de
Oferece à gerência executiva diversos benefícios
potenclas:
Uma ava I i ação da ef I các I a dos sistemas de informação
vigentes;
Uma abordagem lógica definida para auxl I lar na solução de
problemas de controle da gerência a partir de uma
perspectl va do negócio;
Uma aval iação das futuras necessidades de sistemas de
Informação baseadas em impactos e prioridades
com o negócio;
Uma abordagem planejada que pode permitir
relacionadas
um retorno
antecipado do investimento em sistemas de Informação;
Sistemas de informação que são relativamente independentes
da estrutura da organização;
Confiança de que existe uma orientação para os sistemas de
informação bem como uma atuação adequada da gerência com
vistas a Implementar os sistemas propostos.
Uma vez que a BSP é bem sucedida a ponto de
satisfazer as necessidades de uma organização quanto a
sistemas de Informação, baseados em computador,
significativamente melhorados, segue-se que o estudo da BSP
deve ser dedicado aos objetivos básicos de tais sistemas.
1.70
Apolo a metas e objetivos do negócio
Este obj etl vo dos I/S exp I i ca a abordagem "do a I to
para ba i xo" da BSP para a aná I i se de negóc I os bem como sua
ênfase tanto em entrevistas com executivos como no
estabelecimento de prioridades de sistema. A BSP pode ser
pensada na verdade (de fato), como um modo de traduzi r a
estratégia de negócios numa estratégia de I/S (veja figura 1)
King, W.R. "Strateglc Plannlng for MIS"
MIS Ouarterly, March 1978
Estratégia BSP Estratégia
do Negócio I/S
Missão, Objetivos I/S
Estratégl a I/S
> Metas e Políticas I/S
Processo de Objetivos
Planejamento Arquitetura
Estratégias da Informação
Flg.1 - Tradução da estratégia do negócio para estratégia de IIS.
Orientada para as necessidades de todos os níveis de Gerência
A ênfase primária no 1/5 deveria ser fornecer
medidas das condições vigentes reais para a tomada de
decisões da Gerência. A maioria das decisões do negócio podem
ser associadas ou com 21ªU~1ªm~n!Q (estabelecimento de várias
m i s s õ e s, o b j e t i vos, p o I í t i c as) o u c o m l<Qu!.r..Q.lª ( 9 u i a rum a
atividade em direção a um objetivo). É geralmente aceito que
cada nível de gerência é envolvido com três distintos tipos
de planejamento e controle:
flªu~lªm~n!Q ~~!Lª!iglkQ preocupado com o estabelecimento
de objetivos, decisão sobre recursos para atlngí-Ios e
e s t a b e I e c I me n t o de P o I í t I c a s p a r a 9 o ver n a r a a qui s I ç ã o, uso
e dispOSiÇão dos recursos.
~Qn!LQ1ª g~L~nklªl, preocupado em garantir aos gerentes que
os recursos estão sendo obtidos e usados adequadamente para
atingir os objetivos.
~QnlLQ1~ QQªL2klQUftl preocupado em realizar tarefas
específicas eficazmente e eficientemente.
A figura 2 mostra algumas características destas
áreas. Esta estrutura apl ica-se a qualquer Indústria, função
ou nível de gerência.
l.72
CARACTER [S1' ECA I [IA
DEC[SAO
PlA~E,IA"E~TI]
ESTRATE6 [CI]
CORTROlE
6ERE~C[Al
I:O~TRtllE
OPERAC [1]~Al
r-------~----------+_----------_+-------------
Se f"l!nlJ i.l
E n'1 ,] I 'I i ,h
Se r~n.: i.l 6e f-.ll
Se r~nl= i.l FllfI~ j 110.11 Se r~nl= j.1 FIJ.n,: i I]n.1l
6~ r~n!J i.l Ilp~ f'·llJ i Iln.ll
Se r-enl: j.1 F 1Jj1 ': i Iln.!1
Se r~nl: i.l I]p-e r··ll~ i Im.ll
HSJ f-i ilJnt...e .j.J l'ln'J'] P r'·UI] Anl] - .1 - Anl] Di.1 - ·i - [I i.l
T €G'!PiJ I: I -- I ~ .:LJ1ll:.i:' Ml\ln:j.il Sen.:uu.1
6 "·UL de
E:.i t. rij,in f'·3..
6e r~nl: i.l tie
Ael:I!rM.:iI]S
!'lal] e:it.r'u1:Jll"'.ld,] e ~.li:.i e:.i+~r·ut.Jlr·.3.d1] I ~ I t.-~nt..e e:.it.r'llt.Jlf'.ldl]
i r-r~'J111.1r, '~,ld.:l.. I~ i d i 1:0, '.lr"1'.aB"lent..e r~FI-et.i ti '~I]
P r11b I e 111 di re r~nt~ r~peti 1:. i 'lI]
FI f,€lje fi n i f', OJ.i +.J] fi] fnu n·ll] .rotAI: i p.i- i nt~ rl1.lI'~nt~
e:dJ! rflll ·11]:'; neq,]- Ih.:; I 'Jr·.3J1ljew.nt~
~i'l:.1 int~rfIl]
p/]1 i ti I~·U e:.ipec i - r"~I~U.r~.ill:i
fi I~.!S p.ir·.i IJ~l
r~r!lj.r-..iO:i
Em conexão com Isto, o recurso gerência representa
um Importante veículo para a definição do l/S. Cada recurso,
incluindo o produto, é gerenciado através de decisões tomadas
pelos três tipos de planejamento e controle. A Gerência de
Recursos tem a característica desejada de passar através das
fronteiras organizacionais - verticalmente através das linhas
de gerência e horizontalmente através das linhas funcionais.
Assim, uma estrutura baseada em recursos, bem como um
planejamento e controle, pode ser estabelecida e uma
arquitetura de 1/5 pode ser aplicada dentro desta estrutura.
Promover Consistência de Dados
Problemas na área de consistência de dados surgem
na maioria das organizações devido a variações na iQLmª
Qªilnl~~Q e QQQL!ynlQªQª dos dados. A iQLmª pode se
constitui r de dados brutos, não tratados, arquivo de dados
mecanizados, relatórios de processamento de dados detalhados
ou sumarizados, documentos de negócios ou conhecimento na
cabeça de alguém. A Q~ilnlkªQ de qualquer Item determinado de
dados pode ter tantas variações quanto usuários. A
QQQL!QD1QªQª dos dados também varia com a maneira pela qual é
capturado, processado, fornecido e usado.
Todas estas variações são parte e parcela do
clássico desenvolvimento, uma a uma,
processamento de dados.
das ap I I cações de
Para modificar a situação é necessário adotar uma
abordagem diferente para gerência de dados, uma abordagem
baseada em dados como sendo um L~kQL~Q. O recurso deve ser
gerenciada de modo a estar potencialmente disponível e ser
174
comparti I hado pela tota I Idade
consistente. A função gerência
do
de
negócio
dados
numa base
Incluiria a
formulação de pol íticas e procedimentos para uma
consistente, fornecimento, implementação técnica,
segurança.
definição
uso e
Ser capaz de sobreviver a mudanças
Os sistemas de processamento de dados e ap I I cações
que existem para servir às necessidades de uma entidade
organizacional específica ou para produzir relatórios para um
Gerente particular correm o risco de se tornarem obsoletos a
qualquer Instante. Isto pode ser caro. A mUdança' Inevitãvel
em qualquer empresa dinâmica, mas seu custoso Impacto nos
sistemas pode ser minimizado através de um sistema de
Informação que possa antecipar e viver através de mudanças
organizacionais e de gerência.
Por esta razão, os sistemas de informação devem ser
construídos para apoiar os elementos não translentes dos
negócios - elementos que são bãslcos e que não mudarão
apreciavelmente a menos que a essência do negócio mude. A BSP
refere-se a estes elementos como processos do negócio e
define este termo como grupos de decisões e atividades
logicamente relacionadas necessárias para gerenciar os
recursos do negócio. Um conjunto lógiCO destes processos pode
ser definido para qualquer tipo de negócio e sofrerã mudanças
mínimas enquanto o produto ou a área de serviço permanecer
j.7~j
basicamente a mesma.
Definir os processos de negócios das organizações é
uma das mais Importantes partes da metodologia BSP e o método
para fazê-lo está diretamente ligado a basear a estrutura do
1/5 em recursos, planejamento e controle. Com isto em mente é
conveniente identificar processos de negócios de uma
organização em associação com cada um de seus
determinados.
recursos
Cada recurso de um negócio pode ser pensado como
tendo um ·ciclo e vida" composto de vários estágios. (Um
ciclo de vida de um produto, por exemplo, tem quatro
estágios: solicitação; aquisição; transporte e ai ienação). Os
processos de negócios podem ser Identificados para descrever
as mais Importantes atividades real izadas e decisões tomadas
para o negócio no curso de gerenciar o recurso através de seu
cicio de vida.
Esta abordagem resulta em identificar processos que
abrangem o planejamento estratégiCO, o controle gerenciai e o
controle operacional. Por exemplo, a decisão de se dedicar à
uma particular área de produto seria planejamento
estratégico; o planejamento e as decisões de controle
relativas a volumes de produtos ou gastos com propaganda
seria controle gerenciai e as decisões nas áreas de controle
da engenharia, eficiência de fabricação, etc., seria controle
operacional. Usando esta abordagem para todos os recursos é
1.76
possível definir todos os processos de negócio que se
rea I i zam dentro de qua I quer segmento organ I zac lona I.
Implementar Estratégia por Subsistema dentro da Arquitetura
Tota I de Informação
Para evitar problema de Inconsistência de dados,
projeto de sistemas não Integrados, custosas manutenções de
sistemas, dificuldade de atribuir prioridade, etc. , a
fi losofia BSP (veja figura 3), acentua: (1) planejamento de
I/S do topo para baixo para identificar objetivos de I/S de
longo alcance; (2) implementação de sistemas de baixo para
cima durante um período de tempo, consistente com as
prioridades de negócios da organização, fundos disponíveis e
outras considerações de curto prazo.
t)b .ie-t i '.lOS tt:e· ~~cice.
Fr cc E'!ó.~<:€. ti::€. ló;.gi'c i (€.
... " ...---""-------,
l A!=oCti c· ao F'r[c~.SE<tF.r,tt::. riP C'Cdt:e.
.. :~I
177
Fr cc E'!ó<:€. tt:,.,. ~i(€.
. ' ./
....r·, .-/
./ ..
~. i s ~ E?lfes a.1Eo I nfCf"u-a:~J
A metodologia B5P está em harmonia com esta
f i I osof I a, ) á que envo I ve quatro grandes at I v Idades (vaj a
figura 4):
DEF [~[R OS DEF [M [R O:,
ilB.JEr [VI]:; (11] PRIlCE:;:;O:,
ME60G[0 [11] ~E60G [OS
DEF I~ [R A'-., DEFIMIR li
GUISSES [IE [lADOS AAI11J ITETIJRA DA
("FOR"ilCAI]
rl~. 01- RIJ,] "l.3-'r~11 ,e P l.iI1~.j·l.rent,] 6e '·.il p.u-·i li:,.
ºQ~Ym~nlâL Q§ Q~1~11~Q§ QQ n~gQ~lQ de modo a obter o acordo
dos executivos sob os quais o negócio é chefiado, de modo
que a estratégia de 1/5 possa estar fortemente suportada;
prioritárias de longo prazo para suportar os 1/5 do
negócio.
a produzir uma definição de todos os dados a serem
gerenciados como recurso através da unidade do negócio;
inter-relações dentro de um grupo de áreas de 1/5 e para
mostrar os dados associados que devem ser gerenciados. É
através desta Informação de arquitetura que os modelos
i7B
individuais podem ser Identificados, prlorizados e
construídos como previsto pelo plano de l/S.
Não apenas a metodologia consiste em atividades
muito mais detalhadas do que o indicado acima, mas também é
flexível. Isto é, os passos e técnicas podem ser adaptados a
situações específicas. Em qualquer caso a metodologia é
direcionada para satisfazer os objetivos dos I/S e estes
objetivos devem ser considerados como inalteráveis.
Perspectiva na abordagem Estudo BSP
Uma Importante articulação existe entre
identificação dos requisitos gerais
fases para a implantação dos I/S
requisitos são identificados para
do negócio e as
(veja figura 5).
uma unidade total
a
seis
Os
de
negócio e então separados em projetos que são empreendidos e
implementados ao longo do tempo. Em adição aos projetos de
sistemas de informação há também um conjunto contínuo de
projetos cobrindo a arquitetura da informação e a gerênCia
dos sistemas de informação (ISM).
No passado e em multas negócios hoje, os projetos
são definidos para atender uma área funcionai do negócio sem
levar em conta os requisitos totais da unidade de negócio. A
BSP pOde fornecer orientação para todo o negócio antes que
sejam empreendidos projetos e , portanto, evitando
fracionamento dos dados e Inconsistência de sistemas.
179
~:E IIJ I S IT[rj
GUlE:A IS
[Ul
VI
1II1III IllIl (I [VI
I) I
'lI
L-__ p_r_~._~_W_; __ d_~ __ G~ __ ~_[_i. __ d_~ __ R_~:_W_~_l __ ~ ____ ln_r_o~ __ ~_~_l ____________ J - Opf in içr~~. cf.J~. F~~J j.; i ter;
11 - PPl .~t,]~. E:d.I3r'fttri
III - Prol ."t'l'. l"t~r"D
I ~I - ~.!:~w[d ~Ij ~nt[1 cil1 Pro!O'"ama li - T~5JE' r:!.l 5 j-;~IJ.J
I) I - In;t.1 <P;1io:J ~ M""ut~~J[,
Principais Atividades do Estudo BSP
Pode se dizer que enquanto um estudo BSP consiste
de treze atividades principais (veja figura 6), duas destas -
obtenção do compromisso dos executivos e preparação para o
estudo - são realmente preliminares ao estudo propriamente
1.80
dito. As várias atividades podem progredir até diferentes
graus, mas nenhuma pode ser omitida.
[t.lJ:-r~. dt. r:oo.:fU!I i 5Sh
l fl"i1'~d\fII:. I~
t. EE.1.J.mi:,
,1"
[~OE<;I' dt, !S1JJdi:,
1 Dc.f i fi i i;lit. dro!-fTlQo!;m. 11:, ~iD
,t, [1E'f i fi i i;lit> da!.
rI",·!~· cI1! ~~.
l ~~I i!-E' ck:-s ~.i!:.-t.... di> Of"!'it,
\' i !lt .... ru..
J' [ME<11 i róG. Ela P.,"'.,pod i ,.. do
&Kllli""
J-[lE'fiflili<' Ii:~. ro:t~. " [:m: III!~;"" .
'i,' . ~" I F:E<.' i ,&, da !iEor!'r
ri. cI:~. Fro.r! Mo Ir{t<1>1ldit
w.(~, ,
[1Ef i fi i i;lit, "" w.~ i iPÚlõ da Iflft~,
... J. ... [",t.n.i~, oi;,
" 11" i tO" i W:I?!. da ... ~ i 1.PiJ.Iri, '.
} '.f" EI;/:<.-d;f,t, Mo
FKr ..... ~. f·I .... , .. ~,
J. F:EoI.lJ:, !I:~.
F:Eo<"I~.
FI6. t - FluoD do Es1.J.mi:, da E~i'.
181.
Obtenção do compromisso dos executivos
Um estudo BSP não deve começar a menos que um
executivo de primeiro escalão o patrocine e, certos outros
executivos se comprometam a estarem envolvidos com o mesmo. O
estudo deve refletir o ponto de vista dêles sobre o negócio e
o sucesso do estudo depende dos mesmos fornecerem à equipe um
entendimento do negócio e os requisitos de informação. A
ma i o r i a das contr i bu i ções v Irá d I reta ou I nd I retamente destes
executivos.
É neste estágio prellmi nar que um acordo deve ser
atingido quanto À abordagem e objetivos do estudo e no que se
espera que ele forneça, uma vez que a aprovação das
recomendações feitas no fim do estudo comprometerão a
companhia durante vários anos com uma certa direção no uso de
seus recursos de processamento de dados.
Imediatamente depois de ser obtido o compromisso
dos executivos, deve ser selecionado um I Ider para a equipe
de estudo. Este Indivíduo deve ser um executivo que
trabalhará em tempo Integral no estudo de (tipicamente) 6 a B
semanas e dirigirá as atividades da equipe ( de novo
tipicamente) de 4 a 7 semanas. O I Ider também cuidará que o
contato da equipe com outros executivos seja feito no nível
adequado e que as contribuições destes executivos seja
Interpretada corretamente. O executivo patrocinador deve
enviar uma carta para todos os executivos participantes,
estabelecendo o tom e manifestando compromisso com o estudo.
Preparação para o estudo
A preparação para o estudo envolve treinamento e
orientação própria para os executivos participantes, membros
da equipe de estudo de modo a que se obtenha a melhor
contribuição possível dos executivos e seja feito o melhor
uso possível da equipe.
Decide-se quais as pessoas a serem entrevistadas o
mais cedo possível para permiti r que se orientem e programem
a entrevista. Também neste estágio a Informação deve ser
reunida na companhia e no apolo ao processamento de dados.
sala de
Deve ser permitido à equipe uso exclusivo
controle apropriadamente localizada, onde
de uma
possam
trabalhar Juntos, colocar mapas nas paredes e conduzir
entrevistas.
NO fim deste estágio, a equipe deve ter produzido
um I ivro de controle do estudo contendo:
Um plano de trabalho do estudo;
Um programa de entrevistas;
Um programa de revisões com o executivo patrocinador, em
certos pontos de verificação;
183
Um esboço para o relatório final do estudo;
Dados sobre 05 negócios e sistemas de informação
anallzados, mapeados e prontos para o começo do estudo.
Quando a preparação do estudo estiver completa,
tudo o que tiver sido executado durante aquela fase deve ser
revisto pelo executivo patrocinador.
Começo do Estudo
Aqu I é onde rea I mente começa o verdade I ro estudo
BSP e os membros da equipe começam a participar em tempo
Integral. O começo do estudo consiste em três apresentações:
o executivo patrocinador reitera 05 obJetivos,
esperados e perspectiva do estudo;
resultados
O I íder da equipe examina 05 fatos sobre o negócio que
foram reunidos para verificar se cada membro da equipe está
profundamente faml II ar I zado com e I es. E I e também trata de
certos assuntos que não poderiam ser documentados
po I í t i cas, assuntos sens í ve 15, mudanças p I aneJ adas ou em
progresso. Finalmente ele cobre o processo de decisão, como
a organização funciona, pessoas chaves, problemas
principais, a opinião do usuário de suporte do
processamente de dados e a Imagem do departamento de
processamento de dados;
O diretor dos sistemas de Informação, ou um de seus
gerentes, tambén apresenta opinião sobre o processamento de
HI4
dados. Em adição, esta pessoa cobre o status do projeto e o
controle do projeto, história dos principais projetos de
processamento começados nos últimos dois anos, principais
atividades em andamento, mudanças planejadas e problemas
principais.
Definição dos processos do negócio
Nenhuma outra atividade do 'estudo BSP é mais
importante que a definição precisa dos processos do negócio.
Estes processos formam a base para as entrevistas dos
executivos, arquitetura da informação, análise de problemas,
identificação de classes de dados e várias atividades a serem
acompanhadas. Por causa disto, todos na equipe devem ter uma
compreensão precisa dos mesmos. Onde tal compreensão ainda
não existe, pode ser obtida ao longo da ajuda na
identificação dos processos e da descrição dos mesmos por
escrito.
No fim deste passo a equipe não terá somente
prOduzidO uma lista de todos os processos e
escrita de cada um, mas também terá assinalado
são chaves para o sucesso do negócio.
Definição das classes de dados
uma descrição
aqueles que
É neste ponto que 05 dados são agrupados em
categorias logicamente relacionadas isto é, classes de
185
dados - de modo a auxi I iar o negócio a desenvolver bases de
dados ao longo de um período de tempo com mínima redundância
e de tal modo que sistemas possam ser adicionados sem uma
grande revisão nas bases de dados. Uma vez Identificadas, as
classes de dados são relacionadas com (1) processos do
negóc i o de modo a def i n i r a arqu i tetura da Informação; e, (2)
os arquivos existentes, para auxi I lar o proJeto de um plano
de migração.
Aná I I se dos Sistemas de Apo I o V I gentes
Esta atividade é dirigida para mostrar como o
processamento de dados está apoiando o negócio de modo que
possam ser feitas recomendações para ações futuras. Com
vistas a detetar redundânc I as, auxiliar a clarificar
responsabl I idades e aprofundar o entendimento já obtido dos
processos do negócio, a equipe analisa quatro elementos:
organizações existentes no momento, processos do negócio,
sistemas de informação (apl icações) e arquivos de dados. Para
faci I Itar a anál ise, a equipe desenvolve matrizes usando
combinações destes elementos (veja figura 7). Através das
várias anál ises feitas, a equipe prepara-se para discussões
com executivos e obtém auxíl lo na determinação de
para o apolo à Informação.
1St.>
requisitos
Ff~XE59)
\ ....
'.,
\,
... '<,
\,
\ " "
\ ....
lAÇ~) '<,
" ,
C:E-f1'EoI c€t~c I A
CoE 1,9l:fE,
I bl::.t':EI'~_:1 '" c€ CoE
1e:.:f'll:)~::1 A CoE
FI G_ 7
I)
[
ti IJ 1-o
[
[
lJ f-
Croll/;:tE, OC ')Ell:fE, Ff,;or:@)
C' oI I) rI I[ Z bJ ri [ Dl Z 1,;0 bJ o c' ri li f- I} IJ bJ ,1 l: '1 f- o
nl 1'1 I,[ o o C' L 'I o 'I l '1 tJ [ li ,I ~, ri Ij
o 7 '- - CI L - [ li '1 I} I: oI
Z J li -, -' r.; lO '1 :1 li [
IJ L C' 'I 0'1 o [ I) 'I B.. ,) 1- li } o I[ li 'I [ IJ [ J C"l IJ 'I L
'I I~ I: o ,) 1'1 L L I- ~I [ L ç,
.. :.: ............ , ........ .
I8:?
Determinação da Perspectiva do Executivo
Esta atividade é uma parte Integral da abordagem de
cima para baixo. Sua finalidade é validar o trabalho feito
pela equipe e obter relacionamento com os executivos e
envolvimento dos mesmos. As entrevistas com
fornecem o entendimento do negócio necessário
planejamento dos sistemas de Informação.
o principal resultado consiste de
executl vos
para o
notas das
entrevistas, de uma atualização dos mapas da sala de controle
e de um novo ou melhorado relacionamento entre o executivo e
a equipe de estudo BSP.
Definição dos Achados e Gonclusões
Esta atividade envolve a análise dos problemas que
foram fornecidos como entrada durante a coleta de fatos,
expandida pela equipe e somada à entrevista com o executivo.
Este estágio também envolve relacionar estes problemas com os
processos dos negócios e desenvolver processos e
que preparam o palco para recomendações.
Inclusões
Em adição, o estabelecimento do problema I nc I u I
dividi r problemas, naqueles que têm relação com o apolo aos
sistemas de Informação e aqueles que não têm. Aqueles que não
têm são dei Ineados e entregues ao executivo patrocinador para
18B
seguí-Ios; aqueles que têm são examinados mais a fundo no
estudO BSP e nas atividades de acompanhamento.
Definição da Arquitetura de Informação
Esta atividade representa um Importante movimento
no sentido de um exame do presente para uma síntese do
futuro. É aquI que esboçamos os futuros sistemas de
informação e seus dados associados.
Sistemas pOdem ser consideradas como sendo as
porções automatizadas de processos. As bases de dados são as
partes computadorizadas do estoque total de dados dos
negócios. A arquitetura de informação (veja figura 8) traz
ordem e estrutura aos sistemas e dados que criam e usam. Uma
vez que esteja estruturada permite o desenvolvimento,
passo-a-passo, migrar das aplicações de hoje para os sistemas
de informação do futuro.
Uma vez que esta tarefa envo I ve tira r uma
he I I ográf I ca para o fututo,
equipe.
merece a atenção de toda a
1. B9
... 1 I J l ... •• I) ..
" '11 UI oe· I l ., F'R[{:[1:,5[1 f-[ f-01 t~ Z lU lU liJf- lU I ·1 ... ., ri I) rliJ oHl ) oIiJ - Z lI:uJ ·1\ I ~J ,.
" -H"I -I': uu I) IH! ~I IlUII ~I oI f- '1 i ''---, l-lI 1':1.1 -[ [ 'IuJ lIl)l) 'Ior lIl)C' )(·zo Z l
\ -[O -} JI) 11, foU 2:1-1- I- li: ·1 ZHI [I--f- li 0"1 i [Um: [IE , r[z L '1 11 ZO[ 'IUI lOI} 11ZII1 IJZlIZ O al i
" [IÇ{(~,
lH .. :W
m~lTr+:1[I DE I.rnlil.',
[~iEl'l
[tM[6
EI1~:IliId1~,
...
'f.I[:Il,?l1
, "
ullll 01iJ lIlJ :[
~ IU-::- '1 O [li li
IDm:l~
, , l' , ,
~
lU«t.
(·-lJ JlIJ 1)-[ JIiJIiJ allJ[lJ Z O.l ... I)JI') ll:l) I)JC' La [rfor - I.i/
~1J1~,,1T~, EEItI{:I~
' " , " , "
--, "
Ç(tlIHI~,m(ll) , ,
Ff.':mll..
Determinação das Prioridades da Arquitetura
Uma vez que uma arquitetura total de informação não
pode ser projetada e implementada de uma única vez, a equipe
deve estabelecer prioridades para o projeto dos sistemas de
bases de dados. Decidindo quais das bases de dados devem ser
projetadas em primeiro lugar, a equipe estabelece quais
subsistemas serão definidos durante o andamento dos projetos.
Para estabelecer prioridades, a equipe elabora uma
I ista de projetos originados dos subsistemas da arquitetura
de informação, então estabelece um conjunto de critérios e
1. 90
aval ia os projetos em consideração com referência aos mesmos.
Revisão da Gerência de Recursos de Informação (IRM)
A final Idade do IRM é estabelecer um ambiente
controlado no qual a arquitetura de Informação possa ser
projetada, implementada e operada eficientemente e
eficazmente. As funções dos sistemas de informação são
examinadas durante o estudo BSP para detetar (1) quaisquer
mudanças que poderiam ser feitas imediatamente para assegurar
sucesso no acompanhamento dos projetos; (2) mudanças que são
necessárias para gerenciar e Implementar adequadamente a
arquitetura de Informação dos projetos de alta prioridade; e,
(3) atividades importantes que se tornarão projetos no
acompanhamento do estudo BSP. A realização Integral deste
passo é vital para um bem sucedido apolo dO negócio pela
função processamento de dados.
Elaboração de Recomendações e Plano de Ação
o plano de ação é feito para auxl I iar a tomada de
decisões considerando 05 projetos de acompanhamento
recomendados, cada um dos quais terá sido definido como um
resultado de atividades nas áreas de prioridades de
arquitetura e recomendações IRM. O plano de ação une estas
duas áreas para identificar recursos específicoS,
programações e interações de projetos.
191
o plano de ação também Identifica os passos que
devem ser tomados antes de começar cada uma das atividades de
acompanhamento. Estes passos devem ser examinados e
dimensionados antes que as datas de Início possam ser
estabelecidas para o andamento dos projetos, de modo que a
gerência possa dar a orientação necessária para
Imediatamente para estas atividades preparatórias.
Relato dos Resultados
Os resultados finais de estudos BSP
apresentados à gerência executiva em duas formas:
mover
são
um
relatório escrito e uma apresentação. A final Idade de cada
uma é obter o compromisso da gerência executiva com a
implementação e recomendações do estudo.
O relatório fornece a base para a apresentação aos
executivos e a distribuição dos resultados finais às pessoas
designadas pelo patrocinador. Depois da apresentação aos
executivos, que é normalmente feita pelo chefe da equipe,
todos os outros materiais relevantes que não façam parte do
relatório devem ser Indexados e arquivados para se ter pronta
disponlbi I Idade nos proJetos de acompanhamento.
Sumário
o plano que resulta de um estudo BSP não deve ser
considerado Imutável: ele simplesmente representa a melhor
192
concepção num determinado ponto no tempo. O verdadeiro valor
da abordagem BSP é que ela oferece aos cl ientes a
oportunidade de (1) criar um ambiente e um plano I n i c i a I de
ação que pode permitir a um negócio reagir a futuras mudanças
nas prioridades e na direção sem radicais di laceramentos no
proJeto do sistema; e, (2) definir uma função sistema de
informação para continuar o processo de planejamento.
O sucesso do investimento em qualquer sistema de
Informação futuro pode ser predito com base na habl I idade da
organização em elaborar um abrangente plano de longa duração
baseado em seus próprios e singulares requisitos. O Sistema
de Planejamento de Negócios da IBM é um método efetivo para
elaborar tal plano - um que pode fornecer Informações na
forma que for requerida e é bastante flexível
modificação.
para acomodar
Para informações adicionais sobre Sistemas de
Planejamento de Negócios e sua aplicação aos requisitos de
sistemas de informação de sua organização, contate seu
representante "Processamento de Dados IBM".
193
194
CICLO DE VIDA DOS
SISTEMAS DE INFORMAÇZO
195
Análise organizacional - Esta etapa objetiva determinar as
condições empresariais e o ambiente em que a empresa opera,
descrevendo-se as principais funções e atividades que
realiza. Determina-se a partir da metodologia definida e
aplicada no Planejamento Estratégico Empresarial, as
suas POlíticas, Objetivos, Metas e Desafios da Organização,
prioridades e os fatores críticos para o seu sucesso. São
determinados os Sistemas de Informação Atuais.
Procura-se compreender 05 problemas gerenciais,
anal i sando-se as projeções de crescimento da empresa,
antevendo-se possíveis mudanças nos processos decisórios que
podem afetar ou ser afetados por seus sistemas de
Informações.
São determinadas as perspectivas da alta gerência
em termos de recursos e sistemas de informações e detetada a
posição da empresa quanto às questões estratégicas envolvendo
o uso da automação de Informações.
As informações tratadas compreendem: organogramas,
dados econôml co f i nance I ros, pub I i cações da empresa, aná I I ses
de mercado, modelos empresariais, documentação dos sistemas
atuais, questionários de entrevistas, descrições de funções e
atividades, mapeamento de funções por unidade e local e,
análise dos principais Indicadores e medidas de desempenho.
Os resultados esperados compreendem: coleta de
196
dados a respeito da empresa, descrição das principais funções
e atividades associadas às unidades organizacionais e
localizações físicas, principais Indicadores e medidas de
desempenho, relação dos Sistemas de Informação atuais,
perspectivas gerenciais sobre as condições atuais e futuras
da empresa, Pol ítlcas, Objetivos, Metas e Desafios, fatores
críticos de sucesso, necessidades de informação da alta
gerência, perspectivas sobre recursos de informática,
determinação do uso estratégico da Informática pela empresa.
Anã I I se de Necessl dades - Esta etapa é o momento em que uma
primeira aproximação de alguns detalhes exigidos pelo usuário
final é especificado. Determina-se as informações necessárias
desafios, funções e para dar suporte aos obJetivos, metas,
fatores e estabelece-se a arquitetura global dos sistemas
associando-se os principais processos com classes de dados.
São identificados parâmetros para fixação de prioridades para
o desenvolvimento de sistemas.
As informações tratadas compreendem relação dos
principais processos desenvolvidos em cada área funcional,
relação dos dados uti I Izados e criados pelos processos,
relação dos Indicadores e medidas de desempenho e dos dados
uti I izados ou criados para ou pela elaboração desses
Indicadores e medidas de desempenho, relação das propostas de
uso da tecnologia de Informação para alcançar vantagens
competitivas. Os resultados esperados compreendem:
da arquitetura global dos Sistemas de Informação,
1 97
definição
definição
das necessidades de automação de processos, definição do modo
de uti I i zar a tecno I og i a de I nformação para Incorporação de
vantagens competitivas pela empresa (seja por adicionar valor
aos produtos ou serviços da empresa, seja por oferecer
faci I Idade de relacionamento com o mercado).
Análise de Viabilidade Nesta etapa, Já definidos a
arquitetura global dos sistemas e o elenco de proJetos para
automação de processos e de projetos para utl Ilzação da
tecnologia de informação para Incorporação de vantagens
competitivas, e com base na capacitação do recurso humano,
nas tecnologias disponíveis, na estimativa do volume de
procedimentos e dados a serem manipulados, na capacidade dos
equipamentos disponíveis, na potenc i a I i da de do software
disponível, na topologia da demanda, na tecnologia para o
projeto de rede, na expectativa de ganhos e na expectativa de
desembolso, (hardware, software, rede, mão de obra,
comunicações, infra-estrutura e manutenção) é feita a
avaliação de tempo de desenvolvimento, custo global de
implantação, expectativa de benefícios e performance, e
me I hor I a das re I ações com os c II entes, também são ava I i adas
as incertezas (variações em torno das expectativas) de modo a
estabelecer o nível de risco do empreendimento.
As Informações tratadas, compreendem: arquitetura
global dos sistemas, elenco de proJetos, topologia da
demanda, volumes de processos e dados manipulados em cada
ambiente, tecnologias disponíveis (hardware, software, rede,
198
comunicações), expectativa de ganhos, expectativa de custos
(tecnologia, infra-estrutura, mão-de-obra) e capacitação da
mão-de-obra.
Os resu I tados esperados, compreendem: Ava II ação do
tempo de desenvolvimento, estimativa do custo global de
implantação, dos benefícios, da performance, da melhoria de
re I ação com 05 c I i entes, assoc i ando-se a essas est I mat I vas as
Incertezas, de modo a estabelecer o
empreendimento.
nível de risco do
O estudo deve oferecer a comparação entre as
diversas alternativas disponíveis e compatíveis
complexidade do projeto.
com a
forma I i zação do PI ano - Nesta etapa, com base nas di retr I zes
estabelecidas pela alta gerência, após ava I i ação das
alternativas oferecidas pela análise de viabilidade, é
elaborado o Plano.
As
alternativas,
Informações tratadas compreendem uma das
de dentre as oferecidas pela
viabilidade, selecionada pela alta gerência,
alterações, as diretrizes para alocação de
análise
com ou sem
recursos, as
diretrizes para desenvolvimento da capacidade, as diretrizes
para elaboração da estrutura organizacional,
para transição de ambiente.
as diretrizes
Os resultados esperados compreendem: Definição
199
detalhada da estrutura do Projeto, Definição da prioridade
entre os Sistemas, Programação do Desenvolvimento Plurianual,
Definição da Estrutura de Gestão do Projeto (Gerente Usuário,
Gerente Anal ista, Gerente de Banco de Dados, Administração de
Dados, Estrutura órgãos de Processamento de Dados), Plano de
Hardware (Equipamentos e Periféricos), Plano de Software
(Linguagens de Software Operacional e de Apoio), Plano da
Rede (Topo I og I a, Centra Ilzação X Descentra II zação,
Arquitetura da Rede, Descentralização do Processamento),
Plano de Telecomunicações, Plano de facl I Idades, Plano de
Pessoal, Plano de Treinamento, Plano de Segurança, Auditoria,
Documentação e Normas, Programa de Ações e Responsabl I idades,
Plano financeiro.
Projeto Lógico Nessa fase, é de suma ImportânCia a
participação intensiva e o comprometimento dos usuários
envolvidOS com a função anal isada, de forma a estabelecer o
modelo de dados e o modelo de processo detalhados, reais,
completos, e de plena conflabllidade, a partir das
necess i dades i dent I f I cadas na fase de P I anej amento (Aná I I se
Organizacional e Análise de Necessidades). As classes de
dados são refinadas em atributos e os processos gerenCiais
são decompostos em atividades, gerando visões de contexto dos
Submodelos de Oados e dos Diagramas de fluxo de Dados. Os
Submodelos de Dados deverão ser completamente normal izados e
os Diagramas de fluxo de Dados serão desdobrados até um nível
elementar resultando os correspondentes Diagramas de Ação em
português estruturado. (Uma alternativa é optar-se pelo
200
Diagrama de Navegação de Dados, que operará sobre o Modelo de
Dados). 05 Diagramas de Fluxo de Dados migrarão para
Diagramas de Estrutura dos quais derivarão os programas.
As informações tratadas compreendem: todos os
procedimentos relacionados com a obtenção, armazenagem,
atualização, transferência, Inclusão/exclusão de Informações
necessárias à execução das atividades de produção e gestão
empresarial, bem como o conhecimento detalhado dessas
informações e dos mecanismos de operação dessas informações.
Os resultados esperados compreendem: Definição
detalhada dos Diagramas de Contexto, definição detalhada dos
Diagramas de Fluxo de Dados, definição detalhada do Modelo de
Dados, definição detalhada do Dicionário de Dados, definição
detalhada dos Diagramas de Ação.
ProJeto Administrativo Nessa fase é estabelecida a
sistemática de produção (operação) das apl icações, Isto é,
define-se detalhadamente a forma de registrar os dados que
originam as transações da empresa; os dados podem ser
registrados via terminal ou em documentos especfficos. Se
forem registrados via terminal, deve ser descrita a forma de
estabelecer o controle administrativo dessa inclusão,
alteração ou exclusão de dados; a forma de caracterizar a
autorização dos reponsávels pela transação; o mecanismo e os
destinos para "dlstrl bulção das cópias" que se fizerem
necessárias;
responsável
o modo de transfer I r a informação para o
pela execução das atividades associadas à
201
transação e o modo de confirmar a transferência da
informação, etc; se forem registrados via formulário, deve
ser descrito o lay-out do formulário, o número de vias, a
distribuição das cópias, o responsável pela digitação dos
dados, o modo de transfer i r e conf i rmar a transferênc i a da
I n f o r ma ç ã o p a r a o r e s p o n s á v e I p e I a e x e c u ç ã o das a t i v I da d e s
associadas à transação, etc; ou seja, são definidos todos os
procedimentos que posslbl I Itam operar e controlar o fluxo de
informações que suporta a execução de uma transação desde o
início até a conclusão dessa transação, explicitando as
etapas a se rem rea I i zadas manua I mente e aque I as a serem
automatizadas.
e/ou
As informações tratadas
equipamentos de entrada de
compreendem: formulários
dadOS; relatórios e/ou
dispositivos para exibição de informações de saída; origem e
destino das comunicações e o número de vias; tramitação da
i n f o r ma ç ã o; a u t e n t I c a ç ã o das o r d e n s, s o I I c I ta ç õ e s e p e d I dos;
articulação dos procedimentos manuais e automáticos; recepção
e expedição de formulários e relatórios, etc.
Os resultados esperados, compreendem: lay-out de
formulários, descrição de arquiVOS, determinação do tempo de
manutenção das Informações em arquivos ou fltotecas,
espec I f i cação de re I atór los,
programação da produção, etc.
processogramas, slstemogramas,
Projeto físico - Esgotadas todas as fi Itragens e refinamentos
202
necessários à elaboração dos
administrativo, passa-se a executar
projetos
o proj eto
lógico
físico
e
dos
sistemas, com a uti I ização das ferramentas disponíveis, desde
geradores de códigos até I inguagens de quarta geração
compatíveis com os equipamentos de processamento de dados da
empresa; se houver necessidade rea I i za-se, também,
refinamento do projeto de hardware, rede,
na seleção do software (operacional e
telecomunicações
de apoio, SGBD
um
e
e
linguagens de programação), de modo a assegurar que esses
recursos sejam os mais adequados à construção da estrutura
física que suportará os sistemas.
Não serão apresentados detalhes desse n í ve I de
representação, porque o mesmo já se refere à implementação de
sistemas específicos, fugindo do objetivo desse trabalho.
Nosso propósito é apenas de posicionar esse nível de
representação numa visão geral da especificação de sistemas.
As Informações tratadas compreendem: o projeto
lógico, o projeto administrativo, as características do
hardware, rede e telecomunições, as características do SGBO e
das linguagens de programação.
Os resultados esperados compreendem, Projeto físico
dos depósitos de dados que se constitui da determinação dos
dados elementares que compõem um depósito de dados,
especificando-se a forma de organização de tais dados (ordem
de acesso, forma de agrupamento, dispositivo físico de
203
armazenamento, etc). HierarqUização de sistemas que se
dos constitui na representação da estrutura operacional
sistemas através de um esquema semelhante a um organograma,
em que as I inhas de Igação representam formas de acesso a
determinado módulo. Processogramas que se constituem na
representação dos recursos técnicos envolvidos na execução de
cada módulo ou unidade de tratamento do sistema (conjunto de
processos agrupados sob uma mesma rotina de processamentos).
Rotinas e Programas correspondentes aos processogramas,
observando-se que a rotina ou rotinas
processogramas devem ser convertidas em
derivadas
programas
doS
de
computador, na linguagem adotada pela empresa. Podem ser
utilizados, ainda, lay-outs de relatórios e telas.
Projeto de Programação - Essa etapa estabelece a distribuição
das atividades de programação pelas equipes de programação
existentes na empresa. Em função do volume de atividades a
ser desenvolvido pode haver necessidade de realizar
contratação de mão-de-obra extra para agi I Izar a conclusão
dos sistemas.
As informações tratadas compreendem, Submodelos de
Dados, Diagramas de Dados, Diagramas de Fluxo de Dados,
Diagramas de Estrutura Modular, Projeto FíSico dos Depósitos
de Dados, Processogramas, Rotinas derivadas dos
Processogramas, lay-out de relatórios e telas.
05 resultados esperados compreendem, Programas de
Computador na linguagem adotada pela empresa.
Implementação e Testes Essa etapa se preocupa com a
integração das novas aplicações ao dia a dia de nossas
organizações. Dependendo do ambiente empresarial esta
transição (do ambiente antigo para o n o v o ) pode ser
extremamente complexa.
Para empresas com pouco investimento em automação
de processos de gestão, a fase de Implementação se limita a
comparar o novo mOdelo com os antigos procedimentos. Quando
houver certeza de que é possível executar os processos ao
menos tão bem quanto antes podemos começar a substituir os
antigos procedimentos pelos novos com algum grau de
confiança. Ocorrerão problemas, e, programas e procedimentos
deverão ser modificados. Normalmente, ava I i ações serão
rea II zadas pe I os usuár I os e ana II stas para dec I d I r o que deve
ser feito dentre as alternativas que se
preservar a integridade do proJeto
apresentarem. Para
e os objetivos
estabelecidos é essencial estabelecer mecanismos de controle.
Uma metodologia bem entendida e
a I nda o I nstrumento chave para
obJeti vos dos novos 51 stemas.
uniformemente
sustentar o
aplicada, é
controle dos
Para empresas com algum investimento em automação
de processos de gestão, a fase de Implementação, além dos
cuidados mencionados acima, deve se preocupar
perturbações que a Introdução de novos
com eventuais
sistemas
acarretar para os sistemas antigos que continuarão
pode
em
205
operação. É natural que uma concepção totalmente nova não
esteja Integrada com sistemas antigos que ainda deverão ser
substituídos. Essa falta de Integração desorganiza a
estrutura de dados que subsidia os processos dos sistemas
antigos, que continuarão operando, obrigando os usuários
desses sistemas a esforços adicionais para aproveitar os
dados originados e para preparar os dados destinados
respectivamente nos e aos novos sistemas. A necessidade desse
trabalho adicional estimulará a reação dos usuários
prejudicados e tende a desestabi I izar o comprometimento dos
usuários com os objetivos do projeto. É necessário portanto
que, d u r a n t e a e I a b o r a ç ã o do P I a n o O I r e t o r d e I n f o r má t i c a ,
quando da definição da ordem em que os proJetos deverão ser
desenvo I v i dos (def i n i ção de pr I or Idades), seJ am
os reflexos que a Implantação dos sistemas,
cons i derados
na ordem
pretendida, acarretará no desenvolvimento das atividades do
dia-a-dla. Uma estratégia que reconci I ia estas dificuldades é
selecionar aplicações para todas as funções, fortemente
articuladas, de modo a estabelecer benefícios para todos os
usuários e reduzir os esforços adicionais, além de
distribuí-los por um maior número de usuários.
Revisões e Ajustes São rea II zados durante a fase de
Implementação e testes. São modificações no projeto ou em
programas, de modo a estabelecer uma relação mais amigável
entre o sistema e o ambiente ou eventualmente corrigir erros
detetados durante a Implantação.
206
Operação - Nessa fase o sistema é colocado à dispOSiÇão dos
usuários para produzi r os seus efeitos. É
manuais de usuário e de produção descrevam
Importante
as rotinas
que
de
relacionamento de usuários e operadores com os sitemas e
equipamentos.
Manutenção - A partir do momento em que o sistema se torna
parte das operações da empresa nos Ingressamos na etapa de
manutenção. A manutenção de software e o modo de abordá-Ia é
o mais difíci I de todos os problemas a serem enfrentados. A
cada ano o estoque de aplicações úteis cresce e com Isto
cresce o esforço de manutenção a ser real izado. A crença de
que a necessidade de aumentar o esforço de manutenção decorre
da dlspl icêncla ou incompetência dos programadores foi
superada pela conclusão de diversas pesquisas. Para empresas
que adotam procedimentos clássicos de desenvolvimento de
sistemas a relação entre o tempo de desenvolvimento e o tempo
de manutenção se situa entre 70% / 30% e ~O% / 60%; para
empresas que adotam procedimentos que incluem as técnicas
modernas de planejamento de sistemas a mesma relação se situa
entre 95% / 5% e 80% / 20%.
A manutenção de software contém três componentes.
Há erros genuínos que devem ser determinados, há mudanças que
ocorrem na empresa em decorrência de transformações no
ambiente, e finalmente mudanças determinadas pela lei.
As relações entre os tempos de desenvolvimento e
207
manutenção no ambiente clássico e no ambiente das técnicas
modernas de planejamento permite conclui r que a maioria dos
problemas detetados decorre das ambigüidades ou entendimento
equivocado que são gerados nas etapas de definição dos
requerimentos e planejamento estratégico. Essa
permi te I nfer I r que as três componentes de
estariam sob um controle muito melhor se uma
constatação
manutenção
forte e bem
entendida metodologia tivesse sido utl I Izada desde a fase de
planejamento. Se uma estrutura de programas está sob
controle, a inserção de diferentes funções pode ser feita de
modo controlado. Se uma metodologia de controle tiver sido
utilizada, a etapa de análise de necessidades pode ser
aval i ada de trás para frente de modo a examl nar o Impacto que
os entendimentos equivocados poderão acarretar. Uma conclusão
é I nev i táve I: uma abordagem di sc i P I I nada, qua I quer abordagem
disciplinada, é essencial. Os gerentes devem ajudar a
selecionar a abordagem que se ajusta melhor com as propostas
existentes para planejamento estratégiCO e
necessidades.
análise de
Treinamento - A atividade de Treinamento deve ser orientada
para os usuários e os profissionais de processamento de
dados. O tre i namento deve ser rea II zado de forma contí nua de
modo a estabelecer ou complementar a capaCitação das equipes
comprometidas com o projeto. Os conhecimentos demandados para
a real ização de cada etapa devem ser exercitados antes da
realização da etapa. A gerênCia do projeto deve articular a
programação de treinamento com o programa de execução das
208
diversas etapas de modo a assegurar a capacitação necessária
à manutenção do fluxo contínuo das atividades. A importância
da sustentação dO nível de competência sugere que seja
treinado um número de usuários maior ( cerca de 25% ) do que
o pressumlvelmente necessário para a elaboração do projeto;
essa precaução se faz necessária porque as maiores perdas em
participação ocorrem exatamente no ambiente dos usuários.
As Informações tratadas compreendem: livros,
apost i I as, rev I stas espec I a I i zadas, documentação produzida
por fornecedores de equipamentos e software.
Os resultados esperados compreendem: Elaboração de
um Programa de Treinamento orientado para os seguintes
conhecimentos:
Pol ítica e Estratégia de Empresas
Metodologias de Planejamento de Sistemas
Metodologias de Planejamento de Sistemas de Informação
Metodologias de Modelagem de Dados
Metodologlas de Diagramação de Fluxo de Dados
Técnicas de Projeto Estruturado
Hardware, Rede e Telecomunicações
Sistema Operacional, Software de ApOio e Linguagens de
Programação
Sistema Gerenciador de Banco de Dados
Gerência de Banco de Dados
Administração de Dados
209
Ferramentas de CASE
Operação de Sistemas
O programa deve estabelecer o cronograma de
elaboração do material didático, a previsão de salas,
auditórios e equipamentos, a re I ação dos participantes
(instrutores e alunos) por curso, a cooperação de
fornecedores de equipamentos e software.
A figura a seguir oferece uma visão simplificada do
produto alcançado nas principais etapas de elaboração da
arquitetura global dos sistemas e do
ap I i cações.
210
desenvolvimento das
ANÁLISE ORGAHIZACIONAL
PROJETO LÓOICO
PROJETO AOMINISTRATlVO
PROJlTO rlSICO
p,
PRINCIPAIS ETAPAS DO PROCESSO DE DESENVOLVIMENTO DE SISTEMAS
PROCESSOS DADOS
'-. :~ LO
L'
.., i=]L-{1 ... •
I: : o., f=~~
~, I' , ' ...
, , , , , ,
, , '
DF'
~~%~'í:g, DO ... ... u
.~. -ATlylDADE
. -c -
U!UARIO
•
PROCESSO
.' PROIRA."
§ ROTl • ..., [11 PIIO;UIIU
211
USUARIO
•
o
ORa O PROCESSAIIIEIITO
Ô Q Q PRODUTO FíSICO DOS ARQUIVOS
I I I
1- DICIONÁRIO OE DADOS
!. OICIOIIMIO M PROJETO
I~I
-+-+-++-+-+-1--+-1-+-+-+-+-+-+--+-+-+-+--1 APnO I c E I I I I-++++-i
iU O 1°
lo 10
O • 212
8
10 O
lI'~p IEND][ elE J[ v
OUTRAS DECISBES
214
Neste apêndice são descritas as condutas
decisões relacionadas com a seleção
que
de
orientaram
SGBO; com
as
o
treinamento orientado para a administração de dados, banco de
dados e modelagem de dados; e, com a Organização das equipes
e diretrizes para a elaboração do proJeto lógico, nesta
ordem.
215
I Seleção de SGBD
Como foi mencionado anteriormente, a empresa
acumulara muita experiência em sistemas suportados por SGBD.
Essa experiência tinha se desenvolvido com o uso de um
produto que denominaremos SGBDA, Implantado no equipamento
da sede, que denominaremos TECNOLOGIA A, para suportar
sistemas de Interesse, fundamentalmente, da Administração
Centra I. O G. C. cons i derava mu i to prováve I a ut II i zação pe los
Distritos de equipamentos da TECNOLOGIA B, formando uma rede
cuja finalidade principal seria a de suportar a automação de
processos de produção. Considerava-se Importante que o SGBD
Implantado nessa nova rede oferecesse as condições mais
adequadas de produtividade e desempenho. Com base nessa
motivação foi elaborado pelo órgão de Procesamento de Dados
da sede da empresa o procedimento para a aval iação de SGBD
utl I izado para selecionar o produto que foi
empresa.
adquirido pela
É Importante notar que a questão não se resumiria a
uma simples eSCOlha entre dois produtos. A experiência de 8
anos com o SGBDA representava um Investimento multo alto;
portanto, a adoção de um novo SGBD, com ou sem substitUição
do SGBDA, só deveria ocorrer se fossem Identificados, no novo
produto, características de desempenho e produtividade que se
traduzissem em benefícios perfeitamente quantificáveis.
:':?:í.ó
foram considerados os seguintes aspectos:
1. Um único "Banco de Dados Lógico" resulta nos seguintes
benefícios para uma rede de Informática de gestão:
uma única linguagem de programação e de acesso aos dados
para todos os centros de processamento de dados da rede
de Informática de gestão e para todos os usuários não
especialistas;
uma mesma estrutura de armazenamento de dados em
qualquer ponto da rede;
uma mesma metodologia de proJeto e
arquivos;
"desenho"
distribuição física dos dados pelos vários centros;
garantia de "back-uP" por toda a rede;
de
mesmo padrão e cultura de suporte e administração de
Banco de Dados por toda a rede;
ganhos em escala com o custo de manutenção do sistema
gerenciador de banco de dados.
2. I nvest I mento rea I i zado no SGBDA:
2i7
. 6.525.835 registros implantados;
6.822 módulos programados na
associada;
linguagem de 4ª geração
235 ana listas e programadores faml I i ar I zados com o
produto;
400 usuár I os f I na I s não espec I a I I stas tre I nados na
linguagem de consulta;
sistema de acesso ao banco de dados, programado pela
empresa, para dar suporte a usuários sem nenhum
treinamento em BD;
. sistemas desenvolvidos para:
projeto, armazenamento e manipulação de tabelas;
dicionário de dados a nível conceituai
dicionário de dados a n í ve I lógiCO;
controle de uti I i zação;
contro I e de área;
gerência de bibliotecas;
n í ve I de utilização diário (média) de 3.972.666
transações;
. dlsponibll idade, Integridade e segurança no ambiente de
satisfação geral com o produto;
satisfação geral com os serviços de suporte;
performance;
suporte do vendedor;
operação.
percentual de usuários ativamente InteressadOS em
substituir o SGBD, quantificando os que o faziam por
motivo de insatisfação com a performance;
ava I i ação do me rcado financeiro com re I ação ao
desempenho da empresa fornecedora.
Fontes de Consulta:
. Artigo assinado por Ralph JenKs, da Control Corporatlon
Computerworld, maio, 1985 - "Dle-hard COBOl: programmers
try Natura I and II Ke I t"
Setzer, Waldemar - "Banco de DadOs - Conceitos, Modelos,
Gerenciadores, ProJeto lógico e Projeto Físico"
Editora Blucher, 1986
Inbucon Informatlon Technology "4th Generatlon
languages and Advanced Software Development Aids", 1985
banco de dados não ocorrem atrasos ou erros
ocasionados pelos produtos nos sistemas mesmo para
aqueles submetidos a manutenções frequentes;
número de terminais que utllzam o banco de dados: 270;
equipe de administração de banco de dados
permanentemente atua I I zada.
3. Consulta a ava I I ações rea I I zadas por revistas
espec i a I i zadas com re I ação a:
produtividade dos analistas de dados envolvidos com o
projeto de novas bases de dados (produtividade medida em
termos de comparação do volume de mão-de-obra necessário
para alcançar o mesmo volume de produção na mesma
unidade de tempo);
produtividade da I inguagem de programação de qª geração
associada ao SGBO medida em termos de comparação com
linguagens do tipo CaBal;
satisfação dos usuários, medida por uma pesquisa que
analisou 21 produtos distribuídos em 792 instalações
oferecendo os seguintes resultados:
escala de pontos variando de 10 a 9 (superior), 8 a 6
(muito bom), 5 a 3 (aceitável) e 2 a 1 (inadequado)
atribuídos para as seguintes características:
21?
Datamation, dezembro 1984,
partir da página 85
"PeSqUisa de Software" a
· "Financiai World" - agosto 1985
· "Washington Post" - 6 de maio de 1985
Conclusões do Processo de Seleção
Considerando:
1. que a aquisição de mais de um SGBD implicaria em:
· pagamento do produto e taxa de manutenção de dois SGBD;
equipes de suporte para os dois ambientes (acréscimo de
2/3 no valor da mão-de-obra existente);
ampliação de recursos de máquina na sede (memória,
disco) para suportar os dois ambientes de Banco de
Dados;
ampliação dos recursos humanos para operação e gerência
dos dois ambientes.
2. que a substituição do SGBD existente, a I ém das
repercussões mencionadas acima, acarretaria em:
· quebra da integração do Banco de Dados;
acréscimo de 50~ dos recursos de mão-de-obra de
desenvolvimento e manutenção;
conversão dos sistemas implantados.
3. a conveniência em manter:
mesma I inguagem de programação e acesso, permitindo
produtividade e hOmogeinlzação das tarefas dos
programadores e dos usuários finais;
mesma estrutura de armazenamento dos dados, permitindo a
qualquer sistema desenvolvido em um ambiente, ser
processado no outro;
descentra I i zação do banco de dados pe I a rede, permi t Indo
economia de transmissão.
"I. que os resultados do benchmark possibilitaram afirmar que:
os SGBO ana I Isados, apesar de apresentarem estilos
diferentes, pertencem mesma "geração de
produtividade";
que os produtos ana Ilsados tendem a apresentar
performance equivalente,
r) 'I"} (: •• ': •• 1:' ••
Recomenda-se:
Que seja adquirido o SGBDA existente no ambiente de
tecnologia A para o ambiente de tecnologia B.
Concluído o processo de seleção do SGBD, foi rea I I zado um
teste no equipamento de Tecnologia B para avaliar a sua
capacidade de processamento quando submetido a diversas
condições de uti I ização. O G.C. pretendia determinar o
limite de solicitações por processos simultâneos, no
ambiente do SGBDA, sem que houvesse degradação do tempo de
resposta. Essa Informação era necessária para que o projeto
de rede pudesse ser real izado de modo a assegurar o nível
de qua I i dade e di spon i b III dade adequado à operação dos
serviços da empresa.
I I Treinamento orientado para Administração de Dados, Banco
de Dados e Modelagem de Dados
A rea I i zação desse tre i namento fo I precedida pela
leitura do livro "Banco de
Gerenciadores, Projeto Lógico
1986), do qual Já haviam feito
Dados, Conceitos, Modelos,
e Projeto Físico' [Setzer,
uso os profissionais que
participaram do processo de seleção de SGBD.
A ênfase do treinamento foi orientada para o
processo de modelagem de dados, especificamente para a
proposta de modelagem conceitual de dados apresentada no
XVIII Congresso Nacional de Informática (Rêgo, 1984J. O G.C.
considerava que a técnica de elaboração de Diagramas de Fluxo
de Dados já era perfeitamente dominada pelos profissionais da
empresa.
A dinâmica do treinamento seguiu os padrões
tradicionais: exposição teórica e realização de exercícios.
Foram treinados profissionais de processamento de
dados e usuários dedicados a todos os módulos e Identificados
pela BSP.
O objetivo era estabelecer uma base comum de
conhecimentos que possi bllltasse a formação de grupos
homogêneos, constituídos por analistas de sistemas e
usuários, que se dedicariam ao projeto lógico dos sistemas
correspondentes a cada módulo identificado pela BSP.
Para reforçar a representatividade (e o
comprometimento), cada grupo teria um gerente usuário
(usuário especial izado da Região ou Departamento responsável
pelo desenvolvimento do sistema), um coordenador técnico
(analista de si stema da Região ou Departamento responsável
pelo desenvolvimento do sistema), e, pelo menos um usuário de
cada Região e Departamento (quando afetados pelO sistema).
processo
Admitiu-se, também, que haveriam
de treinamento, decorrentes da
perdas, após o
dificuldade de
assimilação, pelos não profissionais de processamento de
dados, das habl I Idades necessárias à elaboração de um projeto
lógico de sistema. Para fazer face a essa Incerteza, o G.C.
programou o treinamento do dobro do número de profissionais
Inicialmente estimado.
do pessoal
atribuídas
Durante a fase de proJeto ocorreu uma perda de
treinado. As causas dessas perdas podem
aos seguintes fatores: maior afinidade
envolvimento com outras atividades, dificuldade
ass iml I ação das hab I I idades, res i stênc i a às mudanças,
45'10
ser
ou
de
falta
de confiança no empreendimento. De um modo geral a
resistência às mudanças se manifestou entre profissionaiS de
processamento de dados não fami I iarlzados com a modelagem de
dados.
Observe-se que não houve um processo de seleção da
técnica a ser uti I Izada. O G.C. adotou os métodos praticados
pela empresa, para os quais já se havia desenvolvido sól ida
experiência, e algumas ferramentas compatíveis com o SGBDA.
O treinamento orientado para a Administração de
Dados e Administração de Banco de Dados foi oferecido apenas
para os espec i a I i stas das Regiões e Departamentos
especificamente dedicados às funções de Administração de
Dados e de Banco de Dados.
I I I Organização das equipes e diretrizes para a elaboração do
projeto lógico
Concluído o treinamento e definida a arquitetura
dos sistemas, foi possível Iniciar o projeto lógico.
Para o G.C. a dimensão da tarefa, a diversidade de
serviços e ambientes, a diversidade de volume de transações
por ambiente, a necessidade
áreas na mesma loca I I dade ou
de
em
comunicação
loca I idades
entre d I versas
necessidade de manter sob controle o conj unto
diferentes,
(imenso)
a
de
faci I idades associadas a um também multo grande conjunto de
unidades de serviço, exigiam o esforço articulado de um
grande número de especialistas (usuários). Por outro I ad o,
devido à natureza da atividade
conceitual) o G.C. considerou que a
um
(processo de construção
elaboração do projeto
deveria ser rea I i zada por número reduzido de
profissionais, o que favoreceria a comunicação entre as
pessoas e conseqüentemente a determinação e a
do modelo concebido.
representação
Para o G.C. a primeira condição (ou exigência) está
relacionada à necessidade de se projetar sistemas que atendam
aos requisitos dos usuários (eficácia), a segunda condição
está relacionada com a necessidade de se alcançar os
resultados no menor tempo e com o menor custo (eficiência).
A dinâmica estabelecida pelo G.C. para superar a
contradição foi a seguinte:
constituiÇão dos grupos de desenvolvimento com
participação, em cada grupo, de pelo menos um usuário de
cada Região e Departamento. A coordenação de cada grupo de
desenvolvimento foi atribuída a um gerente usuário
auxl I lado por
técnico);
um analista de sistemas (coordenador
para cada módulo Identificado pela BSP foi constituído um
grupo ao qual se atribuiu a responsablll dade do
desenvolvimento do prOjeto lógico (Diagrama de Fluxo de
Dados, Modelagem dos Dados, Diclonarização dos Processos,
Dados e Atr i butos);
todos os participantes dos grupos receberam os resultados
obti dos com a apll cação da BSP, receberam o treinamento
sobre modelagem de dados e foram orientados com relação à
dinâmica do trabalho;
cada grupo deve se reun i r Isoladamente objetivando
estabelecer o modelo do sistema de sua responsabi I idade e
as interfaces com os outros sistemas;
periodicamente deve ser rea I I zada uma reun i ão dos
coordenadores (gerente usuário e coordenador técnico) de
todos os grupos, objetivando universalizar a visão do
modelo global e estabelecer a solução mais adequada das
227
interfaces;
as reuniões de grupos e de coordenadores devem ser
supervisionadas por um profissional com experiência em
modelagem de dados e diagramação de processos.
Nesse ponto lembramos que, no Início do processo,
haviam sido Identificadas duas alternativas para orientar o
processo de planejamento: a primeira considerava os sistemas
existentes como base para a solução definitiva, enquanto a
segunda desconsiderava o desenvolvimento sobre essa base. A
decisão do G.C. elegeu a 2ª alternativa porque era
considerado oportuno estabelecer
fundamentadas.
bases conceituais bem
A construção de bases conceituais bem fundamentadas
era considerada pelo G.C. como questão central do proj eto
lógico. A Informatização não deveria ser
dos processos operados no dia a dia
I Imitada à automação
da empresa. Se r i a
necessário portanto real Izar um exercício de crítica dos
conceitos já estabelecidos. Esse exercício era considerado
pelo G.C. muito di fiei I, pais
(profissionais de processamento de
são poucas
dados ou
as pessoas
usuários) que
conseguem perceber com clareza a distinção entre a rea I idade
concreta e a representação mental que se faz da real i dade, e,
que essa representação mental pode ser alterada a fim de
assimi lar os diferentes aspectos da Natureza em relações que
sejam eficaz e eficientemente úteis à condução da ação
empresarial.
A fim de explicitar o que deveria ser entendido
como base conceituai bem fundamentada, foram
por especial istas de processamento de dados,
I dentl f i cadas,
em uma RECOR
promovida pelo G.C., as propriedades que os sistemas a serem
projetados deveriam ostentar e a conduta de projeto a ser
observada durante o processo de modelagem, para assegurar o
resultado pretendido.
Propriedades do sistema (modelo lógico):
Integraç~o - caracteristlca dos sistemas nos quais cada uma
de suas partes componentes se completam ou complementam,
sem haver superposição.
Estabi I idade - característica dos sistemas cujo
equl I íbrlo é pouco afetado por perturbações.
estado de
Eficácia - característica dos sistemas que produzem o
efeito desejado.
Eficiência - característica dos sistemas nos quais o ato de
produzir ocorre de forma adequada e/ou vantajosa e/ou
lucrativa.
Invariância característl ca
grandezas (conceitos) que se
dos
mantêm
sistemas que possuem
constantes quando o
sistema se transforma (quando muda o ambiente ou o
serviço).
A eficácia é uma propriedade relacionada com a
capac I dade de di scern i r a or I entação para os obj etl vos
corretos.
A integração e a eficiência se relacionam com a
capacidade de conceber e operar estruturas de mOdo otimizado
do ponto de vista lógico e econômico.
A estabi I idade se relaciona com a capacidade de
conceber estruturas invulneráveis a perturbações.
A eficácia e a Invariância não confl itam entre si e
nem com nenhuma outra propriedade. Integração e eficiência
cooperam entre si. Eficiência não confl ita com establ I idade.
Entretanto integração e estabi I idade são propriedades
conflitantes, Isto é, um modelo que tenha sido concebido de
um modo tal que cada uma das partes estabelecesse multas
vinculações com as outras (acoplamento forte entre as partes
Integradas) será fortemente perturbado se ocorrerem
alterações em qualquer uma das partes.
Para superar o conf I I to Indentiflcado entre as
propriedades e assegurar a eficácia do processo de modelagem
(produzir um projeto lógico com as propriedades desejadas)
foi delineada, pelo plenário da REGOR, a seguinte conduta de
~)30
proJeto:
- manter a arqu I tetura a I cançada pe I a apl I cação da BSP
como um objetivo permanente;
2 - considerar que o sistema é um recorte da rea I Idade
constituído por partes que são
9 loba I ;
recortes dêste recorte
3 - estabelecer distinção entre processos que manipulam
(i nc I uem, exc I uem, atua Ii zam, lêem) obj etos, a f im de
registrar as ocorrências do processo produtivo e as
ocorrências que Interessam às decisões gerenciais, e
processos que dão suporte às decisões e ao controle
empresarial. Esses processos devem operar completamente
desacop lados, de modo a não comprometer a estabi I idade
global do sistema;
4 - considerar que processos e objetos são recortes
elementares, cuja conceituação deve ser apropriada
sempre que se revelar úti I para a construção de um
modelo com as propriedades desejadas;
5 - a articulação entre os recortes que constituem as partes
do sistema global devem ser estabelecidas de modo a
produzir um acoplamento fraco;
6 - o acoplamento entre os elementos que constituem cada uma
das partes do sistema gl oba I pode ser rea I i zado de modo
a estabelecer uma forte coesão;
7 - a articulação entre os recortes deve ser realizada pelos
objetos situados na fronteira entre os recortes.
objetos deverão ser rigidamente controlados
Esses
para
assegurar a eficiência do processo de modelagem e a
estabilidade do modelo, mesmo se vier a ocorrer alguma
redundânc I a;
8 - consl derar
serviço;
cada processo primitivo
9 - considerar cada processo complexo
encadeamento de processos primitivos;
10 - cada serviço deve ser controlado
(como sendO)
(como sendo)
para fins
estatística de uso e melhoria do Sistema;
11 - o processo de aprimoramento do modelo conceituai
um
um
de
deve
ser Interrompido quando não houver expectativa de ganho
de produtividade que
empreendido;
remunere o esforço a
12 - observar que a integração ocorre na estrutura
ser
de
objetos, particularmente através daqueles objetos que
são comuns a várias funções, isto é, o processo complexo
é específico de uma função, mas, cada processo primitivo
~.~32
apreende uma mudança de estado de um determinado aspecto
da rea I idade, aspecto que pode se const I tu I r em atr I buto
de diferentes objetos. Desse modo, não deve existir mais
de um processo primitivo para a mesma finalidade,
devendo-se, entretanto, fazer uso desse processo
primitivo único para construir processos complexos e os
objetos através dos quais se estabelece a comunicação
entre funções. A dependência do processo primitivo a uma
determinada função será decidida pelo critério de
precedência.
Os diagramas a seguir representam os resultados
parciais alcançados em dois momentos do processo
e I aba ração do projeto I ó g i c o . No primei ro momento
de
foi
apreendida a visão global do sistema; no segundo momento foi
apreendida a visão de um recorte dessa visão global. Em todos
os momentos o modelo reflete perfeitamente a arquitetura
global gerada pela BSP.
Para o G.C. a preocupação em identificar
propriedades do sistema e condutas de projeto, resultou da
compreensão de que o processo de modelagem é eminentemente um
processo de criação, de construção conceitual; a partir desse
entendimento, os princípios e condutas auxl I iam o processo de
determinação dos resultados a serem alcançados. Esses
princípiOS e condutas emergiram durante a elaboração do
projeto, resultantes das Indagações sugeridas pelas
dificuldades encontradas.
Para o G.G. as técnicas de normalização são
ap I i cáve i s a estruturas conceptua I s já estabelecidas e
auxl I iam o processo de depuração dessas estruturas. O
processo de modelagem, por outro lado, é um processo de
criação através do qual o analista pretende explicitar a
realidade, constituindo-se, portanto, em um processo de
elaboração que tira partido da capacidade criativa dos
ana I Istas da rea I Idade, que têm, como únicos elementos de
orientação coletiva, o conhecimento comum da realidade, dos
objetivos a serem alcançados, das prioridades entre sistemas
e das condutas de projeto a serem consideradas.
234
VISAO GLOBAL
iiiIiiiMiiiiI&Iili&IiU4li Mi!DMIJiiIi5i IRNIMMi!priiQi§j8ign.
SOLlCnACAO ORDEM FACILIDADES CLIENTE SERVI CO E>:ECUCAO -
fACI~IDA~ES EOT A RE UNE AR CPS
CLI ENTE RECLAH PEDIDO US E:LO~UEIO OE
DES :LOQUEIO FACILIDADE SOL -E:LOQUE I O DESE:LOQ-DESL
SOL-SERVI CO
Cf'S SOL-BLOQUEIO DESE:LO~-DESL
PA6A EFETUA A ITEM-US-REAl-PROHTA US-f"EH[lEHTE
F' - 3 f' - 2 F' - 4 REClAKAC lTEH-US-REAl-APRAZ U5-F"ROVI50RJA
CF'S FATURAR ITEK-US-(OKER ATENDER I ADKINISTR
E I'~O"H FACILIDAD ,-.----i COBRAR USUARIO MEDIDA UNIDADES UTI l IZAC .. V5 REC lAKA[IA jV5-I'ROVI50RIA SERVICO ! SER!,.' I (OS • ITEK-V5-R:j F
USU V5-RECLAKA~A • • APRAZA[IA A
It~A(IIK I C
usu ITEH-US-COKERC-PRONTA ITEH-US-REAl-PROHT I I --- &:iii\IlItil!WIlllOl1lDll I L
MEDIDAS CLI ENTES UNIDADES Us-tROVISORIA-APRAZADA I I
- SERVICOS I [o
OE-8LOQUEIO-[IEStlOQ r-- - - - -- _. _.J A I [o
OE-REC LAKACAO I E I I I I
lTEH-US-(OKERCIAl-PROHTA I I FACILIDADES
US-F"ROV I SOR 1 A-Af"RAI I
I I I I FAC lL FAC IL
CLI ENTE ftNHMiliNUriMiUlli I TRAH5- CO.VT
UNIDADES I
rOL-SERVICO-CO"C LVIDA I SERVICOS I I I f' - 5 I
F' - 1 I MEDIR I UTILIZAC
SOLICmC VENDER I
SERVICO SERVI CO US-f"EH(lEHTE I I
~L-5ERVlCO I MEti 1 HE[II
I I IRAW' (OliUT
Of.;DEHS I EXECVC.O I
OE I MEDIDAS
• , I I s.OL-cmnATO I I I
I I
'E[lIDO-DESATIVACAO P - 6 I F' - 6 I
I I
CLI ENTE "[DIDO-CAMCElAHEHTO MANTER I OE AVAL IM~ I
SERVI CO L._~~ __ 4 __ 4_M* (IESEHf"EHH ~~c,ic'~~ PEDIDO-AlTERA(AO OE CONCLUIDA OF"EF;IAC IOH SISTEKA _.
DFD ô. f'r-oôucao Int.egr·acao 82/82/88 (INTPROD)
-
235
I I I CaI'!ERCI~llz~c~a I
I I I I
I I
I I
I USU~RIO I
I I
I I
I I
I
I
I
I
OR~EM p~'~ SOLIClT~C~O I SERVICO I
• r-' I I I
I I F~C ILI D~DES I ~EDICOES I--~-------- ------------ I'!ANUTENC~O I I
I I I I
D:-~ I
I I r-K I UHI~~DE DE ~;-+ ORDEM DE rACILIDADE f'OHTO I SERVICO
l..[~[U"O.J KEDIC~O
I I I I I I I I I I
I
I
J ITEM DE US
~!L I l'OF'OlO61CO I
Cf'S I
I D ACESSORIO MEDID~ I I rACILID~DE I I I ITEM DE UHl ~ADE
L ____________________ H • __
I DE SERVI O ~ I I
I I I ~ I ITEM DE US ACESSORIO I NAO TOf'OlOSICO HAO F~CILID~DE I
I I L ___________
········--·-1 I
A I I
r'" I I
I I
ITEM rATUR~HEHTO ~
ITEK rATUR~KENTO I I
f O M~DIDA POR US POR I TEM DE US I I FATU 'AHEHTO
I ATENDI~ENTO USUARIO I
I I
A I I I I I I
I I I I
FATURAi'lENTO ITEM I I
r~TUR~MEHTO I I I I I
DO da Produc.o
Int.es,"c.o a2/a2/88 (INTEGRAl
,..."
_.-C SOLlC!TACAO ~ SOL, CA~CELAME~TO
CANCELAMENTO DE ALTERACAO
C --SOl. CANC[LAME~TO
DE ATlVACAO
C SOLlCITACAO -O
ATlVACAO
C C SOl! C !TACA0 kECLAMACAO u--
ALTERACAO
SOLl C !TACA0 ~~-{I> C SOLlC!TACAO ~O SOLlCITACAO f' OROEH SOl! C ITACAO ~-o f'kOf'OSTA/PkOJETO SERYICO BLOQUEIO BLOQUEIO --
- C SOLlC!TACAO f' ORDE~ SOl! C !TACA0 ---o ~
CONTATO DESBLOQUEIO DESE:LOQUEIO
C ~OLICITACAO f' ORDEM O ~ DESAT I VACAO DESATlVACAO
F' SOLlC!TACAO CONCLUI DA
[:~IEm p ~ USUARIO f' USUARIO USUARIO 1*--0
FATURAKE~TO I NADI MF'lEHTE --
DO da Producao
Co"erc i ai i zaCao
02(~2(a8 (Ca~ERC)
237
c I US I~ f' US o
f'ROVISORIA Af'RAZADA
~[~~;m I~ f' US O
CARTEIRA
COlO=
US
I· f' US
I O
ATIVADA RECLAMADA UNIDADE DE
SERVI CO
I C US
DESATl VOA
C US
CANCELADA
I C US
r.LOQUEADA
Cl ITEM DE US
f'ROVISORIO
Cl ITEM DE US
Af'RAZADO
D Cl ITEM DE US
I f'ENDENTE ITEM DE UNIDADE
SHVICO
I Cl ITEM DE US f' [TEM DE US
f'RONTO COMERCIAL
C2 ITEM DE US f' ITEM DE US --O
TOf'OL06ICO L061CO
C2 ITEM DE US f' ITEM DE US
NilO TOf'OLOSICO REAL DO da Producao
At.endi .. ent.o ao Usuar i o
1it2/1it2l88 (ATEr!DUSUl
238
I ~~~~
[ OE .• _ ACESSORIO
OE FACILIDADE
-
DE [ CO~CLUIDA
00 da Producao
Manut.encao a2/a2/BS (~A~UT)
:}C2
C2
• . C2
f'
-Cl OE
RECLAHACAO
Cl OE AL TERACAO
Cl OE ATIVACAO
Cl OE DESATIYACAO
ORDEM DE n:ECUCAO
~ Cl OE I CA~CELAM[~TO I I I I I I I Cl OE I I E:LOQUE I O I I I I I I I Cl OE I I DESE:LOQUElO I
r - - - - - - - , I Cl OE L. - •••••• - - - •••••• - •••• Oi I
DESVIO L ~ _ _ _ _ _ _ J
239
T1F'O D . HICILIDADE
m'o D ACESSORIO
UNIDADE MEDIDA
..
MEDIDA ANALISE-TRAFEGO
MEDIDA FATURAMENTO
MEDIDA AVALIACAO-
DO da Producao
Facil idade e Medica0 02/02/83 (FACIL~ED)
DESEMPENHO
FACILIDADE EOT
F'
FACILIDADE
ACESSORIO FACILIDADE
C
ACESSORIO
~p
P -t ~
f' 0-
FACILIDADE "7 f'OWTO
t
~ FACILIDADE COHEl:AO
C ACESSORIO NAO FACILIDADE
PONTO MEDICA0
( A A A
t- C MEDIDA ....
~
248
FACILIDADE
~j"~~O_W_TO __ DE_DI_C_AD_O-J
4!-
~ FACILIDADE PONTO COMUTADO
INTERVALO TEMPO MEDIDA
'" MEDIDA
TRANSMISSAO
MEDIDA INFRAESTRURA
MEDIDA COMUTACAO
ITEM UH IDADE
DE SERVICO
A r--- ,.., ITEM FATURAMEHTO
f'OR !TEM DE US
A r-'
ITEM DE
FATURAMEHTO
80 d. Peoducao
Fat.ural>ent.o
02/02/88 ( FATURA )
!TEM fATURAMEHTO "
POR US
c ] crs crs RECLAMADA C f'ASA
1"' r
CF'S
C CF'S
HAO PASA
241
.... sist.ema: sps
DETALHE ATENDI~ENTO USUARIO 85-p(·ocessament.o da (·ecl-se-r'v. ver-sao: 64/61/96 ar-qui vo: at.ud/"36 f'ag: 61/63
------------------------------~------I _.,----~
use-r-ee I amada
r-ec 1
61 I r-egist.r-arr-ee 1 amaeao
oloj-r-eel
...--...... ",J.... __ _
84 I
ELEMEHTOS TOPOL061COS
I A
USCS
r-ee 1
r'ee I-feet.- imp r'oe-sem-d i ag 62 I r'ecl-r'eir,c anal isar' r-eclam.
.---------------1 come r-c i a 1 mer,te r-e it
RECLAKACOES
r-ee 1- i ~ i e-aloe r-ta
DI A6HOSTlCOSI SERVI CO
r-.,.-'·'---
VASAS
63 I ger-ar- ottoes t.e-d i ag
di ag/r'ee I-nao-eor,e I us i vo di agr,os t. i ear' r'ee I amaeao
ot.-teste-diag
[,~,~.! " tes tes -----
o t-t.es t.e-p r'ogr'amada
DI A6HOSTI COSI
RECLAMACAO
diag-reelam-eo~clusivo ~ L--..:....--__ '\..:..)
ot-tes t.e-d i ag-exeeutada
Ol' S
ot-t.est.e-diag executada
r--'---.... ~6 I I
executart.es t.es
"------ --------------------------------------------,---------~
sistema. sps B~-F'r-oce55arneflto da f'ecl-ser-v. ver'sao: 84/61/98 ar'quivo: atuof3! f'ag: 82/83
ot.- r·ec 1 85 I I E: o i ag/r·ec 1-cor.c I us. i \10 pr'ogr'amar' execu- ot-~ec I-pr'ogr-amada
cao o t - r·e c I 1----1r----""--"-----,
84 I I E:
ger-ar' ot-r'ec I
f AO
OT'S
i tem- fatti~amento
18 I g"'a~ i tem fatur'amento
usuar-j o
~---"--ver- in ca.r' corlc I u s.ao f'eeupe f'aeao
t
ot- r·ec 1- fech
r·ec I-conc I ti i da
r·ec l-cone I ti i da
r·ec I-par-a-noyo-o i ag
243
ot-r-ec 1- fechaoa
f:ECLAMACOES
DIA6HOSTlCOS/
RECLAMACAO
di ag- r-ec 1- f'echaoo
8f. ! E:
executar' ot-~ec I
ot.- ~ec 1-fech
87 I "eg i st~ar' fechament.o ot- r-ec I
ot.-r·eclfech-r.aoexec
ot- r-ec 1- fechexec-final
88 I fecharoiagnostico
-ema. $f'$
da r·ec I-ser'v, r'ocessament.o ao: 64/61/% ar'<fui vo: atudf32 F'ag: 83/63
I.ist. I às-p \ler'$
--di aglr-ec I-car.ce lado
. DIA6HOSTlCOSI
RECLAHACAO
,
I "
69 I ! P-ó i ag/r'ec I-a-cance I ar'
--!o car.ce I ar· o i agrtOs t. i co
~ j ar.a I i saro ot- f--fech-nao-exec
ot-a-cance I ar·
ot.-a-car,ce I u
69 ! l° -- cancelu ot
di ag/r'ec I-par-a-novas-ot.' s oi:-cance I ada
r·ec I-f'ar'a-novo-oiag
f I I I ! OT'S
diaynost.icar· ge r·ar· r·ec amacao ot.- r-ec I
-
-244
~ f'O~TO !LE. A F'O~TO
COm!AO A E:
f' f'
---_ .. f'O~TO Lo..
-CO~D! /
L1G
f' U --. ' _____ --IK---
I
f'
c' U - li I. I!
C
+ OE:J
RECL
REIT ~o
f'RAZO Ict--.
-L16
D, L RECL
c
REIT -r-- ..". -$
C c
RECL ~EIT FORA f'RAZO r-I' AE:ERTA
[RECL AE:ERTA C
PRAZO [)!f' O O If---.--.-I _._, ___ ,.J
C
R[CL AE:ERTA f'RAZO HAO
[)!f'DO
~ _____________ . ____ ~t
f'
f' U - E:
.
C --
RECL mc
c
c
~
RECL FECH
RECL rECH
IMf'ROC
245
f'
A, L
OT RECL FECH
~ WAO ~ D!ECUTADA
u..------l
• DIA6 / b
RECL J
-" A
CA~CELADA
[)!ECUTADA
,--CAUSA-~AO
D!ECUCAO
EL-TOf'OL
RECL DIA6/ SERV
A 1* smrco A REI~C
c
LCO
i 4 1EIA;! RECL rECH ~J
r- f'ROC 6RTl A C ~AO D!f'DA
RECL rECH f'ROC
1 c RECL rECH
f'ROC 6RTl A EXf'DA
;:.'46
PRINCIPAIS RESULTADOS
DO PRO..JIET"O
247
Neste Apêndice descrevemos os principais resultados
alcançados pelo proJeto real izado pela Telecomunicações S.A.,
de acordo com o enunciado no capítulo 4 item 4.5.
I Modelo Geral dos Sistemas
o modelo geral dos sistemas foi desenvo I V I do a
partir das aplicações identificadas pela BSP, e, resultou no
conjunto constituído pelos seguintes módulos:
Planejamento Estratégico
Planejamento Tático
Come rc i a I I zação
Atendimento ao Usuário
Fac i I idades
Manutenção
Medições
Faturamento e Cobrança
Material
Recursos Humanos
Serviços de Apolo
Informática
Econôml co F I nance I ro
I I Postos de Trabalho por Amblente-
Terminais
Ouantlflcação de
o segundo passo na elaboração da proJeto foi a
realização da projeção do número de postas de trabalho a ser
implantada em cada unidade operacional.
Projetou-se o pretendido número a parti r do
conhecimento da situação então existente, tendo-se o cuidado
de estabelecer parâmetros referentes tanto à diversidade de
porte das tarefas realizadas (em face à desigualdade dos
volumes de transação operados por diferentes unidades
operacionais dedicadas às mesmas funções), quanto às
diferenças do grau de uti I ização que se dá aos terminais (uso
de CPU), de acordo com as áreas de atuação em que são
necessários.
Assim, coerentemente com o modelo geral dos
sistemas, adotou-se uma classificação do conj unto de
atividades desenvolvidas em cada área operacional, com as
seguintes categorias e sub categorias (figura 1):
CLASSIFICAGÃO DAS ATIVIDADES POR ÁREA DE OPERAÇÃO
L ÁREAS SUBDIVISIíO DE SUBÁREAS ÁREAS
._.-_ ..
Administração Material ( MAr) (AOM) Serviços de Apoio ( S . A . )
Recursos Humanos (R.H.) Econômlco-Financeiro ( E . F . )
Comere I a II zação Comerciai (COM) (COM) Implantação ( I MPLl
Faturamentol Cobrança (F/C) Centro de Serviços e Informações (CS I ) Planejamento
'--. de Sl~ (ES I )
(cont)
,-------------I ÁREAS SUBDIVISílO DE
ÁREAS SUBÁREAS
---------------------t-----------t--------------------j
Técnica Telex
Dados
Transmissão (TX)
Laboratório (LAB) Di 5 tr I b • G e r a I (DG ) Infraestrutura(INF) Te I efon I a(TLf)
Oficina Centrais Multlplex Transdata/ RENPAC Oficina Modems Multlplex Rádio Centro de TV
(OFC) (CEN) (MUX)
(TRD/REN) (OFC.MOD)
(MUX) (RD) (CTV)
l--------t---Reclamação de Chamadas Central
(REC.CHA) (CEN)
Processamento
de Dados (PD)
i
Desenvo I v I menta e Manutenção Apolo Produção
(DES.MAN) (APO) (PRO)
~-----------~--------------~---------------------4 Gerência
L..... ______________ -----'
Superintendente Gerência Informática Gerência
(SUP)
( G I )
Engenharia (GE) Gerência Administração (GA) Gerência Comercialização (GC) Gerência Segurança Industrial (GSI)
_________ ._-'-__ uO..l! .,;;5ut.,JrLLI ,UJt 0-..0.11 e r a ç õ e s _ (n n P )
f I 9 1
Consistentemente, no contexto do critério adotado,
estabeleceram-se quatro níveis para a classificação dos
portes em que se distinguem as unidades operacionais,
adotando-se os parâmetros de 1 a ~,numa escala de sentido
ascendente.
Finalmente, atr I bu í ram-se med i das diferenciadas
para indicar os distintos graus de utl I Ização de terminais
(uso de CPU) em cada uma das áreas consideradas, adotando-se,
adicionalmente, diferenciá-Ias em relação aos respect i vos
n í ve i s atr I bu í dos aos portes das un idades operac i ona i s.
De tUdo resultou a tabela a seguir (figura 2), onde
se lê a quantidade de terminais Idealmente definida para cada
posto de trabalho, discriminadamente em função do porte das
atividades, da área, da subdivisão da área, da subárea,
segundo os fatores de utl I ização dos terminais.
A apl icação dessa tabela às situações concretas
resulta na indicação efetiva da quantidade de terminais a ser
alocada em cada caso conforme representado na figura 3.
As quantidades de terminais eventualmente sofreram
pequenas a Iterações determl nadas pe I a situação da loca I I zação
física dos órgãos de operação, tais como distribuição do
mesmo órgão em andares ou prédios diferentes, o que determina
o aumento do número de terminais.
Para o G.C. a SOlução ideal seria a construção de
uma matriz que registrasse o volume de transações por função,
Incluindo indicação do trânsito de Informações entre órgãos.
Entretanto, essa solução demandaria esforço de toda a
estrutura (e os custos conseqüentes) e não aumentaria
significativamente a precisão do resultado alcançado.
DISTRIBUlt~O DE TER~INAIS POR POSTO DE TRABALHO
I ;;;:; ~ 1 c",,,,, PC'F:TE e'E ATII.'I L'Ae'E
4 ~,
" 1 -' , M A T 'I- 3 " I: , 1 1 I A c' ri -'- 1'1_
E. F_ I 1 " F: _ H_ :.;: , ------
r' I) 11 2: 1
I M P L 1[1 2: 2: 1
C C· M F " r' 2: 1
r' ~, I 9 1\ 2: 1
P " I 1 1 D [1--
t----' -- -I) F' r' 2: 2: 1 ,
I
T'ELD: r' E N 2: 1 T _. 1 1
M li :( " 1 É
C me, ,..- REi~ 2: 1 C'AC'J)~. 1 1 rl
I)FC .111)D 1 1 I ---
M li :< 1 1 r-
I n: F: c' 1 2: " 1
~, -I r- T v 1 1
L A E: Z 1 1 [J
H'C-r----
c' Ei 1 D [I D
tn f--
I r~ F z 2: [I [I
CA f-
F:EC _ CHA 1 1 i r L F f-- 1 1 I r' E rl 1 1 _.
e'E" _ ~Ml 1(1 ~: C': 1
P. C' _ A P C' C': 1
P F: I) fi 5 [J (1--
f---A c' M _ E: _4 _2 E' . '
FAre'F: ---r' I) M _9 _8 E' - ' - c;
e'E T E r' , - , _ E. ~,
-~ _ 1
ur I L I Z AÇ~;I) f--F' • c' . 2.[1 1.5 1.D _ E,
c -' li P <: --
€i I 2:
€i E ~,
-'
6EF:~W::1 A €i A o "
€i C :::
Oi c -' I 1
1-._- --L' G' P 1[1 3 <: 1
- ,--i F~lrl)F: e'E L UTI LI LAtM
€i E F: _ E: - c; _2 - 'I
\ FtJ.IÇ(lES \ , ÃREA \ ATENDIDA \
SUP DOPA-POL01 DOPA-POL02 DOPA-POL03 DOPA-POL04 OOPA-POL05 DOPA-POL06 DOPA-POL07 OOPA-POL08 DOPA-POLOS DOP8 DOPe
DOPO DOPE DOPF DOPG
DOPH DOPI
OOPJ fX)P\(
!)OPL OOPN
OOPN-POL01 OOPN-POL02 DOPO DOPP DOPQ DOPR
DOPS DOPT DOPU DOPV DOPW
OOPX OOPY DOPZ DOP$
REG 11\0
QUANTIFICAÇ~O DE TERMINAIS
POR REGI~O DE OPERAÇõES
REGI~O A
TOTAL TOTAL ArXi cct1 TEG OPD GER LOCAL ÃREA
2 2 2 1 7 14 9 24 20 20 10 83 136
10 10 2 2 4 4 2 2
1 4 2 1 8 2 2 1 1 1 1
1 4 1 1 7 2 2
3 7 7 1 2 20 32 1 1 1 1
1 4 3 1 1 10
3 7 8 1 2 21 29 1 2 4 1 8
3 4 "1 1 2 17 25 1 3 3 1 8
3 4 "1 2 2 18 26 1 2 4 1 8
5 9 13 9 3 39 6S 4 4
1 3 3 1 8 1 2 3 1 7 1 2 3 1 "1 1 2 1 4
5 9 13 3 3 33 59 2 2
1 4 3 1 9 1 2 3 1 "1 1 3 3 1 8
3 4 8 3 2 20 45 1 3 4 1 9 1 2 4 1 8 1 2 4 1 8
52 114 164 42 49 421 421
Fig. 3
GlAI..I DE UT I L I ZAO\O
SIREHOTO GIREMOTO
119,8 138,4
1,7 18,4
14,7 16,1
10,2 10,6
9,6 1,0
40,6 43,8
31,2 32,7
17,5 18,2
261,3 289,2
I I I Relação terminais e processos simultâneos
Estabelecida a quantidade de terminais alocados em
cada local idade, com base no fator de uti II zação, foi
real izada uma estimativa do número máximo de processos de
natureza diferente com ocorrência simultânea, nos momentos de
mai ar movimento, em cada local idade.
Os resultados dessa estimativa foram registrados em
tabelas, conforme o modelo abaixo (figura 4):
ESTIMATIVA DE TERMINAIS E DE PROCESSOS
COM OCORRÊNCIA SIMULT~NEA POR LOCALIDADE
LOCALIDADES TERMINAIS PRDCES SOS COM CPU
S P O 80 60
-
R J O 75 57
--- -
R C E 35 25
8 S A 33 25 -----
8 L M 28 21 .-
P A E 30 18
f i g. 4
05 resultados obtidos pelo método uti I Izado para
estimar o número de processos simultâneos, foi comparada com
os valores medidos e registrados pela controle de produção
dos órgãos de processamento de dados, de modo a
vai Idação dos resultados proJetados.
promover a
Os resultados obtidos nessa fase do ProJeto de
Alternativas foram comparados com as conclusões da "Medida de
Desempenho do Equipamento de Tecnologia B", de modo a
possibilitar a determinação da configuração da CPU a ser
i mp I antada em cada loca I i dade que v I esse a ser identificada
como um dos nós (com CPU) da rede de teleprocessamento a ser
construída.
Observação: A determinação do número simultâneo de
processos foi precedida pelo estabelecimento das diretrizes
para macro-operaclonallzação do Sistema.
Macro operacionallzação deve ser entendida, nesse
contexto, como a articulação dos sistemas produtivos com os
sistemas gerenciais, re levando considerar, quanto aos
sistemas produtivos, que neles, a agilidade das informações
deve suportar a agi I Idade dOS processos, enquanto que nos
sistemas gerenciais a velocidade dos processos admite que não
haja comprometimento estrito, entre a ocorrência dos fatos e
seu Imediato conhecimento a nível de ação gerenciai.
A situação acima descrita sugere que os sistemas
produtivos sejam desenvolvidos para ambientes on-Ilne,
enquanto que os gerenciais sejam produzidOS no ambiente de
processamento mais próximo do nível gerenciai a ser
considerado, a partir de uma transferência programada de
dados.
Com relação aos sistemas produtivos, cabe
evidenciar que a maior parte das transações se dá em ambiente
fechado, havendo, eventualmente, comunicação remota. Esta
situação sugere que a acesslbl I Idade entre locais dl.ferentes
seja restrita apenas às comunicações remotas, enquanto,
as comunicações locais, haja acessibilidade plena.
para
Apenas o sistema de controle de facl I idades aparece
com características que determinam acessibl I Idade plena a
todos os ambientes.
I V Determl nação do n í ve I ótimo de descentra Ilzação da rede
Estimados o número de terminais por local idade e o
número de processos simultâneos por localidade (com e sem
comunicação entre local idades) já era possível determinar o
nível ótimo de descentralização da rede para as tecnologias
A, B ou para uma combinação entre elas.
AS premissas consideradas no proJeto da rede foram
descritas no item ~.~.1, letra E da Conclusão
I I I, do volume I.
I I I da RECOR
Com base nessas premissas e na estimativa de
capacidade determinada conforme o descrito anteriormente, foi
rea I I zada a aná I I se de trade-off entre os custos crescentes,
em função do número de nós (com CPU), de hardware, software,
pessoal e manutenção e os custos infra-estrutura,
decrescentes das inhas de comunicação. Foram considerados os
custos relativos às aquisições, modificações e despesas
operacionais.
Rea I i zado o proJ eto para diferentes n í ve i s de
descentra I i zação, com os preços e tarifas vigentes em
setembro de 1987, foram determinados os resultados
representados na figura 5.
9 CZ$10
Centralizado X Descentralizado Custos Totais Por Numero de Localidades
4.-------------------------------------,
3
otal 6 Anos
2 ----
+ 1
+
o , 6 4 21 8 31
Fig.5
Todos os resultados foram calculados pelo método do
valor presente, considerado um horizonte de 5 anos e custo de
capital de 12,5% ao ano.
A partir de 31 localidades, a elevação dos custos
de hardware, software, operação e Infra-estrutura começaram a
superar em multo a queda dos custos de comunicação, motivo
pelo qual não foi ampliado o número de localidades.
V Quantificação das alternativas tecnológicas
o G.C. considerando que os custos da rede se
revelaram relativamente constantes com o número de pontos de
descentra I i zação var i ando de 6 a 28 local idades, e ,
considerando que do ponto de vista da segurança,
confiabi I idade, e desenvolvimento cultural, (o maior número
de loca I i dades cor responde à situação ma I s adequada) adotou
como so I ução uma rede com 28 nós (loca II dades com un i dades de
processamento de dados). Para essa configuração foram
desenvolvidas cinco alternativas de solução, conforme as
tabelas abaixo (figura 6):
QUANTIFICACÃO DE ALTERNATIVAS TECNOLóGICAS
ALTERNATIVAS HARDWARE -
A TECNOLOGIA B - EQUIPAMENTO NACIONAL
B TECNOLOGIA B - EQUIPAMENTO NACIONAL F IMPnRTD.nn
C TECNOLOGIA A E T F r.N n I nr, I A ~JiA..C-LQJIl.A.L
----------,_._--------AL TERNAT I VAS S G B O
S G B O - B
I I S G B O - A
-------------~--------------
_._._------ -.,--
COMPOSiÇÃO DE CUSTO CUSTO ALTERNATIVAS OTN ( 10 *3 ) CR$ ( 10 *6 )
_ .. __ ._-- -A. I 7.930 3.172
A. I I 8.640 3.456
f---- -B. I 6.020 2.408
--B. I I 6.530 2.612
.
C. I I 6.120 2.448 --- -
f I g. 6
VI Custos de Desenvolvimento: ambiente SGBO X amb I ente
convencionai
Para aná I i se dos custos comparativos foram
considerados 05 seguintes componentes:
dimensão da equipe: 80 anal istas e programadores;
salário médio + encargos: CZ$ 100.000,00;
velocidade de desenvolvimento no ambiente de SGBO três
vezes maior que no ambiente convencionai.
Para esses valores, e, com base em resultados
alcançados em desenvolvimentos anteriores, foram real izadas
as seguintes estimativas (figura 7),
CUSTOS DE DESENVOLVIMENTO,
AMBIENTE CONVENCIONAL X SGBO
PRAZOS (ANOS) CUSTO CZ$ 10*6
A OTIMISTA 2 192 M S ----B ~ G LNOR~AL 3 288
'--1 T PESSIMISTA 384 E O - --- ---------
C O
A N M V OTIMISTA 6 576 B E ----I N E C ~_ NORMAL 9* 864 N I T O E N PESSIMISTA 12* 1152
L __ ~-,-__ . _____ --l _____ -'-_. ____ _
(*)Esses prazos Indicam que a alternativa de solução é inviável.
f i g. 7
VI I Expectativas de Ganhos e Custos
As expectativas de ganho, decorrentes da Implantação
do projeto, foram postas nos termos que se seguem.
o G.C. considerou significativos os seguintes fatores:
- perspectivas de ganho por aumento de receita:
por completude do faturamento;
por atendimento à demanda reprimida;
- perspectiva de redução de perdas financeiras;
- perspectiva de economia do fator mão-de-obra;
- crescimento da capacitação técnica do quadro de empregados;
- crescimento da Imagem institucional.
Foram quantificados os ganhos decorrentes das
perspect i vas de aumento de receita, de redução das perdas
f i nance I ras e de economl a do fator mão-de-obra.
A quantificação desses ganhos foi realizada pela
técnica do valor presente, considerados o horizonte de cinco
anos e o custo de capital de 12,5% ao ano.
Nessas condições foi determinado, para a expectativa
global de ganho, o valor de CZ$ 6 X 10 * 9. Esse valor foi
considerado uma estimativa pessimista.
As tabelas a seguir resumem as expectativas de ganhos
e custos (figura 8).
EXPECTATIVAS DE GANHOS E CUSTOS
G A N H O S
[ I CZ L_
COMPLETUDE DEMANDA ECONOMIA FATURAMENTO REPRIMIDA MAO-OE-OBRA
I $ 1: 80 2.500 3.420 -
CUS T O
A - INVESTIMENTO: HARDWARE E SOFTWARE
---r-
A N O I A N O
CZ$ 1: 868 1.020
8 - MÃO-DE-OBRA
f -
A N O I A N O - -
l_ CZ$ 1: 96 96 -----~-
-
CZ$ 1:
C - DESLOCAMENTOS
A N O I A N O -.
7,4 7,4 ,
1 US$ = CZ$ 51.282,00 1 OTN = CZ$ 400,00
* = CZ$ 10 * 6
flg 8
~)64
I I A N O I I I
724
I
I I I A N O I I I
48
-
I I A N O I I I
7,4
TOT AL
6.0 DO
-TOTA L
2.612
TO TAL
24 O
TOTAL
22,2
VI I Determinação de Prioridades
Para o G.C. era necessário evidenciar a complexidade
da tarefa global para que fosse estabelecida a conduta que
mais se ajustasse às necessidades da empresa.
A conduta adotada para a determinação de prioridades
foi preced i da por uma revisão cuidadosa dos objetivos
pretendidos.
Descrevemos abaixo os resultados dessa revisão:
1 - O projeto deve atender às necessidades dos seguintes
sistemas:
- Planejamento (e Controle);
- Sistema de Produção (Comercialização, Atendimento ao
Usuário, Facilidades, Manutenção, Medição, Faturamento);
- Sistemas de Administração de Recursos (Recursos Humanos,
Material, SerViços de APOlO, Serviços de Processamento
de Dados);
Sistema de Economia e Finanças.
2 - Os Sistemas devem atender às necessidades de todos os
serviços (Dados, Texto, Voz, Imagem; Fixos, Móveis;
Terestres, Satélite, etc.).
3 - As estruturas dos sistemas para todos os serviços devem se
comportar de modo Invariante.
4 - Os sistemas devem constituir um todo Intregrado,
perfeitamente articulado pelos
fronteira de cada um deles.
5 - As diversas categorias de
objetos situados na
processos deverão ser
desenvolvidas de forma completamente Independente, de modo
a assegurar a máxima establ I Idade dos sistemas. Desse
modo, os processos dos Sistemas de Apoio à Decisão e
Planejamento (e Controle) devem ser desenvolvidos para
operar a estrutura de dados gerada pelos Sistemas de
Produção (Administração da Produção), Administração de
Recursos e Economia e Finanças.
Para o G.C. esse conjunto de objetivos sugeria que o
desenvolvimento deveria privilegiar a função de produção,
articulada com a administração de recursos (pessoal, material,
serv i ços e recursos f I nance i ros).
Desse modo, cada serviço deveria ser considerado
como se fosse um produto em uma linha de montagem. Assim, a
partir do pedido (Comerciai Ização ou Atendimento ao UsuáriO),
são reunidos os recursos (Facl I idade e/ou Material e/ou
Serviços de ApOiO), para suprir às necessidades da fabricação
ou recuperação (Ativação e/ou Manutenção) e, após determinação
dos recursos consumidos no produto (Medições) é realizado o
Faturamento e a CObrança; em paralelo, são realizadas as
operações financeiras e a contabilização.
Essa í n t I ma articulação entre os processos de
administração da produção deverá ser apreendida no modelo a
ser desenvolvido, cuidando-se para que haja unificação de
conceitos e que o modelo seja adequado a todos os serviços.
o G.C. considerou que os processos diretamente
orientados para a produção e os processos diretamente
orientados para a administração de recursos, constituíam dois
conjuntos de processos que manifestam forte coesão
coesão externa um pouco menos forte.
interna e
00 exposto acima, o G.C. concluiu que o critério de
determinação de prioridades adotado para o projeto deveria
prlvi legiar aspectos estruturais.
A estrutura global deveria reconhecer:
Três categorias de Processos: Apolo à Oecisão,
(e Controle) e Produção (execução);
( e
Planejamento
Controle), Quatro categorias de Sistemas: Planejamento
Administração da produção, Administração
Economia e finanças;
de Recursos e
Quatro (mais importantes)
Texto, Voz e Imagem.
categorias de serviços:
Além dessas premissas, o G.C. admitiu que:
Dados,
os processos de Planejamento (e Controle), e Apolo à Decisão
operam sobre a base de dados construída pelos processos de
Administração da Produção,
Economia e finanças;
Administração de Recursos e
os processos orientados para a produção se relacionam de
forma indivlslvel;
os processos orientados para administração de recursos se
relacionam de forma indlvislvel (com forte coesão a parti r
dos processos de administração financeira).
Esse conjunto de condicionamentos estruturais, Impôs
a precedência entre processos, ou seja, os processos de
produção deveriam anteceder o desenvolvimento de qualquer
outro processo, e 05 processos de Planejamento (e Controle)
deveriam ser desenvolvidos antes dos processos de Apolo à
Decisão. O Sistema de Administração da PrOdução deveria ser
desenvolvido com altlsslma coesão interna, o que também deverá
ocorrer entre os Sistemas de Administração de Recursos e
Economia e Finanças. Finalmente, como o Sistema de Produção
seria aquele capaz de determinar a utl I ização de recursos,
esse deveria ter a precedência sobre os demais.
Estabelecidas as unidades e a precedência
estrutural, a questão da prioridade se I Imitou à ordenação da
precedência entre os serviços da empresa.
Para determinar essa precedência foram utl I Izados
critérios que recorreram às dimensões pai Itica,
econômica e cultural (capaCitação técnica).
estratégiCa,
A análise de prioridades decorre do estudo de
expectativas de ganho descrito em VI I. Na real Idade a
expectativa de ganhO foi realizada para cada serviço oferecido
26E3
pela empresa.
Das análises de precedência estrutural e
expectativas de ganhos resultaram os seguintes quadros (figura
g ) : PRIORIDADES DE SISTEMA E SERVICO
j
SISTEMAS ORDEM DE PRIORIDADE - . PARA IMPLANTACílO _.
____ .I1A.lE...B.1AL Q* -T É COMERCIALIZACílO 1 C f-- --N
P I ATEND. USUÁRIO 1 R C r-- -- -O O D FACILIDADES 1 U C ç O Ã M MANUTENCÃO 1 O E --
R C MEDICÃO 1 I __ o
- . A L FATURAMENTO 1
.. .. -A D ECO - FIN 2 M ------- - '--
P R REC. HUMANOS 2 O R r-.. D E U C SERVo GERAIS 2 ç U . -Ã R O S I NFORMÁT I CA 2
O -----EJ..1l.1lI E J IH1 E t,U Q ::l
* Esse sistema fo I se I ec i onado para a rea I i zação de um projeto pl loto objetivando exercitar as ferramentas e os padrões de projeto.
;;.?69
PRECEDÊNCIA DE SERVIGOS -~-~
ERVIGO PRIORIDADE
ADOS O
EXTO 1
--
v OZ 2
--1--. --ou TROS 3
F I g. 9
A conduta adotada para o projeto determinou que o
desenvolvimento tivesse início pela construção do modelo que
a te n d e s s e a to dos os s e r v i ç o S (s i 5 t ema i n v a r I a n te). A se 9 u I r
seriam real izados os ajustes para cada serviço e para os
diferentes níveis de porte de atividade de cada ambiente.
A adoção dessa conduta foi possível porque os
sistemas então existentes, apesar das inadequações,
continuariam suportanto a operação da empresa.
IX Análise de Risco do Projeto
A análise de risco foi rea I i zada objetivando
aval iar as duas posslbi Ildades identificadas:
desvios no tempo de execucão
desvios do objetivo
~.)70
As estimativas de desvios no tempo, conforme foi
demonstrado no Item V I , não acarretaria diferença
significativa com relação às despesas de mão-de-obra. O risco
de perda do Investimento decorrente de ociosidade dos
recursos adquiridos (equipamentos e despesas de
telecomunicações) seria perfeitamente admi n Istráve I, visto
que a aquisição dos recursos, pela característica modular do
projeto da rede, podia ser programada para ser realizada
apenas quando as apl icações estivessem disponíveis para serem
Implantadas. Assim sendo, atrasos no desenvolvimento do
projeto seriam compensados por adiamentos
aquisição de recursos.
no cronograma de
Partindo do pressuposto de que o atraso máximo
seria de um ano, a perda mais significativa se verificaria
com relação à redução dos benefícios (cerca de dez por cento
do benefício esperado) motivo pelo qual os objetivos de prazo
deveriam ser rigidamente controlados.
Com relação aos desvios do obJetivo, foi
considerado que a complexidade da tarefa e a dimensão do
esforço seriam plenamente compensados pela capacidade
empreendedora do grupo, plenamente demonstrada em proJetos
anteriores. Por outro lado, a não realização do projeto
significaria trocar a Incerteza de alguma perda de benefício,
pela certeza de uma perda total. Como os benefícios estimados
superavam 05 custos numa proporção de 2 para e ,
considerando-se que a estimativa dos benefícios era tida como
pessimista e a estimativa de custos era considerada correta,
o G.C. concluiu que a probabl I idade de perda decorrente da
rea I i zação do proj eto era mu i to pequena.
X Composição das EquipeS
Para empreender o desenvolvimento do Sistema e a
Instalação do ambiente de hardware e software, no qual os
sistemas deveriam operar, e , para que as duas cOisas
foram
pelas
ocorressem e se desenvolvessem ao mesmo tempo,
organizadas as equipes que se responsabi i zar I am
diferentes atividades específicas do projeto (deixamos de
mencionar as equipes de produção, suporte e manutenção, pois
essas estão mais comprometidas com as questões re I ac I onadas
às Instalações físicas), conforme as diretrizes que
mencionamos no Item 4.4 do volume I.
Essas equipes foram as seguintes:
X.l Equipe de Desenvolvimento de Sistemas - constituída por
um Coordenador Técnico, um Gerente Usuário,
usuários representantes das diferentes
Departamentos.
ana I i stas
Regiões
e
e
X.2 Comitê de Administração de Dados constituído por
profissionais, selecionados entre usuários e
espec i a I i stas em processamento de dados, dedicados à
tarefa de sustentar a integração conceituai e lógica das
estruturas de dados estabelecidas pelo projeto. A
Coordenação desse Comitê é exercida por representantes do
órgão Central de Processamento de Dados. Os membros desse
Comitê são representantes dos órgãos de Processamento de
Dados das Regiões e Departamentos (em cada Região ou
Departamento uma pequena equipe de duas a três pessoas se
dedica a essa tarefa).
Foram considerados relevantes, entre outros
aspectos, os seguintes:
a abrangência da atuação da Administração de Dados deve ser
sobre todos os dados Identificados conceitualmente:
a necess i dade da compat i b i I i dade das estrutu ras de dados de
diferentes locais:
a necessidade de um controle mais efetivo quanto aos
aspectos de segurança.
X.3 Comitê de Administração de Banco de Dados const I tu í do
por profissionais de procesamento de dados,
representantes das equipes de Administração de Banco de
Dados das Regiões, Departamentos e do órgão Central de
Processamento de Dados, cabendo ao representante dessa
última equipe a coordenação do Comitê.
Foram consideradas necessidades
seguintes tarefas:
imediatas, as
alocar fisicamente os componentes do Banco de Dados (BD);
parametrizar os softwares do ambiente de BD;
reorganizar o BD;
determinar a necessidade de gravação de LOG;
determinar periodicidade / retenção de back-up;
recuperar o BD;
controlar o cumprimento de padrões;
instalar / manter os softwares do ambiente de BD;
divulgar recomendações técnicas para o uso do BD.
A dinâmica estabelecida para o trabalho considerava
a participação intensa dos usuários, a promoção de encontros
freqüentes e profundos dos Comitês, a Gerência do Projeto
pelos Usuários, a aprovação formal das especificações
estabelecidas e a realização sistemática de treinamento para
Incorporação dos conhecimentos necessários.
XI Resumo das Decisões e Providências Necessárias
As alternativas de solução foram apreciadas pela
gerência competente, tendo sido decidido o seguinte:
1. Quanto às alternativas de configuração da rede:
Fo i conf i rmada a 50 I ução descentra I i zada;
2. Quanto ao ambiente de software:
Fo i conf i rmada a ut I I I zação do SGBDA;
3. Quanto à configuração hardware/software:
Foi selecionada a alternativa B.II;
Z.'74
"l. Quanto à distribuição do investimento no tempo:
Foi recomendada a distribuição do Investimento em, no
mínimo, três anos e, no máximo, cinco anos, de modo a
atender às localidades de mesmo porte de atividade, no
mesmo Intervalo de tempo;
5. Quanto às prioridades:
Fo I conf i rmado o esquema de pr I or I dades proposto;
6. Recursos Humanos:
Foram autorizados os recursos para que as equipes pudessem
desenvolver os sistemas e, fOi autorizada a organização
dos Comitês;
7. Providências:
Foram autorizadas as seguintes providências:
a - Instalação de ambiente de hardware e software com
capacidade compatível com
desenvolvimento;
b - Treinamento orientado para:
I inguagens de programação;
SGBDA;
Administração de Dados;
Gerência de Banco de Dados.
c - Real ização de reuniões de
as necessidades de
va I I dação ob] eti vando
divulgar o projeto e ampliar o comprometimento com os
resultados projetados.
