Fichamento 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 
 
Rodrigo Sabino da Silva 
 
 
 
 
 
 
 
Trabalho da disciplina 
Auditoria e Controle de Seg. E Clas. Da Informação 
Tutor: Prof. Andre Jorge Dias de Moura 
 
 
 
 
 
 
 
 
 
 
Rio de Janeiro 
2017 
 
 
 
 
ESTUDO DE CASO: 
 
Cisco Systems 
Implantação de ERP 
 
 
 
REFERÊNCIA: Robert D.Autin, Richard L. Nolan, Mark J. Cotteleer. Cisco Systems, Inc.: 
Implantação de ERP, Harvard Business School,611-P03, Rev.06 de Maio de 2002. 
 
Em 1984, dois cientistas da computação da Universidade de Stanford, tiveram uma ideia 
voltada ao mercado de internet, uma vez, que os acessos cresciam de forma exponencial. A 
Cisco System Inc. empresa focada na área de telecomunicação de dados e com o principal 
produto, o roteador, a combinação de hardware e software, onde as rotas de dados transitavam 
por esse appliance, embarcou nesse nicho de negócio. Don Valentine, sócio da sequoia 
Capital e vice-presidente do conselho de administração da Cisco, foi o primeiro visionário 
desse nicho de negócio, não perdeu tempo em investir na Cisco. Assumindo um risco com 
jovem empresa, quando outros investidores de risco foram cautelosos. Valentine usou a 
seguinte estratégia para proteger o investimento aplicado, começando inicialmente com valor 
de US$ 2,5 milhões, reservou o direito de formar time de gestão e buscar profissionais de 
mercado. 
Em 1988, Valentine apostou na contratação de John Morgridge como CEO (Chief Executive 
Officer). Morgridge era um executivo com experiência na área de computação. Com 
autonomia de formar a própria equipe e seguindo os seus critérios de gestão, não demora 
muito, a equipe formada entra em confronto com os fundadores e, após a oferta pública inicial 
da Cisco, em 1990, empresa abre capital e ambos venderam todas as suas ações e deixaram a 
empresa. Assim, Morgridge ficou livre para dar continuidade ao seu plano estratégico de 
instalar uma estrutura de gestão extremamente disciplinada. 
 Para Morgridge, a descentralização de gestão torna a empresa vulnerável ao fracasso, sua 
estratégia era manter uma organização funcional e centralizada. 
Em 1993, Pete Solvik ingressa na Cisco com CIO (Chief Information Officer). Objetivo era 
levantar o capital, uma vez que capital da empresa era de US$ 500 milhões e usada um pacote 
de software baseado em UNIX para dar suporte ao seu principal processamento de transações. 
As áreas funcionais suportadas pelo pacote incluíam os sistemas: financeiro, de manufatura e 
de entrada de pedidos. A experiência de Solvik e as significativas perspectivas de 
crescimentos estavam convencidos de que Cisco precisava mudar. 
Objetivo era superar US$ 5 bilhões. As aplicações de gestão tinham pontos de falhas, como 
também, não tinham como fazer as alterações necessárias para atender as demandas de 
negócios. Para Solvik, migrar para solução de ERP era símbolo de impacto no negócio. A 
filosofia era permitir que áreas funcionais tomasse sua própria decisão com relação à 
aplicação e ao plano de mudança, desde siga as normas estabelecida e padronização da Cisco 
que era utilizar arquitetura e banco de dados comuns. Solvik, acreditava que as decisões de 
orçamento sobre gastos de TI seriam tomadas pelas áreas funcionais, enquanto que 
organização de TI reportaria diretamente a ELE. 
Em 1994, Randy Pond, diretor de manufatura, descreve a seguinte situação, que enfrentaram 
no final de 1993: 
.....O rompimento do negócio que faria ir ao conselho dizer: "Muito bem, o departamento de 
manufatura quer gastar US$ 5 ou US$ 6 milhões para comprar um pacote que, a propósito, vai 
levar um ano ou mais para entrar em funcionamento", era muito complicado de justificar. 
Nenhum de nós iria jogar fora os sistemas legados e fazer algo grandioso. 
O fator complicador era substituição dos sistemas legados das áreas funcionais da 
organização, no entanto, como as interrupções de sistemas estava impactando diretamente o 
negócio, faz necessário tomar uma decisão. 
Solvik, e vários outros diretorios da Cisco chegaram à conclusão de autonomias das áreas 
funcionais em substituir seus próprios sistemas não eram suficientes. Seria necessário utilizar 
uma outra estratégia. 
O Conselho chegou a seguinte conclusão. 
“ Não podemos esperar que, em algum momento, os departamentos de entrada e Pedidos, 
Finanças e Manufatura saia e tomem três decisões diferentes". 
A equipe de direção da Cisco percebeu que implantar um sistema que atendesse às 
necessidades dos negócios exigiria um grande envolvimento de todas as áreas da empresa. 
Isto não poderia ser uma iniciativa apenas de TI. Era criticamente importante conseguir os 
melhores profissionais que pudessem ser encontrados. A primeira ideia era retirar algumas 
pessoas chaves de sua função para trabalhar no projeto, além disso, precisava de parceiros 
fortes. Solvik e Refiel acreditavam que era importante trabalhar com um parceiro de 
integração e que pudesse ajudar na seleção e implantação da solução. Como parceiro de 
integração, escolheram a KPMG. 
O parceiro KMPG tinha experiência no negócio, chegando a estabelecer prática com pessoas 
experientes no setor: Por exemplo, o gerente de programas que Eles trouxeram para o cargo, 
Mark Lee, tinha sido diretor de TI de uma empresa no Texas que adotara várias partes de um 
sistema ERP. 
A KPMG a bordou, a equipe de acerca de 20 pessoas que voltou para mercado de software 
com objetivo de identificar os melhore pacotes de software. O desafio da equipe era buscar o 
máximo de conhecimento possível, aproveitando as experiências dos outros. Eles mapearam 
as seis grandes empresas de contabilidades, tendo como referência a fonte de pesquisa Gartner 
Group. Com o resultado, a Cisco reduziu as alternativas identificadas para cinco pacotes. 
Após uma semana de avaliação em alto nível dos pacotes, a equipe escolheu dois candidatos 
principais, a Oracle e outro participante importante no mercado de ERP. Para Pond, o 
tamanho da empresa fornecedora era uma questão a ser considerada. Como ele disse:..."Nós 
decidimos que não devíamos colocar o futuro da Cisco nas mãos de uma empresa que fosse 
significativamente menor do que a nossa..." 
A seleção da Oracle foi baseada em diversos fatores. Redfield, descreveu três dos principais 
pontos da decisão: 
Primeiro: O Projeto estava sendo conduzido muito fortemente pela área de manufatura, e 
Oracle tinha competência em sistemas de produção e manufatura melhor do que outro 
fornecedor. 
Segundo: Prometerá desenvolver pacotes com novas funcionalidades em logo prazo; 
Terceiro: A flexibilidade oferecida pela Oracle por estar localizada nas proximidades; 
Para Oracle, o projeto Cisco seria a primeira grande implantação de um novo lançamento do 
produto de ERP da Oracle. A Oracle estava divulgando a nova versão como tendo grandes 
melhorias no suporte à fabricação. Uma implantação bem-sucedida do produto na Cisco 
lançaria a nova versão numa trajetória muito favorável. 
Depois da escolha do fornecedor, a equipe precisava responder, as duas questões muito 
importantes: Qual seria o custo ? Quanto tempo levaria? Porque, a equipe sabia que seus 
executivos estavam preocupados que um grande projeto pudesse sair do controle e produzir 
resultados abaixo do esperado. Tinha necessidade de um escopo bem definido e cronograma 
de implantação que não impacta-se o negócio. 
Depois da definição do escopo e cronograma, orçamento foi aprovado, O projeto se tornou 
um dos setes principais objetivos da empresa no ano, "todos na empresa sabiam que isso 
estava acontecendo e que era uma prioridade para o negócio." 
Comaprovação do conselho em mão, a liderança da equipe do projeto ERP não perderam 
tempo para montar a estrutura para implantação. As primeiras ações foi estender a relação da 
Cisco com a KPMG até o final da implantação. A decisão foi tomada com base no 
desempenho da KPMG e durante o processo de seleção do software em seu contínuo 
compromisso de alocar ao projeto seus funcionários mais experientes. 
Os integrantes da equipe de toda a Cisco foram alocados em cinco grupos, equipe por área de 
processo. Ou seja, cada grupo tinha como membros da equipe um líder de sistemas de 
informações da Cisco, um líder de negócios da Cisco, consultores de negócios e da KPMG ou 
da Oracle, e pessoal adicional da empresa. Cada grupos eram coordenados a parti de uma 
Equipe de Gestão do Programa, que incluía gerente de projeto da Cisco. Acima de toda 
estrutura de gerenciamento do projeto, havia uma comitê Executivo de Projeto. 
A estratégia da equipe de ERP para utilizar o Comitê Executivo era poupá-los da necessidade 
de intervir diretamente na gestão do projeto. Cujo objetivo do comitê era proporcionar um alto 
nível de patrocínio ao projeto, assegurando a visibilidade e motivar a equipe. 
A estratégia de implantação da equipe utilizava uma técnica de desenvolvimento chamada 
"rapid iterative prototyping". Com essa técnica, os integrantes da equipe dividiram a 
implantação em diversas fases, denominadas Conference Room Pilotsn (CRP). O objetivo de 
cada CRP era desenvolver um trabalho prévio para possibilitar uma compreensão mais 
profunda do software e seu funcionamento no ambiente de negócios. 
O primeiro CPRO começou com treinamento da equipe de implantação, time trabalhou com 
duas frente em paralelo. A primeira se concentrava em treinar a equipe nos aplicativos 
Oracle. A imersão tinha duração de duas semanas no conjunto completo das aplicações. A 
segunda equipe cuidava da implantação das aplicações, objetivo é colocar em pleno 
funcionamento. Depois de diversas reuniões de alinhamento, a equipe faz uma demonstração 
da capacidade do CRPO. 
O Ponto de atenção durante o CRPO foi que a Cisco não seria capaz de cumprir objetivos 
iniciais para implantação, que era evitar a modificação do software de ERP. Evitar as 
mudanças nos pacotes de sistemas era importante, pois tendem a ser específica de cada 
empresa. As lições aprendidas da equipe no primeiro CRPO indicavam que, sem um número 
significativo de alterações, o software não seria capaz de suportar de forma eficiente as 
transações da empresa. Ficou claro que algumas mudanças seriam necessárias. Com resultado, 
a equipe deu inicio ao CRP1. Objetivo era que cada grupo fizesse o sistema funcionar dentro 
de suas áreas de atuação. Durante o processo, os integrantes da equipe elaboravam escopo 
detalhados e seguida documentavam os procedimentos de execução. A fim de assegurar que 
todas as contingências fossem consideradas, desenvolveram-se planilhas de testes e 
rastreamento de processos. Com os apontamentos e processos documentados, confirmou as 
preocupações com software. Havia um grande número de processos de negócios que software 
não poderia fazer. Solução de contorno foi desenvolver uma categorização para avaliar 
individualmente cada ponto de falha. Todas as solicitações de modificação foram 
classificados como vermelho, amarelo ou verde. Cada solicitação era enviada para os líderes 
de grupo, e todas as solicitações vermelhas tinham que ser encaminhados ao Comitê de 
Direção para aprovação. No final, foi necessário alocar trinta programadores durantes três 
meses para modificar algumas linhas de códigos. As mudanças não estavam no escopo, o que 
alterou o projeto e orçamento. Além de identificar as modificações necessárias, a equipe de 
implantação também informou que pacote da Oracle não daria o suporte adequando às 
necessidades de atendimento pós-vendas da Cisco. Sendo assim, após avalição da equipe, 
ocorreu a seleção de um pacote de apoio ao serviço. O pacote foi selecionado e implantado 
em um cronograma que combinava com o cronograma geral de implantação. A Cisco 
pretendia rodar ambos os pacotes no mesmo dia. 
Conforme algumas mudanças ocorreram, O CRP1 se transforma em CRP2. E mais uma vez, o 
escopo do projeto havia se expandido para incluir as modificações necessárias e relevantes 
para um novo pacote de suporte pós-venda. No entanto, os impactos eram notórios nas 
atividades secundárias, a equipe decidiu abordar algumas questões técnicas complexas. O 
desafio era fazer a integração dos sistemas, foi então que surgiu a ideia de utilizar um banco 
de dados distribuído, Data Warehouse, que permitiria que todas a aplicações da Cisco 
acessassem uma única fonte para suas necessidades de informação até o fim do CRP2. A 
primeira rodada de modificações estava implantada e funcionando. Durante o tempo, equipe 
de implantação não parou de buscar conhecimento dos pacotes Oracle e serviços para 
adequação no ambiente de produção Cisco. Objetivo final do CRP2 era começar a testar o 
sistema, tanto o hardware quanto o software e avaliar os comportamentos frente uma carga de 
processamento e volume de transações necessária para gerir os negócios em expansão da 
Cisco. 
Objetivo do CRP3 era validação do sistema completo e avaliar o comportamento em um 
cenário de produção. Todos os colaboradores chaves da organização validaram o sistema. Em 
seguida, foi iniciada fase de transição. 
A fase foi conturbadora, o desempenho dos sistemas era bastante instável, em média, o 
sistema ficava indisponível uma vez por dia. Identificado que um dos problemas era na 
arquitetura da solução, foi necessário adicionar um novo hardware. O segundo problema foi 
capacidade do software com relação a volumetria das transações. Não simularam o ambiente 
de produção para os testes. Nos testes de sistema, a Cisco havia executado processos 
individuais sequenciais, e não simultâneo. Durante os três meses, a Cisco e seu fornecedores, 
trabalharam juntos para estabilizar os incidentes e corrigirem algumas falhas. Por fim, Os 
testes de implantação foram concluídos com sucesso e sistema ERP em produção.