Pregunta: Estudio de caso de implementación de ERP de Cisco. ¿Problemas y cuestiones clave planteadas en el caso? Analisis de CASO; ¿Soluciones alternativas a los problemas anteriores con pros y contras para cada alternativa? (utilice marcos de gestión de TI en su análisis) Recomendaciones de Manejo; ¿Solución recomendada y justificación? Analice el impacto de la

Estudio de caso de implementación de ERP de Cisco.

¿Problemas y cuestiones clave planteadas en el caso? Analisis de CASO; ¿Soluciones alternativas a los problemas anteriores con pros y contras para cada alternativa? (utilice marcos de gestión de TI en su análisis)

Recomendaciones de Manejo; ¿Solución recomendada y justificación?

Analice el impacto de la globalización en su recomendación y su aplicabilidad fuera del mercado interno.

Pete Solvik, CIO de Cisco Systems, la última línea restante de su presupuesto de implementación de Planificación de Recursos Empresariales. Un momento decisivo, al año siguiente se avanzó poco. Pond, director colíder del proyecto, describió el dilema que enfrentaban las áreas funcionales en 1993: Si nada cambiaba, estábamos en problemas, cualquier cosa que hiciéramos pasaría por encima de los sistemas heredados existentes. Se convirtió en un esfuerzo por arreglar constantemente nuestros sistemas existentes. Las interrupciones de los sistemas se convirtieron en rutina. Las deficiencias del producto exacerbaron las dificultades para recuperarse de las interrupciones. En 1994, la situación heredada de Cisco fracasó terriblemente y las deficiencias de los sistemas existentes ya no podían ignorarse. Un método no autorizado para acceder a la base de datos central de la aplicación, una solución que en sí misma fue motivada por la incapacidad del sistema para funcionar mal, corrompiendo la base de datos central de Cisco. La empresa estuvo cerrada en gran medida durante 2 días. En ese momento, aproximadamente un mes después del [cierre de la empresa], formamos un equipo para investigar y reemplazar la aplicación. Solvik explicó la elección de KPMG como socio de integración: KPMG entró y vio la oportunidad de construir realmente un negocio en torno a la instalación de estas aplicaciones. La estrategia del equipo fue construir conocimiento aprovechando las experiencias de otros. También recurrieron a fuentes de investigación como Gartner Group. Orientando el proceso de selección a lo que la gente estaba usando y continuando enfatizando la velocidad de decisión. Oracle y otro jugador importante en el mercado de ERP. El equipo pasó 10 días escribiendo una Solicitud de propuestas (RFP) para enviar a los proveedores. A los proveedores se les dio 2 semanas para responder, mientras los proveedores preparaban sus respuestas. El equipo de Cisco continuó con su "diligencia debida" visitando una serie de clientes de referencia ofrecidos por cada proveedor. Después del análisis de Cisco de las respuestas a la RFP, se invitó a cada proveedor a una demostración de software de 3 días para ver cómo su paquete podía cumplir con los requisitos de procesamiento de información de Cisco. La selección de Oracle se basó en una variedad de factores, en primer lugar, este proyecto estaba siendo impulsado en gran medida por la fabricación y Oracle tenía una mejor capacidad de fabricación que el otro proveedor. En segundo lugar, hicieron una serie de promesas con respecto al desarrollo a largo plazo de la funcionalidad del paquete. La otra parte era la flexibilidad que ofrecía la cercanía de Oracle. El proyecto de Cisco sería la primera implementación importante de una nueva versión del producto Oracle ERP. Oracle estaba promocionando la nueva versión con importantes mejoras en el soporte de la fabricación. Una implementación exitosa en Cisco lanzaría la nueva versión en una trayectoria muy favorable. Desde el inicio hasta la selección final, el equipo de Cisco pasó 75 días. No hubo ningún proceso importante por el que tuviéramos que pasar con la gerencia para "aprobar" la selección. Luego pasamos a las negociaciones del contrato con Oracle y elaboramos una propuesta para nuestra junta directiva. Así que ahora, a fines de abril, estábamos armando todo el plan. Dijimos que tuvimos este gran apagón en enero. Que éramos el mayor cliente de nuestro proveedor de software actual y que otra empresa estaba comprando al proveedor. No estaba claro quién iba a respaldar nuestros sistemas existentes y necesitábamos hacer algo. La confiabilidad, la escalabilidad y la modificabilidad de nuestras aplicaciones actuales no respaldarían nuestro crecimiento futuro anticipado. Necesitábamos actualizaciones a la nueva versión de la aplicación actual o necesitábamos reemplazarla. Si lo reemplazáramos, podríamos hacerlo por partes o hacerlo como un todo. Evaluamos esas 3 alternativas, hablamos sobre los pros y los contras de cada alternativa y recomendamos que reemplacemos nuestros sistemas, a lo grande, con una solución ERP. Nos comprometimos a hacerlo en 9 meses por $15 millones. Con la aprobación de la junta en h&, el equipo central de ERP no perdió tiempo en establecer una estructura para la implementación. Continuar con la implementación también significó que el equipo tuvo que expandirse de 20 miembros a aproximadamente 100. Una de las reglas de compromiso para quienes trabajaban en la implementación era que era de corta duración y no representaba un cambio de carrera para los involucrados. Los miembros del equipo de todo Cisco se colocaron en 1 de 5 "pistas" (equipos de área de proceso). Cada pista tenía un líder de sistemas de información de Cisco, un líder comercial de Cisco, consultores comerciales y de TI de KPMG u Oracle, y personal adicional de la empresa como equipo. Herbert y Mark Lee, gerente de proyectos de KPMG. Sentado sobre toda la estructura de gestión de proyectos había un Comité Directivo Ejecutivo compuesto por el vicepresidente de fabricación, el vicepresidente de defensa del cliente, el controlador corporativo, Solvik, el vicepresidente senior de aplicaciones de Oracle y el socio a cargo de West Coast Consulting para KPMG. . La presencia en el comité directivo de ejecutivos de tan alto nivel de Oracle y KPMG fue indicativa de la importancia que estas organizaciones le dieron al éxito del proyecto. La estrategia del equipo de ERP para utilizar el Comité Directivo fue liberarlos de la necesidad de intervenir directamente en la gestión del proyecto. El papel del comité era proporcionar un patrocinio de alto nivel para el proyecto, asegurar la visibilidad y motivar al equipo. El equipo tenía como objetivo hacer que las reuniones del comité directivo fueran eventos de celebración. Para garantizar esto, se concentraron en abordar las preguntas de los miembros del comité directivo antes de las reuniones. Implementación de Oracle: la estrategia de implementación del equipo empleó una técnica de desarrollo conocida como "prototipo iterativo rápido". Usando este enfoque, los miembros del equipo dividieron la implementación en una serie de fases denominadas "Pilotos de sala de conferencias" (CRP). El propósito de cada CRP era construir sobre el trabajo previo para desarrollar una comprensión más profunda del software y cómo funcionaba dentro del entorno empresarial. El primer CRP (CRP0) comenzó con la capacitación del equipo de implementación y la configuración del entorno técnico. El primer esfuerzo se centró en capacitar al equipo en las aplicaciones de Oracle. Cisco ordenó a Oracle que comprimiera sus clases de capacitación normales de 5 días en 2 días de 16 horas. Los miembros del equipo de todas las áreas de la empresa se "encerraron" 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. A los miembros del equipo se unieron especialistas de Oracle y KPMG. Entonces, salimos del sitio dos días, 40 personas, y la tarea de todos era para esa reunión fuera del sitio, tal vez tres o cuatro semanas después del proyecto en esta etapa, llegó con una recomendación de 80-20 sobre cómo configurar el sistema. Expertos de Oracle, con expertos de KPMG, con gente de negocios de Cisco, gente de TI de Cisco, hablemos de GL, no es un enfoque típico de ERP, en el que te vas durante seis meses y lo analizas en exceso hasta la muerte. Tuvimos esto de tres a cuatro semanas en el proyecto, y terminamos siendo un 80% precisos en términos de cómo podíamos hacer esto. 1 semana después de esta reunión, el equipo completó CRP0 con una demostración de la capacidad del software para tomar un pedido de Cisco a lo largo del proceso comercial de la empresa (de la cotización al efectivo). Una conclusión importante que surgió de CRP0 fue que Cisco no podría cumplir con uno de sus primeros objetivos para la implementación: evitar la modificación del software ERP. Evitar la modificación era importante porque los cambios tienden a ser específicos de la empresa y hacen que la migración a versiones futuras de la aplicación sea difícil y requiera mucho tiempo. Las experiencias del equipo durante la primera fase del proyecto indicaron que, sin una cantidad significativa de cambios, el software no podría respaldar a la empresa de manera efectiva. Cuando había pasado un mes, estaba claro que se requerirían algunos cambios. Dos meses después de eso, quedó claro que algunos de los cambios serían sustanciales. Cuando nos dimos cuenta de que no íbamos a poder transmitir en vivo "vainilla", comenzamos a trabajar en nuestra estrategia de modificación. Los meses de julio y agosto estuvieron enfocados en que modificaciones íbamos a hacer? Lo que es real y lo que no lo es. En algunos casos, el usuario estaría diciendo "sabes, la fecha solía ser lo primero que ingresabas y en Oracle, es la cuarta". En otros casos, nos dimos cuenta de que tendríamos que contratar a 100 personas en el piso de producción para abrir y cerrar órdenes de trabajo si no encontrábamos una manera de automatizarlo. El descubrimiento de la necesidad de modificar Oracle condujo a algunos cambios no planificados en el plan y el presupuesto del proyecto. Además de la identificación de las modificaciones requeridas, el equipo de implementación también determinó que el paquete de Oracle no respaldaría adecuadamente las necesidades de soporte posventa de la empresa. Como resultado, el equipo se embarcó en un esfuerzo simultáneo para evaluar y seleccionar un paquete de soporte de servicios. El paquete se seleccionó e implementó en un cronograma que coincidió con el cronograma general de implementación. Cisco planeó lanzar ambos paquetes el mismo día. CRP2 y CRP3: cuando CRP1 se convirtió en CRP2, el equipo de implementación se encontró en la parte más compleja y difícil de la implementación. El alcance del proyecto se ha ampliado para incluir modificaciones importantes y un nuevo paquete de soporte posventa. También se avecinaba otro cambio importante en el alcance. Debido a que los impactos posteriores del proyecto fueron mucho mayores de lo esperado, el equipo decidió abordar algunos problemas técnicos más importantes. Mientras que antes los sistemas tendían a comunicarse directamente entre sí, ahora se emplearía un nuevo enfoque en el que toda la comunicación de datos se realizaría a través de un "almacén de datos". La utilización de un almacén de datos permitiría que todas las aplicaciones de Cisco accedieran a una única fuente para sus necesidades de información. Los cambios de alcance significaron cambios adicionales en la utilización de los recursos de Cisco, especialmente para su departamento de TI de 00 personas. La naturaleza técnica de la mayoría de los cambios de alcance significó que este grupo asumiera la mayor parte de la responsabilidad por la adición del proyecto. Solvik describió el resultado: Básicamente, todo el resto del grupo de TI comenzó a desvincularse de sus otros proyectos. Dijeron “tenemos que pasar nuestro tiempo simplemente absorbiendo el hecho de que los sistemas centrales de la empresa están cambiando. Necesitamos desviar más y más energía y más y más recursos hacia el proyecto”. No hizo nada más ese año. También decidimos no convertir ninguna historia como parte de este proyecto. En su lugar, el grupo de almacenamiento de datos creó la capacidad de generar informes históricos y futuros en una conversión de datos integrada. Renumeramos a nuestros clientes; renumeramos nuestros productos y cambiamos nuestra estructura de lista de materiales. Cambiamos, y el almacén de datos se convirtió en el sistema puente que uniría la historia y el futuro. Al final de CRP2, la primera ronda de modificaciones estaba en su lugar y en funcionamiento. Durante este tiempo, el equipo de implementación continuó profundizando su comprensión de los paquetes Oracle y Service y para determinar cómo hacer que funcionen mejor para Cisco. El objetivo final de CRP2 era comenzar a probar el sistema, tanto el hardware como el software, para ver qué tan bien resistiría la carga de procesamiento y los volúmenes de transacciones necesarios para operar el negocio en crecimiento de Cisco. El enfoque de CRP3 estaba en probar el sistema completo y evaluar la preparación de la empresa para "salir en vivo". Se realizó una prueba final con un complemento completo de usuarios para ver cómo funcionaría el sistema, de principio a fin, con una carga completa de transacciones. El equipo de implementación ejecutó estas pruebas capturando un día completo de datos comerciales reales y “volviéndolos a ejecutar” un sábado de enero. Los miembros del equipo observaron cómo cada pista, a su vez, ejecutaba el trabajo de un día simulado. Con esta prueba completada a satisfacción de todo el equipo, todos se sintieron listos para la transición en febrero. El envío único, el envío en la fecha en que nos comprometemos con el cliente, cayó del 95 % a aproximadamente el 75 %, aún no era miserable, pero no era bueno. — Pete Solvik El éxito inicial de la transición de Cisco a Oracle fue, por decir lo menos, algo menos de lo que se esperaba. El rendimiento comercial general se desplomó Los usuarios intentaron lidiar con un nuevo sistema que era inquietantemente inestable. El sistema dejó de funcionar casi una vez al día, ya que resultó que el problema estaba en la arquitectura y el tamaño del hardware. Normalmente, corregir la deficiencia habría requerido la compra de hardware adicional, aumentando así el gasto total del proyecto. Cisco había pedido y obtenido un contrato inusual del proveedor de hardware. En su contrato, Cisco compró equipos en función de una capacidad prometida en lugar de una configuración específica. La responsabilidad de solucionar los problemas de rendimiento del hardware recayó completamente en el proveedor del hardware. Un segundo problema tenía que ver con la capacidad del propio software para manejar el volumen de transacciones requerido en el entorno de Cisco. El diseño de la aplicación exacerbó los problemas de hardware al procesar tareas comunes de manera ineficiente. En retrospectiva, estaba claro dónde se había equivocado la empresa en la prueba final del sistema. Como lo expresó Pond: “Algunas cosas se rompieron seriamente en grandes volúmenes de datos, . . . Y tenemos una gran base de datos. Nuestro error fue que no probamos el sistema con una base de datos lo suficientemente grande adjunta”. Al probar el sistema, Cisco ejecutó procesos individuales secuencialmente en lugar de hacerlo al mismo tiempo. Además, solo se utilizó una base de datos parcialmente cargada. Después de la transición, cuando todos los procesos se ejecutaban juntos en una base de datos completamente convertida, el sistema carecía de la capacidad para procesar la carga requerida. Los siguientes 2 meses fueron algunos de los más difíciles de toda la implementación. Esto fue particularmente cierto para el personal de TI, ya que trató de lidiar con las dificultades técnicas provocadas por la implementación del nuevo sistema. Fee describió cómo era en ese momento: Fue duro, realmente estresante. Esta fue una gran cosa, una de las principales iniciativas de la empresa. Había mucho enfoque en lograrlo. Trabajábamos muchas horas; tomar decisiones que afectarían a la empresa en el futuro.