Problemas legales asociados con la transición desde sistemas antiguos en el desarrollo de sistemas

Crear un nuevo sistema de TI para su uso en las empresas es una tarea representativa de los ingenieros de TI. Sin embargo, cuando se habla de “crear un nuevo sistema”, a menudo implica simultáneamente el proceso de “desechar el sistema que se ha estado utilizando hasta ahora”. En este artículo, vamos a reconsiderar el proyecto de desarrollo de un nuevo sistema desde la perspectiva de “desechar el antiguo sistema” y explicaremos los diversos problemas legales que surgen en relación con esto.

¿Qué significa la transición a un nuevo sistema?

La vida útil de los sistemas de TI no es eterna

Los sistemas de TI utilizados en las empresas no son algo que, una vez creado, pueda utilizarse de manera continua para siempre. Además, no siempre es bueno seguir utilizando algo antiguo con cuidado. Aunque varía según la empresa y el uso del sistema, como regla general, existe una tendencia a tomar decisiones de gestión que sugieren que es mejor renovar a algo nuevo después de usar un sistema durante aproximadamente 10 años.

En 10 años, el rendimiento de los ordenadores en el mercado cambia drásticamente. Por lo tanto, por ejemplo, un programa que no era práctico para implementar debido a las limitaciones de velocidad de procesamiento de la computadora hace 10 años (aunque es un diseño simple y excelente desde el punto de vista humano) puede ser implementable ahora. Además, si ha estado utilizando algo durante 10 años desde que lo creó, es posible que el flujo de trabajo de las operaciones de la empresa y las reglas internas hayan cambiado considerablemente durante ese tiempo. El código que se ha implementado posteriormente para responder a los cambios en el entorno de gestión interno y externo de la empresa puede tener una estructura tan compleja e intrincada que no se puede reconocer desde la pantalla. En este punto, incluso si los usuarios quieren agregar funciones, puede llegar a ser imposible para los desarrolladores agregar implementaciones.

Los sistemas antiguos pueden gradualmente generar mucho “trabajo manual” para los ingenieros de TI (como emitir consultas para extraer datos individualmente). Irónicamente, el propio sistema, a medida que envejece, tiende a “personalizar” el trabajo. Cuando se intenta tomar medidas para “sistematizar” aún más las tareas relacionadas con los sistemas que se han vuelto demasiado antiguos y tienen muchas tareas personalizadas, se inicia un proyecto para “desarrollar un nuevo sistema para migrar desde el sistema antiguo”.

El desarrollo del nuevo sistema avanza junto con la abolición del antiguo sistema

Como se mencionó anteriormente, aunque no todos los proyectos de desarrollo de sistemas son así, muchos proyectos de desarrollo de sistemas tienen el aspecto de la transición desde el antiguo sistema. Es común que el sistema en sí cambie de manera discontinua a partir de un cierto día.

Sin embargo, el progreso del trabajo diario debe ser continuo desde el pasado hacia el presente, y desde el presente hacia el futuro. Mientras se almacenan los datos necesarios del pasado, el progreso del trabajo actual no debe ser interrumpido, y a menudo hay varios desafíos asociados con la transición al nuevo sistema, como la presentación de conceptos innovadores de “sistematización” hacia el futuro. Debido a la combinación de estas circunstancias, el desarrollo del nuevo sistema y las operaciones y mantenimiento del sistema existente están complejamente relacionados, y pueden surgir situaciones en las que se establece una relación inseparable.

¿Qué son los pasos para la transición a un nuevo sistema?

Al pasar de un sistema antiguo a uno nuevo, es especialmente importante asegurarse de que los datos se transfieran correctamente. Los pasos para transferir datos suelen seguir el siguiente procedimiento:

1. Identificar claramente cuáles de los datos almacenados en el sistema antiguo deben ser transferidos al nuevo sistema. Esto incluye determinar qué datos deben ser fácilmente buscables desde la interfaz del nuevo sistema, y qué datos, aunque no necesiten ser buscables desde la interfaz (por ejemplo, para auditorías), deben estar disponibles para ser extraídos si es necesario.
2. De los datos identificados en el paso 1, exportar los que deben ser importados al nuevo sistema en un formato como CSV.
3. Importar los datos extraídos en el paso 2 al nuevo sistema.
4. Verificar si los datos importados en el paso 3 se reflejan en el nuevo sistema y confirmar si la transferencia se ha realizado correctamente. Los resultados de esta verificación suelen documentarse a través de capturas de pantalla de la interfaz y la impresión de informes (es decir, el proceso de prueba).

La transición a un nuevo sistema es difícil cuando se trata de definir los roles de los usuarios y los proveedores

En los pasos de la migración de datos mencionados anteriormente, a menudo surge el problema de hasta qué punto los usuarios deben considerar esto como un problema interno y mantenerlo bajo control. Además, para una descripción general de la “obligación de cooperación del usuario” en todos los proyectos de desarrollo de sistemas, no solo en la migración de datos, consulte el siguiente artículo.

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

En general, en un proyecto de desarrollo de sistemas, es cierto que los proveedores a menudo superan a los usuarios en términos de conocimientos especializados para el desarrollo de sistemas (o más bien, a menudo es por eso que se les confía el trabajo). Sin embargo, por otro lado, a menudo solo los usuarios pueden discutir cómo debería ser su sistema.

Con esto en mente, se podría considerar que los usuarios deben llevar a cabo los pasos 1 y 4 mencionados anteriormente. Para decirlo de otra manera, durante la migración de datos, la “definición de requisitos” de los datos a migrar y la “aceptación” de si los datos se han migrado según los requisitos podrían considerarse como obligaciones de cooperación del usuario. O, como otra forma de organizarlo, si hay alguien en el lado del usuario con un amplio conocimiento del antiguo sistema, también podrían ser responsables del paso 2.

Si se puede manejar el antiguo sistema internamente sin necesidad de subcontratar, se podría considerar la posibilidad de subcontratar solo el nuevo sistema al proveedor. De esta manera, en el trabajo de migración de datos, los roles de los usuarios y los proveedores a veces pueden volverse ambiguos. Además, para una explicación general de qué roles se esperan de los proveedores cuando los usuarios subcontratan trabajos relacionados con el desarrollo de sistemas a ellos, y qué obligaciones legales se les asignarán, consulte también el siguiente artículo.

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

Casos judiciales pasados relacionados con la transición a nuevos sistemas

Existen casos reales en los que se han producido problemas durante los proyectos de desarrollo de sistemas destinados a la transición a nuevos sistemas, lo que ha llevado a litigios. El caso citado en la sentencia a continuación implica un fallo en el trabajo de transición durante la migración de datos, lo que resultó en inconsistencias y errores en múltiples datos en el nuevo sistema y retrasos en la fecha de entrega. Se debatió qué obligaciones tenían tanto el proveedor como el usuario en relación con el proyecto ante estos diversos problemas. Como conclusión, se determinó que el proveedor había violado su deber de cuidado, que debería haber asumido como se indica a continuación.

El acusado, en su trabajo de migración de datos basado en este contrato de subcontratación, no se limitó simplemente a migrar los datos del antiguo sistema a este nuevo sistema, sino que asumió la obligación de poner en funcionamiento este nuevo sistema con los datos migrados. En concreto, antes de comenzar el trabajo de migración de datos, investigó y analizó los datos que serían objeto de migración en el antiguo sistema, comprendió la naturaleza y el estado de los datos, consideró si estos datos podrían obstaculizar el funcionamiento del nuevo sistema una vez migrados, y si podrían ser un obstáculo, decidió cuándo y cómo corregir estos datos, y luego se enfrentó al trabajo de migración de datos (diseño de migración, desarrollo de herramientas de migración, migración de datos), y finalmente asumió la obligación de poner en funcionamiento este nuevo sistema con los datos migrados desde el antiguo sistema.

Es apropiado reconocer que en este caso, el acusado tenía la obligación de corregir y resolver las inconsistencias de datos en el momento de la migración de datos.

Sentencia del Tribunal de Distrito de Tokio, 30 de noviembre de 2016 (Año 28 de Heisei)

Este caso implicaba que el usuario asumía los pasos 1 y 4, mientras que el proveedor asumía los pasos 2 y 3. En otras palabras, el proveedor había asumido una vez la extracción de datos del antiguo sistema (paso 2). Por lo tanto, el tribunal también decidió que si el proveedor, como especialista en desarrollo de sistemas, había asumido la extracción de datos, debería haber considerado de antemano si este trabajo de extracción de datos podría realizarse sin problemas.

Por otro lado, ¿qué habría pasado si el usuario hubiera asumido la extracción de datos (paso 2) como su tarea y hubiera fallado en este trabajo después de haber organizado los roles de antemano? En este caso, es posible que el usuario, por no haber investigado de antemano si la extracción de datos podría realizarse sin problemas, haya causado retrasos en la fecha de entrega, y que ahora el usuario pueda ser acusado de violar su deber de cooperación.

Además, tales decisiones se toman no sólo en base al contrato, sino también en base a las actas de las reuniones que se llevan a cabo de acuerdo con el progreso del desarrollo del sistema. La importancia de las actas de las reuniones se explica en detalle en el siguiente artículo.

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

Resumen

Un proyecto de desarrollo de sistemas implica que tanto el lado del usuario como el del proveedor deben asumir muchas obligaciones mutuamente y avanzar mientras se comunican meticulosamente. Por lo tanto, incluso en los casos judiciales mencionados anteriormente, solo un ligero cambio en las condiciones previas puede fácilmente invertir a quién se le atribuye la responsabilidad, ya sea al usuario o al proveedor.

Dada la posibilidad de que un sistema pueda contener una cantidad enorme de datos y mecanismos complejos que no se pueden imaginar desde la apariencia de la pantalla, y que una pequeña diferencia en las premisas puede cambiar significativamente el rumbo del juicio final, se podría decir que es importante abordar de manera integral la gestión de riesgos de los proyectos de desarrollo de nuevos sistemas, junto con la eliminación de los sistemas antiguos.