В инженерии программного обеспечения есть метрика bus-factor — минимальное количество людей, одновременная потеря которых останавливает систему. Чем выше число, тем устойчивее операция к кадровым изменениям.
В IT эту метрику считают регулярно. На складах — почти никогда. При том что текучесть персонала в складской отрасли составляет около 49% в год. Склад, который не знает своего bus-factor, не знает, насколько каждый такой уход приближает его к операционному сбою.
Важная оговорка до расчёта: bus-factor — не оценка компетентности. Высокий bus-factor у конкретного человека означает, что склад правильно спроектирован вокруг этой роли. Низкий — что знание об операции сосредоточено в одном месте и нигде больше не зафиксировано.
Как считать
Алгоритм адаптирован из методики расчёта для IT-команд и переложен на управленческие роли склада.
Шаг 1. Карта зон ответственности
Выпишите функциональные зоны, где требуется специфическое знание. Это не должностные инструкции — это реальные ситуации, где один человек справляется с задачей, а без него операция зависает или деградирует.
Шаг 2. Оценка покрытия
Трёхуровневая шкала для каждого сотрудника по каждой зоне:
Балл | Уровень |
1 | Лид — закрывает зону самостоятельно, может обучить другого |
0,5 | Средний — справляется с большинством задач, в нестандартных случаях нужна помощь |
0 | Слабый — зона не покрыта |
Шаг 3. Расчёт
Сложите баллы всех сотрудников по зоне, округлите вниз. Это bus-factor зоны. Bus-factor всей операции — минимальное значение среди всех зон.
Пример:
Сотрудник | Балл по зоне |
Иванова | 1 |
Петров | 0,5 |
Сидоров | 0 |
Итого | 1,5 → BF = 1 |
Шаг 4. Симуляция
Уберите из таблицы строку конкретного человека и пересчитайте. Это покажет, что именно теряет склад при его уходе — до того, как это произошло.
Целевые показатели
Bus-factor | Ситуация |
0 | Зона не покрыта никем — операция встаёт |
1 | Критический риск. Нужны немедленные действия |
2 | Минимально приемлемый уровень в период роста |
3+ | Устойчивая операция |
Директор по логистике / директор по складу
Что является критичным знанием
Директор по логистике — это не просто управленческая должность. За годы работы он накапливает несколько слоёв знания, которые нигде не фиксируются:
Логика приоритизации потока. Какие клиенты требуют жёстких окон отгрузки. Как распределять ресурсы при одновременном пике входящего и исходящего потока. Какие заказы можно сдвинуть без последствий, а какие — нет. Это знание существует в голове и реализуется через ежедневные решения, которые со стороны выглядят как «интуиция».
История операционных договорённостей. С каким перевозчиком лучше работать по срочным маршрутам. Где в цепочке обычно возникают узкие места. Какие исключения из стандартного процесса уже согласованы с конкретными клиентами — но нигде не записаны.
Архитектура физического склада. Реальная логика зон хранения, которая сложилась исторически и отличается от того, что отражено в системе. Правила товарного соседства, которые появились после инцидентов, но не перенесены в мастер-данные.
Как выглядит таблица
Зона ответственности | Замы / старшие смены | Резерв |
Приоритизация отгрузок | 0,5 | 0 |
Управление пиковой нагрузкой | 0,5 | 0 |
Работа с ключевыми перевозчиками | 1 | 0,5 |
Архитектура хранения | 1 | 0 |
Операционные договорённости с клиентами | 0 | 0 |
При таком распределении bus-factor по зоне «Операционные договорённости» равен 0 — она не покрыта никем, кроме самого директора. Уход директора переводит эту зону в полный стоп.
Что снижает зависимость
Критичные зоны этой роли снижаются через два механизма. Первый — формализация логики приоритизации в WMS: правила распределения заданий, очерёдность волн отбора, атрибуты срочности в карточке заказа. Второй — регулярная передача контекста: старшие смены должны получать не задания, а объяснение логики решений, чтобы накапливать собственное понимание потока.
Директор по закупке
Что является критичным знанием
История поставщиков. Директор по закупке знает, что конкретный поставщик регулярно кладёт пересорт в третью строку спецификации, что другой занижает вес нетто на 2–3% на паллете, что третий требует особого порядка согласования актов. Это знание накапливается через претензионную работу и нигде не хранится системно.
Условия, существующие вне договора. Устные договорённости о сроках, о порядке замены бракованных партий, о приоритете в дефицитных позициях. Директор по закупке держит эти договорённости в голове — они не попадают в карточку поставщика в системе.
Логика страхового запаса. Реальные нормы запаса для конкретных позиций часто отличаются от формульных расчётов. Директор по закупке знает, какие позиции нужно держать с удвоенным запасом из-за нестабильности поставщика, а какие — с минимальным, потому что есть альтернатива на следующий день.
Как выглядит таблица
Зона ответственности | Менеджеры по закупке | Резерв |
Работа с поставщиками (ключевые) | 0,5 | 0 |
Претензионная работа | 0,5 | 0,5 |
Логика страхового запаса | 0 | 0 |
Устные договорённости | 0 | 0 |
Замена при дефиците | 1 | 0,5 |
Bus-factor по «Логике страхового запаса» и «Устным договорённостям» — 0. Это означает, что при уходе директора по закупке часть закупочных решений будет приниматься без контекста, который он держал в голове.
Что снижает зависимость
Паспорт поставщика с историей инцидентов, задокументированные отклонения по каждому контрагенту, правила страхового запаса в системе управления запасами — всё это переводит tribal knowledge директора по закупке в институциональное знание компании. Устные договорённости должны фиксироваться в карточке поставщика сразу после достижения — не в момент ухода директора.
IT-директор
Что является критичным знанием
Архитектура интеграций. IT-директор знает, как связаны WMS, ERP, системы маркировки, личные кабинеты маркетплейсов. Часть этой архитектуры существует в документации, часть — только в его голове. При сбое интеграции именно он понимает, в какой точке искать проблему.
История технических решений. Почему конкретная настройка сделана так, а не иначе. Какие компромиссы были приняты при внедрении и почему. Что нельзя менять без последствий для смежных систем. Это знание не попадает в техническую документацию — оно остаётся в памяти человека, который принимал решения.
Операционный контекст систем. IT-директор склада, в отличие от корпоративного IT, понимает физический процесс. Он знает, почему оператор не может нажать кнопку в конкретный момент, почему определённое поле заполняется иначе на практике, чем предполагает логика системы. Без этого контекста технические изменения ломают операцию в точках, которые не очевидны при разработке.
Как выглядит таблица
Зона ответственности | Системный администратор | Разработчик / интегратор |
Архитектура интеграций | 0,5 | 0,5 |
История технических решений | 0 | 0 |
Операционный контекст систем | 0 | 0 |
Администрирование WMS | 1 | 0 |
Работа с вендором | 0,5 | 0 |
Bus-factor по «Истории технических решений» и «Операционному контексту» равен 0. Это означает, что при уходе IT-директора система продолжит работать до первого нестандартного изменения — и при нём начнутся проблемы, источник которых будет неочевиден.
Что снижает зависимость
Архитектурная документация с объяснением принятых решений — не «что сделано», а «почему сделано именно так». Протоколы изменений с контекстом. Регулярные сессии передачи знания с системным администратором по реальным кейсам, а не по инструкциям.
Общая таблица: bus-factor по управленческим ролям
Роль | Типичный BF | Наиболее уязвимые зоны | Способ снижения зависимости |
Директор по логистике | 1–2 | Приоритизация потока, операционные договорённости | Правила приоритизации в WMS, передача контекста старшим |
Директор по закупке | 1 | Логика запаса, история поставщиков, устные договорённости | Паспорт поставщика, правила запаса в системе |
IT-директор | 1 | История решений, операционный контекст систем | Архитектурная документация с обоснованием решений |
Bus-factor управленческих ролей опасен иначе, чем bus-factor линейного персонала. Линейный сотрудник уходит — останавливается одна зона. Руководитель уходит — исчезает несколько слоёв контекста одновременно: операционный, исторический, договорной. Часть этого контекста восстановима через документы. Часть — только через повторный опыт, который займёт месяцы.
В этом месте разговор о bus-factor перестаёт быть разговором только про риски и переходит в разговор про окупаемость WMS. Пока критичная логика живёт в людях, компания платит не только за найм и адаптацию. Она платит за простои в исключениях, за замедление согласований, за ошибки при смене персонала, за зависимость от узкого круга носителей знания и за длинный период выхода нового руководителя или специалиста на рабочую скорость. Современные WMS-проекты сокращают время онбординга и снижают зависимость операций от стажа конкретного человека, потому что переносят правила, статусы, маршруты и сценарии исключений в исполняемую систему.
Окупаемость WMS в такой логике считается не только через квадратные метры, скорость отбора и остатки. В расчёт входят стоимость замены сотрудников, длительность адаптации, цена ошибок в приёмке и отгрузке, потери на ручных согласованиях и стоимость управленческого контекста, который исчезает при уходе ключевого человека. Подробный расчёт этой модели — с кадровыми рисками, сроками адаптации и экономикой проекта — вынесен в отдельный материал на сайте INTEKEY.