# Аналитика коммуникаций 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. Главное (один экран) - Из **21 327 рабочих переписок** (тред ≥2 реплик) **63% — межотдельные** (13 504): компания живёт на стыках, не внутри колодцев. **22% переписок застревают** (>7 дней без движения, 4 726 шт), 1 756 — «пинг-понг» (документ ходит туда-сюда). - ⚠️ **Три узла концентрируют потери — Закупки, Юристы, Бухгалтерия.** Финансово-снабженческо-договорной контур — через него проходит большинство застрявших линий компании. - ⚠️ **Юридический отдел — сквозной тормоз договоров.** Худшая линия компании: Бухгалтерия↔Юристы (47% застряли, 433 пинг-понга). Тот же юротдел тормозит закупки (34%) и продажи (40%). - ⚠️ **Вязнут не заявки, а объектные карточки.** Вокруг проектов/договоров/контрагентов застревает 43% переписок, вокруг заявок — всего 11%. У заявок есть статус-машина, у объектов её нет — общение вокруг них живёт в комментариях и теряется. - ⚠️ **Согласования наверху висят дольше всего** (Администрация↔инженерия/продажи — 67–81% застрявших). - ⚠️ **Производство — слепая зона:** крупнейший штат даёт 4% трафика; Кострома цех (31 чел) — 2 комментария на человека. Реальное исполнение системе не видно. - ⚠️ **Трение разное по природе (слой 2):** договоры/деньги вязнут на **отказах-доработках** (Договоры 45%), снабжение/заказы — на **переспросах** (22–23%), рекламации — на **жалобах**. Конфликт почти нигде (0.4%): потери от структуры, не от ссор. → одно лекарство на всех не работает (§4b, §6). --- ## 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):** - **Договоры/деньги** вязнут на отказах-доработках (E 45%) → нужна **статус-машина согласований** (явные состояния «черновик→на проверке→возврат с замечаниями→утверждено»), чтобы циклы доработок не жили в комментариях. - **Снабжение/заказы** вязнут на переспросах (B 23%) → нужен **единый канал с историей и явной передачей хода** (переспрос = информация не дошла с первого раза). Это и есть прямой довод за Zulip-в-Grace. - **Рекламации** — единственная горячая зона (жалобы 20% + конфликт 7%) → **приоритетная эскалация качества**. **Аргумент за единый канал (Zulip-в-Grace), без FUD:** - Там, где у процесса нет «движка» (договоры, проекты, контрагенты), переписка тонет в комментариях и застревает — единый канал даёт ей видимую очередь и статус «на ком сейчас». - **Переспросы (слой 2)** — снабжение/заказы переспрашивают в 22–23% застрявших тредов: информация не доходит с первого раза. Канал с историей и явной передачей хода прямо снимает этот класс потерь. - Производство и Кострома координируются вне системы — единый канал вернул бы их ход в поле зрения руководства. - Документы-«пинг-понги» (договоры — 433 хождения туда-сюда) — прямой кандидат на канал с явной передачей хода. **Что делает агент (прототип — этот бриф):** регулярно ранжирует vital-few линий/узлов/объектов «где+на чём+масштаб» и выносит ЛПР решение-готовым списком; по запросу — ретро-бриф по любому отделу (скилл `dept-brief`). **Слой 2 (готов) добавил «на какую ТЕМУ вязнут»** — §4b. --- ## 7. Оговорки (честность данных) - **Только канал Grace-комментов** — телефон/почта/совещания/мессенджеры вне; реальная переписка шире (слепые зоны — её прямое доказательство). - Корпус **исторический** (медиана возраста треда ~1.5 года) → это ретро-карта закономерностей, не live-монитор. - Пороги из данных: застревание = пауза >7 дней, длинный ≥6 реплик, пинг-понг ≥3 авторов и ≥4 чередования. - Суммы в §2 считают тред у обоих концов линии (для ранжирования узлов, не для доли в общем). - **ПОЧЕМУ не выводим** — карта показывает ГДЕ и НА ЧЁМ; причины — предмет адресного разбора людьми. # 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) - **АКТ:** A(информирование) 13378 · C(поручение) 3611 · B(вопрос/уточнение) 1946 · Z(служебное) 1673 · E(отказ/возврат) 1247 · D(согласование) 681 · G(жалоба) 308 · F(эскалация) 71. - **ТОН:** T0(нейтр.) 21908 · T1(напряж.) 909 · T2(конфликт) 99. → 95.6% нейтрально, 4% напряжённо, 0.4% конфликт. ## Карта «тема × трение» (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. Резюме для руководителя - Управление продаж = **начало воронки и второй по объёму коммуникатор компании**: 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) пусты. - Линия Администрация↔продажи: Администрация включает руководство (в т.ч. ЛПР) — трактовать как «согласования на верхнем уровне», адресно смотреть конкретные треды, не делать вывод о причине. - **ПОЧЕМУ не выводим** — причины застреваний за рамками данных (это «где смотреть», не диагноз). # 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. Резюме для руководителя - Проектный (инженерный) отдел = **ядро расчёта и разработки изделий**: 28 активных инженеров в трёх подразделениях (перспективные расчёты НКУ, разработка НКУ, разработка РУСН/подстанций). 10 347 комментариев (9% трафика) силами 33 человек. - ⚠️ **Центр тяжести — расчёт себестоимости:** `Calculation` — 2 940 комментариев (крупнейший тип) + 121 заявка `calculation`. Это и есть этап расчёта воронки (LEV-151), вокруг которого крутится инженерия. - ⚠️ **Расчёт цены — узел между инженерами и продажами:** линии Перспективные расчёты↔Продажи (435 + 409 + 86 + 77 тредов), застревания 33–60%, много «длинных» итераций. Продажи ждут цену — инженеры считают. - ⚠️ **Внутри инженерного контура координация рвётся сильнее всего:** Проектный отдел↔Разработка НКУ — **65% застрявших**, Проектный↔Перспективные расчёты — 53%, между подразделениями расчёта/разработки — 50–57%. - ⚠️ **Экстремум на согласованиях с руководством:** Администрация↔Разработка НКУ — 98 тредов, **79 застрявших (81%)**; Администрация↔Перспективные расчёты — 76%. Инженерия вязнет на верхнеуровневых согласованиях. --- ## 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. Оговорки (честность данных) - **Только канал Grace-комментов** — устные обсуждения у инженеров, совещания, CAD-переписка вне системы. - `calculation` в каноне = **активное окно**, не вся история (ограничение API; история закрытых — только если API даст фильтр, **не из MySQL**). Записи расчётов/проблем/рабочей документации в канон не синкаются — видны через комментарии. - Дублей карточек в юните не выявлено (28 активных = 28 уникальных). - Калькулятор/методику расчёта **не трогаем** — анализируем только коммуникацию вокруг расчёта (граница из LEV-151). - **ПОЧЕМУ не выводим** — причины застреваний за рамками данных (это «где смотреть», не диагноз). # 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. Резюме для руководителя - Операционная дирекция = **снабжение компании**: Отдел закупок + Склад + Отдел логистики + Транспорт (+ склад Кострома). ~39 активных сотрудников. Заместитель по закупкам — Корнилова Н.А. - **Отдел закупок — коммуникационный позвоночник всей компании:** 33 120 комментариев / 19 339 тредов силами 14 человек — самый плотный узел общения в ITECH. Через него проходит вся цепочка «заявка → поставщик → платёж → приёмка → склад». - **Снабжение вязнет НЕ внутри себя, а на границах** с обеспечивающими функциями: Закупки↔Юристы — застряло 34% (договоры с поставщиками), Закупки↔ОТК — 34% (приёмка/брак), Закупки↔Управление сервиса — 45%, Закупки↔Бухгалтерия — 24% (платежи). Внутренняя линия Закупки↔Логистика, наоборот, почти не застревает (0.6%). - **Крупный контур брака комплектующих:** ComponentDefect — 5466 комментариев (3-й по объёму) — замкнут на закупки + склад + ОТК = переделки/рекламации к поставщикам. - **Поток хоз-услуг растёт и держится на одном человеке:** `services_requests` — 4345 заявок на **626,9 млн ₽**, рост 2024→2025 +23%, 2026 уже 737 за полгода; **2107 из 4345 (48%) — на Кулажко Н.М.** (логистика) = риск шины фактора. --- ## 2. Команда (функциональный периметр дирекции, активных/всего) | id | Подразделение | Руководитель (по должности) | Активных | |---|---|---|---| | 35 | Отдел закупок | **Корнилова Н.А.** (Зам. опер. директора по закупкам) | 6/15 | | 14 | Склад | **Карелкин В.В.** (Начальник склада) | 19/57 | | 36 | Отдел логистики | **Кулажко Н.М.** (Ведущий спец. по логистике)¹ | 5/7 | | 31 | Транспортный отдел | — | 1/2 | | 103 | г. Кострома Склад | — (региональный) | 8/9 | > ¹ У Отдела логистики `chief_user_id` в Grace пуст — **пробел в данных, не отсутствие руководителя** (лид определяется по должности — Кулажко). Стоит проставить у клиента. То же по Транспортному. **Ключевые роли (активные):** - *Закупки (35):* Корнилова Н.А. (зам. по закупкам) · Авилова А.В. (ведущий менеджер) · Черняк Н.А. (ведущий менеджер по закупкам и ВЭД) · Шепелева Л.С. (коммерческий менеджер) · Зайцева Т.А., Фролов Д.В. (менеджеры по закупкам). - *Склад (14, 19 чел):* Карелкин В.В. (начальник) · Баранов А.В., Мацнев И.М. (начальники смен) · кладовщики/ст. кладовщики (7) · грузчики (4) · водители погрузчика (2) · Синдякова (оператор WMS) · Глушенкова (управление товарным запасом). - *Логистика (36):* Кулажко Н.М. (ведущий спец.) · 4 водителя. --- ## 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. Оговорки (честность данных) - **Только канал Grace-комментов:** переписка с поставщиками (почта/телефон/мессенджеры) — снаружи, реальная картина шире (особенно по внешним поставщикам). - `purchase`/`supply` в каноне = **активное окно** (67/26), не вся история (ограничение API; история закрытых — только если API даст фильтр, **не из MySQL**). `services_requests` — полная выгрузка (4345). - ² status_id 49 = «КП получено» (резолюция из прошлой сверки, 4341/4345 совпало; справочника статусов в каноне нет — при необходимости подтвердить эндпоинтом `statuses` Grace API). `approval_status_id` 72/34/71 — стадия согласования, метки не резолвлены. - `services_requests.department_name` в каноне не резолвится (id-first) — подразделения по `department_id`. - `chief_user_id`/`reports_to` местами пусты (пробел оргструктуры) — руководители определены по **должности** (Хлопяникова, Корнилова, Карелкин, Кулажко). Стоит проставить у клиента. - **ПОЧЕМУ не выводим** — причины пауз/застреваний за рамками данных (это сигнал «где смотреть», не диагноз). # 04 · Производство # Аналитическая справка: Производство ITECH (сборочные цеха · ОТК · техотдел) **Дата:** 2026-06-21 · **Руководители производства:** Маринчу Н.Х. (Начальник производства, Подольск), Леваков Е.С. (Начальник производства, Кострома) · единого «директора по производству» в данных нет (верхний — ген. директор Виноградов). **Источники (проверено по живым данным):** Grace API (`purchase_requests`); витрина на сервере 89 (`dim_employee`, `dim_department`, `fact_request`, `fact_communication`, `agg_comm_dept_pair`). **Метод:** контент-анализ — фактура **ЧТО** и **КАК**; причины (**ПОЧЕМУ**) — вне данных. --- ## 1. Резюме для руководителя - Производственный контур = **самый большой коллектив компании: 95 активных** (Подольск цех 51, Кострома цех 31, ОТК 4+3, Технический отдел 3+2, Электролаборатория 1). В основном сборщики НКУ — монтажники 2–6 разрядов. - ⚠️ **ГЛАВНОЕ: производство — слепая зона в Grace.** 95 человек дают всего **4 899 комментариев (4% от 120 573) силами 76 авторов.** Для сравнения: один Отдел закупок (14 человек) = 33 120 комментариев. **Крупнейшая часть компании почти невидима системе.** - **Кострома цех практически вне системы:** 31 активный сотрудник → **61 комментарий, 5 авторов.** Координация цеха идёт мимо Grace (устно/на месте/телефон). - **Где производство видно — это ОТК и погоня за материалами:** контроль качества активен (ОТК 934 комментария на 8 человек), а цех в основном «выбивает» комплектующие у закупок/склада — и там застревает 32–34%. - **Контур дефектов и проблем:** ComponentDefect 449 + Problem 843 комментариев — производство/ОТК фиксируют брак и проблемы, которые тянут за собой закупки, склад и разработку. --- ## 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. Оговорки (честность данных) - **Только канал Grace-комментов.** Низкий трафик цехов НЕ значит, что они не общаются — значит, что общаются **вне Grace** (устно, на участке, по телефону, в локальных чатах). Это и есть слепая зона, а не бездействие. (Урок: пустота поля ≠ отсутствие в реальности.) - `purchase` в каноне = **активное окно** (68), не вся история (ограничение API; история закрытых — только если API даст фильтр, **не из MySQL**). Записи изделий/дефектов/проблем в канон не синкаются — видны лишь через комментарии. - ² Аномалия «100% застрявших» на линии Администрация↔Технический отдел — это исторический кластер старых тредов (проекты/проблемы возрастом до ~3 лет), а не текущий завал; смотреть как «давно брошенные нити». - СМР (0 активных, 664 комментария) — отдел расформирован/перемещён; его коммуникация — исторический след. - `chief_user_id`/привязка по площадкам местами пусты (пробел оргструктуры) — руководители определены по **должности** (Маринчу, Леваков, Гапон, Шибаев, Лукин). Стоит проставить у клиента. - **ПОЧЕМУ не выводим** — причины простоев/застреваний за рамками данных (это «где смотреть», не диагноз). # 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. Резюме для руководителя - **Бухгалтерия — финансовый узел компании:** 9 активных, **7 087 комментариев / 5 746 тредов** силами 12 человек (~787 комм/чел — один из самых нагруженных отделов). Работает с платежами, договорами и учётными заявками. - ⚠️ **САМАЯ БОЛЬНАЯ ЛИНИЯ КОМПАНИИ — Бухгалтерия ↔ Юридический отдел:** 806 тредов, **381 застрявший (47%)**, 433 пинг-понга, 412 длинных. Договоры мечутся между бухгалтерией и юристами — крупнейший узел трения «согласование договоров» во всём ITECH. - **Платежи поставщикам подвисают:** Бухгалтерия↔Закупки — 901 тред, 216 застрявших (24%). - **Узкие места по ролям (bus factor):** банковские операции, зарплата, расчёты с поставщиками, учёт производства — каждый участок держится на одном специалисте. - **Отдел менеджмента качества (СМК) — фактически один человек.** 1 активный сотрудник (Тимофеева), след в Grace минимальный (363 комментария, в основном планы корректирующих действий). СМК как функция почти не оцифрована — за последнее время штат сжался с 4 «писавших» до 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. Оговорки (честность данных) - **Только канал Grace-комментов** — телефон/почта/совещания не захвачены; реальная картина шире. - `accounting`/`payment`/`supply` в каноне = **активное окно**, не вся история (ограничение API; история закрытых — только если API даст фильтр, **не из MySQL**). Записи договоров/счетов в канон не синкаются — видны через комментарии. - **Расхождение по штату:** данные Grace = 9 активных в бухгалтерии (присланный список — 8, без Горловой Н.А.); карточка Володиной задвоена. Численность сверять по `is_active` + актуальной оргструктуре клиента (урок: пустое/двойное поле ≠ факт о реальности). - ОМК: 4 «исторических» автора, активен 1 — выводы по динамике штата делать осторожно. - **ПОЧЕМУ не выводим** — причины застреваний за рамками данных (это «где смотреть», не диагноз). # 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. Резюме для руководителя - Юнит = управление + 3 отдела, **14 активных сотрудников** (АСУ 3, Сервис 9, Управление 2; «Отдел сервиса и автоматизации» — 0 активных, фактически пуст). - **Отдел сервиса (9 чел) = полевая бригада электромонтажников (4–6 разряд)** под началом **Масальского А.С.** (Начальник производственной службы). На 21.06 **6 из 9 в командировках/отпуске** (до 22–28.06) — бригада в разъездах (выезды на объекты). - **Внутренняя коммуникация буксует сильнее всего:** линия Управление↔Отдел сервиса — **86 застрявших из 151 (57%)**, худший показатель по юниту. - **Полевой сервис почти стоит:** из 8 активных `service_dep`-заявок **6 «Приостановлено»**, 2 в работе. - **АСУ-бэклог в основном не начат** («Новый»), держится на 1-2 людях (Печурин, Шагеров). - ⚠️ **`services_requests` (4345 заявок, 627 млн ₽) — это НЕ работа сервис-юнита**, а общефирменный поток хоз-услуг (исполнитель — Кулажко Н.М./АХО). Не приписывать сервису. --- ## 2. Команда (дерево юнита, активных/всего) | id | Подразделение | Руководитель | Активных | |---|---|---|---| | 107 | Управление сервиса и автоматики | Сухарученков Н.А. (Руководитель) | 2/3 | | 12 | Отдел АСУ | Шагеров А.Е. (Руководитель АСУ ТП) | 3/6 | | 108 | Отдел сервиса | **Масальский А.С. (Начальник произв. службы)** | 9/11 | | 105 | Отдел сервиса и автоматизации | — | 0/2 (пуст) | > ⚠️ В `dim_department.chief_user_id` у Отдела сервиса пусто — это **пробел в данных, а не отсутствие начальника** (руководитель определяется по должности — Масальский). Не делать вывод «без руководителя» из пустого поля. **Активный ростер (14) — должность · статус на 21.06:** - *Управление (107):* Сухарученков Никита — Руководитель · **Маслов Артемий — Технический директор**. - *Отдел АСУ (12):* Шагеров Алексей — Руководитель АСУ ТП · Печурин Илья — Ведущий инженер АСУ ТП · Чернышов Виктор — Ведущий инженер АСУ ТП. - *Отдел сервиса (108) — бригада электромонтажников:* Масальский Александр — Начальник произв. службы *(отпуск до 22.06)* · Барташевич Евгений — ЭМ 6 р. *(командировка до 24.06)* · Беленис Юрий — ЭМ 6 р. *(отпуск до 28.06)* · Семенюк Ярослав — ЭМ 6 р. *(командировка до 24.06)* · Глотов Станислав — ЭМ 5 р. *(командировка до 24.06)* · Попов Андрей — ЭМ 5 р. *(командировка до 24.06)* · Фетисов Александр — ЭМ 5 р. *(на месте)* · Куницын Дмитрий — ЭМ 4 р. *(на месте)* · Третьякова Оксана — Специалист *(на месте)*. --- ## 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. Оговорки (честность данных) - **Только канал Grace-комментов:** телефон/Telegram/выезды не захвачены → реальная картина шире. - `service_dep`/`acs` = **активное окно** (мелкое, 8 и 9) — не вся история (ограничение API; история — только если API даст фильтр, не из MySQL). - **Рекламации и ComponentDefect** в OpenSearch-канон не синкаются — видны лишь через комменты. - `services_requests.department_name` в каноне не резолвится (id-first; имя — по join `department_id`). - **ПОЧЕМУ не выводим** — причины пауз/застреваний за рамками данных. # 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. Резюме для руководителя - В отделе цифровизации **8 активных сотрудников** (Калдарбеков + 7 разработчиков), хотя формально в оргструктуре числятся 16 — **половина уволены** (заметная текучка: ~8 человек за 2 года). - Активный бэклог — **138 заявок**, из них **реально в разработке только 25**; 113 ждут (86 даже не начаты). Поток заявок **растёт** (2024→41, 2025→64, 2026→30 за полгода). - **60% бэклога помечены топ-важностью**, при этом 62% — в статусе «Новый». **52 топ-важных заявки даже не начаты** (28 из 41 «вопрос жизни и смерти»). **64% заявок (89) вообще ни на кого не назначены.** - Реальная разработка держится на **двух людях**: Литвиненко (backend) и Моисеенко (frontend) → пропускная способность отдела — узкое место. - **1С/ERP-направление практически не двигается** (2 заявки в разработке) и держится на **внеструктурном ресурсе** (не в штате отдела) — риск для внедрения 1С ERP. - Отдел сам тянется к AI и Telegram-уведомлениям — органичная точка входа для AI-инструментов и единого канала коммуникаций. --- ## 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 помощник», «Оповещение в телеге для производства». ### Кто ставит задачи (заказчики и авторы) - **Отделы-заказчики:** Администрация 33 · Бухгалтерия 19 · сам отдел 11 · Проектный 10 · Закупки и логистика 9 · Проектирование НКУ 8 · цеха Подольск/Кострома 7+5. - **Авторы заявок:** **Баранов А.Н. — 27** (заказчик №1) · Хлопяникова М.И. 20 · Галина Т.В. 10 · Краснов К.С. 9 · Леваков Е.С. 9. → цифровая повестка идёт сверху. ### 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С | ШТАТ | - Реальная разработка держится на **двух людях: Литвиненко (backend, 13 в работе) и Моисеенко (frontend)**. Руководитель Калдарбеков и новичок Музыка назначений не несут. - **1С — на внешнем Мокрецове** (2 в работе); штатный Боликов — только в очереди. - **«A S» (id 1) — системная заглушка** (51 «назначение», 0 в работе) — не человек, исключена. - **89 заявок (64%) — без единого назначенного исполнителя ни в одной фазе.** ## 8. Сигналы для ЛПР (это ЧТО — повод разобраться, не вывод о ПОЧЕМУ) 1. **Пропускная способность — узкое место (резко):** **64% заявок (89) ни на кого не назначены**, **52 топ-важных не начаты** (28 из 41 «жизни-и-смерти»), реальная разработка — на **двух людях** (Литвиненко/Моисеенко) при растущем потоке. 2. **1С/ERP практически не двигается** (2 в разработке) и держится на внеструктурном человеке → прямой риск для проекта внедрения 1С ERP. 3. **Текучка** (8 ушли за ~2 года) на фоне растущего потока заявок. 4. **Отдел сам идёт к AI и Telegram** («AI помощник», оповещения в телегу) → органичный вход для наших AI-инструментов и единого канала коммуникаций вместо разрозненной телеги. --- ## 9. Оговорки (честность данных) - **Только канал Grace-комментов:** телефон, Telegram, совещания не захвачены → реальная коммуникация шире. - **Бэклог = активные заявки**, завершённые эндпоинт не отдаёт → судить о «проценте закрытия» по этим данным нельзя. - **ПОЧЕМУ не выводим:** причины (почему стоит 1С, почему растёт бэклог, почему текучка) — за рамками данных, нужны разговором с отделом.