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

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

Чому мета та цілі розробки системи стають причиною конфліктів?

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

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

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

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

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

Підсумовуючи вищезазначене, можна вказати два важливі моменти:

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

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

Конкретні ситуації, коли цілі користувача впливають на проект

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

• Зменшення витрат на зарплату завдяки автоматизації
• Збільшення продажів та прибутку
• Скорочення робочого часу

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

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

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

Справа, в якій було висунуто ціль покращення швидкості роботи

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

• Зменшити час ручного введення на 50%
• Забезпечити завершення обробки документів за допомогою даної ІТ-системи в межах встановленого терміну

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

Таким чином, (пропуск) згідно з загальним змістом дебатів, ① метою цієї справи є “підвищення ефективності роботи”, “створення основи CRM”, “проведення “прозорого управління” та інше, що є абстрактним, а цільові показники, такі як “збільшення контактів з клієнтами”, “розподіл робочої сили адміністративних працівників на внутрішній контроль та підтримку продажів”, “точніше прогнозування продажів”, “обмеження надмірних знижок на продажі”, та інше, є абстрактними, а такі цільові показники, як “зменшення часу введення на 50%”, “зменшення часу створення оцінки на 50%”, “забезпечення законодавчого розкриття інформації в межах законодавчого терміну” та інше, залежать від управління та методів роботи відповідача після впровадження SBO, і це не є речами, які позивач, як компанія з розробки систем, може взяти на себе, ② в протоколах зустрічей після початку цього проекту немає згадок про конкретні обговорення щодо досягнення цієї мети та цільових показників, ③ в плані цього проекту використовуються вирази, такі як “стати публічною компанією”, які не мають характеру контракту, (пропуск) враховуючи ці обставини, позивач створив опис мети цього проекту в плані цього проекту на основі пояснень відповідача, щоб проект не зазнав невдачі, це було зроблено для отримання спільного розуміння мети та результатів цього проекту, і відповідач не може визнати, що він доручив позивачу розробку системи для досягнення цієї мети. (пропуск) Тому, оскільки не можна визнати, що позивач взяв на себе розробку системи для досягнення цієї мети від відповідача, (пропуск) немає підстав для ствердження про відповідальність за невиконання зобов’язань та гарантійну відповідальність.

Рішення Токійського окружного суду від 28 грудня 2010 року (2010 рік за Григоріанським календарем)

Юридичне значення управлінських цілей та кількісних цілей, яке можна зрозуміти з судового рішення

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

• Абстрактні та нечіткі, що не відповідає характеру юридичного обов’язку, тому вважати їх частиною контракту було б нерозумно
• Ті, що вимагають зусиль з боку користувачів, особливо з боку управління, не можуть бути контрольовані вендором, тому вважати їх відповідальністю вендора було б неправильно, і вважати їх частиною контрактних обов’язків було б нерозумно

Таким чином, вони отримали таку юридичну оцінку.

Що ще можна зрозуміти з цього рішення

Це рішення також містить декілька цікавих моментів.

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

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

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

Правові питання, що стосуються управлінських та числових цілей

Проте, щодо правових питань, що стосуються таких “цілей” та “завдань”, слід врахувати наступні додаткові відомості.

Консалтингові послуги можуть бути платними або безкоштовними

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

Дефекти продукту та невідповідність функціональних та технічних вимог – це окремі питання

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

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

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

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

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

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

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

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

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