ERP de código abierto en las empresas

Es un hecho que los sistemas de gestión de código abierto (SGCO de ahora en adelante) no están teniendo el mismo nivel de aceptación en las empresas que otros tipos de aplicaciones también en código abierto como por ejemplo Linux como sistema operativo, MySQL como base de datos, Apache como servidor Web, etc.

¿Qué está pasando?, ¿por qué, con toda la parafernalia que se está montando, la promoción por determinadas administraciones públicas, el clamor de tantos profesionales solventes, etc. ... las empresas no acaban de creérselo?


Pues en mi humilde entender estas son algunas de las pistas que ayudan a entenderlo:


1. Las empresas de servicios importantes no se están metiendo.

Y es previsible, ¿cómo van a morder la mano que les da de comer? Accenture, IBM, EDS, Indra, etc. facturan demasiado con comisiones sobre licencias y servicios alrededor de SAP, Oracle, Lawson, ... como para encabronar a estos todopoderosos fabricantes.

La única compañía con tamaño, capacidad tecnológica, comprensión del fenómeno y músculo financiero que podría hacer mover al sector en ese sentido es Sun, que aunque hizo sus pinitos con implantaciones de un ERP propio, ahora prácticamente abandonado, no está tan condicionada como las mencionadas anteriormente.

¿A qué espera Sun?, ¿es que no ven la oportunidad?


2. Solvencia aparente.

Este punto no hay que despreciarlo aunque a priori pueda parecer un prejuicio injustificado.

Una empresa, sobre todo si es grande, necesita que en caso de desastre en la implantación de su ERP pueda ser compensada, demandar a alguien y obtener, en su caso, una recuperación, aunque sea parcial, de su inversión.

Y no sólo esto, sino que si el proyecto se retrase, el implantador pueda aguantar hasta el final sin declararse insolvente y si te he visto no me acuerdo.

Recientemente viví un caso en el que una empresa prefirió implantar su ERP directamente con el fabricante y no con la empresa de servicios con más experiencia local en la implantación de ese ERP, y la decisión se tomó sólo por el tamaño y capacidad de hacer frente a "daños y perjuicios" y siendo conscientes todos que se optaba por un peor implantador.

Pues si pasa con los ERPs privativos, pues aún más con los SGCO. ¿A quién demandar?... ¿a la comunidad?

3. Madurez de los SGCO.

No nos engañemos. Una aplicación de gestión es una aplicación de misión crítica con unos requerimientos funcionales muy concretos y normalmente exigentes.

La funcionalidad cubierta por los ERPs privativos actuales no ha salido por generación espontánea sino por inversión en i+d y la capitalización de las experiencias en los sucesivos proyectos de implantación. Los SGCO han empezado más tarde y les queda camino por recorrer.

Habitualmente, y ese es uno de los mensajes de los implantadores de SGCO, se parte de una funcionalidad básica y se desarrolla lo que falte durante el proyecto. En una implantación con ERP privativo el desarrollo necesario, a priori, es siempre mucho menor. Esto hace que en la práctica los proyectos de implantación de SGCO, aún siendo más baratos, no son diferencialmente más baratos como para correr el riesgo.

En mi caso concreto conozco tres casos por los que un proceso de selección de ERP, un SGCO que se presentaba fue descartado por este motivo. En una ocasión el coste de implantación que salía era prácticamente el mismo que con los otros (privativos todos) que competían y en las otras dos ocasiones, el propio implantador/fabricante se retiró al conocer los requerimientos funcionales (quizá porque apreció que otra vez no iba a ser competitivo en costes)

4. No hay tanta independencia real de vendedores e implantadores

Una de las grandes ventajas que se suelen esgrimir respecto de los SGCO es que te permiten independizarte de los fabricantes/implantadores porque: uno, hay múltiples opciones para elegir implantador y dos, tienes acceso al código fuente.

Con respecto al primer punto, sencillamente no es correcto: en ERPs privativos tampoco se depende tanto del implantador porque puedes optar por diferentes empresas partners (Microsoft, SAP, Oracle, ...).

Esto es especialmente cierto con Microsoft Dynamics donde los partners de Microsoft van con el cuchillo en la boca quitándose clientes los unos a los otros.
Además, y esto es particularmente remarcable, cualquier verticalización o adaptación realizada por uno de ellos es de obligada disponibilidad para el resto - fuentes incluidos y con pago de licencias aparte por supuesto.

Respecto al acceso a los fuentes, en la práctica no es tan sencillo, en aplicaciones con cierta complejidad como los SGCO, meterle mano al código aunque tengas los fuentes y esté todo documentado y bien programado, por lo que acabas dependiendo, igual, del implantador que te acabó adaptando el sistema, ya que es el único que puede entender en un tiempo razonable lo que ha hecho.

5. Reticencias a compartir por las empresas.

No me imagino a una empresa pagando un proyecto para desarrollar una megaaplicación que incorpore sus mejores prácticas sobre un SGCO para, por obligación, tener que cedérsela a la competencia - para eso se hace un desarrollo a medida propietario y formando a personal propio - que es justo lo que hacen las empresas de servicios financieros tradicionalmente.

Ya se que Julen me va a castigar por esto pero es que uno es un poco escéptico cuando hablamos de empresas.

Creedme que me quedo con mal sabor de boca con este post. No es que yo sea un fundamentalista en esto. Creo que las aplicaciones de código abierto y las privativas pueden y deben convivir en sana competencia, pero me queda la sensación de que el tema pinta mal para los sistemas de gestión de código abierto. Intentaré hacer una segunda parte a ver si se me ocurren salidas ...