// система электронного документооборота

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

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

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

Именно эти вопросы в типовом ТЗ чаще всего остаются на усмотрение подрядчика — с формулировкой «согласование реализовать по действующему регламенту организации» или вовсе без упоминания. На этапе разработки это означает, что подрядчик либо угадывает, либо постоянно переспрашивает, а на приёмке — что система делает не то, что подразумевалось.

Что обычно упускают в ТЗ

Маршруты согласования описаны как «в соответствии с принятым порядком организации»

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

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

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

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

Как написать правильно. Указать объём и состав архива, подлежащего переводу в электронный вид: сканирование, индексация, привязка к карточкам документов. Если полный перевод архива не требуется — явно написать, что в объём работ входит только текущий документооборот с такой-то даты.

Требования к электронной цифровой подписи не прописаны или ограничены фразой «поддержка ЭЦП»

Чем оборачивается. Подпись документов ЭЦП — не опция, а отдельный модуль интеграции с удостоверяющим центром, со своей логикой хранения сертификатов, проверки подлинности и юридической значимости подписанного документа. Если в ТЗ не указано, с каким УЦ интегрироваться и какие типы документов требуют подписи, этот модуль либо не реализуют вовсе, либо делают в последний момент без тестирования.

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

Роли и права доступа описаны общими словами вроде «администратор», «пользователь», «руководитель»

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

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

Обучение сотрудников и переходный период не заложены в сроки проекта

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

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

Контроль сроков исполнения поручений описан как функция, но без конкретных сценариев эскалации

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

Как написать правильно. Описать сценарии уведомлений: за сколько дней до срока предупреждать исполнителя, что происходит при просрочке, кому и в каком виде уходит эскалация — email, системное уведомление, отчёт руководителю.

Что даёт хорошее ТЗ

Хорошее ТЗ на СЭД превращает организационный регламент в техническое задание до начала разработки, а не во время приёмки.

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

Подрядчик оценивает объём работ точно — включая интеграцию с ЭЦП, перенос архива и этап внедрения — и не несёт расходы на доработки, не предусмотренные в контракте.

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

Сколько стоит и сколько занимает

Техническое задание — от $400, 1–4 недели: цена зависит от сложности системы, архитектуры, стека и интеграций. Разработка на субподряде — по объёму контракта, оценка до подачи заявки.

ТЗ для тендера или субподряд — подробнее →

Заказчиков и закупки не называем: разбираем типовое ТЗ, а не чей-то тендер.

Готовите закупку или уже выиграли тендер?

Обсудить тендер