 |
Данищук Михайло
юрист best-run Consulting |
“Впровадження ERP-системи — це не просто ІТ-проєкт. Це трансформація бізнесу: змінюються процеси, ролі, звичні способи роботи. І якщо щось пішло не так — затягнулись терміни, виросла вартість, система не робить те, чого очікували — перше питання, яке ставить керівник: «А що написано в договорі?»
Відповідь на це питання або рятує ситуацію, або ускладнює її ще більше.
У цій статті я розбираю ключові блоки, які має містити договір про впровадження ERP, і пояснюю, чому кожен із них важливий як для виконавця так і для замовника”.
Чому договір ERP — це не стандартний договір послуг
Класичний договір про надання послуг (юридичних, бухгалтерських, дизайнерських) описує, що виконавець робить і скільки це коштує. З ERP так не працює.
По-перше, на початку проєкту ніхто — ні виконавець, ні замовник — не знає точного обсягу робіт. Бізнес-процеси виявляються складнішими, ніж здавалось. По-друге, результат залежить від обох сторін: якщо замовник вчасно не надав доступи, не призначив відповідальних, не погодив документацію — проєкт зупиняється. По-третє, тут завжди є «сіра зона» між тим, що домовились зробити, і тим, що реально потрібно бізнесу.
Тому хороший договір ERP — це не просто юридичний документ, а узгоджена карта очікувань обох сторін.
Предмет договору і додатки
Найпоширеніша помилка — прописати предмет розмито: «надання консультаційних послуг із впровадження програмного забезпечення». Це нічого не говорить ні про обсяг, ні про результат.
Предмет договору має містити посилання на конкретні додатки, де все деталізовано. Зокрема:
Додаток з переліком послуг і етапів — перелічує всі роботи, які виконавець зобов’язується зробити, з прив’язкою до термінів і трудомісткості (у людино-годинах). Якщо це не зафіксовано — будь-яка претензія «ви не зробили X» буде наштовхуватись на відповідь «X не входило в наш план».
Прейскурант ставок — визначає вартість однієї людино-години роботи консультанта. Це основа для розрахунку вартості будь-яких додаткових робіт, які виникнуть у ході проєкту (а вони обов’язково виникнуть).
Процедура додаткових робіт — описує, як діяти, коли в процесі реалізації виявляється щось нове: новий бізнес-процес, розширення вже узгодженого функціоналу або покращення. Без цього блоку «хотілки» замовника перетворюються на конфлікт.
Порядок надання послуг і роль замовника
Замовники нерідко сприймають своє завдання як «підписати договір і чекати результату». Насправді в ERP-проєкті замовник — активний учасник, і договір має це фіксувати.
Що повинен закріпити цей блок:
Керівник проєкту з боку замовника. Протягом перших днів після підписання договору замовник призначає відповідальну особу — менеджера проєкту. Ця людина координує взаємодію, погоджує документи, приймає рішення. Без неї проєкт зупиняється — і виконавець матиме підставу перенести терміни.
Обов’язок надавати доступи та інформацію. Виконавець не може налаштовувати систему «наосліп». Йому потрібні доступи до ІТ-інфраструктури, документація по бізнес-процесах, актуальні дані. Договір має чітко прописати, що замовник зобов’язаний надавати все це в узгоджені терміни, і — важливо — несе відповідальність за точність і достовірність наданої інформації.
Що відбувається, якщо замовник затримує доступи. Виконавець має право перенести терміни на рівний строк затримки. Це логічно, але замовнику варто знати про це заздалегідь — щоб не дивуватись, чому дедлайн «поїхав», хоча виконавець «нічого не робив».
Додаткові роботи — найчастіше джерело конфліктів
Будь-який ERP-проєкт виходить за початковий обсяг. Питання тільки в тому, як це оформлюється.
Хороший договір передбачає чітку процедуру:
Виявлено щось нове → зафіксовано в спільному проєктному документі → обговорено на відеозустрічі → погоджено статус (виконувати / відкласти / відхилити) → якщо виконувати — оцінено трудомісткість → виставлено рахунок → після оплати розпочато роботу.
Кожному додатковому запиту присвоюється статус за критичністю:
Критичний — без цього продуктивний старт неможливий. Якщо замовник відхиляє — строки зсуваються автоматично.
Некритичний — без цього можна запуститись, але якість роботи постраждає. Реалізується після основного проєкту.
Покращення процесу — не впливає на запуск, робиться коли зручно.
Чому це важливо? Без такої процедури замовник може несподівано отримати рахунок на «додаткові роботи», які він вважав частиною основного договору. А виконавець — застрягти в безкінечних безоплатних доопрацюваннях. Чітка процедура захищає обох.
Інтелектуальна власність
Для IT-проєктів це критично важливий розділ, про який часто забувають при підписанні.
Базовий принцип у добре складеному договорі такий: результати виконаних і оплачених послуг належать замовнику. Тобто налаштована функціональність, виправлені помилки, розроблена документація — ваше.
Але методи і підходи залишаються у виконавця. Технологія налаштування, методологія впровадження, шаблони та моделі, які використовувались для досягнення результату — це інтелектуальна власність виконавця, і він має право застосовувати їх в інших проєктах.
Що перевіряти перед підписанням:
Якщо узагальнити, ось мінімальний чеклист для замовника ERP, про який варто подумати в договорі:
Предмет і додатки. Чи деталізовано перелік робіт і терміни? Чи зрозуміло, що входить у фіксовану вартість, а що — ні?
Ваші обов’язки. Чи розумієте ви, що від вас вимагається і які наслідки вашого бездіяльства?
Процедура змін. Як оформлюються додаткові роботи? Хто і коли їх погоджує?
Прийняття послуг. Які строки розгляду актів? Що відбувається, якщо ви не реагуєте?
Оплата. Яка схема передоплати? Чи є валютна індексація і як вона рахується?
ІВ. Що залишається у вас, а що — у виконавця?
Конфіденційність і строк після завершення договору. Як захищені ваші бізнес-дані?
Штрафи та заборони. Чи є умови, про які варто знати заздалегідь?
“Договір про впровадження ERP не захищає від всіх проблем. Але він значно скорочує кількість непорозумінь — і дає сторонам спільну мову для їх вирішення.
Підписуючи договір, замовник часто думає про бюджет і терміни. Насправді варто думати про контроль: хто відповідає за кожен етап, як фіксуються зміни, що відбувається, якщо щось пішло не так. Якщо договір відповідає на ці питання — він зроблений правильно”.
