ТЗ на автоматизацию: 12 пунктов без слива бюджета

Как написать ТЗ на автоматизацию, чтобы подрядчик сделал как надо

Техническое задание — это документ, который переводит бизнес-требования в проверяемые условия реализации проекта. Если фраза из ТЗ не проверяется на приемке, ее там быть не должно.

Когда ко мне приходят после неудачного внедрения, почти всегда выясняется одно: ТЗ писали от функций, а не от результата. Например, «нужен бот для заявок» звучит понятно, но не отвечает на 5 критичных вопросов: кто подает заявку, по какому сценарию, в какие системы идут данные, кто согласует, где точка отказа. В Deloitte, PwC и позже в проектах для крупных компаний вроде МТС и X5 именно такие пробелы обычно и создавали риск дорогих переделок.

Начинайте с цели процесса, а не с экрана или кнопки

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

В ТЗ для подрядчика цель лучше фиксировать в цифре. Было: согласование счета занимает 3 дня и 6 касаний между отделами. Стало: до 4 часов, 2 касания, статус виден всем участникам. Тогда и у заказчика, и у исполнителя появляется единица измерения, а не повод спорить на этапе сдачи.

Соберите 12 пунктов, без которых документ слабый

Вот минимальный состав, который я использую в проектах PROMAREN для автоматизации бизнес-процессов:

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

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

Что должно быть в ТЗ, кроме списка хотелок

В марте 2026 я разбирала проект, где заказчик написал 4 страницы пожеланий и считал, что этого достаточно. Через 7 недель подрядчик принес прототип, который формально совпадал с текстом, но не решал задачу продаж. Документ был подробный по интерфейсу и пустой по логике.

Чтобы понять, какое ТЗ нужно для автоматизации бизнес процесса, смотрите на связку из 4 слоев: процесс, данные, роли, контроль. Пожелания к интерфейсу идут только после них. В проектах для крупного бизнеса этот принцип работает одинаково — будь то авиаперевозчик, ритейл или телеком. У Аэрофлота, X5 или МТС масштабы разные, но ошибка одна и та же: сначала обсуждают форму, потом вспоминают про процесс.

ТЗ на автоматизацию — это описание цели, процесса, данных и правил приемки, по которому можно проверить результат без споров о трактовке. Хорошее ТЗ связывает бизнес-цель со сроками, бюджетом и ответственностью сторон.

Опишите процесс последовательно, включая исключения

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

Если у вас есть заявка, то в ТЗ нужны минимум 3 режима: нормальный сценарий, сценарий с ошибкой и сценарий с возвратом на доработку. Именно исключения обычно съедают срок. Подрядчик может честно сделать основной путь, но на третьей неделе пилота выяснится, что никто не продумал отмену, замену ответственного или повторное согласование.

Зафиксируйте данные, роли и границы проекта

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

Права доступа лучше описывать по ролям, а не по фамилиям. Интеграции тоже нужно перечислять сразу: CRM, ERP, бухгалтерия, почта, мессенджеры, телефония. Если интеграции не внесены в ТЗ, подрядчик позже оформит их как дополнительный объем работ. В апреле 2026 я снова видела этот сценарий: базовый проект продали за одну сумму, а после старта стоимость выросла на 35% только из-за «внезапно открывшихся» обменов данными.

Когда нужен быстрый и бюджетный запуск, подходят конструкторы Make.com и n8n. Когда приоритет — надежность, масштаб и контроль, разумнее идти в код. Этот выбор тоже надо зафиксировать в документе, иначе вас будут оценивать по разным моделям реализации. Теперь перейдем к главному вопросу: почему отсутствие такой детализации так быстро сливает бюджет.

Почему без ТЗ автоматизация сливает бюджет

300 000 рублей могут исчезнуть еще до первого релиза, если проект стартовал с формулировок «сделайте удобно» и «добавим по ходу». Бюджет в автоматизации утекает не в один момент, а серией маленьких решений без рамки.

По данным материалов РБК о проектах автоматизации, компании недооценивают стоимость неверно заданного объема и потребность во внутренней ИТ-компетенции при запуске изменений. По данным практических публикаций на Habr, автоматизация ускоряет процесс только там, где логика заранее формализована и проверяема. Если логика расплывчата, система просто начинает быстро воспроизводить хаос.

Основные каналы утечки денег предсказуемы

1. Сначала согласовали одну задачу, потом выяснили, что нужны интеграции.
2. Сделали основной сценарий, потом нашли 6 исключений, которых не было в описании.
3. Не определили критерии приемки, поэтому работа «почти готова» неделями.
4. Не разделили ответственность, поэтому заказчик и подрядчик перекладывают вину.
5. Не задали границы проекта, поэтому каждая новая идея кажется логичным продолжением.

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

Сколько реально стоит ошибка в описании

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

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

Как понять, что ТЗ на автоматизацию составлено слабо

Клиент спросил: а можно проверить документ за 15 минут, если сам не технарь? Я ответила: да, если смотреть не на термины, а на проверяемость. Слабое ТЗ видно по тому, что в нем много текста и мало условий, которые можно принять или отклонить.

Ниже чек-лист, который помогает понять, что прописать в ТЗ чтобы подрядчик не сорвал проект. Я бы советовала пройти его до тендера и еще раз перед подписанием договора. В 2025 это уже базовая гигиена проекта, а в 2026 — обязательный фильтр для любого внешнего исполнителя.

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

1. Есть ли у проекта цель в цифрах, а не только описание удобства.
2. Понятно ли, где границы проекта и что в него не входит.
3. Описаны ли сценарии работы от старта до завершения, включая ошибки.
4. Перечислены ли все интеграции и источники данных.
5. Есть ли права доступа по ролям и условия логирования действий.
6. Есть ли критерии приемки по каждому блоку, а не одна общая фраза.
7. Разделены ли ответственность, сроки и входные данные от заказчика и подрядчика.

Если на 2-3 вопроса нет точного ответа, документ уже рискованный. Если нет ответов на 4 и более, проект почти гарантированно уйдет в пересборку. Подрядчик может быть сильным, но работать ему придется в тумане. А значит, и вы будете покупать не результат, а попытки уточнить, что имелось в виду.

Большинство внедрений ломается после MVP, когда заканчивается запас допущений. Закладывайте отдельный этап калибровки на 2-4 недели после запуска и фиксируйте его в ТЗ заранее.

Что важнее для проекта: ТЗ на автоматизацию или выбор подрядчика

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

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

• Если нужно быстро проверить гипотезу — Make или n8n. Быстрый запуск, бюджет ниже, результат за дни.
• Если нужен масштаб, SLA и строгий контроль — код. Предсказуемость, надёжность, нет ограничений платформы.
• Если нет внутренней экспертизы — подрядчик плюс внешний надзор. Иначе приёмка будет слепой.

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

Где проект ломается чаще всего

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

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

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

Что ещё стоит учесть

Можно ли написать ТЗ на автоматизацию без технического бэкграунда?

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

Что делать, если подрядчик просит сначала договор, а ТЗ потом?

Сначала зафиксируйте хотя бы рамочное ТЗ. Без него договор будет описывать общий процесс сотрудничества, но не результат. Допустим вариант с отдельным этапом аналитики, где первым артефактом становится согласованное техническое задание с границами проекта и сроками.

Как составить ТЗ подрядчику, если процесс еще меняется?

Разделите требования на стабильное ядро и гипотезы. В ядро включите обязательные функции, роли, интеграции и критерии приемки. Гипотезы оформите отдельным бэклогом изменений. Тогда подрядчик оценит базовый объем честно, а проект не поплывет из-за новых идей.

Что должно быть в ТЗ для автоматизации бизнес-процесса в первую очередь?

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

ТЗ на автоматизацию пример лучше брать из интернета или писать с нуля?

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

Как выбрать подрядчика, если сам не технарь?

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

Когда для автоматизации нужен код, а не конструктор?

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

Можно ли менять ТЗ после старта проекта?

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