¿Cuál es el método de manejo cuando el desarrollo del sistema se interrumpe debido a las circunstancias del usuario?

El trabajo de desarrollo de sistemas a menudo toma la forma de proyectos a largo plazo. Entonces, ¿qué puede hacer el proveedor si, después de haber comenzado a trabajar en el desarrollo del sistema, el usuario unilateralmente dice “ya no necesitamos ese sistema, no tienes que hacerlo”?

En este artículo, organizaremos las características únicas de los contratos de desarrollo de sistemas y explicaremos las medidas a tomar en tales casos.

La importancia de considerar las interrupciones por conveniencia del usuario

El contrato de desarrollo de sistemas tiene varios aspectos característicos cuando se ve desde una perspectiva contractual. Uno de ellos es que el plazo de ejecución suele ser largo, y el proveedor, con una gran discreción, tiene una gran responsabilidad en la gestión del proyecto. Para una explicación detallada del contenido general de las obligaciones de gestión de proyectos que el proveedor debe asumir, consulte el siguiente artículo.

https://monolith.law/corporate/project-management-duties[ja]

Otro aspecto es que el usuario, aunque sea un cliente, tiene una amplia responsabilidad de cooperar con el trabajo del proveedor. Dado que se trata de un sistema que se utilizará internamente, no es suficiente simplemente “delegar” todo al proveedor. Desde dentro de la empresa, existe la obligación de cooperar adecuadamente para que el proveedor pueda ejercer su especialidad en el trabajo. Para una explicación detallada de esto, consulte el siguiente artículo.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Para resumir brevemente el contenido anterior, entre el proveedor y el usuario, además de la relación de intercambio entre el “contratista externo” que desarrolla el sistema y el “cliente” que paga la remuneración, también existe un aspecto de “compañeros” que deben colaborar hacia el objetivo común de completar el proyecto. Esta complejidad de la relación no es común en, por ejemplo, un sastre que simplemente hace trajes a medida, y es una característica importante de los contratos relacionados con el desarrollo de sistemas. Los conflictos relacionados con el desarrollo de sistemas son complicados debido a esta complejidad de la relación, y una vez que se enredan, se vuelve complicado determinar cómo organizar legalmente la relación entre las dos partes.

Considerar el problema de cómo entender la relación de derechos y obligaciones entre las dos partes cuando el usuario cambia de opinión y de repente dice cosas como “Finalmente, no necesitamos ese sistema, así que ya no necesitamos avanzar en el proyecto” tiene el significado de presentar un ejemplo práctico de pensar legalmente frente a esta compleja relación contractual. A continuación, organizaremos los asuntos a considerar después de asumir tal caso.

Primero, organice las razones por las que se ha solicitado la cancelación

Desde el punto de vista del proveedor, puede haber casos en los que se perciba que “el usuario quiere interrumpir el proyecto unilateralmente”, pero no necesariamente se comparte esta percepción con el usuario. Por ejemplo, supongamos un caso en el que se estaba desarrollando un proyecto para crear un sistema para gestionar el personal de los empleados en las oficinas en el extranjero, pero luego se retiró el plan de expansión en el extranjero en sí, haciendo innecesario el desarrollo de dicho sistema. Ciertamente, a partir de esta explicación, podría interpretarse como un cambio de opinión unilateral por parte del usuario.

Sin embargo, ¿qué pasaría si, en el proceso que llevó a tal decisión, hubiera habido problemas reales de incumplimiento de las obligaciones de gestión del proyecto por parte del proveedor, como retrasos en cada etapa, y las dificultades en el progreso del desarrollo en sí también hubieran contribuido al cambio de política de la empresa?

Como se mencionó anteriormente, el desarrollo de sistemas es algo que tanto el proveedor como el usuario deben llevar a cabo en estrecha colaboración, asumiendo grandes responsabilidades. Por lo tanto, incluso si el usuario es quien quiere interrumpir y el proveedor considera que es una cancelación por conveniencia personal del usuario, debe reconocerse que existe la posibilidad de que se señalen las razones atribuibles al proveedor y se devuelva la afirmación de que es una cancelación basada en incumplimiento de obligaciones o una cancelación mutua.

La distinción entre si es una cancelación por conveniencia personal, una cancelación basada en incumplimiento de obligaciones, o una cancelación mutua, tiende a ser juzgada individualmente en cada caso, dependiendo del progreso del proyecto y el historial de negociaciones hasta ese momento. Por lo tanto, si el proveedor va a proceder con el manejo posterior bajo la percepción de que es una cancelación por conveniencia personal del usuario, es importante dejar un registro claro de esto en las actas de las reuniones, etc., para evitar disputas sobre este punto más adelante.

Confirmando las cláusulas de base para reclamaciones de remuneración y daños y perjuicios

Tomando en cuenta los puntos mencionados anteriormente, si podemos proceder con la conversación como una cancelación por conveniencia del usuario, a continuación, debemos considerar si es posible o no que el proveedor reclame al usuario una remuneración proporcional a la finalización del trabajo, o una reclamación por daños y perjuicios.

Las cláusulas que deben consultarse en tales casos varían según el tipo de contrato. Esto se debe a que los contratos relacionados con el desarrollo de sistemas se pueden dividir en contratos de obra y contratos de mandato.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Y en el caso de los contratos de mandato y de obra, el Código Civil japonés establece lo siguiente:

a.) En el caso de un contrato de mandato
Reclamación de remuneración: Artículo 648, párrafo 3 del Código Civil japonés
Cuando el mandato termina a mitad de camino debido a una causa que no puede atribuirse al mandatario, este puede reclamar una remuneración proporcional al trabajo ya realizado.
Reclamación de daños y perjuicios: Artículo 651 del Código Civil japonés
1. El mandato puede ser revocado en cualquier momento por cualquiera de las partes.
2. Si una de las partes revoca el mandato en un momento desfavorable para la otra parte, esa parte debe indemnizar a la otra por los daños sufridos. Sin embargo, esto no se aplica si hay una causa justificada.

b.) En el caso de un contrato de obra
Reclamación de daños y perjuicios: Artículo 641 del Código Civil japonés
Mientras el contratista no haya terminado el trabajo, el cliente puede rescindir el contrato en cualquier momento indemnizando los daños.

Además, se considera que el alcance de los daños y perjuicios basados en el Artículo 641 del Código Civil japonés incluye no solo los costos ya incurridos, sino también “los beneficios que se habrían obtenido si el contrato no hubiera sido rescindido”. Esto refleja la idea de que es inútil que la ley obligue a completar un trabajo que se ha vuelto innecesario para el cliente, y que en tales casos es más razonable garantizar los beneficios del contratista a través del pago de una compensación equivalente.

Por supuesto, en cuanto a los daños y perjuicios basados en el Artículo 641 del Código Civil japonés, no es raro que se excluyan en contratos individuales entre el proveedor y el usuario. En tales casos, las promesas individuales hechas entre las partes (es decir, el contrato) prevalecen, y es posible que las disposiciones del Código Civil japonés no se apliquen, por lo que se requiere precaución.

Avanzar en la prueba de volumen de trabajo y daños

En el caso de la cancelación por conveniencia del usuario, lo que se ve comúnmente en el contrato es la estipulación de que se puede solicitar el pago de la comisión por el volumen de trabajo (es decir, la parte completada) y la indemnización por daños. Por lo tanto, normalmente, desde el lado del proveedor, es necesario llevar a cabo la prueba del volumen de trabajo y los daños para hacer una reclamación de indemnización por daños.

Sin embargo, se puede prever que esta prueba del volumen de trabajo, es decir, la prueba de la proporción de finalización, será una tarea muy ardua si se lleva a cabo en realidad. Esto se debe a que, especialmente cuando hay varios subcontratistas, se puede considerar que la cantidad de entrevistas para verificar el progreso, si se llevan a cabo en realidad, será considerable. Además, si se tiene que hacer todo, desde la creación de documentos para respaldar los resultados de las entrevistas hasta la documentación del contenido de las entrevistas en sí, el esfuerzo será enorme. Si hay un riesgo de que, a pesar de todo esto, se diga que la prueba es insuficiente, el esfuerzo dedicado a preparar la prueba puede resultar en vano, y hay muchos desafíos.

Teniendo en cuenta estos puntos, como medida, se puede considerar hacer cosas como especificar desde el principio en la etapa del contrato que si se cancela a mitad de camino, se calculará prorrateado por el número de días hasta el momento de la cancelación, para hacer los cálculos de manera simple. Además, considerando que la solicitud basada en el volumen de trabajo requiere mucho esfuerzo para probar, se puede considerar un enfoque en el que se renuncia a la solicitud basada en el volumen de trabajo en sí y se hace una solicitud por los “costos incurridos en el desarrollo de la parte ya completada”. Si se trata de un costo de desarrollo interno, no es raro que se pueda calcular fácilmente con una simple fórmula de “horas de trabajo x tarifa”. Especialmente en proyectos con bajos márgenes de beneficio, al priorizar las reclamaciones basadas en costos en lugar de en el volumen de trabajo, se puede esperar que se realice la compensación de pérdidas mientras se da prioridad a la facilidad de recuperación de deudas, lo que puede ser una medida de alivio más realista en muchos casos.

¿Qué deberían considerar los usuarios desde su perspectiva?

Por cierto, también hay puntos que los usuarios, que están considerando cancelar por su propia voluntad, deben considerar de antemano. Esto es, verificar una cantidad estimada de la compensación por daños y perjuicios que deberían pagar al proveedor, como cuánto podría ser aproximadamente. Cuando decimos “estimado” aquí, es para tener una idea general y establecer un punto de referencia para las negociaciones futuras (incluso si la cantidad no es precisa, será suficiente, ya que retrasar la expresión de la intención de cancelar sería poner el carro delante del caballo).

Si la cantidad estimada que ha verificado se considera injustamente alta, debe solicitar una explicación de las razones. Sin embargo, si intenta negociar de manera irrazonable para reducir la cantidad a pagar, también existe el riesgo de que surjan litigios innecesarios y la situación se complique aún más. Si las negociaciones entre las dos partes parecen ser difíciles, podría ser una opción consultar a un abogado.

Además, en este artículo, hemos estado explicando con la premisa de que se ha establecido un contrato para el desarrollo del sistema. Sin embargo, en la realidad del desarrollo de sistemas, no es raro que se dispute si el contrato se ha establecido válidamente en primer lugar. Hemos explicado esto en detalle en el siguiente artículo.

https://monolith.law/corporate/system-development-contract[ja]

Resumen

En este artículo, hemos explicado el proceso para manejar situaciones en las que un proyecto se interrumpe debido a circunstancias del usuario. Sin embargo, el punto más importante de este artículo es la necesidad de considerar si realmente se puede atribuir a las circunstancias del usuario y si realmente no hubo negligencia por parte del proveedor.

El desarrollo de sistemas, que es un proyecto en el que tanto el proveedor como el usuario asumen grandes responsabilidades, requiere una consideración cuidadosa de si realmente es posible atribuir la culpa unilateralmente a la otra parte. Si no se considera esto de antemano, podría dar lugar a una situación que solo echa más leña al fuego. Este es un punto que debería tenerse en cuenta.