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