La Universidad de Arizona ha descubierto un novedoso y original método para implantar ERPs sin pasarse del presupuesto. El método consiste básicamente en que "el sistema se arranca en la fecha prevista esté como esté. Ya iremos arreglando internamente y sobre la marcha (on the fly que dicen ellos) lo que vaya saliendo".
La base racional sobre la que se sustenta el "método" es que "ya que es imposible arrancar un ERP sin que luego haya problemas, no retrasemos el momento de dicho arranque, ya que esa es la razón principal de las desviaciones de presupuesto" - sobre todo en facturas de consultores.
No les ha ido demasiado bien ya que incluso tuvo que intervenir la policía para proteger las instalaciones ante los trabajadores amotinados que no cobraban (una de las cosas que "no estaba fina" en el arranque era el módulo de nóminas - grave error donde los haya, porque un usuario puede aguantar que la contabilización de facturas le "casque", pero eso de no cobrar su nómina...)
En principio, el ahorro se obtiene básicamente de evitar los honorarios extras de los consultores por extensión del proyecto (magnífica frase para meter otra factura) pero quedarse en eso me parece un poco miope - sí es cierto que en facturas de consultores se habrán ahorrado un pico pero ¿cuáles son los costes asociados a la falta de rendimiento del personal durante el periodo de estabilización?. La diferencia es que un coste se materializa en facturas y el otro es más difícil de cuantificar.
De todas formas y aunque aparentemente puede parecer una aberración, en algún caso podría tener sentido, ya que ¿qué pasa si el coste de consultor y el interno se compensan?... puede que en un organismo público sí (ya que no se van a perder ventas sobre todo). Quizá esté aquí la clave de la decisión del "innovador" que lo tiró p'alante (casi me lo imagino vestido de Cow Boy y pegando un tiro al aire)
¿Y el implantador del ERP? pues que podrá poner de forma muy destacada en sus referencias un proyecto que cumplió el presupuesto, pero me imagino que en su fuero interno debe estar reconcomiéndose por los honorarios por ampliaciones del presupuesto que se le han escapado.
De hecho, Oracle que es el implantador, ya lo ha colgado como un caso de éxito en su Web.
Nota: después de releer el post he visto que he utilizado repetidamente el palabro "arrancar" - para los que no estéis muy puestos en esto de los ERPs, arrancar significa en la jerga de la profesión algo así como poner en marcha.
Nota: después de releer el post he visto que he utilizado repetidamente el palabro "arrancar" - para los que no estéis muy puestos en esto de los ERPs, arrancar significa en la jerga de la profesión algo así como poner en marcha.
6 comentarios:
In presionante. Conste que empezar, esté como esté, no deja de ser un lanzamiento en beta, ¿no?
Pues sí, la verdad Julen que es como una beta, pero no es lo mismo una beta en el "mundo 1.0" que en el "2.0". En el segundo se vive en beta perpetua y los cambios son muy pequeños tendiendo a infinitesimales si se puede (aparte del truco de que beta se utiliza para decir de alguna manera que "por ahora no te cobro pera ya verás cuando no sea beta")
Saludos
Pues el viernes por la tarde yo hice similar recomendación a una empresa del grupo...que arranquen con una aplicación aunque no cubra el 100% de sus necesidades y luego ir trabajando en ella.
Si partes de dos premisas básicas en sistemas: "en el arranque siempre hay problemas" y "en el minuto 1 ya verás que hace falta modificar la aplicación", lo de arrancar "a las bravas" no es tan disparatado.
Por recuperar algo de sensatez, que parezco un pirómano. Probablemente lo de los chicos de Arizona sea extremo, pero yo creo que si esperas a tener el sistema perfecto, lo más probable es que no arranques nunca: nunca tendrás el ciclo de prueba completo, el entorno de explotación no es idéntico al de desarrollo, habrán surgido modificaciones a la versión inicial durante su desarrollo y, si esperas a tenerla, aparecerán otras nuevas, etc.
No se trata de "tirarse a la piscina" sin mirar antes (lo de las nóminas es de suicida), pero si en asumir ciertos riesgos y aplicar cierta filosofía de "beta".
P.D.: Sólo he vivido un "arranque perfecto", incluso con felicitación del consejo al equipo de implantación a los 4-5 días. Cuando pasaron un par de semanas se descubrió que las operaciones no pasaban correctamente a contabilidad y hubo que tirarse un fin de semana corrigiendo "a mano" todos los pedidos de una fabrica de pedidos recibidos en tres meses ;-)
(Perdón por el rollo, pero me apetece más comentar aquí que escribir un post nuevo)
De rollo nada Rafa, bienvenidos tus comentarios.
Coincido con tu reflexión que yo reformulo con un refrán: "lo perfecto es enemigo de lo bueno"
Recuerdo ese refrán desde que a mí, siendo un humilde analista, me la dijo un gerente de esa consultora que conocemos tú y yo tan bien, cuando estaba tardando mucho en acabar una tarea porque la quería dejar "perfecta".
Pues... tampoco han inventado nada nuevo Luis, eso ya lo habíamos hecho algunos, en concreto un servidor en un par de clientes, uno con un ERP de Comercial + Financiero y otro con un ERP + MRP.
A ver, hay que tener cierto valor para arrancar asi, está claro, pero... dependiendo de la idiosincrasia de la empresa creo que es correcto correr los riesgos asociados al arranque "en beta", como dice Julen.
Hay proyectos que se van alargando en el tiempo tanto, y tienen tantas dificultades, cambios de funcionalidad y especificaciones, etc... que los usuarios clave (y los finales) van perdiendo el respeto al proyecto, y sin quererlo comienza a ser complicado incluso montar una simple reunión de control.
Reconozcámoslo: los usuarios suelen ser nuestro peor enemigo en las implantaciones porque se resisten al cambio todo lo que pueden. Cuando el proyecto comienza a alargarse los usuarios a veces perciben una cierta posibilidad de que finalmente no se lleve a cabo, albergan la secreta esperanza de que las dificultades acaben por cansar a la dirección y abandonen el proyecto, dejándoles seguir trabajando con su querida hoja de excel.
Arrancar asi parece como un golpe en la mesa, es como un espaldarazo más que definitivo de la dirección de la empresa al proyecto. Es un toque a los usuarios que disipa las dudas. Es un "esto es lo que hay, esto se va a quedar si o si".
Por cierto, aprovecho para felicitarte por tu nominación a los Thinking Blogger en el blog de Antonio España. ¡Enhorabuena!
Hola Alejandro, pues yo no lo había visto tan a lo bestia como aquí. Piensa que son cientos de usuarios y que como le comento a Julen, una beta en el mundo 1.0 no es lo mismo que una beta en el mundo 2.0.
Muy buena reflexión la de que alargar el proyecto favorece los actos subversivos y saboteadores de los "malditos" usuarios. Otra razón para acortar cuando se pueda.
Gracias por la felicitación y por los comentarios.
Publicar un comentario