Es habitual que un perito informático reciba peticiones de presupuesto para determinar el grado de cumplimiento de un contrato de prestación de servicios informáticos, en los que el objetivo de dicho contrato era la implantación de un ERP comercial (Enterprise Resources Planning), que habitualmente debe ser parametrizado, es decir, adaptado, a las necesidades de la empresa. Muchas de estas implantaciones resultan fallidas o parcialmente fallidas y se requiere, por tanto, del informe de un perito informático colegiado que estudie el contrato, el documento de Especificación de Requisitos del Software, así como la documentación adicional aneja al proyecto, al objeto de elaborar un informe que permita sustentar una demanda contra la empresa que realizó la implantación.
En esta demanda, siempre sustentada en un peritaje informático (es imposible que la demanda a un procedimiento tan técnico prospere sin un informe pericial), se podrá solicitar el reembolso del montante abonado a la empresa por la parametrización fallida o parcialmente fallida del software ERP, así como (según la mejor decisión de los letrados), una posible indemnización por daños y perjuicios y, en algunos casos, por lucro cesante (peticiones que deberán sustentarse adecuadamente en los informes periciales económicos que sean precisos).
Existen muchos tipos de ERP, siendo los más conocidos el SAP ERP, el SAP Business One, el Navision (actualmente, Microsoft Dynamics Nav), el SAGE, etc. Todos ellos poseen diferentes módulos capaces de gestionar los distintos departamentos de una empresa (grande y mediana), así como los distintos procesos empresariales. Estos módulos son, tomando la referencia de SAP, los siguientes: Finanzas (FI), Contabilidad (CO), Recursos Humanos (HCM), Clientes -Client Relationship Management (CRM)-, Proveedores -Supplier Relationship Management (SRM)-, Materiales -Material Management (MM), Ventas -Sales and Distribution (SD)-, Producción -Production Planning (PP)-, Mantenimiento de Planta -Plant Maintenance (PM)-, Gestión de Proyectos -Proyect System (PS)-, etc. Todos ellos poseen especificidades en cada empresa, por lo que necesitan ser adaptados, siendo que, además, los procesos de interconexión entre dichos departamentos son diferentes en cada compañía, por lo que es necesario el modelado y parametrización de la comunicación entre los distintos módulos del ERP.
La mayoría de los fabricantes de ERPs comerciales poseen un conjunto de partners o asociados por todo el mundo. Se trata de empresas autorizadas a modificar y adaptar el software de base, las cuales se presupone han pasado por un proceso de examen y certificación de conocimientos por parte del fabricante, que debe acreditar, normalmente, que un porcentaje determinado de sus empleados y/o la empresa en su conjunto, poseen la certificación oficial del fabricante. Los ERPs más conocidos poseen su propio lenguaje de programación, su propio entorno de desarrollo, etc., en el que deben ser expertos los empleados del partner.
El proceso de parametrización es crítico, ya que suelen ser necesarias muchas jornadas de los expertos del partner en la sede de la empresa cliente, donde deben imbuirse de los procesos de la empresa, que posteriormente deberán modelar y adaptar en la implantación del ERP, modificando campos de las tablas de la base de datos, relaciones entre tablas, el acceso a la base de datos por parte del programa, procesos de comunicación entre departamentos de la empresa y hasta interfaces de usuario (que suelen ser de tipo formulario).
En este contexto y, debido, entre otras cuestiones, a la falta de regulación de la Ingeniería Informática en España, muchas implantaciones resultan fallidas o parcialmente fallidas, ya que los partners ajustan los precios con bajas temerarias para no perder el cliente, siendo que, finalmente, se detecta que, ni el tiempo planificado puramente para consultoría funcional de negocio (cuando los ingenieros del partner se desplazan al cliente a imbuirse de sus procesos de negocio), ni el tiempo planificado para la parametrización o adaptación del software, son suficientes, con lo que el proveedor comienza a perder dinero y, en algún punto del proceso, abandona la implantación. A este respecto ya existe alguna sentencia que dictamina como “abandono de obra”, el desistimiento o interrupción de la implantación o parametrización del ERP por parte de la empresa contratada, como por ejemplo la sentencia dictada por Juzgado de Primera Instancia nº 5 de Vitoria, el día 5 de enero de 2009.
En una implantación fallida o parcialmente fallida de un software ERP, el trabajo del perito informático colegiado consistirá en la determinación de si el software se ajusta a los requisitos especificados en el contrato de prestación de servicios (o de arrendamiento de obra, como ya se ha visto), así como si la documentación entregada se ajusta a la normativa aplicable. La diferencia entre un arrendamiento de obra y un arrendamiento de servicios no es baladí, ya que, si bien ambas figuras se enmarcan, dentro del Código Civil, en los contratos de arrendamiento, en los cuales las partes quedan obligadas de manera recíproca, a la cesión de un bien la parte contratada y al pago del precio estipulado la parte contratante; el arrendamiento de obra se enfoca en el resultado, es decir, en la entrega de la obra, mientras que el de servicios fija una remuneración por un tiempo determinado. El criterio diferenciador fundamental se encuentra en que en el contrato de arrendamiento de servicios se obliga a prestar una actividad durante un tiempo determinado, que puede estar medido en horas o jornadas, en tanto que, en el arrendamiento de obra se pacta teniendo en cuenta el resultado. Lo habitual es que este criterio diferenciador quede supeditado a la redacción del contrato.
Hay que tener en cuenta que, si se produce una interpretación restrictiva del contrato de prestación o arrendamiento de servicios en la implantación de un proyecto software de tipo ERP, en el momento en que la empresa contratada o partner logre demostrar que sus empleados trabajaron en el proyecto de implantación las horas o jornadas estipuladas en el contrato, dicha empresa podría verse liberada judicialmente de abonar la indemnización que la contratante hubiere estimado como legítima, esto es, al menos, la inversión económica realizada para la implantación que luego devino en fallida o parcialmente fallida. Por ello, es esencial contar con el asesoramiento legal oportuno y, por supuesto, con un perito informático colegiado como asesor tecnológico independiente, que guíe a la empresa contratante en todo el proceso, especialmente desde el principio del mismo, para evitar estos graves problemas que cada vez son más comunes y que, finalmente, suponen un gasto imprevisto y un perjuicio empresarial muy elevados para la compañía contratante.
En este marco, la normativa de proyectos de ingeniería informática, aprobada por el Consejo General de Colegios de Ingeniería en Informática, es el único reglamento existente a nivel nacional que relaciona la documentación que debe aportarse a un proyecto informático, con objeto de que dicho proyecto cumpla con unos mínimos estándares de documentación y sea mantenible, es decir, modificable (lo cual está autorizado por la diversa jurisprudencia existente en la materia, siempre y cuando el mantenimiento se circunscriba a que el proyecto informático se pueda seguir utilizando y, por supuesto, sin perjuicio de las cláusulas que las partes puedan incluir en el contrato de arrendamiento de obra o de servicios, que podrán ser aplicables o no). Esta normativa está codificada como “Norma CCII-N2016-02” y se titula “Norma Técnica para la realización de la Documentación de Proyectos en Ingeniería Informática”.
Al ser la única norma oficial de proyectos informáticos existente en el ámbito colegial de la Ingeniería Informática, siendo que, además de estar aprobada por el Consejo General, está inspirada en distintas normas nacionales e internacionales, esta norma puede y debe constituirse en referencia para que los peritos informáticos determinen si los proyectos informáticos, incluidos los de implantación o parametrización de sistemas ERP, cumplen con los mínimos requisitos de documentación exigibles en un proyecto informático. Además de determinar su ajuste a la normativa, el perito informático deberá dictaminar si el software es utilizable o no y, si es posible, el grado o porcentaje de utilización respecto a los requisitos predefinidos que fueron planteados.
Finalmente, será el juez el que tome la decisión, en base a la audiencia de las partes, de si el proyecto se ha ajustado al contrato o no y si corresponde devolución y/o indemnización, pero es obvio que un informe pericial informático, en el que además se compare la documentación entregada con la documentación requerida en base a la citada norma de proyectos informáticos, será una de las piedras angulares de un procedimiento o demanda civil para la recuperación de la inversión en la implantación o parametrización de un ERP que resultare fallida o parcialmente fallida. La elección de un perito informático colegiado para la realización del análisis de cumplimiento de la parte técnica del contrato y su ajuste a la normativa de proyectos, será también crucial, ya que se requiere de una formación y una experiencia profesionales de primer nivel para realizar, con todas las garantías, un informe de este tipo.