Author: Andres Lopez Astudillo
HAY VIDA DESPUES DE UN ERP?
Eran las 5:30 a.m. del 30 de Enero del a帽o 2008, pleno cierre del mes, ya estaba amaneciendo y la actividad en el centro de distribuci贸n era incesante. Se ve铆an caras de angustia y cansancio, los insultos y los reclamos se o铆an por todos los rincones, las tareas eran mas largas que lo normal y el stress era el rey del lugar.
El coordinador Hugo Correa estaba muy cansado y se sent贸 en un rinc贸n a reflexionar: -“Nunca cre铆 que esto era tan berraco… c贸mo es posible que antes聽que existiera este sistema de informaci贸n,聽yo pod铆a alistar 500 Toneladas en mi turno y hasta alcanzaba a charlarme las peladas de la oficina y ahora siguiendo derecho en dos turnos apenas est茅 completando 50 Toneladas y trabajando full…!聽 Noo, este trotecito me va a matar y todav铆a mi jefe me dice que la culpa es m铆a y de mi gente y que si no me pongo las pilas nos van a echar a todos… No, pues que vaina… si esto no cambia r谩pido mando todo al carajo… que se聽larguen su ERP por donde vinieron; …claro!!!, los consultores y los funcionales vinieron, vieron el desorden, intentaron arreglarlo, propusieron soluciones y se largaron… que tal la capacitaci贸n que me dio ese tal Mohamed? Todo lo que esos z谩nganos hicieron en 9 meses, intent贸 explic谩rmelo en una tarde… y las soluciones que proponen? Nooo, el problema es que las tales soluciones que propusieron se debieron haber probado hace como dos meses y no despu茅s de la salida en vivo!!!!!!!”
DIEZ D脥AS ANTES…聽
Enero 20 de 2008,聽 3:45 PM, reuni贸n extraordinaria en sala de juntas, oficina central,聽 asistentes:
Dr. Facundo Villa – Gerente de Operaciones y Director del Proyecto F茅nix.
Dr. Dieter Brand – Presidente.
Dr. Jerem铆as Otoya – Presidente de la Junta Directiva.
Dr. Federico Otoya – Miembro de la Junta Directiva.
Inicialmente la palabra la tom贸 Federico:
篓C贸mo diablos me explican ustedes que hayamos invertido mas de dos millones de d贸lares en un sistema que no permite vender?聽聽 A los socios no nos interesa tener el sistema mas avanzado del mundo, nos interesa vender lo que hacemos, exijo una explicaci贸n 篓
Ante lo cual Facundo respondi贸:
“Como ustedes saben caballeros, estamos en la etapa de estabilizaci贸n del software y tenemos estimado para la pr贸xima semana comenzar actividades normales y alcanzar la meta fijada de para el cierre de ventas. En este momento les pido que conservemos la calma y tengamos paciencia que los resultados se van a dar…”
El Presidente Brand intervino:
“Despu茅s de lo que he visto, no conf铆o mucho en que estos problemas sean resueltos en una semana. T煤 y tu oneroso equipo de ineptos me responden por la cifra de cierre, y la vaina es simple, si les toca facturar a mano pues que as铆 sea, en vez de cargar tanto port谩til y tanta pendejada deje a cada uno su maquina de escribir y papel carb贸n para que facturen!! Exija que los consultores arreglen eso.
Ante lo cual Jerem铆as objet贸:
“La cifra de cierre de ventas se tiene que cumplir se帽or presidente Brand, si esto no se d谩, est谩 en juego su puesto, y adem谩s nos debe responder por los perjuicios del lucro cesante y oportunidades perdidas, si no cumple nos reunimos de nuevo una semana despu茅s del cierre. Hasta luego”
El Presidente acorralado llev贸 aparte a Facundo Villa y solo se le ocurri贸 decir:
” 隆Ya escuch贸 Dr. Villa, ahora que otra estupidez se le va a ocurrir!聽 voy a estar al tanto de todas las decisiones que tome, me va a reportar cada hora las acciones que ha tomado y los resultados que vaya obteniendo para que la ineficiencia que mont贸 permita alcanzar la cifra de cierre.”
Con este ultim谩tum culmin贸 la reuni贸n dejando en el aire una atm贸sfera cargada de presi贸n, temores y resentimientos.
El informe que hab铆a recibido Facundo Villa del centro de distribuci贸n era que el sistema no daba resultados por que el personal encargado de operar el sistema no sabia como hacerlo, estaban cometiendo muchos errores que afectaban el desempe帽o del sistema. Por lo tanto se dirigi贸 a la oficina del director de log铆stica Miguel Angel Lopera.
Lopera lo recibi贸: -“Buenas tardes Dr. Villa, cu茅nteme en que puedo ayudarlo?”
-Buenas tardes Miguel Angel, evaluando la situaci贸n actual de operaci贸n del nuevo sistema se concluye que en log铆stica de la planta no hay quien haga funcionar el sistema, en las bodegas tenemos un poco de buenos para nada, es tu responsabilidad que de los centros de distribuci贸n y agencias puedan despachar los pedidos. Vengo de una reuni贸n en presidencia y la situaci贸n es cr铆tica, todos estamos muy molestos. Necesitamos que te integres definitivamente al proyecto, desde aqu铆 en oficina central tu no haces nada para que la gente a tu cargo opere correctamente el sistema, vete con tu equipo de planeadores de log铆stica para la planta y arregla desde all铆 el problema con la gente.
-O.K. Cuente conmigo Dr. Villa, voy a arreglar mis cosas y ma帽ana mismo me traslado para la planta. Respondi贸 Miguel Angel.
Seguidamente, Miguel Angel se comunic贸 telef贸nicamente con el director de la planta Boris Ortiz.
-Entonces qu茅 viejo Boris, qu茅 mas?. Te cuento que ahora si me llevo el patas…, se me apareci贸 en la oficina el viejo Villa y me enchicharron贸 con que tengo que arreglar lo del proyecto, que lo haga funcionar antes del cierre y para eso me orden贸 traslado a la planta ya mismo con todo mi equipo. Qu茅 tal, despu茅s de que no me tuvo en cuenta en las etapas previas del proyecto ahora si me tira al agua…
-Viejito, ay煤dame, supuestamente el problema es la gente, parece que no quieren operar debidamente el sistema…
-Yo no creo que ese sea el problema viejo Mike… respondi贸 Boris.
-Bueno viejo Boris, de todas formas necesito que me ubiques a los coordinadores mas pilosos, y que no les de miedo entrar en combate. Yo creo que con tres podemos arreglar esta vaina. Ser谩 que para ma帽ana que llegue me los ten茅s ubicados?
-Claro mijo, ma帽ana que llegue se los tengo. Cuente con eso. Chao viejo Mike.
“Esta gente si es muy miope, pens贸 Boris. Que yo recuerde los tales consultores y lideres funcionales vinieron a aparecer en planta por el mes de Noviembre y la salida en vivo era el primero de Enero… y con nosotros no contaron dizque porque est谩bamos llenos de vicios y paradigmas a destruir. En fin, voy a ayudarle al viejo Mike a conseguir unos coordinadores pilosos”.
“Para estas vainas pueden servir Hugo Correa, Miller Moreno y Otoniel Orozco. Esos pelaos son j贸venes pero son buenos profesionales, necesitan surgir y los operarios los tienen en buena estima. Me la juego con estos tres.”
Al otro d铆a 21 de Enero lleg贸 Miguel Angel a la planta a las 8:00 a.m. y se dirigi贸 inmediatamente a la oficina de Boris para iniciar la labor. Despu茅s del tinto de rigor, Boris mand贸 a llamar a los tres ingenieros. Estos se presentaron inmediatamente y Boris les dijo: Bueno muchachos a lo que vinimos, les presento a Miguel Angel su nuevo jefe, y bueno no se diga mas, ahora si vamos a arreglar esto.
Los tres ingenieros y Miguel Angel se dirigieron a las oficinas del centro de distribuci贸n donde se encontraban los consultores y los lideres funcionales.
Al llegar, Miguel Angel los reuni贸 y les dijo: -Se帽ores como vamos, vamos muy mal… tenemos que corregir sobre la marcha lo que estamos haciendo. He pensado en armar tres equipos a cargo de estos coordinadores para que dirijan a los operarios a su cargo y nos aseguren el correcto manejo del sistema pues seg煤n ustedes ah铆 radica la falla…
El l铆der funcional Jorge Tenorio intervino: -Miguel, estos tres se帽ores necesitan una capacitaci贸n intensiva durante lo que resta del d铆a de hoy para que ma帽ana desde el primer turno arranquen con su tarea. Qui茅n los va a capacitar?
Las miradas entre los otros lideres funcionales y los consultores empezaron a vagar por la sala y a tratar de evadir la nueva tarea, sin embargo una voz se escuch贸 que dec铆a:- pues el indicado es Mohamed que es el que mas sabe. Adem谩s con lo que cobra…
La propuesta fue acogida un谩nimemente y se acord贸 la iniciaci贸n para las 10 de la ma帽ana.
Miguel Angel se reuni贸 inmediatamente con el l铆der funcional Jorge Tenorio y le pregunt贸: -mijo, como as铆 que estos coordinadores necesitan capacitaci贸n? Seg煤n lo que escuch茅 en la reuni贸n anterior a la salida en vivo, ustedes no se gastaron 2 meses capacitando la gente?
Jorge respondi贸: -lo que pasa Miguel Angel es que para ahorrar costos llevamos a cabo el esquema del multiplicador, recuerdas que elegimos a Botero? Pues lo capacitamos los dos meses y su responsabilidad era capacitar a los otros, pero ese man nos sali贸 chimbo… le ofrecieron tres pesos mas en otra empresa y se larg贸!! Alcanz贸 a capacitar a unos pocos pero los jefes le dec铆an que solo prestaban el personal por dos horas diarias porque el d铆a a d铆a se iba a atrasar y todas esas vainas… y el hombre pues capacit贸 lo que pudo y se fue…y ahora a los operarios que capacit贸 les dio por decir que como no los dejaron practicar se les olvid贸 todo…
A las 10 en punto se reunieron en la sala de capacitaci贸n y los tres ingenieros se colocaron enfrente del computador. Lleg贸 Mohamed medio afanado y los salud贸: Morning… Sorry mi espanol es poco… esperou que su ingles sea buena… ok let麓s start! If you wanna make a picking then …
A eso de las cuatro de la tarde, Mohamed termin贸 su charla y se despidi贸 diciendo: OK guys, pueren practicar esta noche lo visto y ma帽ana a trabajar… C麓mon practice and run!! Bye.
-Viejo Hugo, c贸mo la ve? Se imaginaba esta vaina como era?
-Pues hermano, esto es mas complicado que la ir al infierno… Con raz贸n esto est谩 hecho una desorden. Vos te imagin谩s a Gumercindo hablando de picking list 贸 de que la estiba tiene que ponerla donde el sistema le diga y no donde le quede mas f谩cil?
-Ja, ja, ja! Y ahora? Ser谩 que salimos de esta?
-Pues hermano, met谩mole l贸gica a esta vaina, practiquemos esta noche los casos que tenemos frecuentes y hag谩mosle..
-Listo!
A eso de las 9 p.m. lleg贸 Jorge Tenorio a la sala de capacitaci贸n y les dijo a los coordinadores:
Listo no hay de otra, uno de ustedes arranca trasnocho y otro va de 6 a 2 p.m. Ma帽ana a las 3 p.m. nos reunimos para evaluar como va todo y volvemos a arrancar con la misma rutina hasta el cierre del mes pues de lo contrario no cumplimos. Ustedes ver谩n como se reparten, chao.
El 22 de Enero, se lleva a cabo la reuni贸n a las 3:00 p.m.
Comienza el director de Log铆stica: -Acabo de pasar por la porter铆a, y que veo?, Los mismos dos kil贸metros de carros que vi ayer cuando llegu茅, que es lo que pasa? Esto est谩 mas cr铆tico de lo que pens茅.聽
Contesta Jorge: -La situaci贸n es super cr铆tica, hay carros para descargar, para cargar nacional y exportaciones, algunos llevan lo que va corrido del mes all铆, nos van a cobrar stand by.
Por otro lado jefe, ya se entren贸 a los tres coordinadores para que nos ayuden, ya saben manejar el ERP, el mismo Mohamed los entren贸.
-Ok, muchachos ya tienen su usuario en ERP, ya saben entrar, necesito que me ayuden pues como ven estamos llevados y mis esperanzas las tengo en ustedes. Les comento que la planta no va a producir la pr贸xima semana de lunes a jueves para darnos un respiro, nos toca despachar como sea, y organizar el almac茅n. Tenemos que aprovechar este papayazo se帽ores!
Ahora si Jaime, (Jefe del centro de distribuci贸n) como est谩n los cosas en piso?
-Jefe tenemos lo siguiente:
- No hemos podido imprimir el picking.
- Hubo errores astron贸micos en el cargue de saldos.
- Hemos ingresado la mercanc铆a a ojo para no estallar el cendist y dejar todo en el piso
- El personal en piso, est谩 temeroso y como les debemos vacaciones se quieren ir.
- El inventario esta hecho un caos, el sistema dice una cosa y f铆sicamente por ubicaci贸n hay otra.
- Nos llegaron todas las devoluciones de la temporada de diciembre y no sabemos que hacer con eso, estamos reventados, no hay espacio para caminar en el cendist.
- Los transportadores est谩n que no se les puede ni hablar.
- Todo el que viene al Cendist de casa matriz, no hace mas que llamarnos ineptos, y vienen solo a cagarla mas y se van
- El gerente de plata dice que apaguen el nuevo sistema y prendan el viejo
- El personal de piso est谩 cansado, algunos llevas trabajando derecho mas de 50 horas.
- No funciona el modulo de facturaci贸n.
- El sistema pide cosas que hace mas de un a帽o no se producen.
Eso es todo jefe.
Termin贸 la reuni贸n y Miguel Angel se qued贸 solo en la sala reflexionando. Esta vaina no se estabiliza en una semana, ni en un mes, de malas con el viejo Villa y con Mr. Brand… yo voy a hacer lo posible por mostrar que me esforc茅, pero no me voy a dejar echar el agua sucia. Ahora s铆, s谩lvese quien pueda!
BREVE HISTORIA DE 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 sobretodo 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.
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 (Alvaro 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 mas 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 mas 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 aun 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 mas.
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 煤ltima paso para concluir y aprobar dicha practica 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 lideres 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, quede 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.
,
noviembre 24th, 2008 at 13:42
FERNANDO TORRES MEJIA
Eventos:
El proyecto no cont贸
鈥 Participaci贸n de personal tiempo completo
鈥 Con las personas mas id贸neas por 谩rea
鈥 Personal con conocimiento total de la empresa y de los procesos
鈥 Una adecuada capacitaci贸n.
鈥 Con consultores experimentados y se limitaron a improvisar durante varias de las fases
鈥 Con un compromiso de parte de los administradores que se limitaron a tratar de tener el m铆nimo del personal para que estos a su vez transmitieran los conocimientos adquiridos al resto de la organizaci贸n
Hechos:
鈥 Se fracaso con el proyecto en general
鈥 Descoordinaci贸n en todas las 谩reas de la compa帽铆a
鈥 Perdidas en general de toda la compa帽铆a
鈥 Elevados costos antes, durante, y despu茅s de la implementaci贸n
鈥 No se cont贸 con una adecuada planeacion
Problemas:
Uno de los principales inconvenientes que se puede apreciar en todo este proceso, fue la falta de definici贸n de un equipo multidisciplinario que debi贸 conformarse para un tama帽o de inversi贸n de este tipo, no solamente monetaria, si no que es de las t铆picas actividades que afectan a toda la organizaci贸n y para lo cual se requiere que se involucre a todas las 谩reas de la compa帽铆a. Es t铆pica la falta de liderazgo, y el sentido de pertenencia que se debe tener, pues al final se pod铆a observar que no todos estaban comprometidos o entend铆an la magnitud de los cambios que exig铆a este proyecto. Finalmente pienso que cuando se toma este tipo de decisiones, se debe contar con el compromiso de todos los colaboradores y as铆 mismo se debe retirar de la operaci贸n del d铆a a d铆a de los participantes en la implementaci贸n, pues este es el futuro y coraz贸n de la compa帽铆a
Paradigma:
B谩sicamente subestimar a las personas e intentar manejar este tipo de proyectos solo con personal gerencial pensando que son solo estos, los que saben como se maneja o como se deben trabajar los proyectos de gran impacto en la organizaci贸n pensar que las dem谩s solo se deben limitar a cumplir ordenes in sin ni siquiera involucrarlos en las etapas decisivas y necesarias.
Soluci贸n:
En proyectos de gran impacto, se debe involucrar a todas las 谩reas de la compa帽铆a, y ojala a todo el personal, pues son ellos los que realmente operan las herramientas.
As铆 mismo Entregar todos los recursos no solamente econ贸micos, si no de personal que se requieran, pues el 茅xito y los ahorros que se pretender tener, se ven afectados por nuestra forma ego铆sta de manejar los recursos
noviembre 26th, 2008 at 17:08
El caso de Bebidas Olaya…
Bebidas Olaya es una empresa familiar, como empiezan muchas, que fue creciendo conforme las oportunidades se iban dando: Inicialmente crece por una necesidad de “entrar en norma” con la producci贸n de Cerveza. Posteriormente aprovechando los canales de distribuci贸n venden otro tipo de bebidas y el paso natural de la misma despu茅s de ser exitosos con esta es iniciar la exportaci贸n de dichos productos… No siendo mas era completamente “indispensable” tomar otros argumentos para seguir creciendo y tomar las decisiones apropiadas que pudiesen llevarlos al cumplimiento del objetivo… Los socios necesitaban informaci贸n y las ERP fueron la soluci贸n reportada en su momento por n-mil proveedores.
Una vez detectada dicha oportunidad, se genero un plan dentro de la estrat茅gia de crecimiento antes expuesta, sin embargo en cada uno de los puntos siguientes se comentieron grandes errores que paralelamente se estan explicando:
鈥 Selecci贸n del proveedor de servicios de consultor铆a para la implementaci贸n del software: Consultores no biling眉es. Caso de Mohamed.
鈥 Selecci贸n del equipo interno implementador del SOFTWARE
No se hizo un mix entre la experiencia (por dudar de las capacidades t茅cnicas) y el personal nuevo de la compa帽ia (en teoria “mejor” preparado) sin experiencia en los casos tipo a resolver con el nuevo sistema. En algunos otros casos, se envio al empleado del cual se podia presindir… No necesariamente era el mejor!!!
鈥 Capacitaci贸n de dicho equipo en el manejo de la herramienta.
En algunos m贸dulos los mismos consultores de la empresa contratada no tenian conocimientos profundos del tema y al pedir refuerzos el material(para aprendizaje autodidacta) fue recibido en ingl茅s (limitaci贸n de personal con la lengua)
鈥 Elaboraci贸n del blueprint del sistema.
Se hicieron caracterizaciones de parametros con base en otras empresas, aqui se enlaza el punto de elecci贸n del team leader… Era personal nuevo en la empresa sin el conocimiento de los issues del d铆a a d铆a o la historia de eventos en cada 谩rea… Mientras habian otros miembros que sencillamente no aportaron nada.
鈥 Adquisici贸n e instalaci贸n del nuevo equipo de hardware
Se tomaron las cotizaciones mas baratas en las compras sin tener base t茅cnica para hacerlo.
鈥 Instalaci贸n y Configuraci贸n del ERP
El m贸dulo de planeaci贸n tuvo muchos problemas, dado que los consultores no tenian profundidad de conocimiento para efectuar modificaciones y dar entrenamiento… Las particularidades que necesitaban ser modificadas para la empresa no fueron tomadas en cuenta por los consultores, entonces el sistema no hacia lo que se necesitaba sino que la empresa debia adaptarse a lo que el sistema le imponia.
6 de los 9 meses del plan de implementaci贸n se fueron en esta etapa sin llegar a resultados satisfactorios.
鈥 Capacitaci贸n a usuarios finales
El plan decia entrenar al 100% de los usuarios, finalmente se decidi贸 usar un team leader que entrenara a los otros. Pero estos team leader en algunos casos no tenian idea de la terminolog铆a ni de las situaciones a manejar, su aporte fue minimo y los cambios efectuados en esta etapa fueron hechos a la carrera por las personas que debieron recibir la capacitacion desde un inicio.
鈥 Desarrollo del Piloto
Dado que no habia tiempo, los prototipos por aplicaci贸n no fueron evaluados individualmente sino en conjunto (sin apreciar el detalle de cada uno de ellos), nuevamente como en todo el proceso aqui tampoco fue tenido en cuenta el personal que “lidiaba” con el d铆a d铆a de los procesos manejados por el ERP.
鈥 Salida en vivo
Los modulos de Finanzas, Inventarios, Ventas y Distribuci贸n arrancaron el primero de Enero… Pero todo fall贸, no se pudo facturar, las problemas para ingreso/salida de materiales y producto, no habia apropiada grabaci贸n de productos y se presento diferencias en la informaci贸n financiera.
QUE SALIO MAL???
1. Mal servicio de la compa帽ia oferente del servicio de ERP
2. Bebidas Olaya no se “par贸 en la raya” y exigi贸 sus requerimientos
3. Equipo de trabajo de Bebidas Olaya no era el apropiado: Diferencias en el idioma, no era el personal idoneo (no aportantes, no conocian el d铆a a d铆a de las operaciones que se iban a ejecutar a futuro con el ERP), falta de compromiso del equipo elegido (tenian otras prioridades).
4. Entrenamientos incompletos y a las personas erradas.
5. No se evalu贸 de manera apropiada el piloto… Ejecuci贸n muy r谩pida
6. Nadie tomo la directriz del proyecto!!!
7. Al final a apagar incendios.
diciembre 5th, 2008 at 11:34
Caso: Hay vida despu茅s de un ERP
Eventos:
– No hubo planeaci贸n del proyecto donde estuvieran involucradas todas las 谩reas responsables, para construir entre todos con sus conocimientos la adaptabilidad el proyecto.
– No hubo capacitaci贸n adecuada para todos los involucrados.
– No evaluaron el proyecto y su viabilidad teniendo en cuenta los recursos que ten铆a la compa帽铆a.
– No hubo planeaci贸n de las consecuencia e impactos que generar铆a el proyecto.
– El proveedor del proyecto no conoc铆a la organizaci贸n ni como funcionaba para dar una buena asesor铆a.
– El idioma (tanto el ingles como el idioma t茅cnico) era una barrera para muchos de los involucrados en el proyecto.
Hechos:
– Sobre costo en el montaje del proyecto, por la actualizaci贸n que se debi贸 llevar a cabo en los sistemas.
– Incrementaron los costos de todos los procesos de producci贸n, transporte, y bodegaje..
– Se dise帽aron pr谩cticas ideales que no aplicaban al sistema de la organizaci贸n y los consultores evadieron el requerimiento y muchos de la organizaci贸n lo permitieron.
– Se cambiaron los consultores para la programaci贸n de aplicaciones paralelas en el sistema, pero con corto tiempo disponible lo que gener贸 sobre costos.
– No se logr贸 la estrategia de capacitaci贸n de todo el personal.
– No hubo personas dedicadas al 100% del proyecto, era una actividad
Problemas:
No haber planeado el proyecto para evaluar la viabilidad y la forma de llevarlo a cabo de una manera exitosa para toda la organizaci贸n.
Arqueotipos:
– Tomar decisiones apresuradas sin evaluarlas
– Pormenorizar la experiencia de las personas
– No trabajar en equipo
Soluci贸n:
– Hacer un plan para evaluar la viabilidad del proyecto
– Involucrar a todas las 谩reas correspondientes en la evaluaci贸n del proyecto
– Capacitar y darles a conocer a los consultores todo lo necesario de la organizaci贸n para poder evaluar la viabilidad de 茅ste proyecto.
– Definir un equipo con gente de varias 谩reas que se dediquen 100% al proyecto.
– Cuantificar y evaluar el impacto del proyecto para tener soluciones posibles anticipadas.
– Capacitar 100% a las personas, es un costo del proyecto como tal.
– Contar con el tiempo necesario para sacar el proyecto adelante.
enero 7th, 2009 at 8:41
Primero que Todo Saludos a Todos
Esto ya parece un cuento de Horror , que el erp , que el inventario ,que los usuarios ,que el de bodega , todos absolutamente todos son responsables de el mal funcionamiento de la aplicacion , yo supongo que antes tuvieron que elaborar una consultoria ,tambien hacer analisis de procesos y mejor aun probar el sistema como minimo 6 meses , todo eso sin contar que el personal se debe capacitar intensamente , todos no tenemos PI de 100/100 adicional a eso exixsten mas herramientas para el ELEARNING del personal de la compa帽ia 7x24x365 con las cuales se pueden realizar cursos y documentar los procesos,en todo caso la base del conocimiento de las empresas son los empleados ya que por alguna razon ellos con una tablita y un esfero solucionan los problemas sin nescesidad de un software de UD XXXXXXX lo que deberian evaluar no es quien tiene la culpa sino que los DIOSES de la tecnologia (ING) Sistemas y su Corte se metan en un centro de datos pretendiendo ser dioses todo lo puede y todo funciona Segun ellos y comienzen por agachar la cabeza , dirijirse a la JUNTA DIRECTIVA y aceptar que la embarraron , no se puede pretender altos estandares de produccion si los implicados no Hacen uso Coherente de la tecnologia , exixten los famosos mapas conceptuales , los diagramas de flujo ,los analisis de procesos y para que eso (ERP) funcione se debe integrar a todas las areas productivas de la compa帽ia ,delegar funciones de capacitacion seria , mantener retroalimentando permanentemente los funcionarios que tienen que ingresar la informacion , todo eso aunado a la mas vieja de todas las tradiciones matematicas (regla de tres ) no pretendan instalar y usar como dice MSOFT
LO QUE HICIERON FUE PLUG AND PRAY y esperar a que todo como por arte de Sistemas funcionara…….
marzo 1st, 2009 at 17:33
El caso de bebidas olaya presenta un claro problema de comunicacion en todas las areas. Es tan obvio observar que ninguna de las fases tenia una coherencia comunicativa con las areas que intervienen en el desarrollo de la implementacion del software. Se llega a un punto tan absurdo sobre el contenido de software y la manera de almacenar con los procesos instaurados de hace muchos a帽os que tiene la compa帽ia. Hay hechos evidentes como el mal escogido grupo de capacitacion, como el dejarle todo el conocimiento a una persona que se fue a otra empresa, los tiempos mal estructurados de planeacion escogido por pocas personas, el pensar que un nuevo sistema facilitaria de forma inmediata un mejor flujo de informacion y mejora en los procesos de almacenamiento y logistica, la no evaluacion de los impactos externos con proveedores y transporte.
La solucion ante este impase es retroalimentar la informacion con la empresa que dio el software, seguir con los sistemas y procesos que se venian manejando hasta no tener una plena seguridad de que este conocimientos es replicado a todas las areas y dependencias y asi suene absurdo hasta la persona de los tintos, puesto que esa area tiene un manejo de informacion de insumos para la parte administrativa y de aseo, en fin….cuando se quiera implementar una herramienta compleja y sofisticada y este intente cambiar habitos en las personas es como volver a nacer, toca paso por paso y eso si, tener a las personas mas abiertas al cambio y sin paradigmas que obstaculicen la implementacion.
marzo 1st, 2009 at 21:16
Varias empresas han mejorado su productividad,estructura de costos, cultura organizacional etc, al implementar un ERP el cual constituye una herramienta de planeacion de recursos empresariales o sistema de gestion empresarial; sin embargo muchas de estas empresas tambien han sub estimado los riesgos de un proyecto de implementacion de un software empresarial, este es el caso de bebidas olaya.
Eventos:
En log铆stica de planta no hay quien haga funcionar el sistema.
*Los centros de distribuci贸n y agencias no est谩n despachando los pedidos.
*El personal encargado de operar el sistema no sabe como hacerlo.
*Por ahorrar costos redujeron la inversi贸n en capacitaci贸n y utilizaron el sistema multiplicador que no dio resultado.
*No se ha podido imprimir el picking.
*Existen errores en el cargue de saldos.
*Se ingreso mercanc铆a a ojo para no estallar el cendist y dejar todo en el piso.
*El personal del piso esta temeroso y como se les debe vacaciones se quieren ir.
*El inventario esta hecho un caos.
*No hay buen manejo de las devoluciones no saben que hacer con ellas.
*Hay problemas con los transportadores.
*El sistema pide cosas que no se producen hace rato.
Hechos:
No se siguieron eficientemente las etapas de implementaci贸n del ERP, por ejemplo en la selecci贸n del proveedor de los servicios de consultor铆a escogieron un proveedor que aunque era del mismo que les vendi贸 el paquete no ten铆a el suficiente conocimiento de la funcionalidad del paquete, adem谩s hablaban otro idioma y las personas que estaban recibiendo la capacitaci贸n no eran biling眉es eso no lo tuvieron en cuenta.
No hubo una adecuada selecci贸n del personal encargado para ejecutar el proceso de implantaci贸n.
Poca profundidad de los cursos por parte del proveedor del sistema y adem谩s informaci贸n suministrada en ingles.
La informaci贸n suministrada por parte de los consultores no fue uniforme.
Se escogi贸 el proveedor de m谩s baja cotizaci贸n para la compra y la instalaci贸n del nuevo software, hicieron una inversi贸n de 2 millones de d贸lares y se pusieron a reducir costos en partes vitales del proceso de implementaci贸n del sistema que no pod铆an ahorrar.
El nuevo sistema no soportaba los requerimientos exigidos por el l铆der del modulo de planeaci贸n y los consultores evadieron el tema, por lo cual se requiri贸 de otros consultores especializados en programaci贸n de aplicaciones paralelas.
Se contrato muchos programadores de bajo costo, en lugar de pocos con experiencia comprobada.
No se involucro al personal actual de la compa帽铆a porque se les subestimo en cuanto a sus conocimientos actuales de la cadena de abastecimiento y manejo de sistemas de informaci贸n modernos.
PROBLEMA:
Falto definir y estructurar mejor una estrategia de operaciones para la implementaci贸n del nuevo sistema, que tuviera en cuenta los 5 pasos que se mencionan a continuaci贸n:
1-An谩lisis: Realizar un adecuado an谩lisis de los recursos de la empresa, procesos del negocio, impacto del ERP, y contexto externo.
2-Planeamiento y dise帽o: La empresa debe realizar una adecuada planeaci贸n del proyecto, teniendo en cuenta y dejando claro el Cuando, Como , Quien, y Que?
3-Prueba dise帽o (modelado) y entrenamiento del ERP.
4-Implementaci贸n: en esta etapa la empresa deber谩 hacer la implementaci贸n, el seguimiento y el ajuste de detalles.
5-Pos implementaci贸n: Mejoramiento an谩lisis del proyecto
Las empresas se construyen y funcionan con personas, y por eso es dif铆cil excluirlas de los cambios organizacionales. Uno de los errores m谩s comunes en los que a menudo caen la compa帽铆as es concentrarse mucho en las mediciones 鈥渉ard鈥 y prestar poca atenci贸n a temas no tan f谩ciles de medir, como por ejemplo, actitudes, valores, sentimientos y puntos de vista.
PARADIGMA: El Sistema es tan bueno que puede con todo y lo hace todo eficientemente, invirtiendo en el se lograran mejores 铆ndices de productividad, la capacitaci贸n viene por a帽adidura lo mas importante es comprar el paquete hacer una buena inversi贸n en el software.
SOLUCION:
EL equipo gerencial de bebidas Olaya debe elegir el equipo de proyecto y el l铆der ya que es cr铆tico para el 茅xito de la funci贸n de gerenciamiento y administraci贸n. La selecci贸n deber铆a basarse en la capacidad de los individuos para manejar los recursos, el tiempo, con una alta motivaci贸n y con mente abierta para las tareas que ata帽en a funciones horizontales.
Es necesario pasar mas tiempo con los usuarios finales del sistema para que ellos lo moldeen y no dejar simplemente al equipo de implementaci贸n que haga lo que considera mas adecuado para el usuarios final, adem谩s se deben definir muy bien las necesidades y el presupuesto; especialmente las funciones cr铆ticas que son determinantes para la selecci贸n del software.
Poner m谩s 茅nfasis en los casos de 茅xito y casos de fracaso, para, de esta forma, establecer probables desv铆os en los recursos del proveedor/implementador y en los propios.
Dedicar el suficiente tiempo para seleccionar una soluci贸n a implementar. Es una decisi贸n de inversi贸n muy importante para cualquier empresa, no s贸lo desde un punto de vista econ贸mico, sino tambi茅n desde un aspecto organizacional y de procesos. Consultar a empresas que usen los productos propuestos
Incluir activamente a todos los sectores de la empresa en la selecci贸n y evaluaci贸n, desde jefes hasta personal operativo, incorporar todos los procesos dentro de un mismo sistema y no por separado en diferentes tecnolog铆as.
Asumir que lo m谩s dif铆cil del cambio es vencer la inercia cultural, que tendr谩 que cambiar sus procesos internos, ya que no se puede ajustar un ERP a los procesos, sino que ambos deben confluir juntos
Planear el sub proyecto de migraci贸n de datos considerando que los recursos propios ser谩n exigidos por tareas extras, obtener opiniones imparciales y objetivas.
La selecci贸n del 鈥渧endedor鈥 del ERP es un tema cr铆tico dentro del rubro de gerenciamiento de la informaci贸n.
El cambio organizacional se relaciona con los recursos humanos para aumentar las ganancias y reducir los riesgos de la reingenier铆a de procesos. El 茅xito de un proyecto de reingenier铆a normalmente incluye un programa de cambio para considerar los aspectos de las personas, a las cuales se les dede involucrar y hacer parte de todo el proceso haci茅ndoles ver todas las ventajas de el y lo que les beneficiara a largo plazo.
marzo 2nd, 2009 at 10:39
Durante el caso se evidencia claramente una crisis producto de la implementaci贸n del nuevo ERP lo cual genera tensiones y traumatismos internos, los cuales seguramente ser谩n percibidos por los clientes externos y proveedores, agudizando a煤n m谩s el problema.
Lo primero es que cuando una compa帽铆a decide cambiar su sistema de operaci贸n, debe lograr que desde la alta gerencia hasta los niveles de operaci贸n de apropie el sistema y todos los integrantes de la organizaci贸n tengan 鈥渓a camiseta puesta鈥.
Tal como lo muestra el caso la alta direcci贸n s贸lo busca identificar problemas, pero no soluciones. En momentos de crisis lo ideal es generar un plan de choque, donde se planteen soluciones y se dise帽e un plan de acci贸n con tareas bien definidas.
La decisi贸n de implementar un ERP no fue tomada 煤nicamente por Villa. Se debe tener claro que es normal que cuando un ERP se implementa, tenga un proceso de estabilizaci贸n el cual puede durar algunos meses, por eso la importancia de tener un plan de contingencia por variable.
Tal como se mencion贸 el problema radicaba en que las personas que operaban no sab铆an c贸mo hacerlo, pero producto de una inadecuada capacitaci贸n, tanto a los consultores funcionales como a los usuarios finales. Lo anterior genera una mala actitud hacia el sistema y se crea resistencia.
Seg煤n lo comenta el caso el gerente del proyecto Fenix , no trabaj贸 en equipo con el Director de Log铆stica Miguel Angel Lopera y tampoco a las dem谩s personas que estaban en la operaci贸n, por lo tanto no hubo familiarizaci贸n con el sistema.
Concentraron el proceso de capacitaci贸n en una sola persona (Botero) y cuando esta persona tuvo una oferta laboral mejor se fue de la compa帽铆a generando caos en el proceso de capacitaci贸n (estrategia multiplicadora). Sumando a lo anterior al parecer la capacitaci贸n fue te贸rica, o sea que las personas nunca practicaron en el computador. Los manuales estaban en ingl茅s y eso tampoco ayudaba.
Otra situaci贸n por evaluar es que las personas del equipo implementador no conoc铆an a fondo la empresa, eran personas reci茅n ingresadas a la compa帽铆a. De otro lado las personas que ven铆an de las 谩reas a formar parte del proyecto eran los colaboradores con menores competencias en su trabajo, es decir no enviaron a las estrellas al campo, con esto se muestra la falta de compromiso con el proyecto.
La etapa de parametrizaci贸n no fue exitosa, debido al desconocimiento por parte del equipo del proyecto de la empresa. Eran inexpertos y carec铆an de experiencia y conocimiento de la empresa. Lo mismo ocurri贸 con el dise帽o de los m贸dulos de la soluci贸n del ERP, fue concebido desde lo ideal y no con una visi贸n realista.
No se capacit贸 a todos los usuarios finales, s贸lo a usuarios claves. Lo cualse refleja en falta de dominio y por supuesto errores al operar y retrasos. Tambi茅n falt贸 en las pruebas del sistema y modelamiento involucrar a los usuarios finales.
Las pruebas de integraci贸n demostraban la falta de trabajo en equipo al momento de modelar la aplicaci贸n. Estas pruebas en su mayor铆a no fueron con los usuarios finales.
No hubo un equipo que liderar谩 el cambio desde la perspectiva humana, entendiendo que le estamos cambiando la manera de operar a las personas.
Creo que en resumen falt贸 control a la ejecuci贸n del proyecto y sobretodo falta mucha claridad en la importancia del proyecto para el desarrollo de la empresa. Ahora lo 煤nico que hay que hacer es estabilizar la operaci贸n y potencializar el nuevo software, buscando las ventajas e identificando los puntos por mejorar. La alta direcci贸n debe comprender que no es una tarea del 谩rea de gesti贸n de operaciones, sino que involucra a todos los departamentos de la compa帽铆a. Tan importante es el proyecto y superar la crisis que est谩 afectando directamente las relaciones con clientes, competidores y proveedores, lo cual genera impacto negativo para la empresa.
No se debe desmontar el ERP, la soluci贸n es salir de la crisis y capacitar correctamente a las personas para que puedan operar el sistema de manera adecuada.
Elaborado por: Juan Carlos Oviedo R.
marzo 2nd, 2009 at 15:58
Este es un caso es muy com煤n en muchas empresas colombianas (mas de las que uno quisiera). Pues en el desarrollo e implementaci贸n de un sistema de informaci贸n deben seguirse unas pautas b谩sicas que garanticen de alguna manera y en gran porcentaje los resultados finales esperados.
飪 Se debe en primer lugar hacer un an谩lisis de los requerimientos de operaci贸n e informaci贸n que requiere la organizaci贸n
飪 Realizar un an谩lisis de los proveedores de software con las caracter铆sticas deseadas
飪 Escoger varios consultores que estudien las caracter铆sticas de la organizaci贸n y sugieran las posibilidades de implementaci贸n.
飪 Escoger el equipo consultor que implementar谩 la aplicaci贸n que se adapta a las necesidades de la empresa.
飪 Recoger los requerimientos y realizar la plantaci贸n del proceso de implementaci贸n de manera seria y ordenada.
飪 Escoger dentro de la organizaci贸n al personal m谩s id贸neo, experto en cada proceso que tenga experiencia y conozca los pormenores del funcionamiento de su proceso y separarlo del cargo mientras dure el proceso de desarrollo e implementaci贸n.
飪 Capacitar al personal de la organizaci贸n escogido como complemento al equipo consultor.
飪 Adquirir el hardware necesario para llevar a cabo el montaje de la plataforma, analizando de manera rigurosa la capacidad requerida y pensando en un horizonte de tiempo amplio que contemple el crecimiento de la organizaci贸n y anticipe los escenarios futuros.
飪 Instalar la plataforma e iniciar el proceso de desarrollo e implementaci贸n de acuerdo al plan previamente trazado.
飪 Realizar evaluaciones constantes a los avances de los procesos y recoger las inquietudes del personal involucrado en el proceso, como de los usuarios finales.
飪 Realizar pruebas peri贸dicas de los avances con los usuarios finales y recoger sugerencias y recomendaciones.
飪 Evaluar de manera constante el desarrollo del cronograma de actividades.
飪 Elaborar el piloto sobre el cual los usuarios finales realizaran todas las pruebas necesarias para detectar posibles errores y corregirlos antes de la entrada en producci贸n.
飪 Antes de salir a producci贸n debe realizarse un paralelo, que va a sacrificar a todo el personal de la empresa, pero que permitir谩 a la postre poder comparar resultados y realizar los ajustes necesarios.
飪 Una vez el sistema tengo un alto grado de confiabilidad puede salir a producci贸n y terminar el paralelo.
El seguimiento estricto de este protocolo que se puede mejorar o modificar de acuerdo al tipo de organizaci贸n ayuda a minimizar errores y reduce los altos costos que se deben pagar cuando la empresa entra en la sin salida de arrancar un sistema de informaci贸n a medias y con un c煤mulo de inconsistencias, la salida por etapas es tambi茅n una posibilidad cuando el sistema lo permite y permite ir probando la funcionalidad y flexibilidad del sistema.
Cuando en el desarrollo e implementaci贸n de un sistema de informaci贸n se configuran cosas tales como: improvisaci贸n, desinter茅s por parte de los miembros del equipo interno de desarrollo e implementaci贸n, ahorros inapropiados como en capacidad de equipo y dem谩s recursos. Generan un caos que generan perdidas incalculables para cualquier organizaci贸n y que en la mayor铆a de los casos no dan la posibilidad de dar marcha atr谩s y obligan a contratar una accesoria permanente de consultores para que corrijan errores en caliente, aumentando la inestabilidad del sistema.
Por eso en esta caso particular creo que la soluci贸n esta en que contraten de tiempo completo al equipo consultor y los miembros de la organizaci贸n trabaje tiempo extra para solucionar por lo menos de manera temporal los inconvenientes acaecidos por la mala planeaci贸n e improvisaci贸n en la implementaci贸n.
marzo 30th, 2009 at 23:24
Independiente de la herramienta, su implementaci贸n exige una planeaci贸n rigurosa de tiempo de incorporaci贸n, recurson humano, desempe帽贸 y funcionamiento. La inversi贸n econ贸mica para la incorporaci贸n de un sistema de informaci贸n debe ser proporcional a la disposici贸n de tiempo y calidad del personal a formar para su implementaci贸n. En el caso, no existe un plan de trabajo estudiado para la transmisi贸n de contenidos a cada sector de la organizaci贸n, era importante no solo seleccionar las personas id贸neas para recibir la capacitaci贸n si no con las condiciones de canalizar los flujos de informaci贸n para acudir a la multiplicaci贸n de la informaci贸n seg煤n el caso.
Tambi茅n es necesario tener en cuenta que la adaptabilidad del sistema la cual depende a su vez de cada organizaci贸n en particular, el reconocimiento de los ciclos del negocio en la gesti贸n actual, debe hacerse minuciosamente y previo a la incorporaci贸n del sistema, por lo tanto es importante varias opciones para aplicar la adecuada o ajustar la elegida. A su vez hacer un seguimiento riguroso de su desempe帽o y realizar las pruebas necesarias. Una inadecuada definici贸n de procedimientos, poca informaci贸n, y/o informaci贸n incompleta por parte de la organizaci贸n o informaci贸n i de la personas pertinentes, como en el caso, entorpecer谩 la incorporaci贸n de un programa que s贸lo automatizar谩 lo que ya por s铆 s贸lo funciona mal.
marzo 30th, 2009 at 23:30
Independiente de la herramienta, su implementaci贸n exige una planeaci贸n rigurosa de tiempo de incorporaci贸n, recurso humano, desempe帽o y funcionamiento. La inversi贸n econ贸mica para la incorporaci贸n de un sistema de informaci贸n debe ser proporcional a la disposici贸n de tiempo y calidad del personal a formar para su implementaci贸n. En el caso, no existe un plan de trabajo estudiado para la transmisi贸n de contenidos a cada sector de la organizaci贸n, pero adem谩s era importante no solo seleccionar las personas id贸neas para recibir la capacitaci贸n si no con las condiciones de canalizar los flujos de informaci贸n para cumplir exitosamente con la multiplicaci贸n de la informaci贸n seg煤n lo propuesto, que aunque no es lo ideal puede conseguirse con mejores resultados.
Tambi茅n es necesario tener en cuenta que la adaptabilidad del sistema depende a su vez de cada organizaci贸n en particular, es necesario el reconocimiento de los ciclos del negocio en la gesti贸n actual, el cual debe hacerse minuciosamente previo a la incorporaci贸n del sistema, por lo tanto es necesario revisar varias opciones para aplicar la herramienta adecuada o ajustar la elegida. Posteriormente hacer un seguimiento riguroso de su desempe帽o y realizar las pruebas necesarias de control . Una inadecuada definici贸n de procedimientos, poca informaci贸n, y/o informaci贸n incompleta por parte de la organizaci贸n, como en el caso solo entorpecer谩 la incorporaci贸n de un programa que s贸lo automatizar谩 lo que ya por s铆 s贸lo funciona mal.
abril 15th, 2009 at 16:38
Indiscutiblemente, la vida despu茅s de una ERP, se complico.
La falta de comunicaci贸n entre producci贸n y sistemas genero el caos, sumado a las vac铆os de gerencia del proyecto.
El proyecto se desarrollo bajo la premisa de ahorrar costos y no de incrementar productividad con calidad.
La Selecci贸n del proveedor no se realizo por el conocimiento y experiencia del mismo, sino por lo que costaba.
La selecci贸n del equipo interno implementador no fue la adecuada, no se involucraron a los dolientes en el proceso.
No hubo una oportuna capacitaci贸n.
La adquisici贸n e instalaci贸n del Hardware se hizo con miras de corto plazo sin considerar las necesidades futuras.
No se realizo un cronograma juicioso, detallado y preciso, todo se improviso bajo la marcha.
Los usuarios finales no estuvieron involucrados en el proceso de implementaci贸n, no pudieron prevenir errores ni realizar sugerencias sobre el funcionamiento.
La salida en vivo no fue definitiva, fue improvisada, interrumpida y con vac铆os.
La capacitaci贸n permanente de todos los usuarios, las sugerencias de los mismos en la implementaci贸n y desarrollo del ERP, el no tener como lideres del proyecto a los mejores colaboradores, no profundizar en el aprendizaje, el no tener la camiseta puesta y el realizar un cambio de plataforma solo por cumplir con un proceso de modernizaci贸n de la compa帽铆a al menor costo posible, llevaron a que la implementaci贸n de ERP fuera un fracaso.
marzo 22nd, 2010 at 21:04
El caso del ERP en Bebidas Olaya es un ejemplo de c贸mo las omisiones e inconsistencias en el actuar empresarial pueden multiplicarse entre s铆 y resultar devastadoras para la salud de una compa帽铆a.
Los motivadores de la decisi贸n de mejorar los sistemas de informaci贸n parecen en un inicio ser apropiados: efectivamente, la informaci贸n oportuna y los controles pertinentes en la cadena de valor son elementos que pueden contener un alto valor estrat茅gico para la organizaci贸n. Sin embargo, desde el punto de vista estrat茅gico, deben resaltarse dos principios fundamentales que parecen no haberse cumplido.
1. Primero estrategia, luego software. Si despu茅s de comprado el software, en la etapa de configuraci贸n se est谩n a煤n realizando deliberaciones te贸ricas, pareciera que a煤n no est谩 del todo clara la estrategia de operaci贸n. Las “mejores pr谩cticas” incluidas en el software deben ser coherentes con la cadena de valor de la empresa. De esta forma, resulta desconcertante que sea necesario desarrollar aplicaciones paralelas para soportar procesos requeridos en la operaci贸n.
2. El 茅xito de la decisi贸n requiere de una buena ejecuci贸n. Varios hechos posteriores a la decisi贸n de adquirir el software ilustran una desalineaci贸n en las acciones subsecuentes. Llama la atenci贸n, por ejemplo, invertir en el software de mayor precio para despu茅s asignar el hardware de menor precio (a帽adiendo una restricci贸n al desempe帽o del software), o bien, asignar al personal menos id贸neo para las capacitaciones (con las evidentes dificultades posteriores para la utilizaci贸n del sistema).
La sucesi贸n de errores y vac铆os en la comunicaci贸n es extensa. Un liderazgo efectivo, aterrizado al campo y ejecuci贸n, hubiese sido deseable para integrar los esfuerzos del costoso equipo de trabajo; para involucrar al personal relacionado con cada etapa y detectar oportunamente las fallas, y sobre todo, para imprimir un sentido de logro y compromiso en el personal involucrado en el proyecto.
marzo 30th, 2010 at 13:54
Antes que nada, a la pregunta del nombre del caso considero que si hay vida, y puede ser una mucho mejor vida despu茅s de un ERP siempre y cuando se cumpla con 3 premisas fundamentales. 1) Adecuada toma de decisi贸n, 2) adecuado esfuerzo de parametrizaci贸n y alistamiento y 3) adecuado esfuerzo de salida en vivo y estabilizaci贸n.
En lo referente al punto 1) lo primero es tener claro cu谩l es el fundamento para decidir tener un ERP como plataforma de operaci贸n en una compa帽铆a. La tecnolog铆a, como tantas otras herramientas, deben ser puestas al servicio de la estrategia y los fines organizacionales. La decisi贸n de implementar un ERP parte de un an谩lisis de la estrategia corporativa y de las decisiones de gobierno corporativo que de la misma se desprenden, pues cualquier sistema de informaci贸n es un veh铆culo para estandarizar procesos, potencializar flujos de datos y de informaci贸n con miras a lograr las metas y en esa medida se debe tener clara la estrategia y sus palancas para garantizar que no se pierdan en la implementaci贸n. Para el caso, lo primero es que la decisi贸n sobre el ERP parece m谩s basada en un comparativo del mercado y en el reconocimiento de un proveedor que en un verdadero an谩lisis de ajuste entre implementador, aplicativo y empresa. Temas tan sencillos como el idioma de los consultores o su nivel de expertise en la implementaci贸n deja mucho al azar pues la transferencia de tecnolog铆a no estaba garantizada. Al igual que este hay otros ejemplos.
En relaci贸n al punto 2), una vez tomada la decisi贸n se debe garantizar que adicional a los expertos del implementador se tengan los mejores expertos internos en un trabajo integrado para garantizar que todos los flujos necesarios para que los procesos corran y se puedan lograr las sinergias y mejoras est茅n presentes. Esto debe ir acompa帽ado de una estrategia de cambio organizacional acorde al dimensionamiento que se haga del impacto de cambio con el fin de poder vincular a las personas con el modelo de operaci贸n parametriado cmo parte de una cadena de abastecimiento integrada y no por funciones independientes. En este aspecto hubo muchos puntos a mejorar:
– como primera medida no contar con el personal de operaci贸n, el mejor, le rest贸 mucha potencia al proyecto pues limit贸 el conocimiento detallado de lo necesario para operar y la participaci贸n de quienes est谩n en el d铆a a d铆a en la configuraci贸n en la herramienta.
– la falta de comunicaci贸n entre la 谩reas y a nivel de la alta gerencia
– el no dimensionamiento del impacto de forma adecuada y por consiguiente la falta de involucramiento en el tema de las 谩reas d eoperaci贸n adicional a los miembros para el equipo.
– la falta de darle sentido de compa帽铆a al proyecto y limitarlo a grupo cerrado, entre otros.
Finalmente sobre el punto 3) no hubo un manejo adecuado de las contingencias previas a la salida en vivo durante la salida en vivo. La respuesta de la alta gerencia denot贸 la desconexi贸n con el proyecto y la dificultad en su vinculaci贸n con la estrategia gracias a esta desconexi贸n. La falencia en formaci贸n de las personas que hubo en la fase 2) tampoco fue solucionada en la fase 3) llevando a un desastre organizacional.
Por esto entre otras cosas concluyo que si se puede tener 茅xito…驴c贸mo? Aprendiendo de casos como estos y de c贸mo tomar la decisiones adecuadas. Berkshire Hathaway Inc., una de las corporaciones m谩s exitosas del mundo no tiene ERP porque su estrategia es diversificada desde su modelo de operaci贸n, Mc Donalds una compa帽铆a presente en casi todo el mundo es exitosa y no tiene un ERP como plataforma, tiene una base de procesos que le permite funcionar de manera estandarizada. FedEx una compa帽铆a global es exitosa y sin tener procesos estandarizados funciona con sistemas de informaci贸n compartidos que le permiten coordinar su operaci贸n y finalmente compa帽铆as como Target tienen tanto la misma plataforma y los mismos procesos tambi茅n siendo exitosas. La decisi贸n de un ERP es una decisi贸n de estrategia de operaci贸n, no de moda o necesidad por tendencia. En esa medida un an谩lisis adecuado dar谩 la respuesta adecuada que de ser s铆, y siendo consistente en apostarle con todas las capacidades organizacionales debe llevar a la compa帽铆a a una mejor vida.