Los proveedores de software defectuoso no están exentos de tener que asumir responsabilidad civil por los daños y perjuicios ocasionados, a la par que la restitución de las cantidades abonadas por sus clientes. En este tipo de procesos resulta vital la prueba pericial informática. A continuación se ilustrará la casuística en base a reciente sentencia de la Audiencia Provincial de Madrid.
Sentencia condenatoria a proveedor de software defectuoso
La reciente Sentencia de la Audiencia Provincial de Madrid nº 6/2024, de 10 de Enero de 2024 (ECLI: ES:APM:2024:48), resolviendo Recurso de Apelación nº 473/2023, ilustra muy bien la casuística habitual en este tipo de litis en el ámbito civil, así como la importancia de la prueba pericial informática para sustentar las pretensiones de cada una de las partes.
Antecedentes de hecho
Por Juzgado de 1ª Instancia nº 26 de Madrid se dictó Sentencia de fecha 27/09/2022, cuyo fallo es el tenor siguiente:
» ESTIMO PARCIALMENTE LA DEMANDA presentada por ASOCIACIÓN DE INVESTIGACIÓN DE MATERIALES PLÁSTICOS Y CONEXAS (AIMPLAS), representada por la Procuradora de los Tribunales doña Beatriz de Mera González, frente a ALTRAN INNOVACIÓN S.L.U., representada por la Procuradora de los Tribunales doña Pilar Rico Cadenas, y:
1º.- Declaro resuelta de pleno derecho, la PROPUESTA TÉCNICO ECONÓMICA PROYECTO «IMPLANTACION LIMS» de fecha 24 de abril de 2015 y la anudada PROPUESTA TÉCNICO ECONÓMICA PROYECTO «BOLSA HORAS MANTENIMIENTO SISTEMA LIMS» por incumplimiento contractual esencial de Altran Innovación S.L.U.
2º.- CONDENO A ALTRAN INNOVACIÓN S.L.U., representada por la Procuradora de los Tribunales doña Pilar Rico Cadenas, A PAGAR A AQUÉLLA LA SUMA DE CIENTO TREINTA Y SEIS MIL TRESCIENTOS VEINTIÚN EUROS CUARENTA Y SIETE CÉNTIMOS DE EURO (136.321,47 €), más el interés legal del dinero devengado desde la reclamación judicial incrementado en dos puntos.
Sin expresa imposición de las costas procesales a ninguna de las partes.
ESTIMO PARCIALMENTE LA RECONVENCIÓN instada por ALTRAN INNOVACIÓN S.L.U. frente a ASOCIACIÓN DE INVESTIGACIÓN DE MATERIALES PLÁSTICOS Y CONEXAS (AIMPLAS) y CONDENO A AIMPLAS A PAGAR A ALTRAN INNOVACIÓN S.L.U. la cantidad de DIECINUEVE MIL SEISCIENTOS CUARENTA Y TRES EUROS TREINTA Y UN CÉNTIMOS DE EURO (19.643,31 €) más el interés legal del dinero desde la fecha de la reclamación judicial (fecha de presentación de la reconvención).
Sin expresa imposición de las costas procesales a ninguna de las partes».
Fundamentos de Derecho
Fundamento Primero
Por la representación procesal de la mercantil ASOCIACIÓN DE INVESTIGACIÓN DE MATERIALES PLÁSTICOS y CONEXAS (AIMPLAS), se interpuso demanda contra la mercantil ALTRAN INNOVACIÓN SLU (ALTRAN), en la que se ejercita acción de resolución derivada de incumplimiento contractual y reclamación de la suma de 226.570,84 euros. Con relación al encargo realizado a la demandada para la implantación de un LIMS (Laboratory Informatión Management System), que es un software para gestionar de forma integral todos sus servicios de laboratorios, ya que dispone de tres: Químico, Físico-Mecánico y de Automoción.
Se aporta como documento 1 de la demanda, el mail de fecha 24 de abril de 2015, en el que se acepta la propuesta edición 1.3 ref. 20150PP00109538, por importe total de 86.180 euros. Se aporta como documento 2, la Propuesta Técnico Económica, en el que se recoge las características que debía cumplir, con un plazo de ejecución e implantación de seis meses, desde abril a septiembre de 2015. Se aduce que desde su implantación el software fue un caos, registraba continuas incidencias y errores, que lo hacen inservible por los problemas que generaba con los clientes, hasta que se deja de utilizar el 27 de abril de 2017. Se reclama la restitución de la cantidad abonada de 112.156,18 euros y una indemnización por los daños y perjuicios causados por las horas que sus trabajadores malgastaban consecuencia del incorrecto funcionamiento del sistema, que el informe pericial aportado con la demanda cifra en la suma de 114.414,66 euros.
En la contestación a la demanda se aduce que las funcionalidades del software LIMS fueron determinadas por AIMPLAS y han sido debidamente ejecutadas. Se corrigieron todas las incidencias y la resolución contractual es injustificada, negando que se encargase un nuevo LIMS con las mismas funcionalidades a un tercero. Se solicita por vía de reconvención la suma de 17.218,30 euros como parte del precio que resta por pagar y 1.977,07 euros pendientes de pago de la bolsa de horas. Como aumento de costes por modificaciones requeridas por IMPLAS, según informe técnico aportado como documento 31 de la reconvención, se reclama la suma de 74.872 euros.
En fecha 27 de septiembre de 2022 se dictó sentencia por el Juzgado de 1ª Instancia nº 26 de Madrid en la que se estima parcialmente la demanda: 1.- Se declara resuelto de pleno derecho la propuesta Técnico Económica Proyecto «Implantación LIMS», de fecha 24 de abril de 2015 y la anudada Propuesta Técnico Económica Proyecto «Bolsa Horas Mantenimiento Sistema LIMS», por incumplimiento contractual esencial de ALTRAN INNOVACIÓN SLU; 2.- Condena a la demandada a pagar a la actora la suma de 136.321,47 euros, más el interés legal del dinero devengado desde la reclamación judicial incrementado en dos puntos. Sin hacer expresa imposición de las costas procesales. Estima parcialmente la reconvención y condena a la reconvenida AIMPLAS a pagar a ALTRAN la suma de 19.643,31 euros, más el interés legal del dinero desde la fecha de la reclamación judicial, sin hacer expresa imposición de las costas procesales.
Según la sentencia, de la prueba documental, testifical y pericial practicada en autos, se acredita que se produjo la frustración del fin práctico perseguido por las partes con el contrato suscrito, que era de implantación de un sistema de mejorar las prestaciones del que venía utilizando la actora. Se refiere que frente a los cinco meses previstos inicialmente para la implantación del software, se prolongó casi un año más, hasta julio de 2016. Cuando se empezó a utilizar, los trabajadores de AIMPLAS constataron que el LIMS les obligaba a hacer continuas correcciones, lo que obligó a su desconexión dos años después de su implantación y convocar un nuevo concurso para la implantación de un nuevo LIMS. Considera la sentencia que concurre la causa de resolución del art. 1.124 del Código Civil, ya que el software elaborado e instalado por ALTRAN no permitía a la actora llevar a cabo la gestión de la empresa, conforme a sus necesidades, debido a las incidencias que se repetían.
En cuanto al perjuicio económico del referido incumplimiento, según el Juez a quo, de la cantidad abonada por AIMPLAN de 87.035,30 euros, hay que descontar la suma de 10.430,20 euros correspondiente a la gestión de informes, 10.424,15 euros correspondiente a la mitad de la partida de gestión de solicitudes y 10.424,15 euros correspondiente a la mitad de la partida de gestión de servicios. Se estima parcialmente la reclamación del precio en la suma de 55.756,80 euros.
En relación con la bolsa de horas de mantenimiento del sistema, se reclaman 480 horas en 12 meses, que se contrató el 12 de noviembre de 2015 hasta el 12 de noviembre de 2016. Se inicia la funcionalidad del sistema el 1 de septiembre de 2016, por lo que no pudo ofrecerse como mantenimiento cuando aún o se había entregado al cliente y entiende que son para subsanar fallos del LIMS imputables a la demandada o nuevas aplicaciones no previstas contractualmente, por lo que debe reembolsarse a la actora la suma de 25.120,88 horas abonadas por bolsa de horas, que junto con la anteriormente referida de 55.756,80 euros por parte del precio, hace un total de 80.877,68 euros a reembolsar a AIMPLAS.
En concepto de horas dedicadas por los trabajadores de AIMPLAS a rehacer trabajos por errores creados por el defectuoso funcionamiento del software, se reclama la suma de 114.414,66 euros, según los informes periciales de los Sres. Belarmino y Carlos, atendiendo a 785 horas invertidas por el personal técnico y 1.400 horas de las empleadas por el personal TIC. En la sentencia, se tiene en cuenta la declaración de los testigos y las periciales, así como que el Perito Sr. Carlos hace el cálculo económico sin tener en cuenta que las horas calculadas por el Sr. Belarmino lo son en su totalidad y no por año, por lo que no son 4.509 horas. Haciendo un cálculo proporcional, la sentencia apelada reduce la indemnización reclamada a la suma de 55.443,79 euros.
Según la sentencia, AIMPLAS debe percibir 136.321,47 euros (80.877,68 euros más 55.443,79 euros).
En cuanto a la demanda reconvencional. Se reclaman las siguientes cantidades:
1.- 17.218,30 euros IVA incluido, que restan por abonar del encargo procesional, que afirma se ejecutó conforme con los requerimientos y funcionalidades interesadas, más intereses devengados desde que debió facturarse, el 4 de octubre de 2016;
2.- 1.977,07 euros IVA incluido, que queda por abonar de la bolsa de horas; 3.- 74.872 euros por sobrecostes en concepto de modificaciones en las funcionalidades técnicas del sistema LIMS, solicitadas por AIMPLAS, según informe técnico de D. Ezequiel, Gerente de la Unidad Técnica de ALTRAN.
La sentencia apelada, atendiendo al citado informe técnico, ratificado por el informe pericial emitido por el Perito Sr. Fructuoso y contradicho por el informe pericial del Sr. Belarmino, teniendo en cuenta que el propio Sr. Ezequiel reconoce que los trabajos se desarrollaron entre octubre de 2015 y diciembre de 2016, es decir, durante el periodo de implantación o correcciones, no los considera como mejora ni evolutivos no previstos en contrato, por lo que solo admite la aplicación de las horas extras para la aplicación del escritorio y condena a la reconvenida AIMPLAS a pagar a ALTRAN la suma de 19.643,31 euros, más el interés legal del dinero desde la fecha de la reclamación judicial.
Fundamento Segundo
Por la representación procesal de la mercantil ASOCIACIÓN DE INVESTIGACIÓN DE MATERIALES PLÁSTICOS y CONEXAS (AIMPLAS), se interpone recurso de apelación.
Según el recurso, la valoración de la prueba que se hace en la sentencia es correcta, porque entiende que de la misma queda acreditado que el software elaborado e instalado por ALTRAN no permitía a la actora atender las funcionalidades para las que fue encargado, ante las continuas incidencias que presentaba, lo que llevar a declarar resuelto el contrato, pero se rechazan las consecuencias que de ello se derivan en la sentencia.
Se aportan como prueba documental distintos mails remitidos entre las partes para acreditar el incorrecto funcionamiento del sistema. Como documento 4 de la demanda mail de fecha 14 de marzo de 2016, en el que se recopilan distintas incidencias acreditativas de los problemas que generaba el software, siendo esta sobre funciones muy básicas, como no transportar los importes presupuestados a la factura definitiva, no arrastrar los descuentos y no sumar líneas a la hora de hacer las facturas, calcular mal el IVA, no restaba las cantidades previamente abonadas por el cliente… Como documentos del 5 a 31 se aportan mails que acreditan las incidencias que se crearon con los clientes como consecuencia del mal funcionamientos del LIMS, desde la implantación del sistema hasta el 29 de marzo de 2017. Es especialmente relevante el documento 30 de la demanda, mail de fecha 20 de enero de 2017, en el que se plasma la difícil situación creada por los clientes como consecuencia del mal funcionamiento del sistema. Como documento 32 de la demanda se aporta, mail del Jefe del Departamento informático de AIMPLAS, Sr. Millán, de fecha 15 de febrero de 2017, en el que mostraba sus quejas a ALTRAN por las deficiencias del software y daba plazo para subsanarlos, debemos apreciar que habían pasado ya muchos meses desde que se implantó y pese a ello seguían produciéndose continuas incidencias, con el consiguiente perjuicio para trabajadores y clientes.
También se hace una correcta valoración de la prueba testifical, en la que se tiene en cuenta la declaración de los testigos Sra. Soledad, que era empleada de AIMPLAS y se ocupaba de la gestión de informe técnicos y presupuestos, gestionar la administración del laboratorio y clientes, que se jubiló un mes antes de cerrar el LIMS; también del Sr. Simón, que se fue de la empresa un mes después de la desconexión del programa, por lo que ambos gozan de una imparcialidad de la que carecen el resto de testigos, que siguen manteniendo relación laboral con las empresas litigantes, ambos han sido claros al señalar que hasta el momento de abandonar la empresa, los fallos del Software eran continuos y su funcionamiento muy deficiente, sin que se llegara a solucionar por la demandada, siendo el mismo persistente desde que se implantó. Los fallos eran de bulto, como descuentos en presupuestos mal aplicados, datos de una empresa en presupuestos de otra distinta, cálculo mal del IVA, problemas al clonar, falta de trazabilidad… Las incidencias quedan perfectamente reflejadas en el documento nº 3 de la demanda, ya que en la fase de adaptación al nuevo sistema, se acordó entre las partes un sistema de ticketing, que es un sistema de registro de las incidencias y peticiones relacionadas con un sistema informático para su seguimiento, en él que constan 780 incidencias registradas en el periodo comprendido entre el 19 de septiembre de 2016 y el 27 de abril de 2017, cuando se decidió dejar de utilizar el LIMS adquirido.
También se hace mención en la sentencia a la prueba pericial, emitida por los Peritos Sres. Belarmino y Fructuoso, conforme a la cual entiende que queda acreditado que era conforme a derecho la resolución contractual llevada a cabo por AIMPLAS, por incumplimiento esencial previo de ALTRAN de las condiciones contractuales, consecuencia de las continuas incidencias por un deficiente proyecto y ejecución del software.
En el recurso de apelación se está de acuerdo con que el arrendamiento de obra obliga a un resultado y que el incumplimiento de la demandada ha sido esencial y ha impedido el fin práctico del contrato, frustrando sus expectativas. Pone en valor que, una vez desconectado el software, dicha mercantil lo encargó a una tercera empresa y debió abonarle a ésta una cantidad importante por su trabajo, según facturas aportadas como documentos nº 34 a 44 de la demanda). Por todo lo expuesto, entiende que estamos ante un incumplimiento total del contrato y no procede el pago de cantidad alguna por un software ineficaz. La Sala lo comparte.
Como indica la Sentencia del Tribunal Supremo de 4 de Septiembre de 2014, «El artículo 1124 del Código Civil no lo dispone de modo expreso, pero se interpreta en el sentido de que no basta cualquier incumplimiento para provocar la resolución de la relación contractual – sentencias de 16 de enero de 1975 , 25 de febrero de 1978 , 7 de marzo de 1983 , 22 de marzo de 1985 , entre otras muchas. Es más, la jurisprudencia – sentencias 366/2008, de 19 de mayo , 35/2012, de 14 de febrero , 162/2012, de 29 de marzo , entre otras muchas – ha precisado en los últimos años que, para reconocerle fuerza resolutoria, el incumplimiento, además de no excusable, ha de ser esencial, ya porque la estricta observancia de la obligación forme parte de lo pactado en el contrato; ya porque prive sustancialmente a la parte perjudicada de aquello que tenía derecho a esperar de acuerdo con él, a menos que la otra no haya previsto ni podido prever razonablemente tal resultado; ya porque, siendo intencional el comportamiento del deudor, la parte perjudicada crea razonablemente que no puede confiar en un cumplimiento futuro.»
Más recientemente la STS del tribunal Supremo de 30 de julio de 2020 ha declarado: » Para que pueda ejercitarse con éxito la facultad de resolución de los contratos generadores de obligaciones recíprocas, la jurisprudencia de esta Sala se ha inclinado decididamente por exigir la frustración de la finalidad perseguida por los contratantes, prescindiendo de la «voluntad deliberadamente rebelde», exigida en etapas anteriores».
La sentencia aplica la doctrina jurisprudencial referida y declara la resolución contractual, al considerar que las incidencias que presentaba el software litigioso eran de tal entidad y continuidad desde antes de su implantación hasta la desconexión del mismo, que lo hace inservible para las funcionalidades que fueron encargadas. El artículo 1124 del Código Civil permite que la contratante no incumplidora solicite la resolución de contrato o el cumplimiento, en ambos casos con indemnización de daños y perjuicios.
En el caso de autos, la actora solicita la resolución contractual y, además, la indemnización de daños y perjuicios. La resolución contractual produce sus efectos, no desde el momento de la extinción de la relación obligatoria, sino retroactivamente desde su celebración, es decir, no con efectos ex nunc sino ex tunc , lo que supone volver al estado jurídico preexistente como si el negocio no se hubiera concluido, con la secuela de que las partes contratantes deben entregarse las cosas o las prestaciones que hubieran recibido en cuanto la consecuencia principal de la resolución es destruir los efectos ya producidos, tal como se ha establecido para los casos de rescisión en el art. 1295 del Código Civil, al que expresamente se remite el art. 1124 del mismo Cuerpo legal , efectos que sustancialmente coinciden con los previstos para el caso de nulidad en el art. 1303 y para los supuestos de condición resolutoria expresa en el art. 1123. ( SSTS 25 de Noviembre de 2016, 17 de junio de 1986 , citada en las de 5 de febrero de 2002 , 27 de octubre de 2005 , 26 de marzo de 2012 y 10 de diciembre de 2015 ).
El motivo del recurso debe ser estimado.
Fundamento Tercero
Respecto de la errónea valoración de la prueba que se argumenta como segundo motivo del recurso, es preciso recordar que las facultades del tribunal de apelación se extienden también a una nueva valoración de la prueba y que la misma viene facilitada por el hecho de contar con la grabación íntegra del juicio celebrado en primera instancia, siendo así que en la apelación el tribunal está facultado para realizar una revisión total del juicio de hecho y de derecho efectuado en primera instancia, con la única excepción que comporta el necesario respeto a los principios que rigen el recurso en relación con los solicitado por el recurrente.
La sentencia del Tribunal Constitucional de 18 septiembre, Sala Segunda, 18-09-2000 ( STC 212/2000) de 2000, afirma lo siguiente: «Este Tribunal ya ha tenido ocasión de señalar que, en nuestro sistema procesal, la segunda instancia se configura, con algunas salvedades en la aportación del material probatorio y de nuevos hechos, como una ‘revisio prioris instantiae’ , en la que el Tribunal Superior u órgano ‘ad quem’ tiene plena competencia para revisar todo lo actuado por el juzgador de instancia, tanto en lo que afecta a los hechos (quaestio facti) como en lo relativo a las cuestiones jurídicas oportunamente deducidas por las partes (quaestio iuris), para comprobar si la resolución recurrida se ajusta o no a las normas procesales y sustantivas que eran aplicables al caso, con dos limitaciones: la prohibición de la ‘reformatio in peius’, y la imposibilidad de entrar a conocer sobre aquellos extremos que hayan sido consentidos por no haber sido objeto de impugnación ( ‘tantum devolutum quantum appellatum’)…». En este mismo sentido se pronuncia en la sentencia de 29 de noviembre de 2005.
Según el recurso, la valoración de la prueba que se hace en la sentencia no es correcta porque ningún modelo funcionó correctamente. Se impugna el pronunciamiento de la sentencia en el que no se reconoce como perjuicio la partida de aceptación del proyecto, por importe de 34.908,50 euros, con el argumento de que el proyecto se elaboró y los fallos se concretan en módulos. El pago de la referida cantidad se hizo cuando se aceptó el presupuesto y antes de que comenzaran los trabajos. Según la Propuesta Técnico Económica, aportada como documento nº 2 de la demanda, esta partida cubría las fases de lanzamiento del proyecto y análisis previas a la entrega de los módulos, servía para definir la forma más detallada los diferentes requerimientos que disponga el sistema y harán referencia a las necesidades funcionales, modos de operación de restricciones y necesidades técnicas, etc… El LIMS constaba de tres módulos: de gestión de solicitudes, de gestión de servicio y de gestión de informes. ALTRAN asumía el buen fin del proyecto, con obligación de elaborar e implantar el sotfware y con facultades de supervisión, es decir, a dicha mercantil correspondía contractualmente conocer las necesidades de la actora y realizar un correcto estudio en fase de elaboración del proyecto. El plazo de ejecución e implantación del LIMS era de 6 meses, debiendo iniciarse en abril y debiendo estar finalizado en septiembre del mismo año 2015, aunque dicho plazo fue pospuesto por acuerdo de las partes. En la fase de adaptación al nuevo sistema, se acordó entre las partes un sistema de ticketing, que es un sistema de registro de las incidencias y peticiones relacionadas con un sistema informático para su seguimiento. Consta aportado como documento 3 de la demanda y en él constan 780 incidencias registradas en el periodo comprendido entre el 19 de septiembre de 2016 y el 27 de abril de 2017, cuando se decidió dejar de utilizar el LIMS adquirido.
Según la testifical, tal y como recoge la sentencia apelada, los contactos previos entre responsables y técnicos de las litigantes, fueron insuficientes, lo que evidentemente dificultó conocer con exactitud los trabajos necesarios para desarrollar un LIMS adecuado a las necesidades de AIMPLAS. No obstante, caso de que no hubiera habido una información adecuada de AIMPLAS sobre cuáles eran sus necesidades, previamente a realizar el proyecto, como aduce ALTRAN, una vez implantado y ante las continuas incidencias que presentaba, durante el largo periodo de implantación de más de un año, debieron darse soluciones a las deficiencias que presentaba el sistema, lo que no se hizo sino que se mantuvieron hasta la finalización del contrato. Habiéndose incluso acordado, en noviembre de 2015, ante las continuas incidencias, la contratación de una bolsa de horas para resolverlas, pero siguieron repitiéndose los problemas hasta el momento del cierre del sistema, como se recoge en el documento 3 de la demanda y declaran los usuarios del mismo, que han declarado como testigos. A tenor de lo expuesto, se reconoce como perjuicio la partida de aceptación del proyecto, por importe de 34.908,50 euros.
Así mismo, el recurso impugna la valoración de la prueba que se hace en la sentencia porque ningún modelo funcionó correctamente. Según la sentencia, solo procede la devolución de la mitad del importe abonado correspondiente al módulo de gestión de solicitudes, ya que se pudo utilizar parcialmente. Según el documento 2 de la demanda, el trabajo a realizar por dicho módulo era registrar en el sistema la solicitud de un cliente, indicar los trabajos a realizar, ensayos, indicar muestras, hacer el presupuesto y enviarlo al cliente. Los usuarios que han declarado como testigos ha sido claros en cuanto a que no había manera de trabajar con fiabilidad con el sistema. La Sra. Soledad, el Sr. Simón, ya hemos mencionado su testimonio anteriormente, la Sra. Felicisima, también refiere problemas de programa para aplicar descuentos, calculaba mal el IVA, no clonaba. La Sra. Julia, atendía las quejas de los clientes, que se quejaban de que no se había aplicado en los presupuestos los descuentos, retrasos en la recepción de los mismos y ello era debido a un atasco derivado de la utilización del LIMS, se facturaban cantidades distintas de las presupuestadas. Quejas que se recibían cada semana.
La declaración de los testigos, es ratificado por el documento 3 de la demanda, sistema ticketing sobre registro de incidencias y peticiones relacionadas con el sistema informático para su seguimiento, que registró 780 incidencias en el periodo comprendido entre el 19 de septiembre de 2016 y el 27 de abril de 2017, cuando se dejó de utilizar. Se aprecia que en su mayor parte eran incidencias con la elaboración de los presupuestos, que eran constantes y durante todo el tiempo en que el sistema se utilizó hasta su desconexión. Sobre esta cuestión técnica, es fundamental el informe pericial emitido por el Perito Sr. Belarmino, aportado como documento nº 33 de la demanda, que recoge de forma exhaustiva los importantes errores del software y que existen partes del mismo no desarrolladas.
El módulo de gestión de solicitudes no ha funcionado correctamente, por lo que procede la devolución total de las cantidades pagadas por la demandada, por importe de 20.848,30 euros.
En cuanto al módulo de gestión de servicios, según la sentencia, solo procede la devolución del 50% del importe abonado porque también se utilizó parcialmente. Según el documento 2 de la demanda, sus funciones eran la puesta en servicio del trabajo en curso, creación de datos de trabajo, factura prepago, listado de trabajo en curso, asignación en ensayos y tareas, asignación de técnicos , asignación de material, seguimiento de trabajos en curso, introducción de datos del informe de ensayos, introducción de datos del informe de ensayos, introducción de datos de los métodos de ensayo, introducción manual de datos tabulares, importación de ficheros de laboratorios, generación de estadísticas y finalización de trabajos para emisión de informes. Según el documento 3 de la demanda, las incidencias en el módulo de servicios fueron más de sesenta y constantes desde el 20 de septiembre de 2016 al 18 de abril de 2017. La testigo Sra. Purificacion, que fue la trabajadora de AIMPLAS que más lo utilizó, en su condición de Directora del Laboratorio Físico Mecánico, declaró en el juicio que se iba a sustituir la hoja Excel en la aplicación LIMS, pero no llegó a funcionar, no pudieron pasar la hoja Excel al sistema LIMS, se intentó ver como se solucionaba, pero lo que se optó por seguir utilizando las hojas Excel con unos cambios para que el sistema LIMS fuera capaz de tomar los datos, pero tampoco funcionaba bien, nunca pudieron emitir los informes automáticos que era el objetivo del programa.
El módulo de gestión de servicios no ha funcionado correctamente, por lo que procede la devolución total de las cantidades pagadas por la demandada, por importe de 20.848,30 euros.
El último motivo del recurso impugna la estimación parcial de la reconvención, en relación con la estimación del extra relativo a la aplicación del escritorio, que no funcionó nunca. Como documento nº 31 de la reconvención se aporta informe técnico del D. Ezequiel, Gerente de la Unidad Técnica de ALTRAN, que justifica las horas extras para la aplicación del escritorio, entre marzo a octubre de 2016. El mismo carece de la objetividad necesaria, dada la especial relación que mantiene con la sociedad. La usuaria del mismo, la Sra. Soledad, que ya no trabaja para la entidad apelante, junto con el Sr. Millán, han insistido en su testimonio sobre la inhabilidad del mismo, dadas las múltiples y continuas incidencias por fallos de esa aplicación de escritorio.
A tenor de lo expuesto, declarada la resolución contractual por incumplimiento de la demandada ALTRAN, procede condenar a dicha mercantil al pago a la apelante de la suma de 112.156,18 euros, en concepto de devolución del las cantidades abonadas, además del abono de la suma de 55.433,79 euros, a que es condenada en la sentencia apelada, en concepto de indemnización de daños y perjuicios por las horas dedicadas por los trabajadores de AIMPLAS a rehacer trabajos consecuencia de los errores creados por el defectuoso funcionamiento del software, que no es objeto del recurso de apelación. Procede la desestimación de la demanda reconvencional e imposición de las costas procesales a la reconviniente.
Fundamento Cuarto
Por la representación procesal de la mercantil ALTRAN INNOVACIÓN SLU (ALTRAN) se interpone recurso de apelación. En el mismo se niega que haya incumplimiento esencial del contrato que justifique la resolución contractual. Aduce que de la prueba practicada ha quedado acreditado que del software litigioso no funcionaba total o parcialmente, el módulo de informes, parte del módulo de servicios y parte del módulo de gestión. Así se reconoce en la sentencia apelada, en que también se afirma que ha quedado acreditado que AIMPLAS había incumplido previamente sus obligaciones de pago de una parte del precio pactado, en concreto el hito de entrega del proyecto y del hito final de la bolsa de horas, por lo que no queda justificada la resolución contractual. Además, se indica que según contrato, AIMPLAS tenía que definir las funcionalidades del sistema y ALTRA ejecutarlo. El encargo fue el desarrollo e implementación de 110 requerimientos o funcionalidades definidas por AIMPLAS, contenidas en el documento 3 de la contestación.
Según el recurso ALTRAN ha cumplido con lo contratado. Las incidencias registradas en el Ticketing no todas eran errores del sistema y se indica que así lo declaran en el juicio los testigos Sres. Millán, Raúl, Rubén y Ezequiel. En cuanto a la valoración de la prueba testifical, como ya ha señalado esta Sala en varias sentencias, debe tenerse en cuenta la regla máxima de la sana crítica recogida en el artículo 376 de la Ley de Enjuiciamiento Civil , apuntando que la apreciación del referido medio probatorio es puramente discrecional del órgano judicial, dado que la norma citada no contiene reglas de valoración tasada que se puedan violar, de forma que la impugnación solo procede cuando se constate que la apreciación de los testimonios ofrecidos es ilógica o disparatada. Debemos tener en cuenta que dichos testimonios son contradichos por la declaración de las testigos usurarias del mismo Sras. Soledad, Felicisima, Purificacion y Julia, como ya hemos expuesto en el fundamento jurídico segundo de esta resolución y que damos por reproducidos para evitar reiteraciones innecesarias. Testigos que no eran técnicos, pero que en su condición de usurarias eran quienes padecían las incidencias del software y eran conocedoras de las mismas.
Además, se reconoce en el propio recurso la existencia de incidencias relativas a descuadre de recuadre de redondeos, cálculo del IVA, descuadre de gestión de abonos y prepagos múltiples, bloqueo en envío de presupuesto, descuadre de coincidencia de resultados entre la factura y el presupuesto, problemas al clonar y errores en las direcciones y contactos. Incidencias importantes, que se dice que fueron solventadas, pero las testigos usuarias del sistema lo contradicen y son unánimes al declarar en la vista su pésimo funcionamiento. Dichos testimonios son corroborados por el contenido del documento 3 de la demanda, de constante referencia, en el que se constata que los fallos no fueron resueltos y persistieron en su mayor parte hasta la desconexión del sistema.
Además de la declaración de las usuarias del sotfware, disponemos del contenido del documento 3 de la demanda, que recoge el sistema de ticketing, que es un sistema de registro de las incidencias y peticiones relacionadas con un sistema informático para su seguimiento, en él que constan 780 incidencias registradas en el periodo comprendido entre el 19 de septiembre de 2016 y el 27 de abril de 2017, cuando se decidió dejar de utilizar el LIMS adquirido a la apelante, por lo que hasta ese momento el sistema siguió presentando errores. Dado que estamos ante una cuestión técnica es fundamental la prueba pericial aportada a los autos. Disponemos de dos informes periciales, el emitido por el Perito Sr. Fructuoso, a instancia de ALTRAN, y el emitido a instancia de AIMPLAS, emitido por el Perito Sr. Belarmino.
En cuanto a la valoración de los informes periciales, como ya ha declarado esta Sala en numerosas sentencias: «Las pruebas periciales obrantes en autos han de ser valorados según las reglas de la sana crítica, de acuerdo con lo establecido en el artículo 348 LEC, y recogido en la jurisprudencia del Tribunal Supremo, que en sentencia de 30 de julio de 2.008 se pronuncia en los siguientes términos: «esta Sala tiene declarado que la prueba pericial debe ser apreciada por el Juzgador según las reglas de la sana crítica, pero sin estar obligado a sujetarse al dictamen pericial, y sin que se permita la impugnación casacional a menos que la misma sea contraria en sus conclusiones a la racionalidad y se conculquen las más elementales directrices de la lógica«, como ya se indicó por el Alto Tribunal en sentencias de 13 de febrero de 1.990 , 29 de enero de 1.991 , 11 de octubre de 1.994 , 1 de marzo y 23 de abril de 2.004 STS, Sala de lo Civil, Sección 1ª, 23-04-2004 (rec. 1060/1998) , 28 de octubre de 2.005 , 22 de marzo , 25 de mayo , 15 de junio , 20 de julio y 17 de noviembre de 2.006 , 12 de abril , 20 de junio y 29 de noviembre de 2.007 y 29 de mayo de 2.008».
En la sentencia de fecha 8 de febrero de 2019 nos pronunciamos en los siguientes términos: «Apreciar en mayor medida el valor probatorio de un informe pericial frente a otros constituye una manifestación más del ejercicio de la jurisdicción y de la formulación del juicio necesario para dictar sentencia, pues frente a la disparidad de criterios periciales, es precisamente el juzgador quien, bajo el presupuesto del empleo de la sana crítica, está llamado a decidir cuál de ellos merece mayor credibilidad ( STS 1 de junio de 2011). Si, como ocurre en el caso, son varias las periciales practicadas, puede el tribunal en uso de la referida facultad atribuir mayor valor a unas sobre otras en orden a procurarle la convicción sobre los hechos a los que se refieran ( STS 14 de octubre de 2010). La emisión de varios dictámenes o el contraste de algunos de ellos con las demás pruebas, posibilita que la autoridad de un juicio pericial se vea puesta en duda por la del juicio opuesto o por otras pruebas, y que, con toda lógica los Jueces y Tribunales, siendo la prueba pericial de apreciación libre y no tasada acepten el criterio más próximo a su convicción, motivándolo convenientemente, como ocurre en este caso ( STS 17 de junio de 2015, 13 de febrero de 2015 y 29 de mayo de 2014)». «Al valorarse la prueba pericial deberán ponderarse: (a) Los razonamientos que contengan los dictámenes y los que se hayan vertido en el acto del juicio o vista por los peritos, pudiendo no aceptar el resultado de un dictamen o aceptarlo, o incluso aceptar el resultado de un dictamen por estar mejor fundamentado que otro; (b) las conclusiones conformes y mayoritarias que resulten de los dictámenes emitidos tanto por peritos designados por las partes como de los dictámenes emitidos por peritos designados por el tribunal, motivando su decisión cuando no esté de acuerdo con las conclusiones mayoritarias de los dictámenes; (c) las operaciones periciales que se hayan llevado a cabo por los peritos que hayan intervenido en el proceso, los medios o instrumentos empleados y los datos en los que se sustenten sus dictámenes; y (d) la competencia profesional de los peritos que los hayan emitido así como todas las circunstancias que hagan presumir su objetividad, lo que le puede llevar en el sistema de la nueva Ley de Enjuiciamiento Civil a que dé más crédito a los dictámenes de los peritos designados por el tribunal que a los aportados por las partes ( STS de 19 de julio de 2018)».
En el caso objeto del presente recurso, examinados los informes periciales aportados a los autos y visualizada la grabación del juicio, la Sala comparte la valoración que de la prueba pericial se hace en la sentencia apelada, que no es arbitraria ni ilógica, sino ajustada a la sana crítica. El Perito Sr. Belarmino constata que el software litigioso presenta innumerables errores y deficiencias con pérdida de tiempo para los trabajadores de gran impacto económico para la empresa. Fallos al realizar funciones muy básicas, como redondeos, cálculo del IVA, cálculo de descuentos, deficiente usabilidad y bloqueos del sistema. Según el Perito, no cumple con lo requerido en el contrato, con múltiples errores y falta de entendimiento entre los módulos. Lo califica de forma rotunda como inservible. El Perito Sr. Fructuoso, reconoce que el único software que ha analizado fue la versión de 8 de mayo de 2017, no la litigiosa, y que la nueva versión funcionaba correctamente, pero no pudo ser implementada por la negativa de AIMPLAN, que desactivó el acceso de ALTRAN al sharepoint. Frente a dicho informe pericial, el Perito Sr. Belarmino no analizó la versión de 8 de mayo sino la anterior de 14 de marzo de 2017, que es el objeto de la demanda y refiere importantes errores en el software y que existen partes del mismo todavía no desarrolladas, más de dos años después del encargo. Así resulta de su navegación en el LIMS, que grabó y depositó en CD. Puntualiza el Perito que el documento 2 de la demanda, Propuesta Técnico Económica, en el que se recoge las características que debía cumplir el LIMS, advertía que el sistema debía ser compatible con Navisión y el elaborado por ALTRAN no lo era.
Según el Perito Sr. Fructuoso la nueva versión de 8 de mayo de 2017 solventaba todos los problemas, pero no se implementó porque el 27 de abril de 2017 se desconectó la versión anterior y AIMPLAS se negó a ello, encargando uno nuevo a un tercero. El propio Perito que ha realizado el informe pericial a instancia de ALTRAN, no pone en duda las comprobaciones que ha hecho el Perito Sr. Belarmino en la versión anterior del software y reconoce que el no ha hecho dichas comprobaciones. De lo expuesto, es evidente que los informes periciales se han hecho sobre versiones del software diferentes y, por tanto, debemos estar al contenido del informe pericial elaborado por el Sr. Belarmino, dado que es el único que hizo comprobaciones con la versión que proyectó y ejecutó ALTRAN y es objeto del litigio, que fue implementado y dio los errores e incidencias que han sido objeto del pleito, no subsanadas tras dos años del encargo efectuado en abril de 2015 hasta que se desconectó en abril de 2017, ya que la versión de 8 de mayo de 2017 no llegó a implementarse y AIMPLAS decidió encargar un nuevo LIMS a un tercero.
Según el Perito Sr. Fructuoso, el nuevo LIMS contratado a un tercero por AIMPLAS era conceptualmente distinto al encargado a ALTRAN, al no incluir los módulos de facturaciones y presupuestos, que afirma daban problemas y tenían su origen en el sistema Navisión. Esto es contradicho por el Perito Sr. Belarmino, que en su informe de 6 de noviembre de 2020, sobre las similitudes del LIMS contratado a ALTRAN y finalmente adquirido a NUNSYS, empresa tecnológica especializada en laboratorios, también conecta con el sistema Navisión, que la apelante ya tenía de inicio e interactúa con él. El Perito indica que el RFP que se facilita a la nueva empresa tiene el alcance de lo solicitado anteriormente a ALTRAN. Se ha corregido las partes más importantes que generaban errores en el desarrollado por ALTRAN y el Perito verifica que partes importantes del sistema no estaban terminadas y eran muy diferentes a los solicitado por AIMPLAS, los informes de laboratorio cumplen con la usabilidad requerida por AIMPLAS a ALTRAN. Según el Perito Sr. Belarmino, la nueva empresa aprovecha toda la integración con Navisión, lo que no hacía el LIMS desarrollado por ALTRAN. Frente a dicho informe, el Sr. Fructuoso reconoce que en el programa de ALTRAN solo había determinadas comunicaciones con Navison, algo puntual, porque todo se resolvía dentro del programa de ALTRAN. El Sr. Belarmino insiste en que el contrato en todo momento habla de la integración con Navison y el Sr. Fructuoso también insiste en que el software de ALTRAN y el de NUNSYS son distintos, aunque reconoce que ambos se han desarrollado para la misma funcionalidad, el segundo es una versión mejorada del primero.
De lo expuesto, no podemos sino compartir con la sentencia apelada que se ha producido un incumplimiento grave y esencial de las obligaciones contractuales por parte de la demandada-reconviniente, al desarrollar el LIMS objeto de la demanda, que justifica la resolución del contrato, conforme al art. 1124 del Código Civil, con las consecuencias inherentes a dicho pronunciamiento, que han sido argumentadas en el fundamento jurídico segundo de la presente resolución y damos por reproducidas para no incidir en reiteraciones innecesarias. Procede condenar a dicha mercantil al pago a la apelante de la suma de 112.156,18 euros, en concepto de devolución de las cantidades abonadas, además del abono de la suma de 55.433,79 euros, a que es condenada en la sentencia apelada, en concepto de indemnización de daños y perjuicios por las horas dedicadas por los trabajadores de AIMPLAS a rehacer trabajos consecuencia de los errores creados por el defectuoso funcionamiento del software.
En cuanto a los errores de cálculo que se alegan en el recurso. Debemos partir de que AIMPLAS abonó a ALTRAN por el software la suma de 87.035,30 euros, cantidad que debe ser restituida, como consecuencia directa de la resolución contractual por incumplimiento de la apelante. En cuanto a las bolsas de horas de mantenimiento del sistema, conforme al contrato aportado como documento nº 2 de la contestación a la demanda, se reclaman en la demanda 480 horas de 12 meses, que se contrató el 12 de noviembre de 2015 hasta el 12 de noviembre de 2016. Se inicia la funcionalidad del sistema el 1 de septiembre de 2016, por lo que, como atinadamente aduce la sentencia apelada, no pudo ofrecerse como mantenimiento cuando aún o se había entregado al cliente, sino para subsanar fallos del LIMS imputables a la demandada o nuevas aplicaciones no previstas contractualmente, por lo que debe reembolsarse a la actora la suma de 25.120,88 horas abonadas por bolsa de horas, junto con la anteriormente referida de 87.035,30 euros como parte del precio, hace un total de 112.156,18 euros a reembolsar a AIMPLAS.
No obstante, en el recurso se alega que en acta de 14 de diciembre de 2016, AIMPLAS aprobó 204,5 horas como evolutivas, realizadas desde el 20 de junio de 2016 (documento 8 de la contestación), es decir, que fueron validadas por AIMPLAS y ascienden a la suma de 11.544,85 euros, cantidad que se pretende deducir del importe a devolver. Nada debe abonarse por AIMPLAS por unos trabajos que, ya hemos reiterado en la presente resolución, no cumplieron con las funcionalidades para las que fue desarrollado. Tampoco apreciamos errores de cálculo e incongruencia de la sentencia, que reconoce el pago de la suma de 17.218,30 euros y 1.977,07 euros de la bolsa de horas pero no estima la reconvención y ello por el mismo motivo. En cuanto a los sobrecostes por importe de 74.872 euros, que se reclaman en la demanda reconvencional por modificaciones en las funcionalidades técnicas del sistema LIMS, solicitadas por AIMPLAS, según informe técnico emitido por D. Ezequiel, Gerente de la Unidad Técnica de ALTRAN, debemos tener en cuenta que, por la especial relación que mantiene con la empresa, carece de la objetividad e imparcialidad necesarias, además de que no consta reclamación de dichos importes hasta la formular reconvención y el citado informe pericial ha sido contradicho por el Perito Sr. Belarmino, que tiene en cuenta que los trabajos se realizaron para implementación o correcciones de un LIMS que no funcionó y frustró las expectativas que AIMPLAS tenía para su adquisición, lo que supuso un incumplimiento grave y esencial de las obligaciones contractuales por parte de la demandada-reconviniente, que llevó a la resolución contractual y nada puede reclamar.
En concepto de horas dedicadas por los trabajadores de AIMPLAS a rehacer trabajos por errores creados por el defectuoso funcionamiento del software, se reclama en la demanda la suma de 114.414,66 euros, según los informes periciales de los Sres. Belarmino y Carlos, atendiendo a 785 horas invertidas por el personal técnico y 1.400 horas de las empleadas por el personal TIC. En la sentencia, se tiene en cuenta la declaración de los testigos y las periciales. Aprecia el juez a quo con acierto que el Perito Sr. Carlos hace el cálculo económico sin tener en cuenta que las horas calculadas por el Sr. Belarmino lo son en su totalidad y no por año, por lo que no son 4.509 horas. En la sentencia apelada se hace un cálculo proporcional y reduce la indemnización reclamada a la suma de 55.443,79 euros. En el recurso se aduce que se ha computado entre mayo de 2015 a septiembre de 2016 y dicho periodo no debería tomarse para el cálculo, ya que era el periodo de toma de datos y desarrollo inicial de diseño y pruebas. Así lo reconoce el Perito Sr. Belarmino, pero afirma que lo ha tenido en cuenta al computar a la baja el número de horas. El Perito Sr. Fructuoso considera que debe procederse a la reducción del número de horas, porque en los proyectos de este tipo la empresa que contrata tiene que calcular un tiempo de dedicación de su personal sobre 400 o 500 horas para hacer el aplicativo (hacer análisis, apoyar al equipo de desarrollo y hacer pruebas), por lo que estima que se debería reclamar por 400 horas. El Sr. Belarmino dice que lo tuvo en cuenta y así ha considerado que el Sr. Millán estuvo dedicado un 100% y le ha aplicado un 50%, al resto de personal un 2% y ha descontado todas las incidencias que no quedaban claro si eran responsabilidad de AIMPLAS o de ALTRAN, por eso ha aplicado porcentajes a la baja. El Perito Sr. Belarmino ha considerado las horas computadas 2.185 horas (1.400+ 785) y el Perito Sr. Carlos hace el cálculo económico, pero al no tener en cuenta que las horas calculadas por el Sr. Belarmino lo son en su totalidad y no por año, no son 4.509 horas y, por ello, en la sentencia apelada se hace un cálculo proporcional y se reduce la indemnización a la suma de 55.443,79 euros. La Sala no aprecia una valoración de la prueba pericial arbitraria ni ilógica sino ajustada a la sana crítica.
El recurso de apelación debe ser desestimado.
Fundamento Quinto
En aplicación de lo dispuesto en los arts. 394-1 y 2 y 398-2 de la LEC, las costas procesales de la demanda reconvencional se imponen a la reconviniente y no se hace especial imposición de las costas procesales de la demanda principal ni de esta alzada. Vistos los preceptos legales citados y demás de general aplicación.
Fallo de la sentencia
Que, con estimación del recurso de apelación interpuesto por la representación procesal de la mercantil ASOCIACIÓN DE INVESTIGACIÓN DE MATERIALES PLÁSTICOS y CONEXAS (AIMPLAS) y desestimación del presentado por la representación procesal de la mercantil ALTRAN INNOVACIÓN SLU (ALTRAN), frente a la sentencia dictada en fecha 27 de septiembre de 2022 por el Juzgado de 1ª Instancia nº 26 de Madrid en los autos a que el presente Rollo se contrae, debemos revocar y revocamos parcialmente la resolución indicada, en el sentido de condenar a ALTRAN al pago a la apelante de la suma de 112.156,18 euros, en concepto de devolución del las cantidades abonadas, además del pago de la suma de 55.433,79 euros, a que es condenada en la sentencia apelada; se desestima la demanda reconvencional y se absuelve a la reconvenida de las pretensiones de la demanda contra ella entablada. Las costas procesales de la demanda reconvencional se imponen a la reconviniente y no se hace especial imposición de las costas procesales de la demanda principal ni de esta alzada.
La estimación del recurso determina la devolución del depósito constituido, de conformidad con lo establecido en la Disposición Adicional 15ª de la Ley Orgánica 6/1985, de 1 de julio, del Poder Judicial, introducida por la Ley Orgánica 1/2009, de 3 de noviembre, complementaria de la ley de reforma de la legislación procesal para la implantación de la nueva oficina judicial.
La desestimación del recurso determina la pérdida del depósito constituido, de conformidad con lo establecido en la Disposición Adicional 15ª de la Ley Orgánica 6/1985 de 1 de julio, del Poder Judicial, introducida por la Ley Orgánica 1/2009, de 3 de noviembre, complementaria de la ley de reforma de la legislación procesal para la implantación de la nueva oficina judicial.
Remítase testimonio de la presente Resolución al Juzgado de procedencia para su conocimiento y efectos.
Casuísticas comunes en procesos por software defectuoso
La sentencia anterior es enormemente didáctica, dado que ilustra muy bien lo que de normal nos encontramos los peritos informáticos en procesos por software defectuoso en vía civil. Lo podemos resumir de la siguiente manera
El inicio del litigio: cruce de demandas entre las partes
De normal en los procesos por software defectuoso las acciones legales se inician de una de las dos siguientes maneras:
- El contratante del software reclama devolución de importes satisfechos así como daños y perjuicios por pérdidas operativas o perjuicios frente a terceros ocasionados por el software defectuoso. Frente a ello, el proveedor de software interpone oposición a la demanda y acción reconvencional para que el cliente abone la totalidad del importe a satisfacer según contrato
- El proveedor de software interpone demanda por impago de conceptos en el marco de contrato suscrito para el diseño, elaboración e implantación de un software. El cliente se opone a la demanda alegando que se trata de software defectuoso e interpone acción reconvencional invocando la resolución del contrato y la devolución de las cantidades satisfechas junto con daños y perjuicios
A grandes rasgos casi siempre la litis se inicia en base a una de estas dos situaciones.
La prueba pericial informática, vital para acreditar software defectuoso
Tal y como se observa en la muy didáctica sentencia «ut supra», es normal que ambas partes confronten pruebas periciales informáticas sobre las que sustentar sus pretensiones, según se trate del proveedor de software o del contratante que sufre el software defectuoso.
Así, la prueba pericial informática por parte del proveedor tratará de desmontar las causas de resolución contractual, por no tratarse de defectos esenciales ni insubsanables que invaliden el objeto del bien a entregar, en este caso el software. Para ello tratará el perito informático de acreditar que el software defectuoso no es tal y que no presenta defectos o bien que los mismos no hacen completamente inservible el sistema informático y son subsanables en un plazo y coste razonables. Así mismo tratará de dejar sin argumentos al cliente sobre los daños y perjuicios que pudiera reclamar, tanto contrastando los daños causados en sí, como el criterio esgrimido para la cuantificación de los mismos.
Por contra, la prueba pericial informática por parte del cliente tratará de acreditar que se trata de un software defectuoso. Para ello acreditará técnicamente que el software resulta inservible con imposibilidad de cumplir el objeto del contrato y las expectativas razonables que pudiera tener el cliente sobre el resultado de la prestación de servicios. Así mismo, tratará de acreditar que dichos defectos no son subsanables en un plazo y coste razonables, dejando como única salida la resolución contractual. Además, el perito informático por parte del cliente tratará de acreditar los daños y perjuicios sufridos, estableciendo nexo causal directo entre los defectos que presenta el software y el perjuicio sufrido. Finalmente, el perito informático tratará de establecer criterios razonables que permitan cuantificar el daño sufrido.
En definitiva, se trata de materia eminentemente técnica, en la que a buen seguro se confrontarán distintos informes periciales informáticos. El tribunal deberá valorar ambos informes y determinar cuál le merece mayor credibilidad y por qué.
Pretensión de que el análisis de software lo haga el cliente
Resulta habitual que la empresa de software pretenda trasladar al cliente la responsabilidad de determinar exhaustivamente la funcionalidad del software a implementar. Con ello se pretende que en caso de que se den fallos de diseño, éstos no les sean imputables. Se suele incurrir en palmaria mala praxis, haciendo firmar al cliente un documento de conformidad respecto de un documento funcional muy genérico y críptico que, por ser lego en la materia, el cliente tiene imposible comprender y que debe firmar si quiere obtener lo contratado.
En proyectos serios, antes del propio contrato de software se realiza un contrato independiente por servicios de consultoría y auditoría. Con ello se ilustra de forma exhaustiva, documentalmente y tras amplio trabajo de campo, tanto la operativa de la empresa, como las necesidades a cubrir por el software a contratar, las mejoras que se obtendrán y las características detalladas del software a implementar, junto a horizonte temporal y coste.
Por tanto, el primer paso para tratar de acreditar que no se trata de software defectuoso consiste en aportar un documento de auditoría con los trabajos realizados: entrevistas al personal de la empresa, documentación examinada, solución propuesta exhaustivamente detallada y previsión de costes. Aún firmando este documento el cliente, éste es lego en la materia, no pudiendo pretenderse que por ese mero hecho haya validado unos trabajos técnicos por su propio personal. De ser así resultaría absurdo contratar a un tercero para llevar a cabo la labor con personal externo.
Por parte del cliente, éste tratará de acreditar fallos de diseño y malas praxis profesionales ya en el propio análisis del software. Al tratarse de fallos de diseño, el software defectuoso puede ser difícilmente subsanable, justificándose de plano la resolución del contrato.
Pretensión de colar como defectos funcionalidad no contratada
Si bien en la sentencia examinada no se da este caso, resulta bastante habitual que el cliente pretenda calificar como software defectuoso el objeto del contrato por el mero hecho de no contener funcionalidades que les gustaría tener, pero que no contrataron. Para ello resulta fundamental contrastar los detalles de la funcionalidad contratada para poder calificar de software defectuoso, o no.
Tampoco resulta adecuada la pretensión del proveedor de software de acogerse únicamente a las funcionalidades indicadas de forma somera y superficial en un documento suscrito por el cliente. Aquí entran en juego las perspectivas razonables que pudiera tener el cliente al contratar el software. Algo de esto se menciona en la sentencia examinada, y resultará fundamental la labor del perito informático para argumentar técnicamente dichas pretensiones. Una de ellas es que el software sea seguro, sin que sea necesario indicarlo en documento alguno. Otra, que calcule el IVA correctamente. Aunque no figure en las funcionalidades contratadas, se presupone que un software de facturación debería calcular correctamente el IVA en una factura, resultando inútil para ese fin en caso contrario. Estaríamos palmariamente ante un software defectuoso.
Al contrario, los proveedores de software que trabajan adecuadamente se encuentran en situación de rebatir la pretensión de incluir funcionalidad no pactada. Utilizando la analogía de un vehículo, resulta fácilmente contrastable si, habiendo contratado un utilitario, se pretende luego obtener un superdeportivo, y a precio de patinete eléctrico. Por tanto, contando con el soporte documental adecuado y habiendo explicitado correctamente las características técnicas detalladas de forma comprensible para el cliente, no debe haber mayor problema para acreditar este extremo. Para ello resulta fundamental contar con el proyecto técnico.
El software defectuoso no suele contar con proyecto técnico informático
Otra característica común es que el software defectuoso no cuente con un proyecto técnico informático como tal. Este documento resulta fundamental para determinar la funcionalidad, características, componentes y operabilidad de cualquier software informático contratado. Se trata de un conjunto de planos, esquemas, y textos explicativos, utilizados para definir las características de un producto informático (hardware y/o software), su fabricación y desarrollo, su instalación y puesta en marcha y/o las condiciones de realización de dicho proyecto.
Así mismo, contiene una serie de planos que hacen inteligible para un lego en la materia las funcionalidades básicas con las que cuenta, así como sus distintos componentes, de forma muy visual. A continuación se expone un diagrama de actividades en Lenguaje de Modelado Unificado (UML) usado internacionalmente en el diseño de software. El algoritmo resulta perfectamente entendible sin necesidad de ser experto en la materia:
Siguiendo el anterior ejemplo, a continuación se puede observar un diagrama de despliegue, también en UML. Resulta entendible por cualquier profano la estructura informática necesaria para desplegar el software y que funcione correctamente.
Estos diagramas no son baladís. Con ellos el proveedor podría acreditar que no se trata de un software defectuoso, sino que el mismo se ha instalado y operado de manera incorrecta y contraria a sus indicaciones por parte del cliente.
Por ello, uno de los documentos fundamentales sobre los que pivotar la controversia sobre el software defectuoso es el proyecto técnico. Su no existencia puede determinar la mala praxis e impericia del proveedor, ya que resulta elemental, no sólo para justificar el trabajo realizado, sino para que el Cliente pueda, en un futuro, ampliar, actualizar o suprimir funcionalidades del software de su propiedad. Sin este documento podría considerarse el software defectuoso sin más, por no poder ejercer plenamente sus derechos sobre el bien contratado, siendo un defecto insubsanable. ¿Se imaginan la entrega de una casa sin planos ni proyecto de edificación alguno? ¿Cómo podrían reformar después el inmueble? Algo parecido pasa en el ámbito software, que no es otra cosa que un producto de ingeniería, en este caso, informática.
Proveedor no certifica adecuadamente el software que entrega
Volviendo a la sentencia que recojo en este articulo, otra casuística habitual es que el proveedor de servicios es incapaz de certificar adecuadamente las características del software entregado en un momento dado. Ello se deriva de la inexistencia de documentación sobre la entrega, instalación, configuración y puesta en marcha del software contratado. En la sentencia se observa que incluso el perito informático contratado por la empresa de software demandada reconoce que no examinó la misma versión de software que examinó el perito informático de la empresa demandante, con lo que su pericial resultó inútil.
Este descontrol, junto a la incapacidad de certificar los componentes software que se entregan al contratante en un momento dado dificultan enormemente poder acreditar que el software defectuoso no era tal. Incluso en muchas ocasiones se presenta al perito informático un software parcheado y arreglado lo suficiente para tratar de engañar al perito propio.
Estos casos se subsanan pudiendo aportar documentación relativa a los componentes entregados en cada momento junto con las pruebas de control de calidad realizadas y testeadas por el propio proveedor de servicios. Por desgracia, no suele hacerse para ahorrar costes.
El Proveedor carece de capacidad legal para obrar
Una de las casuísticas que suelen aparecer en procesos por software defectuoso es la falta de capacidad legal para obrar por parte del proveedor. Tanto la dirección del proyecto informático como el análisis y diseño del mismo o la dirección de los trabajos para su implementación y despliegue son actos propios de la profesión de ingeniero técnico en informática (Art. 2, Ley 12/1986), de forma análoga a los trabajos en otros ámbitos de ingeniería técnica.
Incluso en determinados territorios autonómicos, para realizar estas labores se exige, por Ley, la pertenencia a un colegio profesional, como por ejemplo:
- Andalucía: Ley 12/2005, de 31 de mayo, de creación del Colegio Profesional de Ingenieros Técnicos en Informática de Andalucía, artículo 4.
- Castilla La Mancha: Ley 5/2002, de 11 de abril, de creación del Colegio Oficial de Ingenieros Técnicos en Informática de Castilla-La Mancha, artículo 3.
- Comunidad Valenciana: Ley 7/2005, de 18 de noviembre, de creación del Colegio Oficial de Ingenieros Técnicos en Informática de la Comunidad Valenciana, artículos 3 y 4.
- Islas Canarias: Ley 7/2006, de 10 de noviembre, de Creación del Colegio Profesional de Ingenieros Técnicos en Informática de Canarias, artículo 4.
- Galicia: Ley 8/2006, de 1 de diciembre, de creación del Colegio Profesional de Ingeniería Técnica en Informática de Galicia, artículo 3.2.
Así mismo, el Real Decreto 517/2015, de 19 de junio, por el que se aprueban los Estatutos Generales de los Colegios Oficiales de Ingeniería Técnica en Informática y de su Consejo General, establece las titulaciones que dan acceso a la profesión de ingeniero técnico en informática, siendo por orden de antigüedad creciente:
- Graduado en Ingeniería Informática, en su respectiva especialidad.
- Ingeniero Técnico en Informática de Sistemas
- Ingeniero Técnico en Informática de Gestión
- Diplomado en Informática
Si observamos un contrato de servicios en el que no se identifica a los responsables técnicos concretos que deben materializar el contrato, resulta razonable sospechar que pueden carecer de la titulación legalmente exigida, y por lo tanto carecen de capacidad de obrar. Por tanto, resulta muy pertinente solicitar como prueba que el proveedor aporte los currículums de todo el personal que ha intervenido en materializar el software defectuoso, con especial énfasis en la titulación oficial que poseen. Es habitual que traten de distraer al tribunal con numerosos cursos y experiencia de años, pero sin la titulación oficial habilitante legalmente exigida. Ello comporta que el contrato pueda ser anulado por falta de capacidad legal del proveedor para materializar su objeto.
Aunque le pueda parecer increíble, resulta muy habitual que el personal a cargo carezca de titulación habilitante. Con ello, ciertos proveedores ahorran muchísimo dinero en personal, ofertando sus servicios a precios muy inferiores a otras empresas de software que sí cumplen la ley.
Auditoría funcional del software frente al análisis de su código
Un error común en este tipo de procedimientos por software defectuoso consiste en tratar de analizar el código informático del propio software en sí. Más allá de que la codificación informática se realice de una forma más o menos eficiente y correcta, lo que realmente importa es el resultado y si el software entregado cumple suficientemente el objeto para el que se adquirió.
Así, no resulta pertinente ni justificado requerir el código informático del software defectuoso al proveedor de servicios, esgrimiendo que al no entregarlo trata de ocultar los defectos. Lo que sí es pertinente es requerir el proyecto técnico, y más concretamente el diseño funcional del mismo. Esos diseños sobre el papel deberán ser cotejados con una auditoría funcional de lo entregado, documentando los defectos y errores que, a juicio de una de las partes, permiten aseverar que estamos ante software defectuoso.
Otro error común consiste en no documentar qué versión del software es la que se está auditando funcionalmente. Esa circunstancia ocurrió en el caso observado en la sentencia «ut supra», auditando el perito del proveedor demandado un software distinto del entregado y que, por lo tanto, no cabe valorar en la litis. Al contrario también se da el mismo error cuando el perito del proveedor no puede acreditar que el software auditado fue el efectivamente entregado al cliente, bien por impericia, bien por falta de la documentación necesaria a la hora de entregar el producto contratado.
La declaración de los peritos determinará en buena medida si el software es defectuoso
La declaración de los peritos determinará en gran medida si el software es defectuoso o no. La sentencia examinada incide en los criterios a la hora de evaluar pruebas periciales contradictorias, que merece volver a traer a colación. Así, deberá ponderarse por el tribunal:
- Los razonamientos que contengan los dictámenes y los que se hayan vertido en el acto del juicio o vista por los peritos, pudiendo no aceptar el resultado de un dictamen o aceptarlo, o incluso aceptar el resultado de un dictamen por estar mejor fundamentado que otro
- Las conclusiones conformes y mayoritarias que resulten de los dictámenes emitidos tanto por peritos designados por las partes como de los dictámenes emitidos por peritos designados por el tribunal, motivando su decisión cuando no esté de acuerdo con las conclusiones mayoritarias de los dictámenes
- Las operaciones periciales que se hayan llevado a cabo por los peritos que hayan intervenido en el proceso, los medios o instrumentos empleados y los datos en los que se sustenten sus dictámenes
- La competencia profesional de los peritos que los hayan emitido así como todas las circunstancias que hagan presumir su objetividad.
En gran medida el proceso de inmediación durante la vista oral resultará determinante para realizar esta ponderación. Por tanto, resulta fundamental que el perito informático sepa hacerse entender y sea capaz de confrontar, que no agredir, sus criterios con los del perito informático contrario. En este tipo de procedimientos resulta perentorio contar con peritos informáticos colegiados y con experiencia previa en este tipo de procesos, por lo demás, muy técnicos.
Los tribunales, aún siendo legos en la materia, podrán razonar por qué se decantan por un criterio técnico u otro en base a la intervención de cada perito en la vista oral y la calidad de la misma.
Recomendaciones básicas para afrontar pleito por software defectuoso
Cerraré el presente artículo trayendo a colación unas recomendaciones muy básicas para afrontar con unas mínimas garantías de éxito los pleitos por software defectuoso.
Busque de inmediato un perito informático colegiado
Ya debe de estar suficientemente claro que el buen resultado en un proceso civil por software defectuoso depende en buena medida de la prueba pericial informática. Por ello resulta imprescindible contar desde el mismo inicio, además de con letrado avezado en este tipo de pleitos, con un perito informático colegiado que forme tándem con el letrado. La prueba pericial determinará en buena el resultado del proceso, pero esta prueba no se presenta aislada, sino apoyada o complementada por un conjunto probatorio que lleve al tribunal a admitir las pretensiones esgrimidas. Por ello la estrategia procesal debe estar completamente alineada con la prueba pericial informática y el conjunto probatorio de apoyo. Sólo desde una perspectiva técnica y legal perfectamente alineadas se consiguen buenos resultados en este tipo de procesos por software defectuoso.
Así mismo, examine bien las credenciales del perito a contratar. No resulta extraño descubrir en la vista oral que el perito informático elegido ni está colegiado ni cuenta con la titulación oficial habilitante exigida por Ley, lo que puede dar al traste con todo el procedimiento y causar graves daños económicos a la parte representada. Posteriormente podrá actuar frente al perito por delitos de intrusismo profesional y estafa, pero el daño ya estará hecho.
Exija que el perito esté colegiado en un colegio profesional de ingeniería técnica informática. Sólo así estará completamente seguro de que cumple con los requisitos legales.
Recopile la documentación necesaria
En este tipo de procesos resulta fundamental la prueba documental, en forma de contratos y documentación técnica intercambiada entre las partes. También los currículums de los profesionales que han intervenido en la materialización del software, para acreditar o desacreditar su capacidad legal de obrar y grado de profesionalidad.
Por tanto, antes de plantear la demanda, sea como actora, sea con carácter reconvencional, hay que recopilar y comprobar toda la documentación técnica necesaria. En este punto necesitará ya el apoyo del perito informático.
Comunicaciones y devenir del proyecto informático
Otro punto importante consiste en acreditar los posibles problemas e incumplimientos a lo largo de la materialización del contrato. Con ello se persigue acreditar los hechos que han llevado a materializar un software defectuoso o, al contrario, para acreditar la corrección y buena praxis de lo actuado. Durante este tipo de servicios es de lo más adecuado establecer reuniones y levantar actas de lo acordado entre las partes.
Respecto a las comunicaciones electrónicas, suele tratarse de cientos de correos electrónicos durante meses o años. Tal cantidad de elementos de prueba suele distraer al tribunal del núcleo de la litis. Mi recomendación es la de filtrar esas comunicaciones con el fin de acreditar, bien que se puso de manifiesto que el software era defectuoso, bien para acreditar que se califica como software defectuoso de manera espúrea, para ocultar otros intereses y circunstancias.
Examen del software entregado
Resultará fundamental poder examinar el software entregado, eso sí, en el mismo estado en que se entregó. Corresponde al proveedor acreditar en qué estado exacto entregó el producto resultante de los trabajos contratados. De lo contrario, tal y como se ha comentado, podría estar examinándose otro software distinto para determinar si lo entregado es un software defectuoso, lo que no es pertinente ni útil al proceso.
Los peritos deberán examinar las características del software entregado para dilucidar si es defectuoso o no, si dichos defectos son subsanables o no, y el grado de afectación que dichos defectos suponen para alcanzar los objetivos perseguidos con la celebración del contrato. También será determinante para cuantificar los daños y perjuicios causados. Para realizar este examen los peritos informáticos deberán no sólo auditar funcionalmente el software, sino cotejar el proyecto técnico y las especificaciones iniciales para comprobar su grado de materialización.
Así, por ejemplo, puede haber software que funcione correctamente a la hora de emitir una factura, pero que se atasque o deje de funcionar cuando se emiten miles de facturas simultáneamente por cientos de usuarios. Por tanto, se puede defender que el software emite facturas, pero no que cumpla los objetivos contratados, que es de lo que realmente se trata para determinar si estamos ante un software defectuoso.
Por contra, la base para una demanda reconvencional consistirá en acreditar, tras el examen de lo entregado, que no se trata de software defectuoso, sino que realmente la parte contraria puede estar actuando de mala fe, pretendiendo no pagar los trabajos contratados, pagar menos por ellos u obtener muchas más prestaciones por el mismo importe. Estas casuísticas son también habituales.
Tasación pericial de defectos, daños y perjuicios
Por último resultará indispensable que la prueba pericial relativa al software defectuoso, en un sentido o en otro, se acompañe de una tasación pericial informática. Así, la parte que sostenga que el software es defectuoso deberá argumentar con solvencia no sólo por qué lo es, sino en qué grado y por qué. Ello será la base para establecer la cuantía económica respecto del total abonado para requerir la devolución del importe. En caso de que el software defectuoso lo sea de forma esencial, impidiendo alcanzar los objetivos para los que se adquirió, puede llegar a requerirse la devolución de la totalidad de lo abonado. Además el perito informático deberá establecer un nexo causal directo entre los defectos del software y los daños y perjuicios que alegue haber sufrido la parte adquiriente del programa informático. Establecido el nexo causal deberá justificar la cuantía de dichos daños y perjuicios en base a razonamientos lógicos y a la lex artis profesional.
Por contra, el perito informático del proveedor de software deberá tratar de desmontar el nexo causal entre los supuestos defectos del software y los daños que dice haber sufrido la parte contraria. También deberá someter a escrutinio si los criterios para cuantificar esos daños corresponden a razonamientos lógicos y a la lex artis profesional, pudiendo minorar sustantivamente las cuantías a resarcir.
Expertos en peritaciones informáticas de software
En Indalics somos expertos en la realización de peritaje de software, al objeto de determinar si se trata de software defectuoso o no. También realizamos tasación económica tanto para determinar coste de defectos y daños como para tratar de rebatir los de la parte contraria. Peritos informáticos colegiados y legalmente habilitados. Ámbito nacional.
Partners técnicos de confianza para letrados
Somos los peritos informáticos de confianza para su despacho jurídico y sus clientes. Aportamos amplios conocimientos técnicos y periciales, pero siempre desde una óptica legal y procesal adaptada al caso concreto. Además, todos nuestros peritos cumplen los requisitos legales para realizar la actividad de perito informático, acreditando su cumplimiento. Le ayudamos en su proceso por software defectuoso desde el minuto uno.