Контракты в IT-аутсорсинге. Что учитывать обязательно?

В качестве примера приведем события, которые произошли с BP в 80-х годах прошлого века, когда они решили передать на аутсорсинг  функции управления своей информационной системой, но несерьезно подошли к составлению контракта. В итоге «попали» на 500 000$, которые затребовал поставщик услуги, а это, на минуточку, на 50% больше, чем предварительно планировалось. А все по причине того, что менеджеры, которые подписали контракт со стороны заказчика, сделали ряд серьезных ошибок, из которых основная была — неправильный выбор модели ценообразования.

В их случае идеально подходила модель фиксированной стоимости (Fixed Price), а по факту получилась Time & Material, и, как следствие, была оставлена «дыра» при составлении договора в виде неправильно раcписанных оплат и их структуры. В результате чего исполнитель на вполне законных основаниях выставил счет за дополнительные услуги, не прописанные в контракте.

Думаете, это частный случай? На самом деле нет. Многие компании совершили ту же ошибку, что и нефтяная компания, упомянутая в истории. При заключении договора они расплывчато доносят свои требования до исполнителя и мало обращают внимания на то, что и как прописано в контракте.

Но давайте расставим все по своим местам и начнем с самого начала. Когда речь заходит о контрактах на аутсорсинг, особенно если это контракты на IТ-аутсорсинг, обойти вниманием основные компоненты такого документа попросту преступно. Так как это не только упростит работу вашей компании, но и существенно снизит риски получить «подарок» от недобросовестных исполнителей. 

От вас зависит, подписывать контракт или нет. Всем известно, что при принятии решения необходимо внимательно ознакомиться с тем, что прописано к контракте. Давайте вместе рассмотрим, какие же обязательные блоки (компоненты) должны быть в контракте на аутсорсинг. И почему их отсутствие должно вас не просто насторожить, но и заставить пересмотреть условия, вплоть до расторжения предварительных договоренностей.

Мы долго можем изощряться в искусстве изящной красивой словесности, но давайте будем честны друг перед другом: подписанный контракт — это зона ответственности продавцов в первую очередь. Не стоит ее перекладывать на юристов, у них задача максимально обезопасить, прежде всего себя, от всевозможных косяков (уверены, у вас не так, но неплохо об этом помнить). Отдавая контракт «на откуп» юристам, вы рискуете потратить время и получить пугающие заказчика комментарии к этому контракту. Не хочется такого сценария? Давайте разбираться, как минимизировать риски.

Сначала определяем модель ценообразования.

В зависимости от типов и видов взаимодействия между заказчиком и исполнителем выработано 3 основных подхода.

1. Fixed Price
2. Time & Material
3. Dedicated Team

Почему это так важно? Неверно выбранная модель приводит к неправильно выбранной стратегии оформления контракта, и, как следствие, — финансовые и репутационные потери, разрыв соглашений, судебные издержки… Чтобы этого избежать, необходимо четко понимать отличия и практику применения этих моделей.

Fixed Price

Это одна из наиболее понятных и часто используемых моделей, в том числе и на отечественном рынке. Она подойдем тем предприятиям, где есть возможность четко определить и описать требования, спецификации и графики разработки проекта.

После запроса вам необходимо будет проанализировать объем и сложность проекта и предоставить заказчику модель реализации проекта с фиксированным бюджетом на весь объем необходимых для выполнения проекта услуг.

Если вы можете описать функциональность вашего продукты и четко обозначить все этапы его создания, если проект краткосрочный и вы уверены, что после сдачи его заказчику вам не придется вносить существенные доработки, то данная модель то, что вам нужно.

Вот «киты», на которых стоит данная модель:

• фиксированный бюджет,
• постоянный объем проекта,
• установленный временной интервал,
• возможный компромисс по качеству.

Вам пригодится последовательность основных этапов работы:

• получение от заказчика запроса и предоставления условий к проекту;
• обсуждение и согласование всех деталей проекта;
• отправление коммерческого предложения с детализацией сметы, графика исполнения, сроков реализации;
• подписание контракта, в котором отражены все необходимые пункты, дабы не было разногласий в процессе выполнения работ;
• передача реализованного решения;
• одобрение клиентом.

Как и у любой модели, у Fixed Price есть как свои плюсы, так и минусы.

К плюсам можно отнести:

• понятные требования и четко оговоренные этапы реализации;
• фиксированная стоимость, что позволяет заказчику четко планировать расходы, а исполнитель будет иметь такое же четкое представление о доходах;
• относительно невысокий риск неисполнения проекта для заказчика, так как вся ответственность лежит на исполнителе, что очень сильно его мотивирует.

Минусы тоже есть:

• сложность разработки детализированного плана работ и платежей;
• сложность и высокая стоимость, внесение изменений в процессе реализации;
• риск низкого качества окончательного продукта, так как вся реализация лежит на исполнителе, который не всегда может глубоко погрузиться в бизнес-процессы заказчика;
• риск потери прибыли разработчиком в случае неучтенных дополнительных работ в контракте.

Эту модель ценообразования идеально использовать, когда проекты небольшие и предсказуемые, до 2 месяцев, которые впоследствии не будут развиваться: написание ТЗ, верстка страницы, создание понятного небольшого микросервиса и т.п.

Совет: если вы молодая команда без опыта оказания аутсорсинговых услуг в такой системе ценообразования, вам следует крайне осторожно подходить к оценке проекта, так как все неучтенные расходы лягут на ваши плечи — и карета легко превратится в тыкву.

Time and Material

Если проект связан с новыми технологиями, развивающимися рынками или когда клиент хочет иметь возможность вносить доработки и изменения в процессе, а также иметь более серьезный контроль над исполнителем, когда отсутствует возможность детализированной проработки этапов проекта по причине неясности объема работ, их стоимости, либо невозможно разбить процесс реализации на подпроцессы, тогда рекомендуется обратиться к следующей модели — Time and Material.

 Одним из самых больших преимуществ способа сотрудничества является приоритизация задач для проектов развития.

В данной модели этапы реализации не так четко сегментированы:

• запрос от клиента;
• разработка и разбивка проекта на отдельные задачи, включая варианты использования, тесты, функционал и прочие;
• определение стоимости условного часа работы исполнителем;
• определение приоритетности задач для реализации решения, а также вариантов их использования;
• принятие клиентом этих вариантов.

 Плюсы этой модели:

• оплата не зависит от продолжительности проекта;
• внесение любых изменений в процессе проекта не отражается на стоимости нормо-часа;
• высокая вероятность получения высококачественного продукта на выходе.

К минусам можно отнести:

• нет 100%-ной гарантии завершения проекта;
• риск недополучения прибыли исполнителем из-за установления низкой ставки за нормо-час;
• риск «накручивания» исполнителем количества нормо-часов сверх необходимого.

Хотя эти минусы можно предусмотреть в детально разработанном контракте, а также использовать специальное ПО для контроля: от электронных таблиц до специализированных веб-приложений, которые предоставляют все необходимые данные, осуществляют отслеживание времени и связь для успешного решения по управлению проектами и отчетности. Все это поможет свести эти риски к минимуму.

Dedicated Team

Это такая бизнес-модель, когда обе стороны взаимно соглашаются с рабочей нагрузкой и требованиям к проекту с указанием необходимого количества времени, а аутсорсинговая компания предоставляет IT-специалистов, отвечающих требованиям заказчика, которые не только полностью концентрируются на его проектах, но и становятся полноправными членами команды заказчика. Заказчик имеет полный управленческий контроль над проектом и командой, а исполнитель выполняет функцию рекрутера персонала и административной поддержки.

При такой модели сотрудничества заказчик имеет возможность полностью изменить направление предварительно оговоренной деятельности, не разрывая договорных отношений с аутсорсинговой компанией. Такой вариант сотрудничества будет актуален, если у заказчика очень сложный продукт разработки, с серьезными перспективами роста и при этом его интересует возможность личного контроля команды, которая будет работать только над его продуктом.

Этапы работы будут отличаться от предыдущих моделей:

• определение клиентом навыков и набором компетенций будущей команды;
• исполнитель подбирает необходимых специалистов;
• начало работы согласованными разработчиками над задачами заказчика.

Следует отметить, что роль аутсорсера услуг сводится к минимуму после формирования команды.

Плюсы:

• контроль над бюджетом;
• лояльные внешние специалисты с глубоким погружением в проектные процессы заказчика;
• возможность менять направления деятельности и ее объем.

Минусы:

• относительно невысокая стоимость по сравнению с другими моделями;
• время на подбор команды и сложность этого намного серьезнее, чем в других вариантах;
• полная вовлеченность заказчика в процесс разработки;
• полная вовлеченность заказчика в процесс рекрутинга персонала;
• Cross-sell и Up-sell — неработающие инструменты в этой модели;
• отсутствие вариантов серьезного контроля со стороны исполнителя за отношениями «заказчик vs команда» может привести не только к потере команды, но и к финансовым потерям со стороны исполнителя из-за этого.

После того как мы определились с моделью, необходимо ознакомиться с обязательными пунктами в контракте, ведь ошибка в контракте или упущение выражается во вполне ощутимых денежных знаках.

Обязательные пункты контракта

• Подробное описание проекта

Первое, что должно быть в контракте на аутсорсинг, — это детальное описание проекта. Тут указывается все — от членов команды до рисков и методик их смягчения. Подробную форму см. в приложении 1.

• Соглашение об уровне сервиса (SLA)

SLA, или соглашение об уровне сервиса, — соглашение, в котором описываются детальные характеристики услуги, права и обязанности заказчика и поставщика, а также уровень доступности целевого сервиса.

В SLA среди прочего указывается:

• согласованное время работоспособности, СВР (к примеру, «24×7» подразумевает круглосуточное функционирование, семь дней в неделю);
• согласованное время поддержки, СВП (к примеру, «8×5» подразумевает «10:00 — 18:00, пн-пт»);
• время простоя (downtime) — интервал с момента неработоспособности сервиса до момента возобновления его работы. К примеру, если SLA равен 99%, простой может быть не более 7,5 часа в месяц, если 99,9% — уже не более 43,5 минуты в месяц;
• время реакции — интервал между получением сигнала от системы мониторинга (или клиента) о возможном нарушении работоспособности сервиса и началом работ по восстановлению доступности.

Ключевой пункт SLA — фактическая доступность, которая устанавливает процент доступности сервиса за расчетный период. Считается по формуле: (СВР за период – время простоя за период) / СВР) × 100%. Для примера: доступность 99,95% подразумевает, что общее время простоя не должно превышать 22 минуты в месяц. Показатель может рассчитываться как на инфраструктуру или сеть в целом, так и на отдельные сервисы — в зависимости от вида услуги. Также в SLA прописываются уровень функциональности дисковой подсистемы (IOPS, latency), временные «окна» технического обслуживания (плановые, срочные), размеры компенсации.

• Передача активов

Существуют различные IТ-активы, которые при заключении соглашения об аутсорсинге необходимо передать: телекоммуникационное оборудование, компьютерное оборудование, аренда оборудования, лицензии на программное обеспечение и т.д. Для официальной передачи этих активов аутсорсинговой компании требуется это документально оформить. При передаче лицензий на программное обеспечение следует обратить внимание, что передача этих активов может потребовать дополнительных затрат или лицензионных сборов. Кроме того, при передаче этих активов могут взиматься налоги и другие сборы, которые необходимо учитывать при согласовании стоимости контракта на аутсорсинг. Кроме того, убедитесь, что ваш контракт на аутсорсинговые услуги исчерпывающе описывает все трансфертные расходы.  

• Гарантия на продукт/проект
  

Обязательным пунктом в контракте должно быть детальное описание гарантии на разрабатываемый продукт или выполняемый проект. Необходимо указать:

• разрабатываемый продукт на выходе будет заранее оговоренного и прописанного качества;
• срок гарантии;
• гарантировать заказчику, что в случае выявленных недостатков, которые появились по вине исполнителя, эти недостатки будут устранены за счет исполнителя;
• на что гарантия не распространяется.

• Право собственности или право на управление/использование продукта

Естественное желание каждой компании получить право собственности на конечный продукт должно быть четко отражено в контракте.

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

Ваши операции могут быть парализованы, если вам не будет передано полное право собственности на продукт. Клиент должен получить доступ к исходным кодам и контролю за дальнейшими модификациями, чтобы избежать таких проблем в IТ-операциях, как в случае внезапного прекращения или разрыва отношений аутсорсинга.

Отдельно стоит упомянуть использование Free and Open Source Software (FOSS). Это обязательно надо выносить на согласование с клиентом, так как не все заказчики хотят в своих проектах использовать софт с открытым кодом. Но если клиент согласился на использование FOSS, то:

• необходимо использовать только тот FOSS-код, который предоставляется по разрешительным лицензиям, и в договоре определить конкретные виды таких лицензий;
• предусмотреть освобождение IT-компании от ответственности за какие-либо проблемы в работе конечного софта, при разработке которого использовался FOSS, на который заказчик дал свое согласие;
• предусмотреть освобождение или ограничение ответственности компании-разработчика в случае предъявления каких-либо претензий со стороны правообладателей FOSS на случай нарушений условий лицензии FOSS заказчиком.

Иначе вы просто сами под себя подложите мину с часовым механизмом. Не верите? Погуглите про использование FOSS-компонента в программном обеспечении Distribution Channel Management (DCM), которое было разработано компанией Versata Software, Inc.

• Защита интеллектуальной собственности

Самый большой страх клиента — это страх, связанный с риском кражи интеллектуальной собственности, и он вполне обоснован. Поэтому, чтобы избежать или минимизировать вариант наступления такого случая, следует не только детально подходить к выбору исполнителя, но и четко и подробно прописать ответственность сторон за передачу информации третьим лицам, запретить возможную конкуренцию,  а также не помешает упомянуть юридические положения, условия для лицензий, ограничение на обмен информацией и т. д. И конечно, все это должно быть юридически жизнеспособно, т.е. ссылаться на работающие нормы права и законы.

Вот некоторые моменты, которые будут выступать в качестве дополнительной защиты: 

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

• Стоимость работы и структура оплаты

Этот пункт особенно важен, если вы применяете модель ценообразования с фиксированной стоимостью. Фактически в любом контракте на аутсорсинг следует четко указывать цены на аутсорсинг, способ оплаты и структуру оплаты. Он должен ответить на вопрос: когда, как и кто согласует стоимость. Кроме того, следует четко указать сумму, которая будет выплачиваться при расторжении. Цена, согласованная обеими сторонами, должна включать все предоставляемые услуги, лицензионные сборы на программное обеспечение, налоги и т.д. Также должен быть пункт, посвященный пересмотру затрат в указанный период времени в соответствии с меняющейся динамикой рынка технологий. Также следует упомянуть фиксированные и переменные компоненты цен, изменения затрат с течением времени и проч. Так как, например, стоимость обработки бита информации постоянно падает, и крайне неразумно не оставить в контракте вариант пересмотра фиксированной цены.

• Термин действия контракта

Во многих случаях, как и в модели с фиксированными затратами, масштаб проекта довольно ясен и определить крайний срок не очень сложно. Упоминание срока, в течение которого контракт будет существовать, важно в контракте. Правильно описанная продолжительность вашего контракта имеет большое значение.  Спросите: «Почему?» В качестве примера: BBC подписала 10-летний контракт с Siemens Business Services на аутсорсинг IТ-услуг в 2004 году без права расторжения — и это обязательство дорого им обошлось. За эти годы появлялось множество вариантов ускорить, удешевить, но условия контракта не позволяли этого сделать.
 
Вот почему лучше разбивать срок действия контракта на подпериоды, чтобы иметь возможность либо пролонгировать срок действия, либо перейти на обслуживание к другому.

• Раздел разрешения споров (юрисдикция)

Рынок аутсорсинговых услуг по разработке программного обеспечения стал глобальным. Контракты на IТ-аутсорсинг часто бывают международными, когда клиент и поставщик базируются в разных странах. Таким образом, одним из основных краеугольных камней контракта с поставщиком IТ-аутсорсинга является юрисдикция, которой он подчиняется. Для сторон чрезвычайно важно договориться о том, каким будет регулирующее право контракта, а также как будет выглядеть процесс разрешения споров, в зависимости от ситуации. Стороны могут обратиться в местный суд или выбрать международный арбитраж.

Поверьте, вы просто можете не потянуть судебные разбирательства в лондонском суде.

• Пункт про субподряд

Не секрет, что в IT-индустрии частенько прибегают к субподряду — это ускоряет работу, делает исполнителя более гибким и многовариантным. Но нужно учесть и предусмотреть, например, такой момент, как потеря интеллектуальной собственности. Можно четко прописать запрет на такой вид сотрудничества, прописать, где он возможен, вплоть до обязательного предоставления информации, что, где и как он делает. Не забывая, конечно же, про ответственность основного подрядчика, который в данном случае должен нести ответственность за привлекаемых к работе третьих лиц.

• Пункт про возмещение убытков и ответственность сторон

Так как во время действия контракта частенько возникают различные юридические коллизии, необходимо четко расписать пункт про возмещение расходов в случае: срыва сроков, несоблюдения прописанных пунктов, даже ущерб деловой репутации… Не стоит пренебрегать детальным описанием того, что будет относиться к убыткам, а также методику расчета компенсаций в случае потребности в них. Естественно, ответственность должна быть прописана двусторонняя, это увеличит шансы согласования и подписания контракта.

• Стратегия выхода

Как прекратить отношения аутсорсинга? Это повредит вашему бизнесу? Будет ли у вас по-прежнему полный контроль над программным обеспечением? Все это должно быть описано в разделе стратегии выхода вашего контракта на аутсорсинг.

Это может быть последний, но один из самых важных компонентов, который необходимо включить в ваш контракт на аутсорсинг. Вы должны очень четко прописать варианты о прекращении отношений.

Эти варианты должны ответить на все эти вопросы в стратегии выхода:

• Какие активы или элементы будут возвращены поставщику услуг, а что останется у вас?
• У кого будут права на ПО?
• Как скоро активы будут возвращены?

• Подписание контракта

Подпись — самая важная часть вашего контракта на аутсорсинг. Подписывая договор, вы юридически заявляете, что все прочитали и согласны с этим. Вы будете юридически связаны контрактом, как только он будет подписан. И дабы не попасть впросак, еще раз проверьте, включены ли все необходимы пункты, корректно ли описаны:

• услуги и их полное описание;
• перепроверьте структуру оплаты и общую стоимость;
• убедитесь, что стратегия выхода вас никоим образом не связывает;
• прочтите условия использования интеллектуальной собственности еще раз;
• посмотрите, не упоминаются ли какие-либо ограничительные положения.

Отдельно вынесу ОБЯЗАТЕЛЬНУЮ процедуру для компаний, которые собираются работать с европейскими компаниями.

С 2018 года в Евросоюзе принят Общий регламент по защите данных (GDPR), который вы должны соблюдать, если:

• собираетесь работать с государственными органами власти;
• деятельность компании будет связана с разработкой продуктов для мониторинга самочувствия, здоровья, местоположения: смарт-весы, смарт-автомобили, фитнес-приложения, продукты в сфере digital health и т.д.;
• будут обрабатываться персональные данные европейцев.

У вас, помимо того что в штате должен быть Data Protection Officer (DPO) — это сотрудник или подрядчик компании, который будет помогать в вопросах внедрения и поддержания соответствия требованиям законодательства Европейского союза и ЕЭС (Европейского экономического сообщества) касательно защиты персональных данных, должны быть четко прописаны в контракте положения об обработке персональных данных (либо положения, внесенные в сам договор, либо выполненные в качестве дополнения к основному договору).

В процессе принятия решения о целесообразности наличия такого сотрудника может возникнуть желание сделать это фиктивно, так сказать, для галочки, не стоит забывать, что за нарушение Регламента предусмотрены штрафы в размерах до 10 000 000 евро либо до 20 000 000 евро: величина варьируется в зависимости от статьи GDPR. Если оборот компании больше 0,5 млрд евро, то максимальный штраф считается в процентах от мирового оборота за прошлый год: от 2 до 4%. Санкции устанавливает ст. 83 GDPR. А также надзорные органы имеют право налагать административные штрафы как на контролеров, так и на процессоров данных. Штрафы могут идти вместо либо вместе с другими мерами, предписанными надзорными органами.

 Вот примеры самых больших штрафов за время действия Регламента.

• В январе 2019 года компания Google была оштрафована на 50 млн евро за то, что их политика приватности не соответствовала требованиям GDPR. Политика была написана на много страниц и на сложным языке, из-за чего пользователи не понимали, как обрабатываются их персональные данные. Кроме того, согласие на обработку персональных данных также не соответствовало Регламенту, поскольку за пользователей уже заранее были проставлены галочки во всех полях.
• Компания H&M была оштрафована Гамбургским надзорным органом на 35,3 млн евро. Такое решение было принято после того, как шведский масс-маркет бренд проводил мониторинг нескольких сотен своих сотрудников. В данную обработку попали данные о личной жизни работников, которые впоследствии стали доступны по всей компании.
• Компания TIM (telecommunications operator) была оштрафована надзорным органом Италии на 27,8 млн евро. Компания совершила целый ряд нарушений, в числе которых: отсутствие согласия на маркетинговую деятельность, обращение к субъектам данных, которые просили не связываться с маркетинговыми предложениями, недействительные согласия, собранные в приложениях TIM, отсутствие надлежащих мер безопасности для защиты персональных данных, отсутствие четких сроков хранения данных.
• В июле 2018 года авиакомпания British Airways получила штраф в размере 22 млн евро за отсутствие надлежащих технических мер информационной безопасности по ст. 32 GDPR.
• Сеть отелей Marriott International, Inc оштрафовали на 20,5 млн евро. В 2016 году Marriott поглотила другую группу компаний, которая тоже была связана с отельным бизнесом. Позже выяснилось, что с 2014-го у этой группы компаний была серьезная уязвимость в системе защиты информации. В Marriott о ней узнали только в 2018 году, уже после утечки. Она коснулась 339 млн пользователей. Среди информации оказались банковские сведения и другие персональные данные.

Эти пять случаев только подтверждают слова о важности соблюдения Регламента.

Кстати, наличие в штате DPO даст дополнительные очки компании при заключении соглашения с европейскими компаниями.

P.S.

Приложение 1

Приложение 2

Вопрос: Кто является заинтересованными сторонами этого проекта? 

Ответ: Рассмотрим 360-градусную область сверстников и заинтересованных сторон вверх и вниз по течению в следующих категориях.

Функциональные результаты

1. Спонсоры/инициаторы проекта.
2. Конечные потребители продукции проекта (профессорско-преподавательский состав, сотрудники, студенты; другие).
3. Функциональные офисные или административные пользователи.
4. Другие администраторы данных.
5. Поддержка пользователей (например, сообщество Techsupport; 4help; База знаний).

Проведение проекта, развертывание и продолжающиеся операции

1. Основная рабочая группа (команды).
2. Персонал, ответственный за закупку оборудования, программного обеспечения, услуг.
3. Тренеры.
4. Потребности сети — существуют ли особые требования CNS к инфраструктуре или к выделению бизнес-циклов?
5. Поддержка системы; поддержка предпроизводства системы; системные администраторы; администраторы баз данных.
6. Продолжаемая поддержка приложений, включая поддержку и обслуживание интерфейса.
7. Поставщики необходимых услуг (например, аутентификация и авторизация).