Цепочки поставок включают набор разнородного корпоративного программного обеспечения. Эти слои программного обеспечения постепенно, а иногда и бессистемно, внедрялись в течение последних четырех десятилетий1. Почтенный EDI (электронный обмен данными) может находиться рядом с прототипом блокчейна. Такие системы в основном управляют рутинными, но необходимыми аспектами цепочки поставок: производством, хранением, транспортировкой, выставлением счетов, соблюдением нормативных требований и т.д.

Сколько людей нужно, чтобы заменить лампочку в цепочке поставок?

Эти системы были внедрены не с целью обеспечения чистой среды данных для R&D. Этот факт сам по себе объясняет, почему большинство инициатив по прогнозированию, а в целом и большинство проектов в области data science терпят неудачу в цепочке поставок. Судя по анекдотическим примерам, обычно физически быстрее переместить все товары, находящиеся на складе, чем перенести всю IT-инфраструктуру на новое место.

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

  • Консультанта, который курирует проект и оказывает помощь высшему руководству.
  • Специалиста по IT-инфраструктуре, который оценивает риски, связанные с дополнительной IT-инфраструктурой.
  • Администратора баз данных, который определяет соответствующие таблицы в нужных системах.
  • Специалиста по ETL, который разрабатывает конвейер, обеспечивающий логистику данных.
  • IT-консультанта, который оказывает дополнительную помощь с придирчивыми IT-решениями.
  • Координатора проекта, который налаживает взаимодействие между IT-специалистами и экспертами в области цепочек поставок.
  • Бизнес-аналитика, который составляет большинство отчетов для руководства.
  • Data Scientist, который займется частью предиктивного моделирования.
  • Техподдержку поставщика, которая справляется с ошибками во внедряемых технологиях.
  • Продавца поставщика, который управляет ожиданиями и допродает «продукты» в процессе.
  • Практика в области цепочек поставок, представляющего «голос клиента».
  • Руководителя цепочек поставок, который является инициатором проекта.

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

Более того, третьи стороны, консультанты, IT-компании и поставщики технологий руководствуются собственными интересами, которые не совпадают с целями компании. На каждом этапе процесса существует возможность заработать на создании дополнительного трения2. Это позволяет начинать с небольшого предварительного бюджета, который, как “удивительно”, стабильно растет со временем по мере того, как в проект необходимо вкладывать всё больше ресурсов.

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

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

Классическое корпоративное программное обеспечение не совместимо с цепочками поставок потому что «конфигуратор» недостаточно выразителен для решения огромного разнообразия проблем, с которыми сталкиваются цепочки поставок. Необходим язык программирования3. К сожалению, универсальные языки программирования, такие как Python, не соответствуют роли специалиста по цепям поставок. Требования к навыкам слишком высоки, и эти роли в компании сводятся к инженерам-программистам. В этом нет ничего плохого, но экспертизу в области цепочек поставок приходится восстанавливать с помощью специалистов, не являющихся программистами. Скоро почти все перечисленные выше роли станут частью инициативы.

Однако, чтобы специалист по цепям поставок мог справляться с таким количеством задач, необходима специализированная среда программирования: такая, которая позволит ему решать задачи предиктивной оптимизации цепочек поставок с минимальными усилиями4. Технологическим ответом Lokad на эту проблему стал Envision, специализированный язык.

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

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

Основная ценность специалиста по цепям поставок заключается в умении работать на системном уровне, охватывая всю цепочку поставок — от исходных электронных записей до стратегии, разработанной высшим руководством компании. Однако, вдали от образа одиночки, специалист получает значительную поддержку. IT обеспечивает доступ к необходимым данным (без попыток предварительной обработки данных). Операционные отделы документируют существующие процессы, эксплуатационные ограничения и различные накладные расходы. Маркетинг разъясняет понятийные издержки, которые не отражены в бухгалтерских книгах, например, расходы, связанные с дефицитом товара. Высшее руководство формулирует видение, разъясняя, что именно специалист должен оптимизировать, и так далее.

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


  1. Чтобы приоткрыть завесу того, как может выглядеть разработка программного обеспечения для цепочек поставок через пару столетий, я рекомендую A Deepness in the Sky (1999) — одну из лучших книг Вернора Винжа. Появление археологов-программистов в качестве устоявшейся профессии может произойти даже при нашей жизни. ↩︎

  2. Часто дополнительное трение начинается ещё до самой инициативы в цепочке поставок. Привлечение консультантов для помощи компании с процессами RFI и RFQ почти наверняка удвоит как задержки, так и бюджеты↩︎

  3. Сегодня потребность в программируемости удовлетворяется с помощью Microsoft Excel. Подавляющее большинство современных цепочек поставок управляются через электронные таблицы, даже если якобы внедрены более совершенные системы, такие как APS (расширенное планирование и диспетчеризация). ↩︎

  4. Многие IT-концепции лучше абстрагировать от специалистов по цепям поставок. Например: объектно-ориентированное программирование, кодировка текста, управление пакетами, управление сетью, управление дисками, управление памятью, администрирование Linux, администрирование баз данных, восстановление после сбоев, API-протоколы, распределённые вычисления, многопоточность, инъекционные атаки, атаки по побочным каналам и т.д. ↩︎

  5. Рассел Акофф иллюстрирует системное мышление на примере конструкции автомобиля. Если бы CEO автопроизводителя попросил своих сотрудников для каждой детали автомобиля выбрать лучшую, имеющуюся на рынке (лучшие тормозные колодки, лучшие оси и т.д.), то сборка всех этих деталей не привела бы к созданию полноценного автомобиля. Детали не подошли бы друг к другу. «Лучшая» деталь имеет смысл только в контексте всего автомобиля, а не изолированно. ↩︎

  6. Сколько покупать? Сколько производить? Когда повышать или снижать цену? Какое количество запасов перемещать? И т.д. ↩︎