Hay recetas que se aprenden leyendo. Esta no. Esta se aprende quemándose. Y las quemaduras, en tecnología, se pagan en millones.
Ya sea que sean Directores de Sistemas que enfrentan su primer ERP, o el CEO: al final del proyecto, el cheque y el problema llevan tu firma.
Empecemos por los ingredientes, porque casi todos los proyectos fallan antes de encender la estufa.
Los ingredientes
El primero no es el software. Es una lista escrita, de una página, con los problemas que este ERP viene a resolver. Si esa lista no existe, no hay receta; hay antojo. Y los antojos, en tecnología, cuestan.
El segundo, tampoco es el software, son los datos maestros: clientes, productos, proveedores. Hoy viven en catorce versiones del mismo Excel, y ninguna coincide. Limpiarlos es la parte aburrida de la receta, el equivalente a picar cebolla. Nadie quiere hacerlo, todos lloran, y sin eso no hay platillo.
El tercero, tampoco es el software, es el patrocinio. Si el proyecto es “de sistemas”, ya fracasó. Un primer ERP cambia cómo opera la empresa, y eso solo lo sostiene el CEO. Sistemas pone la técnica; la dirección pone el peso.
¿Y cuando el software entonces?
Entre todo el mercado de proveedores de ERP, ¿Cuál elegir? te ahorro la agonía y te respondo: importa menos de lo que crees. Para un primer ERP eliges tres cosas, en este orden:
procesos estándar,
implementador y,
hasta el final, la marca.
Y un dato para tu presupuesto: el licenciamiento tampoco es el factor de costo más importante. El costo real está en la implementación, los datos y la adopción.
Apuesto a que ya elegiste el ERP porque alguien más ya lo implementó. Lo viste en una presentación y fue algo brillante o alguien te lo recomendó como lo mejor del mundo. Pues vas directo al fracaso si no has hecho los demás pasos.
El paso que nadie te enseña
Antes de firmar nada, haz un censo. No de servidores: de Exceles. Los diez o quince archivos que realmente operan tu empresa. Vas a descubrir algo incómodo: el verdadero sistema de tu compañía es una macro que construyó alguien de finanzas hace años, y TI ni siquiera sabe que existe. No se reporta, no se documenta, no se respalda. Vive en una laptop.
Recuerdo el día en que esa laptop se borró. Vinieron a TI a pedir que recuperáramos el archivo. Y la respuesta fue la que nadie quiere dar: no se puede respaldar lo que no se sabe que existe. Ese día la empresa descubrió que su operación dependía de un archivo sin dueño, sin respaldo y sin plan B. Ese archivo es la razón de fondo por la que necesitas un ERP. Y también la razón por la que puede fracasar.
La cocción: dos tentaciones y un cómplice
Aquí es donde se quema el platillo. El implementador cobra por hora; tú pagas por resultado. Ese desalineamiento define el proyecto. Y por eso el implementador no va a detener las dos tentaciones más caras de un primer ERP.
La primera: querer que el sistema nuevo sea una copia fiel del desarrollo a medida que estás tratando de eliminar con su reemplazo. Cada “ajústenlo a como lo hacemos hoy” es una orden de trabajo facturable. La respuesta siempre será que sí se puede.
La segunda: el estudio de brechas —el famoso fit-gap— convertido en cheque en blanco. Cada brecha se resuelve con desarrollo, sin que nadie pregunte si lo que había que cambiar era el proceso y no el sistema.
Un consultor de verdad te detiene ahí. Un implementador te acompaña, sonriente, hasta el precipicio. Por eso la regla de oro de la cocción es una sola: como viene de caja primero, cero personalizaciones en fase uno. Si el estándar no te sirve, la pregunta incómoda es por qué tu proceso es tan especial, no cómo torcer el software.
Cómo se ve el platillo cuando sale mal
Un ERP mal implementado no truena. Algo peor: se convierte en una caja. Una caja cara donde se capturan, al final del mes, los datos que siguen naciendo en Excel. La operación real quedó afuera; adentro solo entra el resumen, tarde y a mano. Pagaste millones por una capturadora elegante, y el poder siguió viviendo en las hojas de cálculo.
Lo viví más de una vez. Me han pedido incorporarme a compañías para revisar una implementación de ERP que, después de meses de esfuerzo, presupuesto ampliado y un arranque doloroso, hicieron la pregunta que nadie quería hacer: de la lista de problemas que este proyecto venía a resolver, ¿cuántos se resolvieron? Ninguno. Habían construido, con dinero nuevo, una réplica más cara del sistema anterior. Con los mismos vicios y los mismos Exceles paralelos, ahora “por si acaso”, pero además nuevos Exceles y programas para automatizar la carga desde las macros al nuevo ERP, y esto incluso consumía más tiempo. La solución siempre fue una reingeniería de la implementación, pero ahora si haciendo lo que he mencionado lo que puse al inicio.
El emplatado
A ti, que estás por firmar: en el próximo comité pide la lista escrita de problemas a resolver. Guárdala. Dentro de un año, cuando alguien presuma que el sistema “ya arrancó”, esa lista será la única pregunta que importe. Arrancar no es resolver.
Esta receta no está en ningún manual, y no porque sea secreta. Es que la experiencia no se lee ni se escucha: se gana con tiempo y con cicatrices. Yo ya pagué las mías.
Un ERP no se implementa. Se negocia. Y en esa mesa, alguien tiene que haberse quemado antes que tú.
Publicado originalmente en Más allá de TI, newsletter quincenal de Mauricio Amaro sobre tecnología y las decisiones que llegan a la mesa de dirección.
