Договор на рабочие места под ключ: границы ответственности

Что такое «рабочие места под ключ» и где чаще всего спорят

«Рабочее место под ключ» обычно понимают как готовый к работе комплект: устройство (ПК, моноблок или ноутбук), операционная система, драйверы, базовые настройки, нужные приложения, доступы и понятный результат приемки. Проблема в том, что у разных сторон этот термин означает разное. Поэтому договор на рабочие места под ключ часто становится источником споров не из-за «железа», а из-за того, что именно считается «готово».

Конфликт часто начинается с фразы «не работает», за которой скрываются разные причины: не выдали учетную запись или права, приложение установили, но оно не активируется, отсутствуют драйверы, обновления или настройки безопасности блокируют запуск. Бывает и так, что лицензия куплена «не на того», не подтверждена документами или не подходит по типу использования. Еще один частый разрыв ожиданий: заказчик рассчитывает на перенос данных и настройку периферии, а подрядчик считает это отдельной услугой.

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

Простой пример: сотруднику поставили новый ПК, Outlook не подключается. Подрядчик говорит «почта не наша зона», заказчик отвечает «рабочее место должно работать». Такой спор легко снять заранее, если в договоре прописано, кто настраивает профиль, кто выдает доступ, а кто подтверждает работоспособность.

Это уточнение выгодно всем: заказчику - чтобы получить измеримый результат; интегратору - чтобы не отвечать за чужие процессы; службе информационной безопасности (ИБ) - чтобы не было «серых» настроек; закупкам и бухгалтерии - чтобы лицензии и документы сходились.

Как правильно описать предмет договора простыми словами

Предмет договора стоит формулировать так, чтобы его понял не только юрист, но и руководитель ИТ, бухгалтер и будущий пользователь. Если в тексте остаются слова вроде «установка и настройка», но неясно, чего именно и до какого результата, спор почти гарантирован.

Удобно описывать договор через роли, состав поставки и понятный «финиш».

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

Дальше опишите объект договора в измеримых терминах: количество рабочих мест, их типы, площадки, периферия и особые требования. Например: 120 офисных ПК, 30 моноблоков с сенсорным экраном, 10 инженерных рабочих станций, плюс принтеры, сканеры, гарнитуры и доставка по 3 адресам.

Чтобы не спорить о слове «готово», задайте границу между «готово к работе» и «в эксплуатации». Практичное правило: «готово к работе» означает, что пользователь может войти, открыть нужные приложения и распечатать тестовую страницу. «В эксплуатации» начинается после подписания приемки и передачи комплектов документов.

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

Идея простая: если на объекте «не работает рабочее место», договор должен позволять быстро понять, это зона подрядчика (например, не установлен драйвер печати) или зона заказчика (например, учетная запись не создана вовремя).

Слои ответственности: от железа до пользовательских приложений

Чтобы в договор на рабочие места под ключ не попадали «серые зоны», полезно разложить результат на слои. Тогда спор «у нас не работает» превращается в понятный вопрос: на каком уровне сбой и кто за него отвечает.

Обычно достаточно такой структуры:

• Железо: ПК/монитор/периферия, гарантия, серийные номера, базовое тестирование.
• BIOS/UEFI: версии, пароли, Secure Boot/TPM, порядок загрузки.
• ОС и базовая конфигурация: редакция, язык, образ, учетные записи, политики.
• Драйверы и обновления: источники, версии, окно обновлений, правила перезагрузок.
• Прикладное ПО и пользовательская среда: перечень программ, версии, плагины, профили, ярлыки.

Ключевой момент в формулировках: «установить» и «обеспечить работоспособность» - не одно и то же. Установка может означать «пакет поставлен», но не гарантировать запуск при ограничениях прокси, DLP или без нужных прав в домене. Если вам нужна именно работоспособность, пропишите, в каких условиях она проверяется и кто эти условия обеспечивает.

Отдельно зафиксируйте зависимости, которые лежат вне поставки рабочего места: домен/AD, сеть и VLAN, DNS/NTP, почта, прокси, антивирус/EDR, DLP, печать и драйверы серверов печати. Иначе подрядчик «настраивает», а заказчик «не дает доступов», и приемка встает.

Практичный прием - разделить «настройку на устройстве» и «готовность инфраструктуры». Например, подрядчик настраивает профиль пользователя и Outlook, а заказчик заранее выдает учетную запись, почтовый ящик и доступ к автоконфигурации.

Перед стартом работ согласуйте короткий набор правил: какие доступы и когда дает заказчик (AD, сети, прокси, репозитории обновлений); что считается «работает» для каждой программы (сценарий проверки); кто отвечает за политики безопасности, которые могут блокировать запуск; кто ведет учет версий образа, драйверов и приложений; где проходит граница поддержки после ввода в эксплуатацию.

ОС, драйверы и обновления: где провести линию

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

ОС: образ, редакция и активация

Зафиксируйте, кто предоставляет образ ОС и кто имеет право его менять. Если заказчик требует корпоративный «золотой образ» с доменными настройками, лучше прямо написать, что подрядчик ставит именно его, а ответственность за состав и совместимость образа лежит на заказчике. Если образ готовит подрядчик, тогда он отвечает за корректность установки и повторяемость результата.

Отдельно пропишите редакцию, язык, разрядность, способ активации (KMS, MAK, OEM) и кто предоставляет ключи. Частая практика выглядит так: заказчик предоставляет лицензии и данные для активации, подрядчик выполняет установку и подтверждает факт активации в приемочных материалах.

Драйверы, патчи и ИБ-настройки

Драйверы - зона риска, потому что «вроде все работает», пока не подключили принтер, не включили второй монитор или не запустили видеоконференцию. Договоритесь, кто выбирает версии драйверов и как проходит тест.

Полезно закрепить границы простым блоком:

• ОС: кто дает образ, кто согласует редакцию и язык, кто выполняет установку.
• Активация: кто дает лицензии и ключи, кто отвечает за успешную активацию.
• Драйверы: кто подбирает версии, кто тестирует на типовых сценариях (печать, сеть, звук, камера).
• Обновления: что входит в поставку (например, актуальные патчи на дату приемки), а что относится к поддержке по SLA.
• ИБ-настройки: кто утверждает политики (шифрование, агенты безопасности), кто внедряет и что считается «успешным внедрением».

Пример: подрядчик поставил ПК, все приняли, но через неделю после обновлений перестал работать сканер. Если прописано, что обновления после даты приемки выполняет заказчик, то откат и проверка совместимости - его задача. Если обновления включены в сопровождение, подрядчик восстанавливает работоспособность по согласованной процедуре.

Прикладное ПО: список, версии, настройки и совместимость

Когда в договор на рабочие места под ключ включают «установить прикладное ПО», спор чаще начинается не про установку, а про ожидания: какие версии нужны, какие плагины обязательны, что считать «работает», и кто отвечает за совместимость.

Как описать состав ПО

Практичный подход - фиксировать перечень не «в целом», а по ролям пользователей (например: бухгалтерия, колл-центр, инженеры, руководители). Тогда видно, где стандартный набор (офисный пакет, браузер, PDF), а где специализированные приложения.

Чтобы избежать разночтений, удобно прямо указать, кто предоставляет установочные пакеты и дистрибутивы (или доступ к ним), кто предоставляет ключи/учетные записи/подписки, кто ведет реестр версий и дат установки (что именно поставили на какие ПК), и кто утверждает изменения (обновления, замены, удаление ПО).

Короткий пример: заказчик просит «поставить CAD», а потом выясняется, что нужна конкретная сборка и плагин под старый проект. Без реестра версий и понятного источника дистрибутива спор почти неизбежен.

Совместимость и настройки

Заранее согласуйте список поддерживаемых версий и простой пилот: на 1-2 рабочих местах проверяют запуск, печать, доступ к сетевым ресурсам, работу с ЭЦП или сертификатами, если это требуется.

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

Лицензии и право использования: как не создать риск для обеих сторон

В договоре на рабочие места под ключ лицензии часто оставляют «между строк». В итоге ПО установлено, люди работают, а потом приходит аудит, смена сотрудников или обновление, и внезапно непонятно, кто отвечает за право использования.

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

Чтобы не спорить по каждой программе, удобно зафиксировать минимум: кто приобретает лицензии и в какие сроки до установки; где хранятся подтверждающие документы и кто предоставляет их при аудите; тип лицензирования для каждого продукта (на устройство, на пользователя, подписка) и как считается количество; кто создает и ведет учетные записи в порталах вендоров и кто отвечает за доступы; что делать при окончании подписки, блокировке аккаунта или изменении правил лицензирования.

Со сторонним ПО (Microsoft, Oracle, SAP и другими) важно отдельно прописать: кто принимает условия вендора, кто ведет переписку по активации, кто обеспечивает доступ к порталам, и что считается «готовностью лицензии» (например, активированный ключ, назначенный пользователь, доступ к подписке).

Главный риск для обеих сторон - «лицензии нет, но ПО стоит». Запретите установку без подтверждения права использования и добавьте простой контроль: сверка установленного ПО с утвержденным реестром на приемке. Например, подрядчик передает список установленных приложений по серийным номерам ПК, а заказчик подтверждает, что на каждую позицию есть лицензия или письменное разрешение заменить продукт на бесплатный аналог.

Пошаговая схема работ: от подготовки до ввода в эксплуатацию

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

Начните с планирования. Подрядчик не может «угадать» среду заказчика, поэтому входные данные лучше перечислить заранее и назначить ответственного за их предоставление: учетные записи и роли (локальные или доменные), параметры сети (VLAN, DNS, прокси, Wi‑Fi, доступ к репозиториям обновлений), требования ИБ (антивирус, шифрование, запреты на USB, политики), список прикладного ПО с версиями и источниками дистрибутивов, окно работ и правила доступа на площадку.

Дальше идет эталон. Подрядчик собирает «золотой образ» или пакет установки: ОС, драйверы, базовые настройки, нужные агенты и обязательные приложения. Важно заранее определить пилот, например 3-5 рабочих мест в типовом подразделении. После пилота фиксируются версии и контрольные суммы, чтобы тиражирование было повторяемым.

На тиражировании обычно всплывают «бытовые» детали: доставка, распаковка, маркировка, подключение мониторов и периферии, присоединение к домену, установка приложений и проверка принтеров. Если оборудование поставляет интегратор (например, рабочие станции или моноблоки), стоит отдельно прописать, кто отвечает за совместимость периферии и наличие драйверов.

Сдачу лучше описывать как проверку по чек-листу с понятными критериями: загрузка и вход пользователя, сеть и доступ к нужным ресурсам, работа ключевых приложений, печать/сканирование (если требуется), устранение дефектов и повторная проверка.

Такой порядок помогает быстро отделить «не настроили сеть» от «не тот драйвер» и не превращать приемку в спор о формулировках.

Приемочные артефакты: что должно остаться «на руках» у заказчика

После сдачи рабочих мест важен не только акт приемки. Если через месяц часть ПК уйдет в ремонт, появится аудит по лицензиям или спор о том, «так и было», решает набор документов и реестров, которые остаются у заказчика.

Минимальный комплект артефактов лучше закрепить прямо в договоре или приложении к нему:

• Реестр оборудования: модель, конфигурация, серийные номера, гарантия, дата ввода в эксплуатацию, где стоит каждое рабочее место.
• Реестр ПО: что установлено, версии, откуда получено (дистрибутив), кто предоставил лицензии и на каком основании используется.
• Акты и протоколы: акт приемки, протокол испытаний по согласованным проверкам, ведомость замечаний со сроками исправления.
• Эксплуатационные документы: короткая инструкция пользователю, инструкция администратору, схема развертывания (как восстанавливать и обновлять).
• Материалы по ИБ: какие политики применены, какие агенты стоят (EDR, DLP и т.п.), какие исключения сделаны и кто их согласовал.

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

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

Матрица RACI: простой способ зафиксировать зоны ответственности

Когда в договоре на рабочие места под ключ нет ясных ролей, любая ошибка превращается в спор: «это ваша зона» против «это у вас в инфраструктуре». Матрица RACI помогает закрепить, кто делает работу (R), кто принимает окончательное решение и подписывает результат (A), кого подключают как эксперта (C), и кого просто держат в курсе (I).

Чтобы RACI работала, делите ее не «в целом по проекту», а по слоям: ОС и образ, драйверы, домен и учетные записи, сеть и Wi‑Fi, ИБ (антивирус, политики, шифрование), прикладное ПО, печать и сканирование.

Пример строк для одной рабочей станции (сокращенно):

• ОС: установка и настройка - R: подрядчик, A: заказчик, C: ИБ заказчика, I: служба поддержки
• Драйверы: чипсет, видео, печать - R: подрядчик, A: заказчик, C: производитель/вендор, I: пользователи
• Домен и доступы - R: заказчик, A: заказчик, C: подрядчик, I: пользователи
• Прикладное ПО по списку - R: подрядчик, A: заказчик, C: владелец приложения, I: ИБ
• Печать в конкретной сети - R: заказчик, A: заказчик, C: подрядчик, I: пользователи

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

Самое ценное - описать исключения и «серые зоны». Например: кто отвечает за обновления ОС после приемки, как действуем при конфликте драйвера с корпоративной политикой ИБ, что делать, если приложение требует нестандартных прав или старой версии компонента. Формулировки лучше делать однозначными: «подрядчик делает X при условии Y; если Y нет, ответственность у заказчика; подрядчик консультирует в течение Z дней».

Если рабочие места поставляются как готовое оборудование (ПК, моноблоки или серверная часть под VDI), RACI особенно важна на стыке «железо - инфраструктура». Тогда проще согласовать, где заканчивается ответственность производителя/интегратора и начинается ответственность ИТ-службы заказчика.

Реалистичный пример: как спорят о «неработающем рабочем месте»

Типичный спор выглядит так: рабочее место формально сдано, но в первый же день пользователь говорит, что «ничего не работает». Подрядчик отвечает: «ОС стоит, драйверы поставлены, дальше это уже ваша ИТ-служба». Заказчик считает, что раз это договор на рабочие места под ключ, то проблема целиком на подрядчике.

Сценарий из практики интеграции: поставили ПК, подключили принтер и токен, установили нужные приложения. На приемке все запускается, но через неделю начинается поток заявок.

Что именно ломается и где обычно граница

1. «ОС установлена, но не активируется». Часто подрядчик ставит ОС, но ключ, KMS/MAK и доступ к серверу активации дает заказчик. В договоре стоит зафиксировать, кто предоставляет ключи и доступы, и в какие сроки. Иначе простаивание рабочих мест неизбежно.

2. «Драйвер есть, но периферия не работает». Подрядчик отвечает за установку драйверов на согласованные модели, а заказчик - за то, чтобы эти модели были заранее перечислены (принтеры, сканеры, ЭЦП-носители) и реально доступны для теста до массовой поставки.

3. «Приложение падает». Здесь важно разделить: установка (подрядчик), базовая настройка (по ТЗ), лицензия (кто покупает и на кого оформлена), совместимость (какие версии ОС и зависимостей поддерживаются), а также ограничения ИБ (политики, EDR, белые списки), которые может менять только заказчик.

4. «Пользователь не может войти». Обычно учетные записи, права, домен, MFA и группы - зона ИТ заказчика. Подрядчик настраивает клиент и присоединение к домену, но не создает права «на лету», если это не оговорено.

Как оформлять инциденты после сдачи

Чтобы не спорить «на словах», в гарантийный период договоритесь о простом формате заявки: серийный номер и инвентарный номер, текст ошибки и скриншот, что изменилось (обновления, политики ИБ, замена периферии), кто пробовал и какие шаги уже сделаны, срок реакции и критерий «восстановлено».

Так спор быстро превращается в проверяемую диагностику: что было в зоне подрядчика на момент приемки, а что изменилось на стороне заказчика после нее.

Частые ошибки в договорах и ТЗ, которые потом дорого стоят

Самые дорогие конфликты появляются не из-за «плохой работы», а из-за размытых формулировок. В договор на рабочие места под ключ часто попадают общие слова, которые каждая сторона читает по-своему.

Типовые ошибки, которые ведут к спорам и сдвигу сроков:

• ПО перечислено «в целом» (например, «офисный пакет, браузер, антивирус»), но без версий, языка, разрядности и источника дистрибутива.
• Нет определения «готово к работе»: что именно должен уметь пользователь, какие проверки считаются успешными.
• В одном документе смешаны поставка оборудования, работы по настройке и дальнейшее сопровождение, но не определена дата, когда ответственность за эксплуатацию переходит к заказчику.
• Не описаны обязанности заказчика: кто дает доступы, кто готовит сеть и домен, кто согласует окна работ, кто принимает решения на месте.
• Нет правил управления изменениями: после установки «еще одного агента ИБ» ломаются драйверы или вход в домен, и начинается поиск виноватых.

Типичный сценарий: рабочее место сдано, акты подписаны, через неделю служба ИБ заказчика ставит новый агент. После перезагрузки не работает печать и камера в видеосвязи. Подрядчик говорит: «это изменение среды», заказчик отвечает: «вы же сдавали рабочее место». Без процедуры изменений и точки отсечения по времени обе стороны теряют время и деньги.

Чтобы закрыть риски, добавьте в ТЗ и договор базовые вещи: четкие критерии приемки (проверки и ожидаемые результаты), список ПО с версиями и параметрами установки, границу ответственности по времени (до ввода в эксплуатацию и после), порядок изменений (кто инициирует, кто согласует, кто оплачивает, как фиксируется результат).

Быстрый чек-лист перед подписанием и перед приемкой

Перед тем как подписать договор на рабочие места под ключ, полезно пройтись по короткому списку проверок. Он помогает заранее отделить «настройку по умолчанию» от того, что реально должен сделать подрядчик, и снижает риск споров на приемке.

Перед подписанием убедитесь, что в договоре и ТЗ явно зафиксировано:

• Состав рабочего места по слоям: железо, ОС, драйверы, обновления, домен/учетки, сеть, печать, базовые политики ИБ и список прикладных программ.
• Кто отвечает за совместимость: например, если «1С/клиент банка» работает только с конкретной версией ОС или требует исключений в антивирусе.
• Как управляются изменения: версии образа, политики, исключения, а также что считается изменением объема и как оно согласуется.
• Лицензии на ПО: тип лицензирования, на кого оформляется право использования, какие документы передаются, и кто их хранит.
• Поддержка после ввода: куда обращаться, время реакции, окно работ, порядок эскалации и что считается гарантийным случаем.

Перед приемкой важно не просто «проверить, что включается», а убедиться, что у вас останутся доказательства и возможность повторить конфигурацию.

На приемке запросите и проверьте:

• Реестр поставленных рабочих мест (серийные номера, комплектация, привязка к кабинетам/пользователям, если нужно).
• Акты и протоколы тестов: вход в домен, доступ к сетевым ресурсам, печать на конкретных принтерах, обновления, базовые проверки ИБ.
• Перечень установленного ПО с версиями и ключевыми настройками, включая исключения и разрешения.
• Инструкции для пользователей и администраторов: как восстановить, переустановить, подключить периферию, куда писать в поддержку.
• Доступы и пароли: только в допустимом формате (например, через запечатанный конверт или корпоративный менеджер секретов) и с указанием, кто владелец.

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

Следующие шаги: как подготовиться и выбрать формат работ

Начните с короткого набора вводных. Чем точнее вы опишете, кто и как будет работать за компьютером, тем меньше сюрпризов на приемке. Сразу разделите требования на обязательные (без них нельзя запустить) и желательные (можно внедрять позже).

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

Дальше зафиксируйте в приложениях к договору три вещи: RACI по слоям (железо, ОС, драйверы, ПО, обновления), критерии приемки и список приемочных артефактов (образы, ведомости, акты, инструкции, учет лицензий). Если это не приложено, спор почти гарантирован.

Перед массовым развертыванием проведите пилот на 2-5 рабочих мест. Выберите «сложные» роли, прогоните реальные задачи и оформите короткий протокол результата: что принято, что дорабатывается, кто и в какие сроки.

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

Если вам нужны и поставка оборудования, и развертывание, часто удобнее выбирать исполнителя, который закрывает цикл целиком и потом поддерживает парк. Например, GSE.kz (gse.kz) производит компьютеры, моноблоки и серверы в Казахстане и выступает системным интегратором, что упрощает разделение ответственности между поставкой «железа», внедрением и дальнейшей поддержкой.