Cisco Systems, Inc .

: Implementacin ERP
Pete Solvik, CIO de Cisco Systems (CIO), considerado el ltimo rengln restante de su ERP
(Enterprise Resource Planning) presupuesto de implementacin. Cisco tena un historial de
desempeo satisfactorio con bonos en efectivo, pero el importe destinado a recompensar el
equipo de ERP, ms de $ 200.000, no tena precedentes. Para estar seguros, que haban entregado
una gran cantidad en un marco de tiempo que nadie haba credo posible. No haba sido fcil. Los
miembros del equipo, Solvik incluido, haban tomado un riesgo en unirse al proyecto. Las
recompensas deben, y seran, ser generoso. El tamao del fondo de bonificaciones, sin embargo,
hizo Solvik pensar: lo haban hecho bien, pero cmo as? Lo que haba salido bien? Qu haba
pasado? Dada otro proyecto de esta magnitud y el riesgo, seran capaces de hacerlo de nuevo?
Historia de CISCO
Cisco Systems, Inc. fue fundada por dos cientficos de la computacin de Stanford en 1984 y se
convirti cotiza en 1990. producto principal de la compaa es el "router," la combinacin de
hardware y software que acta como un polica de trfico en las complejas redes TCP / IP que
conforman la Internet (as como de las empresas "Intranets"). Con el auge de las tecnologas de
Internet, la demanda de los productos de Cisco retumb y la compaa pronto comenz a dominar
sus mercados. En 1997, su primer ao en la lista Fortune 500, Cisco clasificada entre las cinco
primeras empresas a cambio de los ingresos y la rentabilidad de los activos. (Ver Anexo 1 para el
desempeo financiero de Cisco.) Slo otras dos compaas, Intel y Microsoft, nunca han igualado
esta hazaa. Tal vez an ms impresionante, el 17 de julio de 1998, apenas 14 aos despus de su
fundacin, la capitalizacin de mercado de Cisco pas la marca de $ 100 mil millones (15 veces las
ventas de 1997). Algunos expertos de la industria predicen que Cisco sera la tercera empresa
dominante de unirse a Microsoft e Intel para dar forma a la revolucin digital.
Don Valentn, socio de Sequoia Capital y vicepresidente de la junta directiva de Cisco, fue la
primera en invertir en Cisco; l tom una oportunidad en la joven empresa cuando otros
capitalistas de riesgo fueron ms cautelosos. Una forma Valentine protegida su $ 2,5 millones
inversin inicial fue al reservarse el derecho de llevar en la gestin profesional cuando considere
oportuno
En 1988, da de San Valentn contrat a John Morgridge como CEO. Morgridge, un ejecutivo con
experiencia en la industria informtica, de inmediato comenz a construir un equipo de gestin
profesional. Este equipo pronto se enfrentaron con los fundadores y, despus de la oferta pblica
inicial de Cisco en 1990, ambos fundadores vendieron todas sus acciones y dejaron la compaa.
Esta partida dej Morgridge libre para continuar sus planes de instalar una estructura de gestin
extremadamente disciplinado.
Morgridge cree que muchas empresas de Silicon Valley descentralizados demasiado rpido y no
aprecian la capacidad demostrada de la organizacin funcional de crecer sin sacrificar el control.
En consecuencia, Morgridge mantiene una organizacin funcional centralizada. Mientras que la
comercializacin de productos e I + D se descentraliz en tres "lneas de negocio" (Enterprise,
Pequea / Mediana Empresa, y proveedor de servicios), la fabricacin, atencin al cliente,
finanzas, recursos humanos, informtica, y las organizaciones de ventas permanecido centralizada.

Historia de IT en CISCO
Pete Solvik uni a Cisco en enero de 1993 como CIO de la compaa. En ese momento, Cisco era
una compaa 500 millones dlares la ejecucin de un paquete de software basado en UNIX para
apoyar su proceso de transacciones ncleo. Las reas funcionales apoyados por el paquete
incluyen sistemas, fabricacin, y de entrada de pedidos financiera. Cisco fue "de lejos" el mayor
cliente del proveedor de software que apoya la solicitud. La experiencia de Solvik y las
perspectivas de crecimiento significativos de la sociedad lo convencieron de que Cisco necesitaba
un cambio.
Queramos crecer a $ 5 mil millones de ms. La aplicacin no proporcion el grado de
redundancia, confiabilidad y facilidad de mantenimiento que necesita. No fuimos capaces
de realizar cambios en la aplicacin para satisfacer nuestras necesidades de negocio ms.
Se haba convertido en demasiado espaguetis, tambin personalizados. El proveedor de
software no ofrecer [una versin mejorada], pero cuando nos aguarda a que hemos
pensado "para el momento en que hemos terminado nuestros sistemas sern ms fiables y
tienen una mayor redundancia, pero an as ser un paquete por $ 300 millones de
empresas y que 're una empresa $ 1000000000 dlar ".
Inclinacin inicial de Solvik era evitar una solucin ERP. En cambio, l planeaba dejar que cada rea
funcional hacer su propia decisin sobre la solicitud y el momento de su traslado. Siguiendo con
fuerte tradicin de Cisco de la normalizacin, sin embargo, se necesitaran todas las reas
funcionales de utilizar la arquitectura y las bases de datos comn. Este enfoque es coherente con
las estructuras organizativas y presupuestarias que Solvik haba instalado a su llegada. Solvik
estaba convencido de que las decisiones presupuestarias sobre los gastos de TI pueden hacer por
reas funcionales, mientras que la organizacin de TI inform directamente a l. La objecin de
Solvik a soluciones ERP tambin naci de la preocupacin acerca de los tipos de "megaproyectos"
que las implementaciones de ERP a menudo se convirtieron.
Un momento de Definicin
En el ao siguiente, poco se ha avanzado. Randy Pond, un director en la fabricacin y eventual colder del proyecto, describi el dilema que enfrentan las reas funcionales a finales de 1993:
Sabamos que estbamos en problemas si no hacemos algo. Cualquier cosa que hicimos se
acaba de ejecutar a travs de los sistemas de legado que tuvimos en su lugar. Se convirti
en un esfuerzo constante curita nuestros sistemas existentes. Ninguno de nosotros se va de
forma individual para salir a comprar un paquete de ... La interrupcin en el negocio para
m ir a la pizarra y decir "Bueno, fabricacin quiere gastar $ 5 o $ 6 millones de dlares
para comprar un paquete y por cierto que tomar un ao o ms para entrar... "era
demasiado para justificar. Ninguno de nosotros se va a echar a los legados y hacer algo
grande.
Las dificultades de sustitucin de los sistemas de reas funcionales perpetuaron el deterioro del
entorno heredado de Cisco. Modificacin incremental continu mientras que la compaa sufri
una tasa de crecimiento anual del 80%. Sistemas cortes se convirtieron en rutina. Defectos del
producto exacerbaron las dificultades de la recuperacin de los cortes.
Finalmente, en enero de 1994, el medio ambiente legado de Cisco no tan dramticamente que las
deficiencias de los sistemas existentes ya no pueden ser ignorados. Un mtodo no autorizado para

acceder a la aplicacin principal base de datos-una solucin que fue a su vez motivado por la
incapacidad del sistema para llevar a cabo, no funcionaba correctamente, corromper la base de
datos central de Cisco. Como resultado, la compaa fue cerrado en gran parte durante dos das.
La lucha de Cisco para recuperarse de esta importante parada trajo a casa el hecho de que los
sistemas de la compaa estaban al borde del fracaso total. Solvik, Charca, y un nmero de otros
gestores de Cisco llegaron a la conclusin de que el enfoque autnomo a la sustitucin de sistemas
que haban adoptado no iba a ser suficiente. Se necesita un enfoque alternativo. Solvik describe lo
que hicieron:
Dijimos, "no podemos esperar casualmente por orden de entrada, mientras que, Finanzas,
Manufactura y salir y tomar tres decisiones separadas." Se necesitara demasiado tiempo
para conseguir estas aplicaciones en su lugar. Tenamos que tomar una accin ms rpida.
En ese momento llegamos patrocinio de la SVP de Fabricacin, Carl Redfield. l estaba con
digital antes de Cisco, en la fabricacin de PC. l tom la iniciativa y dijo: "Est bien, vamos
a seguir adelante con esto. ... Vamos a empezar desde la perspectiva de la fabricacin, y
ver si podemos obtener la orden de entrada y grupos financieros de la empresa interesada
en hacer una nica sustitucin integral de todas las aplicaciones, en lugar de tomar ms
tiempo haciendo proyectos separados. "Y as, en febrero, un mes despus de la [apagado
empresa], fuimos en armar un equipo para hacer una investigacin para reemplazar la
aplicacin.
Redfield entiende a partir de experiencias de implementacin a gran escala anteriores en digital
cmo los proyectos de TI "monolticos" podran tomar en sus propias vidas. l se hizo eco de las
preocupaciones de Solvik sobre el tamao del proyecto y tena fuertes opiniones acerca de cmo
Cisco debe acercarse a un proyecto de implementacin de gran tamao.
Yo saba que quera hacer esto rpidamente. No bamos a hacer una implementacin por
fases, haramos todo de una vez. Nosotros no bamos a permitir que una gran cantidad de
personalizacin tampoco. Hay una tendencia en systems5 MRP para que las personas
quieren que el sistema para reflejar su mtodo de operacin en lugar de readaptacin a la
gente a hacer las cosas de la forma en que el sistema les destina. Esto toma mucho ms
tiempo. Adems, hemos querido crear un horario que era factible y que sea una prioridad
en la empresa en lugar de un segundo tipo de nivel de esfuerzo.
Seleccionando un producto ERP
El equipo directivo de Cisco dio cuenta de que la aplicacin para satisfacer las necesidades del
negocio requerira una fuerte participacin de la comunidad empresarial. Esto no podra ser una
iniciativa de TI slo. Era de vital importancia para conseguir las mejores personas que pudieron
encontrar. Solvik explic: "Nuestra orientacin en sacar a la gente de sus puestos de trabajo [a
trabajar en el proyecto] fue si era fcil entonces estbamos recogiendo las personas equivocadas.
Llegamos a la gente de que el negocio absolutamente no quera renunciar ".
En consonancia con la necesidad de un fuerte equipo de Cisco, la compaa tambin necesitara
socios fuertes. Solvik y Redfield sintieron que era particularmente importante trabajar con un
socio de integracin que podran ayudar en la seleccin y aplicacin de cualquier solucin que la
compaa eligi. Grandes habilidades tcnicas y conocimiento del negocio eran un requisito
previo. Solvik explic la eleccin de KPMG como el socio de integracin:

KPMG entr y vio la oportunidad de realmente construir un negocio alrededor de poner en

estas aplicaciones. Tambin vieron esto como una especie de oportunidad de definir, a
trabajar con nosotros en este proyecto. A diferencia de algunas otras empresas que
queran traer una gran cantidad de "novatos", KPMG fue la construccin de una prctica
de las personas que tenan mucha experiencia en la industria. Por ejemplo, el director del
programa que ponen en el trabajo, Mark Lee, haba sido director de TI de una empresa en
Texas que haba puesto en varias partes de un sistema ERP.
Con KPMG a bordo, el equipo de unas 20 personas se volvi hacia el mercado de software con un
enfoque mltiple para la identificacin de los mejores paquetes de software. La estrategia del
equipo fue la de construir el mayor conocimiento posible mediante el aprovechamiento de las
experiencias de los dems. Pidieron a las grandes corporaciones y las empresas de contabilidad
"Big Six" lo que saban. Tambin intervenidos fuentes de la investigacin, como el Grupo Gartner.
Orientando el proceso de seleccin a lo que la gente estaba utilizando realmente y de hacer
hincapi en la velocidad de decisin, Cisco se redujo el campo a cinco paquetes dentro de dos das.
Despus de una semana de la evaluacin de los paquetes en un alto nivel, el equipo decidi en dos
principales candidatos, Oracle y otro jugador importante en el mercado de los ERP. Pond record
que el tamao era un problema en la seleccin. "Decidimos que no debemos poner el futuro de
Cisco en manos de una empresa que fue significativamente menor que nosotros."
El equipo pas 10 das escribiendo una Solicitud de Propuestas (RFP) para enviar a los
proveedores. Los vendedores se les dio dos semanas para responder. Mientras que los vendedores
preparan sus respuestas, el equipo de Cisco continu su "diligencia debida" al visitar una serie de
clientes de referencia que ofrece cada proveedor. Tras el anlisis de Cisco de las respuestas de
RFP, cada vendedor fue invitado en una demostracin de software de tres das y pidi que
mostrara cmo su paquete podra cumplir con los requisitos de procesamiento de informacin de
Cisco. Cisco proporciona datos de la muestra, mientras que los vendedores ilustran cmo se
cumplen los requisitos clave (o no se cumplen) por el software.
Seleccin de Oracle se basa en una variedad de factores. Redfield describe tres de los principales
puntos de decisin:
En primer lugar, este proyecto estaba siendo conducido muy fuertemente por la
fabricacin y Oracle tenido una mejor capacidad de fabricacin que el otro proveedor. En
segundo lugar, se hicieron una serie de promesas en relacin con el desarrollo a largo
plazo de la funcionalidad en el paquete. La otra parte de que era la flexibilidad ofrecida
por Oracle de estar cerca.
Cisco tambin tena razones para creer que Oracle estaba particularmente motivado para hacer
que el proyecto sea un xito. Pond siempre su impresin de la situacin de Oracle: "Oracle quera
esta victoria mal. Terminamos conseguir una super oferta. Hay, sin embargo, una gran cantidad de
ataduras. Lo hacemos referencias, permite visitas de campo y en la conversacin general, a
muchas empresas que estn involucradas en la toma de esta decisin. "El proyecto de Cisco sera
la primera aplicacin importante de una nueva versin del producto Oracle ERP. Oracle estaba
promoviendo la nueva versin que tiene importantes mejoras en el soporte de la fabricacin. Una
implementacin exitosa de Cisco lanzar la nueva versin en una trayectoria muy favorable.
Desde el inicio hasta la seleccin final del equipo de Cisco haba pasado 75 das. La eleccin final se
bas en equipo. Solvik describe cmo se tom la decisin y present a los vendedores:

El equipo hizo internamente la eleccin e inform a los vendedores. No hubo un proceso

importante que tuvimos que ir a travs con la administracin para "aprobar" la seleccin.
Acabamos de decir "Oracle usted gan, [otro proveedor] que perdi." Luego nos fuimos a
las negociaciones del contrato con Oracle y poniendo una propuesta juntos por nuestro
consejo de administracin. El foco de inmediato se dirigi a cuestiones de cunto tiempo
tomara el proyecto y cunto costara. El equipo decidi que "s, vamos a hacer esto y
debemos seguir adelante con el proyecto." As que ahora en el final de abril estbamos
poniendo todo el plan juntos.
Yendo a la JUNTA
Antes de ir a la junta para su aprobacin, el equipo necesario para responder a dos preguntas muy
importantes: Cunto es el costo y el tiempo que se tarda? Ellos saban que sus ejecutivos estaban
preocupados de que un gran proyecto podra salirse de control y ofrecer resultados de calidad
inferior. A pesar de los riesgos, el equipo tom un enfoque pragmtico para la estimacin de los
requerimientos del proyecto. Solvik describi el proceso:
Nuestros cuartos van agosto a octubre, noviembre a enero, febrero a abril, y mayo a julio.
As que aqu el 1 de mayo, principios del cuarto trimestre, estamos pidiendo "cunto
tiempo debe tomar para hacer un proyecto para reemplazar todos nuestros sistemas
centrales?" Esto es realmente cmo fue. Dijimos "usted sabe que no podemos aplicar en el
cuarto trimestre. Los auditores tendrn una vaca completa. "Si se tarda un ao estaremos
implementando el cuarto trimestre, y que no va a funcionar. Pensamos que realmente
debe tener 15 meses, julio o agosto, un ao ms tarde. Tom Herbert, el director del
programa, dijo que no hay manera de que vamos a tomar 15 meses para conseguir este
hecho. Eso es ridculo. As que empezamos a ir en la direccin opuesta y dijo tambin
podemos hacerlo en cinco meses? Eso no me parece correcto. Entender que no tenamos
un alcance todava. Al final nos quedamos bsicamente que queramos ir directo al inicio
de la Q3, por lo que estaramos completamente estable para el 4T. (Ver Anexo 2 para un
resumen de las fechas de aplicacin ERP hito.)
Que se encarg de fijar una fecha lmite. Luego vino la tarea de estimar un presupuesto del
proyecto. Una vez ms, Cisco fue agresiva: "Despus nos pusimos una fecha, se estimaron los
presupuestos. Ponemos todo esto juntos sin ser realmente tan lejos en este programa. Nos
miramos el cunto toc "(Pete Solvik). En lugar de desarrollar un caso de negocio formal (es decir,
un anlisis financiero) para demostrar el impacto que el proyecto tendra sobre la empresa, el
equipo opt por centrarse en las cuestiones que haban suscitado el anlisis en el primer lugar. En
opinin de Solvik, Cisco tuvo ms remedio que moverse. Explic su aproximacin a la situacin:
Nos dijo que tenamos este gran apagn en enero. Que ramos el mayor cliente de
nuestro proveedor de software actual y que el vendedor estaba siendo comprada por otra
compaa. No estaba claro que iba a apoyar a nuestros sistemas existentes y tenamos que
hacer algo. La fiabilidad, la escalabilidad y la modificabilidad de nuestras aplicaciones
actuales no apoyaran nuestro crecimiento futuro anticipado. Necesitbamos tanto las
actualizaciones de la nueva versin de la aplicacin actual o que necesitbamos para
reemplazarlo. Si reemplazamos, podramos hacerlo bien en partes o hacerlo en su
conjunto. Evaluamos esas tres alternativas, hablamos acerca de los pros y los contras de
cada alternativa, y recomend que sustituimos nuestros sistemas, big-bang, con una

solucin ERP. Estamos comprometidos a hacerlo en nueve meses por $ 15 millones de

dlares para todo el asunto. (Ver Anexo 3 para un desglose de los costos del proyecto.)
Aunque Cisco era, hasta cierto punto, obligados a implementar ERP, proceder sin una justificacin
econmica formal, fue tambin una cuestin de filosofa de gestin. Como Redfield puso:
Usted no se acercan a este tipo de cosas desde la perspectiva de la justificacin. Reduccin
de costos no es un medio adecuado para mirarlo. Usted realmente tiene que mirar en l
como "Hey, vamos a hacer negocios de esta manera." Usted est institucionalizando un
modelo de negocio para su organizacin.
En $ 15 millones, el proyecto constituira el proyecto de capital ms grande sola vez aprobado por
la empresa. Los miembros del equipo preparados para tomar este nmero a la alta direccin con
cierto temor. La primera reunin con el CEO Morgridge no hizo nada para aliviar sus
preocupaciones. Pond describi la reunin con Morgridge de esta manera:
Pete Solvik, Tom Herbert y yo hicimos la propuesta de Morgridge y la reaccin fue
bastante interesante. Hizo el comentario "usted sabe, las carreras se han perdido ms de
mucho menos dinero que esto." Pete y yo estbamos tan blanca como una hoja de papel.
Sabamos que si no logramos que nos bamos a recibir un disparo. El fracaso no es algo que
la empresa tom bien, sobre todo con este tipo de dinero.
Pero Morgridge dio el visto bueno tomar la propuesta de proyecto a la junta. Desafortunadamente
para Pond y Solvik, la recepcin no era mucho ms clido all. Pond describi lo que pas:
Antes de que lleguemos la primera diapositiva hasta que escucho al presidente hablando
desde el fondo de la sala. l dice: "Cunto?", Le dije que estaba recibiendo a l y l
respondi: "No me gusta sorpresas. Slo hay que poner la diapositiva hasta ahora.
"Despus de que me puse hasta que dijo" Oh, Dios mo, no vale que sea un montn de
buenas diapositivas. . . ".
Haba ya la junta termin aprobando el proyecto. En las semanas y meses siguientes a la reunin,
Morgridge hizo su parte por lo que es claro para el resto de Cisco que el proyecto de ERP era una
prioridad. El proyecto surgi como una de las siete objetivos de la empresa para el ao. "Todo el
mundo en la compaa saba lo que estaba sucediendo y que era una prioridad para el negocio",
explic Pond
Construyendo el Equipo de Implementacin
Con la aprobacin del directorio en la mano, el equipo de ERP central no perdi tiempo en la
creacin de una estructura para la ejecucin. Uno de sus primeros actos fue extender la relacin
de Cisco con KPMG hasta el final de la ejecucin. Esta decisin fue tomada en base al rendimiento
de KPMG a travs del proceso de seleccin de software, y el continuo compromiso de la empresa
con el personal del proyecto con su personal ms experimentados.
Proceder con la aplicacin tambin signific que el equipo tuvo que expandirse desde sus
centrales 20 miembros a 100, lo que representa una seccin transversal de la comunidad
empresarial de Cisco. Una vez ms, el equipo busc slo lo mejor para su inclusin en el proyecto.
Una de las reglas de enfrentamiento para los que trabajan en la aplicacin es que era a corto plazo
en la duracin y no representaba un cambio de carrera para los involucrados. El esfuerzo se

enmarca a los que trabajar en l como un reto, un "arrojar el guante tipo de cosas." Por este
tiempo, conseguir que la gente trabaje en el equipo no era un problema. Elizabeth Fee, un equipo
recluta implementacin, describe cmo era vista la misin: "Ellos escogido las mejores y ms
brillantes para este equipo. Para cada persona que era una posibilidad la promocin profesional.
La gente haca porque era algo diferente, era la oportunidad. "
Los miembros del equipo de enfrente de Cisco se colocaron en uno de los cinco "pistas" (equipos
de la zona de proceso). Cada pista tena un lder Cisco sistemas de informacin, un Cisco lder
empresarial, de negocios y de TI consultores de KPMG ya sea u Oracle, y personal adicional de la
empresa, como los miembros del equipo (vase Anexo 4 para un diagrama de la estructura del
equipo de ERP de Cisco). Las pistas fueron manejados de una "Oficina de Gestin de Proyectos",
que inclua Agente ejecutivo de negocios de Cisco, Tom Herbert, y Mark Lee, el director de KPMG
Proyecto.
Sentado encima de toda la estructura de gestin del proyecto fue un Comit de Direccin
Ejecutiva integrada por el vicepresidente de Manufactura, el vicepresidente de Customer
Advocacy, el Contralor Corporativo, Solvik, vicepresidente senior de Aplicaciones de Oracle, y el
socio a cargo de West Coast Consulting de KPMG . La presencia en el comit directivo de tales
ejecutivos de alto nivel de Oracle y KPMG era indicativo de la importancia de estas organizaciones
que figuran en el xito del proyecto.
La estrategia del equipo de ERP para el uso del Comit Directivo fue para aliviarlos de la necesidad
de intervenir directamente en la gestin del proyecto. La funcin del comit era proporcionar
patrocinio de alto nivel para el proyecto, para asegurar la visibilidad, y para motivar al equipo. El
equipo dirigido para que las reuniones del comit de direccin eventos de celebracin. Para
asegurar esto, se centraron en abordar cuestiones de direccin de los miembros del comit antes
de las reuniones.
Implementando ORACLE
Estrategia de implementacin del equipo emple una tcnica de desarrollo denominada
"prototipado rpido iterativo." Con este enfoque, los miembros del equipo se rompi la aplicacin
en una serie de fases llamada "sala de conferencias" Los pilotos (CRP). El propsito de cada CRP
fue construir en el trabajo previo para desarrollar una comprensin ms profunda del software y
de la forma en que funcionaba dentro del entorno empresarial.
CRP0
El primer CRP (CRP0) comenz con la capacitacin del equipo de implementacin y configuracin
del entorno tcnico. Aqu el equipo trabaj en dos esfuerzos paralelos. El primer esfuerzo se
centr en conseguir el equipo entrenado en las aplicaciones Oracle. Cisco dirige Oracle para
comprimir sus clases normales de formacin de cinco das en dos das de 16 horas. En un perodo
de dos semanas a la mayora de los miembros del equipo participaron en esta capacitacin
"inmersin" para todo el conjunto de aplicaciones. Mientras esto ocurra, un pequeo "equipo de
tigre" se dedica a la segunda esfuerzo, conseguir las aplicaciones en funcionamiento.
Despus de la capacitacin y la configuracin del sistema, el equipo central se reuni en una
sesin diseada para configurar rpidamente el paquete de Oracle. Los miembros del equipo de
todas las reas de la empresa se "bloquean" juntos en una reunin fuera del sitio para discutir y
decidir sobre la configuracin adecuada para los cientos de parmetros integrados en el software.

Los miembros del equipo se unieron a especialistas de Oracle y KPMG. Solvik describi la
experiencia, su intensidad y resultados:
Hay toda clase de opciones configurables sobre cmo se va a ejecutar los sistemas. Se
establece, literalmente, cientos de parmetros en estas aplicaciones. As que nos fuimos
fuera de la escuela dos das a 40 personas, y asignacin de la preparacin de todo el
mundo estaba de esa reunin fuera del sitio, tal vez tres o cuatro semanas en el proyecto
en esta etapa, se procedi con una recomendacin 80-20 sobre la forma de configurar el
sistema. Nos reunimos todo el da y en la noche durante dos das, de bajar a la "nthdegree"
en cmo bamos a hacer esto funcionar para nosotros. Expertos de Oracle, con expertos de
KPMG, con la gente de negocios de Cisco, Cisco gente de TI, vamos a hablar de GL, vamos a
hablar de Plan de Cuentas, a hablar de esto y hablar de eso. Yo lo llamo el esfuerzo 1% que
nos dio 80% de precisin en cmo bamos a ejecutar esta aplicacin, en lugar de un
enfoque ERP tpico, donde te vas por seis meses, y analizar demasiado a la muerte.
Tuvimos esta tres a cuatro semanas en el proyecto y nos acab siendo alrededor del 80%
de precisin en trminos de cmo podramos hacer esto.
Una semana despus de esta reunin, el equipo complet CRP0 con una demostracin de la
capacidad del software para tomar una orden de Cisco todo el camino a travs de procesos de
negocio de la compaa (Quote-to-Cash).
Una realizacin importante que sale de CRP0 fue que Cisco no sera capaz de adherirse a uno de
sus primeros objetivos para la modificacin de implantacin para evitar el software de ERP.
Modificacin Evitar era importante porque los cambios tienden a ser especficas de la empresa y
hacer la migracin a versiones de aplicaciones futuras difcil y lleva tiempo. Las experiencias del
equipo durante la primera fase del proyecto indicaron que sin un nmero significativo de los
cambios que el software no sera capaz de apoyar eficazmente la empresa. Por el plazo de un mes
haba pasado, era evidente que se necesitaran algunos cambios. Dentro de dos meses despus de
que se hizo evidente que algunos de los cambios sera sustancial.
CRP1
Sobre la base de las lecciones aprendidas en CRP0, el equipo de implementacin de inmediato se
embarc en CRP1. Con el equipo ya todo el personal hasta, el objetivo de esta fase del proyecto
era para cada pista para que el sistema funcione dentro de su rea especfica. Al igual que en el
trabajo anterior, se hizo hincapi en conseguir que el sistema para dar cabida a los procesos de
Cisco sin modificaciones. Durante CRP1, los miembros del equipo generan guiones detallados que
documentan el propsito y los procedimientos utilizados para completar un proceso (vase Anexo
5 para un script de ejemplo de procesos de negocio). Con el fin de garantizar que todas las
contingencias se contabilizan, se desarrollaron procesos de negocio hojas de seguimiento
prototipo (ver Anexo 6 para una hoja de seguimiento prototipo muestra). En contraste con CRP0,
los miembros del equipo cuidadosamente documentados los problemas que corran a travs
durante su modelado. Temas fueron abordados en las reuniones semanales de tres horas en
poder de la Oficina de Gestin de Programas. Durante estas reuniones, los lderes de la pista de
cada rea trabajaron juntos para resolver los problemas y empujar adelante el proyecto.
Modelado durante esta fase confirm las preocupaciones sobre el software. Haba un gran
nmero de procesos de negocio que el software no podra apoyar.

La respuesta del equipo de implementacin de las lagunas que se encuentran en el sistema era
desarrollar un medio para la categorizacin y evaluacin de cada uno de ellos individualmente.
"Todas las solicitudes de modificacin se clasificaron como rojo, amarillo o verde. Cada uno se fue
a los conductores de la pista y todo lo que era de un rojo tena que ir al Comit Directivo para su
aprobacin. "Haba pocos Rojos (ver Anexo 7 para la lista de" modificaciones rojas "). Al final, se
necesitaron 30 desarrolladores durante tres meses para modificar Oracle para apoyar el negocio.
Elizabeth Fee describi el proceso.
Cuando nos dimos cuenta de que no bamos a ser capaces de ir a vivir "vainilla",
comenzamos a trabajar en nuestra estrategia de modificacin. Los meses de julio y agosto
se centraron en que las modificaciones bamos a hacer? Qu es real y qu no lo es. En
algunos casos, el usuario estara diciendo "usted sabe, la fecha era el primero que escribe y
en Oracle es el cuarto." En otros casos, fue la constatacin de que tendramos que
contratar a 100 personas en la planta de produccin a rdenes de trabajo de apertura y
cierre, si no buscar la manera de automatizarlo.
El descubrimiento de la necesidad de modificar Oracle llev a algunos cambios no planificados en
el plan y presupuesto del proyecto. Adems de la identificacin de las modificaciones necesarias,
el equipo de implementacin tambin determin que el paquete de Oracle no apoyara
adecuadamente el despus de las necesidades de apoyo de ventas de la empresa. Como
resultado, el equipo se embarc en un esfuerzo simultneo para evaluar y seleccionar un paquete
de soporte de servicio. El paquete se seleccion e implement en un horario que haca juego con
el cronograma general de ejecucin. Cisco planea irse a vivir a ambos paquetes en el mismo da.
CRP2 y CRP3
Como CRP1 convirti en CRP2 y verano se convirti en otoo, el equipo de implementacin se
encontraba en el ms difcil parte ms gruesa, de la aplicacin. El alcance del proyecto se ha
ampliado para incluir las modificaciones importantes, y un nuevo despus del paquete de soporte
de ventas. Otro cambio importante mbito tambin se cerna. Debido a los impactos aguas abajo
del proyecto fueron mucho mayores de lo esperado, el equipo decidi hacer frente a algunos
problemas tcnicos ms grandes. Mientras que antes los sistemas tendan a comunicarse
directamente entre s (es decir, "punto a punto"), un nuevo enfoque ahora se empleara en la que
todas las comunicaciones de datos se llevara a cabo a travs de un "almacn de datos". La
utilizacin de un almacn de datos que permitira todas las aplicaciones de Cisco para acceder a
una fuente nica para sus necesidades de informacin.
Los cambios en el alcance significaban ms cambios en la utilizacin de los recursos de Cisco,
especialmente para el departamento de TI de 100 personas de la compaa. La naturaleza tcnica
de la mayora de los cambios en el alcance signific que este grupo llev la mayor parte de la
responsabilidad de las adiciones de proyectos. Solvik describi el resultado:
Bsicamente, todo el resto del grupo de TI comenz se liber de sus otros proyectos.
Dijeron que "tenemos que pasar nuestro tiempo acaba absorbiendo el hecho de que los
sistemas centrales de la compaa estn cambiando. Estamos necesitando para desviar
ms y ms energa, y ms y ms recursos para el proyecto. "No hizo nada ms que aos.
Tambin decidimos no para convertir cualquier historia como parte de este proyecto. En
cambio, el grupo de almacenamiento de datos creado la capacidad de informar histrico y
futuro en una conversin de datos integrada. Nos vuelven a numerar nuestros clientes; nos

vuelven a numerar nuestros productos; y cambiamos nuestra estructura de lista de

materiales. Cambiamos fundamentalmente todos nuestros datos subyacentes en la
empresa y el almacn de datos se convirti en el sistema de puente que atravesara la
historia y el futuro juntos.
A finales de CRP2, la primera ronda de modificaciones estaba en su lugar y funcionando. Durante
este tiempo el equipo de implementacin continu profundizando su comprensin de la Oracle y
paquetes de servicio y para determinar mejor cmo hacer que funcionen para Cisco. El objetivo
final de CRP2 iba a comenzar a probar el sistema, tanto de hardware como de software, para ver
lo bien que hacer frente a los volmenes de carga de procesamiento y transaccin necesarios para
ejecutar el creciente negocio de Cisco.
El enfoque de CRP3 estaba en probar el sistema completo y evaluar la preparacin de la compaa
para "ir a vivir." Una prueba final se llev a cabo con una dotacin completa de los usuarios para
ver cmo el sistema que funcione, de adelante hacia atrs, con una carga de transacciones
completo. El equipo de implementacin ejecuta estas pruebas mediante la captura de valor de un
da completo de los datos reales de las empresas y "volver a ejecutar" en un sbado de enero. Los
miembros del equipo observaron cmo cada pista, a su vez, ejecuta la pena un da simulada de
trabajo. Con este test completado a satisfaccin de todo el equipo, todo el mundo se senta listo
para corte ms en febrero. Pond describi la ceremonia que concluy CRP3:
Al final de CRP3 cada uno de los cables funcionales present su pedazo del proceso y dijo
"s o no" sobre si estaban listos para ir. Hicimos cada uno de ellos por separado y luego
poner a todos en la misma habitacin y les hicimos asienten con la cabeza y decir
"debemos ir.". . . Y luego doblamos la maldita cosa en. . . .
Cortando a ORACLE
[Despus de corte y cambio] Yo no dira que la empresa golpe la pared, pero yo dira que tuvimos
importante retos diarios que necesitaban ser resueltos rpidamente para evitar un impacto
significativo para la empresa. Por ejemplo, nuestro barco puntuales, envo en la fecha que nos
comprometemos con el cliente, se redujo de 95% a 75%, todava no era miserable, pero que no era
bueno ..
El xito inicial de corte y cambio de Cisco para Oracle fue, por decir lo menos, algo menos de lo
que se esperaba. El rendimiento global de negocios se desplom como usuarios intentaron lidiar
con un nuevo sistema que demostr ser preocupantemente inestable. En promedio, el sistema se
redujo casi una vez al da. El principal problema, como se vio despus, era con la arquitectura de
hardware y dimensionamiento. Ordinariamente corregir la deficiencia habra requerido la compra
de hardware adicional, lo que aumenta el gasto total del proyecto. Pero Cisco haba solicitado, y
conseguido, un contrato inusual desde el proveedor de hardware. En su contrato Cisco adquiri
equipo basado en una capacidad prometido en lugar de una configuracin especfica. Como
resultado, la responsabilidad para la fijacin de los problemas de rendimiento de hardware cay
completamente en el proveedor de hardware.
Un segundo problema tena que ver con la capacidad del propio software para manejar el volumen
de transacciones necesario en el entorno de Cisco. El diseo de la aplicacin exacerbado los
problemas de hardware mediante el procesamiento ineficiente tareas comunes. En retrospectiva,
es evidente que la empresa haba ido mal en su prueba final del sistema. Como Pond puso:
"Algunas cosas resultaron gravemente rompieron en grandes volmenes de datos,. . . y tenemos

una enorme base de datos. Nuestro error fue que no hemos probado el sistema con una base de
datos lo suficientemente grande que se le atribuye. "En las pruebas del sistema, Cisco haba
corrido procesos individuales secuencialmente en lugar de a la vez. Adems, slo se utiliz una
base de datos parcialmente cargado. Despus de corte, cuando todos los procesos se ejecutan a
ms de una base de datos totalmente convertido, el sistema careca de la capacidad para procesar
la carga requerida.
Los prximos dos meses fueron algunos de los ms difciles de toda la aplicacin. Esto fue
particularmente cierto para el personal de TI, ya que trat de lidiar con las dificultades tcnicas
causadas por lo que el nuevo sistema para arriba. Cuota describi lo que era en este momento:
Fue duro, muy estresante. Esto fue una cosa grande, una de las iniciativas principales de la
empresa. Haba un montn de atencin a conseguir que se haga. Estbamos trabajando
muy largas horas; la toma de decisiones que afecten a la empresa en el futuro. . . . Siempre
supimos que lo haramos. Siempre fue un "cundo", no un "si." Haba [muchos] cosas que
no te gusta de [el software].
El estado del proyecto ERP se convirti en el nmero uno de orden del da de las reuniones del
personal ejecutivo semanales. Compromiso proveedor fuerte de Oracle, el proveedor de
hardware, y el plomo KPMG a una eventual estabilizacin del software y mejorar el rendimiento.
Solvik describe el medio ambiente:
As que durante unos 60 das que estuvimos en el modo de SWAT equipo completo, hacer
que esta cosa se dio la vuelta. Por ejemplo, el presidente de la fabricante de hardware fue
nuestro patrocinador ejecutivo. Este vendedor probablemente tena 30 personas en el
lugar en un punto. Estaban por todas partes. Perdieron dinero en este gran momento. Fue
genial para ellos obtener una gran referencia tales, pero fue una experiencia dura para
ellos. Recuerde que habamos comprado una capacidad, por lo que todo lo que hicieron
para aadir capacidad estaba fuera de su propio bolsillo.
Despus de la Estabilizacin
Los problemas tcnicos relacionados con la implementacin de Oracle result ser de corta
duracin. En el transcurso de los prximos tres meses Cisco y sus proveedores, trabajando juntos,
estabilizado, y ha aadido la capacidad para el sistema. El calvario implementacin concluy con
una fiesta de celebracin para la gestin de equipos y compaa. Tambin asistieron varios
miembros del Consejo de Administracin de Cisco. Los sentimientos corran alto que los nuevos
sistemas de informacin deberan cumplir con la promesa de apoyar el rpido crecimiento que la
compaa estaba esperando.
Como l firm en su recomendacin para la distribucin de la prima, Solvik pens en el enfoque
que haban tomado hacia la implementacin. "Reemplazo de sistemas totales por $ 15 millones en
nueve meses que habra pensado que podramos hacerlo?" Trat de pensar en las decisiones que
l y el equipo haba hecho durante el curso de la ejecucin. Qu factores se haban hecho la
diferencia entre el xito y el fracaso? Donde haban sido inteligente? Dnde haban estado
simplemente con suerte? Podran hacerlo de nuevo si tuvieran que?