В ИТ принято много говорить об устойчивости. Мы резервируем каналы связи, строим отказоустойчивую инфраструктуру, проверяем восстановление из резервных копий, распределяем нагрузку между площадками. Но в разговорах о непрерывности гораздо реже возникает другой вопрос: что произойдёт, если на месяц из работы выпадет человек, через которого проходят все решения?
Особенно неприятно задавать этот вопрос, если такой человек — сам ИТ-директор.
На одной из закрытых встреч клуба «Фармакод» мы обсуждали эту тему приглашенным экспертом. Спикер встречи — Дмитрий Мармут, руководитель департамента управления персоналом компании «Гедеон Рихтер Фарма». Разговор начинался с кадрового резерва и преемственности, но довольно быстро вышел за пределы привычной HR-повестки. Потому что зависимость от ключевых людей возникает не только из-за дефицита специалистов на рынке или слабой документации. Нередко руководитель собственными руками выстраивает систему, в которой без него действительно нельзя обойтись.
Если коротко, устойчивость ИТ-функции — это способность компании продолжать критические операции, принимать решения и восстанавливать системы, даже когда руководитель или ключевой специалист временно недоступен. Для этого недостаточно удерживать людей: знания, доступы, полномочия и ответственность должны быть распределены внутри команды.
Почему CIO становится узким местом ИТ-функции
Большинство ИТ-директоров пришли в управление из экспертных ролей. Они привыкли разбираться в технологиях, самостоятельно находить решения и отвечать за результат. Именно это когда-то помогло им вырасти. И именно это может начать мешать на следующем этапе.
Поначалу глубокое погружение руководителя в работу команды выглядит преимуществом. Он знает историю систем, помнит причины старых архитектурных решений, может подключиться к сложному инциденту и поговорить с подрядчиком на одном языке. Бизнес доверяет такому CIO: если возникла проблема, он разберётся.
Постепенно это доверие превращается в привычку. К руководителю начинают приходить не только со сложными или рискованными вопросами, но и с теми, которые команда могла бы решить самостоятельно. Он подключается, уточняет, поправляет, предлагает свой вариант — обычно действительно хороший. Через некоторое время сотрудники уже не видят смысла принимать решение без него. Всё равно придётся переделывать или согласовывать.
Так руководитель, который хотел обеспечить качество, становится узким местом. Чем больше решений он принимает сам, тем меньше опыта принятия решений появляется у команды. А чем меньше такого опыта у команды, тем опаснее руководителю что-либо отпускать.
Почему руководителю сложно делегировать
Проблему легко списать на неумение делегировать, но это слишком поверхностное объяснение. За стремлением контролировать всё часто стоит профессиональная идентичность человека.
Руководитель много лет доказывал свою ценность знаниями и личной результативностью. Теперь ему предлагают управлять людьми, которые в отдельных областях разбираются лучше него. Формально это нормальное состояние зрелой команды. Внутренне оно может восприниматься совсем иначе: если мой сотрудник знает больше, достаточно ли я компетентен? Если команда принимает решения без меня, зачем тогда нужен я? Не сочтёт ли бизнес меня слабым руководителем, если я не смогу немедленно ответить на технический вопрос?
Эти сомнения подпитываются ожиданиями самой организации. Во многих компаниях руководителя по-прежнему воспринимают как старшего эксперта, который обязан знать всё, что происходит внутри функции, и при необходимости выполнить работу любого подчинённого. В ИТ это особенно заметно. От директора могут одинаково уверенно ждать ответа и про архитектуру данных, и про информационную безопасность, и про неработающий принтер — всё это ведь «что-то техническое».
В такой среде отказаться от постоянного погружения в детали непросто. Нужно не только научиться делегировать, но и договориться с бизнесом о другой модели ответственности: CIO отвечает за результат функции, однако не обязан лично решать каждый вопрос, возникающий внутри неё.
Как ручное управление влияет на ИТ-команду
Когда решения постоянно поднимаются наверх, команда быстро понимает правила игры. Самая безопасная стратегия — не проявлять самостоятельность, а вовремя спросить руководителя. Ответственность постепенно подменяется исполнительностью: сотрудник делает то, что ему сказали, и старается не выходить за обозначенные границы.
При этом сильные и самостоятельные специалисты реагируют иначе. Если человек хочет влиять на результат, принимать решения и расширять свою зону ответственности, постоянный контроль довольно быстро становится для него ограничением. Он видит, что реальных полномочий не получит, и начинает искать их в другом месте.
В результате остаются преимущественно те, кому комфортно работать по указанию. Руководитель смотрит на команду и убеждается, что делегировать действительно некому. Получается замкнутый круг: сначала люди годами не получают возможности принимать решения, а затем отсутствие этой способности используется как причина ничего им не передавать.
Есть и ещё одно последствие. Пока руководитель занят операционными вопросами, у него остаётся всё меньше времени на задачи, ради которых компании вообще нужен CIO: работу со стратегией, приоритетами, архитектурой, рисками и бизнес-заказчиками. Личная экспертиза, которая должна была поддерживать функцию, начинает тормозить её развитие.
Если такой режим продолжается долго, он бьёт уже не только по результативности, но и по состоянию самого руководителя. Подробнее о том, как это происходит, мы писали в статье «Выгорание руководителей в ИТ: почему сила превращается в уязвимость».
Как делегировать ответственность до появления перегрузки
Одна из самых опасных ситуаций возникает в тот момент, когда руководитель уже физически не справляется со всем объёмом работы и готов отдать часть ответственности, но передавать её некому. Команда не подготовлена, решения по-прежнему завязаны на одного человека, а любое резкое делегирование выглядит как попытка сбросить на сотрудника проблему вместе с ответственностью за последствия.
Поэтому делегирование нельзя начинать в точке перегрузки. Это не экстренная мера, а способ выращивания команды.
Сначала сотруднику можно передать выполнение задачи с понятным результатом. Затем — право самостоятельно выбирать способ её решения в установленных границах. После этого — ответственность за отдельный процесс, систему или направление, включая взаимодействие с заказчиками и подрядчиками. На каждом этапе руководитель остаётся рядом, но меняет свою роль: не даёт пошаговые инструкции, а определяет критерии результата, ограничения и случаи, в которых вопрос необходимо эскалировать.
В фармацевтической компании эта граница особенно важна. В регулируемых процессах недостаточно просто сказать человеку: «Теперь ты отвечаешь». У него должны быть необходимая квалификация, доступы и полномочия, закреплённые в действующих процедурах. Но это не аргумент в пользу того, чтобы держать всё на одном специалисте. Наоборот, если только один человек способен корректно провести изменение, восстановить систему или принять решение в рамках установленного процесса, компания получает вполне конкретный риск непрерывности.
Как готовить преемников и не потерять сильных экспертов
Разговор о преемственности часто быстро превращается в поиск будущих начальников. Выбирают самого опытного специалиста, добавляют ему подчинённых и считают кадровый вопрос решённым. На практике сильный эксперт и потенциальный руководитель — не одно и то же.
Человеку может нравиться разбираться в архитектуре, писать код, работать с данными, искать уязвимости или поддерживать сложную систему. Управление потребует от него совсем другой работы: развивать людей, разбирать конфликты, объяснять приоритеты, договариваться с бизнесом и отвечать уже не только за собственный результат. Не все этого хотят, и в таком отказе нет недостатка амбиций.
ИТ-функции нужны не только будущие руководители, но и сильные профессионалы, которые хотят расти внутри экспертной роли. Если повышение в должности остаётся единственным способом получить больше влияния, признания и денег, компания сама толкает людей в неподходящую им карьеру. В итоге можно потерять хорошего специалиста и получить слабого менеджера — довольно дорогой способ испортить сразу две позиции.
Поэтому преемственность лучше рассматривать в двух контурах. Первый — управленческий: кто со временем сможет взять на себя команду или направление. Второй — экспертный: какие знания и полномочия критичны для работы и кто способен подхватить их в случае отсутствия основного специалиста.
Здесь особенно важна связка CIO и HR. ИТ-руководитель понимает содержание роли, её влияние на процессы и реальную критичность. HR может помочь оценить мотивацию человека, его готовность к другой ответственности и подобрать подходящий путь развития. Если одна сторона пытается решить задачу без другой, получается либо формальный кадровый резерв, либо очередное повышение лучшего технаря «потому что больше некого».
Как небольшой ИТ-команде снизить зависимость от ключевых сотрудников
Большая компания может позволить себе несколько кандидатов на ключевую позицию, программы ротации и длинный горизонт подготовки преемников. В небольшой ИТ-службе такая модель часто невозможна. Иногда во всей функции просто нет двух людей с похожей экспертизой, не говоря уже о двух потенциальных руководителях.
Это не означает, что небольшой компании остаётся надеяться на удачу. Просто устойчивость здесь строится иначе. Нужно понять, какие процессы действительно критичны, какие знания сосредоточены у одного человека и сколько времени потребуется, чтобы их восстановить. Где-то достаточно второго сотрудника, который регулярно участвует в разборе решений. Где-то потребуется рабочая инструкция и проверка, что ею способен воспользоваться не только автор. Для отдельных задач разумнее заранее иметь внешнего партнёра или специалиста, которого можно подключить в понятные сроки.
Сама по себе база знаний проблему не решает. Документация быстро устаревает, если её ведут отдельно от реальной работы. Гораздо полезнее, когда описание архитектуры, история решений, порядок восстановления и контакты подрядчиков обновляются в ходе изменений и регулярно используются командой. Документ считается рабочим не тогда, когда он лежит в корпоративном хранилище, а когда другой человек с его помощью способен выполнить нужное действие.
Особое внимание стоит уделять не только техническим знаниям. Иногда зависимость держится на доступах, личных договорённостях с заказчиками или понимании того, почему система когда-то была устроена именно так. Если эти связи и решения нигде не зафиксированы, передать одну только инструкцию будет недостаточно.
Как удерживать ключевых ИТ-специалистов
Деньги имеют значение, и было бы странно делать вид, что это не так. Но зарплата редко объясняет всю мотивацию человека. Одному специалисту нужны сложные проекты и ощущение профессионального движения. Другому важны автономия и возможность влиять на решения. Третьему — спокойный рабочий ритм, понятные задачи и хорошая команда. Иногда желание уйти возникает не из-за большой стратегической проблемы, а из-за вполне бытовых условий, затянувшегося конфликта или неудачного взаимодействия с внутренним заказчиком.
Узнать настоящую причину можно только одним способом — разговаривать с людьми до того, как на столе появилось заявление. Не ограничиваться ежегодной оценкой и вопросом о карьерных планах, а понимать, что человеку интересно сейчас, чего ему не хватает и какую работу он хотел бы делать через год.
Для корпоративного ИТ особенно важен портфель будущих проектов. Хороший специалист может быть доволен командой, руководителем и условиями, но не видеть для себя следующей профессиональной задачи. Если стратегия бизнеса изменилась, проекты остановились, а работа свелась к поддержке, удержать такого сотрудника одним повышением зарплаты получится ненадолго.
Иногда честное расставание оказывается правильным решением для обеих сторон. Человек получает новый опыт, а компания сохраняет нормальные отношения и возможность когда-нибудь поработать вместе снова. Удержание любой ценой — такой же признак управленческой тревоги, как стремление согласовывать каждое решение.
Своя команда или аутсорсинг: как выбрать гибридную модель
Противопоставление собственной команды и аутсорсинга давно плохо описывает реальность. Держать внутри компании всех необходимых специалистов дорого, а для небольшой организации иногда просто невозможно. Полностью передать ИТ наружу тоже не получится: вместе с подрядчиком могут уйти знания о процессах, архитектуре и принятых решениях.
Рабочей становится гибридная модель. Внутри остаются владельцы критических процессов, архитектурное понимание, управление доступами, принятие ключевых решений и контроль результата. Внешние специалисты дают дополнительную мощность, редкую экспертизу или берут на себя стандартные операции.
Граница между внутренней и внешней командой должна определяться не привычкой и не только стоимостью, а риском. Чем сильнее функция влияет на непрерывность, качество, данные и способность компании выполнять обязательные процедуры, тем важнее сохранить внутри компетентного владельца. При этом ему не обязательно выполнять всю работу собственными руками. Его задача — понимать результат, управлять поставщиком и не допускать ситуации, когда внутри компании никто уже не знает, как устроен получаемый сервис.
Аутсорсинг может снизить зависимость от отдельного сотрудника, но легко создаёт зависимость от отдельного подрядчика. Поэтому вместе с договором нужны понятный порядок передачи знаний, доступ к документации, требования к резервированию специалистов и сценарий выхода. Иначе компания просто меняет одну точку отказа на другую, более дорогую и находящуюся за пределами собственного контроля.
Как объяснить кадровые риски бизнесу
Разговор о кадровой устойчивости часто проигрывает в борьбе за бюджет. Пока системы работают, предложение выделить время на документацию, обучение дублёров или перекрёстное погружение выглядит как дополнительные расходы без немедленного результата.
Фраза «у нас незаменимый сотрудник» тоже обычно не помогает. Для бизнеса она звучит слишком абстрактно. Гораздо полезнее описать конкретный сценарий: какой процесс остановится, если человек будет недоступен; какие решения нельзя будет принять; сколько времени займёт восстановление; какие проекты задержатся; возникнут ли риски для производства, качества, данных или информационной безопасности.
Не нужно пытаться свести всё к одной красивой формуле. Вероятность ухода нельзя честно посчитать до второго знака после запятой, а последствия редко ограничиваются стоимостью часа простоя. Но можно показать диапазон возможного ущерба и сравнить его со стоимостью профилактических мер. Несколько дней совместной работы двух специалистов, актуальная схема системы и проверенная процедура восстановления обычно стоят заметно дешевле аварийного поиска человека, который должен срочно разобраться в чужой архитектуре.
Так кадровый вопрос перестаёт быть просьбой ИТ о дополнительном комфорте. Он становится частью управления операционными рисками.
Этот же подход работает и в более широком разговоре об инвестициях в технологии: бизнесу проще обсуждать не абстрактную полезность ИТ, а влияние на деньги, сроки и риски. Этой теме посвящена отдельная статья об ИТ-бюджете и ROI цифровых проектов.
Как проверить устойчивость ИТ-функции за один месяц
Начинать необязательно с большой программы преемственности. Достаточно выбрать одну критическую систему или процесс и представить, что её основной владелец недоступен в течение месяца.
Кто сможет принять необходимые решения? У кого есть доступы? Понимает ли второй человек не только устройство системы, но и причины ключевых решений? Сможет ли он взаимодействовать с бизнесом, службой качества и подрядчиками? Есть ли у него предусмотренные процедурами полномочия? И проверял ли кто-нибудь это на практике, а не только в таблице?
Затем тот же мысленный эксперимент стоит провести в отношении самого CIO. Если без руководителя останавливаются согласования, команда боится менять приоритеты, а бизнес не знает, к кому обращаться, проблема уже существует — просто пока её маскирует ежедневное присутствие одного человека.
Сильный ИТ-директор — не тот, кто способен в любой момент заменить каждого сотрудника. Его сила в другом: он строит функцию, в которой знания распределены, решения принимаются на правильном уровне, а отсутствие одного человека не превращается в кризис для всей компании.
Стремление сделать себя менее незаменимым в операционной работе не уменьшает ценность руководителя. Наоборот, оно освобождает его для задач, которые действительно нельзя передать: определения направления, выбора приоритетов, работы с рисками и выстраивания отношений между технологиями и бизнесом.
Именно с этого начинается настоящая устойчивость ИТ-функции.
Короткие ответы на основные вопросы
Что такое устойчивость ИТ-функции?
Это способность ИТ-команды продолжать критические операции, принимать решения и восстанавливать системы при временной недоступности руководителя, ключевого специалиста или подрядчика. Устойчивость зависит не только от инфраструктуры, но и от распределения знаний, доступов и полномочий.
Как понять, что ИТ-функция зависит от одного человека?
Главный признак — без конкретного сотрудника останавливаются решения, согласования или восстановление системы. Дополнительные сигналы: только у него есть нужные доступы, история изменений хранится в его памяти, а команда по любому нестандартному вопросу ждёт его возвращения.
Чем преемник руководителя отличается от дублёра эксперта?
Преемник должен быть готов со временем взять на себя управление людьми, приоритетами и отношениями с бизнесом. Дублёр эксперта обеспечивает непрерывность конкретной технической компетенции. Иногда это один человек, но считать такое совпадение правилом опасно.
Может ли аутсорсинг устранить зависимость от ключевых сотрудников?
Он может снизить зависимость от отдельных внутренних специалистов, но способен создать новую зависимость от подрядчика. Поэтому внутри компании должны сохраняться владелец процесса, архитектурное понимание, контроль доступов и способность оценивать результат внешней команды.
С чего CIO начать работу над преемственностью?
Выберите одну критическую систему и представьте, что её основной владелец недоступен месяц. Проверьте, кто примет решения, у кого есть доступы, насколько актуальна документация и сможет ли другой специалист восстановить работу без помощи владельца. Такой разбор быстро показывает реальные, а не формальные точки зависимости.
