Влюбитесь в проблему, а не в решение
Каждый отдельный SKU требует обыденных ежедневных решений, таких как пополнение запасов или изменение базовой цены. Естественно, полное соблюдение ручного процесса для этих решений требует больших трудозатрат, и компании принимают различные решения по автоматизации на базе программного обеспечения. Самая распространенная стратегия проектирования этих решений заключается в попытке воспроизвести — посредством программного обеспечения — нечто, по сути, похожее на существующую «человеческую» практику.
Этот подход не нов. Можно утверждать, что именно на него делали акцент экспертные системы, которые в основном пришли в немилость во время второго «зимы искусственного интеллекта» в конце 1980-х и начале 1990-х годов. Тем не менее, хотя модное слово экспертные системы уже не используется — я не думаю, что сейчас есть какой-либо (значительный) поставщик программного обеспечения, который позиционировал бы себя как поставщик «экспертных систем» — я не могу не заметить, что базовая концепция остается распространенной в большинстве отраслей.
Действительно, большинство поставщиков программного обеспечения, а также большинство внутренних инициатив, застряли в перспективе воспроизведения существующей практики, которая сама возникла путём имитации оригинального полностью ручного процесса. Экспертная система прошлого, возможно, была заменена более современной версией алгоритма глубокого обучения, однако общая парадигма остаётся (почти) неизменной.
В управлении цепями поставок этот паттерн поразителен, поскольку почти вся практика застряла на подходах, возникших в мире, где компьютеры просто ещё не существовали. Например, многие — а даже большинство компаний — до сих пор различают плановую группу, людей, которые составляют прогноз спроса для каждого продукта, и группу снабжения, людей, оформляющих заказы на закупку на основе прогноза спроса. Такой подход возник из тейлористской перспективы, согласно которой сотрудники должны были быть как можно более специализированными для достижения максимальной эффективности.
Однако, когда речь заходит об оптимизации цепей поставок, тейлоризм противоречит реальности цепей поставок. Реальность диктует, что будущий спрос не является независимым от текущих решений. Если передается значительно больший заказ на закупку, что приводит к гораздо более низкой цене закупки за единицу, то и розничная цена может быть снижена, потенциально вытесняя конкурентов с рынка, и таким образом значительно увеличивая спрос. В мире без компьютеров тейлоризм был наименее худшим вариантом, потому что, хоть и не был очень эффективен, он был чрезвычайно масштабируем. Однако, в мире с компьютерами ситуация требует более интегрированного подхода, который даже грубо учитывает такие обратные связи. Как говорится, лучше примерно правильно, чем точно неправильно.
При опросе клиентов или потенциальных заказчиков по этому вопросу ситуация часто оказывается неясной. Решения, изначально разработанные для репликации полностью ручного процесса, действуют так долго, что люди утратили из виду более фундаментальные аспекты проблемы, которую они пытаются решить. Слишком часто люди становятся специалистами именно в решении, которое уже существует, а не специалистами по проблеме, с которой сталкивается компания. Таким образом, пытаясь улучшить ситуацию, все мысли буквально закреплены за тем, что воспринимается как недостатки текущего решения. Из-за этого предвзятого взгляда подходы к более глубокому пересмотру проблемы воспринимаются как рисковые как руководством, так и их командами. Напротив, вариант постепенного улучшения существующего решения считается безопасным; или, по крайней мере, намного безопаснее.
Если оглянуться назад, история корпоративного программного обеспечения, к сожалению, полна рассказов о поставщиках, навязывающих свой «новый путь» ведения дел, который оказался гораздо более утомительным и жестким, чем старые процессы, приводящим к нулевому или даже отрицательному приросту производительности. По моим наблюдениям, большинство компаний, управляющих крупными цепями поставок, за последние два десятилетия существенно не сократили численность офисных сотрудников, поддерживающих их цепи поставок, в то время как количество синих воротничков было агрессивно автоматизировано за счет лучших заводов или лучших складов. Эти печальные события привили здоровую дозу скептицизма в экосистему против изнуряющих «реорганизаций» ради приведения в соответствие с новой программной системой.
Однако, я также отмечаю, что руководители цепей поставок обычно значительно недооценивают риски, связанные с любой «умной» программой, то есть с любой программой, корректность которой не может быть полностью и лаконично определена. Действительно, большинство корпоративного программного обеспечения представляет собой не что иное, как приложения CRUD, то есть кропотливых бухгалтеров рутинных списков, таких как: счета, поставщики, продукты, платежи и т.д.
Достичь коммерческого успеха с «тупым» программным обеспечением уже достаточно трудно — многим компаниям в сфере электронной коммерции уже сложно поддерживать высокий уровень доступности их веб-фронтенда — но когда в дело вступают прихотливые компоненты, такие как компоненты машинного обучения, добиться успеха становится намного сложнее. Немногие компании открыто говорят об этом, но когда речь заходит о машинном обучении, неудачи доминируют в этой области. Однако ситуация не так мрачно, как может показаться, потому что недостатки ограничены, в то время как преимущества — нет.
Таким образом, в долгосрочной перспективе компании, которые пробуют и терпят наибольшие неудачи, оказываются теми, кто достигает наибольшего успеха.
Тем не менее, риски, связанные с программным обеспечением, вполне реальны, и, безусловно, нет смысла еще больше увеличивать эти риски. Однако, придерживаться парадигмы репликации ныне устаревшей ручной практики неизбежно приводит к ряду случайных осложнений. Например, поскольку плановая группа и группа снабжения раздельны, возникает целый класс проблем, предназначенных исключительно для синхронизации этих групп. Как правило в разработке программного обеспечения увеличение требований на 25% приводит к увеличению затрат на 200%. Решение этих осложнений резко увеличивает затраты, следовательно, на практике риск возрастает, поскольку компании, как правило, прекращают — что является здравой реакцией — инициативы, разрывающие их бюджеты или сроки.
Таким образом, сталкиваясь с полувековым вопросом: приспосабливать ли программное обеспечение под организацию или организацию под программное обеспечение, разумно начать с чистого листа и сначала определить, какие высокоуровневые проблемы необходимо решить. Измеряется ли производительность в процентах? Или в долларах? Правильно ли мы учитываем долгосрочные последствия? Например, обучение клиентов покупать только во время распродажи. Основывается ли подход на использовании человеческого вклада или просто его потребляет? Управляется ли практика привычками или неизбежной необходимостью? Например, две модные коллекции в год против двух урожаев в год.
Глубокое понимание проблемы, которую нужно решить — что явно отличает проблему от её текущего решения — является ключом к определению того, стоит ли сохранять существующее решение или его следует упростить в пользу новых возможностей программного обеспечения, требующих более простого и прямого разрешения проблемы.
