Приёмка автоматизации: что забрать у подрядчика

4 августа 2026 · 11 мин чтения

Сценарий показывают на созвоне, всё отрабатывает, акт подписан, подрядчик прощается. Через полгода нужна мелкая правка: поставщик меняет формат выгрузки. И выясняется, что сценарии живут в аккаунте на личной почте исполнителя, ключ к CRM никто, кроме него, не видел, схемы процесса не существует, а сам он занят на другом проекте. Работа сдана и оплачена, но контур принадлежит не вам.

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

Короткий ответ: приёмка - это не подпись на акте, а два действия. Первое: прогнать 10-15 проверок на своих данных, включая заведомо кривые. Второе: забрать 9 артефактов - владение аккаунтами, экспорт сценариев, ключи, резервную копию, схему, README, таблицу «что где лежит», мониторинг и реестр инфраструктуры. Ниже - чек-лист приёмки из 14 пунктов.

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

Чем приёмка отличается от демонстрации

Внешне они похожи: экран, заявка, карточка в CRM, уведомление в чат. Разница в трёх вещах.

Кто выбирает данные. На демонстрации их выбирает подрядчик, и это те данные, на которых сценарий отрабатывает: демо показывает счастливый путь, и так и должно быть. На приёмке данные выбираете вы, и часть из них специально ломаная.

Чьи руки на клавиатуре. На демонстрации мышь ведёт исполнитель, на приёмке нажимает ваш сотрудник. Это ловит целый класс проблем: кнопка есть, но её не найти; поле обязательное, но нигде об этом не написано; чтобы повторить, надо помнить семь шагов.

Что считается результатом. Демонстрация заканчивается словом «работает». Приёмка - списком: столько-то проверок пройдено, столько-то нет, по непройденным срок и дата повторной проверки. Устное «вроде всё ок» в конце означает, что это была демонстрация.

Сценарии приёмки: 10-15 проверок на своих данных

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

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

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

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

Девять артефактов, которые должны оказаться у вас на руках

Проверки отвечают на вопрос «работает ли», артефакты - на вопрос «сможем ли мы жить с этим без автора».

1. Доступы и владение аккаунтами. Перечень сервисов контура - платформа, CRM, почта, телефония, хостинг, домен, платные API - и по каждому: на кого оформлен и кто платит.
2. Экспорт сценариев и исходники. Файлы выгрузки на вашей стороне, а не только внутри платформы: сценарии, скрипты, шаблоны, настройки полей. Плюс ответ, как из них контур поднимается на чистом месте.
3. Ключи, токены и переменные окружения. Что выдано, где хранится, когда истекает. Значения - в вашем менеджере паролей, а не в переписке; требования к хранению разбирает статья про безопасность автоматизации.
4. Резервная копия и порядок восстановления. Не только файл копии, но и ответ, кто делает её дальше: схема есть в сценарии резервных копий рабочих процессов.
5. Схема процесса на одну страницу. Что откуда приходит, куда уходит, где ветвление, где решает человек. Как её рисуют, разбирает статья про описание бизнес-процесса.
6. README: запуск, остановка, обновление. Как понять, что запуск прошёл; как остановить сценарий и включить обратно; что делать при типовой ошибке; кого звать.
7. Таблица «что где лежит». Строки - объекты контура, колонки - где лежит, кто владелец, где ключ, где копия.
8. Мониторинг: алерты и журналы. Куда приходят сообщения об ошибках, кто в получателях, где история запусков.
9. Реестр инфраструктуры. Где живёт решение, какой тариф, когда следующее продление домена и сервера, к кому идти в поддержку.

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

Доступы: почему аккаунт на почте подрядчика - мина замедленного действия

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

Механика простая. Восстановление пароля уходит на его ящик, подтверждение входа - на его телефон. Часть сервисов передаёт владение только по подтверждению с почты владельца, то есть без его участия перенос не начинается. Оплата привязана к его карте, и при неоплате сервис отключается по причине, на которую вы не влияете. Работает это не только в конфликте: отпуск, болезнь и закрытие ИП дают тот же результат при полной доброжелательности.

• Владелец - корпоративный ящик, а не человек. Отдельный адрес вида automation@вашдомен, доступ к которому есть у двух сотрудников.
• Оплата с вашего счёта или карты. Компенсация подписок подрядчику удобна на время работ, но после сдачи это лишнее звено между вами и сервисом.
• Подрядчику - роль администратора, а не владельца. Прав на работу хватает, права передать аккаунт кому-то ещё или удалить его - нет.
• Именные доступы вместо общих. Один логин на всех лишает возможности закрыть доступ конкретному человеку и понять по журналу, кто что менял. Как выдача и отзыв устроены, показывает сценарий выдачи доступов сотруднику.
• Перевыпуск ключей после сдачи. Токены, которые видел подрядчик, перевыпускаются на вашей стороне после работ или после гарантии. Дата назначается на приёмке, иначе она не наступает.

Если аккаунты уже заведены на исполнителя, переносить их проще, пока последний платёж не отправлен.

Документация, которой хватает

Сорок страниц описания вредны дважды: их не читают, и они устаревают быстрее контура, а устаревшая инструкция хуже отсутствующей. Рабочий минимум - три документа.

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

README. Тоже страница, написанная для того, кто не участвовал в разработке: как понять, что всё в порядке; как остановить и запустить; где журнал запусков; три типовые ошибки и что с ними делать; контакты.

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

У каждого документа - дата и место рядом с контуром, а не в чьей-то личной папке.

Кто отвечает за контур после запуска

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

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

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

Мониторинг передаётся вместе с системой

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

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

Как это собирается, показывает сценарий уведомлений об ошибках. По деньгам позиция скромная: мониторинг - от 10 000 ₽, и добавлять его разумнее до подписания акта.

Гарантия и поддержка: что входит, что нет и сколько стоит дальше

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

Поддержка - жизнь системы после гарантии: наблюдение за сбоями, оплата и обновление сервисов, мелкие правки. В нашем прайсе эксплуатация одного сценария - 4-15 тыс. ₽ в месяц, отдельная строка бюджета. Что входит по объёму и какая ставка сверх него - вопрос для приёмки, а не для первого сбоя. Порядок цен разбирает статья про стоимость автоматизации.

Третий вариант - забрать эксплуатацию себе; он рабочий, если артефакты на руках и ответственный назначен.

Как выглядит плохая передача и по каким признакам её видно заранее

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

• Демонстрацию ведёт только исполнитель. Просьба «дайте нажать самим» встречает мягкое сопротивление: «там неочевидно, проще показать».
• На вопрос про экспорт отвечают уклончиво. «Всё внутри платформы, выгружать нечего» - это либо правда про конкретный сервис, и тогда стоит знать цену переезда, либо нежелание отдавать файлы.
• Аккаунты заводятся «пока на нас, потом перенесём». Перенос без даты в календаре легко откладывается на неопределённый срок.
• Документация обещана после запуска. После запуска исполнитель уже на следующем проекте, и мотивация писать документы падает.
• Алерты приходят только подрядчику. Удобно на время работ, рискованно после: о сбое вы рискуете узнать последними.
• В контуре есть узел, который «лучше не трогать», а вопросы о нём уходят в «это сложно объяснить». Нередко за таким узлом стоит самодельная часть, разобраться в которой без автора трудно.

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

Цена вопроса на явных допущениях: контур - один сценарий, автоматизация одного процесса, от 55 000 ₽ и от 7 дней. Через год экспорта, схемы и доступов нет, собирать приходится заново - снова от 55 000 ₽ и снова от 7 дней.

Чек-лист приёмки: 14 пунктов

Каждый пункт - да или нет; «нет» не запрещает подписывать акт, а требует назвать срок и ответственного. Пункты 8-10 стоит закрывать до последнего платежа.

1. Проверки написаны заранее. Список из 10-15 пунктов, показан подрядчику до приёмки, опирается на критерии из ТЗ.
2. Данные ваши и частично кривые. Выгрузка из боевой системы плюс специально испорченные записи.
3. Кнопки нажимает ваш сотрудник. Исполнитель рядом и комментирует, но не ведёт мышь.
4. Проверен отказ внешней системы. Испорченный ключ или отключённая интеграция - и видно, что происходит с заявкой.
5. Проверены повторы и дубли. Одно и то же событие дважды не создаёт двух карточек и двух уведомлений.
6. Проверены права доступа. Каждая роль видит то, что ей положено, и не видит остального.
7. Замечания оформлены списком. Письменно, со сроком исправления и датой повторной проверки.
8. Аккаунты оформлены на компанию. Владелец - корпоративный ящик, оплата с вашего счёта, у подрядчика роль администратора.
9. Экспорт сценариев и исходники лежат у вас. Файлы в вашем хранилище, и известно, как из них контур поднимается заново.
10. Ключи описаны, дата перевыпуска назначена. Известно, что выдано, где хранится и когда истекает.
11. Резервная копия есть, и известно, кто делает её дальше. Не только файл, но и расписание с ответственным.
12. Схема, README и таблица «что где лежит» получены. Три документа с датой, рядом с контуром.
13. Ответственный прошёл по README сам. Остановил сценарий, запустил заново, нашёл журнал и разобрал искусственную ошибку.
14. Мониторинг, гарантия и поддержка зафиксированы письменно. Алерт проверен тестовой ошибкой; названы срок гарантии, её состав, время реакции и цена обслуживания после.

Список смещён в организационную сторону намеренно: проверки без владения аккаунтами дают систему, которой вы не управляете, а владение без проверок - систему, которая делает не то. Про типовые провалы - статья про ошибки при автоматизации.

Честно: полностью своим контур становится не в день приёмки

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

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

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

Итог

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

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

После приёмки остаётся вопрос, сработало ли: какие показатели смотреть в первую неделю, месяц и квартал - в статье про измерение эффекта.

Не готовы обсуждать проект? Оцените выгоду сами: калькулятор ROI автоматизации - 1 минута, без контактов. Или заберите чек-лист «Что автоматизировать первым».