Компанія часто починає вибір CRM або ERP з таблиці на сотні функцій: картка клієнта, склад, звіти, інтеграції, мобільний доступ. Постачальники ставлять позначки «є», але після запуску з'ясовується, що замовлення проходить не за правилами бізнесу, залишки оновлюються із затримкою, а керівник не отримує потрібного рішення.
Причина в тому, що функція без сценарію нічого не гарантує. Технічне завдання має описувати, хто виконує дію, з якими даними, за яким правилом, що відбувається у винятку і який результат вважається правильним.
Від бізнес-болю до вимоги
| Слабке формулювання | Робоча вимога | Критерій приймання |
|---|---|---|
| Потрібен контроль заявок | Кожна заявка з сайту, телефону й месенджера створює запис із джерелом і відповідальним | Тестові звернення з трьох каналів з'явилися без дублювання |
| Потрібен склад | Менеджер бачить фізичний, зарезервований і доступний залишок за складом | Після резерву доступність зменшилася, фізичний залишок не змінився |
| Потрібні звіти | Власник бачить маржинальний дохід за товаром, клієнтом і каналом | Підсумок розкривається до вихідних замовлень і витрат |
| Потрібні права | Менеджер змінює лише свої угоди, керівник бачить відділ | Негативний тест підтвердив заборону чужих записів |
Таке формулювання дозволяє порівняти рішення й перевірити результат. Відповідь «у нас є складський модуль» уже недостатня.
Структура технічного завдання
- Мета проєкту. Які вимірювані проблеми потрібно зменшити: втрати заявок, помилки залишків, час підготовки звіту.
- Межі першого етапу. Які процеси входять у запуск, а які свідомо залишаються на потім.
- Ролі. Хто створює, погоджує, виконує, контролює й виправляє дані.
- Сценарії. Нормальний шлях операції та важливі винятки.
- Дані. Довідники, обов'язкові поля, джерела, власники якості й історія.
- Інтеграції. Яка система є джерелом істини та що відбувається при помилці обміну.
- Звіти й контроль. Яке рішення приймається за кожним показником.
- Критерії приймання. Конкретні тести, очікуваний результат і відповідальний.
Описуйте процес через події
Замість абстрактного «вести продажі» зафіксуйте послідовність: отримано звернення → перевірено дубль → призначено відповідального → уточнено потребу → сформовано пропозицію → зарезервовано товар → отримано оплату → створено відвантаження.
Для кожної події визначте вхід, результат і правило переходу. Якщо клієнт не пройшов кредитний ліміт або товару недостатньо, система не повинна мовчки рухати угоду далі.
| Елемент сценарію | Питання для ТЗ |
|---|---|
| Тригер | Яка подія запускає дію? |
| Власник | Хто відповідає за результат і строк? |
| Вхідні дані | Що має бути відомо до виконання? |
| Правило | За яких умов дія дозволена або заборонена? |
| Результат | Який документ, статус або рух створюється? |
| Виняток | Що робити, якщо даних немає або сервіс недоступний? |
Зафіксуйте джерело істини
Клієнти можуть існувати в CRM, товари — на сайті, залишки — в обліковій системі, а оплати — у банку. Для кожної сутності потрібно визначити власника: де запис створюється, де редагується й хто розв'язує конфлікт.
Якщо це не зробити, інтеграція створить двостороннє перезаписування: виправлена назва клієнта повернеться зі старої системи, а залишок буде різним у менеджера й на сайті.
Відокремте обов'язкове від бажаного
| Пріоритет | Значення | Приклад |
|---|---|---|
| Обов'язково для запуску | Без вимоги процес або контроль не працює | Унікальність номера замовлення та резерв товару |
| Потрібно на першому етапі | Дає основну користь, але має обхідний шлях | Автоматичне нагадування про прострочену оплату |
| Наступний етап | Розширює вже стабільний процес | Прогнозування повторної покупки |
| Не входить | Свідомо виключено з поточного проєкту | Повна заміна бухгалтерської системи |
Пріоритет не повинен означати «все критично». Якщо кожна вимога має найвищий рівень, команда не може зібрати керований перший запуск.
Критерій приймання сильніший за опис
Для ключових сценаріїв створіть набір тестових даних і очікуваний результат. Перевіряйте не лише позитивний шлях, а й дубль клієнта, недостатній залишок, скасування, повторне повідомлення інтеграції та заборонену дію ролі.
Фраза «працює коректно» не є критерієм. Має бути зрозуміло, який запис створився, який статус змінився, що потрапило в журнал і який підсумок показав звіт.
Типові помилки ТЗ
- копіювання функцій із рекламної презентації;
- опис тільки ідеального процесу без винятків;
- відсутність власника даних і правил дублів;
- спроба включити всі відділи в один запуск;
- змішування вимоги з конкретним дизайном кнопки;
- відсутність тестів і меж відповідальності.
Висновок
Технічне завдання на CRM/ERP повинно пов'язувати бізнес-мету, подію, роль, дані, правило, результат і перевірку. Тоді документ стає основою для оцінки, розробки, тестування й приймання, а не списком побажань.
Після узгодження вимог наступний ризик — перенесення старих дублів, помилкових довідників і невірних початкових залишків у нову систему. Переглянути ядро Business Reactor.
