Юридические проблемы, связанные с переходом от старой системы к новой в процессе разработки системы

Создание новой IT-системы для использования в компании является типичной областью работы IT-инженеров. Однако, когда мы говорим о “создании новой системы”, часто подразумевается также и процесс “ликвидации старой системы”. В этой статье мы рассмотрим проект разработки новой системы с точки зрения “ликвидации старой системы” и обсудим различные юридические вопросы, связанные с этим.

Что означает переход на новую систему

Срок службы IT-систем не вечен

IT-системы, используемые в компаниях, не являются вещами, которые можно использовать бесконечно после их создания. К тому же, не всегда хорошо продолжать использовать старые вещи. Хотя есть различия между компаниями и назначением систем, в общем, считается, что после примерно 10 лет использования одной системы, лучше принять решение о замене на новую.

За 10 лет производительность компьютеров на рынке может кардинально измениться. Таким образом, программы, которые не могли быть реализованы из-за ограничений, таких как скорость обработки компьютера 10 лет назад (хотя они казались простыми и хорошо спроектированными с точки зрения человека), могут быть реализованы сейчас. Кроме того, если вы продолжали использовать систему 10 лет после ее создания, рабочий процесс и внутренние правила компании могли значительно измениться за это время. Код, который был реализован после этого для соответствия изменениям во внутренней и внешней бизнес-среде компании, может стать настолько сложным и запутанным, что его невозможно распознать с экрана. В таком случае, даже если пользователи хотят добавить новые функции, разработчики могут считать, что дальнейшая реализация становится невозможной.

Старые системы могут постепенно приводить к большому количеству “ручной работы” для IT-инженеров (например, выпуск запросов для индивидуального извлечения данных). Сама система, став старой, иронично начинает “персонализировать” работу. Когда задачи, связанные со старой системой, становятся слишком “персонализированными”, и вы пытаетесь применить дополнительные “системные” меры, проект “разработка новой системы для перехода с старой системы” начинает развиваться.

Разработка новой системы происходит параллельно с ликвидацией старой

Как уже упоминалось, в проекте по разработке системы (хотя это не всегда так) часто одновременно присутствует аспект перехода от старой системы. Сама система часто меняется дискретно, от одного дня к другому.

Однако, ход ежедневной работы должен быть непрерывным, идущим от прошлого к настоящему, от настоящего к будущему. При переходе к новой системе часто возникают различные проблемы, такие как сохранение необходимых данных из прошлого, непрерывное продвижение текущей работы и выработка превосходных концепций “систематизации” для будущего. Вследствие сложного сочетания этих обстоятельств, разработка новой системы и операции по эксплуатации и обслуживанию существующей системы становятся сложно связанными и неразрывными.

Что такое шаги перехода к новой системе

При переходе от старой системы к новой, особенно важно правильно перенести данные. Шаги переноса данных обычно следуют следующей процедуре:

1. Определить, какие данные, хранящиеся в старой системе, следует перенести в новую систему. Нужно также определить, какие данные должны быть легко доступны для поиска из интерфейса новой системы, а какие данные могут быть недоступны для поиска (например, для аудита), но должны быть доступны при необходимости.
2. Из данных, определенных на шаге 1, выгрузить данные, которые должны быть загружены в новую систему, в формате, например, CSV-файла.
3. Загрузить данные, извлеченные на шаге 2, в новую систему.
4. Проверить, отражены ли данные, загруженные на шаге 3, в новой системе, и подтвердить, что перенос был выполнен правильно. Обычно результаты проверки правильности переноса документируются путем сохранения доказательств, таких как экраны отображения или печатные отчеты (так называемый тестовый процесс).

Переход на новую систему представляет сложность в определении ролей пользователей и поставщиков

В шагах переноса данных, о которых говорилось ранее, часто возникает проблема определения, до какой степени пользователи должны рассматривать это как внутреннюю проблему своей компании и контролировать ее. Кроме того, общий обзор обязанностей пользователей в рамках проектов разработки систем, не ограничиваясь только переносом данных, можно найти в статье по ссылке ниже.

В общем, в проектах разработки систем, поставщики часто превосходят пользователей в специализированных знаниях для разработки систем (или, скорее, это часто является причиной, по которой они получают задание). Однако, с другой стороны, часто только пользователи могут обсуждать “желаемое состояние” своей системы.

Учитывая это, можно предложить, что пользователи должны выполнять шаги 1 и 4, упомянутые ранее. Если выразиться иначе, можно сказать, что в процессе переноса данных “определение требований” к данным, которые должны быть перенесены, и “приемка” данных, перенесенных в соответствии с требованиями, могут быть организованы как обязанности пользователя. Или, как альтернативный способ организации, если в компании пользователя есть люди, обладающие обширными знаниями о старой системе, можно предложить, чтобы они также были ответственны за шаг 2.

Если можно обойтись без аутсорсинга и решить вопросы со старой системой внутри компании, можно предположить, что заказчик захочет аутсорсить только вопросы новой системы. В таких случаях, в процессе переноса данных, роли пользователей и поставщиков могут стать неясными. Кроме того, когда пользователи аутсорсят задачи по разработке систем поставщикам, обычно ожидается, что поставщики будут выполнять определенные роли, и на них возлагаются определенные юридические обязанности. Для общего понимания этого вопроса, пожалуйста, обратитесь также к статье по ссылке ниже.

Прошлые судебные прецеденты, связанные с переходом на новую систему

В проектах по разработке систем с целью перехода на новую систему действительно возникали проблемы, которые приводили к судебным разбирательствам. В приведенном ниже примере решения суда, во время переноса данных произошла ошибка, в результате которой в новой системе возникли несоответствия и баги в нескольких данных, а также задержки в сроках поставки. Вопросом спора стало, какие обязательства перед проектом несут стороны поставщика и пользователя. В итоге суд пришел к выводу, что поставщик нарушил свои обязательства по оказанию должного внимания, указав следующие аспекты:

Ответчик, выполняя обязательства по переносу данных на основании данного договора подряда, не просто переносил данные с старой системы на новую, но и нес обязательства по запуску новой системы с перенесенными данными. Конкретно, перед началом работы по переносу данных, ответчик должен был исследовать и анализировать данные, подлежащие переносу с старой системы, понять их характер и состояние, рассмотреть, станут ли эти данные препятствием для работы новой системы после их переноса, и если они станут препятствием, определить, когда и каким образом эти данные следует исправить. Затем ответчик должен был приступить к работе по переносу данных (планирование переноса, разработка инструментов для переноса, перенос данных), и в конечном итоге нести обязательства по запуску новой системы с данными, перенесенными со старой системы.

Считается справедливым признать, что в данном случае ответчик нес обязательства по исправлению и устранению несоответствий данных при их переносе.

Решение Токийского окружного суда от 30 ноября 2016 года (Heisei 28)

В этом случае, пользователь обычно берет на себя шаги 1 и 4, а поставщик – шаги 2 и 3. То есть, поставщик вначале берет на себя извлечение данных из старой системы. Следовательно, суд решил, что если поставщик взял на себя извлечение данных, то он должен был заранее рассмотреть, сможет ли он провести эту операцию без проблем.

Однако, что было бы, если бы пользователь заранее определил извлечение данных (шаг 2) как свою задачу и не смог успешно выполнить эту операцию? В этом случае можно предположить, что из-за недостатка предварительного исследования пользователя о том, сможет ли он успешно извлечь данные, возникли бы задержки в сроках поставки, и теперь пользователь мог бы быть обвинен в нарушении обязательств по сотрудничеству.

Кроме того, такие решения принимаются не только на основании контрактов, но и на основании протоколов совещаний, проводимых в соответствии с прогрессом разработки системы. Важность протоколов обсуждается подробно в статье ниже.

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

Заключение

Проекты по разработке систем предполагают, что как со стороны пользователя, так и со стороны поставщика несутся значительные обязательства, и они должны вести тщательное общение друг с другом. Поэтому, как было указано в вышеупомянутом судебном прецеденте, даже незначительные изменения в исходных условиях могут легко перевернуть ответственность на сторону пользователя или поставщика.

Учитывая, что система может содержать огромное количество данных и сложные механизмы, которые невозможно представить, исходя только из внешнего вида интерфейса, а также то, что небольшие различия в исходных условиях могут значительно изменить окончательное судебное решение, можно сказать, что важно комплексно подходить к управлению рисками проектов по разработке новых систем, включая устранение старых систем.