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).
ПОЧЕМУ не выводим — причины пауз/застреваний за рамками данных.