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. Сигналы для ЛПР (ЧТО — повод разобраться, не ПОЧЕМУ)

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

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

Только канал Grace-комментов: телефон/Telegram/выезды не захвачены → реальная картина шире.
service_dep/acs = активное окно (мелкое, 8 и 9) — не вся история (ограничение API; история — только если API даст фильтр, не из MySQL).
Рекламации и ComponentDefect в OpenSearch-канон не синкаются — видны лишь через комменты.
services_requests.department_name в каноне не резолвится (id-first; имя — по join department_id).
ПОЧЕМУ не выводим — причины пауз/застреваний за рамками данных.