]]>
Iba 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 artículo habla de los problemas de los ERPs en base a este estudio [vía].
Voy a dar mi punto de vista habiendo estado en ambos lados, tanto como informático de empresa involucrado en selección de ERPs, como de consultor intentando vender este tipo de aplicaciones.
Desde luego cuando se vende un ERP el objetivo fundamental del consultor es transmitirte que el ERP es fácil de instalar, configurar, adaptar, personalizar, etc. La primera tanda de problemas sucede en el proceso de selección, que suele tener fallos: la empresa no dedica tiempo suficiente a la selección, no asigna a las personas que realmente deberían hacerla (es frecuente por ejemplo, que en la selección intervengan personas lejos de los requerimientos), y sobre todo, que las personas que atienden a las demos no preguntan lo que deberían.
En este sentido, no se exactamente por qué razón los asistentes a las demos suelen comulgar con cualquier cosa que se les dice. Igual no te compran, pero en ese momento, parece que estés haciendo magia en frente de un proyector, y desde luego con la ayuda de Photoshop, Powerpoint y un poco de enseñar el programa las demos quedan de lo más efectivas, pero lejanas de la realidad. Yo les diría a las personas que atiendan a este tipo de demos que no se crean nada, y mucho menos si el consultor les dice que “están desarrollándolo” o que “lo tendremos acabado el mes que viene”. Ah!, y si se les vende que un porcentaje importante de su sector usa esa solución, difícil será que alguien de su empresa no conozca a alguien de una empresa con ese software, así que, aprovechen para preguntar qué tal es el software, cómo responde la empresa, etc.
Volviendo al artículo, estoy de acuerdo con los principales problemas, y diría que los que lastran todos los proyectos de implantación son principalmente el 1º (”Se tardaba muchísimo tiempo en ponerlos en marcha por la complejidad de la personalización”) y el 2º (”Se gastaban fortunas en consultores externos que hacían dicha instalación”). En cuanto al primero, la cabezonería influye mucho en este problema, ya que cuando una empresa tiene 50 empleados que durante 15 años han hecho una cosa de determinada manera, si no tienes apoyo de la dirección y, más importante, de los mandos intermedios, implantar va a ser un auténtico infierno. En cuanto al segundo, obviamente esto de los ERPs es como los coches, el beneficio para la empresa que te lo vende no está en el coche, sino en las horas de taller que te pueda vender.
SOA es posiblemente la solución pero tampoco la panacea bajo mi punto de vista, no por si misma, sino por el escenario actual, al menos en España. Los proveedores de software tienden a trabajar para crear cautividad, y esto no es una excepción. Compartir datos como mucho con el Excel, o bien si el programa no entra en el escenario de mi competencia actual y/o futura, sino, nombrar la palabra “integración” puede producir sarpullidos. Hace algunos años trabajé en escenarios de integración, y no vi jamás ningún ERP que facilitara mínimamente la vida en la exportación e importación de información, siempre accesos a base de datos, a pelo, sin garantía. En este sentido, una de las cosas que más se ha machacado en esta época ha sido el EDI, que al igual que muchas otras tecnologías parece que debía morir por el simple hecho de ser antigua. Pero EDI sin embargo tiene una cosa que es muy importante, y es que “enseña” a las aplicaciones que compartir información es bueno, y si es con mensajes estandarizados mucho mejor.
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. Obviamente los proveedores van buscando la cautividad, y en esto el líder es Microsoft, que tras comprar Navision, se encuentra actualmente en un proceso de migración hacia SQL Server y plataforma .NET, además de vender una integración con otros productos como Office System 2007 o SharePoint, de manera que cuando entras en esa rueda estás más que atado hasta los restos con Microsoft. Lo mismo sucederá, en mayor o menor medida con otros proveedores.
Como decía, libre o propietario, el escenario no cambia esencialmente. La cuestión es que elegir un ERP es una decisión vinculante. Posiblemente con lo que hayas elegido, bueno o malo, vas a pasar los próximos 10, 15 o 20 años. Y vas a tener que convivir con ello. 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. Y eso es lo que las empresas pretenden evitar, que el tener un ERP sea como un saco sin fondo donde no haces más que meter dinero para intentar mantenerlo a flote.
Yo tampoco veo una solución clara, depende de muchos pequeños factores. Hace poco hablaba con un antiguo cliente que afrontó una migración hace cuatro o cinco años. Me decía que él era partidario de pequeñas soluciones específicas para cada problema, y que se comunicaran bien entre ellas. Quiero la mejor contabilidad, la mejor aplicación de producción, la mejor de facturación, la mejor de recursos humanos, y que se comuniquen entre ellas. En lugar de una mega-aplicación que lo controle todo, aislar los problemas. Es muy próximo a lo que mencionaba antes de SOA, pero como decía, nadie está por la labor. De hecho acabó comprando un ERP que cubre toda la funcionalidad que necesita para todas las áreas de la empresa, pero como él dice, todas mal.
¿Quieres patrocinar Tecnorantes? Mas info aquí
13 Respuestas
Ricardo Galli, de software libre » Sí que es relevante que un ERP sea libre
15th Agosto 2007 a las 4:39 pm
1[…] 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 […]
Ernesto Freyre G.
22nd Agosto 2007 a las 8:11 pm
2No creo que las empresas tengan que atarse 5 o 10 annos a una solucion que les facilite la gestion a todos los niveles. Eso si, si lo que seleccionan es un ERP monolotico, cerrado y propietario probablemente tengan esos problemas. Ya que el costo de implementacion es tan alto que el ROI o retorno de inversion probablemente tenga ese tiempo o mas.
Yo me inclino por los sistemas como su amigo le sugirio, un buen sistema de contabilidad, de facturacion, etc. etc. Que solo hagan su pequenna parte y se integren bien con los demas. Este modelo esta mas que probado en el mundo unix y linux, cuando vez que un software solo hace algo para lo que esta pensado y preparado y programado, no mas, y basandose en estandares harto documentados entonces interoperan con el resto de los software.
combinaciones tenemos muchas:
Samba + Bind + Postfix + dovecot + clamav + horde + squid + sarg => Servicios de Dominio, Correo y Navegacion por Internet.
o mas conocido
Linux + Apache + MySQL + PHP => LAMP => Plataforma de desarrollo de aplicaciones web.
Algun dia veremos
ContaX + FacturaY + RRHHZ + ClientesK + HaciendaL => Plataforma de Gestion de Recursos Empresariales
Dandoles a las empresas la posibilidad de adaptar sus sistemas a sus necesidades y presupuestos.
Saludos
Luis-tic616
3rd Septiembre 2007 a las 6:37 pm
3Obviamente 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)
Sergi
3rd Septiembre 2007 a las 6:49 pm
4En línea de lo que comentas, a mí me produce muchísima curiosidad por qué la mayor parte de ERPs que he conocido no disponían de APIs para introducir un asiento en el sistema o para introducir una factura. Nos hemos acostumbrado a insertar en las bases de datos o a que sean los propios desarrolladores del programa en cuestión los que importen información sin que sepamos cómo lo hacen. Eso como dices es algo que tiene que cambiar, y SOA puede hacerlo.
Luis-tic616
4th Septiembre 2007 a las 11:03 am
5Sergi, no conozco los ERPs con los que has toreado pero me sorprende mucho eso que dices porque en todos los que yo conozco esa “API”, o método de entrada encapsulada para introducir documentos sí que existía: desde los más sofisticados con SOA y Web Services (MS Navision, SAP, Deister) hasta otros menos evolucionados (grabar un archivo de entrada batch) pero no por ello menos efectivos.
Es cierto que a medida que un ERP se hace más sofisticado se hace mucho más complicado ya que no es “sólo” grabar una facturita: hay que reclasificar la situación de deuda del cliente, actualizar previsiones de tesorería, lanzar workflows de seguimiento de cobro, grabar un asiento contable, … En los ERPs bien paridos, lo que se hace es que un “evento” como “grabar factura” desencadena el resto de eventos. Hay dos puntos clave en todo eso como te puedes imaginar: granularidad de cada una de las transacciones (para reaprovecharlas de forma aislada) e integridad transaccional del conjunto. Al final, si te fijas, desde un punto de vista técnico es un tema de arquitectura de software. No perdamos de vista que esa es la base fundamental: sea Open o Closed
Saludos y felicidades por el blog
Luis-tic616
4th Septiembre 2007 a las 11:04 am
6Rectificación: donde dije MS Navision, quise decir MS Dynamics (para englovar a Navision y a Axapta)
Luis-tic616
4th Septiembre 2007 a las 11:04 am
7EngloBar va con “B” evidentemente
Sergi
4th Septiembre 2007 a las 11:12 am
8> Sergi, no conozco los ERPs con los que has toreado pero me sorprende
> mucho eso que dices porque en todos los que yo conozco esa “API”, o
> método de entrada encapsulada para introducir documentos sí que
> existía: desde los más sofisticados con SOA y Web Services (MS Navision,
> SAP, Deister) hasta otros menos evolucionados (grabar un archivo de
> entrada batch) pero no por ello menos efectivos.
La mayoría de aplicaciones con las que me he topado son programas de empresas pequeñas hechos generalmente para pequeños nichos de mercado, aunque también conozco algo de Dynamics
De todas formas, para mí una aplicación que le tengo que dejar un fichero con un formato dado en una carpeta para que lo coja, no es un modelo aceptable de integración, es como decir “dejame eso ahí que yo ya lo cojo yo pero no mires cómo lo hago”, quiero decir que muchas veces te encuentras con situaciones en las que si quieres hacer algo de integración o incluso de extracción de información, tienes que pedírselo al consultor de turno.
Una cuestión interesante por ejemplo es cómo se gestionan en estos casos las situaciones de error, qué pasa si el programa no te coge el fichero, cómo te comunica que ha habido un fallo y dónde, o cómo te comunica el éxito de una operación, etc.
Queda mucho por recorrer en integración para la mayoría de aplicaciones. La teoría está genial, pero en la práctica a mí me queda la sensación de que va todo como a tirones, y que desde luego los fabricantes de software no tienen ni la más mínima intención ni ganas de favorecer la integración de sus aplicaciones.
Luis-tic616
4th Septiembre 2007 a las 1:03 pm
9Bueno, yo los que conozco es el entorno ERP de empresas de mayor tamaño donde el tema integración suele estar más trabajado.
En lo del fichero de intercambio he simplificado conscientemente y tienes toda la razón con lo de tus consideraciones sobre la gestión de errores y gestión de la transacción- de hecho es el punto débil más frecuente - pero para ello hay gestores de transacción, EAIs, etc. o un buen diseño de arquitectura de la aplicación.
Para extraer información las últimas versiones de los ERPs traen potentes (y no siempre baratas) herramientas que facilitan la extracción de información por parte de los usuarios “de negocio” sin conocimientos técnicos - una frasecita de los vendedores de ERPs para venderlas es “si sabes utilizar el excel sabes sacar y manipular la información”, lo que es una trampa para elefantes. Aún así, es cierto que si no quieres virguerías, no hace falta ser técnico para utilizarlas - yo suelo reformular la frasecita de marras como “si sabes definir y manejar una tabla dinámica de excel, sabes utilizar la herramienta” - se acerca más a la realidad
Sergi
4th Septiembre 2007 a las 1:17 pm
10Las herramientas de EAI suelen estar muy bien, en particular estuve usando una alemana bastante completa durante varios años, pero no creo que el problema esté en esas herramientas, que están muy bien y arrastran una experiencia importante de todo el tiempo que se viene usando EDI.
Realmente la cuestión para mí es por qué los programas de gestión no colaboran. Me refería antes a ERPs para nichos como puede ser fábricas de muebles, cocinas, etc. (excluyendo el mueble “tipo IKEA”) donde las empresas son grandes pero la mayor parte de soluciones ERP son muy “cerradas” en sí mismas.
Lo de las herramientas que facilitan extraer información, totalmente de acuerdo, y sobre todo en lo de que son una trampa para elefantes. Supongo que entre otras te refieres a aplicaciones tipo cuadro de mando, un tema bastante idealizado en mi opinión, ya que no se necesita una aplicación de última generación e inteligencia artificial para que cualquier gerente o director se pueda montar su cuadro de mando.
Born to be geek!
11th Octubre 2007 a las 12:25 am
11Diseñ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…
Born to be geek! » Diseño y evolución
11th Octubre 2007 a las 12:27 am
12[…] Puede parecer que el hecho de que sea libre o no, no es relevante. En realidad, lo que sí es relevante es cómo se diseña el software. Si se ha hecho en un grupo pequeño y controlado, diseñado desde cero conforme a estrictos requisitos, debido a su complejidad, acaba dando lugar a una mala solución. En otras palabras, puede que si es libre o no carezca de relevancia. Pero si se ha construido por ingeniería o por evolución sí que es relevante. Casualmente, la mayoría del software libre se desarrolla por evolución, y la mayoría del software propietario por ingeniería. […]
antonio
29th Noviembre 2007 a las 1:24 pm
13Hola, parece que controlan bastante de Navision. Estoy desarrollando una tienda online para un cliente que usa y ya tiene instalado Navision. Quisiera saber si me resultará fácil integrar mi site con esa aplicacion. El site lo he desarrollado front-end con XHTML y CSS, mientras que el back-end estoy esperando a decidirme por .NET o PHP en base a lo que me pudieran constestar en este foro. Muchas gracias por anticipado.
RSS sindicación para comentarios en esta entrada · TrackBack URI
Dejar una respuesta