Обслуживание оптимизации

Joannes Vermorel

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

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

Оптимизация цепочки поставок — это особый случай, поскольку поставщики (не Lokad) «успели» исключить обслуживание. Этот «успех», однако, определённо не тот, который ожидали их клиенты.

Начиная с 1980-х годов, поставщики (подобно Lokad, но за десятки лет до) поставляли программное обеспечение для автоматизации решений в цепочках поставок³. С тех пор почти каждая крупная компания приобрела не одно, а зачастую сразу несколько таких решений. Даже ERP-системы, то есть Enterprise Resource Planning, получили своё название в 1990‑х годах благодаря стремлению автоматизировать процесс «планирования». Иначе ERP получили бы название ERM, обозначающее Enterprise Resource Management.

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

С точки зрения поставщиков программного обеспечения такие неудачи приносят прибыль. Поставщик получает лицензионные сборы, возможно, в виде многолетнего обязательства (в случае SaaS). Поскольку решения не работают — по крайней мере, не в части оптимизации — требуется мало или совсем не требуется обслуживания. Клиентов не волнуют возможности программного обеспечения, которым они все равно не пользуются, и, следовательно, они не оказывают существенного давления на поставщика. От исходного решения остаётся лишь фрагмент — обычно, тонкий шлюз для ввода данных, управляющий базовыми правилами автоматизации, интегрированными в системы компании (например, min/max настройки для артикулов).

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

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

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

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

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

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

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

• Прозрачность должна поддерживаться. Специалист отвечает за «открытость» числового алгоритма. Это подразумевает обучение команд для достижения достаточного уровня понимания, что, в свою очередь, позволяет максимально эффективно использовать автоматизацию, предоставляемую алгоритмом. По мере смены кадров новых сотрудников необходимо (пере)обучать.

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

Таким образом, хотя числовой алгоритм может оставаться без присмотра неделями⁶, его актуальность неизбежно снижается со временем. Поэтому для поддержания его релевантности требуются постоянные инженерные ресурсы. Несмотря на недавний прогресс в области искусственного интеллекта, разработка программного обеспечения, способного к самообслуживанию, остаётся вне досягаемости современных технологий. Возможно, это спорно, но задача кажется столь же сложной, как и достижение искусственного общего интеллекта.

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

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

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