Resenha-MauricioLima-Auditoria e Controle de Seg e Clas da Informação

Prévia do material em texto

UNIVERSIDADE ESTÁCIO DE SÁ
PÓS-GRADUAÇÃO EM SEGURANÇA DA INFORMAÇÃO
Resenha Crítica de Caso 
Maurício José de Lima
Trabalho da disciplina Auditoria e Controle de Seg. e Clas. da Informação
 Tutor: Prof. Sergio Rodrigues Affonso Franco
Fortaleza/CE 
2020
CISCO SYSTEMS, INC.: IMPLANTAÇÃO DE ERP 
Referência: AUSTIN, Robert D., NOLAN, Richard L. Cisco Systems, Inc.: Implantação de ERP, Harvard Businnes School, Maio 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 cada vez mais. A Cisco System Inc. empresa focada na área de telecomunicação de dados, 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 um executivo com experiência na área de computação. John Morgridge 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 em 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. 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 diretórios 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.
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 que 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 abordou, 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 nov as 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 impactasse 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." Com aprovaçã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 um comitê Executivo de Projeto. A estratégia da equipe deERP 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. 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 início 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 classificadas 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 encaminhadas 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 decidi u 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. 
FIM