CASO EMPRESA BEBIDAS OLAYA.

Bebidas Olaya es una compañía nacional con casi 50 años de operación. Inició
sus operaciones en una pequeña bodega de la ciudad bajo la dirección del
fallecido patriarca Fidel Olaya fabricando cerveza como respuesta a la restricción
del Gobierno Nacional al consumo de la popular “chicha”.
La empresa rápidamente fue creciendo logrando en poco tiempo el liderazgo
regional y poco a poco hasta convertirse en uno de los principales competidores
del sector en el mercado nacional.
A medida que fue creciendo fue diversificando su portafolio incluyendo gaseosas,
refrescos de frutas y recientemente bebidas energéticas. Su principal producto, la
cerveza, se fabrica en la planta central, las gaseosas y los jugos en la planta 2, y
las bebidas energéticas y otros jugos importados son representados para
aprovechar la red de distribución que se ha logrado desarrollar en los años de
operación. El centro de distribución principal se encuentra en la planta central.
La distribución nacional se hace a través de agencias propias en las grandes
capitales del país como Bogotá, Cali, Medellín, Barranquilla y Bucaramanga.
Desde hace aproximadamente 10 años se lograron realizar ventas en el exterior lo
cual ha venido creciendo en forma importante sobre todo en los países vecinos,
Venezuela, Ecuador y Panamá. El volumen de las exportaciones asciende al 35%
de la producción total de la planta central.
La historia de los sistemas de información de la empresa ha recorrido desde los
registros manuales en los cuadernos de contabilidad, pasando por los sistemas
IBM36, Burroughs hasta los actuales servidores HP. Durante esta historia se han
experimentado todas las tendencias de los sistemas de información, desde las
aplicaciones escritas por programadores internos hasta aplicaciones compradas a
terceros que soportan las nuevas filosofías de operación. Cada departamento es
soportado por una aplicación y la consolidación de la información se hace a través
de interfaces para al final de cada período obtener los estados de resultados,
balances, etc.
Tradicionalmente el servicio prestado por el departamento de sistemas ha sido
muy bueno, pues tienen el control sobre las aplicaciones lo cual les permite
generar los reportes que los usuarios solicitan muy rápidamente. Además la
estabilidad de la empresa ha permitido que dichos funcionarios conozcan muy
bien la operación de la empresa y entiendan rápidamente las necesidades de sus
usuarios.
Dado el crecimiento exitoso de la organización y a la amenaza del medio que cada
vez esta más competitivo, los socios y directivos de la organización se ven en la
necesidad de obtener cada vez mas información que les permita trazar un plan
estratégico y estar al tanto de los cambios en el entorno económico de su negocio.
Además sus ejecutivos cada vez presionaban mas porque la compañía se
enfocara hacia la operación por procesos, el análisis de la cadena de valor, el
gerenciamiento de la cadena de abastecimiento como motor para lograr ventajas
competitivas, lo cual argumenta la adquisición de un sistema integrado de
información que permita obtener información en tiempo real de las operaciones de
la compañía, los inventarios, el volumen de ventas, etc.

Mas aún, presionados por el boom del bug del año 2000 los directivos de la
compañía organizaron desde finales de 1998 un grupo gerencial constituido por el
gerente de sistemas, el gerente de operaciones y el gerente de ventas para la
evaluación de diferentes sistemas integrados de información preferiblemente bajo
la filosofía ERP.
1 El grupo gerencial recibió la visita de los representantes de las casas de
software más importantes del mundo las cuales hicieron sus presentaciones con
gran derroche de tecnología y colorido, además de referencias de instalaciones
exitosas en otras empresas del exterior.
El grupo gerencial se inclinó por la casa de software que consideró con mas
presencia a escala mundial y la cual según sus informaciones era la que tenía el
mejor y más completo equipo de consultoría para parametrizar e implementar el
nuevo sistema de información. La decisión se inclinó por el SCIS (Supply Chain
Integrator System). Este paquete era el más costoso pero la decisión se tomó
sobre la base de los estudios presentados por el proveedor en cuanto al retorno a
la inversión realizada y a los casos de implementación exitosa en otros clientes del
exterior. El proyecto debería iniciarse en Enero de 2008 lo cual fue aprobado por
el presidente y la junta directiva de la compañía.

ETAPAS DE LA IMPLEMENTACION DEL ERP

Para la implementación del ERP, el presidente de la compañía nombró al Dr.Villa
actual gerente de operaciones como director del proyecto.
El Dr. Villa fijó el cumplimiento de las siguientes actividades como las reglas de
oro para realizar una exitosa implementación:
 Selección del proveedor de servicios de consultoría para la implementación
del software.
 Selección del equipo interno implementador del SOFTWARE
 Capacitación de dicho equipo en el manejo de la herramienta.
 Elaboración del blueprint del sistema.
 Adquisición e instalación del nuevo equipo de hardware
 Instalación y Configuración del ERP
 Capacitación a usuarios finales
 Desarrollo del Piloto
 Salida en vivo
Estas etapas estaban previstas para ser cumplidas en 9 meses, la salida en vivo
se programo para el mes de Enero del 2008, incluyendo solo los módulos de
finanzas, inventarios, distribución y ventas. Los módulos restantes de producción y
mantenimiento se instalarían posteriormente en una segunda fase.

RESUMEN DE LA EJECUCIÓN DE LAS ETAPAS.

1. Selección del proveedor de servicios de consultoría para la
implementación del SOFTWARE
Se contrataron los servicios de consultoría del mismo proveedor del paquete pues
se consideró que deberían ser los funcionarios que más sabían de su propio
producto.
Dicho equipo estaba liderado por un gerente de proyecto y consultor de
inventarios (Fritz Kahn, alemán), un consultor para el módulo de Finanzas (Yuka
Thaí), dos consultores para el módulo comercial (Esteban Lamprea y Giovanni
Marulanda), un consultor para el módulo de planeación (Álvaro Segrera) y un
consultor para el módulo de inventarios (Mohamed LaRahja).
2. Selección del equipo interno implementador del SOFTWARE
Según el criterio del gerente del proyecto, el personal actual de la compañía
estaba muy atrasado en cuanto a los conceptos modernos de cadena de
abastecimiento y manejo de sistemas de información modernos. Sólo unos
cuantos funcionarios recientemente enganchados tenían el perfil para un proyecto
como este por lo tanto encargó a recursos humanos el reclutamiento de
profesionales con un perfil más moderno para encarar este proyecto.
Consideró que el personal actual podría servir para las funciones de
multiplicadores de conocimiento cuando el sistema ya estuviese parametrizado y
colaborarían con las pruebas y la depuración y cargues de datos.
Al no poder lograr conseguir la totalidad de los funcionarios que necesitaba se
decidió a utilizar el personal interno que más se acercara a su ideal, sin embargo
los jefes de área se las arreglaron para no entregar al proyecto sus estrellas sino
de los que podían prescindir.
Al tener el equipo completo se definieron los roles de líder funcional y usuario
clave y el equipo se dividió en estos dos roles.
3. Capacitación al equipo implementador interno en el manejo de la
herramienta
Después de conformado el equipo, el paso siguiente fue capacitar a los
responsables de cada modulo en el uso de la herramienta.
Los consultores de SCIS iniciaron sus sesiones de capacitación con sus
respectivos equipos, sin embargo se detectó que algunos de estos consultores no
conocían profundamente la funcionalidad del sistema. Esto causó malestar en el
equipo y se solicitó refuerzo por parte del proveedor.
Este consiguió material adicional pero en inglés y algunos miembros del equipo
debieron desplazarse a otras ciudades a recibir capacitación particular.
Esta etapa del proyecto concluyó por parte de la gerencia del proyecto, sin
embargo los miembros del equipo se quejaron por la poca profundidad de los
cursos ante lo cual el proveedor respondió que eso era normal y que el refuerzo
vendría en la etapa del piloto de prueba.
4. Elaboración del blueprint del sistema
Después de concluir la capacitación del equipo se inició la etapa de la elaboración
del blueprint del sistema a implementar. Aquí se detallarían las especificaciones
con las cuales se parametrizaria el sistema. Los equipos hicieron esta tarea
basados en sus experiencias personales en otras compañías pues muchos eran
nuevos y llegaron directamente al proyecto.
Esta situación no se cuestionó pues uno de los objetivos del proyecto era
implementar una nueva metodología de trabajo empujada por la nueva
herramienta. Algunos consultores aportaron muchos de sus conocimientos en las
mejores prácticas pero otros, los más jóvenes, se limitaron a transcribir lo que los
miembros del equipo les decían.
5. Adquirir e instalar el nuevo equipo de hardware
Finalizando la etapa del blueprint ya se tenían datos acerca del número de
usuarios que utilizarían el sistema y los volúmenes de datos que se generarían día
a día. Así entonces llegó la hora de comprar la máquina sobre la cual correría el
sistema. Para esta decisión se pasó a los proveedores de hardware las
especificaciones técnicas mínimas que debería tener la máquina y estos deberían
devolver la propuesta económica.
Muy rápidamente llegaron las cotizaciones con las configuraciones necesarias de
las máquinas para soportar la operación. Los precios eran supremamente
elevados y las actualizaciones planteadas en las cotizaciones por el crecimiento
de la base de datos asustaron al gerente del proyecto. Este decidió escoger la
cotización de más bajo costo y minimizar en sus reportes el impacto de los costos
de crecimiento futuro del equipo.
6. Instalación y Configuración del ERP
El propósito de esta etapa era la configuración del sistema y que la nueva
herramienta funcionara tal cual operaban los procesos de la compañía.
Mucho se dijo, se planteaba cambiar muchas operaciones actuales por las
mejores practicas, practicas ideales, es así como Jorge Tenorio “Líder funcional
del modulo de planeación” comenzaba una y otra vez a diseñar los procesos de
planeación de la demanda; y debatía que primero iba la simulación del SOP (Sales
& Operation Planning) porque así lo plantea la APICS, que el pronostico debería
ser multivariado y debería considerar todas la variaciones de la demanda, que el
ERP debía soportar estas operaciones, pues por eso costaba lo que costaba, y
eran discusiones de hasta 4 meses en el mismo tema y todos los días. El
problema era que los consultores no eran muy experimentados en el tema y no
tenían argumentos para debatir las propuestas de Tenorio, por lo tanto su
estrategia se encaminó a evadir los planteamientos de Tenorio.
Llego a tal punto su insistencia en reuniones sin conclusión que en ocasiones
llevaba donnas y refrescos para quien lo quisiera escuchar, era tal el desespero de
sus auxiliares que llegaban a la hora de la reunión se comían la donna y se iban
sin que Jorge aun hubiera expuesto.
Así sucedió con los otros módulos, se diseñaban las practicas ideales y que al
final solo eran ideales, el sistema no soportaba dicho requerimiento pero los
consultores usaron la estrategia de evasión con la complicidad de algunos de los
miembros del equipo que necesitaban desocuparse rápido pues tenían
responsabilidades con el día a día de su cargo.
La dinámica de las reuniones empezó a inquietar al Dr.Villa pues no se lograba
consenso y el tiempo se estaba agotando, además para Villa muchos de los
procesos actuales eran los correctos y no permitía el debate. Cómo el sistema no
los soportaba se utilizaron nuevos consultores especializados en la programación
de aplicaciones paralelas al sistema. Con los reportes que se diseñaron y las
modificaciones a los programas estándar del sistema se lograron llegar a acuerdos
para la parametrización del sistema, sin embargo el tiempo de elaboración de
estas aplicaciones no era el óptimo pues para ahorrar costos se contrató a
muchos programadores de bajo costo en lugar de a pocos con experiencia
comprobada.
De esta manera transcurrieron 6 meses, al final de este tiempo la realidad era que
aún no se tenía piloto completamente configurado y no se había capacitado a
nadie, ya quedaban solo tres meses para la salida en vivo.
Muchas de las personas del equipo trabajan tiempo parcial en el proyecto aunque
se habían nombrado de tiempo completo y esto se debía a que eran lo que
conocían todos los detalles de su puesto funcional en la compañía. Por este
motivo y los antes nombrados se corrigió el cronograma de salida en vivo, el Dr
Villa replanteo un nuevo cronograma donde planteaba la salida en vivo en un mes
más.
Algunas de las razones para justificar este retraso ante la presidencia de la
compañía son:
 Mejorar las debilidades del plan de capacitación.
 Replantear la implementación de algunos procesos.
 Muchas de las personas claves que formaban parte del equipo
implementador tenían que compartir su tiempo con el trabajo del día a día.
 La metodología de configuración del prepiloto en esta implementación fue
muy particular, consistía básicamente en lo siguiente: el líder funcional del
modulo daba las directrices y políticas de cada proceso, el usuario clave
 documentaba dichas políticas, dicho proceso y lo entregaba al consultor
para que este lo configurara en el sistema.
Una vez se tenia lista la configuración, el usuario clave hacía las pruebas creando
ambientes específicos para ese proceso, posteriormente los resultados los
analizaba el líder funcional del modulo para dar su aprobación final. Si no se
obtenían los resultados requeridos en dicha prueba, se devolvía al consultor para
realizar ajustes en parametrización.
Esta etapa finalizó el 30 de Julio 2007. (Piloto implementado y listo para probar)
7. Capacitación a usuarios finales
En esta etapa del proyecto se había previsto capacitar el 100% de las personas
que serían los usuarios de ERP. Por lo apretado del cronograma se decido al final
que la mejor estrategia sin sacrificar la salida en vivo para el 20 de noviembre era
capacitar a personas claves que replicaran la información obtenida. Esto se haría
por áreas y por ciudades, es decir se traía una persona de la ciudad de Medellín
que trabajara en la bodega, otra del área de contabilidad, etc.
Y luego estaba persona retornaba y replicaba la información a los otros usurarios
en su ciudad de origen.
En esta capacitación sucedieron eventos que hacían pensar al grupo de usuarios
que para la salida en vivo se requería mas tiempo. Algunos miembros del equipo
del proyecto pensaban que necesariamente se necesitaban 6 meses mas debido a
que los resultados que habían obtenido en el piloto no eran muy consecuentes con
lo esperado, sin embargo debido al carácter fuerte del Dr Villa estas
manifestaciones no se hicieron con mucha fuerza.
Cabe resaltar casos como el siguiente, que ocurrieron en los últimos días de la
fase de capacitación a usuarios finales. Se trata de la conversación entre la
persona que lideraba el modulo de inventarios con sus usuarios finales:

Vilma - Y Así hemos terminado la capacitación en el modulo de inventarios, como

ven no está complejo y se trabajará de la misma forma como lo están haciendo
ahora ¨
Rodrigo - Disculpe Vilma, pero allí veo que faltan cosas.
Vilma - Cuales por ejemplo?
Rodrigo - Cuando vamos a ver la capacitación en el sistema del manejo de las
ubicaciones, recuerda que nuestro almacenamiento se hace con ubicaciones,
nosotros tenemos Racks.
Vilma - racks? y eso qué?, Cómo lo hacían antes?
Rodrigo - El sistema viejo tenía un WM.
Fernando - Vilma, y el sistema no lo he visto manejar las fechas de los materiales.
Cómo es la rotación? Cómo la hace? Cómo quedo? FIFO, FPC, cómo?.
Luego de estos comentarios Vilma, llama a Jorge y le dice:
Jorge, como te parece que en capacitación me preguntaron por WM, por fechas, y
yo no tengo ni idea de que me estaban hablando.
Jorge respondiendo dice, mija usted no hizo nada de eso? y como pensaba que
operaban esas bodegas? si vé, por eso siempre pedí a Rodrigo, es el que mas
conoce de bodegas y como operan, ahora que? Qué piensa hacer?. Lo mejor es
que le des la cara al Dr.Villa y le comente de eso, usted vera que le dice, pero eso
tiene que ir, eso debe quedar para la salida en vivo, ese es un proceso critico.
Hágale solo tiene hasta el 31 de diciembre y ya es 10.
Luego de haberle comentado al Dr.Villa éste llamó a reunión al gerente por parte
de la consultoría y le comento del problema a lo cual, este respondió. Va a estar
como dificil, ya que en WM, casi no hay consultores de ERP, pero bueno si se
necesita, yo lo configuro, tengo algo de conocimiento, además ese modulo es
chimbo. Alcanzamos.
El Dr.Villa respondió: claro que se necesita, tenemos centros de distribución con
mas de 10.000 ubicaciones en 15.000 metros cuadrados, estantes de 10 niveles,
esto sin el WM no lo opera nadie, sin WM, los operarios de bodega no sabrían
donde están ubicados los materiales, súmele a esto que nosotros en nuestras
bodegas de estantería utilizamos almacenamiento caótico.
Al final el WM se parametrizó con la ayuda de Rodrigo, se realizaron las pruebas
no integradas de los procesos mas críticos, esto tardo 8 días.
8. Desarrollo del Piloto de Prueba
El principal objetivo de este prototipo principalmente era hacer escenarios para
probar la integración del sistema de información.
Cada líder de modulo desarrollaba y probaba de manera independiente su
proceso. El último paso para concluir y aprobar dicha práctica y la configuración
del sistema era la prueba de integración, es decir la ejecución de todo un proceso
a través de los diferentes módulos y análisis de resultados obtenidos al final de la
cadena. Este análisis se hacía conjuntamente entre todos los líderes que
intervenían en el proceso, por ejemplo para vender un producto, se requería:
 Planear la demanda.
 Planear la solicitud de pedido a la planta (no se tenía el modulo de
producción).
 Confirmar el pedido a planta.
 Recibir el pedido a planta.
 Almacenar el producto terminado
 Crear el pedido de ventas del producto terminado.
 Despachar el producto terminado
 Facturar
 Liquidar la cartera y cobrar al cliente
 Analizar el resultado obtenido por la venta.
Para ello se organizo un cronograma, donde se presentaban las fechas de cada
una de las pruebas y las personas que debían estar para aprobar el proceso, o
modificarlo en el caso de ser necesario.
En esta etapa se evidencio la falta de integración al momento de la configuración
del sistema. Habían pruebas que tardaban hasta tres días mas de lo previsto,
dado esto fue necesario aplazar 20 días mas el resto de actividades.
Al final se obtuvo un piloto, probado de manera integral y aprobado por los
responsables y los líderes funcionales.
Nota: Cabe resaltar que en estas pruebas no participaron los funcionarios que
trabajaban en el día a día, esto sucedió básicamente para el módulo de
inventarios, para los otros módulos un día especifico se invitaron personas del
área funcional y se les mostró como operaba el nuevo sistema. En el modulo de
inventarios, aunque se tuvo la intención no se pudo debido al costo.
9. Salida en vivo.
El sistema arranco el primero de enero de 2008. Se implementaron los módulos de
Finanzas, Inventarios, Ventas y Distribución:
Para la salida en vivo en oficina central se concentraron todos los consultores y
responsables de cada modulo. En las diferentes plantas del país se concentraron
los líderes funcionales de cada modulo.
Las operaciones arrancaron con fallas a nivel país, las fallas mas graves que se
presentaron son:
 No se pudo facturar nada
 EL sistema de WM, quedo mal cargado, la confiabilidad en inventarios bajo
a 45 %.
 No se podían ingresar los materiales despachados por los proveedores, por
lo cual, tampoco se podían liquidar las cuentas por pagar.
 Los pedidos tomados a los clientes no se podías grabar en el sistema de
manera colectiva, era necesario cargar los pedidos manualmente.
 La información financiera, se cargaba de manera errada.
De esta manera transcurrieron 15 días, con soluciones momentáneas y planes de
contingencia, pero ninguna solución definitiva.

Análisis del Caso

1. ¿Cómo esta organizado el proceso de operación de Bebidas Olaya?
2. ¿Cómo han evolucionado los sistemas de información en Bebidas Olaya?
3. ¿Cuál era el objetivo del proyecto?
4. ¿Cuál es el problema de Bebidas Olaya?
5. ¿Cuáles fueron las causas de fracaso del proyecto?
6. ¿Qué módulos se implementaron finalmente?