FORUM-AUTO
Типовая функциональность класса 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 и темы для обсуждения. По каждому пункту возможен ответ

«уже решено в текущих системах» — тогда фиксируем это в ТЗ как ограничение интеграции.