Sí que es relevante que un ERP sea libre
Hace unas horas escribí Ahora empiezan a verse los problemas del ERP. Sergi de Tecnorantes me contesta en su blog porque la respuesta le estaba quedando muy larga para un comentario.
A mí me pasó exactamente lo mismo, así que lo que iba a ser un comentario de lo que discrepaba lo dejo finalmente como un nuevo apunte.
Discrepo fundamentalmente en:
No obstante, y aquí si que voy a discrepar ligeramente con Ricardo, el que el ERP sea libre o propietario no cambia mucho el escenario. … Como decía, libre o propietario, el escenario no cambia esencialmente.
Como bien dice Sergi (Obviamente los proveedores van buscando la cautividad), la cautividad es uno de los objetivos perseguidos por los proveedores. Esa cautividad desaparece automáticamente si el programa es libre –aunque hay tácticas como la de MySQL para mantenerla a pesar de la licencia libre–. La frase tan repetida el software libre libera el mercado de servicios lo explica todo.
Yo diría que todas las otras razones de los problemas del ERP son prácticamente derivadas de su característica de privativo, especialmente aquellas de los altos costes de puesta en marcha y personalización. Si el programa fuese libre este mercado de servicios sería mucho más competitivo y seguramente de mejor calidad.
Pagar a consultores por extender el ERP es un coste para la empresa, tanto si el ERP es libre como propietario, como también lo es si tienes que tener a personas en plantilla para hacer las adaptaciones.
No es así, porque no sólo los costes no son comparables –costes de cautividad versus costes de mercado libre–, sino que en un caso estás muy limitado a lo que puedes hace –”personalizar o adaptar módulos”– mientras que en otro tienes la libertad de cambiar hasta el propio núcleo.
Si los ERP fuesen libres –¡ojo! que no digo que en su momento haya sido posible– la evolución hubiese sido muy distinto. Por ejemplo hoy tenemos que la infraestructura imprescindible para la gran mayoría de proyectos “web 2.0″ es la pila LAMP. Esta pila no surgió como una agregación instantáneo por diseño de comité o de un “producto” de una empresa, sino que fue una agregación natural y casi biológica.
Pero hay un caso paradigmático al que llamaría la “Ley de Evolución Impredecible del Software Libre”, o LEISL:-) ). Cuando Linus Torvalds liberó la primera versión del núcleo Linux fue muy criticado –especialmente por Tanenbaum– por tratarse de un núcleo monolítico. Según ellos esta característica haría imposible que el núcleo pudiese exportarse a otras plataformas distintas a la original x86 (de hecho el diseño original de Linux esta orientado específicamente a esta plataforma).
Sin embargo pocos años después el núcleo Linux (y toda la pila GNU que lo convertía en un sistema operativo completo) se ejecutaba en más plataformas que ningún otro sistema operativo, desde pequeños controladores, set top boxes, ordenadores personales hasta los superordenadores más grandes. Eso no lo había logrado nadie, ni siquiera grandes y multimillonarias empresas como Microsoft que ni siquiera pudo mantener el soporte multiplataforma del Windows NT, a pesar que estaba especialmente diseñado para ello.
Por el contrario el ERP es por diseño una “pila” preconcebida con algunas opciones, y los módulos y opciones dependen exclusivamente de un sólo proveedor. Este diseño tiene problemas intrínsecos de complejidad como detallan en los estudios enlazados, pero además tiene el problema de la cautividad. El cliente está atado y sujeto sólo a las soluciones de su proveedor.
Además en el estudio comentan que muchas empresas siguen todavía con versiones de hace diez años porque les es imposible gastar nuevamente fortunas en nuevas versiones y la correspondiente adaptación y pruebas de todas sus “personalizaciones” que funcionan en las versiones antiguas.
“It didn’t matter that he was honing his skills on a 10-year-old version of the software because the costs of upgrading are so huge — tens, even hundreds of millions of dollars, or as much as it cost to install the stuff in the first place — that he keeps installing old versions of the software so that it will line up with the old software they already have.”
¿Qué hubiese pasado si cada empresa hubiese podido adaptar o mejorar cada uno de esos módulos en vez de tener que conformarse con hacer cada vez más chapuzas con versiones antiguas o invertir grandes cantidades de dinero? Y aquí traigo a colación a la LEISL, quizás hubiesen evolucionado hacia una pila SOA de forma natural.
Reconozco que lo anterior es pura especulación, pero la realidad es que hay evidencias serias de que los ERP podrían haber sido un gasto inútil de tiempo y grandes cantidades de dinero sin que haya habido un mejora y simplificación de los procesos de negocio. Quizás todo lo contrario.
Me decía que él era partidario de pequeñas soluciones específicas para cada problema, y que se comunicaran bien entre ellas.
Esto es lo que precisamente falló en los ERP, era una solución muy compleja y que además generaba una gran cautividad, yo diría que insostenible (y no me explico cómo una empresa, sobre todo las grandes, pueden gastar tanto dinero para convertirse en prisioneros).
El truco está en cómo unir todas esas pequeñas soluciones específicas para que funcionen en armonía. Yo creo que la única opción es que se agreguen naturalmente y que vayan definiendo sus propias “pilas”, como ha pasado con GNU/Linux y LAMP. Esto no se logrará con la cautividad actual de los ERP privativos –aunque Microsoft lo entendió muy bien en el caso del Windows, que es mucho más “abierto” a desarrollos externos que su propio Navision–
La verdad es que casi me da igual si una empresa usa o no software libre, problemas de ellos. Pero estoy seguro que si hubiesen adoptado soluciones libres –o al menos abiertas– no estarían sufriendo los problemas de dinero y complejidad que tienen ahora. También estoy seguro que un ERP libre hubiese evolucionado de forma muy diferente, quizás hoy el SOA sería lo habitual o estaríamos hablando de “pilas de software de negocio”.
Ahora veremos como las grandes se liberan de la cautividad de SAP, y las medianas y pequeñas del Oracle o Navision. Será divertido, sobre todo escuchar las justificaciones 
Ricardo, yo no creo que siendo libre el ERP lo hubiera hecho mejor, porque creo que el ERP es como el DRM “defective by design”.
Pero dejame preguntarte tu opinión respecto a un problema específico, que tiene que ver con la distinción del software como servicio vs el software como producto.
Hay un servicio en mi país que se llama Bligoo, cuando pregunté si el proyecto era opensource, dado que es liderado por un “conocido promotor” del software libre en Chile, me extraño la respuesta:
“Bligoo no es un programa, es un servicio, el cual utiliza (tanto a nivel de código, como soporte o arquitectura) distintos programas, la mayoría son proyectos Open Source, a los cuales apoyamos y en los que colaboramos. El código desarrollado por nosotros no tiene las características para convertirse en un proyecto Open Source, pero sin duda esperamos que a medida avancemos, parte de nuestros desarrollos tenga utilidad para otros. Aprovechando la ocasión, agradecemos a quienes participan en los siguientes proyectos por la inspiración y el excelente trabajo: Apache 2 - Debian - Dojo - Drupal - Eclipse - FireFox - Hibernate - Jboss - MySQL - Tomcat.”
fuente: http://ayuda.bligoo.com/index.php/Preguntas_Frecuentes#.C2.BFBligoo_es_Open_Source.3F
Si bien uno puede armar un servicio con código propietario, o basándose en software libre, la respuesta me parece insuficiente, e incluso contradictoria con la postura de esta persona (ver: http://www.colonnello.org/content/view/44896/El_dia_de_la_GPL_v3.html).
Como dices tú, el software libre libera el mercado de servicios, pero cuál es el criterio que deberíamo adoptar para liberar el código?
Para concretar un poco más, estas son mis dudas:
¿Que te parece esta actitud? y ¿qué opinión te merece la respuesta de Bligoo?
¿Cuanto se beneficiarían los “servicios” si publicaran su código?
¿No se supone que licencias como la GPL3, y Affero han sido creadas para evitar esta distinción odiosa de no publicar el
código fuente porque se trata de un servicio?
Por último, ¿no se beneficia más un servicio al publicar su código, como el caso de Meneame, por ejemplo?
En lo particular, cuando implanté blogmemes, recibí muy buenos aportes de gente de japón y francia, que no hubiera recibido si hubiera guardado el código fuente para mi propio beneficio, con la excusa de que “sólo se trata de un servicio y no de un programa”.
Comment by Eduardo Díaz — Wednesday 15/8/2007 @ 17:58
Joder, ya decia yo que Agosto no es lo que era.
Un festivo, la gente en la playa, y Sergi y Ricardo currandose megaposts sobre los ERP
Comment by Juan Luis — Wednesday 15/8/2007 @ 18:05
Yo suscribo al 90% lo que dice Toni en http://trespams.com/2007/08/15/va-derps
Por otra parte el tema SOA (a parte de que es como llamarle AJAX al XMLHttpRequest) es una huida hacia adelante para poder mantener bien escondida la “bussiness logic” de la aplicación y abrir una interfaz (XML típicamente) estándar y bien documentada.
Hace 7 años que programé un UI para web que consumía un conjunto de XMLs conocidos que, a su vez, cmandamban a ejecutar los algoritmos a otro sitio. Era muy “guay” porque llevaba bastantes capas que se comunicaban las unas con las otras.
Al final, la capa XML desapareció por dos motivos: el primero porque aparecían las primeras APIs para crear Web Services y el segundo porque la única UI que consumía ese XML era la de la aplicación. Ergo, era más facil consumir el algoritmo directamente.
La idea no era mala. El chocolate espeso. A veces, lo más simple es bueno y lo bueno es enemigo de lo mejor.
Y a pesar de todo eso hace años (como 8 ó 10) que oigo cómo las empresas de internet se convertirán en proveedores de bussiness logic y los clientes pagarán para ejecutar sus algoritmos. Lo más parecido que he visto a eso han sido los scriptlets de google que utilizan ¡¡JavaScript!! y XML, lejos de aquellas vendidas de moto “Enterprise Edition” del momento. Tampoco he llegado a ver un Application Server Provider (a.k.a. ASP, evolución natural de los ISP) que haya funcionado.
Resumen: Desarrollo a medida y código en casa del cliente (libre o no) para que haga con él lo que le plazca. Ahorras tiempo y dinero y tus huevos están siempre en tus manos, no en las de los demás.
Comment by Paco Ros — Wednesday 15/8/2007 @ 20:26
Enga, ahora no hago post
Ricardo, simplemente matizar que a con lo del escenario ERP libre vs ERP propietario me refiero en el contexto de empresa. Mi yo programador tiene clarísimo qué prefiere, pero si tengo que recomendar a una empresa una aplicación de gestión del tipo que sea, sólo buscaré una cosa: que implantar no se convierta en una sangría económica.
Desgraciadamente a la empresa muchos de estos debates les quedan lejos. La mayor parte de los casos que yo he vivido lo único que han pedido es poder funcionar sin riesgo de quiebra porque lamentablemente implantar un ERP no es una experiencia agradable a día de hoy, sobre todo desde dentro de la empresa, y da igual que el ERP se llame XXXXXX.
En cuanto a lo que comenta Paco Ros, no, la solución no es código a medida para cada cliente, al menos mi experiencia no es esa. Las PYMEs están hartas de programas hechos a medida y que al cabo de 5 o 10 años el programador que lo desarrolló ha desaparecido, o la herramienta ya no compila con ningún IDE actual, y se encuentran con aplicaciones que nadie quiere modificar o que nadie puede. Y ahí entramos otra vez en la rueda, que es, que llega el nuevo consultor o informático y dice “todo a la basura” y a empezar de nuevo.
Es por eso que yo pienso que esencialmente el debate -para la empresa- no está en ERP libre vs ERP propietario, sino más bien en calidad del software o en el propósito del mismo. Los ERPs que yo he vivido no están pensados para compartir información, ni para integrarse con absolutamente nada, y daba igual que tuvieras acceso al código fuente o no, porque ahí es donde falla todo. No me refiero a hacer un informe, sino a interfaces para poder generar facturas, órdenes de fabricación o envíos desde aplicaciones externas. Los ERPs tal cual los conocemos son en su mayoría cajas negras. Si fueran libres podríamos modificarlos más fácilmente, eso nadie lo discute.
Comment by Sergi — Wednesday 15/8/2007 @ 21:24
Sergi, en el tercer párrafo, no por obvia, dices una verdad como un castillo
Comment by rwx — Wednesday 15/8/2007 @ 22:52
#1
> Ricardo, yo no creo que siendo libre el ERP lo hubiera hecho mejor, porque creo que el ERP es como el DRM “defective by design”.
> ¿Que te parece esta actitud? y ¿qué opinión te merece la respuesta de Bligoo?
Aunque no la comparto del todo, no creo que estén equivocados. La distinción entre “software” y “servicio público” que se ejecuta en un ordenador que no es tuyo es clara y reconocida por la FSF o RMS. Otra cosa distinta es que genera nuevos dilemas, como si debería ser libre o no, o qué pasa con el código que se ejecuta en tu ordenador (el Javascript).
Pero además hay otra más importante que el código, ¿qué pasa con tus datos? Yo diría que en cualquier caso los datos generados por el usuario deben estar siempre disponibles para ser exportados y migrados a otro sitio. Además por supuesto de asegurar su privacidad.
> ¿Cuanto se beneficiarían los “servicios” si publicaran su código?
Creo que en general el beneficio es siempre positivo, pero parece que no hay mucha cultura y know-how de cómo hacerlo correctamete.
> ¿No se supone que licencias como la GPL3, y Affero han sido creadas para evitar esta distinción odiosa de no publicar el código fuente porque se trata de un servicio?
La Affero sí, la GPL 3 no. Por eso ahora sacan la GNU Affero GPL versión 3, que es la GPL3 más la cláusula de publicación en sitios web: http://gplv3.fsf.org/agplv3-dd2-guide.html
>Por último, ¿no se beneficia más un servicio al publicar su código, como el caso de Meneame, por ejemplo?
Para mí sí, aunque no he recibido demasiadas contribuciones de código “puro”, sí que recibí muchas en correcciones de bugs importantes de seguridad (que además de mejorar el código me han hecho mejorar a mí, aprendí un huevo con este trasto del menéame).
Comment by gallir — Thursday 16/8/2007 @ 2:10
#4 (y #5) Partís de la base de que:
- El programa se ha desarrollado usando un IDE (no libre, por supuesto)
- Que el cliente realmente quiere un nuevo software
- Que, a veces, es mejor tirar lo viejo y hacer uno nuevo (de acuerdo)
- Que el “consultor” es un vendedor de motos.
El cliente para el que trabajo en un 99% de las ocasiones tiene todo el código fuente de sus aplicaciones. Y más de una vez he tenido que modificar aplicaciones de terceros; antiguas con librerías desfasadas… pues se hace y punto. No es tan problemático.
Además, ¿Cómo justificáis que los ERP (sobre todo los no libres) resuelvan estos problemas?
Yo no digo que los ERP no resuelvan problemas. Digo que en muchos casos la implantación de un ERP no está justificada y un desarrollo a medida (y libre) saldría mucho más barato en todas sus fases.
Comment by Paco Ros — Thursday 16/8/2007 @ 2:17
#7, efectivamente, hay gente tan lastrada por el modelo privativo que se les hace imposible asumir que se puede tener el código fuente. Es extraño, porque debería ser lo normal: si has pagado por un desarrollo a medida –que es lo que propones en #3– debes disponer del código fuente.
Comment by gallir — Thursday 16/8/2007 @ 2:21
#7 Paco, no entiendo que concluyas esos 4 ítems de mi comentario, me lo he releido pero no iba por ahí. Lo que he planteado es simplemente que para la empresa lo primordial es no morir intentando implantar el ERP, y hablo estrictamente a nivel económico. Eso no tiene que ver con software libre, entiendo perfectamente las ventajas del software libre, pero también hay que entender que libre no es sinónimo de “implantación gratis”.
De todas formas en la generalidad nos perderemos, el escenario depende mucho del tamaño y tipo de empresa. Varía mucho si la empresa es fabricante o distribuye, si tiene múltiples sedes, si tiene filiales o es una filial, si es exportadora, en qué sector está… Hay muchos factores como para que encontremos la piedra filosofal aquí y ahora.
#8 Ricardo, claro que si te han hecho un desarrollo a medida tienes que tener el código fuente, no creo que eso lo discuta nadie.
Y por supuesto que es mejor que el ERP sea libre, aunque siga pensando que en el cliente final ese no es el debate básico. Para nosotros como consultores trabajar con soft libre resuelve un montón de problemas: acceso al código fuente, modifica a tu gusto, libertad de elección de con quién trabajas, no es necesario que además los programadores estén certificados hasta las cejas, etc. Eso no es discutible.
De todas formas, es que esto de escribir se me da fatal, me enrollo como las persianas y acabo diciendo tonterías
y entre el día que es, y a las horas que escribo de esto no puede salir nada bueno 
Comment by Sergi — Thursday 16/8/2007 @ 3:39
> De todas formas, es que esto de escribir se me da fatal, me enrollo como las persianas y acabo diciendo tonterías
y entre el día que es, y a las horas que escribo de esto no puede salir nada bueno
Pero alerta, yo no digo que el ERP _deba_ ser libre, porque quizás nunca exista uno como un SAP o Navision. Sino que el ERP es demasiado complejo –como lo indica el estudio yu el sentido común– y sumado a su carácter ultra-mega-propietario hace que no pueda salir nada bueno de él a largo plazo.
Yo también creo en las pequeñas soluciones integrados con un sistema de base e intercambio de datos bestial. Creo que se han preocupado demasiado de solucionar la lógica -en plan bestia- y han dejado como “colateral” al tema de datos.
Comment by gallir — Thursday 16/8/2007 @ 3:43
¿Si los ERP son tan malos…? ¿Cuál es la alternativa y por qué nadie la usa?
Comment by Dr. Farolo — Thursday 16/8/2007 @ 9:39
Por mi propia experiencia.
Los ERP como herederos de los “legacy” han sido siempre muy complejos y por la propia incercia del mercado los grandes cautivadores se han hecho con todo el pastel.
Yo intente una temporada hacer negocio con Compiere aquí en Baleares y sin ningún éxito
Comment by miguel — Thursday 16/8/2007 @ 12:34
Sorry corte el post sin querer
Casí todos los intentos de venta chocaban con el mismo argumento.
“Hemos pensado en poner SAP pero los costes se nos disparan”.
“Nuestra estructura es muy compleja y necesitamos una herramienta lo mas flexible posible”
->SAP flexible? Si a coste de talonario.
“Como es un punto critico no podemos jugarmosla y el necesitamos una empresa capaz de darnos un soporte fiable”
“Solo una empresa como SAP o Oracle puede hacer una producto que se adapte a nuestras necesidades”
“Hemos pensando en poner Oracle que es la competencia de SAP pero los costes se nos disparan”
“Ahora utilizamos facturin++”
Y vueltas y mas vueltas sobre el circulo.
Necesitamos cambiar -> Complejidad excesiva -> Coste elevado -> Necesitamos cambiar
Con este panorama mejor nos hubiera ido vendiendo abanicos
Comment by miguel — Thursday 16/8/2007 @ 12:40
Gracias RIcardo por tu respuesta.
Creo que has deslizado una observación importante en tu respuesta, muchas veces las contribuciones a proyectos libres, como meneame, corresponden a correccionesde bugs y seguridad, y eso es muy valioso, para el desarrollador y por supuesto para los usuarios.
Nuevamente gracias por tu tiempo para responder.
Comment by Eduardo Díaz — Thursday 16/8/2007 @ 16:54
Creo que al final no servirá de nada todo eso..
Comment by FotoZone — Thursday 16/8/2007 @ 18:52
En agosto del 2006, un comediante norteamericano, Stephen Colbert aprovechaba su show de televisión para hacer un experimento similar. El resultado fue que lo banearon.. Harán lo mismo con estos canales de televisión?
http://news.com.com/8301-10784_3-6102088-7.html
Comment by cvander — Sunday 19/8/2007 @ 7:00
Ricardo, disculpa que este comentario quedo perdido en esta nota.. Era para el último tema de la wikipedia, pero esto me pasa por ponerme a leer varias notas y luego comentar.
Comment by cvander — Sunday 19/8/2007 @ 7:07
Estuve varios años trabajando como colaborador principal del responsable interno de la implantacion de Microsoft Axapta (ahora Microsoft Dynamics Ax) en un subcontratista de Airbus que fabrica componentes aeronauticos. Se trata de una empresa que en aquellas fechas tenia unos 120 empleados y unos 1500 millones de pesetas en facturacion aunque con unos margenes muy cortos (en torno al cinco por ciento).
Los problemas que observe fueron los siguientes:
1 El coste de la implantacion es brutal para una empresa de este tamaño, no solo los costes iniciales, sino los periodicos. Esa gente cobraba por absolutamente todo. Algunas cosas sin sentido, por ejemplo el numero de usuarios concurrentes esta limitado. La empresa habia pagado por tener seis usuarios concurrentes. En la practica esto significaba que unos usuarios tenian que andar cerrando sesiones para que otros pudieran entrar. Increible. En vez de soluciones nos daban problemas. Recuerdo que la empresa llevaba pagados en aquellas fechas mas de treinta millones de pesetas y no quiero pensar por donde andaran ahora.
2. La documentacion del producto era pesima por insuficiente. Tanto la funcional como la de desarrollo (solo se documentan bien las principales clases). Habia papeles en cantidad pero ni de lejos cubrian el nivel de detalle necesario. Todo a base de consultor externo. Los consultores externos andaban tambien cortitos de material (eso se nota). Nosotros (el personal de la casa) pasabamos la mayor parte del tiempo parametrizando modulos en el entorno de pruebas para ver lo que hacian y extaer conclusiones. Increible pero cierto.
3. La resistencia al cambio. Creo que es un problema comun a todas las implantaciones por lo que no comentare nada mas al respecto.
4. La base tecnologica propietaria. La empresa se “casa” con Microsoft a todos los efectos. El cliente de la aplicacion solo funciona sobre windows. El servidor de la aplicacion y el de base de datos tienen que estar sobre windows. Los base de datos tiene que ser Sql Server. Esto significa que para tenerlo todo legal tienes que pagar licencias de windows por cada cliente, por el windows de cada servidor, por el numero de usuarios concurrentes del erp, por el mantenimiento etc… El coste de licencias es elevado pero no cabe duda de que hay otro coste y es el de estar atado a utilizar tecnologias que no son las mejores en cuanto a rendimiento. Todo el mundo sabe del superior rendimiento que ofrece mysql respecto de sql server o Apache respecto de IIS, por ejemplo. Por cierto si quieres hacer accesible el erp desde la web tendras que utilizar un internet information server y paginas asp.
Si tengo que destacar algo como lo peor esto seria la insuficiencia de documentacion.
Como nota positiva, destacar el lenguaje de programacion utilizado que esta claramente inspirado en java y al que resulta muy facil adaptarse. Tambien resulta facil la creacion y programacion de formularios aunque no tanto la de informes.
Comment by Fernando — Sunday 19/8/2007 @ 21:09
Las soluciones ERP tradicionalmente han intentado agrupar las “mejores practicas” de los negocios en soluciones completas a la par de complejas. Debido principalemente a que ningun negocio funciona igual al otro. Una empresa puede vender o dar servicios de mil maneras, algunas aun inexploradas, para la cual una solucion ERP puede o no adaptarse hasta cierto grado. Y es casi imposible para una empresa, sin llegar a infringir en las licencias de uso extender “in house” esos sistemas si el proveedor no es el que lo hace directamente, resultando en una cautividad del proveedor (vendor lock-in) lo que implica poner una cota maxima a la eficiencia de la empresa impuesta por la propia eficiencia del proveedor de ERP.
Por otra parte las arquitecturas de los ERP, generalmente monoliticas, no resuleven todos los problemas de las empresas, muchas con infraestruturas complejas, organizaciones distintas, enlaces o parcialmente conectadas a los gobiernos, etc. Por lo que soluciones mas moldeables, ubicuas y configurables (aparejado a toda la madeja de interoperabilidad) a la larga se impondran. Ahi es que el SWL tomara cartas en el asunto, cuando existan soluciones de este tipo y que ademas incluyan las bondades de costos, capacitacion y soporte caracteristicas del SWL.
Comment by Ernesto Freyre G. — Wednesday 22/8/2007 @ 19:10
Diseño y evolución…
Sólo conocemos dos modos de construir cosas extremadamente complejas. Una es mediante ingeniería, y la otra mediante evolución.
Esta cita se debe a Daniel Hillis. La nombro en relación a una entrada sobre si es relevante o no que un ERP sea libre…
Trackback by Born to be geek! — Thursday 11/10/2007 @ 1:25
[…] cita se debe a Daniel Hillis. La nombro en relación a una entrada sobre si es relevante o no que un ERP sea libre (definición de […]
Pingback by Born to be geek! » Diseño y evolución — Thursday 11/10/2007 @ 1:27