Cisco Systems, Inc .: Implementación ERP

Pete Solvik, CIO de Cisco Systems (CIO), considerado el último renglón restante de su ERP (Enterprise Resource Planning) presupuesto de implementación. Cisco tenía un historial de desempeño satisfactorio con bonos en efectivo, pero el importe destinado a recompensar el equipo de ERP, más de $ 200.000, no tenía precedentes. Para estar seguros, que habían entregado una gran cantidad en un marco de tiempo que nadie había creído posible. No había sido fácil. Los miembros del equipo, Solvik incluido, habían tomado un riesgo en unirse al proyecto. Las recompensas deben, y serían, ser generoso. El tamaño del fondo de bonificaciones, sin embargo, hizo Solvik pensar: lo habían hecho bien, pero ¿cómo así? Lo que había salido bien? ¿Qué había pasado? Dada otro proyecto de esta magnitud y el riesgo, ¿serían capaces de hacerlo de nuevo?

Historia de CISCO

Cisco Systems, Inc. fue fundada por dos científicos de la computación de Stanford en 1984 y se convirtió cotiza en 1990. producto principal de la compañía es el "router," la combinación de hardware y software que actúa como un policía de tráfico en las complejas redes TCP / IP que conforman la Internet (así como de las empresas "Intranets"). Con el auge de las tecnologías de Internet, la demanda de los productos de Cisco retumbó y la compañía pronto comenzó a dominar sus mercados. En 1997, su primer año 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 desempeño financiero de Cisco.) Sólo otras dos compañías, Intel y Microsoft, nunca han igualado esta hazaña. Tal vez aún más impresionante, el 17 de julio de 1998, apenas 14 años después de su fundación, la capitalización 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 sería la tercera empresa dominante de unirse a Microsoft e Intel para dar forma a la revolución digital.

Don Valentín, 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 más cautelosos. Una forma Valentine protegida su $ 2,5 millones inversión inicial fue al reservarse el derecho de llevar en la gestión profesional cuando considere oportuno

En 1988, día de San Valentín contrató a John Morgridge como CEO. Morgridge, un ejecutivo con experiencia en la industria informática, de inmediato comenzó a construir un equipo de gestión profesional. Este equipo pronto se enfrentaron con los fundadores y, después de la oferta pública inicial de Cisco en 1990, ambos fundadores vendieron todas sus acciones y dejaron la compañía. Esta partida dejó Morgridge libre para continuar sus planes de instalar una estructura de gestión extremadamente disciplinado.

Morgridge cree que muchas empresas de Silicon Valley descentralizados demasiado rápido y no aprecian la capacidad demostrada de la organización funcional de crecer sin sacrificar el control. En consecuencia, Morgridge mantiene una organización funcional centralizada. Mientras que la comercialización de productos e I + D se descentralizó en tres "líneas de negocio" (Enterprise, Pequeña / Mediana Empresa, y proveedor de servicios), la fabricación, atención al cliente, finanzas, recursos humanos, informática, 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 compañía. En ese momento, Cisco era una compañía 500 millones dólares la ejecución de un paquete de software basado en UNIX para apoyar su proceso de transacciones núcleo. Las áreas funcionales apoyados por el paquete incluyen sistemas, fabricación, 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.

Queríamos crecer a $ 5 mil millones de más. La aplicación no proporcionó el grado de redundancia, confiabilidad y facilidad de mantenimiento que necesita. No fuimos capaces de realizar cambios en la aplicación para satisfacer nuestras necesidades de negocio más. Se había convertido en demasiado espaguetis, también personalizados. El proveedor de software no ofrecer [una versión mejorada], pero cuando nos aguarda a que hemos pensado "para el momento en que hemos terminado nuestros sistemas serán más fiables y tienen una mayor redundancia, pero aún así será un paquete por $ 300 millones de empresas y que 're una empresa $ 1000000000 dólar ".

Inclinación inicial de Solvik era evitar una solución ERP. En cambio, él planeaba dejar que cada área funcional hacer su propia decisión sobre la solicitud y el momento de su traslado. Siguiendo con fuerte tradición de Cisco de la normalización, sin embargo, se necesitarían todas las áreas funcionales de utilizar la arquitectura y las bases de datos común. Este enfoque es coherente con las estructuras organizativas y presupuestarias que Solvik había 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 organización de TI informó directamente a él. La objeción de Solvik a soluciones ERP también nació de la preocupación acerca de los tipos de "megaproyectos" que las implementaciones de ERP a menudo se convirtieron.

Un momento de Definición

En el año siguiente, poco se ha avanzado. Randy Pond, un director en la fabricación y eventual co-líder del proyecto, describió el dilema que enfrentan las áreas funcionales a finales de 1993:

Sabíamos que estábamos en problemas si no hacemos algo. Cualquier cosa que hicimos se acaba de ejecutar a través 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 interrupción en el negocio para mí ir a la pizarra y decir "Bueno, fabricación quiere gastar $ 5 o $ 6 millones de dólares para comprar un paquete y por cierto que tomará un año o más para entrar... "era demasiado para justificar. Ninguno de nosotros se va a echar a los legados y hacer algo grande.

Las dificultades de sustitución de los sistemas de áreas funcionales perpetuaron el deterioro del entorno heredado de Cisco. Modificación incremental continuó mientras que la compañía sufrió una tasa de crecimiento anual del 80%. Sistemas cortes se convirtieron en rutina. Defectos del producto exacerbaron las dificultades de la recuperación de los cortes.

Finalmente, en enero de 1994, el medio ambiente legado de Cisco no tan dramáticamente que las deficiencias de los sistemas existentes ya no pueden ser ignorados. Un método no autorizado para

acceder a la aplicación principal base de datos-una solución 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 compañía fue cerrado en gran parte durante dos días.

La lucha de Cisco para recuperarse de esta importante parada trajo a casa el hecho de que los sistemas de la compañía estaban al borde del fracaso total. Solvik, Charca, y un número de otros gestores de Cisco llegaron a la conclusión de que el enfoque autónomo a la sustitución de sistemas que habían 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 necesitaría demasiado tiempo para conseguir estas aplicaciones en su lugar. Teníamos que tomar una acción más rápida. En ese momento llegamos patrocinio de la SVP de Fabricación, Carl Redfield. Él estaba con digital antes de Cisco, en la fabricación de PC. Él tomó la iniciativa y dijo: "Está bien, vamos a seguir adelante con esto. ... Vamos a empezar desde la perspectiva de la fabricación, y ver si podemos obtener la orden de entrada y grupos financieros de la empresa interesada en hacer una única sustitución integral de todas las aplicaciones, en lugar de tomar más tiempo haciendo proyectos separados. "Y así, en febrero, un mes después de la [apagado empresa], fuimos en armar un equipo para hacer una investigación para reemplazar la aplicación.

Redfield entiende a partir de experiencias de implementación a gran escala anteriores en digital cómo los proyectos de TI "monolíticos" podrían tomar en sus propias vidas. Él se hizo eco de las preocupaciones de Solvik sobre el tamaño del proyecto y tenía fuertes opiniones acerca de cómo Cisco debe acercarse a un proyecto de implementación de gran tamaño.

Yo sabía que quería hacer esto rápidamente. No íbamos a hacer una implementación por fases, haríamos todo de una vez. Nosotros no íbamos a permitir que una gran cantidad de personalización tampoco. Hay una tendencia en systems5 MRP para que las personas quieren que el sistema para reflejar su método de operación en lugar de readaptación a la gente a hacer las cosas de la forma en que el sistema les destina. Esto toma mucho más tiempo. Además, 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 aplicación para satisfacer las necesidades del negocio requeriría una fuerte participación de la comunidad empresarial. Esto no podría ser una iniciativa de TI sólo. Era de vital importancia para conseguir las mejores personas que pudieron encontrar. Solvik explicó: "Nuestra orientación en sacar a la gente de sus puestos de trabajo [a trabajar en el proyecto] fue si era fácil entonces estábamos recogiendo las personas equivocadas. Llegamos a la gente de que el negocio absolutamente no quería renunciar ".

En consonancia con la necesidad de un fuerte equipo de Cisco, la compañía también necesitaría socios fuertes. Solvik y Redfield sintieron que era particularmente importante trabajar con un socio de integración que podrían ayudar en la selección y aplicación de cualquier solución que la compañía eligió. Grandes habilidades técnicas y conocimiento del negocio eran un requisito previo. Solvik explicó la elección de KPMG como el socio de integración:

KPMG entró y vio la oportunidad de realmente construir un negocio alrededor de poner en estas aplicaciones. También vieron esto como una especie de oportunidad de definir, a trabajar con nosotros en este proyecto. A diferencia de algunas otras empresas que querían traer una gran cantidad de "novatos", KPMG fue la construcción de una práctica de las personas que tenían mucha experiencia en la industria. Por ejemplo, el director del programa que ponen en el trabajo, Mark Lee, había sido director de TI de una empresa en Texas que había 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 múltiple para la identificación 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 demás. Pidieron a las grandes corporaciones y las empresas de contabilidad "Big Six" lo que sabían. También intervenidos fuentes de la investigación, como el Grupo Gartner. Orientando el proceso de selección a lo que la gente estaba utilizando realmente y de hacer hincapié en la velocidad de decisión, Cisco se redujo el campo a cinco paquetes dentro de dos días. Después de una semana de la evaluación 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 tamaño era un problema en la selección. "Decidimos que no debemos poner el futuro de Cisco en manos de una empresa que fue significativamente menor que nosotros."

El equipo pasó 10 días 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 análisis de Cisco de las respuestas de RFP, cada vendedor fue invitado en una demostración de software de tres días y pidió que mostrara cómo su paquete podría cumplir con los requisitos de procesamiento de información de Cisco. Cisco proporciona datos de la muestra, mientras que los vendedores ilustran cómo se cumplen los requisitos clave (o no se cumplen) por el software.

Selección de Oracle se basa en una variedad de factores. Redfield describe tres de los principales puntos de decisión:

En primer lugar, este proyecto estaba siendo conducido muy fuertemente por la fabricación y Oracle tenido una mejor capacidad de fabricación que el otro proveedor. En segundo lugar, se hicieron una serie de promesas en relación 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 también tenía razones para creer que Oracle estaba particularmente motivado para hacer que el proyecto sea un éxito. Pond siempre su impresión de la situación de Oracle: "Oracle quería 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 conversación general, a muchas empresas que están involucradas en la toma de esta decisión. "El proyecto de Cisco sería la primera aplicación importante de una nueva versión del producto Oracle ERP. Oracle estaba promoviendo la nueva versión que tiene importantes mejoras en el soporte de la fabricación. Una implementación exitosa de Cisco lanzará la nueva versión en una trayectoria muy favorable.

Desde el inicio hasta la selección final del equipo de Cisco había pasado 75 días. La elección final se basó en equipo. Solvik describe cómo se tomó la decisión y presentó a los vendedores:

El equipo hizo internamente la elección e informó a los vendedores. No hubo un proceso importante que tuvimos que ir a través con la administración para "aprobar" la selección. 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 administración. El foco de inmediato se dirigió a cuestiones de cuánto tiempo tomaría el proyecto y cuánto costaría. El equipo decidió que "sí, vamos a hacer esto y debemos seguir adelante con el proyecto." Así que ahora en el final de abril estábamos poniendo todo el plan juntos.

Yendo a la JUNTA

Antes de ir a la junta para su aprobación, el equipo necesario para responder a dos preguntas muy importantes: ¿Cuánto es el costo y el tiempo que se tarda? Ellos sabían que sus ejecutivos estaban preocupados de que un gran proyecto podría salirse de control y ofrecer resultados de calidad inferior. A pesar de los riesgos, el equipo tomó un enfoque pragmático para la estimación 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 "¿cuánto tiempo debe tomar para hacer un proyecto para reemplazar todos nuestros sistemas centrales?" Esto es realmente cómo fue. Dijimos "usted sabe que no podemos aplicar en el cuarto trimestre. Los auditores tendrán una vaca completa. "Si se tarda un año estaremos implementando el cuarto trimestre, y que no va a funcionar. Pensamos que realmente debe tener 15 meses, julio o agosto, un año más 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 ridículo. Así que empezamos a ir en la dirección opuesta y dijo también podemos hacerlo en cinco meses? Eso no me parece correcto. Entender que no teníamos un alcance todavía. Al final nos quedamos básicamente que queríamos ir directo al inicio de la Q3, por lo que estaríamos completamente estable para el 4T. (Ver Anexo 2 para un resumen de las fechas de aplicación ERP hito.)

Que se encargó de fijar una fecha límite. Luego vino la tarea de estimar un presupuesto del proyecto. Una vez más, Cisco fue agresiva: "Después nos pusimos una fecha, se estimaron los presupuestos. Ponemos todo esto juntos sin ser realmente tan lejos en este programa. Nos miramos el cuánto tocó "(Pete Solvik). En lugar de desarrollar un caso de negocio formal (es decir, un análisis financiero) para demostrar el impacto que el proyecto tendría sobre la empresa, el equipo optó por centrarse en las cuestiones que habían suscitado el análisis en el primer lugar. En opinión de Solvik, Cisco tuvo más remedio que moverse. Explicó su aproximación a la situación:

Nos dijo que teníamos este gran apagón en enero. Que éramos el mayor cliente de nuestro proveedor de software actual y que el vendedor estaba siendo comprada por otra compañía. No estaba claro que iba a apoyar a nuestros sistemas existentes y teníamos que hacer algo. La fiabilidad, la escalabilidad y la modificabilidad de nuestras aplicaciones actuales no apoyarían nuestro crecimiento futuro anticipado. Necesitábamos tanto las actualizaciones de la nueva versión de la aplicación actual o que necesitábamos para reemplazarlo. Si reemplazamos, podríamos 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

solución ERP. Estamos comprometidos a hacerlo en nueve meses por $ 15 millones de dólares 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 justificación económica formal, fue también una cuestión de filosofía de gestión. Como Redfield puso:

Usted no se acercan a este tipo de cosas desde la perspectiva de la justificación. Reducción 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 organización.

En $ 15 millones, el proyecto constituiría el proyecto de capital más grande sola vez aprobado por la empresa. Los miembros del equipo preparados para tomar este número a la alta dirección con cierto temor. La primera reunión con el CEO Morgridge no hizo nada para aliviar sus preocupaciones. Pond describió la reunión con Morgridge de esta manera:

Pete Solvik, Tom Herbert y yo hicimos la propuesta de Morgridge y la reacción fue bastante interesante. Hizo el comentario "usted sabe, las carreras se han perdido más de mucho menos dinero que esto." Pete y yo estábamos tan blanca como una hoja de papel. Sabíamos 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 recepción no era mucho más cálido 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: "¿Cuánto?", Le dije que estaba recibiendo a él y él respondió: "No me gusta sorpresas. Sólo hay que poner la diapositiva hasta ahora. "Después de que me puse hasta que dijo" Oh, Dios mío, no vale que sea un montón de buenas diapositivas. . . ".

Había ya la junta terminó aprobando el proyecto. En las semanas y meses siguientes a la reunión, 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 año. "Todo el mundo en la compañía sabía lo que estaba sucediendo y que era una prioridad para el negocio", explicó Pond

Construyendo el Equipo de Implementación

Con la aprobación del directorio en la mano, el equipo de ERP central no perdió tiempo en la creación de una estructura para la ejecución. Uno de sus primeros actos fue extender la relación de Cisco con KPMG hasta el final de la ejecución. Esta decisión fue tomada en base al rendimiento de KPMG a través del proceso de selección de software, y el continuo compromiso de la empresa con el personal del proyecto con su personal más experimentados.

Proceder con la aplicación también significó que el equipo tuvo que expandirse desde sus centrales 20 miembros a 100, lo que representa una sección transversal de la comunidad empresarial de Cisco. Una vez más, el equipo buscó sólo lo mejor para su inclusión en el proyecto. Una de las reglas de enfrentamiento para los que trabajan en la aplicación es que era a corto plazo en la duración 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 implementación, describe cómo era vista la misión: "Ellos escogido las mejores y más brillantes para este equipo. Para cada persona que era una posibilidad la promoción profesional. La gente hacía 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 tenía un líder Cisco sistemas de información, un Cisco líder empresarial, de negocios y de TI consultores de KPMG ya sea u Oracle, y personal adicional de la empresa, como los miembros del equipo (véase Anexo 4 para un diagrama de la estructura del equipo de ERP de Cisco). Las pistas fueron manejados de una "Oficina de Gestión de Proyectos", que incluía Agente ejecutivo de negocios de Cisco, Tom Herbert, y Mark Lee, el director de KPMG Proyecto.

Sentado encima de toda la estructura de gestión del proyecto fue un Comité de Dirección 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 gestión del proyecto. La función 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 dirección eventos de celebración. Para asegurar esto, se centraron en abordar cuestiones de dirección de los miembros del comité antes de las reuniones.

Implementando ORACLE

Estrategia de implementación del equipo empleó una técnica de desarrollo denominada "prototipado rápido iterativo." Con este enfoque, los miembros del equipo se rompió la aplicación en una serie de fases llamada "sala de conferencias" Los pilotos (CRP). El propósito de cada CRP fue construir en el trabajo previo para desarrollar una comprensión más profunda del software y de la forma en que funcionaba dentro del entorno empresarial.

CRP0

El primer CRP (CRP0) comenzó con la capacitación del equipo de implementación y configuración del entorno técnico. 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 formación de cinco días en dos días de 16 horas. En un período de dos semanas a la mayoría de los miembros del equipo participaron en esta capacitación "inmersión" para todo el conjunto de aplicaciones. Mientras esto ocurría, un pequeño "equipo de tigre" se dedica a la segunda esfuerzo, conseguir las aplicaciones en funcionamiento.

Después de la capacitación y la configuración del sistema, el equipo central se reunió en una sesión diseñada para configurar rápidamente el paquete de Oracle. Los miembros del equipo de todas las áreas de la empresa se "bloquean" juntos en una reunión fuera del sitio para discutir y decidir sobre la configuración adecuada para los cientos de parámetros 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 cómo se va a ejecutar los sistemas. Se establece, literalmente, cientos de parámetros en estas aplicaciones. Así que nos fuimos fuera de la escuela dos días a 40 personas, y asignación de la preparación de todo el mundo estaba de esa reunión fuera del sitio, tal vez tres o cuatro semanas en el proyecto en esta etapa, se procedió con una recomendación 80-20 sobre la forma de configurar el sistema. Nos reunimos todo el día y en la noche durante dos días, de bajar a la "nthdegree" en cómo í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 precisión en cómo íbamos a ejecutar esta aplicación, en lugar de un enfoque ERP típico, 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 precisión en términos de cómo podríamos hacer esto.

Una semana después de esta reunión, el equipo completó CRP0 con una demostración de la capacidad del software para tomar una orden de Cisco todo el camino a través de procesos de negocio de la compañía (Quote-to-Cash).

Una realización importante que sale de CRP0 fue que Cisco no sería capaz de adherirse a uno de sus primeros objetivos para la modificación de implantación para evitar el software de ERP. Modificación Evitar era importante porque los cambios tienden a ser específicas de la empresa y hacer la migración a versiones de aplicaciones futuras difícil y lleva tiempo. Las experiencias del equipo durante la primera fase del proyecto indicaron que sin un número significativo de los cambios que el software no sería capaz de apoyar eficazmente la empresa. Por el plazo de un mes había pasado, era evidente que se necesitarían algunos cambios. Dentro de dos meses después de que se hizo evidente que algunos de los cambios sería sustancial.

CRP1

Sobre la base de las lecciones aprendidas en CRP0, el equipo de implementación 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 específica. 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 propósito y los procedimientos utilizados para completar un proceso (véase 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 corrían a través durante su modelado. Temas fueron abordados en las reuniones semanales de tres horas en poder de la Oficina de Gestión de Programas. Durante estas reuniones, los líderes 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. Había un gran número de procesos de negocio que el software no podría apoyar.

La respuesta del equipo de implementación de las lagunas que se encuentran en el sistema era desarrollar un medio para la categorización y evaluación de cada uno de ellos individualmente. "Todas las solicitudes de modificación 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 tenía que ir al Comité Directivo para su aprobación. "Había 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 modificación. 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 estaría diciendo "usted sabe, la fecha era el primero que escribe y en Oracle es el cuarto." En otros casos, fue la constatación de que tendríamos que contratar a 100 personas en la planta de producción 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. Además de la identificación de las modificaciones necesarias, el equipo de implementación también determinó que el paquete de Oracle no apoyaría adecuadamente el después de las necesidades de apoyo de ventas de la empresa. Como resultado, el equipo se embarcó en un esfuerzo simultáneo para evaluar y seleccionar un paquete de soporte de servicio. El paquete se seleccionó e implementó en un horario que hacía juego con el cronograma general de ejecución. Cisco planea irse a vivir a ambos paquetes en el mismo día.

CRP2 y CRP3

Como CRP1 convirtió en CRP2 y verano se convirtió en otoño, el equipo de implementación se encontraba en el más difícil parte más gruesa, de la aplicación. El alcance del proyecto se ha ampliado para incluir las modificaciones importantes, y un nuevo después del paquete de soporte de ventas. Otro cambio importante ámbito también se cernía. Debido a los impactos aguas abajo del proyecto fueron mucho mayores de lo esperado, el equipo decidió hacer frente a algunos problemas técnicos más grandes. Mientras que antes los sistemas tendían a comunicarse directamente entre sí (es decir, "punto a punto"), un nuevo enfoque ahora se emplearía en la que todas las comunicaciones de datos se llevaría a cabo a través de un "almacén de datos". La utilización de un almacén de datos que permitiría todas las aplicaciones de Cisco para acceder a una fuente única para sus necesidades de información.

Los cambios en el alcance significaban más cambios en la utilización de los recursos de Cisco, especialmente para el departamento de TI de 100 personas de la compañía. La naturaleza técnica de la mayoría 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:

Básicamente, 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 compañía están cambiando. Estamos necesitando para desviar más y más energía, y más y más recursos para el proyecto. "No hizo nada más que años. También decidimos no para convertir cualquier historia como parte de este proyecto. En cambio, el grupo de almacenamiento de datos creado la capacidad de informar histórico y futuro en una conversión 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 almacén de datos se convirtió en el sistema de puente que atravesaría 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 implementación continuó profundizando su comprensión de la Oracle y paquetes de servicio y para determinar mejor cómo 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 volúmenes de carga de procesamiento y transacción necesarios para ejecutar el creciente negocio de Cisco.

El enfoque de CRP3 estaba en probar el sistema completo y evaluar la preparación de la compañía para "ir a vivir." Una prueba final se llevó a cabo con una dotación completa de los usuarios para ver cómo el sistema que funcione, de adelante hacia atrás, con una carga de transacciones completo. El equipo de implementación ejecuta estas pruebas mediante la captura de valor de un día completo de los datos reales de las empresas y "volver a ejecutar" en un sábado de enero. Los miembros del equipo observaron cómo cada pista, a su vez, ejecuta la pena un día simulada de trabajo. Con este test completado a satisfacción de todo el equipo, todo el mundo se sentía listo para corte más 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 habitación y les hicimos asienten con la cabeza y decir "debemos ir.". . . Y luego doblamos la maldita cosa en. . . .

Cortando a ORACLE

[Después de corte y cambio] Yo no diría que la empresa golpeó la pared, pero yo diría que tuvimos importante retos diarios que necesitaban ser resueltos rápidamente para evitar un impacto significativo para la empresa. Por ejemplo, nuestro barco puntuales, envío en la fecha que nos comprometemos con el cliente, se redujo de 95% a 75%, todavía 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 día. El principal problema, como se vio después, era con la arquitectura de hardware y dimensionamiento. Ordinariamente corregir la deficiencia habría requerido la compra de hardware adicional, lo que aumenta el gasto total del proyecto. Pero Cisco había 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 configuración específica. Como resultado, la responsabilidad para la fijación de los problemas de rendimiento de hardware cayó completamente en el proveedor de hardware.

Un segundo problema tenía que ver con la capacidad del propio software para manejar el volumen de transacciones necesario en el entorno de Cisco. El diseño de la aplicación exacerbado los problemas de hardware mediante el procesamiento ineficiente tareas comunes. En retrospectiva, es evidente que la empresa había ido mal en su prueba final del sistema. Como Pond puso: "Algunas cosas resultaron gravemente rompieron en grandes volúmenes 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 había corrido procesos individuales secuencialmente en lugar de a la vez. Además, sólo se utilizó una base de datos parcialmente cargado. Después de corte, cuando todos los procesos se ejecutan a más de una base de datos totalmente convertido, el sistema carecía de la capacidad para procesar la carga requerida.

Los próximos dos meses fueron algunos de los más difíciles de toda la aplicación. Esto fue particularmente cierto para el personal de TI, ya que trató de lidiar con las dificultades técnicas 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. Había un montón de atención a conseguir que se haga. Estábamos trabajando muy largas horas; la toma de decisiones que afecten a la empresa en el futuro. . . . Siempre supimos que lo haríamos. Siempre fue un "cuándo", no un "si." Había [muchos] cosas que no te gusta de [el software].

El estado del proyecto ERP se convirtió en el número uno de orden del día de las reuniones del personal ejecutivo semanales. Compromiso proveedor fuerte de Oracle, el proveedor de hardware, y el plomo KPMG a una eventual estabilización del software y mejorar el rendimiento. Solvik describe el medio ambiente:

Así que durante unos 60 días 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 tenía 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 habíamos comprado una capacidad, por lo que todo lo que hicieron para añadir capacidad estaba fuera de su propio bolsillo.

Después de la Estabilización

Los problemas técnicos relacionados con la implementación de Oracle resultó ser de corta duración. En el transcurso de los próximos tres meses Cisco y sus proveedores, trabajando juntos, estabilizado, y ha añadido la capacidad para el sistema. El calvario implementación concluyó con una fiesta de celebración para la gestión de equipos y compañía. También asistieron varios miembros del Consejo de Administración de Cisco. Los sentimientos corrían alto que los nuevos sistemas de información deberían cumplir con la promesa de apoyar el rápido crecimiento que la compañía estaba esperando.

Como él firmó en su recomendación para la distribución de la prima, Solvik pensó en el enfoque que habían tomado hacia la implementación. "Reemplazo de sistemas totales por $ 15 millones en nueve meses que habría pensado que podríamos hacerlo?" Trató de pensar en las decisiones que él y el equipo había hecho durante el curso de la ejecución. ¿Qué factores se habían hecho la diferencia entre el éxito y el fracaso? Donde habían sido inteligente? ¿Dónde habían estado simplemente con suerte? Podrían hacerlo de nuevo si tuvieran que?