Ошибки ТЗ на внедрение CRM и автоматизацию

Коротко: Основные ошибки при составлении ТЗ на автоматизацию связаны с игнорированием обязательного перехода на электронные перевозочные документы (ЭПД) с сентября 2026 года и несоблюдением новых правил ФЗ-265 по защите персональных данных. Неправильное проектирование сценариев обмена документами и отсутствие учета трансграничной передачи данных приводят к необходимости дорогостоящей переделки системы и юридическим рискам.

Кстати, в AmSales мы делаем интеграцию с 1С и внедрение и настройку Битрикс24 под ключ. Если нужна помощь - напишите нам.

Почему неверное ТЗ обходится бизнесу в миллионы

Когда собственник заказывает внедрение CRM, он часто ждет "волшебную кнопку", которая сама наведет порядок в продажах. Но реальность такова, что ошибки постановки ТЗ на CRM закладывают фундамент для будущих убытков еще на этапе обсуждения проекта. Это не просто вопрос неудобного интерфейса. Это вопрос того, сможет ли ваша система легально работать в текущем правовом поле.

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

Ошибки часто кроются в непонимании масштаба задачи. Многие думают, что автоматизация документооборота в CRM - это просто кнопка "Скачать PDF". Но в 2026 году, особенно в логистике, это сложнейшая цепочка взаимодействия с государственными системами и контрагентами. Если в ТЗ не прописаны требования к интеграции с ГИС ЭПД, ваша CRM превратится в изолированный остров, который не видит реального движения грузов и документов.

В итоге компания получает продукт, который:

• не соответствует актуальному законодательству (например, по части обязательного использования ЭПД);
• не интегрируется с учетными системами (1С, ERP) из-за неверно описанных форматов данных;
• требует ручного ввода данных, который сводит на нет всю пользу от автоматизации.

Главная ошибка: игнорирование обязательного ЭПД и ЭДО

С 1 сентября 2026 года правила игры в сфере грузоперевозок изменились бесповоротно. Согласно Федеральному закону от 07.06.2025 № 140-ФЗ, электронный формат для транспортных накладных, заказов-заявок и многих других документов стал обязательным. Если ваше ТЗ на внедрение CRM в логистике по-прежнему подразумевает "бумажный сценарий по умолчанию", вы проектируете систему, которая уже устарела в момент запуска.

Теперь ключевым требованием является интеграция CRM с ЭПД (электронными перевозочными документами). Это не просто отправка файла по почте. Это полноценное взаимодействие через аккредитованных операторов ИС ЭПД. Если в ТЗ не указано, что система должна поддерживать работу в рамках ГИС ЭПД, вы столкнетесь с тем, что ваши менеджеры будут тратить часы на дублирование данных из CRM в государственные системы вручную.

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

Во-первых, нужно четко зафиксировать перечень документов, которые переходят в обязательный электронный формат. Сюда входят железнодорожные накладные, грузовые накладные при авиаперевозках и экспедиторские документы. Во-вторых, необходимо описать процесс получения и подписания этих документов прямо внутри интерфейса CRM. Менеджер не должен переключаться между окнами - он должен видеть статус документа в ГИС ЭПД прямо в карточке заказа.

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

Как учесть новые требования ФЗ-265 по персональным данным

Работа с персональными данными (ПДн) - это зона повышенного риска. С июля 2026 года вступил в силу Федеральный закон № 265-ФЗ, который существенно ужесточил правила игры. Теперь при составлении ТЗ на автоматизацию недостаточно просто написать "обеспечить защиту данных". Регулятор требует конкретики в том, как именно эти данные обрабатываются, где хранятся и кто имеет к ним доступ.

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

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

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

Ловушка интеграции: почему одного модуля CRM недостаточно

Многие руководители совершают классическую ошибку: они покупают "коробочное" решение или заказывают разработку одного модуля CRM, полагая, что этого хватит для покрытия всех нужд бизнеса. Но в 2026 году CRM - это не просто база контактов. Это центральный узел, который должен быть бесшовно связан с десятками других сервисов. Если вы не закладываете в ТЗ требования к открытому API и возможности глубокой интеграции, вы строите "золотую клетку".

Для логистических компаний или дистрибьюторов критически важна связка CRM с учетными системами (например, 1С) и системами управления складом (WMS). Если интеграция настроена поверхностно - например, только по передаче контактов клиента - вы теряете главный смысл автоматизации. Настоящая ценность в том, чтобы при смене статуса заказа в CRM, в учетной системе автоматически создавалась отгрузка, а в системе ЭДО формировался пакет документов.

Еще одна ловушка - отсутствие интеграции с системами мониторинга транспорта. Если ваш менеджер по продажам видит в CRM, что заказ "в работе", но не знает, где физически находится машина, он не может дать качественный сервис. В ТЗ нужно требовать не просто "наличия данных", а автоматического обновления статусов доставки из систем мониторинга прямо в карточку сделки. Это позволяет переходить от реактивного управления ("что случилось?") к проактивному ("что произойдет?").

Проектирование сценариев обмена документами вместо функций

Самая глубокая ошибка при составлении ТЗ на автоматизацию заключается в подходе "от функций". Заказчик пишет: "Система должна уметь отправлять счета". Это слабая формулировка. Она не описывает процесс. Профессиональное ТЗ должно описывать сценарии (use cases) обмена документами. Вместо функции "отправка счета" нужно описывать путь документа: от момента закрытия сделки до момента получения электронного подтверждения от контрагента.

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

1. После подтверждения перевозки в CRM, система автоматически формирует заказ-заявку.
2. Заявка передается в систему ЭПД через аккредитованного оператора.
3. При получении статуса "подписано" от перевозчика, CRM меняет статус сделки на "подтверждено" и создает задачу диспетчеру.
4. Если документ отклонен, система уведомляет менеджера и создает задачу на исправление данных.

Когда вы описываете сценарии, вы учитываете все "разветвления" процесса. Что делать, если контрагент не использует ЭДО? Что делать, если пришел отказ по причине расхождения в весе? Если в ТЗ прописаны только "счастливые пути" (happy paths), где все проходит идеально, ваша автоматизация сломается при первом же реальном рабочем дне. Разработчики просто не будут знать, как обрабатывать ошибки, и напишут код, который будет просто "падать" при любых отклонениях от стандарта.

Помните, что автоматизация документооборота в CRM - это не про хранение файлов, а про управление жизненным циклом документа. Документ должен "двигаться" по системе, меняя статусы, создавая задачи и триггеря другие процессы. Только так вы получите прозрачную систему, где каждый участник процесса понимает свою зону ответственности и текущий статус дела.

Как правильно описать требования к трансграничной передаче данных

В условиях 2026 года вопрос трансграничной передачи данных перестал быть чисто техническим и стал вопросом выживания бизнеса. Если ваша компания работает с иностранными контрагентами, перевозчиками или использует облачные сервисы, чьи серверы находятся за пределами РФ, вы обязаны учесть это в ТЗ. Поправки ФЗ-265 усилили контроль: теперь недостаточно просто иметь юридический адрес в другой стране.

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

Как это реализовать на практике?

• Требуйте в ТЗ разделения баз данных: персональные данные граждан РФ должны храниться на серверах внутри страны.
• Прописывайте требования к анонимизации данных перед их отправкой во внешние сервисы (например, для аналитики или маркетинга).
• Указывайте необходимость ведения детального журнала трансграничных перемещений данных.

Часто компании пытаются "сэкономить", используя глобальные SaaS-решения без настройки локального хранения данных. Это огромная ошибка. В 2026 году риск блокировки таких сервисов или наложения колоссальных штрафов перевешивает любую экономию на инфраструктуре. В ТЗ должно быть четко указано: "Система должна обеспечивать хранение персональных данных на территории РФ в соответствии с требованиями законодательства, включая механизмы контроля трансграничного обмена".

Чек-лист проверки ТЗ перед началом разработки системы

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

Блок 1: Соответствие закону

• Учтены ли требования ФЗ-265 по защите ПДн и ролевой модели доступа?
• Прописаны ли сценарии работы с обязательными электронными документами (ЭПД) через ГИС ЭПД?
• Есть ли в ТЗ требования к хранению данных на территории РФ?
• Описаны ли механизмы логирования действий пользователей с персональными данными?

• Указаны ли конкретные типы документов для интеграции с ЭДО (УПД, накладные и т.д.)?
• Описаны ли API-методы для связи с 1С или вашей ERP-системой?
• Прописаны ли сценарии синхронизации данных (что происходит, если связь прервалась)?
• Учтена ли необходимость интеграции с внешними сервисами мониторинга или телефонии?

• Описаны ли не только функции, но и полные сценарии (use cases) движения документа/заказа?
• Есть ли в ТЗ описание обработки ошибок (отказ контрагента, сбой связи, неверные данные)?
• Определены ли триггеры автоматизации (например, "при смене статуса на Х - отправить уведомление Y")?
• Учтены ли требования к отчетности (какие данные и в каком виде должны быть в отчетах)?

Стоимость исправления ошибок внедрения CRM и автоматизации

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

Первый уровень потерь - это прямые затраты на доработку. Поскольку архитектура системы уже построена, разработчики не могут просто "добавить функцию". Им приходится переписывать ядро, менять структуру таблиц в базе данных и перенастраивать все существующие интеграции. Это всегда стоит в разы дороже, чем если бы эти требования были заложены в ТЗ изначально. По нашему опыту, исправление фундаментальных архитектурных ошибок может стоить до 70-100% от стоимости первоначальной разработки.

Второй уровень - это операционные потери. Пока система "лечится", ваши сотрудники возвращаются к ручному труду. Это значит, что вы платите зарплату за то, что автоматизация должна была исключить. Скорость обработки заказов падает, ошибки в документах растут, а риск штрафов за нарушение ФЗ-265 или несоблюдение правил работы с ЭПД становится реальностью. В логистике один день простоя из-за невозможности выписать электронную накладную может стоить компании миллионов рублей из-за срыва графиков поставок.

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

Что запомнить:

• С 01.09.2026 работа без интеграции с ГИС ЭПД в логистике становится нелегальной и неэффективной.
• ТЗ должно описывать сценарии (процессы), а не просто набор функций.
• ФЗ-265 требует глубокой проработки прав доступа и контроля трансграничной передачи данных.
• Исправление ошибок в архитектуре после запуска стоит в 3-5 раз дороже, чем качественное проектирование.