¿Cuáles son las obligaciones de soporte que el proveedor asume después del final del desarrollo del sistema?

En el desarrollo de sistemas, es bien sabido que los proveedores especializados en desarrollo de sistemas, conocidos como vendedores, asumen la “obligación de gestión de proyectos”. Sin embargo, en términos legales, se ha planteado un concepto similar pero distinto, conocido como “obligación de soporte”. En este artículo, explicaremos esta “obligación de soporte”, teniendo en cuenta precedentes judiciales anteriores.

¿Qué es la obligación de soporte?

Resumen de la obligación de soporte

En el contexto de las obligaciones que un proveedor tiene hacia un usuario, una de las más representativas es la obligación de gestión de proyectos. Este es un concepto que se ha establecido a través de repetidas menciones en precedentes judiciales, y resume las obligaciones que el proveedor, como experto en desarrollo de sistemas, tiene hacia un proyecto completo.

La obligación de gestión de proyectos es un término legal muy conocido en relación con el desarrollo de sistemas, y no hay duda de que es una de las principales obligaciones que el proveedor asume. Sin embargo, algunos precedentes judiciales reconocen la existencia de una obligación diferente a la de gestión de proyectos, denominada “obligación de soporte”.

La obligación de soporte se convierte en un problema en el soporte operativo para los usuarios

Entonces, ¿qué es la obligación de soporte? ¿Y por qué se le da un nombre diferente a la obligación de gestión de proyectos? La obligación de soporte suele ser un problema después de que se ha completado el desarrollo del sistema. Un proyecto de desarrollo de sistemas, siendo un “proyecto de desarrollo”, termina, en principio, una vez que se ha completado el sistema que se debe crear. Es decir, un proyecto de desarrollo de sistemas comienza con la clarificación de lo que debe ser el sistema (definición de requisitos) y termina con la confirmación de si se ha completado o no (prueba o aceptación).

Sin embargo, incluso si se entiende que un proyecto de desarrollo de sistemas es el proceso de desarrollo en sí para crear un nuevo sistema, es natural asumir que el sistema desarrollado se utilizará en las operaciones posteriores. En otras palabras, sería irracional decir que “sólo necesitamos crearlo, ya que somos responsables sólo del desarrollo”, sin tener en cuenta cómo se utilizará el sistema después de su desarrollo. Teniendo en cuenta estos puntos, ha habido casos en los que se ha planteado la cuestión de si se puede imponer al proveedor, que se encarga del desarrollo del sistema, una cierta obligación de soporte operativo. Es decir, se plantea la cuestión de si se debe considerar que las obligaciones que el proveedor asume en el contrato de desarrollo de sistemas incluyen también las obligaciones relacionadas con el soporte operativo después del desarrollo. Como el soporte operativo no es parte del proceso de desarrollo en sí, se cree que se ha utilizado la expresión “obligación de soporte” para distinguirla de la obligación de gestión de proyectos.

¿Qué casos judiciales han surgido en relación con la obligación de soporte?

Caso en el que la realización de las operaciones del usuario se vio obstaculizada en la etapa de prueba del sistema

En el caso citado en la siguiente sentencia, el usuario no pudo utilizar el sistema como se había previsto inicialmente en la prueba del sistema realizada antes de la puesta en marcha del sistema, y como resultado, el usuario tuvo que abandonar la operación del sistema en sí. Este caso fue un problema en el momento del inicio de la operación por parte del usuario, y la cuestión era cómo justificar la responsabilidad del proveedor a partir del contrato de desarrollo del sistema acordado previamente. Como conclusión, se reconoció la reclamación de indemnización por daños y perjuicios por parte del usuario, y se señaló la “violación de la obligación de soporte” como fundamento.

I Violación de la obligación de soporte
(A) El representante del demandante solicitó al demandado el 14 de julio de 1997 (1997), “No sólo quiero que creen el sistema, sino que también quiero que se ocupen de él hasta que funcione correctamente.“, “Somos novatos, así que estamos pagando mucho dinero, así que quiero que lo hagan utilizable hasta el final.“. En respuesta, el demandado explicó que era posible construir un sistema que pudiera lograr el objetivo de implementación del demandante y prometió apoyar hasta que pudiera ser utilizado correctamente. Como resultado, se llegó a un acuerdo entre el demandante y el demandado de que el demandado apoyaría hasta que el demandante pudiera utilizar correctamente el sistema en cuestión.
Es evidente que el demandado tiene una obligación de soporte hacia el demandante, ya que se han contabilizado 1.726.000 yenes en concepto de “apoyo a la implementación del paquete” como parte del precio del contrato en cuestión, y en el presupuesto se menciona una “mantenimiento gratuito durante los primeros seis meses después de la implementación” en relación con la cuota de mantenimiento mensual, y en un documento titulado “Sobre el soporte de SE en el futuro (documento de discusión interna)”, se confirma que se puede recibir soporte de SE para la “creación de un procedimiento (plan) de implementación” y “trabajo de verificación de datos/operación” en relación con el pedido de productos frescos.

(B) Y la obligación de soporte que el demandado tiene hacia el demandante, concretamente, al menos hasta que el demandante llegue a la operación completa del sistema en cuestión, el demandado debe proporcionar al demandante ① asesoramiento adecuado sobre cómo operar el sistema en cuestión, ② asistencia en las pruebas de operación y respuesta a los problemas del sistema que surjan en las pruebas de operación, ③ mejoras del sistema en función de los resultados de las pruebas de operación, ④ formación de los operadores.
Sin embargo, el demandado, a pesar de los numerosos problemas en las pruebas de operación, no respondió seriamente a ellos, alegando que eran problemas de competencia de los operadores, y sólo pidió al demandante el costo de la formación de los operadores, sin proporcionar ningún soporte adecuado para la operación completa.

Sentencia del Tribunal de Distrito de Hachioji, Tokio, 5 de noviembre de 2003 (2003)

En esta sentencia, la palabra “soporte” aparece unas 30 veces en todo el texto de la sentencia, incluyendo el índice. Se puede ver que la voz del usuario que busca un apoyo adecuado se refleja directamente en la sentencia, y que se llegó a una conclusión después de considerar detalladamente el curso del caso y buscar una solución justa. Además, los puntos que deben destacarse en particular en la comprensión de este caso son:

• La violación de la obligación de soporte se trata como un “incumplimiento de la obligación”, por lo que se ordenó la indemnización por los daños causados como resultado.
• El término “obligación de gestión de proyectos” no se utiliza en ninguna parte de la sentencia.

Se puede ver una actitud de tratar la obligación de soporte, que es un concepto distinto de la gestión de proyectos, como una obligación contractual incluida en el contrato de desarrollo del sistema.

¿Cómo debemos interpretar la naturaleza de la obligación de soporte?

La obligación de soporte aún no es un concepto claro

El caso judicial mencionado anteriormente indica que el proveedor que desarrolló el sistema también debe proporcionar el soporte necesario para que el usuario comience a operarlo. Sin embargo, la obligación de soporte no tiene tantos precedentes acumulados como la obligación de gestión de proyectos, y no hay muchas pistas para entender su realidad. En particular, el término “soporte” en sí mismo incluye el problema de no estar claro qué se debe hacer específicamente.

La obligación de soporte no se reconoce ilimitadamente

Además, el fallo que reconoció la violación de la obligación de soporte por parte del proveedor también mostró un punto muy importante.

El demandado, basándose en el contrato de obra en cuestión, se entiende que tiene la obligación de proporcionar cierto soporte necesario para que el demandante opere el sistema que ha construido y entregado al demandante. Sin embargo, no se entiende que su contenido fuera, como sostiene el demandante, proporcionar todo tipo de soporte gratuitamente hasta que el demandante pueda operar el sistema en cuestión, sin limitación de tiempo.

Fallo del Tribunal de Distrito de Hachioji, Tokio, 5 de noviembre de 2003 (2003)

Si el principal trabajo aceptado es el “desarrollo” del sistema, se puede considerar que también hay restricciones en lo que se debe hacer como soporte para la “operación” posterior. En este fallo, también se pueden encontrar varios puntos característicos, como citar las voces de los usuarios que solicitan apoyo en el texto del fallo, mencionar el contenido de la estimación previa, y tocar el tema de la existencia de una cláusula especial para proporcionar soporte. En otras palabras, se puede considerar que la intención era ser bastante cauteloso en la determinación de la violación de la obligación, teniendo en cuenta que si el concepto de obligación de soporte se expande ilimitadamente, impondría una gran carga al proveedor.

La realidad de la obligación de soporte debe ser considerada junto con la obligación de cooperación del usuario

En resumen, la discusión hasta ahora puede ser vista como “¿Cómo deben compartir la carga de trabajo entre el usuario y el proveedor en la etapa inicial de operación en el desarrollo del sistema?”. Ciertamente, esto incluye el problema algo complicado de cuánta obligación legal debe asumir el proveedor al inicio de la operación, a partir del contrato de “desarrollo”. Al mismo tiempo, no se puede negar que hay una fuerte tendencia a requerir un juicio basado en circunstancias individuales.

Sin embargo, se puede considerar que la realidad de la obligación de soporte que el proveedor debe asumir se vuelve más segura al entender la obligación de cooperación que el usuario debe asumir.

Después de todo, el esfuerzo por mejorar las operaciones con un nuevo sistema tiene el aspecto de ser un trabajo conjunto entre el proveedor, que es un experto en tecnología, y el usuario, que tiene conocimientos de las operaciones internas. Por lo tanto, en lo que respecta a esta obligación de soporte, al aclarar los asuntos que el usuario debe resolver con esfuerzo propio como parte del “cumplimiento de la obligación de cooperación”, a menudo se define el alcance de la misma.

Resumen

En este artículo, hemos organizado la información sobre la ‘obligación de soporte’, que podría considerarse una derivación del manejo de proyectos, basándonos en los fundamentos de la gestión de proyectos. Aunque todavía hay muchos aspectos ambiguos en el concepto de obligación de soporte, creemos que lo más importante para entenderlo son los elementos básicos como la ‘obligación de gestión de proyectos’ y la ‘obligación de cooperación’.