«Разработать систему» — плохая формулировка предмета, потому что она называет жанр работы, а не работу. Под неё одинаково честно подходит и полноценный контур обработки заявок с интеграциями, и три экрана с формой и таблицей. Когда на приёмке выясняется, что стороны имели в виду разное, спор начинается не о качестве и не о деньгах, а о том, что вообще было заказано.
Предмет — первый по порядку и первый по значению раздел договора: из него вырастают объём работ, порядок приёмки и права на результат. Если предмет описан жанром, то и приёмка проверяет жанр: система разработана — да, разработана; акт подписывайте. Возражение «мы имели в виду другое» юридически весит немного, потому что «другое» нигде не записано.
Ниже — пять формулировок из реальных договоров на автоматизацию с одним вопросом к каждой: что под неё можно сдать. Затем конструкция, которая закрывает проблему без юридической эквилибристики, и отдельный случай — когда техзадания на старте нет и написать точный предмет объективно невозможно. Общая карта договора по разделам разобрана в опорном материале кластера.
Пять формулировок и что под каждую можно сдать
Формулировки расположены по возрастанию проверяемости. Первые три встречаются чаще всего, четвёртая выглядит приличной и всё равно оставляет зазор, пятая — рабочая. Колонка «что можно сдать» описывает поведение добросовестного подрядчика, а не мошенника: в том и дело, что при размытом предмете спорят честные люди.
| Формулировка предмета | Что под неё можно сдать | Что остаётся за рамками |
|---|---|---|
| «Исполнитель обязуется по заданию Заказчика оказать услуги по разработке программного обеспечения» | Любой работающий код: скрипт выгрузки, форму, отчёт | Всё, потому что «задание» нигде не приложено и не подписано |
| «Разработка и внедрение системы автоматизации бизнес-процессов Заказчика» | Набор сценариев на усмотрение исполнителя, обычно самый дешёвый | Интеграции, миграция данных, обучение, доступы — если они не названы отдельно |
| «Доработка информационной системы Заказчика в соответствии с заявками Заказчика» | Ровно столько заявок, сколько успели за оплаченное время | Объём и результат: рамочная формулировка живёт только вместе со ставкой и лимитом часов |
| «Выполнение работ по внедрению CRM-системы Битрикс24» | Установка, базовая настройка воронки и прав — без единой интеграции | Обмен с 1С, телефония, перенос базы клиентов, шаблоны документов |
| «Создание программы для ЭВМ по техническому заданию (приложение № 1, версия 1.3 от 14.04.2026); результат — заявка с почты и формы сайта создаёт заказ в 1С:УТ и сделку в Битрикс24» | Только то, что описано в приложении, и в состоянии, которое можно проверить на живой заявке | Ничего существенного: границы работ перечислены в самом приложении |
Разница между четвёртой и пятой строкой — это и есть весь разговор о предмете. В четвёртой названа система, но не названо состояние, в котором она считается внедрённой. В пятой названы обе вещи, и обе проверяемы: есть документ с версией и есть фраза, к которой применим ответ «да» или «нет».
Сравнение в две колонки. Слева «Предмет-жанр: разработка и внедрение системы автоматизации бизнес-процессов» — под ним четыре карточки: три экрана с формой, отчёт, ручной перенос данных, обучение по видео. Справа «Предмет через результат: заявка с почты создаёт заказ в 1С:УТ и сделку в Битрикс24, приложение № 1, версия 1.3» — под ним четыре карточки: разбор писем, извлечение позиций, обмен с учётом, карточка со сделкой. Внизу подпись: «Цена одинаковая — 1 800 000 ₽». Чертёжный стиль, подписи по-русски.
Рамка в договоре, детали в приложении
Пытаться уместить в предмет весь объём работ не нужно и вредно: договор становится нечитаемым, а любое уточнение требует переподписания. Рабочая конструкция другая — в договоре остаётся рамка из четырёх элементов, детали живут в приложении, которое можно версионировать отдельно.
- 1Вид работ. Создание программы для ЭВМ, доработка существующей конфигурации, настройка и внедрение готового продукта — это разные виды с разными последствиями для прав на результат. Формулировка «оказание услуг в сфере информационных технологий» не относится ни к одному из них.
- 2Отсылка к приложению. Номер, дата и версия документа плюс оговорка, что приложение — неотъемлемая часть договора. Без версии отсылка не работает: через три месяца никто не докажет, какой текст был в приложении на дату подписания. Механику версий и способы фиксации мы разбираем в материале о ТЗ как приложении.
- 3Итоговое состояние одной фразой. То, что можно проверить на живом объекте: «заявка с почты и формы создаёт заказ в 1С:УТ и сделку в Битрикс24». Это не дублирует ТЗ, а задаёт критерий, по которому ТЗ читается: любое требование, которое не ведёт к этому состоянию, вынесено за границы.
- 4Что передаётся заказчику. Одна строка про состав результата: исходный код, схемы интеграций, инструкции, доступы. Без неё «результат работ» толкуется узко и сводится к работающей системе на чужом сервере.
Закройте ТЗ и прочитайте только предмет. Если по нему невозможно понять, чем принятая работа будет отличаться от непринятой, предмет описывает жанр. Второй тест: попробуйте придумать самое дешёвое, что формально попадает под эту формулировку. Если придуманное вас не устраивает, а подрядчик по договору вправе это сдать — предмет надо переписывать до подписания.
Широкий предмет режет в обе стороны
Заказчики обычно считают, что широкая формулировка выгодна подрядчику. Это верно наполовину. Широкий предмет действительно позволяет сдать минимальную интерпретацию, но он же лишает подрядчика права отказаться от работ, которые в этот жанр попадают, — и при споре суд смотрит именно на текст, а не на переписку о намерениях.
На практике это выглядит так. Предмет — «разработка и внедрение системы автоматизации обработки заявок». Через два месяца заказчик просит добавить выгрузку в маркетплейс: формально это часть обработки заявок, отказаться сложно. Подрядчик соглашается, но растягивает сроки и требует денег за «доработку сверх ТЗ» — а ТЗ, если оно есть, ссылки в предмете не имеет. Обе стороны тратят по 20–30 часов на переписку и приходят к компромиссу, который никого не устраивает.
Отсюда правило, которое избавляет от половины таких разговоров: у требования есть только два состояния — оно входит в объём и описано в приложении, либо вынесено в раздел границ с отдельной оценкой. Третьего состояния «обсудим по ходу» быть не должно. Как собирается раздел границ и почему он оказывается самым ценным листом документа, разобрано в материале о техзадании на автоматизацию.
Если ТЗ на старте нет: предмет первого договора — обследование
Бывает, что точный предмет написать честно невозможно: процесс не описан, данные в трёх системах и одной таблице, а половина логики живёт в голове у одного сотрудника. В этой ситуации попытка сразу зафиксировать объём приводит либо к завышенной цене с запасом на неизвестность, либо к бесконечным допсоглашениям.
Рабочий выход — сделать предметом первого договора не разработку, а обследование с собственным осязаемым результатом: карта процесса, техзадание, приёмочные сценарии, смета по этапам и календарный план. По рынку такой этап стоит 5–12 % будущего бюджета внедрения. Ниже — модельный расчёт для проекта, ориентировочная цена которого 1 800 000 ₽.
Ключевое условие такой схемы — обследование должно быть отдельным договором или отдельным этапом с собственным актом, а не бесплатной прелюдией. Бесплатное обследование существует, но оплачивается оно из будущей сметы, и подрядчик, потративший 65 часов даром, объективно заинтересован в том, чтобы проект состоялся любой ценой. Платный этап снимает этот конфликт: подрядчик может честно сказать, что автоматизация здесь не окупится.
Схема из двух связанных блоков. Левый блок «Договор 1: обследование», внутри перечислено: 65 часов, 162 500 ₽, срок 3 недели; результат — карта процесса, ТЗ, приёмочные сценарии, смета. Стрелка вправо с подписью «результат становится приложением». Правый блок «Договор 2: разработка», внутри: предмет со ссылкой на приложение, 1 800 000 ₽, пять этапов. Под схемой подпись: «9 % бюджета на то, чтобы остальные 91 % были посчитаны». Чертёжный стиль, подписи по-русски.
Готовая система и заказная разработка: предмет устроен по-разному
Ошибка, которую делают чаще всего: берут шаблон договора на заказную разработку и подставляют в предмет название готового продукта. Получается конструкция, в которой заказчик формально претендует на исключительное право на Битрикс24 или МойСклад — а подрядчик передать его, разумеется, не может.
| Что сравниваем | Внедрение готовой системы | Заказная разработка |
|---|---|---|
| Вид работ в предмете | Настройка и внедрение продукта в объёме приложения | Создание программы для ЭВМ по техническому заданию |
| Что является результатом | Конфигурация продукта под ваш процесс плюс написанные доработки | Новая программа, исходный код и документация к ней |
| Права на результат | Право на сам продукт остаётся у вендора, вашими становятся настройки и доработки | Исключительное право на созданное переходит заказчику, если в договоре не написано иное |
| Что обязательно назвать в предмете | Редакцию и тариф продукта, число лицензий и то, кто их оплачивает | Состав передаваемых артефактов: исходники, схемы, инструкции |
| Главный риск размытого предмета | Сдана «коробка из коробки»: продукт установлен, процесс не изменился | Сдан прототип вместо системы: работает на демонстрации, не выдерживает поток |
Практический вывод: если проект смешанный — а он почти всегда смешанный, потому что готовую систему приходится дорабатывать, — предмет пишется двумя частями. Первая про настройку и внедрение продукта, вторая про создание доработок с переходом прав. Иначе весь объём попадает под одно правило, и на выходе либо заказчик не получает исходники доработок, либо подрядчик обещает то, чего передать не может.
Что спросить у юриста и когда предмет можно не трогать
Формулировка результата и раздел границ — инженерная часть, её пишет тот, кто понимает процесс. Всё, что касается конструкции договора и последствий, идёт юристу. Список короткий, поэтому его удобно задать одним письмом.
- Как в нашей редакции соотносятся предмет, приложение с ТЗ и допсоглашения: что имеет приоритет при расхождении текстов.
- Считается ли договор заключённым, если приложение с ТЗ подписано позже самого договора, и с какой даты идёт срок.
- Достаточно ли нашей формулировки предмета, чтобы исключительное право на созданную программу перешло к нам без дополнительных оговорок.
- Что происходит с работами, которые формально попадают под широкий предмет, но не описаны в приложении: обязан ли подрядчик их выполнять и вправе ли требовать за них оплату.
- Как правильно оформить смешанный предмет, где часть работ — настройка готового продукта, а часть — создание доработок.
И честная оборотная сторона: есть работы, где переписывать предмет не нужно. Разовая настройка внутри существующей системы, где нет нового кода и нечего передавать, — перенастройка воронки, шаблон печатной формы, подключение готового модуля. Здесь достаточно короткого описания работ в счёте или в договоре на 3–4 страницы: предмет спора меньше стоимости его согласования, а приёмка занимает час.
Не нужен развёрнутый предмет и при почасовой работе с фиксированным лимитом: там роль предмета выполняют ставка, потолок часов и право остановить работы. Разбор моделей оплаты и того, когда какая из них честнее, — в отдельном материале. Во всех остальных случаях правило одно: если по предмету нельзя отличить принятую работу от непринятой, договор ещё не написан, каким бы длинным он ни был.
