Иностранный контрагент - залог успеха для любой IT-компании. И не важно будь то лакомый кусок субподряда от «Единорога» или небольшой проект «с нуля» - правильно сформированный контракт значительно облегчает ведение проекта, высвобождает время менеджера на устранение недоразумений и сдерживает контрагентов от недобросовестных действий.
Контракт - это дорожная карта проекта, такой же инструмент, как CRM система или репозиторий.
И как сделать так, чтобы этот инструмент был действенным и безопасным - мы расскажем в этой статье.
Этот материал содержит анализ контракта между юридическим лицом, зарегистрированным по законодательству Украины (ІТ компания, исполнитель) и заказчиком - любой компанией, не зарегистрированной в Украине. Речь идет именно о классическом постороннем контрагенте, которого нашел ваш sales менеджер.
В материале мы делимся собственным опытом сопровождения ІТ контрактов с иностранным элементом и даем советы, на которых в свое время «набили шишки» и иногда продолжаем набивать.
Важным этапом правильного заключения договора ІТ услуг является определение предмета договора (типа услуг)
Как и классическая украинская дилемма «услуги или подряд» внешнеэкономические договоры ИТ-услуг могут быть двух видов: аутстаффинг (Outstaffing Services Agreement) и Договор на разработку «с нуля» (Software development Agreement/Outsourcing Agreement).
Предлагаемые названия условны. Вы можете встретить много разных вариаций, однако, как и с договорами услуг/подряда определяющим остается не название, а содержание. Итак, по каждому из видов:
Основные черты услуг аутстаффинга.
Самый распространенный вид услуг предоставляется украинскими IT-компаниями иностранным контрагентам. К сожалению, нигде нет четкого правового регулирования данного вида услуг. Более того, нет даже каких-либо стандартизированных правил/меморандумов, как у SCRUM.
Поэтому определить, что договор является именно договором аутстаффинга, можно по следующим ГЛАВНЫМ чертам этих услуг.
1. Услуги аутстаффингу - это передача разработчика в подчинение РМ или СТО компании заказчика.
Компания исполнитель обеспечивает физическое пребывание разработчика в своем офисе или в другом месте, связь разработчика с заказчиком и своевременность и полноту выполнения технических задач.
В соответствии с услугами аутстаффинг Исполнитель не несет ответственности за конечный результат предоставления услуг, поскольку Исполнитель не разрабатывает техническое задание.
Разработчики, как правило, создают только часть продукта (определенный модуль, фрагмент кода, функционал, т.е.) по готовой инструкции и не могут отвечать за полноту и точность ТС.
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-5 лет) после его прекращения.
Не конкуренция по своему содержанию сродни не переманиванию, но касается вопроса перехвата клиентов или субподрядчиков.
Вы никогда не сможете точно знать всех клиентов вашего контрагента, равно как и контрагент не может знать всех ваших клиентов. Поэтому советуем ограничивать пункты не конкуренции исключительно по тем клиентам, которые стали известны сторонам в результате предоставления услуг и совместной работы над проектами.
Также напоминаем о важности предусматривать компенсацию ущерба за нарушение условий не конкуренции и максимально усиливать ответственность за нарушение этих условий.
Пункты о не переманивании и ответственности важны с практической точки зрения, поэтому их всегда следует отделять от общей ответственности за нарушение условий Договора.
В контексте общей ответственности следует сосредоточить внимание отдельно на ответственности исполнителя и ответственности заказчика.
Объем ответственности исполнителя зависит от типа предоставляемых услуг.
Так, в случае предоставления услуг по аутстаффингу, Исполнитель не может нести ответственность за результаты выполнения услуг (подчеркиваем, что это следует прямо указать в тексте Договора). Если заказчик видит, что его не устраивает квалификация разработчика, то он всегда имеет право отказаться от договора (об этом поговорим ниже).
В то же время, заказчик может нести ответственность за своевременные расчеты, предоставление лицензий, доступ к ПО или рабочей среде и т.п.
Стороны могут также отдельно указать ответственность за нарушение прав интеллектуальной собственности и конфиденциальности.
Правилом хорошего тона является ограничение ответственности (limitation liability), согласно которому любая сумма штрафов или убытков, возлагаемых на каждую сторону, не может превышать либо общей суммы контракта, либо уже уплаченной суммы по контракту, либо по выбору сторон любой другой предел. Так, каждая сторона будет знать и может предусмотреть последствия нарушения условий договора.
Конфиденциальность и защита интеллектуальной собственности
В большинстве случаев на момент заключения Договора между сторонами уже подписано соглашение о неразглашении конфиденциальной информации (Non disclosure agreement/NDA).
Поэтому вопрос необходимости еще раз выписывать условия обеспечения конфиденциальности возникает лишь тогда, когда NDA не регулирует все отношения между сторонами или заканчивает свое действие вместе с окончанием переговоров. В любом случае следует проанализировать существующие между сторонами обязательства и при необходимости дополнить их в контракте или в отдельном NDA.
Другим существенным аспектом конфиденциальных обязательств является соблюдение специфических законодательных процедур, таких как GDPR или CCPA, или подобные акты в других юрисдикциях.
Если вы ссылаетесь на эти акты в контракте, убедитесь, действительно ли они распространяются на конкретные правоотношения, и действительно ли ссылка на них так необходима, ведь недостаточно указать данные акты в своем договоре, важно также их соблюдать. И если ваши разработчики работают в проекте с персональными данными других лиц, вы должны убедиться, что такие данные получаются вашей компанией легально и находятся под надежной защитой.
Если же вы получаете все данные исключительно от контрагента, не будет лишним в тексте договора переложить всю ответственность за последствия использования этих данных на него, если, конечно, ваши действия были добросовестны.
Защита объектов интеллектуальной собственности (ОИС) рассматриваем по двум аспектам.
Первый - использование лицензий, библиотек, посторонних ОИС, технологий и т.д.
В данном аспекте считаем, что легче всего установить правило, что сторона, которая сдает тот или иной ОИС в проект, отвечает за правомерность его использования в конечном продукте.
Второй - передача права интеллектуальной собственности на программный код.
Код является результатом интеллектуальной деятельности конкретного разработчика. И если у вас нет четкой цепочки перехода производных прав от разработчика к конечному клиенту - рано или поздно это может стать проблемой.
В иностранных контрактах вопросы перехода права интеллектуальной собственности регулируются несколько либеральнее, чем в Украине.
Обычно в контрактах применяется конструкция, согласно которой разработчик передает все права ИС на код компании-работодателю, а та, в свою очередь, передает такие права компании-заказчику.
Однако следует помнить о таком аспекте как момент перехода права интеллектуальной собственности.
Заказчик заинтересован в том, чтобы права ИС на код переходили к нему с момента создания кода и перемещения его в репозиторий, в то время как Исполнитель заинтересован в переходе права ИС на код с момента оплаты услуг (ведь если заказчик не оплатит услуги, можно запретить использовать код, как механизм обеспечения оплаты).
Именно поэтому следует обращать внимание на момент перехода права ИС и обеспечить правовую цепочку перехода прав от разработчика к заказчику.
Момент приема услуг, срок договора и его расторжение
Момент приема услуг, а, следовательно, и возникновение долга по их оплате является самым спорным в отношениях между сторонами. Поэтому важно четко определять границы, с какого момента услуги считаются принятыми, с какого момента наступает обязанность по оплате и с какого момента заказчик не может выдвигать исполнителю претензии по результатам выполнения работ.
Эти моменты могут быть разными, однако их следует предусмотреть в Договоре.
Кроме того, следует не забывать, что такой документ как «Акт приемки-передачи» знают только компании из постсоветских стран.
Для большинства контрагентов этот документ непонятен, поэтому не удивляйтесь, если вдруг вы предусмотрели подписание «Certificate of aceptance», а Ваш контрагент не захочет принимать такое условие.
В таком случае следует привязать момент приема услуг конкретной датой, истечением периода после загрузки кода в репозиторий или моментом оплаты услуг.
Дополнительно рекомендуем обращать внимание на наличие в контракте обязанности дальнейшей поддержки проекта (bug fix, обновление версий и т.п.) и условий такой поддержки.
Иногда эти условия изложены в разделе/приложении или отдельном договоре под названием SLA (Service Level Agreement). Однако на практике SLA значительно масштабнее по своему содержанию и к содержанию подобной конструкции следует подходить более ответственно, чтобы не обрадовать менеджеров внезапными не согласованными требованиями к качеству продукта и организации процессов.
Что касается срока действия Договора, здесь распространены два подхода договора на неопределенный срок или договор на короткий период (до года) с автопролонгацией, если ни одна из сторон не заявила о его прекращении за определенный срок до даты окончания.
В любом случае ІТ услуги вещь быстротечна и в самый разгар проекта стороны могут принять решение о досрочном прекращении договора. И это вопрос, который ни в коем случае нельзя пускать в одиночку.
Чтобы иметь стабильную и предполагаемую загрузку разработчиков, следует четко прописывать порядок досрочного расторжения - Termination notice.
Так, важно отметить за какой срок каждая сторона должна сообщить о прекращении договора, с какого момента получающая сторона считается уведомленной и согласившейся со сроком расторжения, в каких случаях возможно мгновенное расторжение договора, какие последствия досрочного расторжения.
В целом же не лишним будет и урегулирование последствий прекращения Договора в целом. Такие последствия включают обязанность передать или уничтожить конфиденциальную информацию, вернуть программное обеспечение или оборудование, аннулировать доступы, порядок окончательных расчетов.
Учитывая специфику услуг, большинство из вышеперечисленных пунктов Договора следует отнести к категории бессрочных, то есть таких, действие которых не прекращается с истечением срока действия Договора (конструкция Survival).
Конечно, это далеко не все вопросы, которые важно урегулировать в договоре о предоставлении ИТ-услуг с иностранным контрагентом. Есть еще вопросы юрисдикции, порядка разрешения споров, языка контракта, порядка коммуникации между сторонами, реквизитами сторон и т.п.
Однако эти вопросы типичны для всех ВЭД контрактов и не имеют какой-либо специфики, которая бы отличала их от других контрактов.
Для того чтобы договор ІТ услуг был действительно безопасен для компании, юристу необходимо понимать специфику услуг, работу менеджеров и принимать во внимание описанные вопросы.
Как энергетическому бизнесу управлять рисками? Попробуйте корпоративное решение LIGA360. Законодательство и мониторинг изменений энергорынка, проверка контрагентов из Украины и Великобритании, ответы экспертов по лицензиям, проверкам, пошлинам и налогам. Только в августе подключите 5 специалистов за 5000 грн/мес
