Me cuesta festejar una implementación si Administración sigue quedándose hasta las diez de la noche. Lo escribí hoy en LinkedIn y lo quiero desarrollar acá con más calma. Soy Juan Manuel Garrido, fundador de EGA Futura, y después de tantos años en software empresarial hay una escena que me dice más de un proyecto que cualquier presentación con los indicadores en verde.
El ERP salió en fecha. Hubo foto, felicitaciones y un mail del CEO. El lunes siguiente, Administración seguía facturando en Excel.
Qué dice de una implementación que Administración siga en Excel?
Dice que se cumplió una fecha, pero no necesariamente un objetivo. Poner el sistema en producción es un hito del cronograma. El resultado que importa es otro: que la gente pueda trabajar mejor y que el mes cierre sin que tres personas se queden hasta tarde acomodando números.
Cuando Administración sigue en la planilla, aparece la doble carga. Lo mismo se registra en el sistema nuevo y en el Excel de siempre, porque todavía no confían en uno o porque al otro le falta algo. Y con la doble carga llega la pregunta de la historieta: cuál de los dos tiene el número correcto? Si nadie puede contestarla con seguridad, la implementación todavía no terminó, aunque el proyecto figure como cerrado.
Qué decisiones suelen llevar a ese lunes?
Casi nunca es una sola. Hay tres que me siguen haciendo ruido cada vez que las veo:
- Elegir la propuesta más barata sin mirar quién va a hacer el trabajo. Dos presupuestos pueden decir lo mismo en el papel y depender de equipos con experiencia muy distinta. Lo que compras es el criterio de las personas que van a configurar tu operación.
- Comprometer una fecha sin preguntarle a Operaciones si llega. La fecha la cumple gente que ya tiene el día ocupado. Si nadie le preguntó a quien despacha, compra o factura cuánto tiempo puede dedicarle al proyecto, el cronograma es una expresión de deseo.
- Sentar a la persona que factura todos los días recién cuando hay que capacitarla. Para ese momento el diseño ya está hecho. Si esa persona maneja excepciones que nadie más conoce, aparecen tarde y aparecen caras.
Ninguna de estas decisiones parece grave el día que se toma. El costo aparece después, cuando el sistema ya está en producción y la operación real no entra en lo que se configuró.
Qué responsabilidad tiene la consultora?
Bastante. Si una consultora vendió experiencia, esa experiencia tiene que aparecer cuando el cliente necesita resolver un problema, no quedarse en la reunión comercial.
El síntoma más común son los adicionales. «Eso no estaba contemplado.» «Ese proceso requiere un desarrollo.» «Ese cambio mueve la fecha.» Algunos ajustes son razonables, porque en toda implementación aparecen cosas que nadie había previsto. Pero si recién a mitad del proyecto descubres cómo entrega mercadería la empresa o cómo autoriza una nota de crédito, faltó una conversación bastante básica antes de presupuestar.
Y alguien la termina pagando. A veces es el dueño, con más plata. Otras veces es el equipo, quedándose hasta tarde para cargar lo mismo en dos sistemas mientras intenta que el negocio siga funcionando. Sobre quién debería conducir el proyecto para que esto no pase escribí en los ERP no fallan por el software: falla quién lidera el proyecto.
Cómo hacer la prueba del pedido al cobro antes de presupuestar?
Antes de discutir pantallas, yo quiero ver una operación completa. Una venta real, desde el pedido hasta el cobro, con sus excepciones, sus aprobaciones por WhatsApp y ese Excel que maneja una sola persona y nadie sabe bien cómo funciona.
Una forma práctica de hacerlo:
- Elige una venta reciente y real, no un caso ideal. Mejor si tuvo algún problema: una entrega parcial, un descuento especial o una devolución.
- Recórrela paso por paso con quien la hizo. Pedido, aprobación, preparación, entrega, factura, nota de crédito si la hubo, cobro e imputación.
- En cada paso anota tres cosas: quién lo hace, dónde queda registrado y qué pasa cuando algo sale distinto de lo normal.
- Marca todo lo que vive fuera del sistema: aprobaciones por WhatsApp o por mail, planillas personales, cálculos que alguien hace de memoria.
- Separa las decisiones de negocio de las configuraciones. Si Ventas y Finanzas no se ponen de acuerdo en quién autoriza una nota de crédito, eso no lo resuelve ningún consultor configurando el sistema.
En esa mesa sentaría a quienes hacen el trabajo todos los días y también a alguien con autoridad para tomar decisiones, porque hay desacuerdos entre áreas que solo se destraban así. Con ese recorrido sobre la mesa, se puede hablar de alcance, equipo, presupuesto y fechas con bastante más criterio.
Qué preguntas no deberían quedar sin respuesta?
- Quién aprueba un precio o un descuento fuera de lista, y qué pasa si esa persona no está?
- Cómo se entrega la mercadería: de una vez, en partes, desde qué depósito?
- Quién autoriza una nota de crédito y con qué límite?
- Qué planillas se usan hoy para facturar o para controlar, y quién las mantiene?
- Cómo se registra un cobro y cómo se concilia contra lo facturado?
- Cuánto tiempo real puede dedicarle al proyecto cada área sin que se frene la operación?
Si alguna respuesta es «depende» o «eso lo sabe fulano», ahí hay trabajo para hacer antes de firmar.
Cómo saber si la implementación salió bien?
La salida en producción no alcanza como prueba. Unas semanas después conviene mirar cosas más simples y más honestas:
- Se sigue cargando algo en dos lugares?
- Quedan planillas paralelas para facturar o para controlar?
- Los números del sistema coinciden con los que usa Administración para decidir?
- Quién se queda tarde en el cierre de mes, y por qué?
Si esas respuestas mejoran, hay algo para festejar. Si no, el proyecto tiene una deuda pendiente, aunque el cronograma diga otra cosa.
Esto aplica solo a los ERP?
No. Lo mismo vale para Salesforce, Oracle, Odoo o cualquier herramienta de gestión empresarial. Implementar es difícil: hay decisiones técnicas que pesan mucho, procesos que necesitan cambiar y hace falta tiempo de gente que ya tiene el día ocupado. Si la dirección no está dispuesta a darle ese espacio, conviene hablarlo antes de firmar. Lo desarrollé desde otro ángulo en por qué fallan las implementaciones de Salesforce, Oracle o SAP.
En EGA Futura trabajamos con un ERP nativo para Salesforce, así que el recorrido del pedido al cobro queda en la misma Salesforce Org que usa el equipo comercial. Si quieres ver cómo se arma ese circuito en la aplicación de ventas, para cotizar, entregar y cobrar, puedes agendar una demo en vivo y lo recorremos con una operación tuya.
Te dejo la misma pregunta del post: en las implementaciones que te tocó vivir, qué se festejó más, la salida en producción o que la gente pudiera trabajar mejor?
Preguntas frecuentes
Por qué Administración sigue usando Excel después de implementar un ERP?
Porque el sistema no cubre alguna excepción de la operación real o porque todavía no confían en sus números. Suele pasar cuando quienes facturan todos los días entran al proyecto recién en la capacitación.
Qué es la prueba del pedido al cobro?
Recorrer una venta real completa, desde el pedido hasta el cobro, con quienes la hicieron, anotando quién hace cada paso, dónde queda registrado y qué excepciones aparecen. Se hace antes de presupuestar la implementación.
Los adicionales de una consultora siempre son una mala señal?
No. Algunos ajustes son razonables porque aparecen cosas imprevistas. La señal de alerta es descubrir a mitad del proyecto procesos básicos, como la entrega de mercadería o la autorización de una nota de crédito, que se podían ver antes de presupuestar.
Cómo medir si una implementación de ERP o Salesforce salió bien?
Mirando si desapareció la doble carga, si quedan planillas paralelas, si los números del sistema son los que usa Administración y si el cierre de mes dejó de depender de horas extra.
Recibe estas ideas en tu correo
Si te sirvió esta mirada sobre implementaciones de ERP y Salesforce, suscríbete gratis al newsletter de EGA Futura en Substack y recibe cada artículo nuevo directo en tu correo.