Auditoria e Controle de Seg e Clas da Informação

Prévia do material em texto

UNIVERSIDADE ESTÁCIO DE SÁ 
MBA EM SEGURANÇA DA INFORMAÇÃO 
 
 
 
 
 
 
 
 
 
 
Fichamento de Estudo de Caso de Harvard 
Rodrigo de Oliveira Paula Teixeira 
 
 
 
 
 
 
 
Auditoria e Controle de Seg. e Clas. da Informação 
Tutor: Prof.: Sheila Góes Monteiro 
 
 
 
 
 
 
 
Rio de Janeiro 
2019 
 
 
Estudo de Caso: Cisco Systems, Inc.: Implantação de ERP. 
Referência: Robert D. Austin, Richard L. Nolan e Mark J. Cotteleer 
 
 
O presente artigo fala sobre como os diretores da Cisco fizeram a implementação de 
um ERP (Enterprise Resources Planning) quando houveram falhas graves que colocaram os 
dados da empresa em risco. Tendo em mente que não seria simples essa implementação, as 
decisões de Solvik e companheiros fez toda a diferença. 
 
Em 1984 a Cisco nascia pelas mãos de dois cientistas da computação de Standford. 
Em 1990 virou uma empresa de capital aberto tendo como principal produto de vendas o 
Roteador. Em 1997 entrou na lista da Fortune 500 e ficou entre as 5 maiores empresas em 
questão de retorno de receitas e ativos. No ano seguinte superou-se aumentando em 15 vezes 
as vendas, levando a capitalização da empresa ultrapassar US$100 bilhões. 
 
Em 1993 quando Pete Solvik entrou como CIO, a Cisco usava um software para dar 
suporte ao seu principal processamento de transação. Esse suporte abrangia as áreas do 
Financeiro, Manufatura e Entrada de Pedidos fazendo da Cisco a maior cliente desse 
programa. Com a mudança e evolução das tecnologias a demanda ficou maior, os problemas 
de suporte do software surgiram e mesmo sendo oferecido uma atualização do fornecedor, em 
1994 o sistema parou completamente por dois dias. Interrupções em momentos decisivos e 
paradas abruptas se tornaram rotina e as deficiências do software aumentavam a dificuldade 
de recuperação das mesmas. Foi grave o suficiente e não poderia mais ser ignorado. Uma 
solução paliativa motivada por esses erros foi implantada, o que causou um erro drástico 
corrompendo o banco de dados da central fazendo a empresa parar drasticamente. Foi aí que 
Solvik, Pond e outros diretores da Cisco decidiram tentar fazer com que os grupos de entrada 
de pedidos e finanças se interessarem em fazer uma única implantação integrada, em vez de 
tomar muito tempo desenvolvendo projetos separados. Era muito importante profissionais 
com experiência na área e sintonia com as necessidades da Cisco para fazer a escolha certa. A 
decisão final foi ficar com a KPMG. 
 
 
 
 
 ”Ao contrário de muitas outras empresas que queriam trazer um monte de novatos, a 
KPMG estava estabelecendo uma prática com pessoas muito experientes no setor”. E essa era 
a característica que os diretores procuravam. Era um trabalho árduo que precisava de firmeza 
e conhecimento na área, já que a implementação era decisiva para o funcionamento da 
empresa. 
 
 Equipe pronta e projeto na mão, a única barreira era o conselho que poderia 
aprovar ou não os planos da mudança. As dúvidas a serem respondidas antes de levar até os 
que decidiriam era simples e necessária antes da apresentação de qualquer projeto: Quanto 
custa? Quanto tempo? Tudo isso teria que ser muito bem pensado pois seria um baque 
financeiro grande demais caso desse algum problema durante a implementação. 
 
 Além disso ainda havia a preocupação na implementação da Oracle, que 
usaram como estratégia a técnica “rapid iterative prototyping” dividindo em várias partes a 
prototipagem, chamada Conference Room Pilots (CRP). Aqui, a implantação começou com 
CRP0 que estabilizava o ambiente e a equipe. 
 
 Mesmo com a integração, treinamento e organização da equipe, erros eram 
inevitáveis fazendo assim o fechamento do CRP0 e abrindo CRP1 onde as lições do primeiro 
foram colocadas em pratica. Algumas mudanças no orçamento precisaram ser feitas e 
modificações pensadas pela equipe com o objetivo de rodar dois programas em um dia só, já 
que a Oracle não daria o suporte necessário no atendimento pós-vendas. O CRP2 e CRP3, 
foram as fases mais maçantes e difíceis porque o CRP2 precisava testar e avaliar o sistema 
para poder avaliar se haveria suporte necessário para gerir os negócios em expansão da Cisco 
e no CRP3 o teste era completo e precisava saber se o software ia rodar na empresa. Esse 
último precisava da participação completa dos funcionários. 
 
 Com a Oracle já implementada, a dificuldade foi o desempenho dos usuários 
que estavam lidando com um novo software, tornando o sistema instável. Um dos problemas 
também foi o volume de transações no ambiente da Cisco. Os cinco meses seguintes foi difícil 
principalmente para a equipe de TI, testando e consertando erros simultaneamente. 
Então, mais uma estratégia precisava ser tomada e por dois meses, parceiros se reuniram para 
 
estabilizar os problemas e fazer com que o sistema funcionasse e se tornasse estável para os 
usuários. 
 
CONSIDERAÇÕES 
 
 Todo projeto, seja pequeno ou grande, pede um enorme comprometimento e 
conhecimento na área. Se tivessem errado lá no começo quando montaram a equipe, a história 
poderia ser outra. Todo o conjunto fez diferença, desde os funcionários até os fornecedores e 
mesmo com os erros durante o processo de implementação, o trabalho árduo de profissionais 
fez com que o software obtivesse sucesso ao final das operações.