Transformación financiera sin reimplantación del ERP

Llega un nuevo CFO, encuentra una función financiera más lenta y menos perspicaz de lo que debería ser, y el instinto es atribuirlo al sistema. El ERP es antiguo, o está mal configurado, o se implantó para una empresa más pequeña. Se propone una reimplantación, se presupuesta y se programa para dentro de un año.

Según nuestra experiencia, ese instinto acierta quizá una de cada tres veces. Con más frecuencia, el sistema existente es capaz de hacer la mayor parte de lo que se le pide, y la restricción está en el diseño de procesos, la disciplina de datos y la estructura de reporting construidas encima — nada de lo cual arregla automáticamente una reimplantación, y buena parte de lo cual simplemente se reconstruirá en el nuevo sistema si no se aborda antes.

Esto importa porque una reimplantación es la palanca más cara y de mayor riesgo de las que dispone una función financiera, y se recurre a ella con frecuencia antes de haber probado las palancas más baratas. Este artículo trata de esas palancas más baratas, y de cómo determinar, honestamente, si realmente necesita la cara.

Por qué esto importa

El coste de una reimplantación innecesaria no es solo el desembolso directo, aunque sea considerable para una empresa mid-market. Son los dieciocho meses de atención organizativa que consume, la congelación de cualquier otra mejora mientras el proyecto está en marcha, y el riesgo real — visible en los patrones de fracaso de implantaciones de NetSuite que vemos repetidamente — de que el nuevo sistema herede los mismos problemas de proceso en una interfaz distinta, porque nadie arregló el proceso antes de migrarlo.

Hay un coste más sutil. Los equipos que pasan por una reimplantación sin arreglar antes el proceso tienden a especificar mal los requisitos, porque describen su proceso actual y defectuoso en lugar del proceso que realmente necesitan. El nuevo sistema implanta entonces fielmente la vieja disfunción, a un coste considerablemente mayor del que habría supuesto arreglar la disfunción directamente.

La alternativa — la transformación empezando por el proceso — tiene un perfil menos espectacular y un retorno ajustado al riesgo mucho mejor. Es además, no por casualidad, la preparación que hace más barata y rápida una futura reimplantación (si de verdad se necesita), porque los requisitos ya se conocen.

De un vistazo: qué arregla una reimplantación y qué no

El patrón: las limitaciones de plataforma son reales y sí exigen sustitución. Todo lo que está por debajo de las dos primeras filas es proceso, gobierno del dato y configuración, y las empresas mid-market proponen habitualmente la solución de la parte superior de la lista para un problema de la parte inferior.

Qué funciona y sobre qué hay que ser honesto

Qué funciona:

Una auditoría de capacidades antes de decidir la sustitución. Antes de dimensionar una reimplantación, establezca específicamente qué no puede hacer el sistema actual — no lo que hace mal por cómo se configuró, sino lo que estructuralmente no puede representar. Suele ser un ejercicio de dos a tres semanas y es lo más valioso que puede hacer antes de comprometerse con algo mayor.

Rediseño del plan de cuentas y de las dimensiones, hecho con independencia de cualquier cambio de sistema. Un plan de cuentas diseñado para una empresa de una quinta parte de su tamaño actual, o para un modelo de negocio que desde entonces ha cambiado, produce informes que no reflejan cómo se dirige realmente el negocio — independientemente del ERP que lo albergue. Esto puede rediseñarse y migrarse dentro del sistema existente.

Trabajo de conciliación y de proceso de cierre, abordado como proyecto propio. La disciplina del cierre en cinco días — conciliación continua, fechas de corte estrictas, gestión de excepciones asistida por agentes — es alcanzable en la mayoría de los ERP mid-market tal como están. Rara vez es el sistema el que lo frena.

Racionalización de la personalización. Un sistema que se ha vuelto frágil por años de personalización acumulada a menudo puede recuperarse revisando y eliminando lo que ya no se necesita, lo cual es materialmente más barato que sustituir la plataforma que hay debajo.

Arreglos de gobierno del dato y de propiedad. Los problemas de calidad de datos que finanzas achaca al sistema son con frecuencia un problema de propiedad — nadie fuera de finanzas responde por los datos que crea. Esto se arregla asignando propiedad y haciendo visible la calidad, no cambiando de software.

Sobre qué hay que ser honesto:

Algunos sistemas necesitan sustitución de verdad. Si su estructura de entidades, sus requisitos de divisa, su volumen transaccional o sus necesidades sectoriales exceden aquello para lo que se construyó la plataforma, ningún trabajo de procesos cierra esa brecha. La auditoría de capacidades existe para detectarlo honestamente en lugar de darlo por supuesto o negarlo.

El trabajo de procesos no es gratis y compite por la misma atención directiva. Exige disciplina de proyecto real, patrocinio real y una voluntad genuina de cambiar cómo trabajan los departamentos — los mismos ingredientes que exige una reimplantación, solo con un presupuesto menor y un calendario más corto. Las empresas que no pudieron sostener la disciplina de procesos también tendrán dificultades para sostenerla aquí.

La secuencia importa y con frecuencia se ignora. Hacer el trabajo de procesos y descubrir después que igualmente necesitaba una reimplantación no es esfuerzo perdido — el trabajo de procesos se convierte en sus requisitos —, pero hacer primero una reimplantación y descubrir después que los problemas de proceso siguen ahí sí es gasto perdido, sin duda. Ponga siempre el proceso antes de la plataforma.

Algunos responsables quieren la reimplantación en cualquier caso. A veces se desea un proyecto grande y visible por razones ajenas al problema declarado — un nuevo CFO que quiere un mandato visible, un consejo que quiere ver acción decidida. Es una dinámica organizativa legítima y conviene nombrarla honestamente en lugar de disfrazarla de necesidad técnica.

Marco de decisión: sustituir o arreglar la capa de procesos

Recórralo en orden. Deténgase en la primera coincidencia.

1. ¿Puede nombrar una transacción, estructura de entidades o requisito de reporting concretos que el sistema actual no pueda representar, con independencia de la configuración?
Si la respuesta es sí y es material, probablemente necesite un cambio de plataforma — pero dimensione la sustitución en torno a esa brecha concreta, no en torno a una insatisfacción general. Si es no, continúe.

2. ¿Su insatisfacción tiene que ver en realidad con la velocidad del cierre, la fiabilidad de los informes o la calidad de los datos?
Estos son los problemas peor atribuidos con más frecuencia. Recorra el marco del cierre en cinco días y el modelo de custodia de master data antes de dar por hecha una limitación de plataforma. La mayoría de los problemas de cierre y reporting del mid-market se resuelven aquí.

3. ¿Su plan de cuentas o su estructura dimensional han seguido el ritmo del negocio?
Si no, rediséñelos dentro del sistema actual. Esto por sí solo resuelve una parte importante de las quejas del tipo "nuestro reporting no refleja el negocio" y no exige migración.

4. ¿El sistema está muy personalizado y es frágil?
Haga una revisión de personalización antes de dar por hecho que la sustitución es el único camino. Distinga la personalización irrecuperable — construida sobre una versión o arquitectura que el fabricante ya no soporta bien — de la personalización que simplemente está indocumentada y desordenada, que puede racionalizarse in situ.

5. ¿Los problemas de calidad y propiedad del dato son en realidad organizativos y no técnicos?
Si los datos llegan tarde o mal desde fuera de finanzas, eso es un arreglo de gobierno del dato, y ningún cambio de sistema lo resuelve, tampoco uno nuevo.

6. ¿Ha completado una auditoría de capacidades genuina, independiente de la aportación del fabricante?
Si no, encárguela antes de cualquier conversación presupuestaria. Es el artefacto que separa "no estamos contentos con nuestros sistemas financieros" de un caso de negocio real.

7. ¿Auditoría completada y brecha confirmada y material?
Ahora dimensione una reimplantación — pero dimensiónela contra un proceso ya arreglado, para que el nuevo sistema herede buenas prácticas en lugar de codificar la vieja disfunción.

Coste y esfuerzo indicativos

El trabajo que empieza por el proceso cuesta normalmente una fracción de una reimplantación y aporta la mayor parte de la mejora que un CFO busca en realidad. Solicite un presupuesto para una auditoría de capacidades dimensionada.

Preguntas frecuentes

¿Cómo sabemos si nuestra insatisfacción es con el sistema o con el proceso construido sobre él?
La auditoría de capacidades está diseñada precisamente para responder a esto, separando "el sistema no puede hacer X" de "el sistema nunca se ha configurado ni usado para hacer X". La mayor parte de la insatisfacción del mid-market cae en la segunda categoría.

¿Nos darán los fabricantes y los partners de implantación una respuesta honesta en esto?
Desconfíe de cualquiera cuyos ingresos dependan de que la respuesta sea "sustitúyalo". Una auditoría es más creíble cuando se dimensiona y se entrega con independencia de quien pueda venderle la sustitución.

¿Podemos hacer el trabajo empezando por el proceso y aun así acabar necesitando una reimplantación más adelante?
Sí, y ese es un buen resultado, no un fracaso. Habrá arreglado problemas que de otro modo se habrían reconstruido en el nuevo sistema, y dimensionará la sustitución final con requisitos reales en lugar de conjeturas.

¿Cuánto tarda en dar resultados el trabajo que empieza por el proceso?
Las mejoras de cierre y conciliación se ven en uno o dos trimestres. El rediseño del plan de cuentas se aprecia en el siguiente ciclo completo de reporting. Los cambios de gobierno del dato y de propiedad tardan más en asentarse — normalmente dos o tres trimestres antes de que la mejora de calidad de datos sea duradera y no un empujón temporal.

¿Cuál es la señal más clara de que realmente necesitamos una reimplantación?
Cuando la auditoría de capacidades produce una brecha estructural concreta y con nombre — una divisa que su sistema no puede manejar, una estructura de entidades que no puede modelar, un volumen transaccional que no puede procesar — en lugar de una lista general de frustraciones. La frustración es un síntoma. Una brecha estructural con nombre es un caso de negocio.

Cierre — Próximos pasos

La transformación financiera se vende habitualmente como una decisión de plataforma porque esa es la versión visible y financiable de la petición. La mayor parte del valor real está por debajo de la plataforma, en el proceso, el gobierno del dato y la estructura — y está disponible más rápido, con menos riesgo y sin la congelación de dieciocho meses que una reimplantación impone a todo lo demás.

El primer paso honesto es la auditoría de capacidades, realizada con independencia de cualquiera que tenga interés en la respuesta. Si encuentra una brecha estructural genuina, ya tiene un caso de negocio real. Si no la encuentra — que es el resultado más común —, tiene una hoja de ruta más barata y rápida y la opción de retomar la sustitución cuando haya agotado lo que la mejora de procesos puede dar.

Sobre el autor

Bruno Galo es el fundador de Atypical Tech, una consultora de NetSuite que presta servicio a clientes mid-market en toda Iberia. Está especializado en conectar sistemas CRM y ERP para flujos order-to-cash sin fricciones, construyendo pipelines automatizados de gestión de pedidos que eliminan la introducción manual de datos entre los equipos de ventas y de finanzas. Como partner oficial de implantación de Stacksync, Bruno diseña y despliega agentes de IA sobre plataformas de integración para gestionar el enrutamiento de excepciones, el procesamiento de documentos y la conciliación — convirtiendo flujos de pedidos fragmentados en sistemas fiables que se supervisan a sí mismos.

LinkedIn: https://www.linkedin.com/in/brunogd

Fuentes

Las URL son de nivel editorial y deberían verificarse antes de la publicación.

• Oracle NetSuite, documentación de capacidades de plataforma y configuración — https://docs.oracle.com/en/cloud/saas/netsuite/
• APQC, Open Standards Benchmarking — medidas de transformación financiera y de rendimiento de procesos — https://www.apqc.org
• Panorama Consulting Group, ERP Report anual — datos sobre la decisión de sustituir frente a optimizar — https://www.panorama-consulting.com
• Experiencia de Atypical Tech en proyectos de transformación financiera mid-market en Iberia