Imagina un equipo financiero que reconstruye informes fuera del ERP mientras el personal de operaciones vuelve a introducir transacciones entre sistemas. La dirección quiere financiar la sustitución. Antes de aprobarla, los responsables de finanzas, operaciones y tecnología deben determinar si esos fallos se deben a funcionalidades que faltan, un diseño deficiente de los procesos, integraciones poco fiables o responsabilidades insuficientemente definidas.
El crecimiento y las dificultades operativas justifican un análisis, no una sustitución automática. Financia mejoras cuando se pueda demostrar que la plataforma actual admite los flujos de trabajo necesarios. Avanza hacia la sustitución cuando existan limitaciones importantes que no puedan resolverse en condiciones aceptables. Encarga una evaluación adicional cuando sigan sin estar claros la causa, la viabilidad económica o la capacidad de la organización.
La decisión de inversión debe dar lugar a una elección respaldada por evidencias entre esas alternativas, no a una propuesta de implantación que ya dé por sentada la sustitución.
Documenta los fallos de los procesos antes de definir un nuevo sistema
Francesco Perrotta identifica los procesos empresariales ineficientes o complejos y la dificultad para integrar las aplicaciones existentes como motivos para plantearse un cambio de ERP. Trata esas señales como el punto de partida de un diagnóstico. Una queja como «el ERP no puede acompañar el crecimiento» debe convertirse en una descripción verificable de qué falla, en qué condiciones y con qué consecuencias para el negocio.
Pide al equipo financiero que detalle un fallo reciente en el cierre, la conciliación o la elaboración de informes. Pide a operaciones que muestre un pedido retrasado, una discrepancia de inventario o una excepción en compras. Registra el resultado esperado, el resultado real, la intervención manual y el impacto en las actividades posteriores. Distingue las consecuencias observadas de las suposiciones: un retraso en la facturación no equivale automáticamente a ingresos perdidos, y liberar tiempo del personal no implica necesariamente un ahorro efectivo.
Para cada flujo de trabajo crítico, reúne la trazabilidad de las transacciones, la configuración pertinente, el historial de soporte y la explicación del responsable del proceso. Después, clasifica la limitación que se sospecha:
- Capacidad del software: la regla de negocio o la transacción necesaria no puede representarse.
- Diseño del proceso: las responsabilidades, aprobaciones o transferencias entre equipos son poco claras o innecesariamente complejas.
- Integración: la información no llega, llega de forma incorrecta o no puede recuperarse de manera fiable.
- Preparación organizativa: los usuarios, responsables de datos o responsables de las decisiones no pueden mantener la forma de trabajar prevista.
Son hipótesis de trabajo, no clasificaciones definitivas. Si finanzas afirma que un informe es imposible, solicita los requisitos de información y una demostración de cómo se genera actualmente. Si operaciones atribuye el problema a la integración, sigue el fallo a través de las aplicaciones. La siguiente decisión de financiación debe abordar la limitación demostrada, no limitarse al departamento que la comunica.
Comprueba si el ERP actual puede adaptarse al cambio
Perrotta sostiene que el valor de una evaluación externa reside en una valoración objetiva de los procesos empresariales y en una comprensión más profunda del contexto de la empresa. Incluye ese principio en el encargo de evaluación: exige una recomendación que permita conservar el sistema actual, en lugar de contratar un análisis cuyo único resultado admisible sea sustituirlo.
Elige un flujo de trabajo crítico para el negocio y pide al equipo que demuestre cómo podría resolverlo la instalación actual mediante cambios de proceso, configuración, un módulo disponible o una integración de alcance acotado. Exige pruebas sobre la versión instalada y las condiciones comerciales aplicables. «El producto lo permite» no basta si la respuesta depende de una actualización no aprobada, una interfaz no disponible o una extensión sin probar.
Escenario hipotético de evaluación: una aplicación de almacén envía confirmaciones de expedición, pero finanzas sigue corrigiendo las facturas manualmente. La transferencia correcta de un mensaje no demuestra que el flujo de trabajo esté resuelto. Pide al equipo que demuestre la contabilización de la operación, la conciliación, la gestión de excepciones y quién asume la recuperación ante fallos. Si el ERP puede completar el proceso una vez corregida la interfaz, hay motivos para estudiar una mejora específica. Si sigue siendo imposible representar una regla de negocio obligatoria, se refuerza la justificación de la sustitución.
Comprueba también la flexibilidad futura, no solo el ajuste actual. En un seminario web sobre soberanía digital con representantes de un proveedor de ERP, los ponentes proponen someter las dependencias a pruebas de tensión ante cambios normativos, adquisiciones y cambios en la estrategia del proveedor. Su preocupación no es la dependencia en sí, sino aquella que elimina la capacidad de actuación de la empresa. Para esta decisión de inversión, pregunta qué ocurriría si una funcionalidad necesaria desapareciera de la hoja de ruta, cambiaran las condiciones de acceso o el negocio tuviera que cumplir una nueva obligación.
Documenta la respuesta contractual, técnica y operativa tanto del sistema actual como de la alternativa propuesta. No des por supuesta en una plataforma nueva la flexibilidad que exiges demostrar al sistema existente. Cuando la solución propuesta implique una extensión duradera, utiliza la plantilla de aprobación de personalizaciones del ERP para examinar esa dependencia, en lugar de convertir esta decisión de inversión en una aprobación detallada de cambios.
Compara la mejora y la sustitución en condiciones equivalentes
Construye escenarios con los mismos resultados de negocio exigidos y el mismo horizonte de planificación. Incluye conservar la instalación actual con mejoras específicas, sustituirla y, cuando persistan incertidumbres importantes, realizar una evaluación acotada antes de comprometerse con cualquiera de las opciones. Si resulta viable volver a implantar el producto existente, presupuéstalo por separado en lugar de ocultar una reconstrucción sustancial bajo la etiqueta de «optimización».
Para establecer la base de costes del sistema actual, las categorías de costes de ERP Research incluyen licencias, alojamiento, soporte, personal interno, mantenimiento de personalizaciones y costes de soluciones manuales o alternativas. Utiliza esas categorías para evitar comparar un programa de sustitución únicamente con la factura de licencias actual. Añade las mejoras propuestas e indica qué costes existentes desaparecerían realmente, cuáles se mantendrían y cuáles aumentarían.
Para la sustitución, solicita estimaciones explícitas tanto del trabajo de transición como de la operación posterior. La guía de decisión sobre ERP de Digital Advisory identifica como componentes del caso de negocio la cobertura del personal asignado al proyecto, los ensayos de migración, las integraciones temporales, los desplazamientos del integrador, una provisión para cambios y el soporte de estabilización más allá del periodo de asistencia intensiva previsto en la propuesta. Trátalos como aspectos que debes presupuestar para tu programa, no como cargos universales ni referencias de costes.
Para cada beneficio previsto, explica cómo se obtendrá y quién será responsable. Si se espera que la sustitución acorte el cierre, especifica qué paso de conciliación o aprobación cambiará, qué pruebas demuestran esa capacidad y qué tendrá que hacer finanzas de otra manera. No contabilices la misma capacidad liberada como reducción de plantilla y como aumento de producción, salvo que el plan operativo explique cómo se reparte.
Formula una recomendación condicionada. La mejora es creíble cuando resuelve los fallos importantes con obligaciones futuras aceptables. La sustitución es creíble cuando las limitaciones demostradas de capacidad o dependencia pesan más que los riesgos de la transición. Una evaluación adicional es adecuada cuando una cuestión concreta pendiente de resolver podría cambiar la elección. Asigna a esa evaluación un entregable definido, un responsable y una fecha de decisión, en lugar de un mandato de análisis sin límites.
Utiliza una plantilla de decisión, no una puntuación compuesta
La siguiente plantilla es una herramienta editorial de apoyo a la decisión, no un modelo de puntuación validado. Complétala para cada escenario viable. Mantén visibles los desacuerdos, en lugar de diluir una limitación crítica del negocio en una puntuación total aparentemente aceptable.
| Área de decisión | Evidencias que deben registrarse | Pregunta para la aprobación |
|---|---|---|
| Impacto operativo | Flujos de trabajo fallidos, pruebas de transacciones, esfuerzo actual y consecuencias para el negocio | ¿Qué fallos resolverá esta opción y cuáles permanecerán? |
| Capacidad y dependencias | Demostraciones de flujos de trabajo, comprobaciones de la versión instalada, interfaces, condiciones de soporte y supuestos sobre la hoja de ruta | ¿Puede el negocio operar y adaptarse con las limitaciones propuestas? |
| Comparación económica equivalente | Costes operativos actuales, costes del cambio, esfuerzo de transición, soporte continuo y supuestos sobre los beneficios | ¿Hemos comparado alcances equivalentes sin dar por hecho que los beneficios son ahorros efectivos? |
| Capacidad interna | Responsables de procesos identificados, participación necesaria, compromisos concurrentes y decisiones sobre la cobertura de sus funciones | ¿Puede el negocio aportar las personas y decisiones que exige esta opción? |
| Riesgos de la transición | Operaciones afectadas, soluciones temporales, responsabilidades de recuperación y cuestiones de continuidad pendientes | ¿Qué riesgos para el negocio acepta la dirección al financiar esta vía? |
| Evidencias aún necesarias | Preguntas abiertas, responsables y hallazgos que cambiarían la recomendación | ¿Aprobar ahora, aprobar una investigación acotada o aplazar? |
Adjunta los documentos de respaldo a la plantilla en lugar de llenarla de garantías sin pruebas. «Los usuarios participarán» debe traducirse en responsabilidades asignadas y una dedicación de tiempo acordada. «La integración es viable» debe identificar la interfaz, el resultado de negocio y las condiciones pendientes. «Menor coste operativo» debe cuadrar con una base de costes y un modelo operativo futuro explícito.
Asigna responsables del negocio antes de aprobar la implantación
Perrotta describe la infravaloración de la formación como un problema recurrente en su experiencia y la relaciona con un uso ineficaz del sistema y una reducción de los beneficios. En la decisión de inversión, esto implica presupuestar la participación del negocio y el aprendizaje, no realizar una revisión prematura de la puesta en producción. Una solución técnicamente plausible sigue necesitando personas que puedan definir, probar y adoptar los flujos de trabajo previstos.
Asigna a finanzas la responsabilidad de los supuestos económicos, a operaciones la de los resultados de los procesos y a tecnología la de las pruebas sobre arquitectura y dependencias. Nombra un responsable del negocio para cada beneficio importante y cada decisión de proceso pendiente. Cuando estas responsabilidades abarquen varios departamentos, el patrocinador ejecutivo debe resolver el traspaso de responsabilidades antes de financiar la ejecución.
Mantén separadas las decisiones posteriores. Una vez aprobada la vía de inversión, utiliza la evaluación del socio de implantación ERP para verificar quién ejecutará el trabajo. La autorización para operar en producción corresponde a una revisión posterior de preparación para la puesta en producción del ERP. Ninguna de ellas debe sustituir la decisión sobre si la inversión en sí está justificada.
Antes de aprobar la implantación, compara en paralelo los principales escenarios de mejora y sustitución. Exige a cada responsable que identifique el hallazgo pendiente con mayor probabilidad de cambiar la recomendación y encarga esa comprobación antes de comprometer el presupuesto de mayor alcance.
Si necesitas apoyo funcional o técnico para evaluar esos escenarios, comenta tus flujos de trabajo, limitaciones de integración y capacidad interna con los especialistas ERP de Digiventi.
