Типовая функциональность класса SPM, не описанная в ТЗ
Предметный gap-анализ (без инфраструктуры и обвязки) · 22.07.2026
Прототип и ТЗ покрывают ядро Sales Performance Management: расчёт мотивации (ICM),
планирование, автозадачи, витрины сотрудника. Ниже — предметная функциональность,
типовая для систем этого класса (Varicent, SAP Commissions, Oracle SPM, Xactly,
отраслевые SFA), которая в ТЗ не описана.
Важно: «не описана в ТЗ» ≠ «отсутствует у заказчика» — часть наверняка закрыта
действующими системами или регламентами. Смысл списка — пройтись по нему на встрече
и по каждому пункту явно решить: «уже есть там-то / берём в scope / осознанно не нужно».
Инфраструктура и обвязка (авторизация, интеграции, уведомления и т.п.) в список
намеренно не включены — это вопросы внедрения, а не класса системы.
Приоритеты — предложение для обсуждения: MVP — влияет на корректность расчёта
мотивации с первого месяца; Фаза 2 — ценно при масштабировании; Обсудить —
зависит от процессов заказчика.
1. Расчёт вознаграждения (ICM-ядро)
| Функция | Что это | Зачем | Приоритет |
| Закрытие расчётного периода | Workflow «расчёт → проверка → утверждение → выплата»; после закрытия месяца суммы зафиксированы | В ТЗ расчёт «ежедневно, автоматически», но не описано, в какой момент и кем сумма фиксируется как основание для выплаты. Уточнить, как это устроено сейчас | MVP |
| Расчёт по правилам своего периода | Версии шкал KPI: месяц считается по шкале, действовавшей в этом месяце; история изменений коэффициентов | Шкалы в ТЗ редактируются (Рис. 13). Не описано, что происходит с расчётом, если коэффициент изменили в середине месяца — а это первый источник споров о бонусе | MVP |
| Ретро-корректировки (clawback) | Перерасчёт бонуса, если возврат товара оформлен после закрытия месяца; удержание из следующего периода | Формула ТЗ вычитает возвраты внутри месяца. Судьба возврата, пришедшего за прошлый (уже выплаченный) месяц, в ТЗ не описана | MVP |
| Диспуты по начислениям | Сотрудник оспаривает расчёт в системе; спор идёт по маршруту с фиксацией решения | Прозрачность мотивации — заявленная цель проекта; формальный канал возражений её завершает | Фаза 2 |
| What-if моделирование схем | Прогон новой схемы мотивации на исторических данных до включения («порог 107% вместо 105% — премиальный фонд изменится на X») | Руководство по ТЗ может менять шкалы — полезно видеть последствия до, а не после | Фаза 2 |
| Командные / каскадные бонусы | Бонус руководителя от результата команды, каскадирование целей | В ТЗ у начальника отдела личный план. Если командная составляющая нужна — её надо закладывать в модель расчёта сейчас | Обсудить |
| Гарантии для новичков (draw) | Минимальный бонус на испытательный срок / сниженная квота на разгон | Новый менеджер с пустой базой по формуле ТЗ получит ноль — вопрос удержания на онбординге | Обсудить |
2. Планирование и территории
| Функция | Что это | Зачем | Приоритет |
| История закреплений Клиентов | Фиксация, за кем и в какой период был закреплён Клиент; правила передачи при ротации/отпуске/увольнении | Отгрузки в ТЗ считаются «по Клиентам, закреплённым за сотрудником». Не описано, чья отгрузка, если Клиента передали в середине месяца — а это прямо влияет на бонус | MVP |
| Согласование планов (top-down / bottom-up) | Менеджер видит проект плана, подтверждает или возражает; фиксация ознакомления | В ТЗ план формируется сверху; этап принятия плана сотрудником не описан | Фаза 2 |
| Сценарное планирование | Базовый / оптимистичный / пессимистичный варианты плана | Инструмент куратора при защите годовых целей | Обсудить |
| Автодекомпозиция сезонности | Разбивка годового плана по месяцам из исторической сезонности | Данные за 3 года в системе уже есть — можно не раскидывать вручную | Обсудить |
3. Работа с клиентской базой (SFA)
| Функция | Что это | Зачем | Приоритет |
| Правила против дублей в автозадачах | Автогенерация с учётом связей Клиентов внутри Контрагента и возможных дублей записей | ТЗ уже учитывает связку Контрагент→Клиенты в условиях задач. Стоит проговорить полный набор правил: по каким признакам два Клиента считаются одним, чтобы 9 типов автозадач не порождали дубли | MVP |
| Планирование визитов и маршрутов | Календарь выездов торг. представителя, маршрут на день, чек-ин у Клиента | В ТЗ есть фиксация путевых листов (факт); планирование выезда и связка «план → чек-ин → путевой лист» не описаны | Фаза 2 |
| Воронка сделок (pipeline) | Стадии сделки от интереса до отгрузки для проектных продаж | Для потокового опта может быть избыточно; для развития Клиентов групп A/B (расширение матрицы брендов) — полезно | Обсудить |
| Причины отказов / потерь | Классификатор «почему Клиент не купил / ушёл» при закрытии задач | Задачи ТЗ имеют статус «НЕ успешно» без причины. Причины — сырьё для аналитики оттока | Фаза 2 |
4. Аналитика эффективности продаж
| Функция | Что это | Зачем | Приоритет |
| Сводный дашборд руководителя | Агрегированная картина отдела/региона: тепловая карта выполнения, динамика ПДЗ, ABC-миграция Клиентов | В ТЗ аналитика построена вокруг сотрудника; агрегаты по отделу и региону руководителю придётся собирать из таблиц глазами | Фаза 2 |
| Проактивные алерты по показателям | Правила «план под угрозой / ПДЗ выросла / Клиент ушёл в блок» → сигнал руководителю | Автозадачи ТЗ реагируют на события Клиентов; сигналов по показателям сотрудников нет. Дополняет контур «здесь и сейчас» | Фаза 2 |
| Анализ эффективности схемы мотивации | Отчёт «мотивация ↔ результат»: корреляция бонусов с перевыполнением, распределение коэффициентов | Отвечает на вопрос руководства «работает ли наша схема» — стандартный отчёт SPM-систем | Обсудить |
5. Нематериальная мотивация (расширение раздела 5 ТЗ)
| Функция | Что это | Зачем | Приоритет |
| Индивидуальные цели вне плана продаж | Формализованные разовые цели (наставничество, проект) с весом в оценке | В ТЗ для этого есть только «входящая сумма» — ручное поле без правил; цели прозрачнее | Обсудить |
| Расширенная геймификация | Бейджи, уровни, командные соревнования поверх ТОП-10 | ТЗ закладывает рейтинг и призы; расширять стоит после того, как приживётся базовое | Обсудить |
Резюме для встречи с заказчиком
Пять предметных вопросов, которые стоит закрыть до фиксации scope MVP, потому что
они влияют на корректность расчёта мотивации с первого месяца:
Момент фиксации расчёта — когда суммы замораживаются для выплаты и кто утверждает.
Изменение шкал среди месяца — по каким правилам считается переходный период.
Возвраты после закрытия месяца — перерасчёт или списание в следующий период.
Передача Клиентов между сотрудниками — чья отгрузка в месяц передачи.
Правила уникальности Клиентов — чтобы автозадачи не дублировались.
Остальное — бэклог Фазы 2 и темы для обсуждения. По каждому пункту возможен ответ
«уже решено в текущих системах» — тогда фиксируем это в ТЗ как ограничение интеграции.