Крупное производство с несколькими заводами на разных участках. Техпроцесс зависит от работы систем связи, а на них АСУ ТП и промышленное видеонаблюдение за станками и опасными участками. Если хотя бы одна рация на участке не работает — работать нельзя. Работать с СКС/ЛВС в колодцах, погружаясь на большую глубину, ремонтировать системы видеонаблюдения в строительных люльках на высоте выше 10 метров, работать под напряжением до 1000 В — всё это на заводе рутина.
На производстве есть своя команда из 50 человек, разбитая по площадкам. Условно, на каждой площадке есть несколько ролей, и они работают сменами с покрытием 24/7, то есть каждый инженер работает только процентов 10–15 времени, а остальное время дежурит удалённо и «плюёт в потолок» осуществляет проактивный мониторинг. Производство решает перейти от модели постоянных дежурств к профилактике и быстрым выездам: по их расчёту, тогда будут незакрыты только риски массовых аварий на разных площадках, а всё остальное окупается за счёт экономии при большей утилизации времени команды.
Это всё планируется отдать в аутсорсное управление интегратору, потому что сам завод умеет отлично делать свои изделия, но не является сервисной ИТ-компанией. Играется тендер, одно из условий которого — принять на 3-летний контракт старую команду, которая уже этим занималась по местам.
Мы побеждаем, принимаем старую команду, нам передают дела — и начинается жесть.
Сейчас прошло два года, и я уже могу более-менее рассказывать, почему вам никогда не стоит повторять такие незабываемые приключения.
Из-за требований КТ и безопасников я обезличил рассказ, не могу показать ни одной фотографии и изменил часть деталей и чисел. Тем не менее в целом основная канва сохранилась именно так, как происходило в реальности.
В чём суть контракта
Заказчик имеет несколько команд на площадках, которые дежурят на местах. Хочет одну команду, которая будет выезжать. Экономия получается очень серьёзная: не нужно обеспечивать очень сложные условия охраны труда для этих специалистов на местах, можно уменьшить размер команды, можно получать меньше допусков итого (один правильно обученный сертифицированный человек сможет работать на разных заводах). Минус — когда аварии сразу на нескольких заводах одновременно, команда не успеет приехать везде сразу. Но этот риск, умноженный на ущерб, ниже, чем ожидаемая экономия.
По условиям контракта мы должны принять команду инженеров с завода, 50 человек, а затем предоставить им зеркальные условия в течение 3-летнего контракта. Зеркальные — это такой же уровень зарплаты, как у них был на заводе. Они переходят к нам через увольнение с производств и одновременный найм внутрь КРОК.
В контракте есть три типа оплат:
-
Фиксированная поддержка: по сути, плата за то, что всё работает. Там внутри SLA-переменная часть (около трети суммы) — если мы укладываемся в SLA по инцидентам, то всё в порядке, если нет, то идут штрафы.
-
Профилактика: если нужны масштабные планово-профилактические работы, они оплачиваются по объёму.
-
Нестандартные работы: всё то, что не было формализовано, по сути, дозаказ работ из расчёта затраченных трудочасов.
Мы должны качественно поддерживать работу телефонии, проводной связи, обеспечивать бесперебойную работу пожарной сигнализации, видеонаблюдения из нескольких десятков тысяч камер, поддерживать систему радиосвязи в цехах и на вагонах, следить за состоянием базовых станций (хотспотов) и систем оперативного управления персоналом на производстве.
Команда с завода
Естественно, передаваемой из инсорса в аутсорс команде идея не понравилась совсем. Когда вы много лет работаете на материнском производстве, а потом вас от него отрывают — это очень и очень плохо для тех, кто привык, что родной завод и кормит, и поит. По сути, это билет в новую жизнь, а в предпенсионном возрасте это очень неприятный билет. Более того, они прекрасно были в курсе про 3-летний контракт и прекрасно понимали, что его могут не продлить. А что будет с ними после контракта, никто нигде не оговаривал.
Они обратились в профсоюз, к юристам — и почти месяц согласовывали детали перехода вместе и по отдельности. По сути, выбор был простой: или переходить на зеркальных условиях, или сокращение с производства с несколькими бонусными окладами, но без возможности вернуться. Они в большинстве перешли, но естественно, мы в этой ситуации сразу же оказались почти врагами.
Сама команда — состоит из инженеров по разным направлениям. Радиосвязь, телемеханика, ЛКС-системы, видеонаблюдение, СКУДы, техтелевидение, взрывобезопасность. На каждом их старом объекте в совокупности или отдельно плюс-минус все. На каждый тип систем был свой человек: 2 телефониста в команде объекта, 2 радиста (стационарная, мобильная и носимая радиосвязь была везде). Были и общие звенья, например, ЛКС отвечали за несколько площадок.
Среди инженеров-телефонистов и кабельщиков были те, кто не умел печатать на компьютере. В смысле, это очень хорошие специалисты, способные на вкус осуществить приёмку кабеля на производство, смонтировать что угодно и где угодно в любой конфигурации — но ITSM-система приводила их в шок. Учёт задач они до нас вели в «тетрадке».
Первые два месяца
Первое, что нужно было срочно решить, — это переобучение. Когда человек меняет работодателя, нужно заново получать очень много корочек и допусков, а это требует прохождения курсов и экзаменов. Затем нужно было дать допуски всем до всех производств, что тоже заняло какое-то время. Параллельно мы искали водителей, покупали машины для выездов и так далее. То есть на некоторое время мы оставили команды в покое.
Сам переход занял около месяца в общей сложности.
Первое, что мы сделали после решения всех юридических вопросов, — это начали пересобирать команды так, чтобы получались привычные нам выездные бригады, а не команды объектов. То есть выделили лидов в командах и стали пытаться управлять (хотя бы ставить задачи) через них.
У нас не получалось.
Некоторое время у нас действовал режим без SLA, а после эти самые SLA включились, и мы сразу же начали залетать на штрафы.
Во-первых, каждый отдельный человек команды слушал только того, кто был для него авторитетом. Как правило, это был его бывший непосредственный начальник, который всю жизнь защищал и отстаивал его интересы, как это принято на заводах. Гибкие структуры управления не подходили вообще. Начальник не сказал — не делается.
Во-вторых, команда просто не понимала модель работы через SLA. К ним приходила задача, они записывали её в журнал. Если она срочная — срочно решали. Если она ждала — собирали несколько похожих задач на одном участке, чтобы решить их разом. Если эта задача требовала большого количества людей (а некоторые задачи требуют 3–4 человека просто по допуску, например), то они ставили заявку в соседнюю команду и смело ждали вплоть до месяца, чтобы синхронизировать окна.
Что куда хуже, они отчасти саботировали рабочий процесс. По крайней мере, так это выглядело, с нашей точки зрения. С их точки зрения, они работали в привычном темпе. Привычный темп, напомню, складывался из дежурства и редких инцидентов, а не постоянного решения инцидентов.
В этот момент начались наши длительные командировки к местам дислокации команды, потому что удалённо нас тоже никто не понимал. Нужно было разговаривать лично, иногда с бутылкой, чтобы люди точно нас поняли.
Сухой остаток такой:
-
Мы хотели, чтобы они выполняли SLA и работали по нашей модели выездного инженера.
-
Они хотели получать, как наш выездной инженер.
Засада была в том, что их уровень оклада был существенно ниже зарплат аналогичных наших сотрудников. Они очень быстро решили, что им платят ровно за тот объём работы, который был при дежурстве, то есть за 15% рабочего времени в инцидентах и 85% в, скажем так, ожидании инцидента. Если мы хотим чего-то большего — нужно повысить оклад.
Звучит крайне понятно и логично, но мы были связаны условиями контракта. Бюджет в принципе не предполагал, что мы сможем повысить оклады. Что ещё хуже, это было как раз начало ковида, и количество инцидентов резко выросло из-за параллельных задач по переходу на удалёнку.
То есть экономика проекта, которая строилась на годовом анализе их тасков, трещала по швам. Никто не предполагал, что случится пандемия, и никто не предполагал тогда, что люди не будут работать работу, потому что она слишком непохожа на дежурство.
С другой стороны, с потерями тоже мириться было нельзя. Первое, что мы попробовали, — это сделали премии за соблюдение SLA. Возможно, вы уже догадываетесь, чем кончилось. Команда в большинстве решила, что можно не напрягаться и получать те же деньги, что и раньше, а не бегать по объектам и зарабатывать.
Беседы 1:1 с лидами давали мало, но хоть как-то двигали процесс.
В этот момент они начали увольняться из-за общего недовольства и конфликтов: мы явно хотели от них того, чего они делать не собирались. В этот момент их лиды предложили следующую схему: каждый уволенный недовольный пополняет собой фонд заработной платы, эта плата делится между всеми, а оставшиеся разбирают задачи уволенного и работают быстрее. Мой циничный анализ показывал, что оптимум в их схеме наступал примерно при 35–40 людях в команде из некогда 50 человек.
В общем, они устроили некий аналог «Голодных игр» между собой, и каждый уволенный увеличивал награду остальных. Если задуматься, это довольно жестоко, но других эффективных вариантов использовать бюджет у нас не было.
Для нас такое управление было непостижимой историей.
Дальше было ещё некоторое количество профдеформаций завода: например, в отчётах ITSM мы видим очередь с количеством запросов, с длиной исполнения запросов с оценками и т.п. Естественно, вместо эффективного решения задач часть команды попробовала сломать систему и перестала регистрировать либо сами задачи, либо оценки. Тоже пришлось это мучительно исправлять.
Мы не штрафовали никого за сорванные SLA, но максимально подробно проговаривали с лидом, инженером и командой каждый залёт. Повысили кросс-функциональность и схемы, чтобы люди не ждали окна соседней команды для масштабных работ, а могли двигать таски так, чтобы сделать важное-большое уже завтра-послезавтра.
Отказались от ночных смен почти по всем профилям, оставили двух критичных дежурных, это помогло. Инциденты класса П1 и П2 требуют подъёма команды и выезда, но случаются они реже, чем раз в несколько месяцев.
Спустя два года работа более-менее стабилизировалась. Процессы уже были похожи на процессы сервисной компании, настроены все детали вроде учёбы, медосмотров, состава ЗИП, работы с водителями и так далее. Команда уменьшилась до 40 человек. Самым большим затыком была именно модель работы — мысль о том, что теперь придётся вписываться в сервисные окна, нести ответственность за весь результат команды (а не только свой) потребовала в итоге 9 месяцев до более-менее нормальной сработанности. Мы долго выстраивали отношения между заказчиком и руководителями групп, добавили «переговорщика» в команду — сервисного менеджера, который находится на объекте и решает операционные вопросы, чтобы инженеры просто спокойно работали, а не думали про допуски, например. Сложно было донести до тимлидов, что у них есть полномочия принимать решения в своей группе: до этого на все, даже самые незначительные вопросы, требовалось распоряжение сверху. Без изменения психологии процессы просто не запускались.
Сами инженеры оказались просто золотыми в плане знания производства. Если бы мы вывели свою команду, то не знали бы очень много ценной информации о работе и технических сторонах процесса и взаимодействии с охраной труда (по уровню сложности квеста напоминающей взаимодействие с юристами-троллями). Было очень много негласных правил безопасности, усиливающих официальные: всё же ИТ-специалисты редко сталкиваются с прямой угрозой жизни, а на производстве это обыденность.
Автор:
Alex4yb
