Ahora empiezan a verse los problemas del ERP
Nicholas Carr hace un breve comentario sobre los problemas del ERP a partir del estudio The Trouble With Enterprise Software en MITSloan.
Aunque dije que escribiría sobre ello mañana, con más tiempo y las neuronas en un estado menos pésimo que lo habitual, pero no pude reprimirme.
A mí me parece que es una especia de catástrofe anunciada. Desde mediados de los 90, cuando ya era notable la forma en que Internet estaba cambiando de forma radical nuestra forma de usar los ordenadores y de interactuar con las personas (y clientes), las grandes empresas se lanzaron a gastar enormes fortunas a su propia “revolución” del negocio, los ERP.
Aunque sólo se trataba de una aplicación de las arquitecturas cliente-servidor, las modularización (como la que conocemos en Unix desde hace casi 40 años) y las ideas de las hojas de cálculo aplicadas al software de gestión de las empresas.
La promesa era que ya no había que programar casi nada, sencillamente había que instalar y configurar los módulos adecuados y “personalizarlos” casi como si se tratasen de hojas de cálculo.
La realidad fue mucho más compleja, los principales problemas según el estudio son:
Se tardaba muchísimo tiempo en ponerlos en marcha por la complejidad de la “personalización”.
Se gastaban fortunas en consultores externos que hacían dicha instalación.
El 75% de los proyectos de instalación de ERP fallaron, tanto que acabar con la puesta en marcha ya era considerado un éxito en sí mismo.
Se han dado cuenta de la exponencialmente creciente complejidad del software, que la idea de tratar módulos de software como piezas de Lego es imposible.
Aunque en el estudio no lo mencionan hay otro problema fundamental, las empresas se volvían cautivas de sus proveedoras de software (fundamentalmente SAP y Oracle). Sumado a que estos programas son privativos, de millones de líneas y que el panorama informático estaba cambiando radicalmente, se tiene la receta perfecta para la catástrofe a medio plazo.
Pues parece que eso está ocurriendo, y aunque muchos plantean que la solución es la nueva palabrota de moda, el SOA (Services Oriented Applications), parece que tampoco se libra de sus problemas. Estos sistemas SOA heredarían y mezclarían código de los ERP aumentando así su complejidad –y yo diría también la cautividad–.
Pero lo importante del estudio es que de alguna manera formaliza el problema: aunque estaban diseñados para reemplazarlos, los ERP ya son parte de los sistemas legacy (heredados) de las organizaciones. Pero además han agregado aún más complejidad después de gastarse fortunas.
Se acercan años de justificaciones y cambios importantes en los departamentos. Carr dice que tampoco sabe la solución, yo creo que hay pistas por dónde irán las cosas. Una de ellas es que el “tratamiento masivo de datos” es un área “caliente” de investigación e incluso de negocios: es el fundamento de Google –que lo lleva al extremo de hacer altamente distribuido, replicado y auto recuperable–, y de casi todos los nuevos sitios sociales o Web 2.0 (aunque estos en mucha menor escala).
Quizás dentro de unos años veamos que además de lo que está enseñando Google a los conservadores informáticos de “empresas”, lo que hoy conocemos como Web 2.0 también dejará su contribución (sino basta mirar los problemas y soluciones ad hoc de bases de datos en Technorati, Wordpress.com, Facebook, Digg, Twitter… [1]):
No te preocupes tanto de los programas y algoritmos como de la forma en que almacenas y recuperas una enorme cantidad de datos, con latencias mínimas y alta disponiblidad.
A los estudiantes que me preguntan les digo siempre que se dediquen a estudiar a arquitecturas y organización de bases de datos orientadas a tratamiento de enormes cantidades de datos.
[1] Menéame no es comparable en volumen de datos, aunque también una cantidad considerable –12 millones de votos, 1 millón de comentarios, 200.000 noticias…– y los requisitos de tiempo de respuesta son similares –incluso más estrictos– y con 800 consultas por segundo de media a la base de datos.
El software libre esta cambiando esto: http://www.principiolegal.com/software/erpcrm.php
Y creo que la clave que haga que se estandarize el tema sea la factura y contratos electrónicos:
Hay un proyecto español: https://www.tractis.com/
Comment by Taikochu — Wednesday 15/8/2007 @ 4:04
Malditas aplicaciones legacy, y cómo las empresas están pilladas de los huevos por el proveedor, por no tener ni puta idea de lo que les venden.
La culpa, como casi siempre en este sector, por la visión cortoplacista. “La mejor solución para este ejercicio fiscal te va a joder vivo de aquí a 6 años, estúpido” xD.
Comment by DZPM — Wednesday 15/8/2007 @ 5:20
La mejor solución implementada hasta el momento para bases de datos _realmente_ grandes son motores orientados a columnas.
A diferencia de los motores relacionales de toda la vida (desde Oracle a MySQL) que almacenan la información fila a fila, éstos almacenan tuplas clave-valor de tal manera que no hace falta recuperar toda la tabla para hacer operaciones agregadas sobre una o varias columnas.
Hay un proyecto libre llamado Monet que es puntero en estos temas. Su principal problema es que devora la memoria RAM ya que necesita cargar cada columna en memoria antes de tratarla (y para tablas de cientos de millones de filas eso es mucha RAM).
En el apartado privativo, la única solución seria es Sybase IQ. que tiene un rendimiento espectacular. Realiza la mayoría de las operacioness básicas SQL sobre una tabla de 650 millones de filas en menos de 10 segundos.
Comment by Guillelle — Wednesday 15/8/2007 @ 12:00
#3, el problema de estas soluciones es que necesita cargado en memoria. No le veo demasiado adecuado para cantidades masivas de datos (a menos que tenga soluciones sencillas de particionado).
Por otro lado, desde el punto de vista web y aplicaciones interactivas, 10 segundos es demasiado. Google hace todas sus consultas en bases de datos de miles de millones de filas en pocas décimas de segundo. Por aquí va el tema.
PS: Otra cosa son las consultas OLAP (On-Line Analytical Processing), en este caso los 10 segundos son más que aceptables.
Comment by gallir — Wednesday 15/8/2007 @ 13:23
Yo estoy trabajando en una herramienta ERP libre que es OFBiz (Open For Business) detrás de la cual está ahora Apache y que creo que podría ser solución a varios de los problemas que consideras. De todas formas mi conocimiento es poco profundo ya que solo he hecho un mes de becario (por ahora) y simplemente me dedico a hacer nuevas funcionalidades a un programa ya en funcionamiento. De todas formas, teniendo una idea así a grandes rasgos de OFBiz me parece un ERP muy interesante y que da bastantes posibilidades.
Comment by morri — Wednesday 15/8/2007 @ 15:53
[…] a comentar en el blog de Ricardo Galli pero al final he creído mejor hacerlo en un apunte ya que me estaba enrollando demasiado. El […]
Pingback by Sobre los problemas de los ERPs by Tecnorantes — Wednesday 15/8/2007 @ 16:38
[…] 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 […]
Pingback by Ricardo Galli, de software libre » Sí que es relevante que un ERP sea libre — Wednesday 15/8/2007 @ 17:39
[…] Ahora empiezan a verse los problemas del ERP de Ricardo Galli de Software libre. Afortunadamente cada vez hay menos gente que continúe pensando que se puede comprar el “know-how” y la experiencia a base de talonario. Falta un libro con casos reales de batacazos a alto nivel… estaría entretenido para el verano… […]
Pingback by Lo que me ha llamado la atención durante la semana (2007/33) | Jordi Planas Manzano — Sunday 19/8/2007 @ 20:44
Obviamente el problema de raíz es la falta de uniformidad en los procedimientos de los procesos de negocio y en los formatos de datos - eso es lo que impide que un enfoque basado en componentes y módulos “configurables” no sea “tan maravilloso” (por cierto, la alternativa, que es hacer un desarrollo a medida NO es la panacea ni la solución, porque al final acaba teniendo los mismos problemas de costes y dependencias, éstos últimos incluso peores)
El software libre no creo que sea diferente al propietario en cuanto a esta problemática de costes sobrepasados, dependencias y expectativas no cubiertas.
No obstante, en mi opinión, en el futuro pueden cambiar las cosas para mejor por varias razones:
* Emergencia de estándares promovidos por la industria y organizaciones sectoriales, tipo AECOC, en formatos de documentos basados en XML
* Consolidación de las soluciones basadas en SasS que facilitarán la adopción de procedimientos comunes y la integración de los datos entre empresas (si comparten sistema y éste es bastante estándar, es más fácil integrar). El maridaje entre SaaS y software libre es el tema de un post que estoy barruntado hace tiempo
* Consolidación del SOA como filosofía que inspira las nuevas arquitecturas tecnológicas de los diferentes productos. En realidad tampoco es algo realmente nuevo, al fin y al cabo hace ya tiempo que se inventó lo de “encapsular” en “cajas negras” y así facilitar la integración.
* Extensión de las “mejores prácticas” entre las empresas del mismo sector. Aquí saco pecho, porque los consultores contribuimos bastante a ello (aunque sea a base de copy&paste, todo sea dicho)
Comment by Luis-tic616 — Monday 3/9/2007 @ 19:37