Caso 4 Vandelay Industry

606-S27 REV. 16 DE ABRIL, 1997

ANDREW McAFEE DAVID UPTON

Vandelay Industries, Inc. Un lunes de enero de 1996 por la mañana, Elaine Kramer estaba en su despacho de Filadelfia poniéndose al día en su correo electrónico. La semana anterior había estado en Minneapolis, en una serie de reuniones en las que habían participado personas de su empresa, Deloitte & Touche Consulting Group/ICS, y directivos y directores de planta de Vandelay Industries, un importante fabricante de equipo para procesos industriales. Como resultado, se había establecido un acuerdo entre las dos empresas para trabajar conjuntamente en un gran proyecto de implantación de sistemas de información. De pronto sonó el teléfono. «¿Sí? Soy Elaine Kramer.» «Hola, Elaine. Te habla George Hall. Soy el director de la planta de Dunbarton de Vandelay; nos conocimos en las reuniones de lanzamiento del proyecto que tuvimos la semana pasada.» «¡Ah! Sí, ya recuerdo. ¿Cómo estás? Me gustó tu presentación sobre el proyecto del sistema de fabricación “pull”. Los resultados parecían excelentes. ¿De qué se trata?» «He estado pensando en la posibilidad de empezar a formar a mi gente en el sistema R/3. Sé que es muy pronto, pero aquí todos tenemos ganas de comenzar. Vuestras presentaciones convencieron a mucha de nuestra gente y ahora están deseosos de sustituir nuestro viejo ordenador central. Queremos organizar un “equipo R/3” de manera que cuando se instale en Dunbarton podamos empezar a trabajar en serio desde el primer momento.» «Bueno, de hecho no hemos ni empezado todavía a diseñar los calendarios de formación…» «Entiendo. Entonces, por favor, acordaros de nosotros cuando lo hagáis. Como dije en mi presentación, a mi gente le gusta experimentar con cosas nuevas, y todos creemos que esto nos ha ayudado mucho a mejorar durante los últimos años. Estamos convencidos de que el sistema R/3 nos vendrá muy bien para superar alguna de las dificultades que tenemos ahora, y por eso queremos empezar cuanto antes.» «De acuerdo, me pondré en contacto contigo cuando tengamos los planes de formación un poco más claros.» Kramer colgó el teléfono y repasó mentalmente la conversación que acababa de tener; de hecho, venía a poner sobre la mesa un tema al que había estado dando vueltas después de las reuniones de la última semana. ¿Qué significaría para las distintas plantas la instalación de los nuevos ordenadores que el despliegue de R/3 exigía? _________________________________________________________________________________________________________________ El caso de LACC número 606-S27 es la versión en español del caso HBS número 9-697-037. Los casos de HBS se desarrollan únicamente para su discusión en clase. No es el objetivo de los casos servir de avales, fuentes de datos primarios o ejemplos de una administración buena o deficiente. Copyright 1996 President and Fellows of Harvard College. No se permitirá la reproducción, almacenaje, uso en plantilla de cálculo o transmisión en forma alguna: electrónica, mecánica, fotocopiado, grabación u otro procedimiento, sin permiso de Harvard Business School.

606-S27

Vandelay Industries, Inc.

Antecedentes del proyecto En 1995, Vandelay había decidido implantar, a nivel corporativo, un sistema de información basado en un único sistema «Enterprise Resource Planning» (ERP). Había elegido el sistema R/3 de SAP AG, una empresa alemana líder en el mercado de ERP. Un criterio importante para la elección fue que la implantación de R/3 pondría fin a la fragmentación de sistemas existente en Vandelay, además de facilitar la estandarización de procesos en toda la corporación, proporcionando a la empresa una ventaja competitiva sobre sus rivales. Los directivos de Vandelay eran conscientes de que la implantación de R/3 requeriría un esfuerzo enorme, del que la instalación del nuevo hardware y el software correspondiente era sólo una pequeña parte. Para ayudarles en todos los aspectos del proyecto, desde los detalles técnicos hasta conseguir la efectiva adopción de los nuevos procedimientos en toda la empresa, Vandelay había contratado a Deloitte & Touche Consulting Group/ICS. ICS tenía experiencia en ayudar a sus clientes en la gestión de cambios fundamentales como el de la adopción de un sistema ERP, y tenía experiencia con el sistema R/3 de SAP. Kramer, que llevaba más de cinco años en la empresa, había sido elegida para liderar el proyecto. En las reuniones de Minneapolis le había impresionado el entusiasmo que Vandelay había mostrado por el proyecto. Los directores de planta parecían los más entusiastas; muchos de ellos habían dicho que los sistemas de información existentes constituían más un impedimento que una ayuda para conseguir una producción eficiente. George Hall parecía encantado con la idea de implantar R/3 en su planta, pero Kramer no se sentía tranquila después de la reciente conversación. Hall suponía, evidentemente, que en Dunbarton podrían modificar el sistema a su antojo, y Kramer sabía que eso no era posible. Se preguntaba cómo responder a la petición de formación de Hall y cómo transmitir claramente, tanto a él como a los demás directores de planta, que no podrían tener control sobre todas las decisiones relacionadas con la implantación de R/3.

Vandelay Industries, Inc. Antecedentes de la empresa Vandelay Industries, Inc. era una corporación centrada en la fabricación y distribución de equipo para procesos industriales en el sector de la goma y el látex, que facturaba unos 8.000 millones de dólares. La empresa se había fundado en Minnesota durante la segunda guerra mundial. Inicialmente, sus productos resultaron importantes para el denominado «Home Front», contribuyendo a significativas mejoras en productividad necesarias en las industrias de guerra. Desde el principio, los productos de Vandelay fueron reconocidos por la calidad e innovación de sus diseños e ingeniería, algo fundamental en una época de escasez de materias primas que exigía procesos de producción precisos y con pocos desperdicios. Los mercados para los productos de Vandelay fueron muy rentables durante las décadas que siguieron a la segunda guerra mundial, con lo que la empresa creció y se expandió, en parte a través de instalaciones de nueva planta y en parte a través de la adquisición de empresas más pequeñas1. La empresa también expandió sus líneas de producto de manera continuada, llegando a suministrar a

1 La mitad de las nuevas instalaciones de Vandelay puestas en funcionamiento entre 1945 y 1985 fueron el resultado de adquisiciones.

2


606-S27

varias industrias de proceso. Las distintas plantas se trataban como centros de ingreso y tenían un alto grado de independencia mientras mantuvieran márgenes razonables. En su momento culminante, la empresa había llegado a tener 30.000 empleados y plantas en cuatro continentes. Los empleados tendían a permanecer en Vandelay durante tiempo, aprovechando unos salarios generosos, complementos atractivos y un entorno de trabajo estimulante. Sin embargo, la empresa empezó a experimentar dificultades a mediados de los años ochenta, como consecuencia de cambios en sus mercados y de presiones competitivas importantes. Aparecieron tres potentes competidores extranjeros que ofrecían alternativas a los productos de Vandelay en prácticamente todas sus líneas de productos, y con mejores precios. Generalmente, dichas alternativas no incluían todas las características funcionales de los productos de Vandelay, pero eran sustancialmente (20-30%) más baratas. Así, el tradicional énfasis de Vandelay en funcionalidad y capacidad de adaptación a las necesidades de cada cliente pasó de ser un activo a convertirse en un inconveniente. Sus procedimientos de fabricación no se habían diseñado para conseguir competir en coste, y ahora sus productos no podían venderse más caros que los de los competidores. Además, los plazos de entrega, que en Vandelay eran más bien largos, también se convirtieron en un problema, ya que los nuevos competidores eran capaces de servir mucho más deprisa. Vandelay reaccionó durante los diez años siguientes, incorporando nuevas tecnologías y aprendiendo a hacer las cosas de maneras distintas. Adoptó nuevos métodos de fabricación más eficientes, racionalizó sus líneas de productos e introdujo máquinas nuevas, más sencillas y baratas. También cerró tres plantas, manteniendo ocho en operación2, y por primera vez en su historia redujo la plantilla, dejándola en 20.000 empleados. Muchos de estos esfuerzos tuvieron éxito, y la empresa volvió a los beneficios a mitad de los años noventa. Durante esta década de adaptación a la nueva situación, los ejecutivos de Vandelay advirtieron que debían poner mucho más énfasis en producción y proceso de pedidos para poder seguir reduciendo costes. Necesitaban también ser más rápidos; las nuevas máquinas tenían buena aceptación, pero los plazos de entrega superaban a los de los competidores. Un estudio interno reveló que los procesos de fabricación propiamente dicha y los asociados de movimiento de materiales suponían sólo el 5% del plazo de entrega para una máquina determinada. La mayor parte del tiempo restante se dedicaba a procesar y transferir información. En parte, eso se debía al bajo nivel de integración entre los sistemas informáticos utilizados, que en algunos casos eran incluso incompatibles.

Sistemas de información Cada planta había elegido su propio sistema MRP («Manufacturing Resource Planning»), utilizado para traducir los pedidos de los clientes en necesidades de compra y de producción. Además, varias de las plantas habían instalado software especializado; por ejemplo, para elaborar previsiones, para planificar la capacidad de producción o para programar la producción. Los sistemas de información utilizados en la gestión de recursos humanos se habían seleccionado también de manera individual. El único caso de sistema integrado a nivel corporativo era el económico-financiero, para el cual cada planta había desarrollado su propia interfaz con objeto de facilitar intercambios electrónicos con los demás sistemas. A medida que Vandelay revisaba sus operaciones iban presentándose casos que ilustraban cómo sus sistemas de información añadían tiempo y coste al ciclo de producción. Por ejemplo:

2 Distribuidas así: 4 en Norteamérica, 2 en Europa y 2 en Asia.

3

606-S27


•

Programación. La disparidad de los sistemas de gestión de la producción hacía que la integración entre plantas resultara difícil. Por ejemplo, una de las plantas en Norteamérica mecanizaba y estampaba unas piezas que se utilizaban en otras fábricas. La planta productora usaba un sistema MRP antiguo, con entrada de datos manual. En este contexto, los pedidos de las demás plantas se entraban al principio de cada semana, una operación que requería casi un día completo. Por esta razón no se permitía entrar más pedidos a lo largo de la semana, lo cual provocaba retrasos y quejas.

•

Previsiones. El grupo europeo de planificación de la producción usaba un sistema de previsiones que mensualmente agrupaba la demanda para una pieza determinada, y las plantas elegían luego –a su conveniencia– cuándo producir, dentro del mes, la pieza correspondiente. Sin embargo, los pedidos de clientes especificaban la fecha de entrega sobre una base semanal, y la consiguiente falta de integración provocaba retrasos.

•

Gestión de pedidos. Los pedidos de clientes eran registrados manualmente por una organización interna regional (una en América, otra en Europa y otra en Asia), y después transmitida vía fax a la planta correspondiente, que a continuación la entraba en su sistema de gestión de pedidos. A veces, los faxes (es decir, los pedidos) se extraviaban.

•

Recursos humanos. Cuando un empleado de Vandelay se trasladaba de una planta a otra, era preciso transferir su registro de personal. Si los sistemas de gestión de recursos humanos eran incompatibles, como ocurría a menudo, esto significaba reentrar los datos correspondientes manualmente. Además de redundante y costoso, este procedimiento resultaba en falta de confidencialidad.

•

Contabilidad y finanzas. Los sistemas de gestión de la producción utilizados en la mayoría de las fábricas no estaban integrados con el sistema económico financiero de la empresa, de manera que datos como horas de mano de obra imputadas a un trabajo determinado, compras de materiales o pedidos servidos, debían introducirse en los dos sistemas. Esto constituía una fuente de errores y originaba la necesidad de reconciliaciones periódicas.

Prácticas y procedimientos de negocio Las prácticas y procedimientos empleados en las distintas plantas eran tan dispares como sus sistemas de información. No había una definición de la «mejor» manera de facturar a un cliente, cerrar las cuentas a fin de mes, asignar stock a un pedido o llevar a cabo cualquiera de los cientos de otras actividades en el proceso de producción, que al final requerían introducir datos en un sistema informático o usarlo de alguna manera. En las reuniones de Minneapolis, Kramer había oído «historias para no dormir» referentes a procesos deficientes que algunos directores de planta habían comentado. Algunas de estas historias merecían ser contadas: «Hace unos días fui al muelle de descarga y me entretuve en observar qué ocurría cada vez que llegaba el camión de un proveedor. Primero, nuestra gente de recepción comprobaba las cantidades. A continuación, dejando las cajas en el muelle, se dirigían a una terminal con las listas de descarga para comprobar, en nuestro sistema de calidad, si las piezas correspondientes debían ser inspeccionadas. En caso afirmativo, las cajas eran trasladadas a control de calidad. Si no era necesario, iban a otra terminal con las listas para introducir los datos de recepción de las piezas a nuestro sistema de compras, y trasladaban las cajas al almacén. Mientras tanto, la gente en el almacén trabajaba poniendo cajas en sus respectivas ubicaciones y registrándolas en el sistema. Si se detectaba cualquier discrepancia en las listas de descarga o llegaba un envío urgente, las cosas se complicaban de verdad.» 4


606-S27

Así opinaba Teri Buhl, director de la planta de Fort Wayne (IN). Por su parte, Alain Barsoux, director de la planta de Marsella, decía: «Cuando el año pasado me incorporé a la planta, no podía creer cómo se programaba el trabajo. Habían puesto en marcha un sistema que consistía en marcar con unas tarjetas verdes los pedidos de alta prioridad que debían estar al principio de la cola. El sistema funcionó durante un tiempo, pero en seguida alguien decidió que los pedidos realmente urgentes debían marcarse en rojo. Ya os podéis imaginar qué ocurrió a continuación. Cuando llegué, si un trabajo no estaba marcado de alguna manera, nadie le hacía caso. Había más de media docena de combinaciones de colores. Las colas parecían árboles de Navidad!» Para solucionar este tipo de problemas y mejorar los procedimientos, Vandelay decidió comprar e instalar un sistema ERP único, que incorporara toda la funcionalidad de los anteriores sistemas. La empresa deseaba también aprovechar el esfuerzo para estandarizar procedimientos en las distintas plantas. Vandelay veía además otra ventaja derivada de la instalación de un sistema ERP: mejorar el acceso, en un formato común, a datos procedentes de cualquier lugar de la empresa. La idea era que una vez instalado el sistema, y con el juego de autorizaciones que hiciera falta, los usuarios podrían consultar de forma instantánea la información que necesitaran, con independencia de su procedencia. Esto posibilitaría una mejor coordinación entre plantas y facilitaría una gestión más estricta del conjunto; a nivel de planta, sería posible ver qué estaban haciendo sus respectivos clientes y proveedores internos, y a nivel de conjunto, sería más fácil comparar el desempeño de distintas plantas. Después de revisar la oferta de ERP en el mercado y la correspondiente de consultoras que pudieran ayudar en el proceso de su implantación, Vandelay decidió adquirir el sistema R/3 de SAP e instalarlo con la ayuda de Deloitte & Touche Consulting Group/ICS.

El proveedor del sistema: SAP Antecedentes de la empresa SAP AG se fundó en 1972, en Walldorf, Alemania, con el objetivo de desarrollar un software integrado de aplicaciones para empresas. Estas aplicaciones debían incluir todas las actividades que normalmente lleva a cabo una empresa, desde compras y fabricación a servicio de pedidos de clientes y contabilidad. El primer producto de SAP fue el sistema R/2, pensado para ordenadores centralizados. Este sistema, y los que competían con él, recibieron la denominación de «Enterprise Information Systems» (EISs), mientras que en entornos manufactureros se conocieron como ERP, para indicar que incorporaban y expandían las funciones básicas de los MRP clásicos. SAP fue uno de los primeros proveedores de sistemas ERP que se dio cuenta de que la tecnología cliente-servidor, desarrollada en los años ochenta, iba a reemplazar las infraestructuras de ordenadores centralizados instaladas en muchas grandes empresas. SAP empezó a trabajar en un sistema pensado para funcionar en arquitectura cliente-servidor en 1987, y presentó el sistema R/3 en 1992. Este sistema aprovecha muchas de las características de la arquitectura cliente-servidor; por ejemplo: •

Facilidad de uso. Las aplicaciones basadas en cliente-servidor usan ordenadores personales ya utilizados en las empresas para otros propósitos, como hojas de cálculo y procesadores de texto.

5

606-S27


•

Facilidad de integración. La arquitectura cliente-servidor es más flexible y puede conectarse más fácilmente, tanto internamente a equipos de control de procesos, por ejemplo, como externamente a otras redes de ordenadores e Internet.

•

Escalabilidad. Es decir, la posibilidad de añadir potencia de cálculo a la instalación de manera más incremental que antes. Se pueden añadir máquinas relativamente pequeñas y baratas a una instalación sin necesidad de incurrir en grandes inversiones. Con los ordenadores centralizados, esto era imposible.

•

Estándares más abiertos. Los sistemas operativos generalmente utilizados en entornos clienteservidor son estándar, lo cual permite combinar hardware de marcas distintas en una misma instalación. En el contexto de ordenadores centralizados, las tecnologías no eran estándar, de manera que sólo podían adquirirse a un proveedor.

Como muestra la Figura 1, el sistema R/3 tuvo mucho éxito y permitió a SAP crecer muy rápidamente. En 1995, SAP ya era la tercera empresa de software más importante del mundo (véase Anexo 1). Su expansión fue muy rápida en Norteamérica, donde evolucionó desde una presencia testimonial en 1992 a 710 millones de dólares en ventas en 1995. Este éxito se debió a varios factores, entre los que merecen destacarse los siguientes: •

Tecnología cliente-servidor. A medida que, al principio de los años noventa, las grandes empresas empezaron a migrar de instalaciones basadas en ordenadores centralizados a arquitectura clienteservidor, el sistema R/3 estuvo disponible para ellas desde el principio, mientras que la mayoría de competidores de SAP no disponían sistemas preparados para la nueva tecnología.

•

Modularidad, funcionalidad e integración. El sistema R/3 incluye varios módulos, desde uno económico-financiero a otro de producción, pasando por uno de logística y otro de recursos humanos, como muestra el Anexo 2. Con anterioridad a los sistemas ERP, estas funcionalidades estaban típicamente repartidas entre varios sistemas. R/3 proporciona una integración efectiva entre ellas, de manera que los distintos módulos pueden intercambiar información sin problema, centralizándola toda en una única base de datos accesible desde todos los módulos.

•

Estrategia de marketing. SAP se asoció con la mayoría de empresas de consultoría, y juntas ofrecen el sistema R/3 a los ejecutivos como una parte de la estrategia de negocio, en vez de venderlo a los responsables de sistemas de información como una pieza de software.

6


Figura 1

606-S27

Crecimiento de SAP y del sistema R/3

Instalaciones

Millones de dólares

Usuarios totales 400.000

6.000

2.000 Ventas

5.000 300.000

1.500

200.000

1.000

100.000

500

4.000

3.000

2.000 Beneficio neto

1.000

0

0 1992

1993

1994

1995

0 1989

1990

Instalaciones y usuarios de R/3

1991

1992

1993

1994

1995

Ventas y beneficios de SAP

Fuente: SAP.

Utilización de R/3: pantallas de transacciones y procesos Una vez instalado en el ordenador de un usuario, el sistema R/3 se parece mucho a una aplicación de ordenador personal; su utilización se basa en pantallas gráficas y en el empleo del ratón. Sus usuarios pueden navegar de pantalla a pantalla, y cada pantalla corresponde a un tipo de transacción. Una transacción es cualquier operación, desde comprobar el inventario de una pieza determinada a cambiar el coste estimado de fabricación de un componente o subconjunto; el Anexo 3 presenta un ejemplo de pantalla de transacción. Una implantación completa de un sistema SAP, que incluya todas las funciones estándar, incorpora cientos de posibles transacciones. Los procesos de negocio más comunes constan de varias transacciones y son multifuncionales, de manera que involucran más de un módulo del sistema. Por ejemplo, la Figura 2 esquematiza el proceso de aceptación de un pedido de un cliente y muestra los módulos SAP que intervienen en cada paso. Sin un sistema tipo ERP, este proceso podría involucrar tres sistemas de información distintos y, quizá, separados –ventas y distribución, MRP y económico-financiero. Con R/3, cada paso requiere una pantalla de transacción, pero todas ellas forman parte del mismo sistema, de manera que comparten y ponen al día la misma información. La eliminación de redundancias que eso representa, así como la efectiva coordinación en el funcionamiento de las distintas aplicaciones, es una de las ventajas más sobresalientes de los sistemas ERP.

7

606-S27

Figura 2 P r o c e s o

M ó d u l o s


Módulos SAP involucrados en un único proceso de negocio

Propuesta

Compromiso

Configuración

Comprobación de crédito

Distribución

Ventas y distribución


Planificación de la producción

S A P

Facturación

Cobro


Gestión de materiales

Económicofinanciero

Económicofinanciero

Utilización de R/3: configuración del sistema Tablas de configuración Aunque R/3 está concebido como una aplicación estándar que no precisa modificaciones significativas para cada cliente, es necesario configurarlo para adaptarlo perfectamente a los requisitos específicos de cada empresa usuaria. La configuración se basa en especificar una serie de valores en las denominadas tablas de configuración. Hay del orden de 8.000 tablas de configuración en R/3, que permiten definir cómo se desea que funcione el sistema y cómo los usuarios van a interaccionar con él; en otras palabras, permiten definir cómo serán las pantallas de transacción y cómo funcionarán. Para configurar un sistema, a menudo se construyen modelos de cómo deben funcionar los distintos procesos, para de ellos deducir los valores que deben contener las tablas. Por ejemplo, después de definir cómo se introduciría un pedido de un cliente, Vandelay decidiría si en el transcurso de ese proceso la persona responsable de aceptar el pedido podría o no modificar el precio, que el sistema colocaría automáticamente en el campo correspondiente de la pantalla de introducción de pedidos. En cualquier proyecto de implantación de R/3, esta actividad de configuración debe repetirse para cada proceso, y por ello requiere mucho tiempo y experiencia. Para hacerla correctamente se requieren personas que entiendan el impacto de cada cambio en las tablas. En el caso de Vandelay, Kramer pensaba apoyarse en varias personas de ICS que tenían este perfil y que trabajarían codo con codo con gente de Vandelay en el equipo del proyecto.

8


606-S27

Funcionalidad adicional Aunque R/3 es considerado un sistema ERP que contempla más funcionalidad que sus competidores, generalmente es capaz de satisfacer del orden del 80-95% de las necesidades específicas de una gran empresa, configurándolos adecuadamente3. La cobertura del resto puede conseguirse de cuatro maneras: •

Diseñando y desarrollando interfaces entre R/3 y los sistemas antiguos.

•

Utilizando interfaces entre R/3 y otros paquetes de software, que se utilizan como soluciones puntuales para tareas específicas.

•

Diseñando y desarrollando software nuevo que extienda la funcionalidad de R/3.

•

Modificando directamente los programas que constituyen R/3. SAP no recomienda esta alternativa, que puede suponer la renuncia por parte de SAP a cuidar del mantenimiento del sistema.

Los consultores: Deloitte & Touche Consulting Group/ICS Antecedentes de la empresa Deloitte & Touche Consulting Group (Consulting Group) es la división de consultoría de Deloitte & Touche, una de las «seis grandes» empresas de auditoría y asesoría fiscal. Resultó de la fusión de Deloitte, Haskins & Sells y Touche Ross. La consultoría ya había sido una actividad importante para esas empresas desde los años cincuenta, y representaba más del 15% de la facturación de Deloitte & Touche a mitad de los años noventa4. En 1995, Consulting Group generó unas ventas de más de 1.000 millones de dólares, con una plantilla de 8.000 profesionales en más de cien países. Deloitte & Touche Consulting Group/ICS es la subsidiaria de Consulting Group especializada en implantaciones de SAP, que ofrece además software complementario, servicios de enseñanza y formación, así como consultoría en reingeniería de procesos y gestión del cambio. ICS es uno de los mayores implantadores de SAP y una de las secciones de Consulting Group de crecimiento más rápido, con una plantilla de 1.300 profesionales, en cuatro continentes, en 1995. ICS tenía en esa época una gran experiencia y conocimientos en SAP; más del 50% de sus consultores contaba con más de dos años de experiencia en productos SAP. De hecho, había conquistado cada año, desde su creación, el «SAP Award of Excelence», que otorgaba SAP sobre la base de encuestas de satisfacción de clientes que realizaba la propia empresa. SAP había nombrado a ICS «R/3 Global Logo Partner». Según SAP5: «Lo que perseguimos con estas asociaciones es extender y mejorar el conocimiento de R/3. Con el objetivo de mantener al día a estos asociados acerca de las últimas novedades, SAP trabaja íntimamente con ellos, proporcionándoles todo tipo de información y ofreciéndoles los siguientes servicios:

3 Estimación de SAP. 4 «Professional Service Trends: Deloitte & Touche», informe de Dataquest, 25 de febrero de 1994. 5 Tomado de la página wep de SAP. http://www.sap.com, 1 de marzo de 1996.

9

606-S27


•

Un sistema R/3 para formación interna.

•

Foros, seminarios y sesiones de formación.

•

Acceso a SAP InfoLine, el sistema de información interno de SAP.

•

Soporte de segundo nivel a través de SAP Consulting, incluyendo acceso a la «hotline» de consultoría de SAP.»

Los profesionales de ICS podían ser consultores en dirección o especialistas en SAP. Estos últimos se especializaban en un área funcional o técnica de SAP y trabajaban, por ejemplo, como expertos en la función de gestión de materiales o como programadores en el lenguaje ABAP/4, el lenguaje nativo de los sistemas SAP. Los consultores en dirección, por otra parte, eran expertos en rediseño de procesos, implantación de sistemas, gestión del cambio o gestión de proyectos. Los profesionales con mayor experiencia combinaban ambos perfiles.

Cambio posibilitado por la tecnología Los consultores de ICS adoptan un conjunto común de principios cuando lideran cambios de envergadura en una empresa. Según Kramer: «Un cambio se puede producir a diferentes niveles en una organización: estratégico, de proceso, personas y tecnología. En función de las circunstancias de cada cliente, es posible adoptar uno de dos enfoques distintos. El primero consiste en “empezar desde cero”, y trata de explorar las cuatro dimensiones de cambio organizativo sin restricciones de ningún tipo. El segundo se denomina “cambio posibilitado” por la tecnología. En este último enfoque en el proceso se escoge pronto la tecnología básica y la elección tiene una fuerte influencia en las otras tres dimensiones, aunque permite realizar cambios muy significativos en la totalidad del negocio. La introducción de soluciones que abarcan toda la empresa de manera potente y flexible, como ocurre con la implantación de un sistema SAP, puede utilizarse con este enfoque, ya que los clientes persiguen simultáneamente la sustitución de sistemas y tecnología antigua y la consecución de mejoras operativas significativas. El enfoque más apropiado se elige en función de la situación de cada cliente. En el caso de Vandelay, el segundo enfoque es más apropiado, porque ellos ya decidieron la adopción de SAP. Para conducir al cliente a lo largo de todas las fases de la implantación, ICS emplea un procedimiento estructurado adaptado a la situación del cliente. La metodología pretende capitalizar en el aprendizaje colectivo de quienes participan y al mismo tiempo crear un mapa claro para la implantación de SAP.» La Figura 3 esquematiza las diferencias, según ICS, entre los dos enfoques de rediseño de procesos.

10


Figura 3

606-S27

La visión de ICS de los dos enfoques para rediseño de procesos de negocio

Desde cero

Implantar

Sí Definición del modelo de proceso futuro

Definición del modelo tecnológico futuro

No No

Elegir solución

¿Adecuada?

Analizar impacto en procesos

Sí ¿Crítico?

Modificaciones de detalle

Modificar solución

Revisar

Posibilitado por la tecnología

Definición del modelo de proceso futuro

Diseño y uso de prototipos y escenarios

Configurar SAP Implantar

Refinar el modelo de procesos

Construir nuevos procesos

Funcionalidad SAP

El proyecto Vandelay La dirección de Vandelay había proyectado que la implantación duraría dieciocho meses y requeriría cincuenta personas a tiempo completo, incluyendo consultores (tanto expertos en rediseño de procesos como especialistas en SAP) y empleados, y también la participación a tiempo parcial de empleados en cada planta. El presupuesto total para el proyecto se había fijado en 20 millones de dólares, incluyendo hardware, software, honorarios de consultoría y los salarios y gastos de los empleados que iban a participar. Dada su experiencia previa en proyectos similares, Kramer creía que tanto el plazo como el presupuesto eran muy ajustados si se tenía en cuenta el alcance de la implantación; dudaba de que todo estuviera realmente preparado y a punto para conseguir el cambio que se pretendía. El proyecto contemplaba la implantación del sistema R/3 en las ocho fábricas de Vandelay, en cuatro bases de entrada de pedidos6 y en la central en Minnesota. Las instalaciones de las fábricas eran las que requerirían más tiempo, ya que cada una de ellas necesitaba de un largo período de preparación con objeto de adaptar sus operaciones a la nueva manera de operar que suponía el sistema. Kramer estimaba que dos tercios de los empleados de Vandelay necesitarían formación para saber utilizar el sistema, en esfuerzos que podían durar desde un día para personas que iban a utilizar el sistema sólo esporádicamente, hasta dos semanas para quienes precisarían utilizar el sistema de manera intensiva en su trabajo.

6 Localizadas dos en Norteamérica, una en Europa y otra en Asia.

11

606-S27


Inicialmente estaba previsto que el equipo del proyecto se concentrara en el diseño del nuevo modelo de proceso de la empresa, dedicando del orden del 80% de su tiempo a este tema. El 20% restante se dedicaría a temas directamente relacionados con la implantación. Esto reflejaba el hecho de que el proyecto se concebía como de cambio, con objetivos claros en resultados, más que como un proyecto de instalación de software. En las últimas fases de la implantación sería preciso poner más énfasis en temas específicos de SAP: para las actividades de configuración del sistema, pruebas, e instalación definitiva, el reparto 80-20 sería justamente el contrario del inicial.

Estructura del equipo En palabras de Kramer: «Un proyecto como éste requiere una variedad de habilidades muy amplia. Creo que las más importantes son las de gestión de proyectos, conocimiento de los sistemas SAP, un buen entendimiento del negocio y del sector, y capacidad de cambio y de liderazgo. Necesitaremos un equipo mixto cliente/consultora con la combinación adecuada de habilidades en cada momento.» Para gestionar el proyecto, ICS y Vandelay habían decidido utilizar dos equipos. Miembros de la alta dirección en el comité de seguimiento del proyecto se ocuparían de los aspectos más estratégicos, mientras que el equipo propio del proyecto sería responsable de la mayor parte de las decisiones, en particular de las que definirían el funcionamiento real del sistema (véase Tabla 1). Kramer era consciente de que acertar en la estructura y composición del equipo iba a ser fundamental.

Estructura de los equipos del proyecto

Tabla 1

Nombre

Comité de seguimiento

Composición y condiciones de trabajo

Vicepresidentes de división 8 personas; reunión mensual

Equipo de proyecto

Personal «de línea»; por ejemplo, compradores, programadores de la producción, etc.

Asuntos de su incumbencia

Estrategia de negocio. Cambios en procedimientos de fabricación; secuencia de instalaciones Temas específicos de implantación; Por ejemplo, reglas para asignación de stock

20 personas a tiempo completo7

7 Incluye sólo miembros de la empresa cliente; no incluye ni consultores ni especialistas en tecnología.

12

Porcentaje de asuntos responsabilidad del equipo

5%

95%


606-S27

Por experiencia, Kramer sabía que había dos maneras básicas de seleccionar personas para incorporar al equipo del proyecto. Una consistía en simplemente preparar una descripción de los perfiles necesarios y pasarla a la alta dirección de la empresa cliente para que ellos determinaran qué personas eran las consideradas idóneas, y que la dirección contactara con ellas para incorporarlas al equipo. Alternativamente, podía exigir que hubiera al menos un representante de cada planta. Aunque eso podía disminuir la calidad del equipo, era una manera de asegurarse de que en cada lugar de implantación habría alguien dispuesto a empujar la implantación desde el primer momento.

Gestión del cambio Conseguir un buen equipo no era la única preocupación de Kramer en relación con el proyecto. Había liderado implantaciones de ERP en el pasado y sabía que uno de los retos más importantes tenía que ver con ayudar a la empresa cliente –sobre todo si era grande–, a cambiar y estandarizar sus procedimientos y prácticas de trabajo. Clasificaba estos retos en unas cuantas categorías: Centralización frente a autonomía Dado que hay que involucrar a todos los usuarios en las decisiones que les iban a afectar en su trabajo, puede ocurrir que algunos de ellos adopten una actitud a la contra, defensiva, cambiando los procedimientos implícitos en el sistema que se implante. Esta posibilidad era especialmente relevante en Vandelay, debido a su larga tradición de innovación y autonomía, como las reflexiones de Hall venían a corroborar. ¿Se debía potenciar esta experimentación o, por el contrario, era mejor adoptar un enfoque de «forzar» la adopción de soluciones específicas y cerradas? ¿Podían Kramer y sus equipos estar seguros de que sus decisiones iban a ser las más adecuadas para Vandelay como un todo? En caso afirmativo, ¿deberían centralizar y controlar los procesos de negocio resultantes y casi prohibir todo tipo de experimentación con ellos? En caso negativo, ¿cómo se justificaba un ciclo tan largo de desarrollo e implantación? Kramer estaba sesgada hacia un enfoque que se podría denominar «escuchar a muchos, pero pocos en el diseño», pero ¿podría ponerlo en práctica en este caso? Sabía que esta cuestión era particularmente importante para empresas globales como Vandelay. Precisamente porque las culturas eran diferentes en países diferentes, como sus monedas, también lo eran las prácticas de negocio usuales, incluyendo las relaciones entre clientes y proveedores. El equipo de implantación debería asegurarse de que los diseños de procesos que se adoptaran pudieran aceptarse en el contexto de las costumbres locales de cada planta o lugar de trabajo. Un tema no independiente del anterior era el de la estandarización basada en «mejores prácticas» definidas externamente. La experiencia de los consultores procedía de proyectos anteriores; sabían qué había funcionado y qué no en otras empresas, de la misma manera que las funcionalidades estándar de los sistemas SAP reflejaban la acumulación de conocimiento acerca de las necesidades de ERP en una serie de entornos experimentados anteriormente. Todo este conjunto de sistemas, operaciones y procesos podrían usarse en Vandelay, pero Kramer se preguntaba cómo podían incorporarse a las prácticas de la empresa, ¿como un punto de partida o como la solución definitiva? Kramer veía con claridad que las plantas tendrían que renunciar a parte de su autonomía en algunas áreas. Por ejemplo, el sistema R/3 requiere que cada pieza tenga un código único, y de hecho eso era consistente con los deseos de los directivos de Vandelay, que querían información consolidada. Pero cada planta había desarrollado su propio sistema de codificación a lo largo de los años. Sustituir todos estos sistemas por uno único iba a suponer un esfuerzo importante, ya que afectaría a prácticamente todo el mundo, desde personal de almacén a los delineantes que especifican las piezas en los planos a quienes utilizan las máquinas para estampar el número de pieza en cada pieza. Además, las personas involucradas deberían olvidar los códigos antiguos, con los que se manejaban ya sin pensar después de 13

606-S27


haberlos utilizado durante años. Kramer sabía que la estandarización de códigos formaba parte del proyecto, que las plantas se iban a oponer, y que finalmente no habría más solución que implantarla. Agentes de cambio e inercia organizativa La experiencia de Kramer le decía también que un proyecto de envergadura marchaba bien si se podía disponer pronto de una masa crítica de líderes –personas entusiastas, convencidas del cambio y respetadas en la empresa. Le decía también, sin embargo, que aun contando con un buen grupo de agentes de cambio de este estilo, la mayoría de personas sólo aceptaba un sistema nuevo cuando lo veían como algo inevitable. Kramer pensaba que esto era una paradoja; la empresa estaba dispuesta a dedicar una cantidad sustancial de recursos al proyecto y lo anunciaba como un hecho, pero la mayoría de empleados mostraban escepticismo durante largo tiempo. ¿Cómo podía enfrentarse a este problema con la ayuda de los agentes de cambio? Software A pesar de la amplitud de la funcionalidad de R/3, habría situaciones en las que el sistema no encajaría completamente con el diseño de procesos más adecuado para Vandelay. Kramer contemplaba tres alternativas básicas para afrontar este tipo de situaciones: 1) Cambiar el proceso de negocio para hacerlo compatible con el software. 2) Construir una interfaz con otro paquete o software hecho a medida. 3) Extender las capacidades de R/3 para incorporar la funcionalidad necesaria. ¿Qué criterios debería seguir para elegir entre estas alternativas? Kramer tendría que responder pronto a la pregunta de George Hall respecto a la formación en su planta, pero no sabía qué decirle. Si no permitía a la gente de Hall experimentar con el sistema, ¿podría su entusiasmo inicial convertirse en hostilidad hacia el proyecto?

14


606-S27

Anexo 1 Las principales empresas de software. Ventas de las empresas de software más importantes, 1993-1995 (en millones de dólares)

Empresa Microsoft IBM SAP AG IBM/Lotus Computer Associates∗ Autodesk Novell Adobe Systems Cadence Design Siemens Nixdorf Todas las demás Ventas mundiales

1993

1994

1.246 1.647 414 281 431 351 603 324 336 350 24.238 30.273

1.688 1.607 843 401 425 392 477 387 391 365 27.895 34.930

Participación 1995 1995 (en porcentaje) 2.484 1.711 1.322 540 478 455 443 438 435 361 31.240 39.989

6,2 4,3 3,3 1,4 1,2 1,1 1,1 1,1 1,1 0,9 78,1

Participación 1996 (en porcentaje) 4,8 4,6 2,4 1,1 1,2 1,1 1,4 1,1 1,1 1,0 79,9

Crecimiento 1994-1995 (en porcentaje) 47,1 6,5 56,9 34,6 12,5 16,1 -7,1 13,3 11,2 -1,1 12,0 14,5

∗ Incluye ventas de Legend Corp. para todo el año.

Fuente: International Data Corporation, 1996.

15

606-S27

Anexo 2


Funciones incluidas en el sistema R/3 de SAP

Figura © SAP.

16


Anexo 3

606-S27

Ejemplo de pantalla SAP

© 1996 SAP America, Inc.

17

Caso 4 Vandelay Industry

Recommend Documents