Skip to main content

01 · Продажи (Управление продаж)

Аналитическая справка: Управление продаж ITECH

Дата: 2026-06-21 · Руководитель: Баранов Андрей Николаевич (Управляющий компанией / Зам. ген. директора, id 90) Источники (проверено по живым данным): Grace API (sales_requests, calculation_requests); витрина на сервере 89 (dim_employee, dim_department, fact_request, fact_communication, agg_comm_dept_pair).

Метод: контент-анализ — фактура ЧТО и КАК; причины (ПОЧЕМУ) — вне данных.


1. Резюме для руководителя

  • Управление продаж = начало воронки и второй по объёму коммуникатор компании: 17 активных, 22 777 комментариев (19% всего трафика Grace) силами 25 человек. Это твоё подразделение — справка про то, где у продаж рвётся на стыках с остальными.
  • ⚠️ Договоры с клиентами застревают у юристов: Юристы↔Сопровождение продаж — 834 треда, 331 застрявший (40%), 241 пинг-понг; Юристы↔Управление продаж — 274 / 110 (40%). Юротдел — общий тормоз: он же душит закупки (поставщики) и бухгалтерию (см. др. справки).
  • ⚠️ Продажи ждут расчёт цены от инженеров: линии с Отделом перспективных расчётов — 435 + 409 + 86 тредов, часть застревает 33–48%, много «длинных» (итеративный подбор КП). Это узел КП↔расчёт (муда этапа расчёта, LEV-151).
  • ⚠️ Согласования наверху буксуют: Администрация↔Управление продаж — 134 треда, 90 застрявших (67%); Администрация↔Сопровождение — 48%. Решения, уходящие на уровень руководства, подолгу висят.
  • Операционный вал несёт «Сопровождение продаж» (6 ассистентов) — 10 126 комментариев (~1 700/чел) = бэк-офис продаж, через который проходит вся рутина заявок/поставок/договоров.

2. Команда (17 активных)

id Подразделение Руководитель (по должности) Активных
90 Управление продаж Баранов А.Н. (Управляющий компанией) 7/8
91 Отдел продаж 1 Дроздов Д.Н. (Руководитель отдела) 4/6
95 Отдел по сопровождению продаж Первова П.С. (Руководитель отдела) 4/6
94 Отдел по работе с клиентами 2/2
6 / 30 Отдел продаж / Отдел продаж ОСН (легаси) 0/3, 0/3 (пусты)

Ключевые роли:

  • Управление продаж (90): Баранов А.Н. · Пересунько П.В. (Зам. ген. директора по развитию) · Гайсин, Горбунов (проектные продажи) · Филимонов (оборудование среднего напряжения) · Лисина (тендеры) · Иванова (продажи эл. оборудования).
  • Отдел продаж 1 (91): Дроздов (рук.) · Верещагин, Лукьянов, Тону (проектные продажи / среднее напряжение).
  • Работа с клиентами (94): Стегнина, Щербак.
  • Сопровождение продаж (95): Первова (рук.) + 3 ассистента менеджера (Левина, Перькова, Ткачук).

3. Чем КОНКРЕТНО заняты

Воронка продаж — заявки

В каноне видно активное окно: calculation 86 (продажи инициируют расчёты КП — начало воронки), sales 3, единичные payment/supply/accounting. Продажи запускают расчёт и ведут сделку до отгрузки.

О чём пишут (target_type, комментариев)

SupplyRequest 7522 (поставки под заказ) · Project 3775 (объекты/проекты) · Delivery 2535 (отгрузки) · Account 1481 (контрагенты) · ContractAnnex 1448 + Contract 1334 (договоры и допники) · Reminder 1357 (напоминания) · Calculation 645 · Contact 459 · Order 352 · Reclamation 205 (рекламации от клиентов). → Продажи ведут сделку «вдоль всей трубы»: КП → договор → поставка → отгрузка → постпродажа.


4. Как работают: коммуникация (19% трафика компании)

Объём по подразделениям (комм. / тредов / авторов):

Подразделение Комм. Тредов Авторов
Отдел по сопровождению продаж 10 126 4 892 6
Управление продаж 6 048 3 329 7
Отдел продаж 1 2 999 1 837 6
Отдел по работе с клиентами 1 841 1 423 2
Отдел продаж (легаси) 1 625 1 284 2

С кем (тредов / застряли >7д / % / пинг-понг):

Линия Тредов Застряли % П-понг
Юристы ↔ Сопровождение продаж 834 331 40% 241
Перспективные расчёты ↔ Сопровождение продаж 435 43 10% 93
Бухгалтерия ↔ Сопровождение продаж 420 148 35% 167
Перспективные расчёты ↔ Управление продаж 409 136 33% 144
Закупки ↔ Управление продаж 302 50 17% 124
Юристы ↔ Управление продаж 274 110 40% 95
Закупки ↔ Сопровождение продаж 234 87 37% 79
Администрация ↔ Управление продаж 134 90 67% 50
Разработка НКУ ↔ Управление продаж 117 63 54% 61
Администрация ↔ Сопровождение продаж 83 40 48% 41

→ Логистика/склад ↔ продажи идут гладко (1–6% застрявших). Рвётся на юристах (договоры с клиентами), инженерах-расчётчиках (цена/КП) и согласованиях с Администрацией (67%).


5. Сигналы для ЛПР (ЧТО — повод разобраться, не ПОЧЕМУ)

  1. Юротдел — сквозной тормоз сделки. Договоры с клиентами застревают на 40% (и пинг-понгуют). Тот же юротдел тормозит закупки и бухгалтерию → кандидат №1 на разбор по всей компании, не только в продажах.
  2. Цена/КП — узел между продажами и инженерами. Сотни тредов с Перспективными расчётами, застревания 33–48% + «длинные» итерации = прямое подтверждение муда этапа расчёта (LEV-151). Где теряется время между «запросил расчёт» и «получил цену»?
  3. Согласования наверху буксуют (Администрация↔Управление продаж 67%). Решения, уходящие на уровень руководства, висят — повод посмотреть, что именно ждёт согласования и сколько.
  4. Бэк-офис продаж — точка концентрации (Сопровождение, 6 ассистентов, 10k комментариев). Весь операционный вал сделки проходит через несколько человек = и узкое место, и кандидат на разгрузку инструментом.
  5. Постпродажа в продажах (Reclamation 205) — рекламации клиентов оседают здесь же; замыкается на сервис и качество.

Связь с целью (единый канал): продажи ведут сделку через комментарии к десяткам сущностей (КП, договор, поставка, отгрузка) и застревают на стыках с юристами/инженерами/руководством. Единый канал в Grace сделал бы видимым, на каком звене сделка «висит», и сократил пинг-понг между функциями.


6. Оговорки (честность данных)

  • Только канал Grace-комментов — звонки клиентам, почта, переговоры вне системы; реальная картина шире.
  • sales/calculation в каноне = активное окно, не вся история (ограничение API; история закрытых — только если API даст фильтр, не из MySQL).
  • Дублей карточек в юните не выявлено (17 активных = 17 уникальных). Легаси-отделы (6, 30) пусты.
  • Линия Администрация↔продажи: Администрация включает руководство (в т.ч. ЛПР) — трактовать как «согласования на верхнем уровне», адресно смотреть конкретные треды, не делать вывод о причине.
  • ПОЧЕМУ не выводим — причины застреваний за рамками данных (это «где смотреть», не диагноз).