No es simplemente dar al proveedor lo que necesitamos y que lo resuelva. Ha de ser un trabajo conjunto desde el principio, en el que se involucren, no sólo nuestra IT y el proveedor, también el negocio, los usuarios. No es un proyecto de TI, es un proyecto para el negocio.

1.- La inmensa mayoría de las empresas que conozco se han empeñado, a la hora de implantar un ERP, en personalizar el mismo, hasta extremos insospechados, para que refleje lo más fielmente posible la forma en que trabajan en ese momento. Ni se han cuestionado si esa forma de trabajar es la mejor (que puede que no) ni las consecuencias que eso tiene para el mantenimiento y las actualizaciones del ERP de marras a versiones posteriores (que por lo general no son 100% compatibles, ver el porque en el segundo punto).

Lo cual genera situaciones kafkianas, como que los plazos de implantación en una empresa de tamaño medio/grande dure entre 2 y 4 años, tiempo medio de actualización del fabricante del software de ERP. Lo cual quiere decir que para cuando se termina de implantar al 100%, ya está la siguiente versión en el mercado y en 3-4 años más, la versión implantada deja de estar soportada (por los altos costes de mantenimiento que supone al fabricante, con un margen de ingresos ínfimo).

2.- El mundo del software privativo, donde el principal objetivo es la venta de productos informáticos para la obtención de ingresos (perfectamente legítimo todo sea dicho de paso), necesita sacar nuevas versiones de su producto cada x años. Porque sino, una vez que ha vendido todo lo que podía vender de su anterior versión, echa la persiana y cierra el negocio. El software no se gasta, no se estropea (no más de lo que estaba cuando te lo han vendido , no caduca. O vendes nuevas versiones, o estás muerto.

Y sólo hay dos argumentos habitualmente utilizados para vender nuevas versiones:

a) incluir nuevas características y/o mejor rendimiento del producto.

b) prometer arreglar fallos existentes en la versión actual.

La primera suele incluir “de serie” cambios a veces incompatibles con versiones anteriores, que se acentúan aún más si hemos sufrido el fenómeno de “personalizacionitis” descrito más arriba. Muchas veces son cambios absolutamente necesarios para poder obtener esa nueva funcionalidad o aumento de rendimiento. A veces, por desgracia, son simples estrategias de “vendor lock-in” que llaman los americanos, y que aquí traduciría libremente por “tener al cliente agarrado por las pelotas”.

La segunda es bochornosa directamente: el fabricante admite descaradamente que su producto es defectuoso, pero no nos lo arregla. Simplemente nos dice que compremos otra vez su producto para ver si se ha arreglado todo (sin ningún tipo de garantía, como la primera vez).

Algunos de estos problemas se pueden paliar usando software libre, siempre que haya uno que se adapte a nuestras necesidades (otro asunto es definir cuales son realmente nuestras necesidades). Y digo “algunos” y “puede” porque el software libre no es gratuito necesariamente y porque lo que encontremos no tiene porque ser lo que necesitemos exactamente.

Pero al menos nos permite no depender de un único fabricante (el famos vendor lock-in) de arriba y que toda la gestión de mi empresa esté en sus manos y tenga que actualizar al ritmo que me imponga el fabricante. Si el código es libre, puedo contratar (y pagar) a la empresa que quiera para que me lo personalice, lo mantenga, lo amplie, etc. Si esa no me gusta o me enfado con ella, me voy con otra. Pero el software (y lo que es más importante, la información incorporada en las tripas de ese software) es mío. Y yo marco los ritmos, las funcionalidades, las características, etc. Y no espero a ver si en la siguente versión, que sale dentro de 12 meses, me corrigen ese error que me está parando la producción. Me lo arreglan ya, porque eso y no otra cosa es prioritario para mí.

El software libre es un mal negocio para los que se dedican a vender software (porque vender algo que luego otros pueden regalar suele ser complicado), pero es un negocio estupendo para los que usan ese software.

Y para no ser tan teórico y aportar algo positivo, ahí va la referencia de un software ERP muy completo y completamente libre:
Compiere (http://www.compiere.org). No es tan grande ni potente como SAP o BaaN, pero es una muy buena opción para empresas de tamaño medio.

Vaya, me ha quedado un poco más largo de lo que esperaba. Al menos puedo afirmar que no se han maltratado animales durante la redacción de este comentario (no prometo nada sobre el antes y el después).

Saludos. Iñaki.

P.D. Sigo pensando que el tamaño de letra de este blog es demasiado pequeña.

O como dicen Jaizki y Julen, trabajamos en adaptar un ERP a lo que necesite la empresa. Lo cierto es que desarrollar un sistema completo no tiene mucho sentido. Las tareas del día a día son muy similares en todas las empresas, y no es muy práctico reinventar la rueda cada vez. Además, hay empresas, pero también hay monstruos, donde desarrollar a medida es muy dificil. Si a veces cuesta decidir qué opción de las que ofrece el ERP se usa, imaginad si hay que definirla por completo.

Por otro lado, a algunas empresas les viene muy bien tener una consultora a la que responsabilizar, y que tome las decisiones por ellos. Mal hecho, pero ocurre.

Como dice Julen, el problema es la ética de la consultora, y la implicación del cliente con el ERP.

Por desgracia no es lo habitual, la dirección de demasiadas empresas ve la informática con algo misterioso y desconocido que es mejor no tocar. La misma gente que no duda en conocer en detalle las máquinas que compra para su proceso de fabricación, por muy compleja que sea, desiste de intentarlo cuando hay ordenadores de por medio.

Cuando se deja toda la interlocución con los implantadores del ERP en el informático o en el departamento de sistemas, según el tamaño de la empresa, el resultado de la implantación dejará por fuerza mucho que desear. Quienes deben estar implicados son los responsables del negocio.

Sin embargo, no tengo tan claro lo de dibujar a la consultora como los malos de la película. ¿Qué debería hacer la consultora? ¿Enfrentarse al cliente para hacerle ver que debe implicar a otro tipo de gente y que, finalmente, el cliente compre a otra consultora que de menos la lata? ¿Negarse a vender porque el cliente no está preparado para comprar? Además, muchas veces, una mala implantación de un ERP es mejor que el caos absoluto precedente.

No creo que el problema esté ni en el ERP ni en la consultora.

Por cierto, una pregunta para la reflexión, según la Kokología para consultores de Mario en “nods en la red” (http://nodos.typepad.com/nodos_prime/2005/12/kokologa_para_c.html), ¿sería el ERP cirugía como plantea con dudas?

Más que negocio habría que llamarlo chantaje, porque además si dás ese primer paso, considero absolutamente inevitable quedar atrapado en lo que Senge llamaba arquetipo sistémico de desplazamiento de carga. La empresa perderá toda capacidad de desarrollar su propio software, y se hará practicamente imposible la vuelta atrás. Quedas atrapado en las “garras” de una empresa externa cuya meta es ganar dinero y no que lo ganes tú por muy cliente que seas.

Es verdad que por otro lado la empresa debe concentrarse en las actividades que generan valor. Pero desde luego, yo personalmente nunca pondría fuera del control de la empresa algo tan vital como es el flujo de información, a no ser que no me quedara otro remedio.

¡Que no me muerda nadie que estamos en navidad! ¡Y después de todo es sólo la opinión personal de un tipo raro que anda subiendo piedras por las laderas!

Con lo el Euro y el efecto 2000 ya metieron el suficiente miedo como para hacer que las empresas se dejaran la pasta. Luego, las NIC y Basilea y su madre. Y luego, cuando no haya nada más, irán directamente a lo que comentas: “uy, es que hemos cambiado de versión, te toca migrar”.

Es un chantaje: una vez que pagas la primera vez, estás atado de por vida…