ТЗ для автоматизации: кто должен писать техническое задание и почему это важно

ТЗ для автоматизации определяет, что именно компания хочет получить от внедрения системы, какие процессы нужно настроить и каким должен быть результат проекта. Если техническое задание составлено поверхностно, команда быстро сталкивается с доработками, спорами, лишними затратами и классическим вопросом: “А почему мы это не обсудили в самом начале?”

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

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

Почему ТЗ для автоматизации нельзя писать “на глаз”

На первый взгляд кажется, что техническое задание — это просто список пожеланий.

Например:

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

Но для реального проекта этого мало.

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

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

А детали в автоматизации — это не мелочи. Это то, на чем держится вся система.

Например, руководитель говорит: “Нужно автоматизировать согласование счета”. Звучит просто. Однако дальше появляются вопросы:

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

Если эти нюансы не попали в ТЗ, они появятся позже. Только уже в виде доработок, задержек и фразы “мы думали, что это очевидно”.

Вот только система не умеет читать мысли. Даже Битрикс24. Даже с AI. Какая досадная техническая мелочь.

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

Обычно компании рассматривают три варианта:

1. ТЗ пишет интегратор.
2. ТЗ пишет ответственный сотрудник внутри компании.
3. ТЗ пишет собственник или руководитель бизнеса.

Каждый вариант может сработать. Однако у каждого есть свои риски.

Поэтому важно не просто выбрать “кто пишет документ”, а правильно организовать сам процесс сбора требований.

Вариант 1. ТЗ для автоматизации пишет интегратор

На мой взгляд, самый надежный вариант — когда ТЗ для автоматизации готовит опытный интегратор.

Почему?

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

Кроме того, интегратор видит типовые ошибки.

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

В результате бизнес получает не просто “как попросили”, а более жизнеспособное решение.

Что делает интегратор при подготовке ТЗ

Хороший интегратор не садится писать ТЗ сразу после первой встречи.

Сначала он изучает процессы компании:

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

Особенно важно разговаривать не только с руководством.

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

Именно эти детали часто решают, будет система работать или нет.

Преимущества интегратора при написании ТЗ

У интегратора есть несколько сильных сторон.

Он знает возможности Битрикс24

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

Он может предложить более простой путь

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

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

Он учитывает опыт других проектов

Если команда внедряла Битрикс24 в разных отраслях, она уже видела типовые сценарии и ошибки.

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

Он проверяет ТЗ на реализуемость

Это важный момент.

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

Вариант 2. ТЗ пишет ответственный сотрудник компании

Второй вариант — когда техническое задание пишет сотрудник внутри компании.

Это может быть руководитель отдела, бизнес-аналитик, проектный менеджер, системный администратор или человек, который отвечает за развитие Битрикс24.

Такой подход тоже может работать.

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

В чем плюс внутреннего сотрудника

Главное преимущество — глубокое знание компании.

Внутренний сотрудник понимает:

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

Это ценная информация.

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

В чем риск такого подхода

Главный риск — недостаточное понимание возможностей Битрикс24.

Сотрудник может хорошо знать бизнес, но не знать, как лучше реализовать задачу в системе.

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

Например, в нем могут быть требования, которые:

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

Поэтому, если ТЗ для автоматизации готовит внутренний специалист, его стоит дополнительно передать интегратору на оценку.

Так можно сохранить знание внутренних процессов, но доработать документ с учетом технической реализации.

Вариант 3. ТЗ пишет собственник бизнеса

Третий вариант — когда техническое задание пишет собственник или генеральный директор.

И здесь ситуация интересная.

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

С другой стороны, собственник часто описывает не текущую реальность, а идеальную картину.

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

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

Почему ТЗ от собственника может быть рискованным

У такого подхода есть несколько рисков.

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

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

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

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

Как правильно собрать требования для ТЗ

Оптимальный вариант — объединить три источника информации.

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

Руководители отделов описывают управленческую логику: кто отвечает за этапы, какие правила действуют, где нужны отчеты и контроль.

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

Интегратор связывает все это с возможностями Битрикс24 и формирует техническое задание, которое можно реализовать.

Такой подход работает лучше всего.

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

Что должно быть в хорошем ТЗ для автоматизации

Хорошее техническое задание должно быть понятным и для бизнеса, и для команды внедрения.

В нем нужно зафиксировать:

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

Кроме того, важно разделить требования по приоритетам.

Не все нужно делать на первом этапе. Часть функций можно внедрить сразу, часть — оставить на следующий релиз.

Это помогает не перегрузить проект и быстрее получить рабочий результат.

Почему подготовка к интервью важна

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

И к этим встречам нужно готовиться.

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

А потом этот “маленький нюанс” требует переделки процесса.

Поэтому перед интервью сотрудникам стоит заранее подумать:

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

Чем точнее команда расскажет о реальной работе, тем качественнее получится ТЗ.

Как плохое ТЗ влияет на проект

Плохое техническое задание почти всегда приводит к одним и тем же последствиям.

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

В результате компания может столкнуться с проблемами:

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

И самое неприятное — многие из этих проблем можно было предотвратить на этапе подготовки ТЗ.

Как мы подходим к созданию ТЗ в Tamplier Digital

Мы начинаем с анализа бизнеса и функциональных требований.

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

При подготовке ТЗ мы всегда смотрим на несколько вещей:

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

В результате клиент получает не просто документ, а понятную основу для проекта.

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

Главный вывод

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

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

Техническое задание — это не формальность перед началом проекта. Это фундамент автоматизации.

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

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