¿Cuál es el significado legal de los objetivos de gestión y los objetivos numéricos en los proyectos de desarrollo de sistemas?

Los proyectos de desarrollo de sistemas a menudo están estrechamente vinculados con mejoras significativas en las operaciones de las empresas y los lugares de trabajo. En estos casos, se puede requerir una actitud que contribuya a resolver los problemas de gestión de la empresa del lado del usuario y a alcanzar objetivos numéricos. Sin embargo, ¿es realmente una obligación legal comprometerse con estos objetivos de gestión? El problema se convierte en qué significado legal tienen los objetivos numéricos y de gestión. En este artículo, explicaremos los problemas legales asociados con varios “propósitos” y “objetivos” en el desarrollo de sistemas.

¿Por qué los objetivos y metas del desarrollo de sistemas se convierten en semillas de conflicto?

Porque se sitúa entre la obligación de cooperación del usuario y la discreción del proveedor

Desde el punto de vista de las transacciones comerciales, hay varios aspectos característicos en los proyectos de desarrollo de sistemas. Uno de ellos es que el proyecto de desarrollo de sistemas por parte del proveedor no puede realizarse solo por el proveedor, sino que requiere la cooperación del lado del usuario. Esta obligación se conoce en la jurisprudencia como “obligación de cooperación”. Principalmente, se requiere que el usuario coopere en el desarrollo del sistema en fases como ① definición de requisitos ② diseño básico ③ aceptación de los productos entregables.

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

Otro aspecto es que se espera que el proveedor ejerza una gran discreción en su trabajo. Existe un término legal que resume lo que el proveedor debe hacer en todo el proyecto de desarrollo del sistema, que es la “obligación de gestión del proyecto”. Este tema se explica en detalle en el siguiente artículo.

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

Resumiendo lo anterior, podemos señalar dos puntos importantes aquí.

• Se espera que el usuario proporcione la información necesaria al proveedor y coopere con el trabajo de desarrollo del proveedor.
• Se espera que el proveedor comprenda los objetivos y metas del proyecto para el usuario y tome medidas que se ajusten a ellos.

Debido a estas dos circunstancias, se plantea la cuestión de hasta qué punto el logro de los objetivos de gestión y los objetivos numéricos explicados previamente por el usuario puede convertirse en una obligación legal del proveedor. En otras palabras, aunque es una obligación del usuario resumir lo que el proveedor debe hacer (no algo vago como los objetivos) en las especificaciones y presentarlo, el proveedor también tiene la obligación como experto de proporcionar lo que el usuario realmente necesita, no solo de hacer lo que se le ha dicho. Este choque de opiniones contradictorias es una característica de los conflictos en torno a los “objetivos” y “propósitos” del desarrollo de sistemas. Desde el punto de vista legal, el desafío en la práctica es proporcionar directrices para la resolución de conflictos que sean justas para ambas partes.

Escenarios concretos en los que los objetivos del usuario afectan al proyecto

Los proyectos de desarrollo de sistemas a menudo están vinculados a medidas de mejora y eficiencia de operaciones a gran escala en empresas y lugares de trabajo, y a menudo se realizan entrevistas sobre problemas de gestión y objetivos de gestión incluso en las etapas de planificación y propuesta. Aquí, se puede considerar que se producen intercambios sobre el costo-efectividad del desarrollo del sistema y varios objetivos numéricos.

• Reducción de los costos laborales debido a la eficiencia
• Aumento de las ventas y los ingresos
• Reducción del tiempo de trabajo

Por ejemplo, si los elementos anteriores son el objetivo final del proyecto, se puede considerar que el proveedor explica el efecto de la inversión en el desarrollo del sistema desde una posición similar a la de un consultor y realiza ventas.

¿Qué casos judiciales se han presentado donde los objetivos de gestión propuestos por el usuario han sido problemáticos?

Sin embargo, los proveedores son, en última instancia, expertos en desarrollo de sistemas. Si se les impone toda la responsabilidad de los objetivos de gestión del usuario, podría ser demasiado severo.

Caso en el que se propuso mejorar la velocidad de las operaciones como objetivo

En relación con este caso, en el documento de planificación creado al inicio del proyecto, que se cita a continuación, se registraron los propósitos y objetivos para iniciar el proyecto de desarrollo del sistema. Sin embargo, una vez que el sistema se completó y se inició su operación, no se pudo lograr ese propósito y objetivo, lo que llevó a un conflicto. En el documento de planificación inicial, se indicaba que se pretendía lograr el siguiente estado después de que el sistema se completara y comenzara a utilizarse:

• Reducir el tiempo de entrada manual en un 50%
• Permitir que el procesamiento administrativo utilizando el sistema de TI se complete dentro de un período determinado

El usuario intentó perseguir al proveedor por responsabilidad por incumplimiento de obligaciones y responsabilidad por defectos porque no pudo lograr estos resultados. Sin embargo, el tribunal no aceptó este argumento (las partes subrayadas y en negrita son adiciones del autor).

Y, (omisión) según la totalidad de los argumentos, ① el propósito de este caso es “mejorar la eficiencia de las operaciones”, “construir la base de CRM”, “realizar una gestión visible”, etc., que son abstractos, y los objetivos también son “aumentar los puntos de contacto con los clientes”, “redistribuir el esfuerzo de los trabajadores administrativos a control interno y apoyo a las ventas”, “hacer predicciones de ventas más precisas”, “restringir descuentos excesivos en ventas”, etc., que son en su mayoría abstractos, y “reducir el tiempo de entrada en un 50%”, “reducir el tiempo de creación de estimaciones en un 50%”, “realizar la divulgación legal dentro del período legal”, etc., son objetivos que dependen de cómo se maneja la gestión y las operaciones del demandado después de la implementación de SBO, y no son de la naturaleza que la compañía de desarrollo de sistemas, que es el demandante, pueda asumir su logro, ② en las actas de las reuniones después del inicio de este proyecto, no hay ninguna mención de que se haya discutido específicamente sobre el logro de los propósitos y objetivos de este caso, ③ en el plan de proyecto de este caso, “para convertirse en una empresa cotizada”, etc., expresiones que no pueden ser consideradas como de la naturaleza de un contrato se han utilizado, (omisión) teniendo en cuenta estas circunstancias, se puede reconocer que el demandante creó la descripción del propósito de este caso en el plan de proyecto de este caso basándose en la explicación del demandado, para evitar que el proyecto fracasara, fue para obtener un entendimiento común sobre el propósito y los resultados del proyecto, y no se puede reconocer que el demandado, encargó al demandante el desarrollo del sistema para lograr el propósito de este caso. (omisión) Por lo tanto, no se puede reconocer que el demandante asumió el desarrollo del sistema para lograr el propósito de este caso del demandado, (omisión) no hay razón para ninguna de las afirmaciones de responsabilidad por incumplimiento de obligaciones y responsabilidad por defectos.

Sentencia del Tribunal de Distrito de Tokio, 28 de diciembre de 2010 (Año 22 de Heisei)

¿Cuál es el significado legal de los objetivos de gestión y los objetivos numéricos que se pueden inferir de los casos judiciales?

Como se menciona en esta sentencia, si se pueden lograr los propósitos del desarrollo del sistema y los objetivos cuantificados numéricamente, normalmente intervienen varios factores, como los esfuerzos de gestión del usuario que utiliza el sistema. Por lo tanto, se debe considerar que el umbral para hacerlo la responsabilidad del proveedor es muy alto. En primer lugar, si se reconoce la responsabilidad del proveedor por incumplimiento de obligaciones y responsabilidad por defectos, eso significa que la “realización” de los “propósitos” y “objetivos” se incorporó como parte del contenido del contrato. Sin embargo, en este caso, los “propósitos” y “objetivos” fueron:

• En cuanto a los que son abstractos y vagos, no se ajustan a la naturaleza de las obligaciones legales, por lo que es difícil considerarlos como parte del contenido del contrato.
• En cuanto a los que requieren esfuerzos de autoayuda por parte del usuario, especialmente en el lado de la gestión, ya que están fuera del control del proveedor, es inapropiado atribuirlos al proveedor, y es difícil considerarlos como parte de las obligaciones contractuales.

Esto es lo que se evaluó legalmente.

Lo que se puede inferir aún más de esta sentencia

Esta sentencia también contiene varios contenidos interesantes.

• El hecho de que el tribunal también tenga en cuenta que compartir los “propósitos” y “objetivos” de un proyecto de desarrollo de sistemas puede ser simplemente un esfuerzo de comunicación para obtener un “entendimiento común” entre el usuario y el proveedor.
• Al considerar cuán esenciales fueron estos “propósitos” y “objetivos” en todo el proyecto, también se refiere a las actas de las reuniones.

Además, desde el punto de vista de la importancia de la gestión de documentos y las actas de las reuniones en relación con los problemas legales asociados con los proyectos de desarrollo de sistemas, se proporciona una explicación en el siguiente artículo.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Consideraciones legales en torno a los objetivos de gestión y los objetivos numéricos

Por supuesto, en cuanto a los problemas legales en torno a estos “propósitos” y “objetivos”, también debemos tener en cuenta los siguientes puntos adicionales.

La historia cambia dependiendo de si la consultoría es pagada o gratuita

Si no solo se trata de un proyecto de desarrollo de sistemas, sino que también se ha firmado un contrato de consultoría pagada, las circunstancias pueden cambiar significativamente. Si, sin tener en cuenta cuántos recursos de gestión tiene el usuario, se ha establecido un plan de ejecución con pocas posibilidades de realización, es posible que se le pueda exigir responsabilidad por incumplimiento de deudas en la parte del contrato de consultoría pagada.

Los defectos en los resultados y las inconsistencias en las funciones y los requisitos de especificación son problemas separados

Además, si hay defectos en el propio proyecto de “desarrollo”, es decir, si se confirman problemas o errores en los resultados, debemos entender esto como un problema separado. En ese caso, no es necesario hablar de los “propósitos” y “objetivos” de gestión, sino que el problema es la consistencia entre los resultados y las funciones requeridas y las especificaciones. Por ejemplo, las medidas que el usuario debe tomar si se descubre un defecto en el sistema después del hecho se explican en el siguiente artículo.

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

Otro tema relacionado es que se puede reconocer que el proveedor tiene la obligación de implementar a su discreción, aunque no esté incluido en los requisitos. Este tema se explica en detalle en el siguiente artículo.

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

En cualquier caso, se puede decir que se debe entender como algo similar pero diferente a los conflictos en torno a los “propósitos” y “objetivos”.

Se requiere una comprensión fundamental de temas como la responsabilidad y los contratos

Hasta ahora, hemos explicado los problemas legales relacionados con los “objetivos” y “metas” del desarrollo de sistemas. En disputas sobre estos temas, los tribunales a menudo consideran que los esfuerzos de comunicación para alinear a los usuarios y proveedores son parte integral del proceso, y se espera que comprendan plenamente este punto. Sin embargo, aunque la validez de la conclusión en sí puede ser plenamente comprendida por la intuición práctica de los profesionales, se requiere una comprensión fundamental de cosas como la “responsabilidad” y los “contratos” en el proceso para llegar a esa conclusión. Explicamos estos puntos en el siguiente artículo.

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

Es importante entender que la responsabilidad legal es diferente de la responsabilidad moral vaga, y que el “acuerdo de voluntades” claro entre las dos partes es lo que genera la responsabilidad contractual. Creemos que es importante obtener una comprensión más esencial de estos puntos.