Por qué los ERP´s no satisfacen el mercado de transporte y logística

EL debate comienza con la afirmación de que la mayor parte de los ERP's no satisfacen a la industria de la Logística y Transporte.

¿Será una cuestión de usuarios o de proveedores de software y servicios?

Luis Carrasco, Consultor / Gerente de Proyectos en Procesos y Tecnología en Delphin Project Hunting, España, considera que “una de las razones de este desfase es la tecnológica. Por naturaleza, este tipo de negocios tiene una gran dispersión de sus fuentes de datos, lo que los hace especialmente difíciles de gestionar por sistemas transaccionales clásicos como los de los ERPs”. Luis confía en que “con los últimos avances en Bases de Datos distribuidas, modelos SaaS (Software as a Service) y otras mejoras en las telecomunicaciones, corregir esta anomalía será sólo cuestión de tiempo”.

Sin embargo, “según la experiencia de haber tratado con algunas empresas de transporte medianas, pensando que sus propietarios son transportistas, les aseguro que la solución de sus problemas pasa lejos de la tecnología”, asegura Daniel Aisemberg, Director de Evaluando ERP. “Si alguno de ustedes tuvo experiencia con empresas de transporte ¿Qué es lo que a un transportista-empresario lo induce o convence de dejar la libreta manual o el Excel para pasar a implementar un software?”

“Dejando a un lado las eventuales ventajas de mejoras de la seguridad y de la prima del seguro si hablamos de gestión de flotas, creo que la libreta tendrá que quedarse en la oficina en la medida en que los cargadores (sus clientes) les pidan datos precisos -en tiempo real- sobre las mercancías transportadas, con incidencias, confirmaciones de entrega y trazabilidad detallada”, responde José María Peláez, Fundador y Socio de Abilogica, España.

“Creo que, en redes de abastecimiento de demanda (Supply Chain Management) cada vez más globales, se aceptarán cada vez menos los datos al retorno de la ruta cuando finaliza la jornada o la semana de trabajo. Por otro lado, si los transportistas saben con detalle lo que les cuestan los servicios que prestan (operaciones de carga y descarga, tiempos de parada, pérdidas desconocidas, distancias recorridas, intentos de entrega…) podrán tener una rentabilidad analítica de sus operaciones y podrán facturar todos los conceptos a sus clientes”.

José agrega algunas otras razones relevantes, que llevan a las empresas a esta necesidad de cambio, que van más allá de las técnicas:

1.- La mayoría de ERPs emplea la contabilidad como núcleo sobre el que desarrolla sus funcionalidades. Pocos se apoyan en las prácticas de planificación de la producción y sus aprovisionamientos. Y muy pocos lo hacen en el proceso de satisfacción de la demanda jugando con los proveedores y los productores, que entiendo, sería el más natural.

2.- La concepción de los ERPs suele basarse en las reglas aplicables a la gestión de una organización, que controla y trata de hacer estable. Un operador de transporte o logística debe trabajar más con las reglas operativas que demandan sus clientes en función de sus mercados, que son muy variadas y cambiantes.

3.- Una empresa de transporte y logística es parte de una red de suministradores y clientes (o la promueve) que debiera usar muchos datos compartidos. Además de las cuestiones técnicas, creo que el diseño funcional del ERP ha de contemplar también la necesidad de actualización compartida y sincrónica de dichos datos desde el exterior del "cortafuegos".

Según el especialista, “la mayoría de las empresas del sector desarrollan aplicaciones a su medida, por un equipo interno o externo, por estos motivos. Por un lado el adaptar los paquetes estándar más conocidos es un proceso lento y caro, y tampoco les da el control. Por otro, sucede que los pocos sistemas menos conocidos que se pueden adaptar mejor no les merecen suficiente confianza como para depender de ellos en una parte crítica de su negocio”.

Pero también sucede que “desarrollar a medida algo bien hecho es complejo y, por consiguiente, también es lento y costoso. Además, tiene un riesgo considerable. El operador de transporte y logística intenta dedicar cada vez más presupuesto a su desarrollo propio, pero sus márgenes operacionales —y los tiempos de reacción ante las peticiones de nuevas funcionalidades (de los usuarios internos y de los clientes) se lo impiden. No me parece extraño que luego haya bastantes que estén descontentos con lo que han intentado desarrollar. Probablemente no hayan logrado terminar de hacerlo bien, o no hayan podido mantenerlo actualizado a un costo sostenible”, asegura José.

Daniel Aisemberg, director de Evaluando ERP, reflexiona ante lo expuesto por los especialistas y se pregunta entonces cuál podría ser la solución. “Con tantas empresas que hay en el rubro, parece difícil creer que no haya soluciones específicas que se acoplen a los ERP's tradicionales. Además, los vendors promocionan sus productos como que poseen respuesta a la problemática del sector. Sin ir más lejos, ¿No tiene SAP aplicaciones para logística y transporte?”, cuestiona.

“Los proveedores que dicen tener estas soluciones son SAP, Oracle, JDA, Infor, RedPrairie, Manhattan, etc. Lo que pasa es que ponen una capa mejor o peor desarrollada sobre su ERP tradicional y, consecuentemente, aplican lo dicho sobre el núcleo de los ERPs. Por consiguiente, sucede que la adaptación que necesita cada organización concreta, su integración con los demás sistemas y el mantenimiento del software implantado, resulta ser caro y lento, tal como ocurre con los desarrollos a medida”, responde José.

“Si bien me consta que hay soluciones más específicas para las empresas del sector concebidas desde cero, provienen de pequeños proveedores locales de software. Resulta que, o bien se trata de aplicaciones demasiado elementales, o bien no merecen la confianza de un gran operador del sector. Los clientes piensan esto: ¿cómo es posible que tú hayas sido capaz de hacer algo que SAP no tiene?”, nos cuenta.

Para Josué Cadilla Andrés, propietario de BizBoost S.L., empresa española dedicada al desarrollo de programación, “es evidente que la solución pasa por el FOSS (Free Open Software Solution). De modo que en lugar de 50 reinvenciones de la rueda, se conseguiría una sola rueda de alto rendimiento. Quizás el ERP no encaja adecuadamente en este mercado”.

Martín Vartabedian, es el propietario de Digital Express, empresa que desarrolla Software solo para Transporte, Logística y Distribución. Veamos su postura:

“Los problemas que plantean yo los veo desde el otro lado”, plantea Martín. “En muchas ocasiones siento que el cliente no quiere conocer la gestión de procesos sino lo más concreto, ver como el producto factura o a lo sumo ver la trazabilidad, pero no la integración en todas las fases del negocio”, expresa. “Comparto plenamente con José que las Compañías creen que si SAP no pudo nadie puede, y es un gran error, porque justamente empresas como SAP tienen muy difícil el ingreso a mercados tan verticales”.

Luis Carrasco interviene de nuevo en el debate, sorprendido por el testimonio de Martín. “Me llama la atención eso que dices que los clientes no piden ver la integración/gestión de procesos. Siempre "le echamos la culpa" a los integradores y es cierto que a veces los clientes "no se dejan aconsejar". Bueno, para eso están los buenos consultores. Respecto a tu observación sobre SAP, estoy de acuerdo, aunque reconozco que se están poniendo las pilas”, opina.

Martín reconoce que “cuando existen los consultores el pedido es diferente, mas concreto. Creo que acá lo importante es evangelizar cómo hacer para que el cliente vea lo importante y no lo urgente o lo tangible. No sé si alguno ha logrado ese objetivo, pero lo creo bastante difícil”, confiesa.

José comparte lo dicho por Luis. “Cuando el cliente es una persona conocedora de la gestión integral de procesos, o cuenta con un consultor de su confianza que lo ayude, las implantaciones de software son mucho más sencillas y efectivas. Lo que no comparto tanto es la visión de "ERP vertical", tanto por el lado del concepto ERP (paquete transaccional integrado) como por el del vertical (orientado a un segmento o nicho específico de negocios). Estando en 2009, ¿por qué no pensamos ya en términos de mashups[1]? ¿Qué nos lo impide? ¿En qué dirección se están moviendo los SAP, Oracle, Microsoft, Infor, Lawson, CDC, RedPrairie, Manhattan? ¿Por qué hay que integrar "a mano" y no "a máquina", como se hace en la web (Amazon, Google, Yahoo!…) con las APIs abiertas?

Luis no está del todo convencido. “No tengo claro cómo una integración tipo mashup puede resolver cuestiones claves como la integridad transaccional entre aplicaciones separadas por un firewall, o la integración bidireccional. Por que conozco, y reconozco que no es mucho, el enfoque mashup es útil para integrar información de carácter no transaccional y para agregar en un sentido. Sin duda que se llegará, si no se ha llegado ya, a lograr un enfoque adecuado”.

“Por mashup me refiero a que un usuario de Amazon o Zappos vea en su terminal la información gestionada por el sistema de transporte de UPS o FedEx como si fuera parte de la aplicación transaccional que usa cotidianamente ¿Es eso un sistema integrado? Creo que sí, en la medida en que la gestión de la tienda electrónica y de la paquetería estén conectadas sincrónicamente M2M: machine to machine por debajo. ¿Lo tendrán hecho de la manera que pides? Me atrevo a afirmarlo”, responde José.

“Hay grados y grados de integración, José”, dice Luis. “Seguro que con enfoques tipo mashup se podrán lograr determinados tipos de integración. Para integraciones más complejas tengo mis dudas. Habría que ver caso a caso. Lo que es indudable es que los tiros van a ir por arquitecturas orientadas a servicios, no hay otra”

“Personalmente creo que la integración -así como la asociación- son claves. Lo que no creo es que ni Microsoft ni SAP piensan en ese sentido. Tal vez google lo hace parcialmente, pero la mayoría de los demás piensan en "intégrense conmigo". Por nuestra parte trabajamos mucho en integración con standares y hasta estamos por lanzar nuestra primera versión Open Source para la comunidad, siendo la primera solución de trucking de carga en la comunidad”, cuenta Martín Vartabedian.

“Quisiera destacar la cantidad de dificultades de integración que nos presentan en el día a día muchos de los grandes (IBM, Oracle, Microsoft o SAP). Ellos hablan de integración y de apertura, pero la única forma de lograrla es utilizando solo sus reglas, que ni siquiera son compatibles entre ellos. Creo que la política de SaaS (Software as a Service) es una tendencia global, que hará que cada quién se especialice en su expertise y concentre sus esfuerzos en mejorar todo lo relacionado a su especialidad solamente”, concluye Martín.

“Yo creo más bien que hay razones económicas y de estrategia empresarial capitalista pura y dura, y esto no es malo. En sentido amplio: menos costos, independencia de proveedor, etc.”, agrega Luis, no tan seguro de ese “giro ideológico” que promete Martín.

La lectura se complementa con el que se encuentra en la sección Biblioteca/ Informes especiales de este sitio donde se puede leer el informe de Logística y Transporte en el que más de 430 firmas de América Latina hablaron sobre su actual sistema de gestión empresarial. El 60% de los encuestados admiten que no utilizan software-producto, sino que operan con un sistema hecho en la empresa o por un tercero.