Cuando un ERP nativo en IA no es la solución adecuada
Siete situaciones en las que recomendamos no hacer el proyecto y qué hacer en su lugar.
Me dedico a implementar ERP nativos en IA. Campfire, Rillet, DualEntry. Ocho implementaciones, con entidades operativas en Estados Unidos, Canadá, Reino Unido, México, Colombia y Panamá. Creo que esta generación de sistemas es realmente mejor que la anterior, y no lo digo como proveedor. Lo digo como alguien que pasó más de una década trabajando con la generación anterior y no la extraña.
Así que esto no es una forma de cubrirnos. Es la lista que realmente reviso en una primera llamada, porque un proyecto que nunca debió comenzar resulta costoso para el cliente y aún peor para mí. Una mala implementación no solo cuesta dinero; también puede acabar con la disposición de un equipo financiero para afrontar cambios durante unos tres años.
Estas son las siete señales que me hacen decir: esto no, o todavía no.
1. Tu negocio depende del inventario
Esta es la señal más clara y, al mismo tiempo, la que más suelen intentar discutir.
Campfire, Rillet y DualEntry son sistemas centrados en finanzas. Están construidos alrededor del libro mayor, el cierre, el reconocimiento de ingresos y la consolidación de múltiples entidades. Son muy buenos en eso. Ninguno de ellos incluye de forma nativa gestión de inventario, operaciones de almacén o compras.
Si distribuyes productos físicos, fabricas algo o mantienes existencias como una parte importante de tu balance general, tu sistema de registro principal no es el libro mayor. Es el sistema que controla los productos. El ERP debe seguir al sistema de inventario, no al contrario. Intentar convertir una plataforma centrada en finanzas en el núcleo de un negocio basado en inventario genera una arquitectura en la que los datos más importantes de la empresa viven fuera del sistema más importante de la empresa.
Qué hacer en su lugar: primero decide qué sistema será responsable del inventario. Después, la plataforma financiera se integra con él. Esa plataforma aún puede ser Campfire o Rillet. Muchas empresas utilizan un sistema especializado de inventario conectado a un libro mayor moderno, y funciona bien. Pero es una arquitectura de dos sistemas y debe plantearse así desde la primera semana. Descubrirlo durante las pruebas de aceptación del usuario es la forma en que los proyectos empiezan a desviarse.
2. Tu factura no es legal hasta que una autoridad tributaria lo autoriza
En gran parte de América Latina, y cada vez más en Europa, una factura no existe para efectos fiscales hasta que la autoridad tributaria la ha validado previamente y ha devuelto un código de autorización. El CFDI de México, el CUFE de Colombia, el DTE de Chile, el CUFE de Panamá y el e-CF de República Dominicana: distintos nombres, mismo modelo. Se conoce como un régimen de autorización previa (clearance) y coloca el cumplimiento tributario dentro del flujo de la transacción, en lugar de dejarlo para un reporte al final del mes.
Ningún ERP desarrollado en Estados Unidos autoriza estas facturas por sí solo. No es una falla del producto; es una consecuencia de cómo están diseñados estos regímenes. La arquitectura que funciona consiste en el libro mayor más un proveedor local certificado que genera el XML firmado, lo transmite y devuelve el código de autorización, que posteriormente el ERP almacena junto con el documento.
Esta arquitectura funciona. La hemos implementado. Pero representa un costo real, implica riesgos reales y es la parte más subestimada de una implementación en América Latina.
Cuándo esto convierte el proyecto en una mala decisión: si operas en un país con un régimen de autorización previa y no tienes presupuesto o disposición para realizar la integración, no empieces. Terminarás con un excelente libro mayor y un proceso de facturación que no genera documentos fiscales válidos, lo cual es peor que tu situación actual. Algunos países exigen todavía más. Colombia requiere emitir un documento electrónico para tus propias compras y un documento de nómina firmado por cada empleado cada mes. México exige un segundo documento fiscal por cada pago que recibes. No son funciones que simplemente puedas activar más adelante.
3. Tus libros contables legales deben llevarse de una manera diferente
Algunas jurisdicciones no solo requieren un reporte diferente. Exigen un conjunto de libros estructuralmente distinto.
Chile exige un ajuste anual por inflación de los activos no monetarios y del patrimonio para efectos fiscales. No existe un equivalente bajo US GAAP o IFRS, porque Chile no es una economía hiperinflacionaria; simplemente así funciona su legislación tributaria. La consecuencia práctica es que el balance general del ERP nunca será igual al balance fiscal, y la declaración anual se construye a partir del segundo. México exige que el plan de cuentas esté vinculado a los códigos contables propios de la autoridad tributaria y se presente mensualmente en XML, lo que significa que el plan de cuentas debe diseñarse teniendo esto en cuenta desde el primer día, en lugar de adaptarlo posteriormente.
Qué hacer en su lugar: nada de esto hace que el proyecto sea imposible. Lo convierte en un problema de diseño en lugar de un problema de configuración, y significa que parte del trabajo legal y tributario permanecerá fuera del ERP con un contador local. Esto debe acordarse explícitamente desde el principio y comunicarse con claridad. El problema no es la complejidad. El problema aparece cuando un cliente descubre en el quinto mes que el sistema que compró para convertirse en su única fuente de verdad no es la fuente de la que provienen sus declaraciones fiscales.
4. El sistema que realmente gestiona tu negocio es una plataforma vertical
Una empresa de viajes con requisitos de liquidación de IATA. Un grupo clínico cuyo verdadero sistema operativo es el expediente del paciente. Una empresa de construcción cuya operación depende de un nivel de costeo por proyecto que ningún libro mayor general puede modelar.
En estas empresas, la mayor parte de la complejidad operativa vive dentro de una plataforma vertical, y esa plataforma no va a desaparecer. Se integra con ella; no se migra desde ella. Si reemplazas el ERP que está detrás, habrás mejorado la capa contable de una empresa cuyos problemas más difíciles siguen estando en otro lugar.
A veces sigue valiendo la pena. Un mejor libro mayor sigue siendo un mejor libro mayor. Pero hay que ser realistas respecto al beneficio. Si el noventa por ciento de tus problemas está en el sistema vertical, un proyecto ERP aborda el diez por ciento de tus problemas con el cien por ciento de la disrupción.
5. Nadie tiene tiempo para hacerse responsable de los datos
Esta es la verdadera razón más frecuente por la que fracasan los proyectos, y no tiene nada que ver con el software.
Hoy en día, gran parte de la migración está automatizada. Eso es real. Las herramientas han mejorado y trasladar un libro mayor ya no es el proceso de varios meses que solía ser. Pero migrar no es lo mismo que tomar decisiones. Alguien de tu organización tiene que decidir cómo debería quedar el plan de cuentas, qué períodos históricos importan y cuáles no, qué hacer con once años de registros que fueron clasificados incorrectamente por personas que ya no trabajan en la empresa y cuáles de tus cuarenta y dos cuentas de gastos son, en realidad, la misma cuenta.
Una IA puede proponer todo eso. No puede asumir la responsabilidad por esas decisiones.
Si tu función financiera depende de un solo controller que ya trabaja hasta tarde para conseguir cerrar en quince días, añadir una implementación no es un proyecto de productividad. Es un segundo trabajo. Las herramientas reducen el tiempo que requieren las tareas mecánicas, y eso es real, pero las decisiones que requieren criterio siguen necesitando una persona con autoridad para decidir y tiempo para hacerlo.
Qué hacer en su lugar: identifica a esa persona antes de firmar cualquier cosa y quítale alguna responsabilidad de encima. Si no puedes hacerlo, espera un trimestre. Un proyecto que comienza con un responsable que tiene capacidad disponible supera siempre a un proyecto que empieza tres meses antes sin esa persona.
6. Tu cierre es lento por razones que un sistema no puede solucionar
Si tardas veinte días en cerrar porque tres departamentos tienen que entregarte información y nadie hace seguimiento, no tienes un problema de sistemas. Tienes un problema de ritmo operativo disfrazado de problema de sistemas.
La automatización acelera un proceso que funciona. No crea uno. Coloca un sistema rápido debajo de un proceso roto y seguirás teniendo los mismos veinte días, además de una nueva herramienta a la que culpar.
La prueba es sencilla y ligeramente incómoda: de todos los días que dura tu cierre, ¿cuántos días está trabajando realmente tu equipo y cuántos está esperando información de otras personas? Si la mayor parte del tiempo es espera, soluciona eso primero. Es gratis y hará que la futura implementación sea mejor. Estarás automatizando un proceso que realmente vale la pena automatizar.
7. El momento no es el adecuado
Tres situaciones en las que la respuesta es sí, pero no ahora.
• En medio de una auditoría. No cambies el libro mayor mientras alguien lo está examinando.
• En medio de una ronda de inversión o una adquisición. La debida diligencia necesita libros estables y un historial comparativo limpio. Dáselos.
• La empresa todavía es demasiado pequeña. Existe un punto mínimo. Si una sola persona lleva la contabilidad en QuickBooks y cierra en cuatro días, el retorno de una implementación todavía no justifica el proyecto. Vuelve cuando haya aumentado el número de entidades o el volumen de transacciones.
Ninguna de estas situaciones es permanente. Son problemas de calendario, y los problemas de calendario son los más fáciles de resolver. Simplemente esperas.
Entonces, ¿cuándo es la opción adecuada?
Para equilibrar la perspectiva, este es el perfil para el que esta generación de sistemas representa claramente una mejor solución:
• Múltiples entidades legales que deben consolidarse, especialmente cuando operan con diferentes monedas.
• Un cierre con una gran carga de trabajo mecánico: conciliaciones, provisiones, operaciones intercompañía y cronogramas de reconocimiento de ingresos.
• Un equipo financiero al que se le exige gestionar más entidades o mayor volumen sin aumentar su tamaño.
• Reconocimiento de ingresos con una complejidad real, donde una hoja de cálculo se ha convertido en una pieza crítica del proceso.
• Un sistema heredado cuyo costo proviene principalmente de mantenerlo en lugar de utilizarlo.
Si este es tu caso, los argumentos son sólidos y los tiempos de implementación se miden en semanas, no en trimestres. Esa parte de la promesa es cierta, y es la razón por la que hago este trabajo.
Cinco preguntas que vale la pena hacerse primero
1. ¿El inventario tiene un peso importante en mi balance general?
2. ¿Alguna de mis entidades opera en un lugar donde la autoridad tributaria valida las facturas antes de que sean emitidas?
3. ¿Mis libros contables legales deben llevarse de una forma diferente a mis libros de gestión?
4. ¿Quién, específicamente, va a tomar las decisiones sobre los datos y qué responsabilidades vamos a quitarle para que pueda hacerlo?
5. De los días que dura mi cierre, ¿cuántos son de trabajo y cuántos de espera?
Si las respuestas a estas preguntas son claras, tienes un buen proyecto. Si dos o más te generan dudas, necesitas tener una conversación sobre el alcance antes de tomar una decisión sobre el software.
Preferimos decirte que no hagas el proyecto antes que implementar uno que nunca debió comenzar. Si quieres evaluar tu situación utilizando esta lista con alguien que no tiene ningún motivo para venderte una licencia, estaremos encantados de conversar contigo.
Expandia implementa ERP nativos en IA (Campfire, Rillet y DualEntry) para equipos financieros que operan en América y Europa.