00:00:13 Проблемы внедрения доказательств концепции в цепочке поставок.
00:01:00 Когда доказательства концепции работают хорошо и чем отличается цепочка поставок.
00:02:29 Цепочка поставок как открытая задача и трудности в оценке её успеха.
00:03:31 Ограничения доказательств концепции в отрасли цепочек поставок.
00:06:30 Важность целостного подхода и учета сроков исполнения в оптимизации цепочек поставок.
00:08:00 Важность сосредоточения внимания на неизменных аспектах инициативы.
00:08:54 Сложность сбора данных при реализации доказательств концепции.
00:11:55 Проблемы упрощения инициативы до простого прогнозирования.
00:13:54 Ограничения прогнозов временных рядов.
00:15:17 Болезненный опыт с доказательствами концепции и их недостатки.
00:17:36 Альтернативы доказательствам концепции при оценке поставщиков программного обеспечения для решений в области цепочек поставок.
00:20:25 Будущее доказательств концепции в отрасли цепочек поставок и их ограничения.
00:21:31 Важность целостного подхода к оптимизации цепочек поставок.
00:22:52 Оценка эффективности поставщиков на еженедельной основе вместо полагания на доказательства концепции.
Резюме
В интервью основатель компании Lokad, Жоан Верморель, и ведущий Киран Чендлер обсуждают оптимизацию цепочек поставок и ограничения доказательств концепции (POCs). Верморель объясняет, почему Lokad часто отказывается от запросов на проведение POC, ссылаясь на вред для обеих сторон. Он считает, что POC наиболее эффективны для узко определённых задач, таких как выбор почтового клиента, но оказываются недостаточными в сложных, трансформационных процессах, как оптимизация цепочек поставок. Цепочки поставок включают множество участников и представляют собой распределённую задачу, которую POC часто упрощают. Он рекомендует сосредоточиться на стабильных аспектах и использовать данные для создания целостной картины. Верморель также предлагает регулярно оценивать эффективность поставщиков и прекращать сотрудничество с теми, кто не демонстрирует удовлетворительного прогресса.
Расширенное резюме
В интервью ведущий Киран Чендлер и основатель Lokad Жоан Верморель подробно обсуждают доказательства концепции (POCs) в контексте программного обеспечения для цепочек поставок и их ограничения. Верморель объясняет, почему Lokad часто отказывается от запросов на проведение POC от потенциальных клиентов, указывая на возможный вред как для компании клиента, так и для Lokad.
Верморель начинает с признания, что POC существуют уже два десятилетия и не являются по своей природе вредоносными. Они эффективно работают, когда применяются к узко определённой задаче. Типичным примером ситуации, где POC будет эффективен, является выбор почтового клиента, такого как Microsoft Outlook или Gmail. Это стандартизированная задача с известным решением. Пользователь имеет чёткие ожидания и знает проблемные моменты. Этот процесс больше не является трансформационным; он просто предполагает переход от одного почтового клиента к другому.
Однако возникает проблема, когда POC применяются к оптимизации цепочек поставок, которую Верморель называет «противоположной» узко определённой задачи. Он утверждает, что это трансформационный процесс для компании, представляющий собой нелокальную задачу, охватывающую несколько локаций и, возможно, множество стран. Сложность увеличивается из-за взаимосвязанной природы цепочки поставок.
Далее, подробно раскрывая идею «открытой проблемы», Верморель описывает оптимизацию цепочки поставок как стремление к оптимизации, которое по своей сути требует измерения. Установление значимой метрики в денежном выражении требует значительных усилий, а полученные показатели — это только начало. Далее следует уточнение «числового рецепта» для оценки влияния действий на операционную деятельность компании. В качестве примера он приводит оценку точной стоимости каждого дефицита товара или конкретного влияния на лояльность каждого клиента.
Когда его спрашивают, неэффективны ли POC исключительно для количественной оптимизации цепочек поставок или для всей индустрии цепочек поставок, Верморель утверждает, что большинство проблем в цепочках поставок трудно свести к формату POC из-за их взаимосвязанного характера. Он объясняет, что цепочки поставок включают множество участников — поставщиков, клиентов, складские хранилища и производственные предприятия. Это распределённая задача, в отличие от локальной, например, оптимизации производственного процесса в изоляции.
Верморель подчеркивает, что цепочки поставок по своей природе связаны с поставщиками и клиентами, что затрудняет выявление чего-либо локального и значимого. Он предупреждает, что, несмотря на то, что локальные оптимизации в цепочках поставок выполнить относительно просто, такие усилия обычно приводят лишь к перемещению проблем. Например, значительная попытка оптимизировать один продукт в одной локации может непреднамеренно создать проблемы в других частях цепочки поставок.
Верморель объясняет, что оптимизация цепочки поставок является сложной задачей для POC, поскольку они склонны сосредотачиваться на микрооптимизациях, не учитывая общую картину. Это может привести к проблемам для поставщиков и клиентов. Кроме того, сроки поставки еще больше усложняют процесс, так как оптимизировать цепочку поставок в более короткие сроки, чем сам срок поставки, практически невозможно. В результате POC часто занимают гораздо больше времени, чем ожидалось.
Чендлер и Верморель обсуждают важность рассмотрения общей картины при оптимизации цепочек поставок. Они отмечают, что POC часто не учитывают полные сроки поставки, необходимые для истинного понимания цепочки поставок. Верморель советует применять капиталистический подход на каждом этапе методологии, сосредотачиваясь на тех аспектах, которые не изменятся вне зависимости от выбранного поставщика или решения.
Одна из проблем, с которой сталкиваются при POC, — сбор и измерение данных. Верморель считает, что оптимизировать то, что не измеряешь, невозможно, поэтому сбор данных должен быть приоритетом. Однако на практике сбор данных для POC зачастую оказывается сложнее, чем ожидалось. Это связано со сложностью реальных ситуаций, таких как розничные сети с несколькими складами, производственными единицами и пунктами дистрибуции.
Верморель приводит пример того, как трудно точно оценить исторический спрос. Такие проблемы, как отсутствие товара на складе, акции и другие аномалии могут искажать данные о прошлых заказах, что затрудняет понимание истинных моделей спроса. Когда POC сталкиваются с этими проблемами, они часто возвращаются к классическим методам прогнозирования, таким как еженедельные прогнозы временных рядов. Такой подход упрощает проблему, но игнорирует сложность и тонкости оптимизации цепочек поставок.
Ретроспективное тестирование, или использование исторических данных для проверки прогнозов, — это ещё один инструмент в оптимизации цепочек поставок. Хотя с статистической точки зрения он работает, Верморель утверждает, что он отражает лишь малую часть общей картины управления цепочками поставок. Например, модели закупок могут зависеть от таких факторов, как согласованные цены и минимальные объемы заказа (MOQ), которые не учитываются при ретроспективном тестировании.
Верморель подчёркивает, что оптимизация цепочек поставок — это не одномерная задача, которую можно решить, сосредоточившись исключительно на точности прогнозирования. Он утверждает, что существующие процессы необходимо пересматривать и корректировать, чтобы сделать оптимизацию возможной. Основная проблема такого подхода заключается в том, что он упускает из виду общую картину и основывается на специфическом типе прогнозирования, который может не подходить для всех случаев.
Верморель отмечает, что цепочки поставок оцифрованы уже десятилетиями, однако многие компании всё ещё полагаются на таблицы Excel и игнорируют данные, генерируемые различными системами. Он предлагает сосредоточиться на основах, таких как консолидация данных в едином хранилище (data lake) и создание содержательной документации, отражающей семантику их цепочки поставок.
Сосредоточившись на стабильных аспектах цепочки поставок, таких как поставщики, производственные единицы, склады и каналы дистрибуции, компании могут разработать метрики, отражающие их долгосрочные финансовые интересы. Верморель подчёркивает, что основная сложность заключается в понимании семантики данных и в том, чтобы обеспечить наличие правильных данных для оптимизации.
При рассмотрении альтернатив POC Верморель предлагает сосредоточиться на тех аспектах цепочки поставок, которые не меняются, и искать поставщика, способного предоставить основанный на данных, целостный взгляд. Хотя POC могут дать некоторую информацию, он предупреждает, что не стоит ожидать слишком многого от небольших экспериментов, поскольку сложные проблемы требуют более глубокого подхода.
Он также считает, что сотрудничество с поставщиками не должно быть долгосрочным обязательством. Компании могут внедрять бережливые инициативы и оценивать эффективность поставщика на еженедельной основе, чтобы обеспечить прогресс. Если прогресс неудовлетворителен, лучше прекратить сотрудничество раньше, чем продолжать работать с субоптимальным поставщиком.
Полная транскрипция
Киран Чендлер: Сегодня мы разберёмся, почему POC не работают, а также выясним, какие альтернативы доступны клиенту при выборе из множества программ для цепочек поставок. Итак, Жоан, POC существуют уже два десятилетия, так что они уж точно не все плохие. В каких отраслях они на самом деле работают?
Жоан Верморель: Доказательства концепции эффективно работают, когда у вас есть узкая, конкретная проблема, которую необходимо решить, и не нужно учитывать огромный спектр возможностей. Например, типичным случаем, где POC будет работать, является ситуация, если я попрошу вас выбрать почтовый клиент, поскольку вы использовали, скажем, Microsoft Outlook или Gmail в течение многих лет. Вы знаете, чего ожидать, вы знаете свои слабые места. Это достаточно стандартизированная задача с готовыми решениями, и вы сможете провести очень точное сравнение, потому что точно знаете, на что обратить внимание. Для вашей компании это, по сути, не является трансформационным изменением; это изменилось десятилетия назад, когда люди только начали использовать электронную почту, а теперь это просто переход от одного почтового клиента к другому. POC хорошо работают для таких супертактических, четко определённых задач. Большая проблема заключается в том, что количественная оптимизация цепочек поставок — это как раз противоположное. Это то, что принципиально изменит вашу компанию, и по своей сути это полностью нелокальная задача. Вы не можете управлять цепочкой поставок с вашего рабочего стола локально, потому что существует сеть, охватывающая множество локаций, потенциально множество стран, и вот тут всё становится действительно сложным.
Киран Чендлер: Так что же характеризует эту задачу как открытую проблему?
Жоан Верморель: Цепочка поставок — это прежде всего идея, которую мы хотим оптимизировать, а для оптимизации необходимо измерять. Уже сам факт, что вы хотите измерять показатели в евро или долларах, требует значительных усилий, чтобы получить измерение, которое действительно имеет смысл. Метрика, исходная точка, — это на самом деле путь к уточнению того, как ваш числовой рецепт оценивает, делаете ли вы что-то хорошее или плохое для вашей компании. Очевидно, что обслуживание клиентов — это хорошо, а массовые дефициты товара — это плохо, но вопрос в том, как именно оценить точную стоимость каждого случая отсутствия товара, точное влияние на лояльность клиента для каждого клиента?
Киран Чендлер: Значит, когда вы говорите, что доказательства концепции по сути не работают, это только для количественной оптимизации цепочек поставок, или же для всей индустрии цепочек поставок?
Жоан Верморель: Большинство проблем в цепочках поставок очень трудно свести к формату доказательств концепции. По определению, цепочки поставок включают множество сторон: множество поставщиков, множество клиентов, складские помещения, производственные предприятия. По сути, это крайне распределённая задача, в отличие от чего-то, что было бы исключительно локальным, например, оптимизации производственного процесса, полностью изолированного от остального мира. Цепочки поставок полностью связаны с вашими поставщиками и клиентами. Таким образом, по определению сложно найти что-то одновременно локальное и значимое, поскольку проблема цепочек поставок в том, что очень легко провести локальную оптимизацию. Суть в том, что когда вы это делаете, обычно в итоге просто перемещаете проблемы. Так, да, вы проделали огромную работу. Таким образом, вы создали проблему для вашего поставщика и, возможно, для нескольких клиентов. Вы не решили общую картину; вы просто микрооптимизировали что-то локально. Это делает цепочки поставок крайне сложными для доказательств концепции в целом. И затем возникает еще один уровень сложности в случае с Lokad. Поскольку мы хотим решать задачи будущего и неопределенности, необходимо учитывать сроки поставки. Когда мы имеем дело с отраслью, где сроки поставки, скажем так, требуют планирования и исполнения за три месяца вперед, это означает, что независимо от того, как вы оптимизируете числовые рецепты для вашей цепочки поставок, одна итерация занимает примерно столько же, сколько ваш срок поставки. Таким образом, вы не можете реально добиться результатов за период короче, чем срок поставки, и, более реалистично, вам потребуется примерно две или три итерации. Если у вас сроки поставки около трёх месяцев, и мы говорим о двух или трех итерациях, это около шести до девяти месяцев. Это не чрезмерно долго для корпоративного ПО, но мы начинаем сильно отдаляться от того, что люди ожидают от быстрого доказательства концепции.
Kieran Chandler: Давайте немного разберём это. То есть, вы говорите, что проверка концепции позволяет увидеть лишь узкий фрагмент, а чтобы решение действительно заработало и доказало свою эффективность, оно должно охватывать всю общую картину. И второе, что вы упомянули, связано со сроками поставок: вы считаете, что проверка концепции обычно проводится в сжатые сроки, поэтому мы не учитываем полные сроки поставок для получения результатов и понимания происходящего. Как долго же следует продолжать проверку концепции, прежде чем вы действительно увидите результаты?
Joannes Vermorelr: Суть в том, что если вы подождете, пока окончательно сформируете измерения и станет абсолютно ясно, что можно измерить преимущества и систематизировать их, это займет слишком много времени. Поэтому мы обычно предлагаем методологию, которая на каждом этапе строится на принципах капитализма и движима видением. Под «капитализмом на каждом этапе» я имею в виду, что независимо от того, как вы хотите оптимизировать свою цепочку поставок, вам понадобятся данные для реализации этой оптимизации. Процесс займет некоторое время, но он отчасти независим от того, какого поставщика или какого решения вы выберете — будь то внутренние ресурсы или внешняя компания. Вам придется пройти через этот процесс. Если вы сможете реализовать инициативу, сосредоточившись на том, что не изменится вне зависимости от выбранного поставщика (если таковой вообще будет), тогда вы сможете действовать в духе капитализма. Например, вы не сможете оптимизировать то, что не измеряете, поэтому следует начать сбор данных для измерений. Эти усилия, вероятно, выйдут за рамки того, что вы считаете допустимым для проверки концепции. Kieran Chandler: Это, вероятно, очень удивительно для многих наших зрителей, ведь при проверке концепции сбор данных должен быть элементарной задачей, который обеспечивается с самого начала проверки. Так почему же это так сложно?
Joannes Vermorel: Это всегда сложно, потому что реальность имеет свои способы обеспечить провал ваших попыток проверки концепции самыми неудачными способами. Но если говорить серьезно, давайте рассмотрим реальную ситуацию. Допустим, у вас есть розничная сеть, включающая пару складов, пару производственных подразделений и, возможно, несколько пунктов дистрибуции. И вот вы запускаете свою инициативу, заявляя…
Kieran Chandler: Давайте поговорим о клиентах, которые довольны тем, как вы их обслуживаете. Вы понимаете, что хотите начать проверку концепции, и обнаруживаете, что сбор всех транзакционных данных оказывается сложнее, чем казалось на первый взгляд. Почему так?
Joannes Vermorel: Например, можно было бы предположить, что заказы клиентов должны обрабатываться просто. И да, и нет, потому что могут возникать всевозможные странные ситуации, например, клиент отправляет заказ, который вы не можете выполнить из-за отсутствия товара. Вы тщательно фиксируете в системе, что заказ выполнить не удалось. На следующий день клиент размещает еще один, даже больший заказ. Почему? Потому что вы не выполнили заказ предыдущего дня. Но если бы вы выполнили первый заказ, скорее всего, второго заказа на следующий день и не было бы. Таким образом, вам нужно учитывать исторический спрос, а не просто необработанный поток заказов клиента, на которые повлияли различные обстоятельства. Вы понимаете, что все оказалось сложнее, чем кажется.
Kieran Chandler: Итак, что обычно происходит с инициативой проверки концепции, когда вы сталкиваетесь со всеми этими проблемами?
Joannes Vermorel: Вы пытаетесь найти способы упростить проблему и неизбежно возвращаетесь к классической проверке концепции прогнозирования, например, к еженедельному прогнозу временного ряда. Вы думаете в терминах прогнозирования спроса на основе исторических данных и можете сразу же провести обратное тестирование. Вы игнорируете отсутствие товара, акции и все странные факторы. В итоге получается нечто, что соответствует определению проверки концепции, но при этом вы полностью отклоняетесь от решаемой проблемы.
Kieran Chandler: Давайте немного поговорим об обратном тестировании. Это когда вы анализируете исторические данные, строите прогнозы и сравниваете их. Почему обратное тестирование на самом деле не работает?
Joannes Vermorel: Обратное тестирование работает с точки зрения статистики, но у него есть свои ограничения. С точки зрения цепочки поставок, это всего лишь небольшой числовой инструмент, составляющий лишь часть общей картины. Если вы начнете думать об оптимизации моделей закупок ваших команд, окажется, что, возможно, все эти минимальные объемы заказа не являются неизменными. Возможно, редкие закупки связаны с тем, что ваша закупочная команда договорилась о низких ценах, но при этом установила чрезвычайно высокие минимальные объемы заказа. Это вынуждает команду задерживать размещение заказов, что усложняет ситуацию и увеличивает сроки поставок.
What I’m saying is that performing optimization is not just a one-dimensional thing, such as decreasing error from a forecasting accuracy perspective. It’s also about embracing and revisiting all existing processes and adjusting what is being done when possible so that optimization actually becomes possible. Also, you need to think about what you’re actually measuring. The problem is that these small proof-of-concept projects, which inevitably circle back to time series accuracy benchmarks, end up having an error expressed as a percentage instead of dollars. Again, we are very far from any business fundamentals. Я имею в виду, что проведение оптимизации — это не просто одномерная задача, такая как снижение ошибки с точки зрения точности прогнозирования. Речь идет также о том, чтобы принять и пересмотреть все существующие процессы и скорректировать выполняемые действия, когда это возможно, чтобы оптимизация действительно стала достижимой. Кроме того, вам нужно задуматься о том, что вы на самом деле измеряете. Проблема в том, что эти небольшие проекты проверки концепции, которые неизбежно сводятся к показателям точности временного ряда, в конечном итоге выражают ошибку в процентах, а не в долларах. Снова отмечу, что мы очень далеки от каких-либо основных бизнес-принципов. Kieran Chandler: Так, настоящая проблема прогнозирования заключается в том, что вы сосредотачиваетесь только на этом аспекте и не видите общую картину? Это очень специфический вид прогнозирования. Сбор всех релевантных данных — сложная задача, поэтому можно быть уверенным, что ваша проверка концепции превратится в классический прогноз временного ряда с еженедельными данными на входе и еженедельным прогнозом на выходе, и на этом все закончится. Думаю, то, что мы описываем сегодня, исходит из болевого опыта, из того, что вы пробовали в прошлом и какие проверки концепции проводили. Так в чем же заключаются ключевые проблемы, с которыми вы сталкивались при проведении проверок концепции? Joannes Vermorel: Худшее то, что иногда вы можете полностью добиться успеха в проверке концепции, и это, вероятно, причиняет наибольшую боль. Как компания-разработчик корпоративного программного обеспечения, вы не выигрываете каждый лид, который к вам приходит — потеря лидов неизбежна. Но действительно больно, когда вы выигрываете проверку концепции, потому что, да, в рамках проверки концепции вы достигаете лучших результатов, возможно, с огромным преимуществом, а затем, когда пытаетесь воплотить это в производственной среде, всё рушится и не оправдывает ожиданий клиента. Вы понимаете, что это потому, что вы перешли от игрушечной задачи к реальной проблеме. Возможно, то, что вы делали для игрушечной задачи, отлично работало в узком масштабе с четко определенной метрикой, но полностью игнорировало все бизнес-основы. При переходе к производственной ситуации вы осознаете, что ваше решение даже близко не дает ответа.
Kieran Chandler: Давайте теперь рассмотрим ситуацию с точки зрения компании. Прелесть проверок концепции в том, что вы можете увидеть различные подходы поставщиков программного обеспечения к решению проблемы и их реакцию на определенные вызовы. Помимо этого, какие альтернативы могут использовать компании вместо проверки концепции? Что еще они могут сделать, чтобы оценить эффективность работы разных компаний?
The worst part is that because supply chains have been digitalized for a couple of decades now, for large companies, you realize that the solution you’re bringing into the company is just going to be like the previous attempts. It will produce a mass of numbers that will be completely ignored by everyone. Inevitably, all the supply chain teams fall back to their usual Excel sheets, completely ignoring the dysfunctional numbers produced by yet another system.
Kieran Chandler: Давайте рассмотрим ситуацию с точки зрения компании. Прелесть проверок концепции в том, что вы можете увидеть различные подходы поставщиков программного обеспечения к решению проблемы и их реакцию на определенные вызовы. Помимо этого, какие существуют альтернативы проверке концепции? Что еще они могут сделать, чтобы оценить, как работают разные компании?
Joannes Vermorel: Альтернатива — сосредоточиться на основах. Я указывал на проблему консолидации данных. Современный способ решения этой задачи — создание data lake. Следующий шаг — предоставление значимой документации с точки зрения цепочки поставок. Чтобы добиться успеха, нужно фокусироваться на том, что не меняется. Ваша цепочка поставок, вероятно, не изменится в своих базовых аспектах. У вас останутся поставщики, производственные подразделения, склады и каналы дистрибуции. Существует множество стабильных элементов, поэтому сосредоточьтесь на них. При консолидации данных объединяйте также соответствующую документацию, ведь главная проблема всегда заключается в семантике данных.
Что означают эти данные? Когда у нас есть дата заказа, подразумевается ли дата, когда вы оформили заказ для отправки поставщику, дата, когда запись была внесена в вашу систему, или дата, когда ваш поставщик подтвердил получение заказа? Возможных вариантов может быть дюжина. Вопрос в том, где задокументированы все эти нюансы. Если у вас нет доступа к данным и их семантике, оптимизация становится невозможной. Опять же, например, когда я описывал подход к количественной оптимизации цепочки поставок, да, существует Lokad как облачная платформа для масштабного выполнения всех этих числовых рецептов. Но то, что действительно имеет особую ценность для клиента, — это консолидация всех релевантных данных, понимание семантики цепочки поставок, разработка метрик, которые действительно отражают долгосрочные финансовые интересы вашей компании, что является сложной задачей. Создание процессов, которые учитывают физические ограничения вашей цепочки поставок, и всё это практически независимо от набора инструментов, который вы используете для выполнения числовых расчетов.
Kieran Chandler: Если мы начнем объединять все воедино и подводить итоги на сегодня, проверки концепции существуют в отрасли цепочек поставок уже десятилетиями. То есть, можете ли вы действительно представить себе время, когда проверки концепции вообще перестанут существовать?
Joannes Vermorel: Очевидно, что всегда найдутся молодые люди, которые не знают лучше и попросят еще одну проверку концепции. Знаете, такова жизнь. И, возможно, они будут правы, ведь бывают ситуации, даже в цепочках поставок, когда проверка концепции действительно является оптимальным решением. Если у вас есть новый принтер штрих-кодов, который, как кажется, совместим с системой, где уже используются старые принтеры, но новый принтер просто лучше, быстрее, дешевле, эффективнее и так далее. Это задача, для которой можно купить еще один принтер штрих-кодов и опробовать его на вашем любимом складе. Так что существуют ситуации и задачи, где проверка концепции — правильное решение. Однако когда речь заходит об оптимизации всей цепочки поставок с целостным взглядом, я бы сказал: не ожидайте многого от небольших экспериментов. Неизбежно вы поймете, что проблема сложна, и если вы не приложите достаточных усилий, вы просто потерпите неудачу, потому что даже не попытались по-настоящему решить проблему.
Kieran Chandler: Итак, как итоговое ключевое сообщение на сегодня: проверки концепции могут дать некоторое представление, но не стоит ожидать многого, и в целом они не работают?
Joannes Vermorel: Да, и альтернатива проверке концепции не должна превращаться в десятилетнее обязательство перед поставщиком. То есть, это ещё один момент. Не то чтобы из-за отсутствия проверки концепции вы не могли сказать: “Наверное, мы можем работать с поставщиком. Мы хотели бы запустить инициативы в духе бережливой индустрии, чтобы это не стоило слишком дорого, а затем двигаться вместе с вами неделю за неделей.” Вместо того чтобы зацикливаться на том, что инициативы должны укладываться в десять недель, важнее, удовлетворяет ли вас скорость прогресса инициативы? От недели к неделе достигаете ли вы удовлетворительного прогресса?
Если вы выбираете поставщика и спустя три недели понимаете, что продвижение происходит весьма медленно, тогда вам следует прекратить сотрудничество, даже если этот срок короче типичной проверки концепции. Вопрос скорее в том, что, хотя вы планируете на десять лет вперед — это ваше видение, вы фокусируетесь на элементе, который будет крайне важен для вашей компании в ближайшее десятилетие. Но когда дело доходит до того, чтобы изгнать корпоративного поставщика за дверь за то, что он не справляется, это будет оценка на еженедельной основе, когда вы снова анализируете, есть ли прогресс и накапливается ли импульс. Вы ищете все эти мелкие признаки, имея в виду неопределенное планирование.
Kieran Chandler: Приходится на этом остановиться, но посмотрим, не напугали ли мы всех.
