Implantar software en retail: lo que me enseñó un ERP puesto en marcha en dos meses

El primer sistema de gestión que implanté lo construí con diecinueve años, solo, en unos dos meses. Mirando atrás después de veinte años de implantaciones, casi nada de lo que hice bien en esos dos meses tenía que ver con el código.

La empresa distribuía periódicos y revistas a través de más de cincuenta quioscos repartidos por una ciudad. Entregas, stock, devoluciones, un almacén, la gestión del efectivo y las liquidaciones con proveedores, todo con un producto de vida comercial brutalmente corta. Un periódico pierde su valor más rápido que la leche, y cada proceso de aquel negocio estaba moldeado por ese hecho.

Yo era el único programador. Un administrador de sistemas me enseñó a descomponer un problema y a mantener el código con cierto orden. Todo lo que tenía que ver con la implantación (hablar con la gente, cambiar su forma de trabajar, conseguir que la herramienta se adoptara) lo aprendí equivocándome delante de todos.

Cincuenta quioscos, dos meses y ni idea de que era una locura

El encargo era tomar una base de software existente y ampliarla para cubrir las operaciones, el stock y el efectivo de toda la empresa. Lo que me llama la atención ahora es cómo lo llevó el consejero delegado. Desde las primeras conversaciones le hablaba a un chico de diecinueve años de procesos de negocio, de cómo los departamentos se pasaban el trabajo, de dónde se atascaba la información y de qué creía que se podía organizar mejor. No de especificaciones. Del negocio.

Parte de por qué funcionó es poco halagadora: no sabía lo suficiente como para saber que la tarea era una locura. Un directivo con experiencia habría hecho una evaluación de riesgos, redactado un plan, pedido un equipo y explicado por qué dos meses era casi imposible. Muchas veces habría tenido razón. No entender el tamaño de un problema aporta a veces una energía que una persona bien calibrada nunca gastaría.

No saber lo descabellada que es una tarea puede ser una fuente real de energía. No es un plan, y no sobrevive al contacto con la segunda ubicación.

Escrito de noche, probado por la mañana

El método, si merece ese nombre, era este: escribir una pieza por la noche, ponerla por la mañana delante de empleados reales haciendo trabajo real, observarla durante el día, encontrar el requisito que se me había escapado y repetir. Cuando ya no podía más, dormía en la sala de servidores, que se mantenía a dieciocho grados y a esa edad se aguanta. No lo pensaba como un piloto ni como una implantación por fases. Lo llamaba programar de noche, lanzar por la mañana y corregir durante el día.

Años después leí el trabajo de Hackman y Oldham de 1976 sobre cómo el diseño del puesto genera motivación: autonomía, resultados visibles, la sensación de que el trabajo importa y retroalimentación inmediata. Yo tenía las cuatro por accidente, porque no había nadie más que pudiera tenerlas. La distancia entre una decisión y su consecuencia era de unas horas, y la retroalimentación la daban personas que tenían que convivir con lo que yo había entregado. Rara vez era diplomática y nunca se equivocaba.

Es el argumento más sólido que conozco para mantener a la gente de implantación cerca de la operación. En las empresas más grandes en las que trabajé después, los departamentos, los traspasos y los niveles de aprobación estiraban esa distancia a semanas, y la calidad de la retroalimentación se degradaba por el camino.

Por qué el heroísmo deja de funcionar en la segunda ubicación

El sistema se puso en marcha y acabó llevando la contabilidad de un negocio con más de cincuenta quioscos y varios cientos de compradores mayoristas. Me dieron una prima de 300 dólares y me la gasté en una bicicleta, lo que con diecinueve años era una asignación de capital defendible. El trabajo siguió después de la puesta en marcha: lógica de reposición, generación de pedidos de compra, recomendaciones para dar de baja las devoluciones y, al final, un módulo de almacén que le decía a la gente adónde ir. Se incorporó un segundo programador y me convertí en mentor sin tener ni idea de cómo serlo.

Lo que me lleva a la corrección que le haría a mi yo de diecinueve años. La responsabilidad personal lleva un primer proyecto notablemente lejos, y después se acaba. Ninguna organización debería depender de que una persona esté dispuesta a renunciar al sueño. Eso tiene que convertirse en procesos, documentación, conocimiento que tenga más de una persona y sistemas que sigan funcionando sin rescates. La idea relacionada sobre la capa de reporting en concreto, que no puede especificarse una vez y dejarse así durante años, es el tema de por qué tu reporting no puede ser un proyecto puntual.

Las preguntas que te dicen si una implantación ha funcionado

La tentación es juzgar una implantación por si se entregó según el plan y si la ingeniería es limpia. La arquitectura importa, y una mala arquitectura acaba convirtiéndose en un problema de negocio, solo que con un reloj más lento. Pero un equipo de tecnología no puede ponerse nota solo por lo bien organizado que está su propio proceso. Estas son las preguntas que hago en su lugar, uno o dos meses después de la puesta en marcha:

• ¿Han bajado de verdad los errores, y se ve en los datos y no en las impresiones?
• ¿La gente termina el mismo trabajo más rápido, o el trabajo simplemente ha pasado a otra persona?
• ¿La dirección recibe la misma información antes, o solo en un formato más bonito?
• ¿El stock se entiende mejor que antes, por ubicación, categoría y periodo?
• ¿Qué pasos manuales han desaparecido por completo y cuáles solo han cambiado de manos?
• ¿Ha cambiado alguna decisión de negocio gracias al sistema, y puedes nombrar esa decisión?

Si ninguna de esas preguntas tiene respuesta, el sistema está en marcha. Eso no es lo mismo que estar implantado, y en la distancia entre las dos cosas es donde se pierde la mayor parte del dinero de estos proyectos.

El software pasa a formar parte de la operación, no es una herramienta al lado

El trabajo de Eric Trist sobre sistemas sociotécnicos, más antiguo que la mayor parte del software sobre el que discutimos, lo explica mejor que yo. Un sistema nuevo no solo sustituye una herramienta. Cambia las relaciones, quién decide qué, cómo se reparte la responsabilidad, cuánto se fía la gente de lo que tiene delante y sobre qué acaba discutiendo.

Si la gente no se fía de los datos de base, no entiende por qué el sistema recomienda algo o dedica parte de cada día a corregirlo, el daño ha salido del software y ha entrado en las relaciones de trabajo que lo rodean. La llegada de la IA ha hecho ese argumento más afilado, no más suave. Una recomendación que nadie puede examinar es un problema de confianza antes que un problema de experiencia de usuario.

Lo que nos llevamos a marql

marql es una capa por encima de los sistemas de TPV, contabilidad y e-commerce que ya utiliza una cadena de tiendas, un grupo de restauración o una red de franquicias: los lee sin sustituirlos, con alojamiento en la UE. No sustituir el TPV ni el ERP es una decisión deliberada sobre cuánto de una operación debería poder alterar una sola implantación a la vez.

Nuestro compromiso es estrecho a propósito: una revisión cualificada de tus sistemas, una primera vista en directo en 24 horas y precios desde 200 € al mes. Lo que preferimos que se juzgue es la lista de arriba: si un responsable de operaciones obtiene una respuesta antes de lo que solía, y si eso cambia algo. Un ejemplo concreto de cómo se ve eso cuando una cifra se tuerce está en cómo investigar un descuadre de inventario.