IT-послуги з іноземним замовником: як правильно скласти договір?

IT-послуги з іноземним замовником: як правильно скласти договір?

Іноземний контрагент – запорука успіху для будь-якої IT – компанії. І не важливо чи то ласий шматок субпідряду або невеличкий проект «з нуля» – правильно сформований контракт значно полегшує ведення проекту, вивільняє час менеджера на усунення непорозумінь та стримує контрагентів від недобросовісних дій.

Контракт- це дорожня карта проекту, такий же інструмент, як CRM система або репозиторій.

І як зробити так, щоб цей інструмент був дієвим і безпечним- ми розкажемо в цій статті.

Цей матеріал містить аналіз контракту між юридичною особою зареєстрованою за законодавством України (ІТ компанія, виконавець) та замовником – будь-якою компанією, що не зареєстрована в Україні. Мова йде саме про класичного стороннього контрагента, якого вполював ваш sales менеджер.

В матеріалі ми ділимось власним досвідом супроводу ІТ контрактів з іноземним елементом та даємо поради, на яких в свій час «набили шишаки» та іноді продовжуємо набивати.

Важливим етапом правильного складання договору ІТ послуг є визначення предмету договору (типу послуг)

Як і класична українська дилема «послуги чи підряд» зовнішньоекономічні договори ІТ послуг можуть бути двох видів: аутстаффінг (Outstaffing Services Agreement) та Договір на розробку «з нуля» (Software development Agreement/ Outsourcing Agreement).

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

Основні риси послуг аутстаффінгу.

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

Тому, визначити, що договір є саме договором аутстаффінгу, можна за наступними ГОЛОВНИМИ рисами цих послуг.

1. Послуги аутстаффінгуу – це передача розробника у підпорядкування РМ чи СТО компанії замовника.

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

2. Відповідно до послуг аутстаффінга Виконавець НЕ несе відповідальності за кінцевий результат надання послуг, оскільки Виконавець НЕ розробляє технічне завдання.

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

3. Під час послуг аутстаффінгу «bug fix» є платним, а послуга тарифікується на погодинній основі.

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

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

Договір на розробку програмного забезпечення «з нуля» більше нагадує наш типовий договір підряду.

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

В даному випадку «bug fix» виконується безкоштовно (якщо він звісно не був передбачений під час розрахунку вартості послуг і не здійснюється до прийомки ПЗ замовником).

Для чого важливо розрізняти предмет договору за його змістом?

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

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

Важливо пам’ятати, що від типу послуг залежить обсяг відповідальності і момент оплати.

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

Про такі елементи ми й розкажемо нижче.

Вартість послуг і порядок розрахунків

В даному розділі радимо прописувати загальні технічні умови оплати, що не будуть змінюватись: спосіб оплати (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).

Звичайно, це далеко не всі питання, які важливо врегулювати у договорі про надання ІТ-послуг з іноземним контрагентом. Є ще питання юрисдикції, порядку вирішення спорів, мови контракту, порядку комунікації між сторонами, реквізитами сторін і т.п.

Однак ці питання є типовими для всіх ЗЕД контрактів і не мають якоїсь специфіки, яка б відрізняла їх від інших контрактів.

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

Поширити допис в:

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

    Хочете замовити консультацію?

    Ми готові допомогти вам вирішити найскладніші правові питання. Залиште заявку на консультацію, і наші юристи оперативно зв'яжуться з вами, щоб обговорити ваші потреби та запропонувати найкращі варіанти вирішення.

    Контакти

    Ми завжди на зв'язку та готові допомогти вам з будь-якими правовими питаннями. Зв'яжіться з нами зручним для вас способом:

    Адреса:

    м. Київ, вул. Симферопольская, 13

    Телефон:

    +380 (50) 587-49-30

    Електронна пошта:

    schipika.andrej@gmail.com

    Графік роботи:

    Пн-Пт: 09:00 – 18:00

    Також ви можете заповнити форму вище, і наші спеціалісти зв'яжуться з вами якомога швидше.

    Завітайте до нашого офісу або напишіть нам — ми раді допомогти вам у вирішенні будь-яких правових питань.

    >