Устойчивость цепочки поставок требует пропускной способности

Joannes Vermorel

Последние несколько лет не были благосклонны к цепочкам поставок. Фактически, единственное, чего не хватало, оказались силы разрушения: локдауны, войны, инфляция и т.д. В результате возник новый интерес к «устойчивым» цепочкам поставок. Естественно, обычные подозреваемые — консультанты, профессора и поставщики программного обеспечения (включая меня) — были заняты поиском «решений», которые, во всяком случае, могли бы смягчить влияние этих нарушений, а в лучшем случае полностью устранять определённые классы нарушений. Однако мои случайные наблюдения показывают, что эти «решения», как бы ни оценивались, обычно представляют собой не более чем мечтательные предположения.

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

Несколько десятилетий назад в программной индустрии ввели термин, описывающий эту проблему: недостаток пропускной способности, когда руководство не может даже задуматься о ещё одной проблеме, так как их внимание уже рассредоточено между слишком большим количеством задач. Актуальность концепции пропускной способности для программного обеспечения и цепочек поставок заключается в том, что в обеих ситуациях обычный корпоративный ответ на чрезмерную нагрузку – то есть привлечение большего количества сотрудников – не работает. Это и есть суть закона Брукса: добавление дополнительной рабочей силы к проекту, уже отстающему от графика, лишь дополнительно его задерживает. В программной индустрии, где работают одни из самых прибыльных компаний, когда-либо существовавших на свободном рынке, проблема с пропускной способностью является особенно раздражающей. Хотя компания может быть достаточно прибыльной, чтобы удвоить штат и руководство, это не решит проблему ¹.

Возможно, что удивительно (или, может быть, и не совсем), но коренной причиной этого бесконечного потока микро-кризисов в цепочках поставок является почти исключительно программное обеспечение. Противоречиво, но не война в Украине и не вероятность новой войны в Азии истощают пропускную способность подразделения, а, как правило, проблемы, которые можно назвать «исключительно анекдотичными», например, несогласованность между WMS и ERP (…снова); или политические игры с IT для добавления дополнительного настраиваемого поля в базу данных для «резервных» запасов ²; или погоня за совершенно неразумными прогнозами, предоставляемыми процессом S&OP.

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

Lokad, как часть экосистемы аналитического ПО, не застрахован от этой проблемы. Однако много лет назад мы разработали противоядие посредством четвертого пункта нашего манифеста ³: Контроль требует автоматизации каждой обыденной задачи. Мы поняли, что необходимо найти тонкий баланс между управлением и оптимизацией. Например, если генерация ежедневных заказов на закупку и производство поглощает весь бюджет пропускной способности подразделения, то для улучшений (в плане устойчивости или чего-либо ещё) остаётся ничего.

Наоборот, если все обыденные задачи полностью автоматизированы, это освобождает огромное количество пропускной способности в организации цепочки поставок. Однако этот процесс требует времени. Не случайно, что когда Lokad начинает работать с клиентом, обычно проходит около года, прежде чем мы сможем непосредственно сосредоточиться на каком-либо вопросе, который можно считать стратегическим (например, на устойчивости). Lokad должен не только выйти на стадию производства (что занимает около 6 месяцев), но и организация должна научиться отдавать контроль над всеми процессами, которые теперь автоматизированы (это требует ещё 6 месяцев, а в крупных организациях – больше).

Автоматизируя обыденные решения, команды цепочки поставок возвращают то, что они утратили ещё десятилетия назад, когда их организации перешли в цифровой формат: способность выбирать свои сражения. Это, пожалуй, самое важное преимущество автоматизации, затмевающее и экономию на производительности. Я не утверждаю, что переход на цифровую цепочку поставок в 1980-х и 1990-х годах, осуществлённый посредством совокупности ERP, MRP и APS, был неправильным решением. Проще говоря, хотя этот цифровой путь был необходим, он имел серьёзные недостатки: (компаниям свободного рынка) ещё никогда не приходилось так глубоко внедряться в собственный прикладной ландшафт, где миграции и обновления обычно измеряются годами. Многие цепочки поставок так долго были поглощены «цифровой борьбой с огнём», что немногие сотрудники помнят дни, когда рабочее утро начиналось без бесконечного потока оповещений, исключений и проблем. И это не считая соответствующего бесконечного потока встреч для решения этих оповещений, исключений и проблем. Все эти процессы имеют прямые затраты в терминах пропускной способности, а умственная нагрузка постоянно растёт.

В качестве анекдотического примера рассмотрим, что менее чем за 5 лет (с 1903 по 1908) Генри Форд из ничего создал Model T. Форд произвел революцию в промышленном производстве, представив более десятка моделей (Model A, Model B, Model C и т.д.), одновременно управляя постоянно меняющимся балансом спроса и предложения. Форду тоже не было легко: паника 1907 года стала одним из величайших и самых серьёзных финансовых кризисов за все времена. В наши дни, за 5 лет «обычного ведения бизнеса», многие (а может, большинство?) компании даже не могут закончить обновление своей ERP.

Таким образом, чтобы стать устойчивой, цепочке поставок необходимо освободить пропускную способность. Устойчивость – это сложная, неуловимая тема, требующая больших ресурсов, что делает задачу ещё более трудной. Более того, недостаток доступной пропускной способности в цепочках поставок, как выяснила программная индустрия десятилетия назад, не может быть устранён простым вбрасыванием огромных сумм денег ⁴. Скорее, лучший путь к устойчивости – это косвенный: безжалостно автоматизировать обыденные решения, чтобы получить свободу думать и реализовывать стратегические задачи, включая обеспечение устойчивости.