Быстрее, чем «один клик»: почему программируемые цепочки поставок выигрывают по скорости
В цепочке поставок мы много говорим о скорости. Скорость пополнения запасов. Скорость реакции. Скорость восстановления, когда что-то идет не так. Однако когда речь заходит о системах, предназначенных для поддержки этих решений, обсуждение скорости быстро сводится к одной метрике: сколько недель требуется, чтобы «ввести систему в эксплуатацию» после подписания договора на программное обеспечение?
Большинство крупных поставщиков программного обеспечения для цепочки поставок дают на этот вопрос очень четкий ответ. Они обещают быстрое достижение ценности благодаря преднастроенному контенту, стандартным моделям данных и «отраслевым лучшим практикам». Если вы посмотрите маркетинговые материалы интегрированных систем планирования бизнеса и продвинутых систем планирования, повествование удивительно последовательное: начните с их эталонной модели, примените набор шаблонов, и вы сможете запустить производство за «несколько недель» или «всего за 12 недель», иногда явно «от Excel к продвинутому планированию за несколько недель».
Недавно я попытался отойти от этого повествования в моей книге Introduction to Supply Chain, где я представляю цепочку поставок как бизнес по принятию прибыльных решений в условиях неопределенности день за днем. Если мы всерьез примем эту точку зрения, вопрос «как быстро мы можем развернуть программное обеспечение?» становится вопросом «насколько быстро мы можем внедрить высококачественные автоматизированные решения и поддерживать их в соответствии с изменениями в бизнесе?» Это совершенно другой вопрос.
Отсюда я прихожу к выводу, который противоречит мейнстриму: для серьезных инициатив в области цепочки поставок программируемый подход не только мощнее традиционного готового программного обеспечения; он на самом деле быстрее приводит значимые результаты в эксплуатацию.
Позвольте мне объяснить почему.
Утешающее обещание преднастроенного ПО для цепочки поставок
Традиционные поставщики корпоративного планирования предлагают утешительную историю.
Они начинают с канонической модели данных для цепочки поставок: местоположения, продукты, иерархии, спецификации, календари, сроки выполнения и ограничения. На основе этой модели они поставляют преднастроенные процессы («лучшие практики»), демонстрационные наборы данных, шаблонные информационные панели, оповещения, стандартные алгоритмы и руководства по конфигурации. Все эти материалы явно разработаны для ускорения внедрения и снижения риска проекта.
Логика совершенно последовательна. Если данные и процессы каждого клиента можно описать как небольшое отклонение от общего шаблона, то большая часть работы должна быть повторно используема. Проект внедрения становится вопросом сопоставления полей ERP с моделью планирования, включения соответствующих функций, настройки параметров и обучения пользователей работе с интерфейсами.
В таком мире кастомизация является необходимым злом. Ее принимают для «особых» случаев, но также признают, что именно она становится основным источником задержек, перерасхода бюджета и долгосрочной сложности. Таким образом, возникает тенденция «конфигурировать, а не кастомизировать» — и, в последнее время, использование инструментов с низким или отсутствующим кодированием — чтобы оставаться в пределах безопасного функционала уже существующего программного обеспечения.
При этих допущениях идея, что готовое программное обеспечение разворачивается быстрее, выглядит вполне разумной.
Проблема в том, что реальные цепочки поставок редко соответствуют этим предположениям.
Где проекты действительно замедляются: семантика, а не интерфейсы
Если присмотреться, на чем на самом деле уходит время при разворачивании крупных систем для цепочки поставок, то это не установка программного обеспечения или даже обучение пользователей. Все время уходит на понимание смысла данных.
В большинстве крупных компаний есть один или несколько ERP, а также множество других систем — CRM, WMS, TMS, PIM, электронная коммерция и так далее. Вместе они содержат тысячи таблиц. Формально этим объектам приписаны задокументированные значения; на деле их реальная семантика является результатом многих лет обходных решений, локальных конвенций, компромиссов и частичных доработок. Истинное поведение системы закодировано в том, как люди ее используют, а не в том, как это задумывал исходный поставщик.
Когда появляется система планирования, она приносит с собой свою собственную модель данных и свои ожидания. Даже если она поступает от того же поставщика, что и ERP, семантика не совпадает точно. Поле под названием «тип местоположения» или «страховой запас» не означает одно и то же в настройках, при ежедневных операциях, в отчетности и в планировочном движке.
Кто-то должен примирить все это.
Именно этим кто-то обычно становится смешанная команда из IT, консультантов и представителей бизнеса. Им предстоит решить, какие таблицы являются авторитетными, какие поля заслуживают доверия, как обрабатывать исключения и как отобразить запутанную реальность компании в чистые структуры, ожидаемые планировочным программным обеспечением. Они пишут задания для извлечения и преобразования данных; добавляют пользовательские флаги и атрибуты; придумывают соглашения для кодирования ограничений, которые стандартная модель выразить не может.
Именно в этот момент так называемое «развертывание в один клик» часто превращается в разрастающуюся задачу интеграции. Само программное обеспечение может быть запущено с первого дня, но данные, которые ему нужны — точные, надежные, ежедневные данные, требуемые серьезным оптимизационным движком — стабилизируются только спустя месяцы или годы.
Это не провал внедрения. Это симптом более глубокой проблемы: семантика локальна, и не существует универсального готового представления цепочки поставок конкретной компании.
Цепочка поставок как программное обеспечение, а не конфигурация
Если принять, что семантика локальна и постоянно меняется по мере изменения бизнеса, то обычное различие между «конфигурацией» и «кастомизацией» становится вводящим в заблуждение.
Под капотом амбициозная инициатива в области цепочки поставок всегда является программным упражнением. Это акт точного и исполнимого определения того, как компания желает принимать решения относительно закупок, производства, запасов, ценообразования, распределения и так далее, с учетом доступных данных и ограничений.
В традиционной модели готового программного обеспечения это программное обеспечение состоит из конфигурационных таблиц, параметров, диаграмм рабочих процессов, нестандартных коннекторов и случайных «точек входа» для пользователей, написанных на универсальном языке программирования. Надеются, что большую часть логики можно выразить через конфигурацию, и только крайние случаи требуют написания кода.
По моему опыту, особенно в сложных условиях, происходит обратное. Самая критическая и отличительная логика оказывается реализована хрупким способом: перегружая поля, накладывая Excel-таблицы и Python-ноутбуки рядом с официальной системой, обучая планировщиков интерпретировать информационные панели определенным образом, который нигде явно не зафиксирован.
В итоге «система» оказывается частично в программном обеспечении и частично в головах людей.
В компании Lokad мы более десяти лет назад решили принять природу проблемы как программную, а не бороться с ней. Мы создали собственный предметно-ориентированный язык Envision, нацеленный на специалистов по цепочке поставок, а не на профессиональных программистов. Идея проста: представлять все преобразования данных, все прогнозы, все ограничения и все решения в виде скриптов, которые можно читать, версионировать, тестировать и модифицировать контролируемым образом.
С виду это выглядит как программная среда. Внутри же это наш ответ на семантическую проблему: вместо того чтобы принуждать сложную реальность к готовой модели, мы предоставляем себе гибкий язык для описания этой реальности, такой, какая она есть на самом деле.
Это возвращает нас к скорости.
Что значит быть «быстрым» в цепочке поставок?
Если скорость определяется как «время до того, как поставщик программного обеспечения сможет объявить о запуске в эксплуатацию согласно своему чек-листу», то преднастроенные системы часто кажутся быстрее. План проекта оптимизирован для достижения этой вехи. Каноническая модель разработана для быстрого заполнения. Обучающие материалы и лучшие практики ориентированы на эту конкретную цель.
Однако, если скорость определяется как «время до того, как у нас будет работающий автоматизированный поток решений, которому мы доверяем реальные деньги», картина меняется.
В программируемом подходе последовательность проекта обычно выглядит следующим образом:
Сначала настраиваются надежные ежедневные извлечения данных из существующих систем, без попыток принудительно вписать их в новую каноническую модель. Это по-прежнему сложная работа, но в основном связана с подводными работами: извлеките исходные данные в их сыром виде, со всеми их недостатками.
Затем, в программируемой среде, шаг за шагом выражается бизнес-логика: очистка и согласование данных; формулирование ограничений и приоритетов; моделирование неопределенности; и, наконец, вычисление конкретных решений, таких как объемы заказов, производственные планы или варианты распределения. Поскольку эта логика написана на специализированном языке, цикл изменений короткий: специалист по цепочке поставок может корректировать её ежедневно или еженедельно по мере появления граничных случаев и новых требований.
Наконец, эти решения внедряются в режиме двойного запуска: сравниваются предложения скриптов и фактические действия планировщиков, измеряется финансовое воздействие и вносятся соответствующие корректировки. Когда уровень уверенности станет достаточным, пусть скрипты берут на себя управление для тщательно отобранных частей портфеля.
Ключевой момент в том, что эта последовательность итеративна. Ни в какой момент мы не ожидаем, что первая версия логики будет идеальной. Также мы не ожидаем, что среда останется неизменной. Вместо этого мы предполагаем, что правила принятия решений придется существенно переписывать каждый год или два по мере того, как ассортимент, сеть, обещания по обслуживанию и конкурентная среда изменяются.
В таком контексте основным показателем «скорости» становится не дата первого запуска, а среднее время изменения: сколько времени требуется, чтобы адаптировать систему, когда бизнес решает изменить свои операционные подходы.
Если политика ценообразования кодируется в монолитной системе планирования за шесть месяцев, то не имеет значения, что первоначальная реализация была завершена вовремя три года назад.
Почему программируемость становится быстрее на протяжении всего срока службы системы
Снаружи программируемость выглядит обременительной. Конечно, написание кода должно занимать больше времени, чем настройка существующего интерфейса?
В простых случаях это может быть так. Если цепочка поставок относительно небольшая, стабильная и близка к эталонной модели поставщика, то преднастроенное решение действительно может быстро достичь приемлемого состояния. Многие компании не используют свои инструменты планирования интенсивно; они применяют их как структурированные электронные таблицы с более красивыми интерфейсами и некоторыми оповещениями. В таком контексте готовый подход может быть адекватным и, в узком смысле, быстрее.
Картина меняется кардинально, как только мы переходим к ситуациям, когда:
-
большие и разнородные (множество ERP, разные бизнес-подразделения, множество видов продуктов и каналов),
-
нестабильные (ассортименты, сроки выполнения и обещания по обслуживанию меняются часто),
и амбициозные (ориентированы на высокий уровень автоматизации, а не просто на поддержку принятия решений).
В этих случаях преднастроенные решения сталкиваются с тремя структурными вызовами.
Во-первых, семантический разрыв слишком велик. Чем больше исключений и локальных конвенций, тем больше требуется адаптировать каноническую модель. Каждая такая адаптация превращается в прием конфигурационного трюка, кастомное расширение или побочный процесс. Со временем система накапливает слои особых случаев, которые трудно понять и еще труднее очистить.
Во-вторых, стоимость изменений контролируется извне. Изменение логики крупной системы планирования обычно включает несколько уровней: внутренний IT, внешние консультанты, а иногда и самого поставщика. Существуют циклы релизов, протоколы тестирования и процессы управления, созданные для безопасности, а не для гибкости. Это понятно, но означает, что даже разумные, умеренные изменения могут занимать месяцы.
В отличие от этого, программируемый подход требует большую часть затрат на начальном этапе: вы должны принять, что по сути вы пишете программное обеспечение. Но как только у вас появляется специализированная среда для этого ПО — такая, которая достаточно специализирована, чтобы быть доступной для экспертов по цепочке поставок, и при этом достаточно выразительна, чтобы описывать реальность бизнеса — экономика изменений переворачивается.
Добавление нового ограничения, интеграция нового источника данных или пересмотр способа управления акциями становится вопросом редактирования скриптов, а не переговоров о новой фазе внедрения. Поскольку логика принятия решений явная, вы можете версионировать её, тестировать и возвращать к предыдущим версиям. Поскольку она централизована, а не разбросана по конфигурационным таблицам и побочным файлам, вы можете рассмотреть её в целом.
На протяжении всего срока службы системы способность быстро меняться обычно перевешивает единовременное преимущество быстрого первоначального запуска.
Это не отказ от мейнстримного программного обеспечения
Было бы ошибкой читать это как аргумент против всего готового программного обеспечения для цепочки поставок. Эти системы решают многие задачи хорошо. Они обеспечивают надежную обработку транзакций; они интегрируются с широкой экосистемой; они предлагают пользовательские интерфейсы, модели безопасности, возможность аудита и функции соответствия, которые было бы дорого воспроизводить с нуля.
И это не призыв к тому, чтобы каждая компания строила всё самостоятельно с использованием универсальных языков программирования. Этот путь быстро приводит к собственной хрупкости, когда появляется множество специализированных сценариев без дисциплины.
То, что я предлагаю, отличается: программный ядро для логики принятия решений, окруженное лучшими готовыми системами для всего остального.
Другими словами, используйте ваш ERP, WMS и TMS для того, в чем они хороши: для записи фактических событий, обеспечения простых бизнес-правил и оркестрации рабочих процессов. Используйте специализированные системы планирования там, где их стандартные функции действительно соответствуют вашим потребностям. Но не ожидайте, что эти готовые инструменты станут местом, где будет жить ваша самая важная, динамичная, дифференцирующая логика принятия решений.
Для этого вам нужно что-то, что с самого начала признаёт, что ваша цепочка поставок уникальна, что она изменится, и что каждая серьезная инициатива в конечном итоге столкнется с семантическими деталями, которые ни один шаблон не предусматривал.
Специальный язык, ориентированный на определённую область, такой как Envision, является одним из возможных ответов. Это язык, который мы разработали и усовершенствовали в Lokad на протяжении многих лет, чтобы дать экспертам в цепочке поставок возможность непосредственно выражать и поддерживать свою логику, без прохождения через слои посредников.
Другие поставщики предлагали аналогичные идеи в различных формах; важно не то, что они называются «DSL», а принцип, лежащий в основе: логика принятия решений должна быть первоклассной, программируемой и находиться под контролем тех, кто понимает экономику бизнеса.
Переосмысление скорости
Если мы переопределим скорость как «насколько быстро мы можем запустить в производство надёжные, автоматизированные решения и насколько быстро можем их пересмотреть при необходимости?», вывод становится неизбежным.
В краткосрочной перспективе готовые комплекты решений часто кажутся быстрее, поскольку они минимизируют видимую работу в начале и оптимизированы для торжественного запуска. В среднесрочной и долгосрочной перспективе их жесткость и стоимость изменений делают их медленнее именно там, где скорость наиболее необходима: когда меняется бизнес-среда.
Программный подход требует больше усилий на начальном этапе, но он окупается каждый раз, когда реальность отклоняется от первоначальных предположений — то есть, постоянно. В мире, где неопределённость является нормой, а не исключением, такая скорость важнее, чем количество недель, запланированных для реализации.
Таким образом, вопрос не в том, хотите ли вы писать программное обеспечение для своей цепочки поставок. Если ваш бизнес достаточно велик и сложен, вы уже это делаете — через конфигурации, электронные таблицы, локальные скрипты и ручные соглашения. Единственный настоящий вопрос заключается в том, хотите ли вы, чтобы это программное обеспечение было явным, последовательным и находилось под вашим контролем.
Мой ответ ясен: если нам действительно важна скорость, цепочка поставок должна быть программируемой.
