ТЗ на автоматизацию бизнеса: как описать требования без лишней бюрократии

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

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

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

Короткий вывод

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

Зачем бизнесу ТЗ на автоматизацию

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

Например, компания хочет внедрить CRM. Если ТЗ начинается со слов «нужна карточка клиента, воронка и задачи», оно почти ничего не говорит о бизнес-логике. Важнее понять, откуда приходит лид, как он квалифицируется, когда появляется коммерческое предложение, кто согласует скидку, как сделка передается в исполнение, что считается просрочкой, какие отчеты нужны руководителю и где менеджеру нельзя действовать по своему усмотрению.

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

Чем хорошее ТЗ отличается от списка пожеланий

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

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

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

Шаг 1. Зафиксируйте управленческую цель

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

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

Если цель касается продаж, полезно свериться с логикой ВЕБОФИС: CRM: в CRM важна не только воронка, но и связка лида, задачи, КП, клиента, договора, исполнения и повторного касания. Если цель касается внедрения в целом, изучите страницу внедрения ВЕБОФИС: там хорошо видно, что автоматизация начинается с обследования, настройки процессов и запуска команды, а не с установки программы.

Шаг 2. Опишите текущий процесс без украшений

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

Для каждого процесса удобно использовать простую карту:

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

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

Шаг 3. Определите границы первого этапа

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

Для первого этапа лучше выбрать ограниченный, но ценный контур. Например, не «автоматизировать весь отдел продаж», а «привести входящие заявки, квалификацию, КП, задачи менеджера и передачу в исполнение к единому маршруту». Не «сделать корпоративный портал», а «запустить единый вход внутренних заявок, статусы, SLA и ответственность по типовым услугам». Не «внедрить ИИ во все процессы», а «подключить AI-помощника к базе знаний и ограничить его ответами на типовые вопросы».

В ТЗ стоит явно разделить требования на четыре группы:

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

Шаг 4. Назначьте владельцев ролей и решений

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

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

Минимальный набор ролей для ТЗ:

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

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

Шаг 5. Опишите данные, справочники и качество заполнения

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

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

Например, для сделки в CRM можно зафиксировать:

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

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

Шаг 6. Разделите функциональные и нефункциональные требования

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

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

Для каждого важного сценария задайте вопросы:

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

Если в проекте есть ИИ, отдельным разделом опишите источники знаний, ограничения ответов, сценарии передачи человеку и ответственность за обновление базы. Посмотреть продуктовый контекст можно на страницах ВЕБОФИС: AI, ВЕБОФИС: НЕЙРОКОНСУЛЬТАНТ и ВЕБОФИС: СКАНЕР ОТДЕЛА ПРОДАЖ.

Шаг 7. Сразу договоритесь о приемке

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

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

В ТЗ удобно добавить таблицу приемки:

Такая таблица дисциплинирует обе стороны. Команда внедрения понимает, что именно проверять, а бизнес видит, что приемка связана с рабочими действиями, а не с субъективным ощущением «нравится или нет».

Шаг 8. Опишите интеграции и ручные обходы

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

Для каждой интеграции в ТЗ стоит указать:

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

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

Шаг 9. Сделайте план внедрения частью ТЗ

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

Полезно описать этапы:

1. обследование процесса и согласование целей;
2. подготовка прототипа или карты будущего процесса;
3. настройка базового контура;
4. импорт и очистка стартовых данных;
5. пилот на ограниченной группе пользователей;
6. исправление критичных замечаний;
7. обучение команды;
8. запуск в рабочий режим;
9. первый управленческий разбор по фактическим данным;
10. формирование бэклога улучшений.

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

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

Используйте этот список как быстрый контроль перед стартом разработки или настройки системы.

• Цель проекта сформулирована как управленческий результат, а не как установка программы.
• Описан текущий процесс: участники, шаги, документы, исключения, проблемы.
• Описан будущий процесс: какие действия должны измениться после запуска.
• Зафиксированы границы первого этапа и список того, что не входит в релиз.
• Назначены владельцы процесса, данных, приемки и изменений.
• Описаны роли пользователей, права доступа и ограничения.
• Перечислены ключевые сущности и обязательные поля.
• Есть правила качества данных, обработки дублей и истории изменений.
• Описаны функциональные требования по сценариям.
• Описаны нефункциональные требования: безопасность, скорость, журналирование, уведомления.
• Указаны интеграции, поля обмена, ошибки и ручные обходы.
• Для каждого ключевого сценария есть критерий приемки.
• Есть план пилота, обучения, запуска и сбора обратной связи.
• Описан порядок изменения требований после старта.

Типовые ошибки и риски

Ошибка 1. Писать ТЗ только силами подрядчика

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

Ошибка 2. Описывать интерфейс раньше процесса

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

Ошибка 3. Считать исключения мелочами

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

Ошибка 4. Не назначать владельца справочников

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

Ошибка 5. Не фиксировать порядок изменений

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

Как применить это в ВЕБОФИС

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

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

Контекстный CTA: если вы готовите внедрение CRM, клиентского портала, AI-помощника или системы задач, начните с короткого обследования и карты процесса. Команда ВЕБОФИС поможет превратить требования в понятный первый этап: без лишнего документа ради документа, но с достаточной детализацией, чтобы запуск был управляемым.

FAQ

Нужно ли малому бизнесу полноценное ТЗ?

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

Кто должен писать ТЗ на автоматизацию?

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

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

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

Что важнее: описание процесса или список функций?

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

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

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

Нужно ли включать в ТЗ интеграции?

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

Как не превратить ТЗ в бюрократию?

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

Что делать, если после старта появились новые требования?

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