Как подготовить техническое задание на CRM и ERP: процессы, роли, данные и границы системы
Техническое задание на CRM или ERP часто начинают с перечня разделов: клиенты, сделки, задачи, склад, отчёты. Такой список помогает представить интерфейс, но почти ничего не говорит о поведении системы. Неясно, кто создаёт заказ, какие данные обязательны, когда документ можно изменить, что происходит при ошибке и по каким признакам работа считается выполненной. В результате одинаковые слова участники проекта понимают по-разному.
Полезное ТЗ описывает не набор экранов, а проверяемую модель работы. В ней есть цель, границы системы, участники, сущности, состояния, правила перехода, исключения, интеграции и критерии приёмки. Документ не обязан быть громоздким. Его задача — сделать решения явными до того, как они превратятся в код и данные.
Техническое задание начинается с управленческого результата
Фраза «внедрить CRM» не задаёт результата. Система может хранить контакты, но не предотвращать потерю обращений. Может показывать воронку, но не объяснять, почему заказ остановился. Поэтому в начале ТЗ нужно назвать процесс и наблюдаемое изменение: например, каждое обращение получает ответственного; заказ нельзя передать в исполнение без согласованного состава работ; руководитель видит просроченные действия без ручного сбора информации.
Результат удобно описывать тремя частями:
— какое событие запускает контролируемый процесс;
— какое состояние или документ подтверждает его завершение;
— какие отклонения система должна обнаруживать и кому сообщать.
Так появляется граница задачи. Если проект охватывает путь от заявки до подтверждённого заказа, в первую версию не обязательно включать весь складской и финансовый учёт. Но связь с ними нужно обозначить, чтобы позднее не выяснилось, что CRM самостоятельно считает сумму, которую фактически определяет 1С.
Не путайте требования и варианты реализации
Требование отвечает на вопрос, что система обязана обеспечить. Вариант реализации объясняет, как именно это будет сделано. «Менеджер видит только клиентов своего подразделения» — требование к доступу. «Добавить фильтр по подразделению на странице клиентов» — лишь один интерфейсный вариант, который сам по себе не защищает данные в API, выгрузках и отчётах.
Эта разница особенно важна при разработке CRM и ERP (https://synchroweb.ru/crm-erp/). Если преждевременно закрепить расположение кнопок, команда может детально воспроизвести привычный экран и упустить правило, ради которого он существует. Сначала фиксируют нужный результат, ограничения и проверку. Прототип интерфейса прикладывают позже как пояснение, а не используют вместо требований.
Стандарт ISO/IEC/IEEE 29148 рассматривает требования как отдельный инженерный процесс и описывает связанные с ним информационные материалы. Для прикладного проекта это не означает обязательный большой комплект документов. Практический вывод проще: каждое существенное требование должно иметь источник, ясную формулировку и способ проверки.
Проведите системную границу до описания модулей
CRM, ERP, 1С, сайт, телефония и личный кабинет могут участвовать в одном процессе, но не должны одновременно владеть одними данными. В ТЗ полезно нарисовать контекст: какие системы существуют, какими объектами они обмениваются и где принимается окончательное решение.
Для каждой внешней системы фиксируют:
— какие данные она передаёт и принимает;
— какое событие запускает обмен;
— какая сторона является владельцем значения;
— допустима ли задержка;
— что видит пользователь при недоступности связи;
— кто разбирает расхождения.
Например, CRM может управлять коммуникацией и ходом заказа, а 1С — номером проведённого документа, учётной суммой и оплатой. Тогда CRM вправе показать эти данные, но не должна молча заменять их своим расчётом. Подробная схема обмена рассматривается отдельно в материале об интеграции CRM, 1С, сайта и телефонии (https://synchroweb.ru/blog/integraciya-crm-1c-sajta-telefonii/).
Опишите роли через решения и ограничения
Названий «администратор», «менеджер» и «бухгалтер» недостаточно. В разных компаниях за ними стоят разные полномочия. Для каждой роли нужно перечислить не только видимые разделы, но и действия над конкретными объектами: создать, назначить, согласовать, отменить, восстановить, экспортировать, увидеть финансовые поля или историю изменений.
Хорошо работает матрица «роль — объект — действие — условие». Менеджер может редактировать черновик предложения, но не согласованную версию. Руководитель может утвердить скидку в пределах своей зоны ответственности. Бухгалтер подтверждает учётный документ, но не меняет содержание обращения. Системная учётная запись интеграции получает только те операции, которые нужны обмену.
Отдельно фиксируют замещение, временный доступ и смену ответственного. Иначе отпуск сотрудника превращается в передачу пароля либо ручное изменение десятков карточек. Требования к доступу должны действовать одинаково в интерфейсе, API, отчётах и выгрузках.
Сущности важнее названий экранов
Сущность — это объект бизнеса со своей идентичностью и жизненным циклом: обращение, клиент, договор, заказ, объект обслуживания, счёт, платёж, задача. Если всё хранить внутри «сделки», со временем появляются повторяющиеся поля и неоднозначные связи. Один клиент может иметь несколько договоров, один договор — несколько заказов, а оплата может относиться к определённой версии документа.
Для каждой сущности в ТЗ достаточно ответить на несколько вопросов:
— когда и кем она создаётся;
— какой идентификатор остаётся неизменным;
— какие поля обязательны и на каком этапе;
— с какими объектами она связана;
— можно ли её удалить или только закрыть и архивировать;
— какие изменения должны сохраняться в истории;
— какая система является источником каждого ключевого поля.
Словарь сущностей снижает число скрытых предположений. Если «клиент» для продаж означает контактное лицо, а для бухгалтерии — юридическое лицо, это две разные сущности или как минимум две роли одного объекта. Такое различие нужно определить до миграции данных.
Состояния должны отражать факты, а не намерения
Статус полезен, когда по нему можно понять, что уже произошло и какие действия разрешены дальше. Формулировки вроде «в работе» или «почти готово» слишком широки. Лучше отделять факты: данные проверены, предложение отправлено, условия согласованы, документ зарегистрирован, оплата подтверждена, исполнение завершено.
В ТЗ составляют таблицу переходов. Для каждого перехода указывают исходное и новое состояние, инициатора, предварительные условия, обязательные данные, автоматические действия и возможность отмены. Если после согласования документ нельзя просто отредактировать, описывают выпуск новой версии. Если отмена допустима, определяют, кто её выполняет и какие связанные операции должны быть остановлены.
Диаграмма BPMN может показать последовательность работы, но она не заменяет правил состояния конкретной сущности. Один процесс иногда затрагивает сразу несколько жизненных циклов: договор согласован, заказ ещё не запущен, счёт выставлен, но не оплачен. Смешивать их в единый универсальный статус опасно.
Основной сценарий без исключений неполон
На встречах обычно описывают маршрут, в котором данные верны, сервисы доступны, согласование пройдено, а клиент не меняет решение. Реальная нагрузка на систему возникает в отклонениях. Поэтому после основного сценария для каждого шага задают вопросы: что может отсутствовать, прийти повторно, измениться, опоздать или быть отклонено?
В требования стоит включить как минимум:
— дубли обращения или документа;
— неполные и противоречивые данные;
— возврат на исправление после согласования;
— смену ответственного во время процесса;
— отказ внешней системы или задержку ответа;
— повторную отправку одного события;
— отмену после выполнения части операций;
— ручное исправление с обязательным комментарием.
Исключение не всегда нужно полностью автоматизировать. Иногда надёжнее создать очередь ручного разбора и показать оператору контекст. Важно, чтобы отклонение не исчезало в журнале ошибок и не оставляло объект в неопределённом состоянии.
Интеграция требует контракта на данные
Фраза «настроить интеграцию с 1С» не проверяется. ТЗ должно назвать операции и формат: какое событие передаётся, какие поля входят в запрос, какой ответ считается успешным, как представлены ошибки, как сопоставляются идентификаторы и что происходит при повторе.
Официальный REST-интерфейс платформы 1С позволяет внешним системам работать с документами, справочниками, регистрами, задачами и бизнес-процессами через HTTP и OData. Однако наличие интерфейса не определяет бизнес-правила. Команда всё равно должна решить, можно ли создавать документ извне, требуется ли его проведение, кто меняет статус и какие проверки выполняются до записи.
Для HTTP API удобно поддерживать машиночитаемое описание. OpenAPI задаёт независимый от языка формат, в котором можно определить операции, параметры, структуры запросов, ответы и требования безопасности. Такой контракт не отменяет бизнес-часть ТЗ, но делает техническую границу проверяемой.
Нефункциональные требования должны иметь меру
«Система должна быть быстрой, надёжной и безопасной» — пожелание, а не критерий. Нужна измеримая или хотя бы однозначно наблюдаемая формулировка. Например: список открывается с пагинацией и не загружает все записи; при недоступности 1С запрос сохраняется для повторной обработки; действия с финансовым документом попадают в неизменяемую историю; резервное восстановление проверяется по регламенту.
В зависимости от процесса уточняют:
— ожидаемую нагрузку и объём данных;
— допустимую задержку интерфейса и обмена;
— требования к доступности и восстановлению;
— срок хранения истории и вложений;
— аутентификацию, роли и аудит;
— поддерживаемые устройства и браузеры;
— правила экспорта, обезличивания и удаления данных;
— мониторинг интеграций и уведомление об ошибках.
Не стоит подставлять универсальные цифры. Показатель выводят из работы компании: сколько пользователей действует одновременно, какая задержка мешает операции, какие данные нельзя потерять и сколько времени допустим простой.
Критерий приёмки описывает наблюдаемое поведение
К каждому существенному требованию нужен способ проверки. Удобный формат: исходные условия, действие, ожидаемый результат и подтверждение в истории. Это превращает обсуждение «работает или не работает» в конкретный тест.
Слабая формулировка Проверяемый критерий
————————- ————————————————————————————————————————-
Есть разграничение прав Менеджер подразделения видит свои заказы, не получает чужие через интерфейс, API и экспорт
CRM связана с 1С После согласования CRM передаёт одну версию документа, сохраняет идентификатор 1С и показывает подтверждённый результат
Есть история Для смены суммы сохраняются старое и новое значения, автор, время и основание изменения
Обрабатываются ошибки Неуспешный обмен получает понятный статус, причину, число попыток и доступное ответственному действие
Приёмка должна включать не только основной маршрут, но и права, повторы, отмены, неполные данные и недоступность внешнего сервиса. Если критерий нельзя воспроизвести, требование следует уточнить до разработки.
Как собрать первую версию ТЗ без лишней документации
Для старта достаточно связанного комплекта из нескольких материалов: контекстная схема систем, описание выбранного процесса, словарь сущностей, матрица ролей, таблица состояний, перечень интеграционных контрактов и набор критериев приёмки. Они должны использовать одинаковые термины и идентификаторы требований.
1. Выбрать один сквозной процесс и обозначить его начало и конец.
2. Провести интервью с исполнителями и проверить описание на реальных документах.
3. Зафиксировать текущий маршрут, исключения и ручные обходы.
4. Спроектировать целевой маршрут и распределить ответственность систем.
5. Описать сущности, роли, состояния и интеграционные события.
6. Согласовать ограничения первой версии и то, что сознательно отложено.
7. Написать критерии приёмки до оценки и разработки.
Такое ТЗ помогает и при индивидуальной системе, и при доработке готовой платформы. Оно позволяет сравнить решения по способности поддержать процесс, а не по количеству пунктов в презентации. Если сначала нужно определить, какой процесс брать в работу, полезна отдельная методика выбора процесса для автоматизации (https://synchroweb.ru/blog/kakie-processy-avtomatizirovat-pervymi/).
Что проверить перед передачей документа в разработку
— У проекта есть конкретный бизнес-результат и владелец решения.
— Граница CRM, ERP, 1С и внешних сервисов показана явно.
— Для ключевых данных назначен единственный источник истины.
— Роли описаны через разрешённые действия и ограничения.
— Сущности не подменены списком экранов и полей.
— Для статусов определены условия входа, выхода и отмены.
— Основные исключения и ручной разбор включены в процесс.
— Интеграции имеют операции, идентификаторы и форматы ошибок.
— Нефункциональные требования можно проверить.
— Каждый приоритетный сценарий имеет критерий приёмки.
Техническое задание не должно угадывать все будущие изменения компании. Его ценность в другом: участники одинаково понимают первую границу системы, знают, где принимаются решения, и могут доказать, что реализованный процесс соответствует согласованным правилам.
Как управлять открытыми вопросами и изменениями
Не все решения удаётся принять до начала проекта. Это нормально, если неизвестность названа и имеет владельца. Открытый вопрос записывают отдельно: что именно не определено, на какие требования влияет, кто должен принять решение, какие варианты рассматриваются и без какого ответа нельзя продолжать связанную часть разработки. Формулировка «уточнить позднее» без ответственного лишь переносит спор на более дорогой этап.
Согласованные изменения тоже нужно отделять от исходного ТЗ. Для изменения фиксируют причину, затронутые процессы, данные, интеграции, критерии приёмки и влияние на уже реализованное поведение. Новое пожелание может выглядеть локальным — например, добавить ещё один статус, — но потребовать изменения отчётов, уведомлений, прав и обмена с 1С. Оценивать следует весь маршрут, а не только элемент интерфейса.
Полезна простая трассировка: требование связано с бизнес-целью, сценарием, макетом или правилом данных и проверкой приёмки. Тогда при изменении видно, что нужно пересмотреть, а при тестировании — зачем существует конкретное поведение. Такая связь не требует сложной системы управления документами; для небольшого проекта достаточно устойчивых номеров требований и актуальной таблицы решений.
Версию ТЗ, переданную в разработку, фиксируют. Рабочие комментарии не должны незаметно менять согласованную основу. Иначе команда реализует разные редакции, а приёмка будет сравнивать результат с требованиями, которых не существовало на момент оценки.
Источники
— ISO: ISO/IEC/IEEE 29148:2018 — Requirements engineering (https://www.iso.org/standard/72089.html)
— Object Management Group: спецификация BPMN 2.0.2 (https://www.omg.org/spec/BPMN/2.0.2/)
— 1С:Предприятие: официальный REST-интерфейс платформы (https://v8.1c.ru/platforma/rest-interfeys/)
— OpenAPI Initiative: актуальная спецификация OpenAPI (https://spec.openapis.org/oas/latest.html)
— OWASP: Application Security Verification Standard (https://owasp.org/www-project-application-security-verification-standard/)