Іноземний контрагент - запорука успіху для будь-якої IT - компанії. І не важливо чи то ласий шматок субпідряду від «Єдинорога» або невеличкий проект «з нуля» - правильно сформований контракт значно полегшує ведення проекту, вивільняє час менеджера на усунення непорозумінь та стримує контрагентів від недобросовісних дій.
Контракт- це дорожня карта проекту, такий же інструмент, як CRM система або репозиторій.
І як зробити так, щоб цей інструмент був дієвим і безпечним- ми розкажемо в цій статті.
Цей матеріал містить аналіз контракту між юридичною особою зареєстрованою за законодавством України (ІТ компанія, виконавець) та замовником - будь-якою компанією, що не зареєстрована в Україні. Мова йде саме про класичного стороннього контрагента, якого вполював ваш sales менеджер.
В матеріалі ми ділимось власним досвідом супроводу ІТ контрактів з іноземним елементом та даємо поради, на яких в свій час «набили шишаки» та іноді продовжуємо набивати.
Важливим етапом правильного складання договру ІТ послуг є визначення предмету договору (типу послуг)
Як і класична українська дилема «послуги чи підряд» зовнішньоекономічні договри ІТ послуг можуть бути двох видів: аутстаффінг (Outstaffing Services Agreement) та Договір на розробку «з нуля» (Software development Agreement/ Outsourcing Agreement).
Запропоновані назви є умовними. Ви можете зустріти багато різних варіацій, однак як і з договорами послуг/підряду визначальним залишається не назва, а зміст. Отже по кожному з видів:
Основні риси послуг аутстаффінгу.
Найпоширеніший вид послуг, що надається українськими IT-компаніями іноземним контрагентам. Нажаль, ніде немає чіткого правового регулювання цього виду послуг. Більш того, немає навіть якихось стандартизованих правил/меморандумів, як у SCRUM.
Тому, визначити, що договір є саме договором аутстаффінгу, можна за настпуними ГОЛОВНИМИ рисами цих послуг.
1. Послуги аутстаффінгуу - це передача розробника у підпорядкування РМ чи СТО компанії замовника.
Компанія виконавець забезпечує фізичне перебування розробника в своєму офісі, або в іншому місці, зв`язок розробника із замовником та вчасність і повноту виконання технічних завдань.
2. Відповідно до послуг аутстаффінга Виконавець НЕ несе відповідальності за кінцевий результат надання послуг, оскільки Виконавець НЕ розробляє технічне завдання.
Розробники, як правило, створюють лише частину продукту (певний модуль, фрагмент коду, функціонал, тошо) по готовій інструкції і не можуть відповідати за повноту та точність ТЗ.
3. Під час послуг аутстаффінгу «bug fix» є платним, а послуга тарифікується на погодинній основі.
Як правило замовник фактично купує певну кількість робочих годин розробника і ставить йому завдання на власний розсуд.
Отже, по своїй суті аутстаффінг є типовим Договором послуг, в якому визначальним є сам процесс розробки, а не його кінцевий результат.
Договір на розробку програмного забезпечення «з нуля» більше нагадує наш типовий договір підряду.
В цьому випадку Виконавець відповідає за кінцевий результат, коректність технічного завдання та отримує оплату в залежності від кінцевого результату розробки.
В данному випадку «bug fix» виконується безкоштовно (якщо він звісно не був передбачений під час розрахунку вартості послуг і не здійснюється до прийомки ПЗ замовником).
Для чого важливо розрізняти предмет договору за його змістом?
Конкретний вид послуг визначається менеджером, а не юристом. Саме менеджери погоджують тип послуг і повідомляють про нього юриста. Завдання ж юриста - прослідкувати, щоб зміст Договору відповідав описаним вище ознакам.
Радимо чітко окреслювати в конктракті предмет послуг та уникати комбінованого типу, коли ознаки аутстаффінгуу та аутсорсу переплітаються.
Важливо пам'ятати, що від типу послуг залежить обсяг відповідальності і момент оплати.
Крім предмету, в контракті важливо передбачити обов'язкові елементи, які забезпечать безпечний проект та попередять непорозуміння між Сторонами.
Про такі елементи ми й розкажемо нижче.
Підготувати шаблон договору - просто як ніколи. CONTRACTUM у LIGA360 надає гнучкі можливості редагування, а також готові шаблони договорів англійською та українською мовами. Створюйте власні договори “з нуля” або використовуйте шаблони LIGA ZAKON за основу. Деталі за посиланням.
Варітсть послуг і порядок розрахунків
В данному розділі радимо прописувати загальні технічні умови оплати, що не будуть змінюватись: спосіб оплати (SWIFT, SEPA), порядок виставлення інвойсу, порядок оподаткування (яка сторона в якій країні які податки сплачує), порядок оплати банківських комісій, порядок погодження та оплати «овертайму», що входить у вартість послуг/робіт, а що сплачується окремо, порядлок компенсації чи оплати ліцензій, спеціального обладнання тощо.
Також важливо вказати застереження, що кожна сторона сама відповідає за оплату обов'язкових соціальних внесків за своїх працівників (особливо в умовах аустафінгу це важливо для уникнення визнання трудових відносин між розробником і замовником в інших країнах).
Що ж до вартості послуг (погодинної ставки чи фіксованої вартості), та специфічних умов оплати, погоджених Сторонами окремо, радимо зазначати їх в окремому Додатку до договору (Annex чи Schedule), редакція якого може змінюватись з часом.
Іноді в контрактах можно зустріти таку умову оплати як Time&Material (T&M). Жодного законодавчого або бодай неофіційного формального змісту цих вимог не існує, і менеджери, домовляючись про умови оплати виходять з загальноприйнятої практики.
Однак, як показує практика, розуміння змісту умов T&M може відрізнятись, тому застосвуючи такі умови оплати, варто зафіксувати в договорі їх розшифрування та пересвідчитись, що всі учасники проекту розуміють ці умови однаково.
Якщо коротко, то за своєю сутністтю T&M близькі за змістом до умов аутстаффінгу (якщо не відображають їх повністтю), але, Сторони завжди можуть надати власну інтерпретацію.
Отже, будь-які «стандартизовані» для менеджера умови, юристу краще уточнити і формалізувати в тексті Договору.
Непереманювання», «не конкуренція» та відповідальність Сторін
Критично важливі пункти, до яких варто віднестись з відповідальністтю та уважністтю.
Нажаль, серед IT- компаній розповсюджена пратика, коли замовники переманюють цінного розробника, або виконавець краде основного клієнта, отримуючи весь проект під свій контроль.
Якщо контракт містить незначну відповідальність за такі дії - недобросовісному контрагенту вигідно сплатити штраф, тим самим «відкупившись» від відповідальності, адже в кінцевому результаті такий контрагент може заробити значно більше.
Саме тому, важливо правильно формулювати ці пункти Договору.
Почнемо з непереманювання (non-solicitation чи non-engagement). В цьому пункті вкрай важливо звернути увагу на деталі:
1. Розмір відповідальності - він має бути таким, щоб контрагенту було не вигідно просто сплатити штраф та викупити розробника. Як правило, краще прописувати великий розмір штрафу та обов'язок компенсувати збитки.
2. Коло осіб та дії, що підпадають під обов'язок непереманювання.
Варто окреслити які конкретно дії вважатимуться переменюванням, на яке коло осіб поширюються обов'язки з непереманювання та перехід розробника до яких осіб вважатиметься переманюванням (окрім безпосередньго замовника, він може мати афілійованих осіб, які можуть виконувати ті ж послуги, що й ви).
Безперечно, не можливо заздалегідь передбачити всі випадки, які можуть підпадати під переманювання, саме тому, важливе зобов'язовувати не переманювати працівників не лише контрагента, а й визначати додатково відповідальність працівника за перехід до клієнта без згоди компанії.
Важливо також пам'ятати, що тотальне обмеження в непереманюванні може зіграти злий жарт з вашою компанією, адже, якщо цінний спеціаліст клієнта чи колишнього клієнта навіть сам захоче перейти в вашу команду, такий перехід може вважатись переманюванням.
3. В контексті вищезазначеного важливим також є строк дії непереманювання. Не варто зазначати безстроковість таких зобов'язань або поширення їх дії на весь строк контракту та значний період часу (3-5 років) після його припинення.
Неконкуренція за своїм змістом схожа на непереманювання, але стосується питання перехоплення клієнтів чи субпідрядників.
Ви ніколи не зможете достеменно знати всіх клієнтів вашого контрагента, так само як і контрагент не може знати всіх ваших клієнтів. Тому радимо обмежувати пункти некнкуренції виключно щодо тих клієнтів, які стали відомі сторонам в результаті надання послуг та спільної роботи над проектами.
Також нагадуємо про важливість передбачати компенсацію збитків за порушення умов неконкуренції та максимально посилювати відповідальність за порушення цих умов.
Пункти про непереманювання та відповідальність важливі з практичної точки зору, тому їх завжди варто відокремлювати від загальної відповідальності за порушення умов Договору.
В контексті загальної відповідальності варто зосередити увагу окремо на відповідальності виконавця і на відповідальності замовника.
Обсяг відповідальності виконавця залежить від типу послуг що надаються.
Так, у випадку надання послуг з аутстаффінгуу, Виконавець не може нести відповідальність за результати виконання послуг (наголошуємо, що це варто прямо зазначити в тексті Договору). Якщо замовник бачить, що його не влаштовує кваліфікація розробника, він завжди має право відмовитись від договору (про це поговоримо нижче).
В той же час, замовник може нести відповідальність за своєчасні розрахунки, надання ліцензій, доступу до ТЗ або робочого середовища тощо.
Сторони можуть також окремо вказати відповідальність за порушення прав інтелектуальної власності та конфіденційності.
Правилом гарного тону є передбачення обмеження відповідальності (limitation liability), відповідно до якого будь-яка сума штрафів чи збитків, що покладаються на кожну сторону не можуть перевищувати або загальної суми контракту, або вже сплаченої суми за контрактом, чи на вибір сторін будь-який інший ліміт. Так кожна сторона знатиме та може передбачити наслідки порушення умов договору.
Конфіденційність та захист інтелектуальної власності
У більшості випадків на момент укладення Договору між сторонами вже підписана угода про нерозголошення конфіденційної інформації (Non disclosure agreement/ NDA).
Тому питання необхідності ще раз порписувати умови забезпечення конфіденційності постає лише тоді, коли NDA не регулює всіх відносин між сторонами, або закінчує свою дію разом із закінченням переговорів. В будь-якому випадку, варто проаналізувати існуючі між сторонами зобов'язання та за необхідності доповнити їх в контракті чи в окремому NDA.
Іншим суттєвим аспектом конфіденційних зобов'язань є дотримання специфічних законодавчих процедур, таких як GDPR або CCPA або подібні акти в інших юрисдикціях.
Якщо ви посилаєтесь на ці акти в контракті, пересвідчіться чи дійсно вони поширюються на конкретні правовідносини, та чи дійсно посилання на них так необхідне, адже замало вказати данні акти в своємо договорі, важливо також їх дотримуватись. І якщо ваші розробники працюють в проекті з персональнимим даними інших осіб, ви маєте пересвідчитись, що такі данні отримуються вашою компанією легально та вони перебувають під надійним захистом.
Якщо ж ви отримуєте всі данні виключно від контрагента, не буде зайвим в тексті договору перекласти всю відповідальність за наслідки використання цих данних на нього, якщо звісно ваші дії були добросовісні.
Захист об'єктів інтелектуальної власності (ОІВ) розгляднемо з двох аспектів.
Перший - використання ліцензій, бібліотек, сторонніх ОІВ, технологій тощо.
В данному аспекті вважаємо, що найлегше встановити правило, що та сторона, яка здодає той чи інший ОІВ в проект, відповідає за правомірність його використання в кінцевому продукті.
Другий - передача права інтелектуальної власності на програмний код.
Код є результатом інтелектуальної діяльності конкретного розробника. І якщо у вас немає чіткого ланцюжка переходу похідних прав від розробника до кінцевого клієнта - рано чи пізно це може стати проблемою.
В іноземних контрактах питання переходу права інтелектуальної власності регулюються дещо ліберальніше ніж в Україні.
Зазвичай в контрактах застосовується конструкція, відповідно до якої розробник передає всі права ІВ на код компанії-роботодавцю, а та, в свою чергу передає такі права копанії-замовнику.
Однак варто пам'ятати про такий аспект як момент переходу права інтелектуальної власності.
Замовник зацікавлений в тому, щоби права ІВ на код переходили до нього з моменту створення коду та переміщенгня його в репозиторій, в той час як Виконавець зацікавлений у переході права ІВ на код з моменту оплати послуг (адже якщо замовник не оплатить послуги, можна заборонити використовувати код, як механізм забезпечення оплати).
Саме тому варто звертати увагу на момент переходу права ІВ та забезпечити правовий ланцюжок переходу прав від розробника до замовника.
Момент приймання послуг, строк договору та його розірвання
Момент приймання послуг, а отже й виникнення обов'язку по їх оплаті є чи не найспірнішим у відносинах між сторонами. Тому важливо чітко окреслювати межі, з якого моменту послуги вважаються прийнятими, з якого моменту настає обов'язок по оплаті та з якого момента замовник не може висувати виконавцю претензії щодо результатів виконаня робіт.
Ці моменти можуть бути різними, однак їх варто передбачити в Договорі.
Крім того, варто не забувати, що такий документ як «Акт приймання-передачі» знають лише компанії з пострадянських країн.
Для більшості контрагентів цей документ є не зрозумілим, тому не дивуйтесь, якщо раптом ви передбачили підписання «Certificate of acceptance», а Ваш контрагент не захоче приймати таку умову.
В такому випадку слід прив'язати момент приймання послуг конкретною датою, спливом періоду після завантаження коду в репозиторій або моментом оплати послуг.
Додатково радимо звертати увагу на наявність в контракті обов'язку подальшої підтримки проекту (bug fix, оновлення версій і т.п.) та умов такої підтримки.
Іноді ці умови викладені в розділі/ додатку чи окремому договорі під назвою «SLA» (Service Level Agreement). Однак на практиці SLA значно масштабніший за своїм змістом і до змісту подібної конструкції варто підходити більш відповідально, щоб не порадувати менеджерів раптовими не погодженимим вимогами до якості продукту та організації процесів.
Що ж до строку дії Договору, тут поширені два підходи договір на невизначений строк, або договір на короткий період (до року) з автопролонгацією, якщо жодна зі сторін не заявила про його припинення за певний строк до дати закінчення.
В будь-якому випадку ІТ послуги річ швидкоплинна і в самий розпал проекту сторони можуть прийняти рішення про дострокове припинення договору. І це питання, яке в жодному разі не можна пускати на самотік.
Щоб мати стабільне та передбачуване завантаження розробників, варто чітко прописувати порядок дострокового розірвання - Termination notice.
Так, важливо зазначити за який строк кожна сторона має повідомити про припинення договору, з якого моменту отримуюча сторона вважається повідомленою та такою, що погодилась зі строком розірвання, в яких випадках можливе миттєве розірвання договору, які наслідки дострокового розірвання.
В цілому ж не зайвим буде і врегулювання наслідки припинення Договору в цілому. Такі наслідки включають в себе обов'язок передати чи знищити конфіденційну інформацію, повернути програмне забезпечення чи обладнання, анулювати доступи, порядок остаточних розрахунків.
Враховуючи специфіку послуг більшість із перелічених вище пунктів Догвоору варто віднести до категорії безстрокових, тобто таких, дія яких не припиняється із закінченням строку дії Договору (конструкція Survival).
Звичайно, це далеко не всі питання, які важливо врегулювати у догвоорі про надання ІТ-послуг з іноземним контрагентом. Є ще питання юрисдикції, порядку вирішення спорів, мови контракту, порядку комунікації між сторонами, реквізитами сторін і т.п.
Однак ці питання є типовими для всіх ЗЕД контрактів і не мають якоїсь специфіки, яка б відрізняла їх від інших контрактів.
Для того, щоб договір ІТ послуг був дійсно безпечним для компанії, юристу необхідно розуміти специфіку послуг, роботу менеджерів та приймати до уваги описані питання.
Як енергетичному бізнесу управляти ризиками? Спробуйте корпоративне рішення LIGA360. Законодавство й моніторинг змін енергоринку, перевірка контрагентів з України та Великобританії, відповіді експертів щодо ліцензій, перевірок, мита і податків. Тільки в серпні підключіть 5 фахівців за 5000 грн/міс.
