Пример ТЗ на разработку ПО

1. Обложка документа

Фрагмент ТЗ, карта требований и экономическая модель процесса

ПроектB2B-личный кабинет для обработки заявок клиентов

ЦельСократить ручную обработку заявок, повысить прозрачность статуса заказа и связать личный кабинет с CRM и учетной системой

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

Граница ТЗРоли, сценарии, функциональные требования, интеграции, экономика процесса, организационная модель, KPI участников, критерии приемки и план согласования

Версия документаДемонстрационный фрагмент 1.0

2. Контекст проекта

Проектирование начинается с экономики и процесса, а не с экранов

ТЗ фиксирует пользовательские роли, сценарии, требования, интеграции, критерии приемки, экономический расчет, стоимость AS-IS и TO-BE процессов, оргструктуру, KPI участников, риски конфликта целей, наблюдения ручного прогона TO-BE процесса и roadmap согласования.

Понятно, где сейчас теряются деньги и почему текущий процесс дорогой.

Есть расчет целевого эффекта и условия, при которых автоматизация экономически оправдана.

Зафиксированы участники процесса, зоны ответственности и точки принятия решений.

Требования связаны с наблюдениями, KPI, интеграциями и критериями приемки.

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

3. AS-IS процесс

Как работает обработка заявок сейчас

Этап	Как выполняется сейчас	Участники	Проблема	Последствие
Получение заявки	Клиент пишет менеджеру в email или мессенджер	Клиент, менеджер	Нет единого канала	Заявки теряются, сложно контролировать SLA
Уточнение данных	Менеджер вручную запрашивает недостающую информацию	Менеджер, клиент	Нет обязательных полей	Несколько итераций переписки
Создание сделки	Менеджер вручную переносит данные в CRM	Менеджер	Ручной ввод	Ошибки, дубли, неполные карточки
Передача в ERP	Операционный сотрудник вручную заводит заказ	Операции, финансы	Повторный ввод данных	Рост времени обработки
Обновление статуса	Клиент спрашивает статус у менеджера	Клиент, менеджер	Нет самообслуживания	Менеджер тратит время на ответы
Передача документов	Документы отправляются по email	Финансы, клиент	Нет единого архива	Документы теряются в переписке

4. Экономический расчет процесса

Экономика и срок окупаемости

AS-IS затраты 1,966 млн ₽

прямое ручное время и потери в месяц

TO-BE затраты 504 тыс. ₽

целевые затраты обработки в месяц

Эффект 1,362 млн ₽

ожидаемая экономия в месяц

Окупаемость 6,2 мес.

при сохранении целевого эффекта

AS-IS против TO-BE

Где появляется экономический эффект

Обработка заявок / мес. -792 000 ₽ / мес.

AS-IS: 1 296 000 ₽ TO-BE: 504 000 ₽

Стоимость одной заявки -660 ₽

AS-IS: 1 080 ₽ TO-BE: 420 ₽

Ручное время на заявку -22 минуты

AS-IS: 36 минут TO-BE: 14 минут

Запросы статуса от клиентов -650 запросов

AS-IS: 900 / мес. TO-BE: 250 / мес.

Окупаемость

Проект выходит в плюс на 7-й месяц

8,45 млн ₽

1 1,36 млн ₽

2 2,72 млн ₽

3 4,09 млн ₽

4 5,45 млн ₽

5 6,81 млн ₽

6 8,17 млн ₽

7 9,53 млн ₽

Бюджет

Из чего складывается 8,45 млн ₽

Разработка 3,0 млн ₽

Интеграции 1,65 млн ₽

Проектирование и UX 1,1 млн ₽

QA и внедрение 0,95 млн ₽

Управление изменениями 1,0 млн ₽

Резерв 0,75 млн ₽

Стоимость обработки заявки AS-IS

Показатель	Значение	Комментарий
Среднее количество заявок в месяц	1 200	По данным продаж и операционного блока
Среднее время менеджера на первичную обработку заявки	18 минут	Проверка письма, уточнение данных, заведение в CRM
Среднее время операционного сотрудника	12 минут	Проверка, перенос в ERP, согласование
Среднее время финансового специалиста	6 минут	Проверка оплаты, документы
Совокупное ручное время на одну заявку	36 минут	Без учета повторных уточнений
Средняя стоимость часа сотрудника	1 800 ₽	Полная стоимость с налогами и накладными
Прямая стоимость ручной обработки одной заявки	1 080 ₽	0,6 часа x 1 800 ₽
Прямая стоимость ручной обработки в месяц	1 296 000 ₽	1 200 x 1 080 ₽

Оценочная совокупная стоимость AS-IS процесса в месяц: 1 966 000 ₽ с учетом прямого ручного времени и дополнительных издержек.

Дополнительные издержки AS-IS

Вид издержки	Описание	Оценка
Повторные уточнения	Клиент не указал обязательные данные, менеджер возвращается к переписке	180 000 ₽
Ошибки ручного ввода	Неверная компания, сумма, контакт, состав заказа	120 000 ₽
Дубли заявок и сделок	Несколько сделок по одному запросу	70 000 ₽
Запросы статуса от клиентов	Менеджеры отвечают на вопросы «что с заказом?»	210 000 ₽
Потерянные или просроченные заявки	Заявки без реакции или с поздней реакцией	300 000 ₽
Ручная работа с документами	Поиск, пересылка, повторная отправка	90 000 ₽

Оценка экономического эффекта

Экономия на ручной обработке заявок	792 000 ₽ / месяц
Снижение дополнительных издержек	570 000 ₽ / месяц
Совокупный ожидаемый эффект	1 362 000 ₽ / месяц
Стоимость проекта	8 450 000 ₽
Ориентировочный срок окупаемости	6,2 месяца

Стоимость TO-BE процесса после внедрения

Показатель	AS-IS	TO-BE	Эффект
Ручное время на одну заявку	36 минут	14 минут	-22 минуты
Стоимость обработки одной заявки	1 080 ₽	420 ₽	-660 ₽
Стоимость обработки 1 200 заявок в месяц	1 296 000 ₽	504 000 ₽	-792 000 ₽
Доля заявок с неполными данными	32%	8%	-24 п.п.
Количество запросов статуса от клиентов	900 / мес.	250 / мес.	-650 запросов
Дубли сделок в CRM	45 / мес.	до 5 / мес.	-40 дублей
Среднее время реакции на заявку	6 часов	до 30 минут	Улучшение SLA

Стоимость разработки и внедрения

Блок работ	Оценка стоимости	Комментарий
Проектирование и аналитика	650 000 ₽	Интервью, ТЗ, карта требований, интеграции
UX/UI личного кабинета	450 000 ₽	Основные пользовательские сценарии
Backend-разработка	1 800 000 ₽	Заявки, статусы, роли, API
Frontend-разработка	1 200 000 ₽	Интерфейсы клиента и менеджера
Интеграция с CRM	700 000 ₽	Создание и обновление сделок
Интеграция с ERP	950 000 ₽	Статусы, документы, заказы
QA и приемка	550 000 ₽	Функциональное тестирование, регресс, UAT
Внедрение и обучение	400 000 ₽	Инструкции, пилот, поддержка запуска
Резерв на риски	750 000 ₽	Интеграционные и организационные риски
Управление проектом и изменениями	1 000 000 ₽	Координация, коммуникации, change management и запуск пилота

Вывод: проект экономически целесообразен, если ручное время обработки снизится минимум на 45%, а доля неполных заявок снизится не менее чем до 10%.

5. Организационная структура процесса

Роли, решения и RACI-матрица

Участники процесса

Участник	Роль	Зона ответственности	Критичные решения
Руководитель продаж	Владелец коммерческого результата	Скорость реакции, качество обработки заявок	SLA обработки, правила приоритизации
Менеджер продаж	Основной пользователь процесса	Проверка заявки, коммуникация с клиентом	Принять, уточнить или отклонить заявку
Операционный отдел	Исполнительная обработка	Передача заказа в ERP, контроль исполнения	Подтверждение возможности выполнения
Финансовый отдел	Документы и оплаты	Счета, акты, УПД, статусы оплаты	Разблокировка или остановка заказа
IT	Технический владелец системы	Доступность, интеграции, безопасность	Архитектура, SLA, поддержка
Поддержка	Первая линия обращений	Помощь пользователям, инциденты	Эскалация проблем
Клиент	Внешний пользователь	Передача данных и получение статусов	Подтверждение заявки, загрузка документов

RACI-матрица

Процесс / Решение	Продажи	Операции	Финансы	IT	Поддержка	Клиент
Создание заявки	C	I	I	I	I	R
Проверка заявки	R	C	I	I	I	C
Подтверждение заказа	A	R	C	I	I	I
Передача в ERP	I	R	C	C	I	I
Обновление статуса	C	R	C	A	I	I
Публикация документов	I	C	R/A	C	I	I
Решение по инциденту	C	C	C	A/R	R	I
Изменение бизнес-правил	A	C	C	C	I	I

R - Responsible, A - Accountable, C - Consulted, I - Informed.

6. KPI участников

KPI участников и проверка конфликта целей

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

Участник	Текущий KPI	Возможный конфликт	Целевой KPI после внедрения
Руководитель продаж	Количество сделок, выручка	Фокус на объеме без контроля качества данных	Конверсия заявка -> заказ, SLA реакции, доля полных заявок
Менеджер продаж	Количество заведенных сделок	Может создавать сделки с неполными данными	Время первой реакции, качество заполнения, отсутствие дублей
Операционный отдел	Скорость обработки заказов	Может возвращать заявки без анализа причины ошибки	Время обработки полной заявки, доля возвратов по причине неполных данных
Финансовый отдел	Скорость подготовки документов	Может блокировать процесс из-за несогласованных данных	SLA выпуска документов, доля документов без исправлений
IT	Доступность системы	Может фокусироваться только на uptime, а не на качестве процесса	Доступность, скорость интеграций, количество инцидентов, MTTR
Поддержка	Скорость закрытия обращений	Может закрывать обращения без устранения корневой причины	First resolution rate, повторные обращения, качество эскалации
Клиент	Быстро получить результат	Может обходить систему и писать менеджеру напрямую	Доля заявок через ЛК, полнота заполнения, самообслуживание

Риски конфликта целей

Риск	Как проявится	Последствие	Решение в требованиях
Менеджеры продолжат принимать заявки в мессенджерах	Заявки обходят личный кабинет	Нет единой статистики, теряются SLA	Заявка считается принятой только после регистрации в ЛК
Продажи будут заводить неполные заявки ради скорости	Операции и финансы получают некачественные данные	Рост возвратов и ручных уточнений	Обязательные поля, проверка полноты, KPI качества данных
Финансы будут блокировать процесс без прозрачного статуса	Клиент не понимает, почему заказ остановлен	Рост обращений в поддержку	Отдельные клиентские и внутренние статусы
IT будет измерять только доступность системы	Система работает, но процесс остается неудобным	Низкая фактическая adoption rate	Добавить KPI использования и бизнес-метрики процесса
Поддержка будет решать симптомы, а не причины	Повторяющиеся обращения	Рост нагрузки	Категоризация обращений и анализ корневых причин

7. Наблюдения за TO-BE процессом

Ручной прогон целевой логики до автоматизации

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

Результаты наблюдений

Наблюдение	Где проявилось	Что это означает для ТЗ
Клиенты часто не знают, какие поля обязательны	Форма создания заявки	Нужны подсказки, примеры заполнения и валидация на форме
Менеджеры хотят видеть «сырой» комментарий клиента	Проверка заявки	Комментарий клиента должен передаваться без редактирования
Операционному отделу не хватает признака срочности	Передача заявки в обработку	В требования добавить поле «приоритет» и правила его расчета
Финансам нужен отдельный статус проверки оплаты	Подтверждение заказа	Статус оплаты не должен смешиваться со статусом заказа
Клиенты продолжают писать менеджерам напрямую	Коммуникация после заявки	Нужны уведомления и правило: вся история заявки хранится в ЛК
Менеджеры по-разному трактуют статус «В работе»	Статусы заказа	Требуется единый справочник статусов и описание каждого статуса
При ошибке в данных никто не понимает владельца исправления	Возврат заявки	Нужен маршрут возврата и ответственный за исправление
Документы часто запрашиваются до завершения заказа	Документооборот	Нужно показать клиенту ожидаемую дату доступности документов

Метрики ручного прогона

Метрика	Результат	Вывод
Количество заявок в пилотной выборке	50	Достаточно для первичной проверки процесса
Заявки с неполными данными	16 из 50	Требуется жесткая валидация обязательных полей
Среднее время первичной проверки	22 минуты	Есть потенциал сокращения за счет формы и автозаполнения
Количество возвратов на уточнение	14	Нужны подсказки и проверка данных до отправки
Количество спорных статусов	7	Требуется отдельный справочник статусов
Количество обходов процесса через мессенджер	11	Нужна политика использования ЛК и уведомления
Количество ошибок ручной передачи в CRM	5	Интеграция с CRM критична для эффекта проекта

Изменения в требованиях по итогам наблюдений

Исходная гипотеза	Что показал ручной прогон	Изменение в ТЗ
Достаточно одной формы создания заявки	Клиенты часто ошибаются в типе заявки	Добавить разные формы под типы заявок
Статус заказа можно брать напрямую из ERP	ERP-статусы непонятны клиенту	Добавить маппинг внутренних и клиентских статусов
Менеджеру достаточно видеть заявку в CRM	Менеджеру нужен контекст переписки и файлов	Передавать комментарии и вложения в CRM
Финансовый статус можно объединить со статусом заказа	Клиенту важно понимать отдельно оплату и исполнение	Разделить статус заказа и статус оплаты
Уведомления можно добавить после MVP	Без уведомлений клиенты возвращаются в мессенджеры	Включить уведомления в MVP
Ошибки интеграции можно обрабатывать вручную	Риск потери заявок слишком высокий	Включить очередь повторной отправки и статус синхронизации

8. Обновленная карта требований

Требования связаны с экономикой, процессом и приемкой

ID	Тип	Требование	Приоритет	Основание	Критерий приемки
FR-01	Функциональное	Клиент может создать заявку через личный кабинет	High	AS-IS издержки, ручной прогон	Заявка создается, получает ID и отображается в списке
FR-02	Функциональное	Форма заявки содержит обязательные поля с подсказками	High	16 из 50 заявок были неполными	Неполную заявку нельзя отправить
FR-03	Функциональное	Заявки разделяются по типам	Medium	Клиенты ошибались при выборе типа запроса	Для каждого типа заявки доступны свои поля
FR-04	Функциональное	Менеджер видит комментарии и вложения клиента	High	Наблюдения TO-BE	Все данные клиента доступны в карточке заявки
FR-05	Функциональное	Система показывает отдельный статус оплаты	High	Требование финансового отдела	Статус оплаты не смешивается со статусом заказа
FR-06	Функциональное	Клиент видит клиентский статус заказа	High	ERP-статусы непонятны клиенту	В ЛК отображается статус из согласованного справочника
FR-07	Функциональное	Система отправляет уведомления по ключевым событиям	High	Клиенты обходили процесс через мессенджеры	Клиент получает уведомление при изменении статуса
INT-01	Интеграция	Заявка передается из ЛК в CRM	High	Ошибки ручного ввода в CRM	В CRM создается сделка, CRM ID сохраняется в ЛК
INT-02	Интеграция	Ошибки CRM API ставятся в очередь повторной отправки	High	Риск потери заявки	Ошибка логируется, заявка не теряется
INT-03	Интеграция	ERP-статусы маппятся в клиентские статусы	High	Ручной прогон TO-BE	Клиент видит понятный статус
NFR-01	Нефункциональное	Страница списка заявок открывается не дольше 2 секунд	Medium	Пользовательский опыт	При 5000 заявок время ответа не превышает 2 секунд
KPI-01	Процессное	Система фиксирует время первой реакции менеджера	High	KPI продаж	В карточке заявки есть timestamp первой реакции
KPI-02	Процессное	Система фиксирует причину возврата заявки	Medium	Анализ качества данных	Возврат невозможен без выбора причины

Требования к аналитике и контролю KPI

Метрика	Где фиксируется	Для кого нужна	Целевое значение
Время первой реакции на заявку	ЛК / CRM	Руководитель продаж	До 30 минут в рабочее время
Доля заявок с полными данными	ЛК	Продажи, операции	Не менее 90%
Доля заявок, созданных через ЛК	ЛК / CRM	Product owner	Не менее 85% через 3 месяца
Количество дублей сделок	CRM	Sales Ops, IT	Не более 1%
Количество возвратов на уточнение	ЛК	Операции, продажи	Снижение на 50%
Среднее время обработки заявки	ЛК / ERP	Операции	Снижение на 40%
Количество запросов статуса от клиентов	Поддержка / ЛК	Support, продажи	Снижение на 60%
Количество ошибок интеграции	Логи / мониторинг	IT	Все ошибки обработаны или переотправлены
Доля документов, доступных без обращения в поддержку	ЛК	Финансы, поддержка	Не менее 95%

9. Критерии приемки

Проверка готовности с учетом экономики и процесса

ID	Критерий	Как проверяется
ACC-01	Клиент может создать заявку без участия менеджера	UAT-сценарий с клиентской ролью
ACC-02	Неполную заявку нельзя отправить	Проверка обязательных полей и валидации
ACC-03	Заявка передается в CRM без ручного переноса	Проверка CRM ID и состава полей
ACC-04	Ошибка CRM API не приводит к потере заявки	Имитация отказа CRM API
ACC-05	Клиент видит понятный статус заказа	Проверка маппинга ERP -> ЛК
ACC-06	Финансовый статус отображается отдельно от статуса заказа	Проверка карточки заказа
ACC-07	Система фиксирует время первой реакции менеджера	Проверка timestamp в карточке заявки
ACC-08	Руководитель видит базовые KPI процесса	Проверка отчета или выгрузки
ACC-09	Поддержка видит историю статусов и событий	Проверка журнала заявки
ACC-10	Процесс не требует ручного дублирования данных между ЛК, CRM и ERP	End-to-end тест

10. Roadmap согласования

От вводных к согласованному ТЗ

Карта целей и ограничений

1. Интервью и сбор вводных

Зафиксированы цели, ограничения и ожидания

Участники: Бизнес, IT, продукт
Артефакт: Карта целей и ограничений

AS-IS карта процесса

2. Анализ AS-IS

Описан текущий процесс и его стоимость

Участники: Аналитик, продажи, операции, финансы
Артефакт: AS-IS карта процесса

Экономическая модель

3. Экономический расчет

Оценены стоимость транзакции, издержки и эффект

Участники: Бизнес, финансы, аналитик
Артефакт: Экономическая модель

Отчет наблюдений

4. Ручной прогон TO-BE

Проверена целевая логика без автоматизации

Участники: Бизнес, операции, поддержка
Артефакт: Отчет наблюдений

Организационная модель

5. Описание ролей и оргструктуры

Зафиксированы участники, зоны ответственности и RACI

Участники: Руководители функций
Артефакт: Организационная модель

Карта KPI и рисков

6. Проверка KPI и конфликтов целей

Выявлены противоречия между KPI участников

Участники: Бизнес, HR/операции, аналитик
Артефакт: Карта KPI и рисков

Карта требований

7. Декомпозиция требований

Требования разделены на функциональные, интеграционные, нефункциональные и процессные

Участники: Аналитик, разработка, QA
Артефакт: Карта требований

Интеграционная карта

8. Проверка интеграций

Зафиксированы системы, обмены и риски

Участники: IT, подрядчики, архитектор
Артефакт: Интеграционная карта

Acceptance checklist

9. Приемочные критерии

Понятно, как проверять готовность

Участники: QA, бизнес, разработка
Артефакт: Acceptance checklist

Согласованное ТЗ

10. Финальное согласование

Документ готов к передаче в оценку и разработку

Участники: Все стороны
Артефакт: Согласованное ТЗ

Финальный вывод примера: на выходе клиент получает не «описание экранов», а полноценную проектную основу: экономику процесса, AS-IS и TO-BE, оргструктуру, KPI, карту требований, интеграции и критерии приемки.

Пример ТЗ: B2B-личный кабинет для обработки заявок клиентов