Юридичні проблеми, що супроводжують перехід від старої системи при розробці системи

Створення нової ІТ-системи для використання в компанії є типовою сферою діяльності ІТ-інженерів. Однак, коли ми говоримо про “створення нової системи”, часто в цьому контексті також мається на увазі “відміна використання попередньої системи”. У цій статті ми розглянемо проект розробки нової системи з точки зору “відміни старої системи” і обговоримо різні юридичні питання, пов’язані з цим процесом.

Що означає перехід до нової системи

Термін служби IT-систем не є вічним

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

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

Старі системи можуть поступово змушувати IT-інженерів виконувати багато “ручної роботи” (наприклад, виконувати операції, такі як відправка запитів для індивідуального вилучення даних). Сама система, якщо вона стає старою, іронічно, починає “особистішувати” роботу. Коли робота, пов’язана зі старою системою, стає занадто особистою, і починаються спроби впровадити додаткові “системні” заходи, починається проект “розробка нової системи для переходу зі старої системи”.

Розробка нової системи відбувається паралельно з ліквідацією старої

Як вже було зазначено, багато проектів розробки систем (хоча не всі) часто включають аспект переходу від старої системи. Сама система часто змінюється неперервно, починаючи з певного дня.

Однак, щоденний прогрес роботи повинен бути неперервним, від минулого до сьогодення, від сьогодення до майбутнього. Зберігаючи необхідні дані з минулого, не перешкоджаючи поточному прогресу роботи, і висуваючи передові ідеї “систематизації” для майбутнього, перехід до нової системи часто супроводжується різними викликами. Ці обставини, які поєднуються у складний спосіб, роблять розробку нової системи та експлуатацію та обслуговування існуючої системи складно пов’язаними, і в деяких випадках вони стають нерозривно пов’язаними.

Що таке кроки переходу до нової системи

При переході від старої системи до нової, особливо важливо правильно перенести дані. Кроки перенесення даних зазвичай відбуваються за наступною процедурою:

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

Перехід до нової системи ускладнює розподіл ролей між користувачами та постачальниками

У кроках перенесення даних, про які йшлося вище, часто виникає проблема: до якої міри користувачі повинні вважати це внутрішньою проблемою своєї компанії та контролювати її. Зазначимо, що це не тільки про перенесення даних, але й про загальну обов’язковість співпраці користувачів у проектах розробки систем. Для загального огляду цього питання, будь ласка, дивіться статтю нижче.

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

Як правило, у проектах розробки систем, постачальники часто переважають над користувачами у термінах професійних знань для розробки систем (або, навпаки, це часто є причиною, чому вони отримують доручення). Однак, з іншого боку, часто тільки користувачі можуть обговорювати “бажаний стан” своєї системи.

Враховуючи ці аспекти, можна розглянути розподіл ролей, за яким користувачі виконують вищезгадані кроки 1 та 4. Якщо сказати іншими словами, можна сказати, що “визначення вимог” до даних, які потрібно перенести, та “прийняття” даних, перенесених відповідно до вимог, можуть бути визначені як обов’язки користувачів. Або, як інший варіант розподілу ролей, якщо у користувачів є люди з багатими знаннями про стару систему, вони також можуть бути відповідальними за крок 2.

Якщо можна впоратися зі старою системою внутрішньо, без залучення сторонніх виконавців, можна розглянути замовлення лише нової системи у постачальника. У такому випадку, у процесі перенесення даних, розподіл ролей між користувачами та постачальниками може стати неоднозначним. Зазначимо, що коли користувачі замовляють у постачальників роботу, пов’язану з розробкою систем, зазвичай від постачальників очікують певні ролі, а також є певні юридичні обов’язки. Для загального огляду цього питання, будь ласка, дивіться також статтю нижче.

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

Минулі судові випадки, пов’язані з переходом до нової системи

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

Відповідач, виконуючи роботу з перенесення даних на основі цього договору про надання послуг, не просто переніс дані зі старої системи до нової, але також мав обов’язок запустити нову систему за допомогою перенесених даних. Конкретно, перед початком роботи з перенесенням даних, він мав дослідити та проаналізувати дані, які мали бути перенесені зі старої системи, зрозуміти їх характер та стан, розглянути, чи стануть ці дані перешкодою для роботи нової системи після їх перенесення, і якщо вони стануть перешкодою, він мав визначити, коли і яким чином він виправить ці дані, а потім приступити до роботи з перенесенням даних (планування перенесення, розробка інструментів для перенесення, перенесення даних), і нарешті, він мав обов’язок запустити нову систему за допомогою даних, перенесених зі старої системи.

Це вважається справедливим, і в цьому випадку, при перенесенні даних, він мав обов’язок виправити невідповідності даних.

Вирок Токійського окружного суду від 30 листопада 2016 року (Heisei 28)

У цьому випадку, користувач мав виконувати кроки 1 та 4, а постачальник – кроки 2 та 3. Тобто, постачальник спочатку погодився витягнути дані зі старої системи. Тому суд вирішив, що якщо постачальник, як спеціаліст у розробці систем, погодився витягнути дані, він мав би заздалегідь розглянути, чи може ця робота з витягування даних бути виконана гладко.

Однак, що було б, якщо користувач заздалегідь погодився виконувати крок 2 (тобто витягування даних) і не зміг виконати цю роботу? У такому випадку, можливо, користувач, який не провів попереднє дослідження, чи може витягування даних бути виконане гладко, міг би бути звинувачений у порушенні обов’язку співпраці, якщо це призвело до затримки в термінах.

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

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

Підсумки

Проект розробки системи передбачає, що як користувачі, так і постачальники взаємно беруть на себе багато обов’язків, ведучи детальну комунікацію. Тому, як було зазначено в раніше наведених судових рішеннях, навіть незначні зміни в передумовах можуть легко перекинути відповідальність на будь-яку сторону – користувача чи постачальника.

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