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

В IT эту метрику считают регулярно. На складах — почти никогда. При том что текучесть персонала в складской отрасли составляет около 49% в год. Склад, который не знает своего bus-factor, не знает, насколько каждый такой уход приближает его к операционному сбою.

Важная оговорка до расчёта: bus-factor — не оценка компетентности. Высокий bus-factor у конкретного человека означает, что склад правильно спроектирован вокруг этой роли. Низкий — что знание об операции сосредоточено в одном месте и нигде больше не зафиксировано.

Как считать

Алгоритм адаптирован из методики расчёта для IT-команд и переложен на управленческие роли склада.

Шаг 1. Карта зон ответственности

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

Шаг 2. Оценка покрытия

Трёхуровневая шкала для каждого сотрудника по каждой зоне:

Шаг 3. Расчёт

Сложите баллы всех сотрудников по зоне, округлите вниз. Это bus-factor зоны. Bus-factor всей операции — минимальное значение среди всех зон.

Пример:

Шаг 4. Симуляция

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

Целевые показатели

Директор по логистике / директор по складу

Что является критичным знанием

Директор по логистике — это не просто управленческая должность. За годы работы он накапливает несколько слоёв знания, которые нигде не фиксируются:

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

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

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

Как выглядит таблица

При таком распределении bus-factor по зоне «Операционные договорённости» равен 0 — она не покрыта никем, кроме самого директора. Уход директора переводит эту зону в полный стоп.

Что снижает зависимость

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

Директор по закупке

Что является критичным знанием

История поставщиков. Директор по закупке знает, что конкретный поставщик регулярно кладёт пересорт в третью строку спецификации, что другой занижает вес нетто на 2–3% на паллете, что третий требует особого порядка согласования актов. Это знание накапливается через претензионную работу и нигде не хранится системно.

Условия, существующие вне договора. Устные договорённости о сроках, о порядке замены бракованных партий, о приоритете в дефицитных позициях. Директор по закупке держит эти договорённости в голове — они не попадают в карточку поставщика в системе.

Логика страхового запаса. Реальные нормы запаса для конкретных позиций часто отличаются от формульных расчётов. Директор по закупке знает, какие позиции нужно держать с удвоенным запасом из-за нестабильности поставщика, а какие — с минимальным, потому что есть альтернатива на следующий день.

Как выглядит таблица

Bus-factor по «Логике страхового запаса» и «Устным договорённостям» — 0. Это означает, что при уходе директора по закупке часть закупочных решений будет приниматься без контекста, который он держал в голове.

Что снижает зависимость

Паспорт поставщика с историей инцидентов, задокументированные отклонения по каждому контрагенту, правила страхового запаса в системе управления запасами — всё это переводит tribal knowledge директора по закупке в институциональное знание компании. Устные договорённости должны фиксироваться в карточке поставщика сразу после достижения — не в момент ухода директора.

IT-директор

Что является критичным знанием

Архитектура интеграций. IT-директор знает, как связаны WMS, ERP, системы маркировки, личные кабинеты маркетплейсов. Часть этой архитектуры существует в документации, часть — только в его голове. При сбое интеграции именно он понимает, в какой точке искать проблему.

История технических решений. Почему конкретная настройка сделана так, а не иначе. Какие компромиссы были приняты при внедрении и почему. Что нельзя менять без последствий для смежных систем. Это знание не попадает в техническую документацию — оно остаётся в памяти человека, который принимал решения.

Операционный контекст систем. IT-директор склада, в отличие от корпоративного IT, понимает физический процесс. Он знает, почему оператор не может нажать кнопку в конкретный момент, почему определённое поле заполняется иначе на практике, чем предполагает логика системы. Без этого контекста технические изменения ломают операцию в точках, которые не очевидны при разработке.

Как выглядит таблица

Bus-factor по «Истории технических решений» и «Операционному контексту» равен 0. Это означает, что при уходе IT-директора система продолжит работать до первого нестандартного изменения — и при нём начнутся проблемы, источник которых будет неочевиден.

Что снижает зависимость

Архитектурная документация с объяснением принятых решений — не «что сделано», а «почему сделано именно так». Протоколы изменений с контекстом. Регулярные сессии передачи знания с системным администратором по реальным кейсам, а не по инструкциям.

Общая таблица: bus-factor по управленческим ролям

Bus-factor управленческих ролей опасен иначе, чем bus-factor линейного персонала. Линейный сотрудник уходит — останавливается одна зона. Руководитель уходит — исчезает несколько слоёв контекста одновременно: операционный, исторический, договорной. Часть этого контекста восстановима через документы. Часть — только через повторный опыт, который займёт месяцы.

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

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