Единая точка отказа в виде сотрудника: когда бизнес внезапно работает на «незаменимого»

В каждой компании есть процессы, которые держатся не на регламентах, не на системе управления, не на документации, а на одном конкретном человеке.

И обычно это выясняется очень просто. Кто-то говорит: «эту задачу сделаем, когда Иван Петрович вернется из отпуска». Или: «с этим только Саша разберется». Или еще лучше: «мы не трогаем эту систему, потому что ее писал один человек, он сейчас на больничном, а без него страшно». Если вы такое слышали - поздравляю, у вас в компании может быть единая точка отказа в виде сотрудника.

Звучит не так драматично, как сгоревший сервер или упавший канал связи. Но для бизнеса последствия могут быть не менее болезненными. Потому что сервер можно заменить, канал можно переключить, подрядчика можно привлечь. А вот если критичные знания живут только в голове одного человека, то в какой-то момент вы можете обнаружить неприятную вещь: формально вы собственник или руководитель, но фактически важная часть бизнеса работает по расписанию, настроению и личным планам одного сотрудника. И вот это уже не ИТ-романтика. Это управленческий риск. Разберем, как его увидеть, чем он опасен и что с ним делать.

В бизнесе очень любят фразу: «У нас есть незаменимый человек». Обычно ее произносят с уважением. Мол, сильный специалист, все знает, всех спасает, в любой аварии первым берет трубку, а если надо - ночью подключится и всё починит.

Проблема в том, что для собственника это должно звучать иначе: «У нас есть процесс, который не контролируется системой управления». Пока такой человек на месте, всё выглядит нормально. Даже хорошо. Задачи решаются, аварии закрываются, бизнес живет. Но вся эта устойчивость может оказаться не настоящей, а персональной. То есть работает не процесс. Работает Петров. А Петров может заболеть, уехать, устать, перегореть, поссориться с руководителем, получить оффер в другой компании или просто однажды решить, что он больше не хочет быть корпоративным Атлантом, держащим на плечах вашу 1С, телефонию, интеграции и половину отчетности.

И вот тогда начинается самое интересное.

Когда мы говорим про ИТ-аудит, важно смотреть не на должности, а на конкретные процессы. Не «у нас есть системный администратор». Не «у нас есть разработчик 1С». Не «у нас есть начальник отдела». А вот так:

Собственнику я бы рекомендовал запросить у каждого подразделения не красивую презентацию на тему «у нас всё под контролем», а простую карту: процесс → ответственный → дублер → уровень знаний дублера → что будет, если основной человек недоступен.

И здесь важно не обманывать себя. Дублер - это не человек, который «примерно в курсе». Дублер - это тот, кто способен выполнить процесс без героического созвона с основным сотрудником, без шаманского чтения старых переписок и без фразы: «Ну, сейчас попробуем, только никто не дышите».

Я видел ситуацию, где один сотрудник отвечал примерно за 67% ИТ-процессов. Формально его дублировал начальник управления. На бумаге всё выглядело терпимо. Но когда начали разбираться глубже, выяснилось, что почти вся разработка учетной мастер-системы и доработки бизнес-процессов завязаны на одного разработчика. И этот разработчик уже успел не просто надеть корону, а подобрать к ней мантию. Он решал, что будет делать, что не будет, когда будет релиз, когда не будет, какие задачи войдут в обновление, а какие «потом посмотрим». Документации к системе не было. Нормального релизного процесса не было. Общей прозрачной картины по задачам тоже не было. Примерно так: «Если всё сложится, ночью что-то выкатим. А вы там уже как-нибудь подстройте тестирование и бизнес-процессы». Для ИТ это может звучать привычно. Для бизнеса - это красный флаг. Потому что в такой ситуации компания перестает управлять развитием системы. Она начинает подстраиваться под одного человека. И если этот человек профессионален, конструктивен и лоялен - вам просто повезло. Но управление бизнесом не должно строиться на везении.

Важно задавать вопрос не про первый день. В первый день после ухода ключевого человека обычно ничего не взрывается. Особенно если компания до этого как-то жила и зарабатывала деньги. Через неделю начинают всплывать первые проблемы: где-то неясно, как согласовать изменение, где-то непонятно, почему не работает интеграция, где-то не могут найти пароль, где-то подрядчик говорит: «Мы всегда общались только с ним».

А вот через месяц начинается настоящая проверка. Потому что заканчивается старая память команды. Исчезает эффект «ну, вроде помню, как он это делал». Накапливаются задачи, которые никто не умеет выполнять. Начинают откладываться изменения. Растет очередь на поддержку. Бизнес замечает, что автоматизация стала двигаться медленнее, а некоторые вопросы вообще зависли.

Поэтому правильный вопрос звучит так: что мы не сможем полноценно поддерживать через месяц после ухода этого сотрудника? Потому что через месяц становится видно, где у вас процесс, а где - культ личности с доступом к продакшену.

Здесь тоже важно быть честными. В компании могут сказать: «систему знают пять человек». А потом выясняется, что один знает архитектуру, второй однажды видел интерфейс, третий умеет перезапустить сервис, четвертый был на встрече два года назад, а пятый просто стоит в копии писем. Это не команда поддержки. Это театральная массовка вокруг одного главного героя. Для устойчивости бизнеса нужно понимать:

Если у вас есть учет рабочего времени и задач, можно построить аналитику и быстро увидеть, на ком сходится слишком много критичных процессов. Если такой аналитики нет - добро пожаловать в аудит, интервью, разбор задач и ручную инвентаризацию.

Да, это не так весело, как покупать новую систему мониторинга. Зато сильно дешевле, чем потом восстанавливать знания по обрывкам переписок и старым файлам с названиями вроде final_final_new_точно_рабочая_версия.

Отдельная боль - документация.

Есть две разные ситуации:

Второй вариант встречается чаще. Пока основной сотрудник на месте, кажется, что всё описано. Где-то лежат файлы, есть старые инструкции, какие-то схемы, несколько страниц в базе знаний, возможно даже папка с гордым названием «Документация», а то и целые пространства в Confluence с множеством страниц умного текста.

А потом сотрудник уходит на больничный или увольняется, и выясняется:

Я был в такой ситуации. Сначала тоже казалось, что документация есть и всё в порядке. А потом ключевой сотрудник внезапно ушел на больничный и не мог работать вообще ни в каком формате.

Вот тогда и стало видно, что система держится не на процессе, а на человеке. Пришлось срочно выстраивать документирование, релизный цикл, правила поддержки и передачу знаний. Хорошо, что мы начали это делать до его увольнения. Потому что через несколько месяцев он действительно покинул компанию. Причина, которую он озвучил лично, была забавной: мы якобы нарушили его личные границы, убрав зависимость от него.

С точки зрения сотрудника - возможно, это выглядело именно так. С точки зрения бизнеса - компания просто перестала быть заложником одной головы.

Сильный проверочный вопрос: когда последний раз кто-то пытался выполнить инструкцию без участия автора? Не прочитать. Не согласовать. Не положить в папку. А именно выполнить. Потому что инструкция в стиле «настроить как обычно» - это не документация. Это записка для человека, который и так всё знает. Хорошая документация должна быть понятна специалисту аналогичного уровня, который раньше не жил внутри вашей системы.

Я обычно говорю проще: писать нужно так, чтобы понял человек, который не находится у автора в голове. Профессионалы часто забывают объяснять базовые вещи. Для них многое «и так понятно». Но для нового сотрудника это может быть вообще неочевидно.

У меня был похожий опыт, когда я начал учиться играть на гитаре. Сначала смотрел онлайн-уроки и думал, что проблема во мне: руки кривые, пальцы не слушаются, видимо, музыка - не мое. А потом пришел на офлайн-занятие, преподаватель поставил руки, поправил посадку, объяснил базу - и внезапно стало получаться.

С документацией так же. Если автор пропустил базовые шаги, новый человек может выглядеть некомпетентным, хотя на самом деле ему просто не дали нормальную инструкцию.

Если зависимость уже есть, а ключевой человек одной ногой на выходе, главное - не паниковать. Компания, скорее всего, не остановится на следующий день. Многие «незаменимые» любят говорить: «без меня через неделю всё ляжет».

Обычно не ложится. Что-то будет работать медленнее. Какие-то задачи временно отложат. Где-то бизнесу придется потерпеть. Какие-то процессы адаптируются. Часть функций подхватят смежные специалисты или подрядчики. Но это не значит, что риска нет. Риск в том, что без быстрых действий проблемы начнут накапливаться.

Поэтому при уходе ключевого сотрудника нужно сразу сделать несколько вещей:

Какие системы, процессы, доступы, интеграции и документы были на этом человеке.

Где используются его учетные записи, почта, личные токены, ключи, VPN, админские права.

Не «есть ли папка», а можно ли по ней реально выполнить работу.

Если система плохо описана, не надо в первый же день после ухода затевать крупный релиз.

Пусть даже с меньшей скоростью, но с понятной ответственностью.

Аутстафф, интегратор, подрядчик - это не слабость. Слабость - ждать, пока проблема сама рассосется.

Именно они покажут, какие компетенции были критичными на этой позиции.

В одной из таких ситуаций после ухода ключевого разработчика мы проводили большое код-ревью, чтобы понять, что действительно описано, а где остались «черные ящики». Полностью предусмотреть всё невозможно, но большую часть рисков можно снять, если начать работать заранее.

Интересно, что бизнес-заказчики сначала были недовольны новым процессом. Им было удобнее писать разработчику напрямую в личку: быстро, привычно, по-домашнему. Потом они оценили прозрачность. Потому что через заявки стало понятно, что принято в работу, что отложено, что вошло в релиз, где есть сроки и кто за что отвечает. А за нас уже говорили статистика, качество релизов и предсказуемость процесса. Иногда бизнесу нужно просто пережить период отвыкания от хаоса.

Зрелость компании проявляется не в количестве героев. Зрелость проявляется в способности работать без них. Это не значит, что сильные сотрудники не нужны. Нужны. Более того, без них не построить качественную ИТ-функцию. Но сильный сотрудник должен усиливать систему, а не подменять ее собой. Зрелый бизнес делает несколько вещей.

Во-первых, описывает критичные процессы. Не для галочки, не «потому что аудит попросил», а чтобы понимать, как компания реально работает.

Во-вторых, убирает единичные точки отказа. Если процесс важен для бизнеса, у него должен быть не только владелец, но и дублер. А у дублера должны быть не только ФИО в таблице, но и реальные знания.

В-третьих, регулярно передает знания. Передача знаний - это не встреча в последний рабочий день сотрудника, когда он уже мысленно на новой работе. Это регулярный процесс.

В-четвертых, проверяет документацию практикой. Документация считается рабочей только тогда, когда другой человек смог по ней выполнить задачу.

В-пятых, хранит доступы и лицензии на корпоративных учетных записях. Если лицензия, домен, сервер, интеграция или критичный сервис оформлены на личную почту сотрудника - это не удобство. Это будущая проблема.

В-шестых, развивает культуру заявок, релизов и прозрачных изменений. Да, писать в личку быстрее. Но для бизнеса быстрее не всегда значит лучше. Особенно когда потом никто не может восстановить, кто что просил, кто что сделал и почему после этого упала интеграция.

Если вы хотите быстро понять, есть ли в компании опасная зависимость от людей, задайте ИТ-директору, руководителям подразделений и ключевым специалистам несколько вопросов.

1. Какие критичные процессы держатся на одном человеке?

Не отделы. Не должности. Именно процессы.

2. Кто сможет выполнять обязанности главного инженера, архитектора, администратора или ключевого разработчика через неделю после его увольнения?

Фамилия должна быть конкретной.

3. Где находятся все пароли, схемы, инструкции и доступы?

И это должно быть не «у него на ноутбуке».

4. Кто проверял актуальность этих инструкций?

Дата последней проверки важнее, чем уверенное «да у нас всё есть».

5. Когда последний раз другой специалист выполнял критичную операцию без участия автора системы?

Если никогда - документация не проверена.

6. Какие системы никто не сможет полноценно поддерживать через месяц после ухода ключевого сотрудника?

Вот это главный вопрос.Не самый приятный, но очень полезный. Потому что большинство компаний думают: «ничего страшного, наймем нового». А потом выясняется:

И найм нового человека превращается не в замену сотрудника, а в расследование. Единая точка отказа в виде сотрудника опасна тем, что долго выглядит как сильная сторона компании. Есть человек, который всё знает. Есть человек, который всё чинит. Есть человек, который всегда спасает. Но для собственника правильный вопрос звучит не так: «как нам удержать этого человека любой ценой?», а так: «что станет хуже работать после его ухода?». Если ответ на этот вопрос вас пугает - это не повод ругаться с сотрудником или срочно искать виноватых. Это повод начать антикризисный ИТ-аудит. Потому что бизнес должен зависеть от процессов, архитектуры, документации и управляемой команды. А не от того, вернулся ли Иван Петрович из отпуска.