Почему ERP никогда не будет управлять вашей цепочкой поставок
Поставщики корпоративного программного обеспечения любят называть свои платформы «цифровым позвоночником» фирмы. В мире цепочек поставок этот позвоночник обычно означает ERP, в комплекте с поддерживающими системами, такими как MRP, WMS, TMS, CRM и аналогичными. Для многих организаций следующим логичным шагом кажется: если ERP уже управляет транзакциями, почему бы не поручить ей принятие решений? Добавьте несколько модулей планирования, прогнозную систему, пару возможностей ИИ — и цепочка поставок более-менее сама позаботится о себе.
Почти два десятилетия, потраченные на создание программного обеспечения, делающего прямо противоположное, привели меня к довольно грубому выводу: обычным поставщикам транзакционных систем структурно не под силу построить удовлетворительную систему принятия решений в цепочке поставок. Это не жалоба на их компетентность. Речь идет о категории продаваемого ими программного обеспечения, экономических стимулах, с которыми они сталкиваются, и ожиданиях, возложенных на них рынком.
Я подробно излагаю этот аргумент в своей книге Introduction to Supply Chain, но хочу здесь выделить одну мысль: почему место «расположения мозга» в вашем программном ландшафте имеет большее значение, чем готова признать большая часть литературы.
Что на самом деле мы просим программное обеспечение делать
Современные цепочки поставок — это не просто эффективная перевозка коробок. Речь идет о том, чтобы ежедневно делать ставки в условиях неопределенности.
Стоит ли закупать один контейнер или три? Откладывать акцию или ускорять её проведение? Отправлять ограниченные запасы в Европу или США? Принять минимальный заказ этого поставщика или отложить и рискнуть разрывом поставок? Каждое решение — это небольшая ставка с асимметричными последствиями. Некоторые ошибки обойдутся недорого; другие будут стоить дорого и продолжат стоить месяцами.
Пятьдесят лет назад люди могли бы вполне удерживать большинство этих ставок в голове, используя бухгалтерские книги и таблицы. Сегодня даже компании среднего размера управляют десятками тысяч SKU, сотнями локаций, изменчивыми сроками поставки и паттернами спроса, реагирующими на цены, погоду, маркетинг, конкурентов и сбои в поставках. Комбинации просто выходят за рамки возможностей человеческого восприятия без вспомогательных средств.
Поэтому мы обращаемся к программному обеспечению за помощью. Но «программное обеспечение» — это не одна вещь. В типичной компании сосуществуют три совершенно разных вида систем:
Во-первых, существуют транзакционные системы: ERP, MRP, WMS, TMS, OMS. Их задача — фиксировать всё, что происходит: заказы, поступления, отгрузки, счета, перемещения в пределах складов и вне их. Это превознесённые бухгалтерские книги с рабочими процессами. Их главные достоинства — надежность, прослеживаемость, права доступа и возможность аудита. Если отгрузка производится дважды или платеж исчезает, всё остальное теряет значение.
Во-вторых, существуют системы отчетности и аналитики: BI-инструменты, приборные панели, порталы KPI, таблицы, наполненные данными из хранилищ. Их задача — суммировать и визуализировать то, что уже произошло, а иногда и то, что может произойти. Они созданы для того, чтобы люди могли их изучать: графики, таблицы, списки исключений, отчеты по отклонениям.
Наконец, есть то, чего на практике почти не хватает: настоящий механизм принятия решений. Под этим я подразумеваю программное обеспечение, основной задачей которого является принятие всех этих необработанных фактов, понимание их закономерностей, оценка вариантов и последующий вывод конкретных, отслеживаемых решений: заказов на закупку, перемещений в распределении, планов производства, изменения цен, изменения ассортимента. Эти решения должны приниматься регулярно и автоматически, а затем записываться обратно в транзакционные системы, как если бы работу выполнял очень последовательный, очень быстрый планировщик.
Основное мнение склонно смешивать эти три роли. Если «цифровой позвоночник» ERP уже интегрирует данные и управляет процессами, то, несомненно, он сможет и планировать, и оптимизировать. А если нет, то это сделает другая универсальная платформа: «цифровое ядро», «контрольная башня» или «единый планировочный набор». В литературе вы регулярно встречаете описания ERP как ядра обработки бизнес-информации и позвоночника предприятия, где планирование и исполнение в цепочке поставок представляются естественными продолжениями этой же платформы.
На бумаге это выглядит привлекательно. На практике именно здесь начинаются проблемы.
Почему поставщики транзакционных систем не подходят для создания «мозга»
Чтобы понять данное несовпадение, полезно отойти от брендинга и взглянуть на то, что такое ERP и его аналоги на самом деле.
В своей сути эти системы представляют собой большие многопользовательские базы данных с жесткими правилами о том, кто, что может изменить и в каком порядке. Они оптимизированы для множества мелких, простых, хорошо структурированных операций, происходящих одновременно: зарегистрировать заказ, провести счет, подтвердить поступление. Когда учебники по ERP называют их «цифровым позвоночником» предприятия, они имеют в виду это буквально: они переносят нервы и сосуды повседневных операций.
Настоящий механизм принятия решений, напротив, не оптимизирован для тысяч легковесных кликов. Он оптимизирован для сложных вычислений.
Ему необходимо обрабатывать большие объемы данных, часто из нескольких систем. Ему нужно исследовать множество возможных сценариев будущего, а не просто экстраполировать один прогноз. Он должен оценивать варианты согласно экономическим критериям, а не только исходя из уровней сервиса или целевых сроков поставки. Ему нужно выполнять вычисления, которые иногда требуют значительных ресурсов: вероятностные модели, симуляции, комбинаторные оптимизации. И всё это должно делаться таким образом, чтобы впоследствии можно было провести аудит: почему мы закупили двадцать поддонов этого товара в тот день, а не пятнадцать или ни одного?
Это не вопрос выбора языка программирования или умной оптимизации. Это другой профиль выполнения, другие инженерные компромиссы и формы ответственности. Размещение такого механизма в той же среде, в которой работают ваши ежедневные счета и складские экраны, подобно установке реактивного двигателя в городской автобус. Это не просто избыточно; это активно мешает автобусу выполнять свою работу.
Отсюда вытекает несколько структурных проблем.
Первая проблема — операционная. Если вы попытаетесь запускать сложную аналитику и большие оптимизационные задачи непосредственно на вашей транзакционной платформе, то либо ограничите аналитическую работу, чтобы не замедлять операции, либо рискуете ухудшить время отклика, когда люди пытаются выполнить работу. Чем больше вы пытаетесь встроить «интеллект», тем больше ухудшаете основную задачу системы: никогда не терять транзакцию и не блокировать пользователя.
Вторая проблема — семантическая. Современные компании редко работают на единственном монолите. У них есть ERP для финансов и основных операций, WMS для складов, TMS для транспорта, CRM для взаимодействия с клиентами, платформы электронной коммерции, а иногда специализированные системы для производства или розничной торговли. Каждая из этих систем имеет свою собственную терминологию и свою версию истины. Однако полезный механизм принятия решений должен охватывать их все. Естественная тенденция поставщиков ERP, однако, заключается в том, чтобы рассматривать их собственную схему как центр вселенной. Всё остальное либо отображается в ней с потерями, либо игнорируется.
Третья проблема — экономическая. Крупные поставщики транзакционных систем получают оплату в основном за лицензии, количество пользователей, модули и объем хранения; в эпоху облака добавляются уровни подписки и оплата по потреблению. Они не получают оплаты в зависимости от того, сколько решений они могут безопасно автоматизировать или сколько денег вернуть в ваш P&L. Если уж и говорить, то действительно эффективный механизм принятия решений сократил бы число «планировщиков» и упростил множество рабочих процессов. Именно это не предусмотрено их ценовой моделью.
Если добавить к этому экосистему сертификаций, ситуация станет еще понятнее. Программа APICS/ASCM CPIM, например, явно представлена как глобальный стандарт планирования и управления запасами, и учебные материалы открыто отмечают, что системы ERP внедряют бизнес-правила, вытекающие из этого свода знаний.
Другими словами: предполагается, что стандартная логика планирования живет внутри ERP. Ожидается, что поставщики закодируют её; практики должны настроить и следовать ей. Задача состоит в том, чтобы привести практику в соответствие с каноном, а не пересматривать архитектуру программного обеспечения или экономику принятия решений.
Наконец, есть культура. Создание систем учета, как правило, привлекает, вознаграждает и продвигает определенный инженерный склад ума: тот, который ценит стабильность, обратную совместимость и учет исключительных случаев. С течением десятилетий эти системы накапливают слои функциональности, модули, настройки и интеграции. Они становятся чрезвычайно мощными, но также и чрезвычайно сложными. Добавить еще один модуль планирования или функцию ИИ культурно легче, чем что-либо удалить. Результатом становится постоянно растущая масса экранов настройки и параметров, вплетенных в уже хрупкие рабочие процессы.
Просить эту машину переосмыслить себя в качестве острого, принципиального механизма принятия решений — в лучшем случае оптимизм.
Основной нарратив, собственными словами
Если вы прочитаете материалы поставщиков, белые книги и большую часть академической и профессиональной литературы, вы увидите, как одна и та же история повторяется с незначительными вариациями.
ERP представляется как объединяющая платформа, которая интегрирует все данные и процессы, «гармонизируя» закупки, запасы, обработку заказов и распределение, одновременно внедряя инструменты аналитики и планирования. Она описывается как программный фундамент бизнеса, «цифровое ядро», на котором зиждется все: от финансов до производства и цепочек поставок. Над этим ядром нам обещают все более продвинутые функции: прогнозирование спроса на базе предиктивной аналитики, моделирование сценариев, интегрированное бизнес-планирование и многое другое.
Параллельно канон операционного управления предоставляет ментальные модели: свод знаний CPIM, рамки S&OP, формулы страховых запасов, логику MRP. Всё это кодифицируется как лучшие практики, экзаменационные программы и модели зрелости. Неявное обещание простое: если вы внедрите правильный ERP, настроите его в соответствии с этими стандартами и обучите своих планировщиков, ваша цепочка поставок будет работать.
Если реальность не соответствует обещанию, обычные объяснения знакомы: качество данных, управление изменениями, объем проекта, отсутствие поддержки руководства, недостаточное обучение. Решением всегда является то же самое: более тщательное внедрение, более дисциплинированные процессы, более полное применение стандартного свода знаний.
Обратите внимание на то, что редко ставится под вопрос: предположение о том, что «мозг» цепочки поставок должен находиться внутри тех же систем, которые регистрируют заказы и печатают счета.
Что на самом деле происходит на местах
На местах у большинства организаций складывается картина, удручающе одинаковая в различных отраслях и регионах.
Транзакционные системы выполняют свою работу достаточно хорошо. Заказы проходят, товары перемещаются, счета отправляются, происходит финансовое закрытие. Всегда возникают мелкие недочеты и разочарования, но в целом бухгалтерские книги в порядке.
Вокруг этого ядра распространяется отчетность. BI-инструменты подключаются к хранилищам данных, которые извлекают данные из ERP и ее спутников. Команды создают панели мониторинга, сводные отчеты, кокпиты и диспетчерские центры. Планировщики тратят все больше времени на просмотр этих экранов, согласование расхождений между ними, экспорт данных в таблицы и повторный импорт «скорректированных» цифр.
Модули планирования и оптимизации присутствуют во многих из этих систем. Они генерируют прогнозы, предлагают объемы пополнения, посылают предупреждения. Однако большая часть сложной работы остаётся выполняться вручную. Прогнозы отменяются. Предлагаемые заказы «рассматриваются» по одному. Списки исключений становятся такими длинными, что никто не в состоянии обработать их за один рабочий день, поэтому люди разрабатывают локальные эвристики: доверять этим индикаторам, игнорировать те, всегда отдать предпочтение этому поставщику, никогда не трогать эти позиции.
Автоматизация больше всего принимает форму условной логики внутри транзакционных систем: если доступность выше определенного уровня, выпускать этот заказ; если ниже, помещать его в очередь исключений. С расстояния это может выглядеть как интеллектуальное поведение. При более близком рассмотрении — это хрупкие правила и стратегии преодоления ситуаций человеком.
Иногда я называю эту ситуацию «автоматизация как бумажная работа»: системы сложны, загружены, даже впечатляют, но они редко полностью отвечают за решение, имеющее реальную финансовую значимость. Всегда ожидается, что человек где-нибудь нажмет «ОК», даже если это действие стало ритуалом.
Это не похоже на зрелый механизм принятия решений.
Иное разделение сфер ответственности
Если мы всерьез воспринимаем идею о том, что цепочка поставок — это ежедневная практика экономического принятия решений в условиях неопределенности, тогда мы должны спроектировать программный ландшафт, отражающий это.
В этом ландшафте транзакционные системы продолжают делать то, что у них получается лучше всего: они остаются авторитетным источником информации о том, что произошло и что в данный момент зафиксировано. Их схемы и рабочие процессы будут продолжать развиваться, и они останутся критически важными. Но мы прекращаем требовать от них изобретательности.
Системы отчетности продолжают делать то, что у них получается лучше всего: они помогают людям видеть, понимать и обсуждать происходящее. Хорошие приборные панели и аналитика останутся бесценными. Но мы перестаем путать визуализацию с оптимизацией.
Затем, отдельно, мы вводим специализированный механизм принятия решений.
Этот механизм получает регулярные потоки необработанных данных из всех соответствующих транзакционных систем: заказы, стоковые позиции, мощности, сроки поставки, цены, ограничения. Ему все равно, происходит ли этот поток данных из ERP, WMS, TMS или каких-либо других систем. Он восстанавливает согласованное представление о мире на основании этих фактов, явно признает неопределенность в спросе и предложении и оценивает альтернативные действия с точки зрения их финансовых последствий: ожидаемая маржа, риск дефицита, стоимость устаревания, альтернативные издержки при ограниченных ресурсах.
Выход этого механизма — не приборная панель. Это поток предложенных действий: купить такое количество данного SKU у того поставщика в эту дату; отгрузить эти поддоны с этого склада на тот сегодня вечером; повысить цену на этот товар на два процента; постепенно вывести этот вариант из ассортимента в течение следующего месяца. Каждое действие сопровождается достаточным контекстом, чтобы при необходимости человек смог его проверить: какие данные использовались, какие закономерности были выявлены, какие компромиссы были сделаны.
Ключевым моментом является то, что эти операции записываются обратно в транзакционные системы с использованием чётко определённых интерфейсов. Заказ на покупку создаётся в ERP, как если бы его набирал планировщик. Перемещение запасов появляется в WMS, как если бы его инициировал менеджер склада. Изменение цены поступает в систему ценообразования с чёткой датой вступления в силу.
Люди не исчезают из процесса. Их роль меняется. Они становятся хранителями числового рецепта: они решают, какие затраты включать, как оценивать риск, какие ограничения являются реальными и какие сценарии приемлемы. Они анализируют и уточняют поведение движка, а не управляют каждой строкой, которую он генерирует.
Эта архитектура звучит экзотически только если вы провели слишком много времени, следуя ERP-центрированной парадигме. С точки зрения программной инженерии и экономики, это просто чёткое разделение обязанностей: бухгалтерские книги для фактов, информационные панели для понимания и движки для принятия решений.
Как это противоречит мейнстримовому взгляду
С этой точки зрения, мейнстримное повествование не столько «неправильно», сколько неполно.
Абсолютно разумно желать наличия интегрированной транзакционной основы. Компании получили огромную выгоду от перехода от фрагментированных систем бухгалтерского учёта, управления запасами и производства к интегрированному ERP. Также вполне разумно требовать качественную отчётность и стандартизировать терминологию и процессы в профессиональной сфере. Инициативы, подобные CPIM, сыграли важную роль в создании общего языка и базового набора инструментов.
Я расходюсь с мейнстримом в неявном предположении, что если мы продолжим обогащать транзакционную основу новыми планировочными модулями, функциями прогнозирования, аналитическими инструментами и возможностями настройки, то в конечном итоге мы придём к эффективным, автоматизированным решениям в цепочке поставок.
Я не верю, что такое слияние произойдёт.
Пока «мозг» ожидается внутри систем, основная миссия и бизнес-модель которых заключается в ведении записей, организации работы на основе ролей и следовании общим лучшим практикам, мы будем застревать в шаблоне впечатляющих интерфейсов и робкой автоматизации. Мы продолжим наблюдать за организациями, где планировщики проводят дни, манипулируя списками оповещений, вместо того чтобы формировать экономическую логику, генерирующую эти оповещения.
Альтернатива заключается не в отказе от ERP или игнорировании сложившихся методов. Речь идёт о том, чтобы воспринимать их такими, какие они есть: необходимой инфраструктурой и ценным профессиональным наследием, но не местом для принятия реальных решений.
Как только мы примем это различие, станет возможна более честная беседа. Мы можем требовать от наших поставщиков транзакционных систем отличных бухгалтерских книг и чистых интерфейсов, а не «оптимизации на базе искусственного интеллекта». Мы можем просить наши команды BI предоставить простые, правдивые представления о реальности, а не анимированные информационные панели, претендующие на статус диспетчерских. И мы можем предъявлять к нашим движкам принятия решений — и людям, которые их создают и эксплуатируют — более высокие стандарты: ночное, автономное принятие решений, подотчётное в денежном выражении, с постоянным улучшением.
Это направление мы преследуем в Lokad на протяжении многих лет. Это не единственный путь, но он основывается на простом наблюдении: когда ваша цепочка поставок фактически ограничена программным обеспечением, то место, где находится «мозг» этого ПО, имеет решающее значение.
