Аналитика коммуникаций ITECH — карта потерь (LEV-187)

Коммуникационная модель ITECH из комментариев Grace (Лассуэлл+Холсти+lean-муда): где рвётся и на чём вязнет. 7 справок по отделам + сводная карта потерь. LEV-187.

00 · Сводная карта потерь

Сводная карта коммуникационных потерь ITECH — бриф для ЛПР

Дата: 2026-06-21 (слой 2 добавлен 2026-06-22) · Кому: Баранов А.Н. (ЛПР) · Источник: 120 573 комментария Grace → витрина 89 (fact_communication, agg_communication_thread, agg_comm_dept_pair); сверено с графом Arango 1:1. Метод: контент-анализ — ГДЕ рвётся + НА ЧЁМ вязнет (фактура ЧТО/КАК). Причины (ПОЧЕМУ) — за разбором людьми. Что это: карта потерь по всей компании + прототип того, что регулярно выносит AI-агент (нервная система).

1. Главное (один экран)

2. Узлы-горла (Парето — где сидит масса потерь)

Ранг отдела по сумме застрявших тредов по всем его линиям (тред считается у обоих концов линии):

# Отдел Тредов Застряли Пинг-понг
1 Отдел закупок 7 130 1 646 1 656
2 Юридический отдел 3 683 1 463 1 338
3 Бухгалтерия 3 353 1 077 1 125
4 Сопровождение продаж 3 425 899 1 010
5 Управление продаж 2 164 758 793
6 Администрация 1 377 683 535
7 Управление сервиса 1 513 665 575
8 Склад 2 713 578 778

→ Сфокусировать вмешательство на топ-3 (закупки–юристы–бухгалтерия) = снять бóльшую часть потерь.

3. Где рвётся — топ-линии (по массе застрявших)

Линия Тредов Застряли % Пинг-понг Контур
Бухгалтерия ↔ Юристы 806 381 47% 433 договоры
Склад ↔ Закупки 1 549 352 23% 329 снабжение (внутри)
Юристы ↔ Сопровождение продаж 834 331 40% 241 договоры с клиентами
Юристы ↔ Закупки 890 307 34% 233 договоры с поставщиками
Бухгалтерия ↔ Закупки 901 216 24% 183 платежи поставщикам
Бухгалтерия ↔ Сопровождение продаж 420 148 35% 167 счета/платежи
Перспективные расчёты ↔ Управление продаж 409 136 33% 144 цена/КП
ОТК ↔ Закупки 334 114 34% 124 приёмка/брак
Юристы ↔ Управление продаж 274 110 40% 95 договоры
Управление сервиса ↔ Отдел сервиса 151 86 57% 35 сервис (внутри)

Самые «глухие» по доле (объём ≥40 тредов): Администрация↔Разработка НКУ 81% · Администрация↔Отдел продаж 74% · Администрация↔Управление продаж 67% · Проектный↔Управление продаж 67% · Проектный↔Разработка НКУ 65% · Перспективные расчёты↔Работа с клиентами 60% · Управление сервиса↔Отдел сервиса 57%. → Два сгустка: верхние согласования (Администрация) и внутренняя координация инженерии.

4. На чём вязнут — по типу объекта

Объект переписки Тредов Застряли % Пинг-понг
Проект/объект 1 432 895 63% 69
Договор (Contract) 1 272 553 43% 433
Допсоглашение (ContractAnnex) 1 367 420 31% 210
Заявка на поставку (SupplyRequest) 4 187 379 9% 342
Контрагент (Account) 518 364 70% 2
Брак комплектующих (ComponentDefect) 968 335 35% 241
Заявка на закупку 1 216 291 24% 95
Рекламация 366 172 47% 35

По слою: объектные карточки — 43% застрявших (2 487), проблемы — 30% (721), заявки — лишь 11% (1 039).

→ Ключевой вывод: процессы с формальным статусом (заявки) текут, а всё, что висит на карточках объектов (проекты, договоры, контрагенты), застревает — там нет «движка», только переписка.

4b. На какую ТЕМУ вязнут — слой 2 (контент-кодирование, 22 916 комментов)

Каждый комментарий застрявших разговоров закодирован по «акту» (тип реплики) и «тону» (GLM-кодировщик по codebook; надёжность двойного кодирования C.R. акт 0.92 / тон 0.99). Среди 4 720 застрявших тредов трение оказалось разным по природе — три механизма, у каждого своё лечение:

Механизм трения Где концентрируется (доля застрявших тредов темы) Природа
Отказ / возврат на доработку Договоры 45%, Платежи 40%, Бухгалтерия 35%, Допсоглашения 26% договорно-финансовые циклы доработок «не согласовано → переделать»
Повторный вопрос Задачи 38%, Снабжение 23%, Заказы 22%, Закупки 15% информация не доходит с первого раза → переспрашивают (разрыв канала)
Жалоба / конфликт Рекламации 20% + 7% конфликт (max по компании), Брак комплектующих 16% качество — единственная по-настоящему горячая (конфликтная) зона

Фон по тону: 95.6% общения нейтрально, 4% напряжённо, 0.4% конфликтно. → Потери идут не от ссор, а от структуры (циклы доработок и переспросы); открытый конфликт локализован в рекламациях.

→ Вывод слоя 2: горло «договоры» (§3–4) вязнет на отказах-доработках, горло «снабжение» — на переспросах, рекламации — на жалобах. Одно лекарство на всех не работает (см. §6). Полная таблица тема×трение — отдельной страницей книги.

5. Слепые зоны (комментариев на человека, штат ≥5)

Подразделение Активных Комм/чел
г. Кострома Сборочный цех 31 2.0
г. Подольск Сборочный цех 51 42.8
Конструкторский отдел 6 45.3
(для контраста) Отдел закупок 6 5 520
(для контраста) Отдел логистики 5 1 315

→ Крупнейший коллектив (производство) почти не оставляет следа в Grace — координация цехов идёт мимо системы. Управлять можно только тем, что видно.

6. Что это значит для решения

Системная картина: компания координируется на межотдельных стыках, а потери концентрируются в трёх местах — (1) договорной контур (бухгалтерия–юристы–продажи), (2) снабжение (закупки–склад–ОТК), (3) верхние согласования (Администрация). Вязнет всё, у чего нет статус-машины (карточки объектов), и невидимо то, что происходит на производстве.

Лечение — разное по механизму (слой 2):

Аргумент за единый канал (Zulip-в-Grace), без FUD:

Что делает агент (прототип — этот бриф): регулярно ранжирует vital-few линий/узлов/объектов «где+на чём+масштаб» и выносит ЛПР решение-готовым списком; по запросу — ретро-бриф по любому отделу (скилл dept-brief). Слой 2 (готов) добавил «на какую ТЕМУ вязнут» — §4b.

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

00_1 · Слой 2 — карта «тема × трение»

Слой 2 — карта «тема × трение» (контент-кодирование застрявших разговоров)

Дата: 2026-06-22. LEV-187. Источник: GLM-кодирование 22 916 комментов застрявших разговоров (codes_stalled.json) × структура тредов (map_stalled.json) → el/rollup_l2.py. Кодировщик GLM-5-turbo по codebook sloy2_kodirovshchik_kommunikacii.md (reasoning OFF; гейт надёжности слоя 2: C.R. акт=0.917 / тон=0.992).

Что меряем: среди застрявших тредов — НА ЧЁМ именно вязнут, по оси «акт» (тип реплики) и «тон». «Трение%» = доля тредов с любым из E/F/G, либо T2, либо ≥3×T1, либо ≥2×B (повтор вопроса).

Распределение (коммент-уровень, 22 916)

Карта «тема × трение» (4720 застрявших тредов; топ по объёму)

Тема (target_type) тредов трение% отказ E% эск F% жал G% повтор B% конфл%
Project 896 21 16 1 3 3 1
Contract 553 48 45 2 3 7 2
ContractAnnex 420 30 26 1 1 8 1
SupplyRequest 379 34 12 2 6 23 2
Account 364 13 10 0 4 0 2
ComponentDefect 335 37 16 1 16 13 1
PurchaseRequest 291 29 13 1 4 15 1
Problem 214 19 11 1 4 5 0
Order 205 46 22 5 11 22 3
Reclamation 172 47 22 3 20 12 7
Reminder 161 21 5 2 14 1 1
Calculation 120 22 14 6 2 0 1
JuridicalRequest 89 31 18 0 7 9 1
Task 78 51 22 4 8 38 5
ServiceDepRequest 75 20 17 0 5 1 0
AccountingRequest 43 40 35 0 2 7 2
PaymentRequest 42 48 40 10 7 5 2
ActionPlan 40 38 32 0 2 8 2
DigitalRequest 30 27 17 0 7 10 0

Хвост малых N (флаг, но не вес): Item 28/68%, WarehouseRequest 15/67%, ServicesRequest 13/54%, SalesRequest 5/80%, OutgoingDocument 2/100%.

Ключевой инсайт слоя 2: трение РАЗНОЕ по природе

Слой 1 показал ГДЕ вязнет (объектные карточки). Слой 2 показал НА ЧЁМ — три разных механизма трения, разные лечения:

  1. Отказ/возврат (E) — договорно-финансовый контур. Concentrated: Contract 45%, PaymentRequest 40%, AccountingRequest 35%, ActionPlan 32%, ContractAnnex 26%. Это циклы «не согласовано → переделать»: договоры и деньги ходят по кругу доработок. Самый весомый: Contract 553 треда × 45% отказов.
  2. Повторный вопрос (B) — снабженческо-операционный контур. Concentrated: Task 38%, SupplyRequest 23%, Order 22%, PurchaseRequest 15%, ComponentDefect 13%. Информация не доходит с первого раза → переспрашивают. Разрыв канала, не конфликт.
  3. Жалоба/конфликт (G/T2) — качество. Concentrated: Reclamation 20% G + 7% конфликт (max), ComponentDefect 16% G. Рекламации и дефекты — единственная по-настоящему «горячая» (конфликтная) зона.

Для ЛПР (Баранов): vital-few горла из слоя 1 (Закупки/Юристы/Бухгалтерия) теперь имеют диагноз механизма — Договоры/деньги лечатся статус-машиной согласований (убрать E-циклы), Снабжение/заказы — единым каналом с историей (убрать B-повторы = headline-аргумент под Zulip-в-Grace), Рекламации — приоритетной эскалацией качества.

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. Резюме для руководителя

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

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

02 · Проектный (инженерный) отдел

Аналитическая справка: Проектный (инженерный) отдел ITECH

Дата: 2026-06-21 · Руководитель: Краснов Константин Сергеевич (Зам. операционного директора по проектированию и разработке, id 4) Источники (проверено по живым данным): Grace API (calculation_requests); витрина на сервере 89 (dim_employee, dim_department, fact_request, fact_communication, agg_comm_dept_pair). Метод: контент-анализ — фактура ЧТО и КАК; причины (ПОЧЕМУ) — вне данных.

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

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

id Подразделение Руководитель (по должности) Активных
77 Отдел перспективных расчётов и оценки себестоимости НКУ Халиков Р.Т. (Руководитель) 13/18
78 Отдел разработки и сопровождения производства НКУ Чесноков М.А. (Руководитель) 10/11
81 Отдел разработки и сопровождения производства РУСН и подстанций —¹ 4/6
4 Проектный отдел (головной) Краснов К.С. (Зам. опер. директора) 1/1
32, 33 Проектирование НКУ / РУ среднего напряжения (легаси) — 0/0 (пусты)

¹ У отдела РУСН (81) chief_user_id пуст — пробел оргструктуры; старший по должности — Никонов Д.М. (Старший инженер-проектировщик РУСН). Стоит проставить у клиента.

Состав: перспективные расчёты (77) — 10 инженеров-проектировщиков + старший инженер + тех. эксперт НН + Халиков; разработка НКУ (78) — схемотехники и инженеры НКУ (Молин, Семенов, Леонтьев, Шабашов и др.) + Чесноков; РУСН (81) — инженеры среднего напряжения, РЗА (Галкин, Ошарин, Коржев, Никонов).

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

Расчёт себестоимости и КП — calculation

Активное окно: calculation 121 (инженеры — исполнители расчётов под заявки продаж). По коммуникации Calculation — крупнейший тип (2 940 комментариев / 2 719 тредов) = расчёт цены изделия = сердцевина работы отдела перспективных расчётов (77).

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

Calculation 2940 · SupplyRequest 2195 (комплектация под изделие) · Project 1815 · Order 1529 (заказы) · Problem 1443 (проблемы конструктива/производства) · WorkDocDevelopment 46 + WorkingDocChange 27 (рабочая документация) · DigitalRequest 21. → Инженеры считают себестоимость, подбирают комплектацию, ведут рабочую документацию и разбирают проблемы изделий.

4. Как работают: коммуникация

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

Подразделение Комм. Тредов Авторов
Разработка НКУ (78) 4 012 2 612 11
Перспективные расчёты (77) 3 638 2 428 15
Проектный отдел (4, Краснов) 1 471 1 178 1
Разработка РУСН (81) 1 226 1 024 6

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

Линия Тредов Застряли %
Перспективные расчёты ↔ Сопровождение продаж 435 43 10% (236 длинных)
Перспективные расчёты ↔ Управление продаж 409 136 33%
Закупки ↔ Перспективные расчёты 393 30 8% (198 длинных)
Закупки ↔ Разработка НКУ 246 75 30%
Разработка НКУ ↔ Управление продаж 117 63 54%
Администрация ↔ Разработка НКУ 98 79 81%
Перспективные расчёты ↔ Отдел продаж 1 86 41 48%
Перспективные расчёты ↔ Работа с клиентами 77 46 60%
Проектный отдел ↔ Разработка НКУ (внутри) 69 45 65%
Проектный отдел ↔ Управление продаж 57 38 67%
Проектный отдел ↔ Перспективные расчёты (внутри) 47 25 53%
Администрация ↔ Перспективные расчёты 37 28 76%

→ Связки с закупками и сопровождением продаж по объёму большие, но застревают умеренно (хотя «длинные» — итеративный подбор комплектующих/цены). А вот внутренние линии инженерии и связки с Администрацией застревают экстремально (53–81%).

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

  1. Расчёт цены — горло воронки. Calculation = крупнейший поток отдела; сотни тредов с продажами застревают 33–60% и тянутся «длинными» итерациями. Это прямое числовое подтверждение муда этапа расчёта (LEV-151): где теряется время между запросом КП и выдачей цены.
  2. Координация ВНУТРИ инженерии рвётся сильнее, чем со смежниками (Проектный↔Разработка 65%, Проектный↔Расчёты 53%, между подразделениями 50–57%). Головной отдел и исполнители не смыкаются — узкое место в самой организации проектной работы.
  3. Согласования с руководством — экстремум застреваний (Администрация↔Разработка НКУ 81%, ↔Расчёты 76%). Инженерные вопросы, ушедшие наверх, висят дольше всего.
  4. Итеративный подбор комплектующих (Закупки↔Расчёты/Разработка — 198 «длинных» тредов) = много кругов «уточнили деталь → пересчитали». Кандидат на типизацию/нормирование.
  5. Проблемы изделий (Problem 1443) — крупный поток разбора конструктивных/производственных проблем, замкнутый на инженеров; пересекается с контуром брака из справки по производству.

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

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

03 · Операционная дирекция (снабжение)

Аналитическая справка: Операционная дирекция ITECH (снабжение · склад · логистика)

Дата: 2026-06-21 · Операционный директор: Хлопяникова Мария Игоревна (id 213, числится в Администрации) Источники (проверено по живым данным): Grace API (purchase_requests, supply_requests); OpenSearch-канон itech_services_requests (досинкан LEV-189); витрина на сервере 89 (dim_employee, dim_department, fact_request, fact_communication, agg_comm_dept_pair). Метод: контент-анализ — фактура ЧТО и КАК; причины (ПОЧЕМУ) — вне данных.

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

2. Команда (функциональный периметр дирекции, активных/всего)

id Подразделение Руководитель (по должности) Активных
35 Отдел закупок Корнилова Н.А. (Зам. опер. директора по закупкам) 6/15
14 Склад Карелкин В.В. (Начальник склада) 19/57
36 Отдел логистики Кулажко Н.М. (Ведущий спец. по логистике)¹ 5/7
31 Транспортный отдел — 1/2
103 г. Кострома Склад — (региональный) 8/9

¹ У Отдела логистики chief_user_id в Grace пуст — пробел в данных, не отсутствие руководителя (лид определяется по должности — Кулажко). Стоит проставить у клиента. То же по Транспортному.

Ключевые роли (активные):

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

Закупки и снабжение — purchase/supply (активное окно)

В каноне видно активное окно заявок: purchase 67 (статусы: «КП получено» 50, «Отправлен запрос» 14, «В работе» 2, «Новая» 1) + supply 26. Это срез открытых на сейчас — не вся история (ограничение API). Реальный масштаб операционной нагрузки виден в коммуникации (блок 4), где заявки на снабжение — крупнейший поток.

Хоз-услуги и услуги для заказов — services_requests (627 млн ₽)

4345 заявок, сумма 626,9 млн ₽, средняя ~144 тыс ₽. Категории: «Услуги для нужд компании» 2666 + «Услуги для выполнения заказов» 990. Статус почти всех — «КП получено» (4341/4345)². Распределение по подразделению-инициатору: Отдел логистики (36) — 2225 (51%), АХО (17) — 525, Кострома сборочный (2) — 520, Отдел продаж (6) — 204, Отдел закупок (35) — 183. Исполнители: Кулажко Н.М. 2107, Петрова К.В. 514, Гурьянова Е.А. 422. Динамика: 2024 → 1617, 2025 → 1991 (+23%), 2026 → 737 (за полгода). → поток хоз-услуг растёт и концентрируется в логистике на одном исполнителе.

Брак комплектующих и приёмка

По коммуникации (блок 4) видны крупные контуры: ComponentDefect 5466 комментариев (брак комплектующих), Delivery 7948 (поставки/отгрузки). Сами записи дефектов/поставок в OpenSearch-канон не синкаются — видны только через комментарии.

4. Как работают: коммуникация (позвоночник снабжения)

Объём (комментариев / тредов / авторов):

Отдел Комментариев Тредов Авторов
Отдел закупок 33 120 19 339 14
Отдел логистики 6 576 5 135 6
Склад 4 175 2 531 8

→ Закупки — самый активный отдел ITECH по объёму общения (33 тыс. комментариев на 14 человек).

О чём пишут (target_type, комментариев): SupplyRequest 11781 · PaymentRequest 9726 · Delivery 7948 · ComponentDefect 5466 · PurchaseRequest 3124 · Contract 1523 · ContractAnnex 1171 · AccountingRequest 391.

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

Линия Тредов Застряли % Длинных (≥6) Пинг-понг
Склад ↔ Закупки (внутри юнита) 1549 352 23% 653 329
Бухгалтерия ↔ Закупки 901 216 24% 193 183
Юридический ↔ Закупки 890 307 34% 266 233
Закупки ↔ Логистика (внутри юнита) 705 4 0.6% 20 16
Закупки ↔ Перспективные расчёты НКУ 393 30 8% 198 99
ОТК ↔ Закупки 334 114 34% 170 124
Закупки ↔ Управление продаж 302 50 17% 182 124
Закупки ↔ Отдел сервиса 289 33 11% 31 27
ОТК ↔ Склад 213 70 33% 134 110
Администрация ↔ Закупки 157 60 38% 78 75
Закупки ↔ Управление сервиса 137 61 45% 80 60

→ Картина: внутри снабжения (Закупки↔Логистика) поток идёт гладко (0.6% застрявших), а рвётся на стыках с обеспечивающими функциями — юристы (договоры с поставщиками), бухгалтерия (платежи), ОТК (приёмка/брак), сервис. Линия Закупки↔Перспективные расчёты — мало застреваний, но рекордно «длинная» (198 длинных тредов) = итеративный подбор цены/комплектации.

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

  1. Снабжение — узкое горло координации всей компании: 33 тыс. комментариев на 14 закупщиков. Любая пробуксовка на стыке закупок мультиплицируется на всю цепочку «заказ → производство». Вопрос: чем разгрузить ручную координацию?
  2. Застревания концентрируются на границах, а не внутри: Закупки↔Юристы 34%, ↔ОТК 34%, ↔Сервис 45%, ↔Бухгалтерия 24% — против 0.6% внутри юнита. Проблема системная — на хэндофф-стыках между функциями.
  3. Контур брака комплектующих (ComponentDefect 5466) замыкает закупки↔склад↔ОТК = переделки и рекламации к поставщикам; постзакупочный контроль качества требует ресурса трёх отделов.
  4. Поток хоз-услуг 627 млн ₽ держится на одном человеке (Кулажко — 48% заявок) и растёт (+23% год к году). Риск шины фактора + точка для автоматизации/типизации однотипных заявок.
  5. Внутренняя линия Склад↔Закупки — рекордный объём ручной координации (1549 тредов, 653 длинных, 329 пинг-понг). Приёмка/размещение ведётся «в комментариях» — кандидат на регламент/инструмент.

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

04 · Производство

Аналитическая справка: Производство ITECH (сборочные цеха · ОТК · техотдел)

Дата: 2026-06-21 · Руководители производства: Маринчу Н.Х. (Начальник производства, Подольск), Леваков Е.С. (Начальник производства, Кострома) · единого «директора по производству» в данных нет (верхний — ген. директор Виноградов). Источники (проверено по живым данным): Grace API (purchase_requests); витрина на сервере 89 (dim_employee, dim_department, fact_request, fact_communication, agg_comm_dept_pair). Метод: контент-анализ — фактура ЧТО и КАК; причины (ПОЧЕМУ) — вне данных.

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

2. Команда (производственный контур, активных/всего)

id Подразделение Руководитель (по должности) Активных
1 г. Подольск Сборочный цех Маринчу Н.Х. (Начальник производства) 51/153
2 г. Кострома Сборочный цех Леваков Е.С. (Начальник производства)¹ · Яблоков А.В. (мастер цеха) 31/50
5 Отдел технического контроля Гапон Д.А. (Начальник ОТК) 4/8
104 г. Кострома ОТК — 3/3
37 Технический отдел Шибаев С.А. (Начальник) 3/5
102 г. Кострома Технический отдел — 2/2
76 Электротехническая лаборатория Лукин А.В. (Руководитель) 1/1
22 Отдел строительно-монтажных работ — 0/14 (штат расформирован/перемещён)

¹ Леваков числится в «г. Кострома Администрация», но по должности — Начальник производства Костромы. chief_user_id у костромских подразделений и СМР пуст — пробел оргструктуры, не отсутствие руководителя (определять по должности). СМР: 0 активных при 14 в истории — отдел фактически расформирован, но исторический след в коммуникации остался (664 комментария).

Состав Подольск цеха (51): монтажники 2–6 разр. 34 · бригадиры 4 · мастера произв. обучения 3 · слесари 3 · электромонтажники 2 · разнорабочие 2 · мастер цеха · начальник производства · специалист ТМЦ. Кострома цех (31): монтажники 3–6 разр. 23 · бригадиры 4 · слесари 2 · мастер цеха · специалист ТМЦ.

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

Сборка НКУ (основная работа — в Grace почти не отражена)

Производственная работа цехов (сборка низковольтных комплектных устройств) ведётся «на полу» и в Grace фиксируется слабо. В Подольске пишут в основном бригадиры, мастера и часть монтажников (28 из 36 монтажников хоть раз оставляли комментарий, но объём низкий); в Костроме — почти никто. То есть ход сборки, передачи смен, проблемы на участках — вне системы.

Технический контроль — ОТК (активен)

ОТК — самый «громкий» в производственном контуре: 934 комментария на 8 человек. Завязан на приёмку закупленного и брак: ОТК↔Закупки 334 треда (34% застрявших), ОТК↔Склад 213 (33%). → постпоставочный контроль качества + разбор брака.

Техническая подготовка — Технический отдел

774 комментария на 3 человек (Шибаев + технолог + спец. по тех. документации). Связь с разработкой НКУ (97 тредов) и проектным отделом (45) — техническое сопровождение производства и документация.

Заявки (активное окно)

Производство — преимущественно исполнитель, а не автор заявок: в каноне видно purchase 68 (цеха/ОТК выступают получателем комплектующих) + единичные calculation/payment. Своего потока заявок производство почти не создаёт — его «голос» в системе это комментарии к чужим заявкам и к изделиям.

4. Как работают: коммуникация (производство = 4% трафика при 95 людях)

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

Подразделение Комм. Тредов Авторов Активных Комм/чел
г. Подольск Сборочный цех 2 184 1 505 47 51 ~43
Отдел технического контроля 934 763 8 4 ~234
Технический отдел 774 672 3 3 ~258
Отдел СМР (расформирован) 664 369 9 0 —
г. Кострома Технический отдел 198 149 1 2 ~99
г. Кострома Сборочный цех 61 53 5 31 ~2
г. Кострома ОТК 46 32 2 3 ~15
Электротехническая лаборатория 38 23 1 1 ~38

→ Контраст разительный: инженерные функции (ОТК, техотдел) пишут активно (~234–258 комм/чел), а цеха — почти молчат (Подольск ~43, Кострома ~2 комм/чел). Чем «ниже» к сборке — тем меньше Grace.

О чём пишет производство (target_type, комментариев): Изделия (Item) 1727 · PurchaseRequest 881 · Problem 843 · ComponentDefect 449 · SupplyRequest 171 · PaymentRequest 119 · Contract 98 · Delivery 83.

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

Линия Тредов Застряли %
ОТК ↔ Отдел закупок 334 114 34%
Подольск цех ↔ Отдел закупок 225 71 32%
ОТК ↔ Склад 213 70 33%
Технический отдел ↔ Разработка НКУ 97 8 8%
Подольск цех ↔ АХО 71 17 24%
Юридический ↔ СМР 65 27 42%
Администрация ↔ Технический отдел 37 37 **100%**²
ОТК ↔ Управление сервиса 33 25 76%

→ Производство, когда выходит в Grace, в основном выбивает материалы у закупок/склада (и там вязнет 32–34% = цех ждёт комплектующие) и гоняет брак через ОТК.

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

  1. Крупнейший коллектив компании — слепая зона. 95 производственников = 4% трафика Grace. Ход сборки, проблемы на участках, передача смен — система не видит. Управлять можно только тем, что видно.
  2. Кострома цех (31 чел) почти полностью вне Grace (61 комментарий). Региональная площадка координируется мимо системы — для руководства это «чёрный ящик».
  3. Цех ждёт материалы: линии цех/ОТК ↔ закупки/склад застревают на 32–34%. Простои сборки из-за некомплекта — кандидат №1 на разбор (где именно теряется время между «заявил деталь» и «получил»).
  4. Брак и проблемы (ComponentDefect 449 + Problem 843) замыкают производство↔ОТК↔закупки↔разработку — многосторонний контур, где легко потерять нить.
  5. Две точечные аномалии: Администрация↔Технический отдел — 100% тредов застряли (старый клуб проектов/ проблем, средний возраст ~1.5 года); ОТК↔Управление сервиса — 76%. Оба — повод посмотреть адресно.

Связь с целью (единый канал): производство — самое яркое доказательство, что коммуникация утекает из Grace. Там, где идёт реальное исполнение (сборка), системной переписки почти нет. Единый канал, вшитый в Grace, в первую очередь нужен именно цехам — чтобы ход производства стал видимым, а не реконструировался постфактум.

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

05 · Бухгалтерия и ОМК (СМК)

Аналитическая справка: Бухгалтерия и Отдел менеджмента качества (СМК)

Дата: 2026-06-21 · Главный бухгалтер: Третьякова Татьяна Валерьевна (id 11) · ОМК: Тимофеева Дарья Юрьевна (Главный специалист СМК по стандартизации и сертификации, id 16) Источники (проверено по живым данным): Grace API (accounting_requests, payment_requests, supply_requests); витрина на сервере 89 (dim_employee, dim_department, fact_request, fact_communication, agg_comm_dept_pair). Метод: контент-анализ — фактура ЧТО и КАК; причины (ПОЧЕМУ) — вне данных.

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

2. Команда

Бухгалтерия (id 11) — 9 активных

Должность Сотрудник
Главный бухгалтер Третьякова Татьяна Валерьевна
Заместитель главного бухгалтера Иванова Елена Александровна
Заместитель гл. бухгалтера по производству Галина Татьяна Владимировна
Старший бухгалтер Морозова Ольга Викторовна
Бухгалтер по банковским операциям Тюркина Анна Владимировна
Бухгалтер по расчёту заработной платы Пенкина Ольга Николаевна
Бухгалтер по работе с поставщиками Аккуратова Ирина Константиновна
Бухгалтер производства и учёту затрат Володина Валентина Владимировна
Бухгалтер Горлова Наталья Александровна

⚠️ Сверка с присланным списком: данные Grace показывают 9 активных — это твои 8 + Горлова Н.А. («Бухгалтер»), которой в присланном списке нет (либо недавно принята, либо страница оргструктуры не обновлена — стоит сверить у клиента). Карточка Володиной В.В. в Grace задвоена (две записи) — кандидат на чистку.

Отдел менеджмента качества — СМК (id 16) — 1 активный

Ещё 3 человека фигурируют в истории комментариев, но сейчас неактивны → отдел сжался до одного. СМК как служба представлена в системе одним специалистом.

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

Бухгалтерия — о чём пишет (target_type, комментариев)

AccountingRequest 2121 (учётные заявки) · PaymentRequest 1046 + PaymentRequestNew 857 (платежи) · Contract 931 + ContractAnnex 486 (договоры и допники) · Account 892 (контрагенты/счета) · SupplyRequest 243 · ServicesRequest 154 · ConsiderationRoute 131 (маршруты согласования) · StaffRequest 35. → Три кита: платежи, договоры, учётные заявки. Большой объём по договорам объясняет трение с юристами (блок 4).

Заявки (активное окно)

Бухгалтерия — преимущественно исполнитель/согласующий: в каноне supply 17, accounting 6, payment 3 (активное окно, не вся история — ограничение API).

ОМК (СМК) — о чём пишет

ActionPlan 190 (планы корректирующих/предупреждающих действий — ядро системы менеджмента качества) · PurchaseRequest 43 · PaymentRequest 26 · Contract 20 · Task 19. → Функция СМК в Grace = в основном ведение планов мероприятий; объём небольшой, замкнут на отдельные согласования.

4. Как работают: коммуникация

Объём: Бухгалтерия — 7 087 комментариев / 5 746 тредов / 12 авторов. ОМК — 363 / 293 / 4.

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

Линия Тредов Застряли % Пинг-понг Длинных
Бухгалтерия ↔ Юридический отдел 806 381 47% 433 412
Бухгалтерия ↔ Отдел закупок 901 216 24% 183 193
Бухгалтерия ↔ Сопровождение продаж 420 148 35% 167 171
Бухгалтерия ↔ Управление сервиса 178 51 29% 51 72
Администрация ↔ Бухгалтерия 147 32 22% 46 43
Бухгалтерия ↔ Управление продаж 126 46 37% 41 39
Бухгалтерия ↔ Отдел логистики 99 25 25% 21 20
Бухгалтерия ↔ Отдел продаж 1 38 30 79% 8 11
Бухгалтерия ↔ Отдел сервиса 102 4 4% 5 4

С кем ОМК: Управление сервиса 24 (9 застр.) · Юристы 21 · Цифровизация 20 (8 застр.) · Бухгалтерия 15.

→ Картина бухгалтерии: главный разрыв — на согласовании договоров с юристами (47% застряли + рекордный пинг-понг 433 = документ ходит туда-сюда). Второй контур — платежи поставщикам (через закупки) и сопровождение продаж. С исполнительным сервисом (108), наоборот, гладко (4%).

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

  1. Договоры застревают между Бухгалтерией и Юристами — самая больная линия компании (47% тредов застряли, 433 пинг-понга). Согласование договоров — главный кандидат на регламент/единый канал: где именно теряется время между «передал на согласование» и «подписано».
  2. Платежи поставщикам подвисают (↔Закупки 24%) — а это деньги и сроки поставок; завязано на тот же контур снабжения, что уже подсвечен в справке по опер.дирекции.
  3. Bus factor: банковские операции (Тюркина), зарплата (Пенкина), расчёты с поставщиками (Аккуратова), учёт производства (Володина) — по одному человеку на критичный участок. Риск при отпуске/уходе.
  4. Линия Бухгалтерия↔Продажи1 — 79% застрявших (объём мал, но доля экстремальна) — точечный завал, стоит посмотреть адресно.
  5. СМК держится на одном человеке. Система менеджмента качества (стандартизация, сертификация, корректирующие действия) представлена в Grace одним специалистом и минимальным следом — вопрос приоритета/ресурса функции качества.

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

06 · Управление сервиса и автоматики

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

Дата: 2026-06-21 · Руководитель управления: Сухарученков Никита Андреевич (id 107) Источники (проверено по живым данным): Grace API (service_dep_requests, acs_requests, statuses); OpenSearch-канон itech_services_requests (досинкан LEV-189); витрина (dim_employee, dim_department, fact_communication, agg_comm_dept_pair) на сервере 89. Метод: контент-анализ — фактура ЧТО и КАК; причины (ПОЧЕМУ) — вне данных.

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

2. Команда (дерево юнита, активных/всего)

id Подразделение Руководитель Активных
107 Управление сервиса и автоматики Сухарученков Н.А. (Руководитель) 2/3
12 Отдел АСУ Шагеров А.Е. (Руководитель АСУ ТП) 3/6
108 Отдел сервиса Масальский А.С. (Начальник произв. службы) 9/11
105 Отдел сервиса и автоматизации — 0/2 (пуст)

⚠️ В dim_department.chief_user_id у Отдела сервиса пусто — это пробел в данных, а не отсутствие начальника (руководитель определяется по должности — Масальский). Не делать вывод «без руководителя» из пустого поля.

Активный ростер (14) — должность · статус на 21.06:

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

Полевой сервис — service_dep_requests (8 активных)

Работы на объектах/проектах силами Отдела сервиса (исполнители — Семенюк, Куницын, Барташевич, Беленис, Фетисов, Глотов, Попов; привязка к проектам). Статусы: 6 «Приостановлено» + 2 «В работе». ⚠️ При этом 6 из 9 бригады сейчас в командировках/отпуске (до 22–28.06): командировка = выезд на объект (полевая работа), не простой. «Приостановлено» в Grace vs физический выезд — повод свериться (это ЧТО, а ПОЧЕМУ стоят — к разбору).

Автоматизация (АСУ) — acs_requests (9 активных)

Заявки на АСУ; исполнители — Печурин (4) и Шагеров (1). Статусы: в основном «Новый» (не начаты), 2 «В работе»; часть привязана к проектам. → бэклог АСУ почти не стартован, держится на Печурине.

Рекламации и дефекты (по коммуникации)

Самый плотный поток комментов — Reclamation 1430 + ComponentDefect 234 → юнит много работает с претензиями и дефектами (постпродажный/гарантийный контур). Записи рекламаций/дефектов в канон не синкаются (только комменты) — глубина по ним пока недоступна.

⚠️ Что НЕ относится к юниту: services_requests (627 млн ₽)

Общефирменный поток заявок на хоз-услуги/услуги для заказов (категории «Услуги для нужд компании» 2666, «Услуги для выполнения заказов» 990). Сумма 626,9 млн ₽, средняя 144,6 тыс ₽; почти все в статусе «КП получено» (4341/4345). Исполнитель — Кулажко Н.М. (2107, ~половина), Петрова, Гурьянова — это АХО/снабжение, не сервис-юнит. Поток растёт: 2024→1617, 2025→1991, 2026→737.

4. Как работают: коммуникация (7117 комментов / 3494 треда)

О чём: Reclamation 1430 · PaymentRequest 1062 · Tasks 1056 · ServiceDepRequest 474 · PurchaseRequest 427 · Project 370 · AcsRequest 300 · ComponentDefect 234 · ItProblem 214.

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

Линия Тредов Застряли
Управление ↔ Отдел сервиса (внутри!) 151 86 (57%)
Отдел закупок ↔ Отдел сервиса 289 33
Отдел цифровизации ↔ Управление 239 67
Бухгалтерия ↔ Управление 178 51
Отдел закупок ↔ Управление 137 61
Юридический отдел ↔ Управление 113 51
Администрация ↔ Управление 79 43

→ Сервис плотно завязан на Закупки (запчасти под рекламации/дефекты) и Бухгалтерию (платежи); застревания особенно высоки на внутренней линии и с закупками/юристами/администрацией.

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

  1. Внутренняя коммуникация юнита рвётся: Управление↔Отдел сервиса — 57% застрявших тредов. Рук-во и исполнители сервиса не смыкаются.
  2. Полевой сервис: 6 из 8 заявок «Приостановлено» — и при этом 6 из 9 бригады на командировках/отпуске. Стоят в Grace или работают на объекте? Свериться.
  3. АСУ держится на 1-2 людях (Печурин/Шагеров) и в основном «Новый» — узкое место/риск шины фактора.
  4. Бригада сервиса в разъездах: 6 из 9 электромонтажников в командировках/отпуске (до 22–28.06). Начальник — Масальский А.С. (Начальник произв. службы); в данных Grace его как chief отдела не проставлено (пробел оргструктуры — стоит поправить у клиента).
  5. Рекламации/дефекты — крупнейший поток общения; постпродажный контур требует Закупок и Бухгалтерии (где и застревает).

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

07 · Отдел цифровизации

Аналитическая справка: Отдел цифровизации ITECH

Дата: 2026-06-21 · Руководитель отдела: Калдарбеков Дмитрий Дуйсенбаевич (id 39, в компании с 2014) Источники (проверено по живым данным): Grace API digital_requests/get, statuses/get, importances/get, users/get; витрина ITECH (dim_employee, fact_communication, agg_comm_dept_pair) на сервере 89. Метод: контент-анализ — фактура ЧТО и КАК; причины (ПОЧЕМУ) — вне данных, требуют разбирательства с отделом.

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

2. Команда

Статус Кол-во Кто
Активны 8 Калдарбеков Д.Д. (рук.), Боликов Н.Н., Ганбаров Д.Г., Литвиненко А.Н., Моисеенко П.А., Музыка И.О. (нов. ~сент 2025), Рябов А.Ю., Сулим М.В.
Уволены/неактивны 8 Лесной Р., Цыпкин И., Мамедов А., Мадудин М., Денисов Е., Крянин В., Разумный Д., Гапон А.

⚠️ dim_employee по department_id включает уволенных — для численности фильтровать is_active (флаг есть на карточке сотрудника в графе и в dim_employee).

3. Чем занят отдел: бэклог (138 активных заявок)

Статусы (общий статус заявки)

Статус Кол-во Доля
Новый (не начат) 86 62%
В очереди 27 20%
В разработке 25 18%

Завершённых нет в выгрузке — эндпоинт отдаёт только активные. 138 = текущая нагрузка, не вся история.

Фазы — что реально в работе по потокам

Поток В разработке В очереди Завершено Не требуется Не назначен
Backend (основной) 18 6 8 14 92
Frontend 9 20 2 11 96
1С (onec) 2 11 0 26 99

→ Основная разработка — backend; 1С реально почти не идёт (всего 13 заявок задействуют 1С, в работе 2).

Важность (словарь Grace)

Важность Кол-во
Вопрос жизни и смерти (4) 41
Критически важно (3) 42
Очень важно (2) 35
Важно конечно (1) 20

→ 83 из 138 (60%) — топ-важность, но большинство при этом «Новый».

Динамика создания: 2023 → 3, 2024 → 41, 2025 → 64, 2026 → 30 (полгода). Поток ускоряется.

4. Темы работ (по названиям заявок)

  1. Аналитика / отчёты / дашборды — готовность заказов в срок (взвеш. по выручке), дашборд продаж, показатели отделов, анализ простоев, отчёты по отгрузке.
  2. Доработки Grace / CRM — контрагенты (создание ИП, проверка, синхронизация), условия оплаты, замечания к СРМ, статусы связанных клиентов.
  3. Модули под отделы — особенно ППР для сервисного отдела (разработка, оптимизация, фильтры, вкладка планирования); журнал несоответствий для субподряда.
  4. Мотивация / расчёты — премии монтажников и отдела продаж, плановые часы конструкторов.
  5. Производство / номенклатура — маркировка клемм и клеммников, ОКПД2 в номенклатуру, паспорта изделий, взаимосвязи заказов.
  6. Интеграция ERP / 1С — «Вывод данных из ЕРП», «Работы по интеграции ERP», нумерация договоров (небольшая доля).
  7. AI / уведомления — «AI помощник», «Оповещение в телеге для производства».

Кто ставит задачи (заказчики и авторы)

1С-исполнители

«A S» (id 1) — системный аккаунт-заглушка, не человек (фигурирует «исполнителем» 51 фазы, но 0 в работе — это дефолт при отсутствии назначения). Реальная 1С-работа — на внешнем Мокрецове Юрии (id 508: 9 заявок, 2 в разработке, 7 в очереди) + штатный Боликов (3, все в очереди, 0 в работе). Штатный Мадудин, касавшийся 1С, уволен. → 1С почти не двигается и держится на внеструктурном человеке.

5. Как отдел работает: коммуникация (1712 комментов в 1146 тредах)

О чём говорят (топ объектов): Tasks 662 · DigitalRequest 201 · Calculations 130 · PurchaseRequest 109 · Problem 100 · Contract 73 · платежи 135.

С кем (линии отдел↔отдел, тредов / из них застряли >7д):

Контрагент по коммуникации Тредов Застряли
Управление сервиса и автоматики 239 67
Бухгалтерия 60 14
Администрация 51 16
Юридический отдел 36 15
АХО 28 11
Отдел закупок 27 8
Проектный отдел 23 9
Отдел разработки НКУ 21 14

→ Главный внутренний клиент/партнёр — Управление сервиса и автоматики (на порядок плотнее прочих).

6. Важность × статус (что из важного стоит)

Важность Новый В очереди В разработке Итого
Вопрос жизни и смерти 28 5 8 41
Критически важно 24 11 7 42
Очень важно 24 6 5 35
Важно конечно 10 5 5 20

⭐ 52 топ-важных заявки (критически важно + жизни-и-смерти) даже не начаты («Новый»); из них 28 из 41 «вопрос жизни и смерти» (68%) не стартованы.

7. Нагрузка по разработчикам (assignee фаз front/back/onec)

Исполнитель Всего В разработке В очереди Поток Кто
Литвиненко А.Н. 24 13 5 backend ШТАТ
Моисеенко П.А. 18 4 14 frontend ШТАТ
Мокрецов Юрий 9 2 7 1С вне отдела
Сулим М.В. 8 4 2 frontend ШТАТ
Рябов А.Ю. 8 5 1 backend ШТАТ
Ганбаров Д.Г. 4 1 3 frontend ШТАТ
Боликов Н.Н. 3 0 3 1С ШТАТ

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

  1. Пропускная способность — узкое место (резко): 64% заявок (89) ни на кого не назначены, 52 топ-важных не начаты (28 из 41 «жизни-и-смерти»), реальная разработка — на двух людях (Литвиненко/Моисеенко) при растущем потоке.
  2. 1С/ERP практически не двигается (2 в разработке) и держится на внеструктурном человеке → прямой риск для проекта внедрения 1С ERP.
  3. Текучка (8 ушли за ~2 года) на фоне растущего потока заявок.
  4. Отдел сам идёт к AI и Telegram («AI помощник», оповещения в телегу) → органичный вход для наших AI-инструментов и единого канала коммуникаций вместо разрозненной телеги.

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