Цепочки поставок требуют программируемых систем, а не настраиваемых продуктов

Joannes Vermorel

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

Я не буду обсуждать конкретных производителей. Меня интересует основная философия: какое программное обеспечение вообще подходит для цепочки поставок?

Почему универсальное программное обеспечение не справляется с конкретными цепочками поставок

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

Сначала вы начинаете с транзакционной основы: системы, которая регистрирует заказы, поступления, перемещения товаров, счета и отгрузки. Этот слой относительно стандартизирован. Он работает с известными сущностями: клиентами, заказами, артикулами (SKU), локациями. Ожидается, что он будет универсальным и пригодным для использования в различных отраслях, и в основном так и есть.

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

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

Однако, при внимательном рассмотрении реальных цепочек поставок возникает препятствие: их характерные особенности.

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

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

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

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

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

Почему конфигурации недостаточно

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

К сожалению, у настройки есть жесткие ограничения.

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

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

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

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

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

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

Почему программируемость неизбежна

Если настройки недостаточно, остается программирование.

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

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

Эта логика включает в себя:

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

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

Вот почему я говорю, что программируемость — это не стилистический выбор. Это признание реальности. Вопрос не в том, «Стоит ли программировать?», а «Где и с помощью каких инструментов?»

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

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

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

Как это формирует технологические решения Lokad

Уже в 2012 году мы приняли осознанное решение: мы не будем пытаться создать универсальный «продукт планирования», который, как утверждается, работает прямо из коробки только благодаря настройкам.

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

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

Конкретно это привело нас к нескольким принципам.

Во-первых, мы рассматриваем данные, поступающие из ERP-систем и других транзакционных систем, как сырье, а не как что-то, о чем требуется просто отчитываться. Мы предполагаем, что реальная ценность заключается в преобразовании этих данных в конкретные решения: заказы на закупку, перемещения товаров, производственные графики, ценовые и скидочные политики, решения по ассортименту.

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

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

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

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

Доминирующая точка зрения и там, где мы расходимся

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

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

Мы расходимся в ответе на один конкретный вопрос:

Где компания должна разместить интеллектуальную составляющую, которая фактически принимает решения?

Основной ответ: внутри настраиваемого продукта, поддерживаемого поставщиком, адаптируемого с помощью параметров, рабочих потоков и расширений.

Наш ответ в Lokad таков: внутри компактного, программируемого слоя, управляемого небольшой командой, которая владеет логикой принятия решений и может изменять её по мере изменений в реальности.

Из этого различия вытекает множество практических последствий.

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

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

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

Узкий путь, но необходимый

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

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

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

Именно это и предлагает программируемость.

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

Эта точка зрения объясняет как технологические решения, которые мы приняли, так и наш подход к работе с клиентами. Мы не продаём коробку, которая якобы содержит интеллект. Мы предоставляем способ его создания, совершенствования и поддержания в рабочем состоянии.