00:00:00 Глава о развертывании и структура практикующего специалиста
00:04:35 Простота превосходит сложность основной цепочки поставок
00:09:10 Автоматические решения позволяют избежать отклонений от рабочего процесса
00:13:45 Управление изменениями в основном устраняет ненужную работу.
00:18:20 Окончательные решения резко сокращают внедрение ИТ.
00:22:55 Загрязнение корпоративных данных — ответственность поставщика.
00:27:30 Выживание доказывает, что данных уже достаточно.
00:32:05 Учёные, занимающиеся цепочками поставок, владеют прибыльными решениями
00:36:40 Единый разум предотвращает фрагментированные числовые рецепты
00:41:15 Объясняемость требует владения и «белого ящика»
00:45:50 Объяснения начинаются тогда, когда решения появляются.
00:50:25 Безумные решения выявляют недостающие ограничения и поля
00:55:00 Прибыльные решения могут сломать старые привычки
00:59:35 После развертывания подразумевается техническое обслуживание против смещения конструкции.
01:04:10 Постоянное совершенствование со временем расширяет возможности принятия решений.
01:08:45 Никакой ценности без решений в эндшпиле.
01:13:20 Десять недель должны показать реальный прогресс
01:17:55 Доверие занимает месяцы; сначала тестируйте самые сложные проблемы
Резюме
Джоаннес Верморель и Конор Доэрти продолжают обсуждение Введение в цепочку поставок по главам. Глава десятая посвящена внедрению: практической работе по внедрению решений автоматизированной цепочки поставок в производство, обеспечению их надежности и обеспечению того, чтобы они меняли повседневные операции, а не оставались прототипом.
Расширенное резюме
Это обсуждение развертывания устраняет массу модной чепухи в корпоративном программном обеспечении. Центральный момент не сложен: цель инициативы по цепочке поставок не состоит в создании информационных панелей, рабочих процессов, карт показателей или других декоративных артефактов управления. Его цель – вырабатывать лучшие решения. Если так называемое развертывание не заканчивается принятием автоматических, проверяемых и экономически обоснованных решений, то многое из того, что ему предшествует, в лучшем случае является церемонией.
Постоянная ошибка в отрасли — путать сложность с изощренностью. Многие компании используют уровни сегментации, переопределения, оповещений и рабочих процессов утверждения, потому что эти вещи выглядят разумными. На практике они часто создают больше кода, больше исключений, больше двусмысленности и больше возможностей для сбоев. То, что кажется «более безопасным», становится труднее поддерживать, медленнее улучшать и легче обвинять всех и никого. Напротив, система, изначально предназначенная для выработки окончательных решений, сложнее в принципе, но проще на практике.
Еще один важный момент касается данных. Фирмам часто говорят, что их данные слишком запутаны, чтобы их можно было автоматизировать. Это оправдание сохранилось, потому что оно полезно поставщикам, чьи системы выходят из строя. Но любая компания, продолжающая масштабный бизнес, уже обладает данными, достаточно хорошими для управления своей цепочкой поставок, иначе она давно бы обанкротилась. Проблема не в том, аккуратны ли данные. Реальные бизнес-системы никогда не бывают такими. Вопрос в том, достаточно ли компетентны люди, создающие решение, чтобы иметь дело с реальностью, а не требовать воображаемого набора данных.
Роль специалиста по цепочке поставок, как описано здесь, не является узкой. Это не просто подготовка данных, моделирование или оптимизация по отдельности. Это владение полным числовым рецептом, от исходных данных до окончательного решения. Разделение этой ответственности между специалистами может показаться эффективным, но обычно оно приводит к провалам. Что необходимо, так это один разум, который достаточно хорошо понимает всю цепочку, чтобы связать ее и объяснить.
Сама объяснимость трактуется здесь скорее практически, чем театрально. Вы не объясняете абстракции ради них самих. Вы объясняете решения. И объяснение должно, наконец, обналичиться в экономике: почему такой порядок, почему такая цена, почему сейчас, почему не позже? Если ответ нельзя сформулировать с точки зрения выгод, потерь, рисков и компромиссов, то объяснение, вероятно, носит декоративный характер.
Более общий урок заключается в том, что развертывание следует оценивать по амбициям и скорости. В первую очередь нацеливайтесь на самую сложную реальную проблему, а не на легкую игрушечную задачу. Требуйте полезных результатов через несколько недель, а не расплывчатых обещаний через годы. Если поставщик не может быстро продемонстрировать способность принимать решения, промедление не излечит некомпетентность.
Полная стенограмма
Conor Doherty: С возвращением. Это 10-я серия очень особенного сериала, в котором мы с Джоаннесом берем его новую книгу Введение в цепочку поставок и обсуждаем идеи, глава за главой. Теперь, в отношении этой конкретной серии, я принимаю очень специфическую позу. Как вы знаете, я притворяюсь не человеком, работающим в Lokad. Я никогда не слышал о количественной цепочке поставок. Я, конечно, не знаю Джоаннеса и не работал с ним почти четыре года.
Я притворяюсь одним из примерно 10 миллионов практикующих в мире, которые могут увидеть эту книгу, заинтересоваться, начать читать, а затем задать вопросы. Итак, сегодня глава 10. Это означает, конечно, что до этого их было девять. Я настоятельно рекомендую вам посмотреть их в первую очередь, потому что то, что мы обсуждали сегодня, наверняка будет основано на материале, рассмотренном в предыдущих эпизодах.
И на этом, Джоаннес, давай начнем. Глава 10, развертывание. Теперь я немедленно нарушу позицию, которую только что всем обещал, и скажу, что, знаете, Конор, который здесь работает, четвертая глава — это экономика, а восьмая глава — это решения, они, наверное, мои личные фавориты. Пожалуй, именно о восьмёрке я получаю больше всего отзывов, извините, от людей, знающих Lokad.
Но если я искренне думаю об этом с точки зрения практикующего специалиста, например, человека, который читает книгу, читает первые несколько глав и думает: «Мне очень нравится этот подход. Мне очень нравится идея количественного финансового ранжирования решений. Я действительно думаю о том, каков период полураспада решения. То, что я делаю сейчас, открывает или закрывает решения позже?» Мол, я полностью за это. У них возникнет очень простой вопрос: «Как, черт возьми, это выглядит?» Например, что, если мой начальник скажет мне: «Это отличная идея, но как она будет выглядеть? Каковы роли? Что от нас требуется? Какие данные? Сколько времени это займет? Каковы возможные точки отказа?»
Глава 10 — это то место, где вы на самом деле углубитесь в это. Итак, мы собираемся поговорить о всех тонкостях этого, но для начала, на высоком уровне, по вашему мнению, что заставляет развертывание действительно работать, а что приводит к катастрофическому провалу?
Joannes Vermorel: Что касается Lokad, то компании, в которых мы добиваемся успеха, по сути, являются теми, которые позволяют нам продолжать работу. И это может звучать глупо, но по сути это не имеет ничего общего со зрелостью. Итак, вы видите, как некоторые обсуждают со многими директорами цепочек поставок и говорят: «О, нам нужна некоторая степень зрелости», и здесь я не согласен, потому что о какой зрелости мы говорим?
Если под зрелостью вы подразумеваете приверженность теориям разорванной цепочки поставок, то дальнейшее движение по этому пути не поможет вам действительно добиться успеха с Lokad, но и просто добиться успеха в цепочке поставок. Видите ли, позиция, которую я придерживаюсь в этой книге, я имею в виду, что эта книга представлена как новое введение в цепочку поставок. Поэтому я не обсуждаю подробно все, что не работает, но вы можете читать это как то, что работает, в отличие от общепринятой теории цепочки поставок, которая, по сути, представляет собой длинный список или набор вещей, которые не работают на практике.
Итак, есть все эти вещи, такие как точечные прогнозы, микроменеджмент на уровне обслуживания, подход, при котором вы будете управлять своей цепочкой поставок с помощью предупреждений и исключений, все на основе правил, ручное переопределение всего и т. д. и т. п. Таким образом, суть в том, что когда Lokad добивается успеха, по сути, это места, которые просто дают нам хороший шанс попробовать что-то, что обычно на порядок проще, чем то, что влечет за собой классическая цепочка поставок.
Потому что проблема в том, что, поскольку основная теория цепочки поставок совершенно несостоятельна, на практике она превращается в кошмар, полный сложностей. Видите ли, как только у вас действительно будет правильная теория, тогда все будет проще. Программное обеспечение проще, математика проще, логика проще, а результат получается гораздо более четко, что похоже на решения, оптимизированные, скорректированные с учетом риска, гораздо более четко в конце инициативы.
Итак, я бы сказал, что, возможно, если бы и был один вывод, то это не следует развивать теорию, которая в конечном итоге потерпит неудачу, независимо от того, кто отвечает за ее реализацию. В Lokad мы стараемся убедить наших потенциальных клиентов и клиентов действительно использовать то, что будет работать. Но в конечном итоге, если нам дают прямые указания, добиться успеха против воли клиента становится очень сложно.
Conor Doherty: Знаете, в продолжение темы, просто чтобы уточнить, извините, когда вы говорите “на порядок”, вы просто приводите цифры, но, скажем, на порядок проще, вы имеете в виду, что с точки зрения развертывания это на порядок проще? Или вы имеете в виду, что с точки зрения результата с этим на порядок проще справиться?
Проще говоря, сколько дней нужно, чтобы запустить систему? Сколько человеко-часов вам нужно вложить? Насколько необходимы нарушения? Я имею в виду, например, пример, пожалуйста.
Joannes Vermorel: Если вы начнете, скажем, с чего-то вроде ABC-анализа, который вам нравится, или с любой выдуманной сегментации, то вы увидите, что вам это не нужно. Это как псевдоочевидное решение несуществующей проблемы. Поэтому люди думают: «О да, нам нужно подойти к этому через изменение качества обслуживания или что-то в этом роде, через сегментацию». Короткий ответ: нет, вам не нужна эта сегментация.
И если нас заставят сегментировать, то в итоге у нас будет так много строк кода, которые будут: если категория A, то это, это и это; если категория Б, то это и это и это. Если у нас есть продукт, который недавно перешел из категории B в категорию A, нам нужно иметь то, то и это. Если он недавно перешел из А в Б, значит, нам что-то нужно. Итак, вы видите, что это всего лишь идея, которая, по-видимому, должна быть принята господствующей теорией, и ей нравится сегментация.
И эта штука, с точки зрения кода, будет каскадом превращаться в лабиринт пограничных случаев, а это означает больше строк кода, больше ошибок, больше, я бы сказал, безумных решений, которые в конце дня выйдут из конвейера данных. И поэтому вам нужно больше времени, чтобы люди действительно просмотрели цифры. Вам нужно больше отчетов, чтобы хотя бы понять цифры и т. д. и т. п. Видите ли, эти вещи накладываются друг на друга.
И то, что делает Lokad, может показаться сложным, как вероятностное прогнозирование, но это не так, потому что это способ устранить буквально целые классы проблем и выразить всего в нескольких строках кода то, что в противном случае потребовало бы тысяч строк кода. В этом вся суть. Я бы сказал, что нам нужно стремиться к тому, что на самом деле просто, а не к тому, что кажется простым, что на самом деле является упрощенным и, таким образом, приводит к множеству правил, крайних случаев и, я бы сказал, к последующим осложнениям.
Conor Doherty: Итак, в продолжение этого, и я хочу очень внимательно следить за тем, чтобы не объединять слишком много идей вместе, поэтому просто сформулирую это немного более конкретно, одна из вещей, о которой вы спорите в главе 10, я снова перефразирую, но это очень верно: вы утверждаете, что в контексте развертывания, конкретно с точки зрения конечного результата, вы не стремитесь к лучшей наглядности. Вы не гонитесь за лучшими информационными панелями. Вы не гонитесь за лучшими прогнозами.
Целью развертывания, безусловно, с точки зрения оптимизации цепочки поставок, является выработка автоматических, проверяемых решений, например, заказов на поставку, перемещений, графиков или изменений цен, которые затем записываются обратно в ваши операционные системы. Да. Это проще. Именно об этом вы и говорите.
Joannes Vermorel: Опять же, и самое главное - без присмотра. Так, например, если вы решите так сказать: «О, планка такая высокая, без присмотра. Вы действительно хотите, чтобы все было правильно, без промежуточных шагов, прямо к хорошему». И я говорю да, потому что какая альтернатива?
Альтернативой является создание очень сложного рабочего процесса, в котором люди могут вмешиваться, выполнять всевозможные изменения, и в конце концов мы генерируем распределение ресурсов и принимаем фактические решения. Сколько я куплю? Сколько я производю? Куда мне положить акции? Движу ли я цену вверх или вниз? Итак, если вы решите, что мы сразу же примем решения без присмотра, очевидно, что вы хотите сказать: «Хорошо, я бы не принял решения без присмотра, которые не являются чем-то отличным». Обычно они должны быть намного лучше, чем то, что люди могут производить вручную.
Я говорю, хорошо, без проблем. Это абсолютно справедливый критерий. И я хочу сказать, что это то, к чему мы должны стремиться с первого дня. И вы видите, если вы попытаетесь, вы скажете: «Хорошо, мы хотим сделать это обслуживаемым способом, с многоэтапным рабочим процессом» и т. д., то ваш процесс, который должен был быть оптимизацией цепочки поставок, перерастает в проектирование рабочего процесса, и тогда он становится, как вы видите, просто другим объектом.
И, по сути, вместо того, чтобы тратить время на вопрос: «Разрабатываю ли я систему, которая действительно максимизирует норму прибыли от каждого выделенного ресурса, который я распределяю через свою цепочку поставок?» Это игра, в которую мы играем, она превращается во что-то, где вам нужно изучить мнение каждого отдельного человека, а затем вам нужно провести оптимизацию производительности, потому что рабочий процесс заключается в том, чтобы «позволить людям вмешаться», поэтому он отнимает время.
Итак, здесь возможны всевозможные компромиссы. Если вы дадите больше гибкости, люди могут сказать: «О, тогда у меня будет больше рычагов», но тогда это создаст сложности, потому что тогда ваши сотрудники могут тратить слишком много времени на рабочий процесс. И затем, если решения в финале окажутся фиктивными, чья в этом вина? Это полностью размывает ответственность.
Особенно, если в рабочем процессе задействовано полдюжины человек, постепенно делающих небольшие повороты, тогда становится чрезвычайно сложно указать, кто виноват. Поэтому вам необходимо провести причинно-следственный анализ по всем этим отделам. И вы видите, именно так мы начали с чего-то вроде: «Давайте сразу перейдем к решениям, которые максимально выгодны», с чего-то, от чего мы полностью отвлеклись, где мы начинаем разрабатывать рабочий процесс и пользовательские интерфейсы, мониторинг того, что делают люди, оптимизацию производительности и т. д.
Видите ли, именно так вы можете получить что-то на порядок медленнее и сложнее, просто потому, что вы на самом деле сделали несколько вещей, которые изначально выглядели проще. Нет, нет, это не так. Итак, еще раз, для нас настоящим критерием успеха является способность сразу идти к максимизации прибыльности, без отступлений от рабочих процессов, без отступлений от выдуманных числовых артефактов, таких как сегментация и тому подобное.
В конечном счете, тебя не волнует ABC. Вас волнует, действительно ли я максимизирую отдачу от инвестиций? Не имеет значения, нарезаю ли я свои SKU на занятиях, через это, через это или через что-то еще. Я имею в виду, что если вы хотите, опять же, максимизировать норму прибыли в долгосрочной перспективе, а это означает, что вы не придерживаетесь краткосрочной, я бы сказал, разрушительной перспективы, вы хотите ценить качество обслуживания, поскольку оно имеет значение, защищая при этом ваши долгосрочные интересы, и все это будет зависеть от нормы прибыли. Если нет, то просто у вас есть упрощенный критерий, который необходимо скорректировать.
Conor Doherty: Да. И что-то, что вы там сказали, в частности, опять же, идея поговорить с практиками, будь то просто на конференции, сделать такие подкасты, будь то деловой звонок, что угодно, одна из вещей, которая возникает, - это управление изменениями. И что-то, что вы там сказали, я спросил вас, что отличает успешную компанию от неудачи, и вы сказали, знаете, компании, позволяющие вам просто делать свое дело.
И я бы добавил к этому, что в управлении изменениями это означает, что в названии будут хоть какие-то изменения. И изменение будет заключаться в том, что вы отойдете от того, что вы только что описали: сегментации, ручного управления, контроля. Вы должны признать, что движетесь в направлении автоматизации, принятия решений без присмотра.
Joannes Vermorel: И опять же, я думаю, что отчасти проблема заключается в том, что изменения, которые приносит Lokad, крайне ограничены и в основном субстрективны. Видите ли, это то, в чем люди очень, иногда очень, очень сбиты с толку. Lokad не требует реинжиниринга компаний наших клиентов. Изменения, которые мы вносим, почти полностью субстрективны, удаляя некоторые вещи, вот и все.
Так что вам не придется переделывать должностные инструкции большого количества людей, проходить переподготовку. По сути, потому что мы снова стремимся к автоматическим процессам принятия решений, да, они концептуально проще на всех уровнях. Для ИТ-специалистов это проще. Это проще для практиков цепочки поставок. Высшему руководству проще. На самом деле это проще для всех.
Так что это не так много, как: «О, у нас так много перемен, нам нужно будет так многому научиться», а не отучиться от всего того, что уже не актуально. Видите ли, просто представьте себе эти старые пишущие машинки, механические. Вам нужно было их смазать маслом. Вам нужно было иметь возможность менять красящую ленту. Иногда нужно было взять…
У меня был такой, когда я был молодым. Я имею в виду, что если вы хотите использовать механическую пишущую машинку в профессиональных целях, эта штука требует большого ухода. Это буквально немного заводного механизма. А если зайти на компе, вдруг пропало. Ваша клавиатура работает, и если ваша клавиатура сломалась, вы просто покупаете новую клавиатуру и все.
Объем знаний, необходимый для использования современной клавиатуры, по сравнению с пишущей машинкой старой школы, намного меньше. Итак, вы видите, управление изменениями очень субстрективно. Множество вещей просто исчезло. И это, пожалуй, та часть, которая больше всего сбивает с толку потенциальных клиентов, когда мы с ними обсуждаем. На самом деле они ожидают больших изменений в том смысле: «О, нам нужно будет переобучить людей, нам нужно добавить то и добавить то», а их очень мало. Это очень, очень мало.
Для ИТ Lokad — это, я бы сказал, лишь малая часть того, что требует классическая система. Так что для ИТ это намного меньше. Конечно, для пилота это обычно очень низкое трение. По сути, речь идет об отправке необработанных файлов, плоских файлов строк, извлеченных из системы, без какой-либо предварительной обработки, копирования и вставки, просто выгрузки и передачи.
Conor Doherty: Это ключевой момент. Извините, на самом деле это довольно ключевой момент, который мы только что упустили из виду, и насколько это незначительно по сравнению с утверждением: «Нам нужен двухлетний процесс реализации только для того, чтобы подготовить его». Не превышайте эту точку снова.
Joannes Vermorel: Да. Причина, опять же, в том, что Lokad изначально задуман так, что мы хотим, чтобы этот механизм принятия решений работал без рабочего процесса. Итак, я имею в виду, что рабочий процесс очень минималистичный: ввод данных, принятие решения, и все готово.
И так много вещей, которые просто не нужны. Видите ли, нам не нужна повторная синхронизация с ERP, тонны сложных вещей, потому что в конечном итоге то, что мы создаем, — это просто окончательные решения, которые очень просто затем повторно импортировать в ERP. Если вы хотите создать, скажем, заказ на поставку, то это затрагивает только продукт, количество и поставщика, и все. Структура данных, завершенный заказ на поставку, очень и очень проста.
В отличие от того, если мы хотим, скажем, управлять большим количеством сегментаций, ресинхронизировать их с ERP, дать людям возможность делать все что угодно в Lokad, а затем ресинхронизировать это с ERP, это то, что предложило бы большинство моих коллег. И именно поэтому реализация занимает вечность, потому что, опять же, существует так много слоев числовых артефактов, вещей, которые, я бы сказал, просто нереальны, которые подобны инструментам для достижения конечного продукта, то есть решения.
И иногда даже классическое программное обеспечение для цепочки поставок даже не доходит до окончательного решения, которое действительно учитывает все ограничения, такие как проверка минимального количества заказа, проверка максимальной вместимости контейнера, проверка полной загрузки грузовика и т. д. Поэтому очень часто вы сталкиваетесь с множеством сложностей, возникающих из-за того, что вместо того, чтобы стремиться к полностью окончательному решению, то, что вы получаете от типичного программного обеспечения расширенного планирования, классического APS, является чем-то, опять же, не окончательным. результат, и поэтому вам понадобится много сантехнических работ, чтобы окончательно принять решения.
Conor Doherty: Я думаю, это очень благодатная почва для дальнейшего продвижения, потому что, когда мы говорим об участии в сфере ИТ, и это снова то, что мы оба знаем из обсуждения со многими, многими практиками на этом этапе, одна из вещей, которая их будет беспокоить, это: «Ну, мои основные данные недостаточно хороши. Состояние моих данных ужасно. Джоаннес, ты должна увидеть мои данные. Это беспорядок. это».
В главе 10 вы ясно дали понять, что это полная чушь.
Joannes Vermorel: О да. О, да. Интересно то, что, опять же, рынок поставщиков корпоративного программного обеспечения для цепочек поставок, я имею в виду, этот рынок абсолютно ужасен, и у большинства поставщиков уровень отказов намного превышает 90%. Нет, это буквально звучит безумно. Они большие. На бумаге у них предположительно есть сотни успешных реализаций. На практике все они имеют разную степень неудачи.
И всякий раз, когда это терпит неудачу, а это почти всегда терпит неудачу, они будут винить в этом данные, потому что это идеальный козел отпущения. Знаешь, такой идеальный козел отпущения. Это все равно, что обвинять бога погоды или что-то в этом роде. Вы просто обвиняете внешнюю силу, как будто данные — это вещь Вселенной, и нам приходится с этим жить. Нет, нет, нет.
Итак, я считаю: данные почти всегда превосходны для любой компании, скажем, стоимостью более 50 миллионов долларов. Почти всегда превосходно. Почему? Потому что компании, у которых не было отличных данных, давно обанкротились. Это просто корпоративный дарвинизм. Если вы не знаете, что покупаете, то вы не знаете, как платить своим поставщикам, и некоторым поставщикам вы будете платить дважды или вообще не заплатите, и тогда они перестанут быть поставщиками, или что-то в этом роде.
Итак, ты не можешь знать, что покупаешь? Нет. Неужели вы не знаете, что продаете? Нет. Потому что если вы не знаете, что продаете, то опять же вы не будете гоняться за клиентами, которые забыли заплатить и тому подобное. Таким образом, выжили только те компании, которые по сути знают, что они покупают, что производят и что, по сути, продают.
Conor Doherty: Да. Да. Основное правило.
Joannes Vermorel: Да. И снова дарвинизм в действии. Компании, которые не могут этого сделать, обанкротились уже давно, скорее, два десятилетия назад. Таким образом, выжили компании, в которых эти базовые данные верны. Правильны в том смысле, что они отражают реальность и их можно использовать.
Conor Doherty: То есть ты отвергаешь аргумент о беспорядке?
Joannes Vermorel: Нет. О да, именно так. Я имею в виду, что происходит, когда некомпетентные поставщики, да, сталкиваются с этими данными, и они ожидают, что данные будут идеально организованы, скажем, организовано соревнование Kaggle. У вас очень аккуратные данные с правильными таблицами, правильными полями, и все очень хорошо документировано. Но опять же соревнование Kaggle.
Да, ну, если вы как продавец ожидаете этого, вы будете разочарованы. Да. Реальность такова, что да, аппликативный ландшафт запутан. Вы столкнетесь с ландшафтом с полдюжиной сложных бизнес-систем, каждая бизнес-система имеет от 1000 до 10 000 таблиц, каждая таблица имеет от 10 до 500 полей. И каждый фрагмент данных, например продажи, дублируется как минимум в три раза. Таким образом, по разным причинам в разных таблицах это представлено тремя разными способами, и это именно так.
Итак, что касается Lokad, то это наша работа, и я бы сказал, что считаю ответственностью Lokad просто разобраться во всем этом. Это всего лишь базовое ожидание. Итак, мы не ожидаем ничего иного, кроме чрезвычайно беспорядочного аппликативного ландшафта с десятилетиями накопившегося материала. Итак, у вас есть четыре разных ERP, одна из которых была… потому что ERP никогда не умирают, они просто уходят в фон, и у вас все еще есть вещь, которая работает на каком-то мейнфрейме, на AS/400 или чем-то еще, которая все еще работает, и ее никогда по-настоящему не отключали.
И да, с этим тебе придется иметь дело так же, как и со всем остальным, и это совершенно нормально. Итак, вы видите, когда люди обвиняют данные, на мой взгляд, виноваты именно поставщики. Для меня это почти всегда демонстрация некомпетентности продавцов. Если поставщик говорит вам: «О да, мы потерпели неудачу, потому что данные плохие», я имею в виду, просто бегите. Этот продавец совершенно некомпетентен. Они даже не осознают своей некомпетентности и обвиняют богов погоды или кого-то еще. Просто… обвинять данные гораздо больше похоже на 21 век, чем говорить: «Да, боги не были с нами в этом, и поэтому мы проиграли эту битву», но на самом деле это одно и то же.
Conor Doherty: Это ключевой момент, и я действительно хочу его углубить, потому что здесь мне нужно разделить два момента, которые вы высказали, но я просто хочу повторить их, потому что они важны. Во-первых, заявление: «Мои данные запутаны», оно находится здесь. А второй: «Мои данные слишком беспорядочны, чтобы с ними можно было что-то делать». Это два отдельных утверждения, которые вы делаете.
И вообще, прямо у тебя за плечом, не знаю, видно ли это на камере, лежит твоя первая книга, манифест, красный. И когда вы приводите пример, я искренне думаю, что это 90-е годы, может быть, страница 98 или что-то в этом роде, вы приводите пример того, что означает дата продажи? И вы приводите примерно шесть-десять разных примеров. Например, если вы откроете свои транзакционные данные, это может означать день, когда товар попал в корзину, день, когда он был продан, день окончания периода возврата, день окончания гарантии и т. д. Существует множество различных интерпретаций того, что это означает. Это делает его грязным.
Но, как вы только что сказали, ответственность поставщика - избавить вас от этого беспорядка и сделать с ним что-нибудь трудолюбивое и продуктивное.
Joannes Vermorel: Да. Да. И самое главное, и это подходит для развертывания главы, заключается в том, что вы хотите в конечном итоге получить результат инициативы, чего-то, что обеспечивает очень обоснованные, скорректированные с учетом риска и очень прибыльные решения, основанные на любых имеющихся у вас данных. Потому что реальность такова, что ваши люди внутри вашей компании не имеют доступа к большему количеству данных.
Менеджер по производству, или менеджер по запасам, или менеджер по закупкам, они не заходят физически на склад, чтобы получить дополнительную информацию перед вводом заказов на поставку, производственного заказа или чего-то еще. Они делают все со своего рабочего места, и у них нет никакого привилегированного доступа к какой-либо конфиденциальной информации, по большей части, за исключением той, которая на самом деле находится в бизнес-системах.
Итак, я утверждаю, что Lokad… потому что ваши люди, ваши сотрудники уже способны управлять вашей цепочкой поставок, иначе, опять же, дарвинизм в действии, вы обанкротитесь. Так что, если вы не банкрот, некоторым людям удается обеспечить ход вашего бизнеса, а это доказывает, что данных каким-то образом достаточно. Тот факт, что ваша компания еще не обанкротилась, сам по себе доказывает, что данные достаточно хороши.
Теперь вопрос: достаточно ли компетентен поставщик, чтобы использовать данные такими, какие они есть, а не выдавать желаемое за действительное? Если приходит поставщик и говорит: «Да, мы добьемся успеха, если ваши данные будут соответствовать моему стандарту», стандарту поставщика, вы, как компания, которая управляет цепочкой поставок, не имеете контроля над стандартами поставщика. Очевидно, это ерунда.
Просто представьте, что вы хотите отремонтировать сантехнику в своем доме, и пришедший парень говорит: “О нет, знаешь, мне не очень нравится, как устроена твоя сантехника. Это кажется немного сложным. Трубы не совсем прямые. Нет, я думаю, что подожду, пока твоя сантехника будет соответствовать моим стандартам, прежде чем я начну осматривать ее”. И люди говорили: «Нет, ты сантехник. Просто разберись с тем, как была проведена сантехника. И да, если есть какие-то трубы, которые не совсем прямые, я имею в виду, разберись с этим. Это то, чего мы от тебя ожидаем».
Видите ли, подобные обвинения в адрес данных – это очень безумие. И, по моему мнению, о безумии этого рынка во многом говорит то, что некоторым поставщикам обычно удается избежать наказания за неудачу, обвиняя клиента под тем предлогом, что это были всего лишь данные. И самое безумное, что им очень часто удается убедить самих клиентов, что это их вина.
Conor Doherty: Знаешь, для меня это как эй. Мало того, что продавец потерпел неудачу, но им удалось убедить… они заставили меня думать, что это я.
Joannes Vermorel: Хорошо. Им удалось убедить клиента, что это их вина. Я бы сказал, да, это талант. В каком-то смысле это искусство, но не совсем то, чего можно ожидать от людей, которые утверждают, что они специалисты по цепочкам поставок, а не специалисты по манипулированию.
Conor Doherty: Ну, это на самом деле подводит к следующему моменту, который, опять же, когда мы говорим, что Lokad возьмет данные, или кого бы вы ни выбрали, но в нашем случае, очевидно, мы Lokad, мы возьмем ваши данные и будем работать с ними, на самом деле мы имеем в виду ученого по цепочке поставок. И это фактически подводит нас к ключевому моменту: роли ученого в цепочке поставок во внедрении и постоянном совершенствовании.
Но, конечно же, на этапе развертывания роль специалиста по цепочке поставок ограничивается только анализом и упорядочением данных, как вы только что сказали, или это более всеобъемлющая задача?
Joannes Vermorel: Нет, потому что дело в том, что вы не можете знать, правильный ли способ обработки данных или нет, без учета окончательных решений. В конечном счете, единственный критерий, позволяющий узнать, правильно ли вы делаете с данными, — это: прибыльны ваши решения или нет? Это…
Conor Doherty: В каком-то смысле, если вы неправильно понимаете данные, но решения выходят в порядке…
Joannes Vermorel: Тогда ваше недопонимание несущественно.
Conor Doherty: Да.
Joannes Vermorel: И вот люди, наверное, удивятся, скажем, как можно ошибиться, и это не имеет значения? Опять же, это игра масштаба. У вас тысячи таблиц. Всего у вас есть десятки тысяч полей. Да, будут недоразумения. Будут глюки. Будет много чего. Но важно то, что, в конце концов, люди тоже совершают ошибки. У вас могут быть люди, которые читают поле; они должны читать другое поле.
Действительно: вы принимаете решения, в которых нулевой процент безумия? Таким образом, нет ни одного решения, которое было бы сразу фиктивным.
Conor Doherty: Мм.
Joannes Vermorel: А потом они все как минимум прилично хороши, знаешь ли. И затем, когда вы измеряете экономические показатели в среднем, действительно ли они превосходят прежний статус-кво? Это критерий.
Тогда тот факт, что вы можете вести бесконечную, я бы сказал, работу над улучшением числового рецепта, чтобы со временем сделать его очень, очень отличным, это приятно, и это продолжение усилий ученого, занимающегося цепочкой поставок. Но в конечном итоге, как видите, вклад ученого, занимающегося цепочками поставок, следует понимать так: удается ли нам ежедневно принимать эти высокоприбыльные решения без присмотра? И это развертывание. Это инициатива, которая доходит до того момента, когда вы каждый день принимаете решения.
Это вклад ученого, занимающегося цепочками поставок. И механически, или извините, не механически, с механистической точки зрения, ученый, занимающийся цепочками поставок, по сути, является экспертом.
Conor Doherty: Думаю, это аналогия, которую ты приводил раньше. Это как пит-бригада — все в одном. Именно инженер, специалист по данным, эксперт по цепочке поставок будет управлять вашим конкретным аккаунтом. Например, вы взаимодействуете с этим человеком, человеком, который управляет вашей учетной записью.
Joannes Vermorel: Да. И это идет немного дальше. Я говорю о том, что это даже от Локада не зависит. Если вы разделите ответственность за числовой рецепт… Итак, кто-то должен разработать программное обеспечение, которое будет принимать ваши исходные данные и генерировать решения. Когда я использую термин «числовой рецепт», это то, что представляет собой часть программного обеспечения, которая начинается с данных, которые можно найти в бизнес-системах, из того, что существует в сыром виде, и генерирует в конце дня фактические окончательные решения.
И когда я говорю «завершено», это означает, что никому не нужно открывать электронную таблицу, чтобы увеличить или уменьшить цифры только потому, что существует минимальный объем заказа, который не был обработан, или что-то в этом роде. Так что это действительно окончательно. Хороший. Заказ на поставку точно готов к отправке, например, поставщику. Хорошо.
Итак, я говорю, и именно так следует понимать ученого, занимающегося цепочками поставок, что все это должен охватывать один разум. Один человеческий разум. И этот единый человеческий разум очень важен, потому что в конечном итоге вы хотите иметь что-то полностью последовательное от начала до конца.
И видите, если разделить ответственность, это то, чему Lokad научился 15 лет назад. Если вы разделите эту задачу на части: «О, будет один человек, отвечающий, скажем, за подготовку данных, а затем другой будет отвечать за выполнение, скажем, вероятностного моделирования, а затем еще один будет отвечать за оптимизацию для окончательного процесса принятия решений», и тому подобное, вы в конечном итоге получите массу ошибок на границах внутри вашей системы.
Видите ли, имея несколько человек, они естественным образом установят границы внутри этого числового рецепта, и почти все ошибки будут сосредоточены на этих границах. Итак, вам нужно просто найти способ удалить все эти границы, чтобы он не фрагментировался.
И еще один способ понять это — просто представить это как процесс, в котором вы разделите игру в шахматы на несколько этапов. Например, первый человек решает короткий список фигур, которые могут быть перемещены, а затем другой решает что-то еще. Если вы инсценируете процесс, получится ли у вас в конце дня лучший шахматный ход? Нет. Я имею в виду, что почти гарантировано, что если вы попытаетесь фрагментировать свой стиль игры в шахматы, вы в конечном итоге получите плохие шахматные ходы, а если вы играете против кого-то, кто действительно хорош, этот человек просто будет иметь огромное преимущество перед вами только потому, что это один разум, который может взглянуть на всю доску вместо того, чтобы пытаться фрагментировать анализ.
Conor Doherty: Конечно. Просто чтобы подчеркнуть какую-то мысль или прояснить и, надеюсь, подчеркнуть эту мысль: когда вы говорите, что это один человеческий разум, вы говорите о стороне Локада. Это один человеческий разум, потому что, очевидно, вам все равно придется взаимодействовать с клиентом.
Joannes Vermorel: Эти отношения не касаются Lokad. Знаете, это Введение в цепочку поставок не о Lokad. Речь идет о том, что работает, а что не работает в цепочке поставок. Lokad почти не упоминается в сносках пару раз в другой книге.
Я хочу сказать, и это важный урок: если вы хотите, чтобы какая-либо инициатива в области цепочки поставок действительно работала, не имеет значения, участвует ли в ней Lokad. Я говорю, что должна быть какая-то программа, которая будет генерировать ваши решения. Мы прошли через это. Если у вас нет программного обеспечения, ваши усилия, ваши инвестиции не приведут к увеличению. Вы не можете сделать его лучше, потому что он становится очень размытым. Если кто-то уйдет, повторюсь, просто крайне сложно систематически улучшать то, что делается полностью вручную.
Вот почему я говорю: ладно, нам нужно относиться к этому как к программному артефакту, к этому числовому рецепту. Хорошо. Я говорю о том, что кто-то будет участвовать в разработке и обслуживании этого числового артефакта. Если в этом замешана компания Lokad, то это может быть кто-то из Lokad. Если Lokad не будет участвовать, то это будет кто-то другой. Неважно где.
И до тех пор, пока у нас не будет, ну, вы знаете, уровней искусственного интеллекта Скайнет, которые были бы такими же автономными и способными, как люди, это будет человеческий разум. Потому что, даже если эти агенты невероятны, они еще не способны самостоятельно выполнить столь сложную задачу. Итак, на данный момент это означает, что будет человек.
И я хочу сказать, что это критерий: независимо от масштаба вашей компании, в ней должен быть один человек. Это не значит, что не может быть три человека, но, видите ли, это совсем другое. Просто подумайте: вы хотите играть в шахматы с тремя людьми и потенциально иметь примерно трех экспертов. Все эксперты обладают одинаковыми способностями, все они способны играть в игру самостоятельно и видят всю проблему. Он не фрагментирован. Это не постановка.
В каком-то смысле, если у вас есть три эксперта, которые принимают решение о ходе, они совершенно избыточны. И это нормально. Итак, вы видите, я говорю о том, что ум должен быть единым. На практике в крупной компании требуется резервирование, потому что вы не хотите, чтобы в случае, если этот человек заболеет, не было запасного варианта. Я это понимаю. Я хочу сказать, что если у вас будет несколько человек, они, по сути, приведут к сокращению штатов. Речь идет не о разделении труда, когда вы разбираете проблему на кусочки, когда люди не знают определенных аспектов процесса.
По сути, чтобы это работало, числовой рецепт должен быть создан кем-то, кто полностью понимает процесс от начала до конца. Вот что я говорю. А если у вас этого нет, вы столкнетесь с чрезвычайно предсказуемыми проблемами, которые почти систематически приводят к сведению на нет такого рода инициатив.
Conor Doherty: Что ж, с точки зрения предсказуемых проблем, которые сводят на нет ту самую инициативу, которую вы пытаетесь осуществить, одна из самых больших - это объяснимость. И опять же, мы оба лично много-много-много раз слышали: «Звучит здорово. Как мне объяснить это моей команде, которой приходится взаимодействовать с этой интеллектуальной системой, которая сейчас разрабатывает автоматические автоматические решения? Как мне завоевать доверие? Как мне обеспечить для этого объяснимость? На что это похоже?»
Joannes Vermorel: Итак, сначала мы вернемся к одному человеку, одному разуму. Видите ли, кто отвечает за объяснимость? Ответ — человек, который разработал числовой рецепт. Это не ИИ. Это не система. Это человек. Значит, есть человек, который может объяснить, что он сделал. Итак, если этот человек недоступен для объяснений, то у вас снова проблема.
Итак, я хочу сказать, что мы возвращаемся к успешному развертыванию. Вам нужен кто-то, кто возьмет на себя ответственность за числовой рецепт. Это первый шаг. Итак, объяснимость начинается с того, что кто-то будет объяснять. Понимаете, это роль.
И потом, способен ли этот человек объяснить? Ну, если у этого человека есть всестороннее понимание от начала до конца, даже если на практике это может быть команда, поэтому некоторые части работы могли быть выполнены другими людьми, если этот человек владеет всем числовым рецептом, тогда да, этот человек может объяснить.
Теперь вы хотите, чтобы этот человек также создал инструменты. Это часть того, что мы называем «белым боксом». Таким образом, человек, создающий числовой рецепт, также будет создавать все инструменты белого ящика. По сути, это всевозможные приборные панели…
Conor Doherty: Да, да, да.
Joannes Vermorel: …этот инструмент числового рецепта. Целью этого инструментария является, прежде всего, позволить человеку, создающему числовой рецепт, убедить себя в том, что рецепт работает. Видите ли, я имею в виду, что я пишу числовой рецепт, который генерирует, скажем, заказы на поставку. Как мне убедить себя, что то, что я только что сделал, правильно? Видите ли, я просто привел формулы.
Conor Doherty: Это буквально тот вопрос, который я тебе задаю.
Joannes Vermorel: Да. И первый ответ: мне нужно создать серию индикаторов, да, в евро или долларах, которые разлагают то, что я собираюсь делать, и просто говорят мне, что я получаю… И опять же, в том, на что я хочу обратить внимание, будет много эвристики.
Так что я буду искать… наверное, опять же, белый бокс - это что-то вроде искусства. Вы не хотите смотреть только на средние значения. Возможно, вам захочется сосредоточить внимание на продуктах, которые очень нестабильны, некоторые очень стабильны, некоторые растут, некоторые имеют длительные периоды дефицита и т. д. Я имею в виду, что все это своего рода инструменты, которые вы накладываете поверх числового рецепта, чтобы убедить себя, как ученого по цепочке поставок, что он действительно работает так, как задумано.
И потом, этот инструментарий обычно немного ошеломляет, потому что это буквально тысячи чисел. И вы, как специалист по цепочке поставок, обычно захотите подготовить гораздо более краткий дайджест, который будет представлен коллегам, или клиентам, или другим людям, чтобы передать убедительность, но в гораздо более краткой форме. И это снова ответственность того же человека, человека, ответственного за разработку числового рецепта.
Conor Doherty: Ну, в этом ответе вы рассказали о том, кто, что и как. Итак, кто объясняет, что объясняет, как объясняет. Что не было затронуто, так это то, когда начинается это объяснение. И если я правильно понял в главе 10, это во время фазы двойного прогона. Вот где вы впервые начинаете видеть, вот как выглядит новая система интеллекта по сравнению с вашей нынешней системой. Итак, пожалуйста, расширьте.
Joannes Vermorel: Итак, дело в том, что в числовом рецепте у вас потенциально есть сотни промежуточных шагов расчета, но все числовые артефакты, все эти вещи, являются всего лишь средством для достижения цели. Единственное, что имеет значение – это конец, потому что именно для этого вы здесь. Опять же, это похоже на то, как если вы играете в шахматы, единственное, что имеет значение, — это ваш ход. Все виды промежуточных шагов, которые вы имели в виду, чтобы прийти к этому решению, — это типа «да, хорошо». В конечном счете они несущественны для наблюдателей. Единственное, что действительно имеет значение, — это то, во что вы на самом деле играете. Это определит исход игры.
Да. Итак, вот что я говорю, и мы говорим то же самое о числовом рецепте: мы говорим, что объяснимость начинается, когда у вас есть решения, которые нужно объяснить. Потому что до этого все как-то спорно. Вы можете объяснить, почему вы выполнили все эти виды предварительной обработки, почему вы применяете эту эвристику здесь и там, почему вы выбираете эту вероятностную модель для времени выполнения заказа, а не другую. Все это лишь бесконечные формальности.
По сути, единственное, что действительно заслуживает объяснения, это эндшпиль, те решения, которые вы предлагаете. И именно поэтому объяснение, «белый ящик» обычно начинается только в конце второго месяца, начале третьего месяца. Однажды в рамках инициативы по цепочке поставок учёный, занимающийся цепочками поставок, начинает фактически принимать ежедневные решения.
До тех пор это просто работа, которая в основном является внутренней по отношению к тому, что делает ученый по цепочке поставок, просто чтобы прийти к этим решениям. Я имею в виду, что срок составляет два месяца, чтобы запустить конвейер данных и заставить ученого по цепочке поставок разобраться с этим беспорядком данных, разобраться в нем, а затем очень быстро написать первый числовой рецепт.
Следующие два месяца будут посвящены быстрым итерациям, направленным на то, чтобы избавиться от всех безумных решений и по-настоящему настроить, с учетом отзывов практиков, все экономические драйверы. Потому что многие вещи требуют тонкой настройки, и это потому, что вы хотите, чтобы ваши экономические движущие силы отражали стратегические намерения цепочки поставок и компании.
Так, например, что на самом деле означает качество обслуживания? Опять же, ученый, занимающийся цепочками поставок, может высказать здесь некоторые предположения и предположения, но в конечном итоге потребуется обсуждение с реальными практиками, чтобы убедиться, что экономическая структура действительно отражает долгосрочные интересы компании. И это очень обыденные решения о том, что на самом деле означает качество обслуживания, как именно устроены структуры, потому что давление на оборотный капитал и т. д. и т. п.
Так много всего, быстрые итерации в течение двух месяцев, а затем, к концу четвертого месяца, вы готовы просто позволить числовому рецепту работать без присмотра в течение двух месяцев, выполняя двойной прогон.
Conor Doherty: Да.
Joannes Vermorel: Чтобы люди действительно могли… чтобы числовой рецепт мог заслужить необходимое доверие, чтобы люди могли затем решить, что они действительно будут полагаться на эту часть программного обеспечения в производстве, чтобы управлять потоком.
Conor Doherty: Ну, вы упомянули безумие, и ранее вы упомянули, что то, что вы ищете, — это нулевое безумие решений. Теперь, во время этой двойной фазы и, скажем, в течение первых шести месяцев развертывания, внедрения, предположительно будут моменты, будь то с Lokad, с кем бы он ни был, когда вы развертываете систему разведки, предположительно будут моменты, когда люди, которые наблюдают, пытаются завоевать доверие к этой системе, могут наблюдать за решением, и оно может быть для них неотличимо от дефекта или: «О нет, это просто новый способ ведения дел».
Как именно вы думаете, если она так радикально отличается от предыдущей системы, как вы ожидаете, что люди будут различать между «Это безумное решение» и «Нет, это просто выглядит безумием, на самом деле это лучшее финансовое решение, которое вы можете принять»?
Joannes Vermorel: Нет, я имею в виду, во-первых, первая партия вещей, которые тебе нужно исправить, - это действительно безумные вещи. Хорошо? Почти всегда это происходит потому, что есть поле, которое неправильно интерпретируется, потому что, опять же, мы говорим о тысячах таблиц. Бывает такое, что вы думаете, что у вас есть единицы, но на самом деле это не единицы, а килограммы или что-то еще. У вас есть вещи, они полностью выключены.
И очень часто, например, первая партия будет просто для того, чтобы проверить у финансового директора, что мы видим ту же валовую прибыль, ту же стоимость акций. И нет ничего необычного в том, что при первой попытке по тем или иным причинам вы получаете расхождение в два раза. Так вот, это как бы первый слой безумия.
А потом ты еще и обнаруживаешь все теневые ИТ. Например, вы предлагаете количество 110, а потом кто-то говорит вам: «О нет, нет, нет. Я вам не говорил, но оно поставляется только на поддонах по 100 единиц». Итак, множитель большой. Это не было задокументировано. Да. Хорошо, нам нужно это принять во внимание. А потом и т. д. А потом есть люди, которые поднимают руку и говорят: «О, но нет, у нас были скидки от этого поставщика».
Conor Doherty: Да.
Joannes Vermorel: Это не записано в системе. Обычно я просто вручную корректировал данные в электронной таблице. Хорошо, нам нужно это исправить и т. д. и т. п. Так что для меня основная часть первых раундов итераций — это действительно все эти вещи, которые, я бы сказал, простое безумие. Это что-то, где есть недопонимание данных, существует ограничение, которое не смоделировано должным образом и т. д. и т. п.
И поскольку вы ставите перед собой цель: мы хотим обеспечить автоматическое принятие решений, это требует больше усилий. Потому что обычно, исторически, практикующие говорили: «О, это число, да, оно хорошее, 110, мы просто вручную округлим его до 100. Для меня это хорошо». А Lokad идет гораздо дальше и говорит: «Нет, нет, нет. Если задействован большой множитель, то числовой рецепт должен, это не обязательно, должен делать все, чтобы нам не нужно было выполнять корректирующий шаг вручную в конце». Это не приносит удовлетворения.
Так что избавиться от безумия - значит удалить все это. И потом, да, позже у нас будут решения, которые не отражают историческую практику. И здесь мы увидим отражение экономических сил. И обычно, если есть разногласия, это будет: «Вы согласны с теми долларами, которые мы видим?» Lokad предполагает, что, когда мы смотрим на доллары, которые задействованы с точки зрения стоимости дефицита и стоимости избытка запасов, мы видим именно это равновесие.
И здесь у нас будет итерация по этим экономическим факторам для заключения общего соглашения. И это будет второй этап, в котором нам придется исправлять безумные решения, поскольку на самом деле экономические факторы, которые представляют собой множество догадок, изначально оказываются неверными, и нам нужно быстро повторять их, чтобы приблизить их к тому, что кажется правильным для компании.
И наконец, да, в конце мы примем решения, которые иногда удивляют практиков, но они приходят довольно поздно, потому что на данный момент мы видим, и это обычно происходит с хорошо функционирующей системой, что она ломает старые шаблоны. Например, предположим, что заказы для данного поставщика всегда делались по понедельникам, но это не является фактическим ограничением.
Conor Doherty: Да.
Joannes Vermorel: Поставщик может принимать заказы, когда мы захотим. И иногда имеет смысл передать заказ в четверг, а не ждать следующего понедельника, просто потому, что, ну, чем раньше, тем лучше, если мы увидим, что произошел неожиданный всплеск спроса. Почему стоит начать с ожидания пару дней, когда уже знаешь, что нужно передать заказ? Так что это избавит от некоторых привычек.
Но здесь снова возникает вопрос: правильный ли это шаг с точки зрения нормы прибыли? Этот ход выгоднее или нет? И вот это будет масштаб проведения изменений, то есть, ну, если это заведомо что-то более выгодное, даже если оно не соответствует старому ручному шаблону, то это должно быть решение, и все, а не пытаться добавить фиктивные ограничения, чтобы оно подошло.
Кстати, это происходило довольно часто, я бы сказал, более десяти лет назад, в Lokad: у нас было меньше опыта, чем сейчас. И проблема, с которой мы сталкивались, заключалась в том, что часто некоторые из наших потенциальных клиентов в конечном итоге говорили: «О, мы хотим… эти решения изменились слишком сильно по сравнению с тем, что мы имели раньше. Поэтому мы собираемся ввести мягкие ограничения, ограничения, которые нереальны».
Например, команда может просто использовать мягкие MOQ, а не жесткие MOQ, поэтому минимальные объемы заказов нереальны. У поставщика их нет. Складу плевать. Никакой экономической выгоды с ними не связано. Но для отдела закупок это был всего лишь способ передавать меньше заказов на поставку, сделать их менее частыми, поскольку у них была очень низкая производительность, и, таким образом, для них это был способ сэкономить время.
Но опять же, как только вы вступаете на территорию автоматических процессов принятия решений, если только пакетирование ваших заказов на поставку не дает экономической выгоды, и в этом случае это должно быть отражено в числовом рецепте, тогда нет смысла пытаться моделировать те мягкие MOQ, которые полностью выдуманы и берутся из воздуха.
Conor Doherty: Слушая это, я вспомнил анекдот. Это были вы, много лет назад, я думаю, это было во время живого мероприятия пару лет назад, вы упомянули, и снова я не буду говорить кто, опять же это был клиент, и в аэрокосмической сфере, вот что мы скажем, но это демонстрирует идею о том, что как только вы устанавливаете систему интеллекта и начинаете адаптироваться, вы должны строить доверие, возникнут оппортунистические и своего рода капиталистические решения, которые выходят за рамки того, что вы раньше считали возможным.
И с этой точки зрения это может показаться безумием, но как только вы действительно изучите экономику, это обретет смысл. И пример, который, как я полагаю, вы привели, заключался в том, что я собираюсь его зарезать, но очень, очень просто: у компании MRO было рекомендованное заказ на покупку, и оно включало, например, покупку полного двигателя. Скажем так, купите двигатель. Купить двигатель от А380. И это было отмечено как: «Это безумие. Почему вы советуете мне купить полный двигатель?»
И оправданием было то, что разведывательная система обнаружила, что на самом деле эти самолеты в этом районе только что были списаны. Этот двигатель сейчас продается со скидкой 50%. Купите, посидите на нем, через полгода сможете продать с прибылью. Таким образом, рекомендация заключалась не в том, чтобы покупать, чтобы использовать, а в том, чтобы покупать, чтобы продать, что опять-таки очень сильно отличается от предыдущего метода, например: «Я покупаю то, что мне нужно, чтобы удовлетворить эту цель». Тогда как это гораздо более всеобъемлющая экономическая перспектива. Так что это не просто: «О, я раньше ставил галочку в этом поле, чтобы добиться этой цели». Есть несколько способов содрать шкуру с кошки и заработать больше денег.
Joannes Vermorel: Да, именно. И это до сих пор происходит, например, в авиации. Самолеты разбирают.
Conor Doherty: Точно.
Joannes Vermorel: Итак, у вас есть возможности для покупки, да, часть… опять же, это зависит от вашей ситуации, но если вы знаете, что вы являетесь компанией, которая не испытывает недостатка в деньгах, богата деньгами, и это что-то, и у вас нет недостатка в месте для хранения, и эта вещь понадобится, возможно, через год, и, скорее всего, когда она вам понадобится, вы заплатите цену, которая почти гарантированно будет намного выше, чем сейчас, да, вы должны это увидеть.
Или это может быть розничный торговец, где у вас есть акция от поставщика и товар не потеряет свою ценность слишком быстро, а у вас просто появится возможность продать его с гораздо большей валовой прибылью. Так что да, это то, что… но опять же, именно поэтому экономическое обоснование и объяснимость, то, как мы обосновываем объяснимость, находится в экономике.
Знаешь, это “Зачем ты это делаешь?” Ответ: ну, посмотрите на финансы. И если моделирование показывает, что это очень выгодно и имеет смысл с экономической точки зрения, то это правильное решение, даже если исторически в компании это не было привычкой.
Conor Doherty: Хорошо. Что ж, единственное, что мы еще не рассмотрели, — это то, что происходит после развертывания. Итак, допустим, вы компания, вы все это слышали, это здорово, вы хотите пойти и купить себе систему интеллекта. Что остается под контролем поставщика после развертывания, а что я, как клиент, сохраняю внутри компании? Мол, какие части этого процесса полностью под моим контролем, а какие для вас внешние?
Joannes Vermorel: Я думаю, что, во-первых, главный урок развертывания заключается в том, каким должен быть финал. Знаете, если вы хотите добиться успеха, вам следует стремиться к автоматическому принятию решений.
Conor Doherty: Мм.
Joannes Vermorel: Если вы этого не сделаете, это будет стоить вам в 10 раз дороже. Он будет в 10 раз медленнее, и он не будет ни нарастающим, ни капиталистическим. У вас не будет чего-то, что действительно выведет вашу компанию на следующий уровень прибыльности с точки зрения вашей цепочки поставок. Итак, это действительно краткий урок.
И не имеет значения, участвует ли в этом поставщик или нет, хотите ли вы сделать это внутри компании или нет и т. д. Опять же, эта книга на самом деле не о Lokad. Это: что значит развернуть? Потому что, как вы видите, антипаттерн, который я вижу в этой отрасли, заключается в том, что многие люди говорят: «О, мы реализовали эту инициативу по цепочке поставок, и эту, и эту, и эту», и ни один из них на самом деле не достиг этой стадии принятия решений без присмотра.
В итоге вы получаете панели мониторинга, которые игнорируются, гаджет здесь, который игнорируется, часть программного обеспечения там, которая является просто ямой для производительности. В буквальном смысле это не принесет многого, учитывая количество времени, которое вам придется потратить на это и т. д. и т. п. Поэтому я думаю, что ключевой момент развертывания заключается в том, что вам нужно иметь четкую цель независимо от того, кто за что отвечает. В конечном итоге должно получиться что-то, чему вы можете доверять, что ежедневно генерирует эти автоматические решения.
И потом я говорю, что это часть программного обеспечения, и ее нужно поддерживать. Опять же, никто не избегает дрейфа.
Conor Doherty: Да, именно.
Joannes Vermorel: Просто потому, что у нас нет искусственного интеллекта Skynet, поэтому не ждите, что часть программного обеспечения, независимо от того, сколько гениальности вы в нее вкладываете и т. д., будет как бы самоадаптироваться к структурным изменениям на вашем рынке.
Conor Doherty: И это происходит постоянно, если быть совершенно честным.
Joannes Vermorel: Да, не всегда. Но видите ли, ведь есть классы изменений, которые не являются структурными. Если речь идет просто о движении рынка вверх или вниз, то модель прогнозирования, модели машинного обучения как раз справятся с этим. Проблема в том, что происходит, когда ваш бизнес становится другим, не просто более или менее похожим, потому что вы растете или сокращаетесь, но когда вы вообще становитесь другим зверем.
Представьте себе, например, компанию MRO, которая продавала запчасти, а теперь продает время безотказной работы за часы полета.
Conor Doherty: Да. Это совершенно другая бизнес-модель.
Joannes Vermorel: Ты даже не продаешь одно и то же.
Conor Doherty: Да. Будут авиационные части. Будут дублирующиеся механизмы.
Joannes Vermorel: Но у вас совершенно другая бизнес-модель, и ваши стимулы совершенно другие. Экономическое моделирование вашего бизнеса совершенно другое. И то же самое произошло, например, десять лет назад, когда многие традиционные ритейлеры стали преимущественно заниматься электронной коммерцией. Итак, очевидно, что если вы занимались преимущественно традиционным бизнесом, а теперь преимущественно занимаетесь электронной коммерцией, опять же, все стимулы, своего рода стратегия, все меняется. И дело не только в увеличении или уменьшении продаж. Это трансформация. Сама природа вашего бизнеса меняется.
Итак, я еще раз говорю, что для всех обыденных изменений, у поставщика возникают проблемы, а время выполнения заказов замедляется, все обыденные изменения должны обрабатываться без каких-либо изменений по вашему числовому рецепту. Я говорю о том, что ваш числовой рецепт сам по себе не сможет учесть тот факт, что, например, вы внедряете новую ERP.
Conor Doherty: Да. Или что вы меняетесь, или закрываете распределительные центры, или все такое.
Joannes Vermorel: Да, именно. Я имею в виду вещи, которые во многом структурны. Вот почему его нужно поддерживать. Это потому, что вам нужен кто-то, кто будет уделять внимание и следить за тем, чтобы эта часть программного обеспечения соответствовала реальности вашего рынка, реальности вашей компании и реальности ее прикладного ландшафта.
И именно поэтому, кто бы ни был ответственным, в Lokad мы называем его ученым по цепочке поставок, но тот, кто отвечает за разработку числового рецепта, впоследствии должен отвечать за поддержание числового рецепта. И реальность такова, что вы также можете поручить этому человеку постоянное совершенствование числового рецепта, потому что обычно, когда вы переходите к производству, работа еще только начинается.
Вы достигли определенного уровня экономической эффективности, что обычно является огромным шагом вперед по сравнению с прежним статус-кво, который представлял собой ручной процесс, но это не означает, что вы приблизились к чему-то, что можно было бы назвать оптимальным. Это просто означает, что вы намного лучше, но вы можете продолжать инвестировать в этот актив, чтобы со временем сделать его лучше.
Conor Doherty: Ну, опять же, я не хочу продолжать, этого нет в главе 10, но стоит объединить это вместе, потому что это основной момент рассмотрения цепочки поставок, в данном случае вашего программного обеспечения для цепочки поставок, разницы между капитальными и эксплуатационными расходами. Потому что, когда вы инвестируете в систему интеллекта, как вы только что сказали, не существует верхнего предела тому, насколько лучшим, насколько более производительным и насколько более финансово выгодным может стать решение. Я имею в виду, я уверен, что в мире существует только определенная сумма денег, но на самом деле нет предела тому, насколько хорошо это может быть. Так что, если вы правильно инвестируете в это, вы, по крайней мере, ориентируетесь в том направлении, в котором вам действительно следует двигаться в финансовом отношении.
Joannes Vermorel: Да. Да. И опять же, это становится в какой-то степени предпринимательским предприятием. Вам придется решить, хотите ли вы расширить диапазон возможностей. Например, если у вас есть решения, в которых вы можете начать говорить о том, что минимальный объем заказа является данностью, но следующим этапом будет: возможно, минимальный объем заказа следует пересмотреть? Есть ли случай? Можно ли заработать на пересмотре минимальных заказов с поставщиками?
О чем должны быть переговоры? Как это должно выглядеть? Готовы ли мы пойти на немного более высокую цену за единицу продукции, если мы можем существенно снизить минимальный заказ, или нам следует пойти наоборот и т. д. и т. п.? Итак, вы видите, что мы начинаем с… инициатива по цепочке поставок начинается с определенного объема решений, но затем со временем она может расширяться и принимать все больше и больше решений.
Обычно вы начинаете, я бы сказал, с основных фундаментальных решений, управляющих потоком, но затем вы можете наслаивать их на решения, которые также формируют поток, хотя обычно они изначально воспринимаются как данность, просто чтобы сохранить инициативу обоснованной и в конечном итоге снова быстро обеспечить автоматическое принятие решений, прежде чем расширяться на все новые и новые области.
Conor Doherty: Ну, вообще-то, это моя заключительная мысль, но она следует за тем, что вы только что сказали. Очевидно, что конечной целью является автоматическое принятие решений, ориентированное на финансовое улучшение компании. Большой. Это конечный продукт внедрения, и он постоянно совершенствуется и т. д. Великолепно.
О рентабельности инвестиций вы можете судить или, по крайней мере, наблюдать. Означает ли это, что в первые пару месяцев, когда вы находитесь только на этапах проверки и сортировки данных, в этом нет реальной финансовой ценности? То есть, по сути, без конечного продукта первые шаги не имеют смысла? Или есть ценность во всей этой цепочке?
Joannes Vermorel: Нет. Я имею в виду, опять же, что до тех пор, пока вы не принимаете финальные решения, вы не имеете ни малейшего представления о том, находитесь ли вы на правильном пути или нет. Видите ли, именно поэтому я говорю, что если вы начнете гоняться за числовыми артефактами, вы не будете знать. Это может выглядеть очень хорошо, но на самом деле вы не имеете ни малейшего понятия.
Видите ли, опять же, думайте об этом так, как будто я рассказываю вам о шахматах. Не предлагая последнего хода. Если я говорю… представьте, что вы играете в шахматы, и я делаю сотню утверждений о том, как она выглядит, о том, что такое сильная позиция, слабая позиция и так далее, и в конце я не говорю, какой ход нам следует делать дальше. Я имею в виду, какова ценность всех этих указаний? Понимаете, это…
И есть проблема: по моему мнению, многие поставщики корпоративного программного обеспечения десятилетиями использовали эту двусмысленность для продажи чего-либо. У них будут всевозможные числовые артефакты. «Я дам вам оценочную карту для ваших поставщиков, оценочную карту для продуктов, индикаторы для того и для этого, цифрового двойника, который имитирует то, и то, и то, и то», — бесконечные вещи. И затем ни единого обязательства принять окончательное решение, в котором мы могли бы прийти к согласию: «Принесет ли эта вещь прибыль или убытки?»
А я говорю, что это не так… и это разница в понимании. Это не далекая цель. Это то, чего вы можете достичь в течение, опять же, опыта Lokad, восьми-десяти недель. И снова восемь-десять недель с командой, которая обычно весьма ограничена. Это не масштабное мероприятие. Это…
И для меня это начало всего. Развертывание - это не… для нас мы говорим, что закрытие развертывания - это когда компания действительно искренне доверяет автоматическому процессу принятия решений, который похож на последние два месяца этого процесса. И я думаю, что ошибка, и именно поэтому я говорю, что многие компании в конечном итоге отвлекаются, заключается в том, что вместо того, чтобы сразу принимать самостоятельные решения, которые, по их мнению, похожи на сверхзрелую, суперотдаленную цель, они начнут преследовать другие цели.
И они говорят: “О нет, мы не можем создать полностью роботизированную систему за 10 недель. Я думаю, нам нужно сначала наладить рабочий процесс, а это займет 20 недель”. Видите ли, таким образом вы устанавливаете промежуточный шаг, который уже в два раза больше и в два раза сложнее вашего эндшпиля. И именно поэтому я говорю, что эти числовые артефакты, эти идеи, исходящие из основной теории цепочек поставок, в конечном итоге создают столько сложностей.
Вот так и получаются проекты, которые занимают несколько лет. И по прошествии нескольких лет у вас все еще нет чего-то близкого к автоматическому процессу или чему-то близкому к чему-то, что было бы капитальными затратами, с продуктивным активом и где ваши инвестиции будут приносить прибыль. Вот почему я говорю, что это необходимо включить в повестку дня, поскольку это цель номер один. Это то, с чего нам следует начать, а затем улучшать это.
Conor Doherty: Я согласен. И единственное, что я хочу к этому добавить, это то, что я действительно хочу использовать аналогию, сравнение, которое вы использовали несколько раз, например, шахматы. А потом я просто собираюсь что-то сказать, а вы высказываете мне свои заключительные мысли.
Но если конечным результатом расстановки является выполнение наилучших ходов фигурами на шахматной доске, чтобы вы могли выиграть игру, то это и есть конечная цель, это система интеллекта, автоматизированные решения. Первые пару месяцев — сортировка и проверка данных, когда вы строите схему, анализируете, понимаете связи, которые эффективно строят шахматную доску или, по крайней мере, показывают вам: «Вот ваша шахматная доска, вот цвет клеток, вот как выглядят фигуры. Вот ходы, которые вы на самом деле можете сделать. Вот как движется лошадь. Вот что делает ладья».
Я не даю вам решения, потому что меня еще нет. Но для меня есть очевидная ценность в том, чтобы знать: «О, вот как выглядит шахматная доска. Вот что делают эти фигуры».
Joannes Vermorel: Да. Да. Очевидно. Так что, если мы говорим о снижении риска инициативы, да, вы можете почувствовать прогресс. Ага. Но давайте будем честными: большинство инициатив в области программного обеспечения для цепочек поставок обычно реализуются в течение нескольких лет. Большинство поставщиков программного обеспечения продают лицензии, в которых у вас должно быть обязательство минимум на один год, а очень часто - на четыре года. Опять же, это полная фальшь.
Я хочу сказать, что вам следует стремиться к чему-то гораздо, намного короче. Да. А 10 недель – это не так уж и много, знаете ли. И снова, если вы хотите понять, движется ли эта сущность, даже если это внутреннее решение, к решению, на четвертой неделе вы можете просто спросить ответственного человека, опять же, я говорю: «Да, что вы делаете?» Что вы строите? Имеет ли это смысл для вас? Это объяснение: «Поможет ли мне эта штука получить полный рецепт всего через шесть недель?»
Я не думаю, что нужно много работать над подготовкой, но в общей схеме корпоративного программного обеспечения иметь возможность достичь момента, когда вы доставите готовый продукт примерно за 10 недель, с точки зрения туннельного эффекта, это на самом деле не так уж и много. Это действительно не так уж и много. Возможно, в будущем с помощью агентов кодирования мы сократим это время вдвое, но, я думаю, это все равно очень быстро.
Да, проблема, понимаете, я не вижу большого потенциала… у нас может быть потенциал довести этот, скажем, 10 недель туннельного эффекта до пяти с большим количеством агентов кодирования, чтобы действительно ускорить эту часть, но на самом деле проблема не в этом. Задача состоит в том, чтобы, по сравнению со статус-кво, стремиться к чему-то, что обычно дает результат за 10 недель, а не буквально стремиться к процессу, где по замыслу вы стремитесь к чему-то, что займет 100 недель.
Видите ли, очень часто, например, когда дело доходит до развертывания, я очень часто слышу, как люди говорят: «О да, о нет, мы не можем себе это позволить, результаты будут через 10 недель. Нам нужно начать с запроса предложений», и бац, 18 месяцев. Итак, вы трансформировались… у вас было что-то, где вы могли получить результаты за 10 недель, а теперь у вас есть полтора года только на выбор поставщика, и этот выбор поставщика обходится вам намного дороже, чем фактическое выполнение работы.
И тогда вы попадаете к поставщику, который буквально спрашивает, им нужны обязательства сроком на один год, если не на четыре года. Ладно, это фейк. Это также урок развертывания: каковы масштабы соответствующих сроков.
Я хочу сказать, что вы можете перейти к автоматическому процессу принятия решений за 10 недель. Вам понадобится около шести месяцев, чтобы полностью доверять этой штуке, потому что большая часть этого времени — это время, необходимое людям, чтобы доверять программному обеспечению. Это не имеет большого отношения к технологии. Вот почему, даже если завтра у нас будут агенты кодирования, которые могут сократить эту задержку, скажем, на 10 недель, чтобы действительно получить числовой рецепт, который работает и это не является полным безумием, мы, вероятно, завтра сможем сжать это за пять, скажем так, за три недели.
Практикам и высшему руководству все равно понадобится пара месяцев, чтобы довериться этому программному обеспечению и позволить ему взять под контроль основную часть компании. Итак, вы видите, в конце концов, я бы сказал, что это не настоящая битва. Настоящая битва… Я имею в виду, ты можешь провести здесь несколько недель. Lokad работает над этим, но для этого требуется множество сложных технологий и очень отточенных практик, потому что каждый день на счету. Вы хотите быть очень, очень быстрым.
Но очень часто, понимаете ли, Lokad, мы работаем над разработкой технологий, чтобы можно было выжать несколько дней то тут, то там. Но что я вижу, так это то, что я вижу много, много компаний, о которых мы ведем переговоры, и они начинают с того, что теряют целые годы на такие вещи, как, да, по замыслу, когда они отправляют запрос на информацию, бум, восемь месяцев, затем 12 месяцев, а затем они выбирают первого поставщика, который сказал, что поставит что-то за восемь месяцев, но на самом деле спустя полтора года им все еще почти нечего показать, и это, конечно, не автоматизировано, и т. д.
Я имею в виду, понимаете, представьте себе такую очень разочаровывающую ситуацию, когда Lokad… мы ведем переговоры с компанией, а затем они проходят процесс, и нам требуется пять лет, чтобы наконец запустить пилотный проект, который затем завершается через 10 недель.
Conor Doherty: Да.
Joannes Vermorel: Видите ли, это очень часто бывает… и это, возможно, послужит уроком для развертывания. Я описываю то, что для реализации инициативы по цепочке поставок компании должны иметь в некотором смысле гораздо более высокие амбиции. Опять же, автоматическое принятие решений.
И ты не хочешь начинать с малого. Вы хотите начать с самой сложной проблемы. Опять же, почему? Потому что вы хотите отсеять некомпетентных людей, будь то внутреннее решение или внешний поставщик. Вы действительно хотите начать с чего-то действительно сложного, чтобы оценить реальную компетентность того, кто, по вашему мнению, сможет решить проблему.
Не начинайте с простой проблемы, потому что тогда вы можете получить некомпетентную организацию, будь то собственное решение или внешний поставщик, который просто сносно выполняет свою работу, но вы не понимаете, что это тупик, потому что вы выбрали что-то простое, французское, работающее с небольшим набором данных и т. д. Нет, нет. Когда вы вступаете на современный путь цепочки поставок, вы выбираете самую сложную проблему, самый большой набор данных, который у вас есть, и вы хотите за 10 недель действительно убедиться, что организация, которая, по вашему мнению, станет вашим долгосрочным решением, проверена по этой проблеме, и вы знаете, что она работает.
Если вы начнете с проверки этого объекта на чем-то простом, вы не будете знать, сможет ли это лицо или объект впоследствии выполнять сложные задачи. Опять же, если бы на решение сложной проблемы ушло около трех лет, вы бы сказали: «Нет, нам нужно сделать что-то маленькое». Но то, что я здесь говорю, и это тоже часть развертывания, заключается в том, что, насколько мне известно, не существует проблем в цепочках поставок, где за 10 недель вы не можете иметь автоматический процесс принятия решений, который демонстрирует либо тот факт, что вы способны это сделать, либо который продемонстрирует тот факт, что вы некомпетентны. Вот и все.
А дело в том, что если поставщик не сможет сделать это за 10 недель, то он не сможет сделать это и за 100 недель. Поэтому продолжать инвестировать бессмысленно. Придётся признать, что не получилось. Вам нужно сменить поставщика, изменить метод, изменить что-то более фундаментальное. Просто дать этому время не поможет.
Conor Doherty: Хорошо. Что ж, Джоаннес, у меня больше нет вопросов. Мы шли, по-моему, около полутора часов, но я думаю, что охватили много очень практической информации, к которой, опять же, я настоятельно рекомендую людям вернуться и прочитать главу 10. Там много очень полезного материала. Но большое спасибо за ваше время и большое спасибо за просмотр.
И да, если у вас есть какие-либо вопросы или вы хотите поговорить со мной и Джоаннесом лично, вы можете связаться с нами через LinkedIn или отправить нам электронное письмо по адресу contact@lokad.com. Вы знаете упражнение. И на этом увидимся на следующей неделе. Возвращайся к работе.
