Este artículo no versará sobre la eterna discusión entre si usar software libre o software privativo, sino sobre la dictadura del software sea libre o privativo -pronto aclararemos su significado-. Ya sé que es un tema recurrente el enfrentar a ambos como si fueran enemigos irreconciliables. Creo que ambos tienen cabida sin ser excluyentes y pueden convivir en perfecta armonía incluso en los mismos nichos de negocio, pero eso será tema de otro artículo.
Si nos vamos al software de ofimática, nos encontramos, que a pesar de la dura competencia que pueda existir entre ellos, de alguna forma existe posibilidad de compatibilizar formatos entre los distintos fabricantes. A pesar que los pioneros suelen ser los que marcan la tendencia y la estandarización del formato, es evidente que para dar la posibilidad de uso de las distintas plataformas, se asume que se debe permitir la compatibilización entre esos distintos formatos. Para entendernos, si Microsoft Office, para sus hojas de cálculo estableció el formato de los ficheros como .xls, cualquier competencia pasa por hacer compatible sus ficheros con MS Office. A su vez, con el crecimiento de OpenOffice, LibreOffice, etc, es entonces Microsoft quien debe mover ficha y permitir abrir ficheros con el formato OpenDocument. Finalmente, gana el usuario dada la libertad de formatos.
Sin embargo, este «convenio» que asumen los distintos fabricantes de software de ofimática, no se da en otros sectores como los fabricantes de ERP. Puede parecer algo absurda la propuesta, pero la realidad es que uno de los procesos más complejos y tediosos que se requiere en la implantación de un ERP es la migración de los datos o cualquier comunicación no solo bidireccional, sino incluso unidireccional. En ocasiones nos encontramos clientes que piensan que se va a migrar todo su histórico al nuevo sistema, y en el mejor de los casos, que se migrará toda la información maestra, aunque algunos ficheros contengan dos registros.
La estructura de datos que cada fabricante diseña para su sistema ERP posee unos criterios propios y únicos, y en ocasiones, aunque no debería, influidos por la base de datos y por el propio lenguaje de programación. Esto conlleva una dispersión muy grande debido a una falta de normas y estándares que rijan un diseño adecuado y compatible entre distintos fabricantes de ERP.
Existe algunos intentos de estandarización como EDIFACT, uno de los formatos de la ONU en que puede darse el Intercambio Electrónico de Datos (EDI) para documentos comerciales y sobre el que ya hablamos en un artículo anterior sobre estandarización e integración. A pesar que un gran número de ERP’s están adaptados para la recepción y envío de documentos a través de este estándar, ninguno de ellos prácticamente se estructura según ese estándar, lo que complica las adaptaciones y la comunicación entre ellos. Es decir, ese estándar se usa como plataforma común de comunicación entre sistemas ERP’s totalmente incompatibles pero ellos mismos no siguen la estructura marcada por EDIFACT.
Un paso más allá, este tipo de estandarización es del todo insuficiente, pues la compatibilidad entre otras estructuras de datos tan importantes como clientes, artículos, listados de materiales, tarifas, hojas de ruta de fabricación, etc., son inexistentes. Alguien podrá objetar que es imposible tener un estándar multisectorial, y así es, pero siempre será mejor partir de un estándar general del que surjan adaptaciones sectoriales, que no tener ningún tipo de normalización.
De esta diferenciación e imposibilidad (o dificultad) de comunicación entre los distintos software ERP, surge la fuerza de los fabricantes y lo que denominamos dictadura del software, aunque en términos más objetivos deberíamos denominar la dictadura de los fabricantes del software. Esa dictadura del software se hace más evidente cuando además, las propias empresas se niegan a realizar interfaces de «comunicación» con otros sistemas.
Un estado utópico, pues dudo que exista el software ideal, sería poder trabajar con unos módulos de un ERP, otros módulos de otro, un CRM de otro fabricante, un BI de otro… y que los flujos de trabajo y datos fuesen transparentes a todos ellos. Solo en este caso dejaremos de hablar de la dictadura del software y podremos hablar de la libertad del software. Otras cuestiones a considerar entonces sería:
- ¿Se dispararía los costes de implantación?
- ¿Serían los niveles de seguridad mayores o se producirían más agujeros de seguridad?
- ¿Se demoraría la implantación de un sistema ERP?
- ¿Se multiplicarían los costes de mantenimiento?
- ¿Cómo serían las actualizaciones? ¿Independientes?
- …
En contraposición a la dictadura del software, ¿es la libertad del software una utopía?
Y tú, ¿qué opinas?
Autor: Sergio Martínez
Recibe nuevos artículos mediante suscripción por e-mail, RSS o Feedly |
|
Si todos los ERP’s fuesen compatibles en estructura de datos, serían de igual funcionalidad, ya que la funcionalidad viene implicitamente data por el diccionario de datos.
Asi, aplicaciones como SAP la cual creo que es la que mayor diccioanrio de datos tiene de todos los ERP’s existentes seria el estandar? y los demas ERP’s (incluso los pequeños para pequenas tiendas) deberian soportar ese estructura de datos?
No creo que eso vaya a ocurrir, la verdad, ni veo en esto una dictadura en lo que a ERP concierne.
Muchas gracias Carlos por tu aportación.
Efectivamente es cierto que la estructura de datos condiciona la funcionalidad, pero ésta no lo es todo. Es increíble la cantidad de funcionalidad que se puede añadir a un sistema sin tocar esa estructura, por lo menos eso es lo que me encuentro en el día a día. En cualquier caso, sí tienes razón que es un porcentaje muy elevado.
El resto es una pregunta abierta, y no confío mucho en que los fabricantes de software tiendan a abrir o compatibilizar su estructura de base de datos a formatos normalizados, entre otras cosas por el coste que implicaría aunque existiera y porque de alguna forma estarían perdiendo control sobre su producto.
Muchas gracias, de verdad, por tu aportación.