Карта метрик продаж (дерево + покрытие)

Карта метрик продаж ITECH (Grace)

Дерево показателей системы управления продажами Баранова, разложенное до операционных драйверов и сшитое с реальными полями itech_*. Каждая метрика помечена покрытием — где данных нет, написано честно «нет источника», чтобы дашборд не врал. Ось всей модели = продажа часов (план меряется в нормо-часах; рубли и маржа производны). Проверено на 89, 2026-06-20.

Как читать

Формат строки: метрика → формула → тип → уровень → владелец → источник itech_* → покрытие.

L0 — вершина бизнес-плана (результаты Баранова)

Метрика Формула Тип Владелец Источник itech_* Покрытие
Годовой оборот, руб. Σ order_amount по реализованным Р ПРО+ИСП orders.order_amount ✅ есть
Выработка нормо-часов (ось плана) Σ total_hours_fact (план: total_hours_plan) Р ИСП orders.total_hours_* 🟡 present 100%, содержательно (часы>0) 43% = 1996 заказов-производство; Товары/Услуги=0. Σ=789 289 ч
Маржинальная прибыль чистая, руб. Σ margin_amount Р ПРО+ИСП orders.margin_amount ✅ 100% (реальна с 2024)
Маржинальность чистая, % Σ margin_amount / Σ order_amount Р ПРО orders ✅ есть (2024+)
Кол-во проектов, шт. count(distinct project_id) Р ПРО projects ✅ есть

L1 — декомпозиция результата

Метрика Формула Тип Уров. Владелец Источник Покрытие
⭐ Маржа на нормо-час margin_amount / total_hours_fact Р L1 ИСП orders 🟡 только заказы с часами>0 (1996); у Товаров не определена (0 часов)
Оборот по линиям (НКУ/СН/Товары/Услуги) Σ order_amount по ТипСчёта+вольтаж Р L1 ПРО order_items / линия 🟡 классиф. линии в items
Средний чек оборот / кол-во сделок Р L1 ПРО orders ✅ есть
Кол-во закрытых сделок count(status='Закрытие сделки') Р L1 ПРО projects.status ✅ срез / 🟡 динамика
Структура затрат (ПерЗ/ПостЗ/Трасх) В − margin; ПостЗ = часы×Сп Р L1 ИСП orders.total_cost 🟡 агрегат, без разбивки
Маржа по объекту Σ margin ⋈ properties Р L1 ПРО projects.property_id→properties 🟡 объект 79%
Маржа по отрасли/типу объекта Σ margin ⋈ sector/property_type Р L1 ПРО properties.sector + property_type 🟡 sector 35%; property_type гранулярнее (тип здания, нужен .keyword)
Маржа по региону объекта (доставка) Σ margin ⋈ регион из адреса Р L1 ПРО properties.address_full (парсинг) 🟡 адрес 99.8%, регион парсится (поле region пусто)
Маржа по отрасли/региону клиента Σ margin по обогащённому ИНН Р L1 ПРО ИНН-обогащение (внешн.) ❌ Grace пусто → строим (см. ниже)

L2 — драйверы воронки (leading) по владельцам

ПРЕ — Прескрипция (посев на стадии проектирования)

Метрика Формула Тип Источник Покрытие
Кол-во регистраций (вход воронки) count(projects, type='Прескрипция') по created_at Д projects (type_of_calculation) 🟡 тип заполнен ~50%
Кол-во объектов в проработке count(distinct property_id) в прескрипции Д projects.property_id→properties 🟡 объект 79%
Конверсия Регистрация→Работа П→Р→Выполнено переходы по стадиям прескрипции Д projects.status + снапшот ❌ переходы не датированы (status_updated_at 53% пуст)
Повторные посевы на объект объект с >1 проектом во времени Д граф properties.accounts 🟡 (через объект)

РАС — Расчёты / подготовка КП

Метрика Формула Тип Источник Покрытие
Кол-во подготовленных КП count(status='Отправлено КП') Д projects.status 🟡 срез есть, поток — нет
SLA расчёта (норматив 8ч/заявка) kp_exposed_at − created_at Д itech_calculations (21065: created_at, kp_exposed_at, start/completed/due) 🟡 индекс есть (live API заблокирован, но данные синкнуты)
Цикл расчёта / в срок completed_at − start_fact; vs due_date Д itech_calculations 🟡 индекс есть
Очередь расчётов / WIP кол-во «в расчёте» на дату Д itech_calculations.status + снапшот 🟡 через снапшот
Точность маржи (факт vs расчёт) orders.margin − calc.amount по project_id Д orders ⋈ itech_calculations 🟡 обе части есть (calc.amount синкнут)
Загрузка инженеров (часы факт) Σ time тайм-трекинг / норму Д engineer_worklog (открыт, LEV-147) 🟡 источник открыт, не в витрине

ПРО — Продажи / коммерция

Метрика Формула Тип Источник Покрытие
Кол-во отправленных КП count(status='Отправлено КП') Д projects.status 🟡 срез / поток нужен снапшот
Win-rate (внешний тендер) закрыто / (закрыто+проиграно) по терминалам Д projects.status + type 🟡 терминалы есть, датировка слабая
Win-rate (внутренний тендер) то же по внутр. воронке Д projects.status + type 🟡 то же
Конверсия КП→Согласование→Закрытие переходы стадий Д projects.status + снапшот ❌ переходы не датированы
Цикл сделки (дни) cycle_time_days Д orders.cycle_time_days 🟡 есть в заказах
Активность / событийный поток по сделке count(comments) по автору/сущности/периоду; дней с последнего касания Д itech_comments (120k: автор+дата+текст) 🟡 derived (reminders пуст, но comments живые и растут)
Соблюдение маржинальности (анти-демпинг) цена↑ при рентабельности↓ Д orders + order_items 🟡 считается из факта

ИСП — Исполнение / производство

Метрика Формула Тип Источник Покрытие
Выполнение плана по часам total_hours_fact / total_hours_plan Р/Д orders.total_hours_* 🟡 план 62% / факт 43%
Маржа факт (по реализации) margin_amount на отгрузке Р orders.margin_amount, shipping_date_fact ✅ 100%
Цикл производства cycle_time_days / status_production_id Д orders 🟡 есть
Часы по линиям (НКУ/СН/Товары/Услуги) Σ hours по линии Д order_items + норматив часов 🟡 норматив артикулов

Клиентская база и приток (⚠️ карточки ≠ клиенты)

Проверено на 89: всего карточек контрагентов 7643, из них покупателей (order_count>0) — 751 (10%), лидов без заказов — 6892 (90%); активных (last_order_at ≥ 2025) — 290. Дата создания карточки не годится как приток: 2020 = 3203 карточки (дамп миграции, не привлечение) + 90% карточек мёртвые.

Метрика Формула Тип Уров. Владелец Источник Покрытие
⭐ Приток новых покупателей / период контрагент с первым заказом в периоде = min(orders.created_at) по account_id Д L1 ПРО orders.account_id+created_at (витрина) 🟡 считается в витрине (НЕ accounts.created_at)
Активная клиентская база count(accounts, last_order_at ≥ окно) Р L1 ПРО accounts.last_order_at, order_count ✅ (290 с 2025)
Конверсия лид→покупатель покупатели / всего карточек Д L2 ПРО accounts.order_count ✅ (751/7643 ≈ 10%)
Отток / спящие был заказ, но last_order_at вне окна Д L2 ПРО accounts.last_order_at ✅
Концентрация выручки на клиенте доля топ-клиента; ≥15% = зависимость Д L2 ПРО accounts.revenue_mln ✅
❌ «Новые карточки / период» count(accounts) by created_at — — — accounts.created_at ❌ не использовать как приток (дамп 2020 + 90% без заказов)

Портрет покупателя + обогащение по ИНН

Проверено на 89 (покупатели, 751): у клиентов sectors (отрасль) и region ПУСТЫ, но inn есть у 100%. → отрасль и регион клиента не из Grace, а обогащением по ИНН из внешнего реестра (Dadata/ЕГРЮЛ/ФНС-открытые/Контур.Фокус). Это параллельный трек ELT-«дообогащения» (живёт в слое нормализации ArangoDB на 147), не блокирует витрину.

Две разные оси — не путать: объект (properties: sector/property_type building-derived + регион из address_full, ~100% адресов) = «куда/во что продаём»; клиент (ОКВЭД/регион по ИНН) = «кому продаём». Сектор Grace проставляет по зданию (property_type → sector).

Признак портрета Источник Покрытие
Роль контрагента (Покупатель/Поставщик/Субподряд/Проектировщик) accounts.account_types ✅ (роли пересекаются)
Надёжность accounts.reliability 🟡 ~30% (227/751)
Выручка / оплачено / долг accounts.revenue_mln/paid_mln/debt_mln ✅
Заказы/проекты, последний заказ accounts.order_count/project_count/last_order_at ✅
Только предоплата accounts.is_prepayment_only ✅
⭐ Отрасль клиента (ОКВЭД) ❌ Grace пусто → ИНН-обогащение строим
⭐ Регион/город клиента ❌ Grace пусто (region пуст) → ИНН-обогащение строим
Размер (МСП/крупный), статус (действ./ликвид.), дата регистрации ИНН-обогащение строим
Отрасль/тип объекта (куда продаём) properties.sector + property_type (building-derived) 🟡 sector 35%; тип здания гранулярнее
Регион/город объекта (доставка) properties.address_full (парсинг) 🟡 адрес 99.8%; регион парсится

Портрет = (роль + надёжность + платёжная дисциплина из Grace) × (отрасль + регион + размер из ИНН) × (отрасль объекта). Под сегментацию, таргетинг допродаж и оценку нового лида ещё до сделки.

Слой комментариев (itech_comments, 120k) — качественный + активность

Отдельный индекс, полиморфный (commentable_type + commentable_id); у каждого комментария: comment (текст, ru-анализатор), author_name, created_at, денормализованы project_id/project_status/account_id/calculation_id. Растёт: 2023=16k → 2024=36k → 2025=53k (живой, в отличие от пустого reminders).

Привязка (топ): SupplyRequest 22k · PaymentRequest 15k · Delivery 11k · Contract 7.5k · ContractAnnex 6.4k · Project 6407 · ComponentDefect 6.2k · Problem 5.8k · Calculation 4347 · Account 2446 · Order 2259 · Task 2112; объекты: Property 107 + ObjectRegistration 264.

Что даёт Как Тип Покрытие
Активность/застой сделки объём комментов + дней с последнего касания по проекту/расчёту Д 🟡 derived (заменяет пустой reminders)
Нарратив воронки (возражения/блокеры/причины) NLP по Project+Calculation коммент. + projects.refusal_reason Д 🟡 derived (NLP)
Качество/рекламации коммент. ComponentDefect/Problem/Reclamation Д 🟡 derived
История сделки для агентов RAG/граф по коммент. (Onyx) — вход для агентов

⚠️ commentable_type именуется непоследовательно (Property vs Modules\Projects\Entities\Project) → нормализация типа (трек Arango). Комментарии не агрегируются как метрики напрямую — это производный слой: витрина берёт счётчики/скорость/NLP-метки, граф — события таймлайна, Onyx — RAG.

Модель «объект → проект» (корень и счётчики притока)

Порядок ввода в Grace: сначала объект (property), потом проект (цепляется через property_id), далее расчёт → заказ. Объект — корень модели и центральное измерение витрины/графа. itech_object_registrations (445) — мост регистрации.

Отсюда три раздельных счётчика притока (не путать): новые объекты (properties.created_at) · новые проекты (projects.created_year) · новые покупатели (первый заказ, min(orders.created_at) по account_id).

Финансовый слой / ДДС (itech_expected_payments, 7896 — из 1С)

Платёжный календарь и факт поступлений, грузится в Grace из 1С → бухгалтерский факт, не CRM-оценка. Поля: exp_payment_status (план/факт), type (Предоплата/После отгрузки/…), pay_amount (план) / paid_amount (факт), pay_date / paid_date, привязка order_id/project_id (88%)/account_id/manager_id. Факт = 7776 (Σ оплачено 12,19 млрд, реализация плана 99,2%); даты 2020→2027.

Метрика Формула Тип Владелец Источник Покрытие
Поступления (ДДС-факт) Σ paid_amount по paid_date Р ИСП/фин expected_payments (status=факт) ✅ 7776
Дисциплина оплат (в срок) paid_date − pay_date; доля просрочки Д ПРО/фин expected_payments ✅
Предоплата vs постоплата (оборот. капитал) доля type=Предоплата vs «После отгрузки» Д ПРО expected_payments.type ✅
Дебиторка / ожидаемые поступления Σ pay_amount где не оплачено Р фин expected_payments (status=план) + accounts.debt_mln 🟡 план тонкий (120)
Форвард платёжный календарь Σ pay_amount по будущим pay_date Д фин expected_payments 🟡 будущих лишь 36 (план почти не ведётся)
Мост маржа→кэш paid_amount ⋈ orders.margin_amount по order_id Р фин expected_payments⋈orders ✅ связь есть

Закрывает «cashFlowAnalysis» из Grace UI на уровне витрины + даёт то, чего нет в orders: реальные поступления и дисциплину оплат.

L3 — коэффициенты и нормативы (из Положения о премии / методики)

Показатель Формула Тип Владелец Источник Покрытие
Кк — качество данных доля корректно заполненных полей К все itech_quality_managers (есть, Кк≈69.7%) ✅ есть
Ку — коэф. участия по стадии норматив по стадии воронки К ПРО Положение о премии §2.x ✅ норматив (не из данных)
Сп — ставка нормо-часа (3250/3660/4170) норматив грейда К ИСП Положение о премии §2.2 ✅ норматив
Утилизация инженеров часы факт / доступный фонд К ИСП engineer_worklog + штат 🟡 фонд не в витрине
Премия П [Σ((Пр×Ку) − КРр)] × Кк К ПРО производная всех выше 🟡 собирается из частей

Сводка покрытия (что сразу, что закрыть)

Считаем сегодня (✅/🟡): оборот, маржа (сумма и %), маржа/час, средний чек, кол-во сделок, win-rate (как срез), цикл сделки, выполнение плана по часам, срезы по объекту/региону/линии, Кк. → этого достаточно для дашборда «план/факт по часам + рентабельность» v1.

Дыры → не выдумывать, закрыть инструментом (❌):

  1. Поток воронки (конверсии, скорость стадий) — status_updated_at пуст 53%, переходы не датированы → лечится датированным снапшотом в ETL (см. LEV-171 шаг 3). Частично восстановимо из itech_comments (датированные события активности по сделке).
  2. SLA расчёта / WIP / точность маржи → ЗАКРЫТО индексом itech_calculations (21065: created_at/kp_exposed_at/completed_at/due_date/amount). Live API заблокирован (LEV-147), но данные синкнуты → SLA, цикл, WIP (через снапшот), точность маржи считаются.
  3. Активность менеджера — itech_reminders пуст, НО itech_comments (120k, автор+дата) даёт активность-прокси и «застой сделки» → дыра закрывается комментариями (derived), не пустым reminders.

Принцип карты: дашборд показывает только метрики с покрытием ✅/🟡; ❌-метрики выводятся как «требует данных X» — белые пятна видны, не маскируются нулём.

Refs: LEV-171 (витрина часов), LEV-169 (3 воронки), LEV-147 (часы/calc API), Положение о премии (BookStack, полка HR), Бизнес-план itech_1/docs/input/Бизнес план с формулами.xlsx, Стрелкова docs/Strelkova/generatory_pribyli.md.

Revision #7
Created 2026-06-20 07:16:43 UTC by Claude Ops
Updated 2026-06-20 09:16:11 UTC by Claude Ops