Estudo de caso: Atacando o Pesadelo do Engarrafamento de Dados

Estudo de caso: Atacando o Pesadelo do Engarrafamento de Dados
Soa como um grande negócio em dinheiro — $10,8 bilhões — por somente 12 quilômetros de autoestrada, mas o custo pode parecer pequeno quando alguém considera o tamanho e as complicações do
projeto de construção de auto-estradas. O centro de Boston tem um trânsito que é um pesadelo; o
congestionamento e os engarrafamentos são crônicos. A nova autoestrada significa alívio do problema.
Quando completada, ela irá incluir elevados, túneis e pontes. Antes de ela estar terminada, os trabalhadores terão que escavar mais de 11 milhões de metros de terra e jogar mais de 2 milhões de
metros cúbicos de concreto. O projeto, conhecido como Artéria/Túnel Central de Boston (CA/T —
Central Artery/Tunnel), é o maior e mais desafiador projeto de infra-estrutura pública que os Estados
Unidos já tiveram.
Observadores especialistas comparam o projeto com a construção do túnel do Canal da Mancha (o
Chunnel — Channel tunnel) e o novo aeroporto de Hong Kong, exceto pelo fato de que, apontam eles, o
CA/T é mais complexo em algumas maneiras fundamentais. O planejamento, sozinho, levou dez anos. A
execução envolverá mais de 100 empreiteiras, 36 escritórios de campo simultâneos e 45 empreiteiros,
indo de um custo de US$ 40 milhões a até US$ 400 milhões cada. No começo de 1998, cerca de
12.000 engenheiros de campo enviavam relatórios diários. O CA/T é tão complexo que duas empresas
de engenharia gigantes internacionais, a Bechtel e a Parsons Brinckerhoff (juntas chamadas de B/PB),
foram selecionadas para gerenciá-lo em conjunto.
Como qualquer outro projeto desse tamanho e complexidade, o CA/T derrubou várias barreiras e ficou
sob o exame minucioso de políticos e da imprensa. Seus defensores se referiam a ele como a
Grande Escavação (Big Dig), mas seus oponentes o chamam de o Grande Porco (Big Pig).
"Grande", qualquer coisa que seja, suaviza não só o tamanho do projeto global mas também o tamanho e
a complexidade da organização e dos dados que devem ser armazenados e compartilhados para o projeto
ser bem-sucedido. A questão dos dados compartilhados no CA/T- é o pesadelo que queremos examinar
neste estudo de caso.
O CA/T remonta a uma longa estrada. O departamento de estradas de Massachusetts, proprietário do
projeto original, começou a planejar o projeto anos atrás, e o projeto começou em 1986. A tecnologia de
computador era então muito mais primitiva. O desktop mais novo era o 386, agora há muito antiquado
e extremamente lento comparado aos PCs atuais. Trabalho em rede, a tecnologia básica de
compartilhamento de dados, quase não existia. Como resultado, não aconteceu nenhuma tecnologia
de informação planejada para integração ou armazenamento de dados; ninguém previu a
necessidade deles. Além disso, como os sistemas de com putador estavam isolados uns dos
outros, ninguém entendia a necessidade de padronizar as exigências de software. Cada contratado usou
o software que queria.
A primeira ferramenta de software usada dentro do CA/T foi o sistema CAD (computer aided design —
projeto assistido por computador), usado pelos gerentes e engenheiros de projeto que faziam ou
supervisionavam o trabalho de projeto. Esses sistemas habilitaram os gerentes de projeto e o
proprietário do projeto a trocar planos de projeto e desenhos. A Bechtel usou o GDS CAD, uma
ferramenta muito poderosa para a época, que tinha muitos instrumentos, incluindo o recurso de
gerar modelos em três dimensões, resolver o problema na hora e, até mesmo, localizar os
movimentos dos ratos que deveriam ser des locados à medida que a escavação e a cons trução
prosseguissem. Todavia, o GDS era caro, e, assim, a maioria dos contratados usava pacotes
mais baratos, dos quais o mais popular era o AutoCAD. Os formatos de dados de dois pacotes de
CAD eram incompatíveis. Quando, com muito esforço, o pessoal fazia traduções bem-sucedidas
entre os dois, muitos dos detalhes dos desenhos eram perdidos. Tony Stucchi, o gerente CAD de
um dos contratados para o projeto, a Perini Company, reclamou que não podia usar os arquivos GDS
convertidos devido à sua baixa qualidade, de modo que teve de dar uma volta e usar os arquivos
que ele podia coletar de projetistas individuais. Feniosky Perla-Mora, um professor de tecnologia de
informação e gestão de projeto do Massachusetts Institute of Technolo gy (MIT), que acabou se
tornando um consultor do CA/T, descreveu o custo negativo e o impacto de tempo do problema
dizendo: "Havia muitas pessoas fazendo horas extras para traduzir coisas, e havia muito backlog por
causa da tradução."
Diferentemente dos órgãos federais e das grandes empresas, que têm o poder de determinar o software
usado pelos fornecedores para construir seus sistemas de informação, os go vernos estaduais são
mais relutantes para especificar o software que os contratados preci sam adotar. A direção do projeto
foi outra função chave com os primeiros problemas de dados. O projeto de gerenciamento do CA/T
exigiu contratados para usar o Primavera Project Planner (P3), mas somente como parte da programação
mestra do CA/T. Cada unidade de projeto mantém seu próprio monitor de pro gresso e registros
p. 1/3
de despesas à sua própria maneira, alguns usando ferramentas de software de gerenciamento de
projeto, muitos usando planilhas, outros usando apenas papel e lápis. "Todos foram desenvolvendo
as suas próprias ferramentas e criando a confusão de dados", diz Per -ia-Mora Walter Erb, que mais
tarde se juntou ao projeto como gerente de serviços e tecnologia de informação da B/PB, descreveu
por que o projeto falhou em exigir que a tecnologia fosse atualizada o tempo todo. "Quando o
trabalho começou", explica ele, "o Lotus e o Word Perfect eram os padrões da época, e
provavelmente eram produtos muito bons. Mas, vindo de fora, eu pensei que tinha dado um passo
para trás no tempo." Até mesmo os dados que foram trocados entre os parceiros de administração do
projeto, a Bechtel e a Parsons Brinckerhoff, criaram problemas porque cada um usava planilhas
eletrônicas diferentes para administrar os seus dados de projeto.
Integrar esses dados manualmente era um processo extremamente lento, mas o que era pior era que os
relatórios gerenciais do projeto contradiziam os relatórios dos contratados. Como Perla-Mora
descreveu o processo de consolidação dos dados: "Alguém diria: 'nós esta mos nesse estágio' e outra
pessoa diria: 'Não estamos nesse estágio'." O resultado final desse compartilhamento de dados
eletrônicos precário estava à beira de um engarrafamento. Finalmente, em 1992, a Bechtel decidiu que era
necessário construir um novo sistema, que foi chamado de Construction Information System (CIS). A
meta principal desse sistema baseado no Oracle foi produzir relatórios padronizados usando SQL
(Structured Query Language — Linguagem de Consulta Estruturada). A Bechtel escolheu o sistema
e o software de gerenciamento de banco de dados com base no Oracle porque a empresa já possuía
uma licença corporativa da Oracle e tinha cinco anos de experiência construindo e operando sistemas
financeiros com o Oracle. O CIS se tornou totalmente operacional em 1996.
Uma vez pronto e rodando, o sistema Oracle ofereceu duas vantagens importantes: os relatórios se
tornaram padronizados, e todas as organizações que participavam do projeto es tavam aptas a
compartilhar as suas informações. Contudo, a direção do projeto e os contratados não tardaram a
perceber que a solução era inadequada. Um problema foi que os programadores da Oracle se tornaram
uma barreira. O projeto CIS não conseguiu construir as interfaces para os vários sistemas usados no
campo e, assim, os dados de campo não eram automaticamente alimentados dentro do sistema Oracle.
Em vez disso, foram usados programadores da Oracle para entrar com os dados manualmente, reduzindo
assim a sua disponibilidade para o trabalho de desenvolvimento. Ao mesmo tempo, o pessoal de muitas
outras organizações participantes do CA/T se tornou conhecedor dos recursos do Oracle e começou a
apresentar pedidos de programação para outras funções. Assim, como a disponibilidade de
programadores se reduzia, a demanda para programadores de Oracle crescia, criando um sério gargalo.
Um segundo problema foi a falta de compartilhamento de dados digitais adequado. Os contratados e os
gerentes do projeto mantinham seus próprios registros para estimativas de progresso e de custos do
trabalho. A direção do projeto mantinha seus registros no Oracle, enquanto os contratados usavam
seus próprios sistemas. Na verdade, o CA/T foi um sistema caro e redundante na entrada de dados.
Dados precisos são críticos por muitas razões, ainda mais se o pagamento daquele contratado está
diretamente ligado ao seu progresso. Para manter os dados atualizados e precisos, a direção do
projeto validava com os seus contratados os dados de custos e de progresso a cada duas semanas. Era um
sistema de trabalho que consumia muito tempo, desperdiçando-o. Dale Payate, presidente da J.
Cashmann Inc., contratado do projeto, estimou que em um típico trabalho o escritório de campo e o
contratado trocavam, pelo menos, 10.000 documentos. Dadas as circunstâncias, o projeto atual estava
na iminência de se afogar em papelada, e o siste ma Oracle não resolveu esse problema. A necessidade
gritante era de que os contratados introduzissem os seus dados de projeto diários diretamente no
sistema Oracle. "Isso eliminaria muita redundância de trabalho", explicou Payate. "Consumiria menos
verificações de dados, e tudo correria muito mais suavemente”.
No começo de 1998, muitos problemas foram resolvidos. Arquivos herdados ainda estavam sendo
convertidos para o Oracle, mas o projeto exigia que todos os novos desenvolvimentos fossem feitos
como parte do CIS, usando o Windows 95 ou NT. Uma aplicação foi construída para capacitar os
contratados a consultar os engenheiros da B/PB através do Ora cle. Uma aplicação Oracle acompanhava
as deficiências de material. Diariamente, dados de engenharia eram introduzidos diretamente dentro do
sistema Oracle, e todos os 12.000 rela tórios diários dos engenheiros eram emitidos pelo Oracle.
Estes relatórios não só incluíam mudanças em materiais e equipamentos, mas também informação do
tempo. De acordo com o administrador de banco de dados Oracle da B/PB, Brian Straesser, os
relatórios permitiram aos "engenheiros chegar de manhã, imprimir um desenho e levá-lo para fora
no campo, depois voltar de tarde e marcar as mudanças, em vez de redigir um novo relatório".
Sob a supervisão do dono do novo projeto. a Massachusetts Tu rnpike Authority, foi criada uma agenda
mestre de projeto, usando software P3 e administrando 8.000 atividades, inclusive projeto, aquisição,
aplicações de licença e relocações de recursos. Ela faz a interface com o banco de dados Oracle, o
p. 2/3
sistema do metrô de Boston e a Amtrak. Perla-Mora, contratado para o projeto em 1994, foi chamado
para criar um plano de integração de TI. O plano foi chamado de projeto IT Enable Office. O projeto
exige que todo software seja compatível não somente com o banco de dados Oracle, mas também
com certas aplicações que alguns contratados já estão usando, como o P3. Introduziu conceitos de
gerenciamento de documentos que são novos para as empresas de construção. Agora, em vez de enviar
documentos de um lado para o outro os dados relevantes são introduzidos direta mente dentro do
Oracle pelos contratados.
Questões do Estudo de Caso:
1. Como um consultor externo de siste mas de informação em 1991, prepare um relatório para
apreciação do dono do projeto CA/T. Descreva os problemas que você vê e defina os fatores gerenciais,
organizacionais e tecnológi cos responsáveis.
2. Se você fosse consultado para ser um a n a l i s t a d e s i s t e m a s n o c o m e ç o d e 1992, trabalhando
em um projeto de sistema para resolver o problema definido na Questão 1, liste quem você
entrevistaria e que perguntas você fa ria a essas pessoas.
3.O projeto Oracle Bechtel em 1992 foi uma resposta apropriada para os problemas existentes naquele
momento? Por quê? Quais fatores gerenciais, organizacionais e tecnológicos você acha que foram
responsáveis para a forma da resposta?
4.Sugira outra tecnologia atual que a B/PB poderia considerar usar para melhorar o gerenciamento dos
dados e descreva o uso de cada uma, explicando por que ela seria melhor em relação ao que está sendo
feito hoje.
5. Reflita sobre as diferenças entre a situação da computação e a tecnologia de rede em 1986 e de hoje em
dia. Se hoje lhe pedissem para administrar um grande projeto que se espera durar vários anos, explique
como você planejaria tirar proveito da nova tecnologia à medida que ela fosse se desenvolvendo.
Fonte: Adaptado de Ann Harrison, "Unsnarling Information for the Real Superhighway," Software Magazine, março de
1998.
p. 3/3