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

Был проект в компании примерно на 15 000 сотрудников. Владелица бизнес-процесса запустила перевод формализованных документов — счетов-фактур, типовых договоров, отчетных листов — в электронный вид в IBM Lotus Notes. Это подразумевало десятки интеграций с 1С, веб-сервисами, базами MS SQL и ПО для распознавания текста. Когда она перешла в другое подразделение и перестала участвовать в доработке ТЗ, проект превратился в долгострой. Сотни человеко-часов, почти пять лет — и к моменту внедрения новому владельцу он был уже не нужен.

Причин несколько. Метрику запаса прочности в ИТ почти никто не считает, максимум — SLA по заявкам. Руководители путают лояльность с незаменимостью: пока человек работает, кажется, что он никуда не денется. За эту иллюзию платят потом месяцами восстановления — я видел, как руководство тратило до полугода, чтобы разобраться в устройстве системы после ухода единственного администратора. Третья причина — отсутствие баланса между временем на текущие задачи и на документирование.

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

Примерно в 70% случаев дело не в злом умысле: руководитель годами закрывает глаза на отсутствие документации и обучения.

У крупного дистрибьютора с сетью филиалов настройки всех интеграций между учетной системой и ЭДО держались на одном человеке.

Руководитель объяснял это тем, что тот работает быстро и дешево, а «писать регламенты дорого». Мы посчитали стоимость риска при его внезапном увольнении — 6–8 млн рублей прямых потерь за первый месяц: остановка процессов, следом финансовых операций, поиск и обучение новых людей, перераспределение задач внутри отдела. Документация и обучение двух стажеров обошлись бы менее чем в 15% этой суммы.

Николай Крыгин: Экспресс-аудит реален за день, для крупной компании с множеством ИТ-направлений — за два-три. Достаточно трех действий:

1. Попросить каждого ключевого специалиста нарисовать схему процессов, за которые он отвечает, с точками входа и выхода. Схема только в голове или на салфетке — тревожный сигнал. Схема, обновленная за последние три месяца, — показатель хороший.
2. Проверить доступы и пароли. На двух предприятиях, куда меня приглашали как антикризисного эксперта, ключевые учетные записи к серверам документооборота существовали в единственном экземпляре. Отсюда и истории про людей, которые не могут в отпуске отключить телефон.
3. Задать вопрос: «Если этот администратор уйдет завтра, кто выполнит его задачи с приемлемым качеством в течение недели?» Называет конкретные имена — ситуация контролируемая. Начинает рассуждать или говорит «никто» — система глубоко зависима.

Николай Крыгин: Чтобы перевести ИТ-риски на язык финансов, нужно посчитать стоимость простоя каждого процесса, привязанного к человеку, и умножить на вероятность его выпадения. Я использую формулу: C = Σ (часы простоя процесса × стоимость часа бизнес-операции) + (затраты на аварийное восстановление за вычетом плановых расходов).

В дистрибьюторской компании с 50+ филиалами маршрутизацию всех входящих и исходящих документов настраивал один человек. Мы оценили, что в случае его увольнения отдел продаж потеряет возможность оперативно выставлять счета клиентам — это около 3 млн рублей выручки в неделю; закупки не смогут подтверждать заказы, а это примерно 1,2 млн упущенной маржи; аварийный вывод системы на аутсорсинг обойдется в 800 тыс. рублей за месяц. Итого потенциальный ущерб — порядка 5 млн рублей за первый месяц.

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

Но это была история с хорошим концом. Чаще руководство не хочет слышать сигналы от ИТ-специалистов, которые готовы говорить о приближающейся аварии заранее, — хотя у сотрудников, которым небезразлична судьба компании, обычно есть и конкретные предложения: выделить время на внутреннюю базу знаний или немного расширить штат.

Николай Крыгин: На предприятии, где согласование договоров и счетов было завязано на одного администратора Lotus Notes — назовем его Артем, — он вручную настраивал маршрут для каждого типа документа: кто следующий подписант, сколько времени на согласование, куда уходить при отклонении. Когда Артем ушел на больничный, согласование встало полностью.

Мы отказались от ручных маршрутов и разработали 9 шаблонов для категорий документов, завязанных на должности, а не на ФИО. Назначение ответственных настроили автоматически, через интеграцию с Active Directory. Добавили интерфейс контроля, чтобы руководитель видел движение документа, не дергая Артема.

Убрали 44% ручных операций: раньше Артем тратил на маршруты до двух часов в день, теперь десять минут. Перестройка заняла три недели — аудит, проектирование шаблонов, тестирование и обучение двух человек.

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

Николай Крыгин: Уйти с унаследованной системы за месяц невозможно, и это нормально. Но и ничего не делать тоже не вариант. Стратегия из трех этапов работает и с Notes, и с SAP R/3, и с любым legacy.

Этап 1 — инвентаризация, 2–3 недели. Вместе с единственным экспертом составить список критических модулей и интеграций. Регламенты на все сразу не нужны — нужна карта: что с чем связано.

Этап 2 — короткие скринкасты вместо мануалов, параллельно с первым. По 5–7 минут на каждую ключевую операцию. На одном предприятии мы сделали 23 таких видео за месяц. Эксперта они не заменят, но новому человеку дадут разобраться в разы быстрее, и поддерживать их проще.

Этап 3 — план миграции с фиксированными точками. В компании с Lotus Notes мы вынесли на внешний сервис только согласование командировок: два месяца работы, зато у эксперта освободилось 15–20% времени, которое он направил на документирование остальных модулей. Дальше по той же схеме добавили отпуска и служебные записки и успели подогнать новую систему под пользователей на простых процессах, до того как перенесли договоры, корреспонденцию и приказы.

Николай Крыгин: Начать стоит с процесса, который чаще всего встает без эксперта, — например, выставление счетов или согласование договоров. На одном проекте мы за месяц сделали схему согласования договоров с ролями, точками принятия решений и альтернативными маршрутами. Это стоило 0 рублей и четырех часов работы трех человек в неделю.

Дальше — назначить ключевому эксперту «заместителя», который присутствует при всех критических настройках и задает вопросы. За месяц такой стажер закрывает 60–70% рутинных операций и работает первой линией поддержки. В производственной компании мы так подготовили замену администратору серверов с ЭДО (Lotus Notes и SAP), уходившему в декрет, — без найма нового сотрудника.

И третье — ввести «обеденные разборы». Раз в неделю по 30 минут эксперт рассказывает, как решил одну конкретную проблему, а кто-то из коллег добавляет кейс во внутреннюю базу. Документацию это не заменяет, но запускает культуру трансфера знаний.

Николай Крыгин: Типичная ошибка — начать с фразы «мы хотим, чтобы ты передал знания». Специалист слышит: «мы готовим тебе замену».

Мой подход — начинать с роста. Я говорю эксперту: «Ты незаменим, и это проблема не для тебя, а для компании. Если мы не передадим твои знания, ты так и останешься на поддержке и не вырастешь до архитектора. Передача знаний — билет наверх, а не на выход». Сильному специалисту нужны трудные задачи, и поддержка пользователей его только держит на месте.

В кейсе с дистрибьютором администратор боялся, что его уволят, как только все задокументируют. Мы привязали его годовой бонус к запуску учебного центра внутри ИТ-департамента, где он стал наставником для двух младших сотрудников. Роль он сохранил, а вместе с ней получил статус и прибавку к окладу в 15%.

Николай Крыгин: Документация в классическом виде — 50-страничный Word — мертвый груз: не больше 5% сотрудников открывают такие регламенты чаще раза в квартал. Сам грешен — приходя на новое место, хочется быстрее потыкать в систему и поговорить с практиками.

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

Чек-листы вместо регламентов: на одном проекте мы заменили 12-страничный регламент по настройке нового пользователя одностраничным чек-листом из 11 пунктов. Любой стажер выполнял настройку за 20 минут вместо двух часов.

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

Документация — артефакт, знание — актив. Регламент — страховка для юриста, но не для инженера.

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

Практически это выглядит так:

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

80% должны быть прозрачными и воспроизводимыми: чтобы команда понимала логику, могла поддержать в аварийной ситуации и знала, куда идти за информацией.

Пример из практики. В одной компании с 500 сотрудниками был администратор SAP, который знал все финансовые модули наизусть. Мы сделали так, чтобы:

• он остался единственным архитектором (глубокая экспертиза сохранилась),
• но базовая операционная документация стала доступна его коллегам — так, что они могли перезапустить упавший сервис без него,
• так же изменили и направление его деятельности – теперь он больше отвечал за внедрение новых функций (получил возможность не просто обслуживать, но улучшать систему), что подстегнуло в нем азарт и повысило производительность в реализации новых проектов.

Он остался уникальным, но перестал быть единственной точкой отказа. Мы не ушли в крайность универсалов — просто сделали границы зон ответственности ясными и защитили бизнес от катастрофического риска.

Николай Крыгин: ИИ смещает проблему зависимости на другой уровень. Вопросы те же — кто обучал модель, кто писал промпты, кто проверял ответы, — только вместо одного человека теперь человек плюс нейросеть.

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

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

Николай Крыгин: Встречаться нужно с самым «незаменимым» техническим специалистом — тем, без кого процессы встанут быстрее всего.

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

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