Які обов'язки підтримки несе вендор після завершення розробки системи

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

Що таке обов’язок підтримки

Загальна інформація про обов’язок підтримки

Коли ми говоримо про обов’язки, які вендор має перед користувачем, одним з найбільш поширених є обов’язок управління проектом. Це поняття, яке було встановлено і згадувалося в судових рішеннях минулого, є загальним поняттям обов’язків, які вендор, як фахівець з розробки систем, має перед проектом.

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

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

Обов’язок підтримки стає проблемою при підтримці користувачів

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

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

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

Випадок, коли на етапі системного тестування виникли перешкоди для виконання роботи користувачем

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

I Порушення обов’язку підтримки
(А) Представник позивача 14 липня 1997 року (рік Хейсей 9) звернувся до відповідача з проханням “Не тільки створити систему, але й подбати про те, щоб вона працювала належним чином до кінця.“, “Ми – дилетанти, тому ми платимо великі гроші, і хочемо, щоб ви зробили так, щоб ми могли використовувати її до кінця.“. На це відповідач пояснив, що можливо створити систему, яка досягне мети впровадження позивача, і обіцяв підтримувати її до того часу, поки вона не працюватиме належним чином. Таким чином, між позивачем і відповідачем було досягнуто угоди, що відповідач підтримуватиме систему до того часу, поки позивач не зможе її належним чином використовувати.
Те, що відповідач має обов’язок підтримки перед позивачем, очевидно з того, що він включив вартість “підтримки впровадження пакету” у вартість контракту у розмірі 1 726 000, а в кошторисі вказано, що щомісячна плата за обслуговування “безкоштовне обслуговування протягом шести місяців після впровадження”, і в документі під назвою “Про майбутню підтримку SE (внутрішні матеріали для обговорення)” підтверджено, що можна отримати підтримку SE для “створення процедури впровадження (плану)” та “перевірки даних/операцій”.

(Б) І тоді, обов’язок підтримки, який відповідач має перед позивачем, конкретно включає, принаймні до того часу, поки позивач не запустить систему, відповідач має, перед позивачем, ① надати відповідні поради щодо способу експлуатації системи, ② взяти участь у тестуванні експлуатації та вирішити проблеми, що виникли в системі під час тестування експлуатації, ③ вдосконалити систему відповідно до результатів тестування експлуатації, ④ провести навчання операторів.
Однак, незважаючи на те, що відповідач стикнувся з багатьма проблемами під час тестування експлуатації, він не віднісся до них серйозно, вважаючи, що це проблема рівня підготовки операторів, і просто вимагав від позивача витрати на навчання операторів, не надаючи позивачу жодної відповідної підтримки для запуску системи.

Рішення відділення Хачіоджі Токійського окружного суду від 5 листопада 2003 року (рік Хейсей 15)

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

• Порушення обов’язку підтримки розглядається як “невиконання зобов’язань”, і тому було вимагано відшкодування збитків, які виникли в результаті цього.
• Термін “обов’язок управління проектом” не використовується жодного разу в усьому тексті рішення.

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

Як слід розуміти характер обов’язку підтримки?

Обов’язок підтримки ще не є чітким поняттям

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

Обов’язок підтримки не визнається безмежним

Крім того, вищезгадане рішення, яке визнало порушення обов’язку підтримки вендором, також вказало на дуже важливу точку.

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

Рішення Гаціодзійського відділення Токійського окружного суду від 5 листопада 2003 року (Heisei 15)

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

Сутність обов’язку підтримки слід розглядати разом з обов’язком користувача співпрацювати

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

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

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

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

Підсумки

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