Поддержка оптимизации

Joannes Vermorel

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

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

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

С 1980-х годов поставщики (как Lokad, но десятилетиями ранее) предоставляют программное обеспечение для автоматизации принятия решений в цепи поставок³. С тех пор почти каждая крупная компания приобрела не одно, а часто несколько таких решений. Даже ERP-системы, что означает планирование ресурсов предприятия, получили свое название в 1990-х годах от этой амбиции автоматизировать часть «планирования». В противном случае ERP-системы назывались бы ERMs, обозначающими управление ресурсами предприятия.

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

Такие сбои приносят прибыль поставщикам программного обеспечения. Поставщик получает лицензионные платежи, возможно, в форме многолетнего обязательства (в случае SaaS). Поскольку решения не работают - по крайней мере, не работает часть оптимизации - требуется незначительное или совсем нет обслуживание. Клиенты не интересуются возможностями программного обеспечения, которые они все равно не используют, и, следовательно, они не оказывают большого давления на поставщика. Изначального решения остается только фрагмент, который обычно представляет собой тонкий шлюз для ввода данных, предназначенный для управления основными правилами автоматизации, интегрированными в системы компании (например, настройки минимума/максимума для SKU).

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

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

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

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

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

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

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

• Необходимо поддерживать прозрачность. Специалист отвечает за “белый ящик” числового рецепта. Это подразумевает обучение команд, чтобы они имели достаточный уровень понимания, что позволяет им максимально использовать автоматизацию, предоставляемую числовым рецептом. При смене команд новым участникам необходимо быть (пере)обученными.

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

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

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

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

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