La implantación de un ERP constituye una de las inversiones tecnológicas más relevantes que puede realizar una organización. Soluciones como SAP, Odoo, Microsoft Dynamics NAV, Business Central y otros sistemas de gestión empresarial tienen como finalidad integrar los procesos de negocio y mejorar la eficiencia operativa de la compañía. Sin embargo, la realidad demuestra que una parte significativa de estos proyectos nunca llega a alcanzar una puesta en producción efectiva o lo hace tras importantes conflictos entre el cliente y el proveedor tecnológico.
Contrariamente a lo que muchas organizaciones creen al inicio del proyecto, los problemas más graves no suelen aparecer durante la firma del contrato ni durante las primeras fases de parametrización. En numerosos casos, las incidencias críticas afloran cuando los usuarios comienzan a recibir las formaciones funcionales o cuando se ejecutan las pruebas unitarias y las validaciones operativas previas a la entrada en producción.
Es precisamente en estas fases cuando la organización empieza a interactuar con el sistema de una forma similar a la que lo hará en su actividad diaria y cuando se comprueba si el ERP realmente responde a las necesidades reales del negocio.
Las formaciones: el primer momento en que los usuarios descubren la realidad del sistema
Durante los primeros meses de un proyecto ERP, gran parte del trabajo se desarrolla entre consultores, jefes de proyecto y responsables funcionales. Los usuarios finales suelen tener una participación limitada hasta que comienzan las sesiones de formación.
Es en este momento cuando muchas organizaciones descubren por primera vez cómo van a realizar sus tareas cotidianas dentro del nuevo sistema.
Durante las formaciones es frecuente que aparezcan comentarios como:
- «Este proceso no funciona como lo hacemos actualmente.»
- «Necesitamos un campo adicional que no existe.»
- «No podemos generar este informe.»
- «La trazabilidad que necesitamos no está disponible.»
- «No podemos gestionar determinadas excepciones operativas.»
- «El circuito de aprobación no contempla nuestro procedimiento interno.»
- «La integración con otro sistema no realiza lo que esperábamos.»
En muchas ocasiones, estas observaciones no corresponden a errores técnicos del ERP, sino a discrepancias entre las expectativas del cliente y lo que realmente fue definido, analizado, presupuestado o desarrollado durante el proyecto.
Cuando estas diferencias aparecen en fases avanzadas, las consecuencias suelen ser importantes, ya que cualquier modificación implica nuevas parametrizaciones, desarrollos adicionales, retrasos en la planificación e incrementos presupuestarios.
Las pruebas unitarias: el momento donde se detectan las deficiencias funcionales
Las pruebas unitarias constituyen otra de las fases donde afloran gran parte de los problemas que posteriormente derivan en conflictos contractuales.
Durante estas pruebas se valida individualmente el funcionamiento de procesos específicos, comprobando que cada funcionalidad responde adecuadamente a los requisitos establecidos.
Es habitual que durante estas validaciones aparezcan incidencias relacionadas con:
- Procesos incompletos.
- Reglas de negocio incorrectamente implementadas.
- Cálculos erróneos.
- Integraciones defectuosas.
- Problemas de rendimiento.
- Procesos contables no operativos.
- Incidencias en compras, ventas o logística.
- Gestión incorrecta de almacenes o inventarios.
- Informes insuficientes o incompletos.
- Funcionalidades desarrolladas parcialmente.
Cuando las pruebas unitarias comienzan a acumular incidencias de elevada criticidad, la organización suele cuestionar la viabilidad del proyecto y la posibilidad real de alcanzar una puesta en producción exitosa.
Cuando el partner no recogió correctamente los requisitos del cliente
Uno de los escenarios más frecuentes que analizamos como peritos judiciales especializados en ERP se produce cuando determinadas necesidades del negocio fueron comunicadas durante las reuniones iniciales, pero nunca quedaron reflejadas adecuadamente en la documentación funcional o contractual.
Durante las sesiones comerciales y los talleres de análisis es habitual que el cliente explique numerosos procesos internos que considera esenciales para su actividad. Sin embargo, si dichos procesos no se documentan correctamente, pueden quedar fuera del alcance real del proyecto.
La consecuencia suele aparecer meses después, durante las formaciones o las pruebas unitarias, cuando los usuarios descubren que determinadas funcionalidades no existen o no funcionan como esperaban.
En estos casos resulta imprescindible analizar toda la documentación generada durante el proyecto para determinar si realmente existía un compromiso del proveedor respecto a dichas funcionalidades o si únicamente existían expectativas no formalizadas.
Cuando el cliente no comunicó todos los requisitos necesarios
También existen numerosos proyectos en los que el origen del problema no se encuentra en el proveedor, sino en una identificación incompleta de los requisitos por parte del cliente.
En organizaciones medianas y grandes es habitual que intervengan múltiples departamentos con necesidades distintas. Si algunos usuarios clave no participan adecuadamente en las fases de análisis o determinadas áreas no comunican sus necesidades reales, es posible que los requisitos aparezcan demasiado tarde.
Cuando los usuarios comienzan las formaciones o ejecutan las pruebas funcionales suelen surgir necesidades que nunca fueron planteadas durante el análisis inicial.
En estos casos aparecen situaciones como:
- Procesos especiales de facturación.
- Operaciones internacionales no contempladas.
- Excepciones logísticas complejas.
- Informes regulatorios específicos.
- Necesidades de integración con terceros.
- Procedimientos internos no documentados.
La aparición tardía de estos requisitos genera frecuentemente conflictos acerca de quién debe asumir los costes y los retrasos derivados de su incorporación al sistema.
Los casos de uso insuficientemente definidos
Otra causa recurrente de fracaso en proyectos ERP es la definición incompleta de los casos de uso.
En muchos proyectos se documentan los procesos estándar, pero no se analizan adecuadamente los escenarios excepcionales que forman parte de la operativa diaria de la empresa.
Esta situación suele pasar desapercibida durante las fases iniciales, pero emerge con claridad cuando los usuarios realizan formaciones prácticas o ejecutan pruebas sobre situaciones reales.
Es entonces cuando se detecta que el sistema no contempla determinadas casuísticas esenciales para el negocio, obligando a replantear parte del proyecto.
El papel del perito judicial especializado en ERP
Cuando un proyecto queda bloqueado durante las formaciones, las pruebas unitarias o las validaciones funcionales, suele iniciarse una discusión entre cliente y proveedor acerca de las causas reales del problema.
Determinar técnicamente quién tiene razón requiere un análisis especializado que vaya mucho más allá de las opiniones de las partes implicadas.
La labor del perito judicial consiste en reconstruir objetivamente la historia completa del proyecto analizando contratos, ofertas, documentos funcionales, actas de reuniones, correos electrónicos, órdenes de cambio, incidencias registradas, evidencias de pruebas y documentación de formación.
A través de este análisis es posible determinar:
- Qué funcionalidades fueron realmente contratadas.
- Qué requisitos fueron documentados.
- Qué elementos quedaron fuera del alcance.
- Qué incidencias existían durante las pruebas.
- Si el sistema era apto para entrar en producción.
- Si existían defectos funcionales relevantes.
- Si el cliente comunicó adecuadamente sus necesidades.
- Si el proveedor actuó conforme a las buenas prácticas del sector.
Especialistas en peritajes de proyectos ERP
En Legal Auditors actuamos como peritos judiciales informáticos especializados en proyectos ERP complejos y conflictos derivados de implantaciones tecnológicas fallidas.
Disponemos de experiencia en el análisis pericial de proyectos basados en SAP, Odoo, Microsoft Dynamics NAV, Business Central y otros sistemas de gestión empresarial, interviniendo tanto en procedimientos judiciales como en procesos de negociación, mediación y arbitraje.
Nuestro trabajo consiste en analizar objetivamente las causas que han impedido que un proyecto alcance una puesta en producción satisfactoria, identificando si los problemas derivan de una definición incorrecta de requisitos, de una ejecución deficiente por parte del proveedor, de una participación insuficiente del cliente o de una combinación de varios factores.
La experiencia demuestra que muchas implantaciones ERP no fracasan durante el desarrollo técnico, sino cuando los usuarios comienzan a trabajar realmente con el sistema durante las formaciones y las pruebas funcionales. Es en ese momento cuando afloran las diferencias entre lo esperado y lo entregado, y donde un peritaje especializado puede resultar fundamental para determinar responsabilidades y aportar evidencias técnicas sólidas en defensa de los intereses de las partes implicadas.
