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 Альтернативы POC при оценке поставщиков программных решений для поставочной цепи.
00:20:25 Будущее POC в отрасли поставочной цепи и их ограничения.
00:21:31 Важность комплексного подхода к оптимизации поставочной цепи.
00:22:52 Оценка производительности поставщика еженедельно вместо полаганиясь на POC.
Резюме
В интервью основатель Lokad Жоанн Верморель и ведущий Киран Чандлер обсуждают оптимизацию поставочной цепи и ограничения доказательств концепции (POC). Верморель объясняет, почему Lokad часто отказывается от запросов на POC, указывая на вред, который они могут причинить обеим сторонам. Он считает, что POC лучше всего работают для узко определенных проблем, таких как выбор почтового клиента, но не справляются с комплексными, трансформационными процессами, такими как оптимизация поставочной цепи. Поставочные цепи включают в себя несколько сторон и представляют собой распределенную проблему, которую POC часто упрощают. Он советует сосредоточиться на стабильных аспектах и принимать решения на основе данных и комплексного подхода. Верморель также предлагает регулярно оценивать производительность поставщиков и прекращать сотрудничество, которое не показывает удовлетворительных результатов.
Расширенное резюме
В интервью ведущий Киран Чандлер и основатель Lokad Жоанн Верморель подробно обсуждают доказательства концепции (POC) в контексте поставочного программного обеспечения и их ограничения. Верморель объясняет, почему Lokad часто отказывается от запросов на POC со стороны потенциальных клиентов, указывая на возможный вред для компании клиента и самой Lokad.
Верморель начинает с признания того, что POC существуют уже два десятилетия и не являются по своей сути вредными. Они эффективно функционируют, когда применяются к узко определенной проблеме. Примером ситуации, в которой POC хорошо работает, является выбор почтового клиента, такого как Microsoft Outlook или Gmail. Это стандартизированная проблема с известным решением. Пользователь имеет четкие ожидания и знает проблемные моменты. Этот процесс больше не является трансформационным; он просто связан с переходом от одного почтового клиента к другому.
Однако вызов возникает, когда POC применяются к оптимизации поставочной цепи, которую Верморель называет “противоположностью” узко определенной проблемы. Он предлагает рассматривать это как трансформационный процесс для компании, характеризующийся как нелокальная проблема, охватывающая несколько местоположений и потенциально множество стран. Сложность возрастает из-за взаимосвязанной природы поставочной цепи.
Дополнительно разъясняя идею “открытой проблемы”, Верморель описывает оптимизацию поставочной цепи как идею желания оптимизации, что неизбежно требует измерения. Установление значимого измерения в денежных терминах требует значительных усилий, и полученные метрики являются только началом. Путешествие продолжается с совершенствованием “числового рецепта” для оценки влияния действий на операции компании. Он приводит пример оценки точной стоимости каждого дефицита товара или конкретного влияния на лояльность каждого клиента.
Когда его спрашивают, являются ли POC неэффективными исключительно для количественной оптимизации поставочной цепи или для всей отрасли поставочной цепи, Верморель утверждает, что большинство проблем поставочной цепи сложно сформулировать как POC из-за их взаимосвязанной природы. Он объясняет, что поставочные цепи включают несколько сторон - поставщиков, клиентов, склады и производственные предприятия. Они представляют собой распределенную проблему, в отличие от локализованной, например, оптимизации процесса производства в изоляции.
Верморель подчеркивает, что поставочные цепи по своей сути связаны с поставщиками и клиентами, что затрудняет выявление чего-либо, являющегося одновременно локальным и значимым. Он предупреждает, что хотя локальные оптимизации в поставочных цепях легко выполняются, эти усилия обычно приводят только к переносу проблемы. Например, значительные усилия по оптимизации одного продукта в одном месте могут непреднамеренно создать проблемы в других частях поставочной цепи.
Верморель объясняет, что оптимизация поставочной цепи является сложной задачей для POC, потому что они обычно сосредотачиваются на микрооптимизациях, не учитывая общую картину. Это может привести к проблемам для поставщиков и клиентов. Кроме того, сроки поставки дополнительно усложняют процесс, так как сложно оптимизировать поставочную цепь в более короткий срок, чем сам срок поставки. Это часто приводит к тому, что POC занимают гораздо больше времени, чем ожидалось.
Чандлер и Верморель обсуждают важность рассмотрения общей картины при попытке оптимизировать поставочные цепи. Они упоминают, что POC часто не учитывают полные сроки, необходимые для полного понимания поставочной цепи. Верморель советует принять капиталистический подход на каждом этапе методологии, сосредоточившись на том, что не изменится независимо от выбранного поставщика или решения.
Одной из проблем, с которыми сталкиваются при POC, является сбор и измерение данных. Верморель считает, что нельзя оптимизировать то, что вы не измеряете, поэтому сбор данных должен быть приоритетом. Однако реальность часто делает сбор данных для POC более сложным, чем ожидалось. Это связано с сложностью реальных ситуаций, таких как розничные сети с несколькими складами, производственными единицами и местами распределения.
Верморель приводит пример того, как исторический спрос может быть сложно оценить точно. Проблемы, такие как дефициты товара, промоакции и другие аномалии, могут исказить исторические данные о заказах, что затрудняет понимание истинных закономерностей спроса. Когда POC сталкиваются с этими проблемами, они часто прибегают к классическим методам прогнозирования, таким как прогнозы на основе недельных временных рядов. Этот подход упрощает проблему, но игнорирует сложности и нюансы оптимизации поставочной цепи.
Backtesting, или использование исторических данных для тестирования прогнозов, является еще одним инструментом, используемым в оптимизации цепей поставок. Верморель утверждает, что хотя он работает с точки зрения статистики, он представляет лишь часть большей картины в управлении цепями поставок. Например, покупательские паттерны могут быть затронуты факторами, такими как согласованные цены и минимальные объемы заказа (MOQ), которые не учитываются при ретроспективном тестировании.
Верморель подчеркивает, что оптимизация цепей поставок - это не одномерная проблема, которую можно решить, сосредоточившись исключительно на точности прогнозирования. Он утверждает, что существующие процессы нужно пересмотреть и настроить для возможности оптимизации. Основная проблема с фокусировкой на прогнозировании заключается в том, что она игнорирует большую картину и полагается на конкретный тип прогнозирования, который может быть не применим ко всем ситуациям.
Верморель указывает на то, что цепи поставок были цифровизированы десятилетиями назад, но многие компании до сих пор полагаются на таблицы Excel и игнорируют числа, генерируемые различными системами. Он предлагает компаниям сосредоточиться на фундаментальных аспектах, таких как консолидация данных в единое хранилище данных и создание значимой документации, отражающей семантику их цепи поставок.
Сосредоточиваясь на стабильных аспектах цепи поставок, таких как поставщики, производственные единицы, склады и каналы распределения, компании могут разрабатывать метрики, отражающие их долгосрочные финансовые интересы. Верморель подчеркивает, что основной вызов заключается в понимании семантики данных и обеспечении наличия правильных данных для оптимизации.
Рассматривая альтернативы POC, Верморель предлагает сосредоточиться на том, что не меняется в цепи поставок и искать поставщика, который может предоставить основанный на данных, голистический подход. Хотя POC могут предложить некоторые идеи, он предупреждает о том, чтобы не ожидать слишком многого от масштабных экспериментов, так как сложные проблемы требуют более глубоких подходов.
Он также предлагает, чтобы работа с поставщиками не была долгосрочным обязательством. Компании могут заниматься ликвидацией и оценивать производительность поставщика еженедельно, чтобы обеспечить прогресс. Если прогресс неудовлетворительный, лучше прекратить отношения раньше, чем продолжать с неподходящим поставщиком.
Полный текст
Киран Чандлер: Сегодня мы собираемся понять, почему POC не работают, и также понять, какие альтернативы открыты для клиента, чтобы выбрать из множества программного обеспечения для цепей поставок. Итак, Йоанн, POC существуют уже два десятилетия, так что они не могут быть все плохими. В каких отраслях они действительно работают?
Йоанн Верморель: Профы концепций хорошо работают, когда у вас есть узкая, ограниченная проблема, которую вы хотите решить, когда вам не нужно думать о массовых открытых возможностях. Например, архетипом области, где POC будет работать хорошо, будет, если я попрошу вас выбрать свой почтовый клиент, потому что вы использовали почтовый клиент, скажем, Microsoft Outlook или Gmail, в течение многих лет. Таким образом, вы знаете, чего ожидать, вы знаете свои проблемы. Это довольно стандартизированная проблема с стандартизированными решениями, и вы сделаете очень точное сравнение, потому что вы точно знаете, что искать. Для вашей компании это фундаментально нечто, что не является трансформационным; это было трансформационным десятилетия назад, когда люди начали использовать электронную почту вообще, но на данный момент это просто переход с одного почтового клиента на другой. POC хорошо работают для этих супер тактических, четко определенных проблем. Большая проблема заключается в том, что количественная цепь поставок является своего рода противоположностью. Это нечто, что фундаментально трансформирует вашу компанию, и это фундаментально нечто, что является полностью нелокальным. Вы не можете выполнить цепь поставок локально со своего стола. Это происходит потому, что существует сеть, охватывающая множество мест, потенциально множество стран, что делает все очень сложным.
Киран Чандлер: Итак, что характеризует это как открытую проблему?
Жоанн Верморель: Снабжение - это в первую очередь идея, которую мы хотим оптимизировать, и для оптимизации нам нужно измерять. Просто сам факт того, что вы хотите измерять вещи в евро или долларах, требует значительных усилий, чтобы получить измерение, которое действительно имеет смысл. Метрика, отправная точка, на самом деле является путешествием к усовершенствованию способа оценки вашего числового рецепта, оценивающего, делаете ли вы что-то хорошее или плохое для вашей компании. Очевидно, что обслуживание клиентов хорошо, а большое количество нехваток товара плохо, но вопрос заключается в том, как именно мы оцениваем точную стоимость каждой отдельной нехватки товара, точное влияние на лояльность каждого отдельного клиента?
Киран Чандлер: Итак, когда вы говорите, что концепции в принципе не работают, это относится только к количественной цепочке поставок, или ко всей отрасли цепочки поставок?
Жоанн Верморель: Большинство проблем в цепочке поставок очень сложно сформулировать в виде концепций. По определению, цепочки поставок включают несколько сторон: у вас есть множество поставщиков, множество клиентов, склады хранения, производственные предприятия. Это очень распределенная проблема по своей сути, в отличие от чего-то, что было бы крайне локальным, например, оптимизация производственного процесса, полностью изолированного от остального мира. Цепочки поставок полностью связаны с вашими поставщиками и клиентами. Таким образом, по определению, трудно найти что-то, что было бы и локальным, и значимым, потому что проблема с цепочками поставок заключается в том, что очень легко выполнить локальную оптимизацию. Вопрос в том, что, когда вы это делаете, обычно вы просто перемещаете проблемы. Таким образом, да, вы сделали большое количество работы. Таким образом, вы создали проблему для своего поставщика и, возможно, для нескольких клиентов, сделав это. Вы не решили общую картину; вы просто микрооптимизировали что-то локально. Это делает цепочку поставок очень сложной для концепций в целом. И затем есть еще один уровень сложности в случае с Lokad. Поскольку мы хотим решить проблемы будущего и неопределенности, необходимо учитывать логистические сроки. Так что, когда мы имеем дело с отраслью, где логистические сроки, скажем, вы должны планировать и выполнять вещи, думая за три месяца вперед. Это означает, что независимо от того, как вы оптимизируете числовые рецепты для вашей цепочки поставок, одна итерация занимает примерно столько же времени, сколько ваш логистический срок. То есть, это означает, что вы не можете сделать ничего в течение времени, короче вашего логистического срока, и более реалистично вам понадобится две или три итерации. Так что, если у вас есть логистические сроки около трех месяцев, и мы говорим о двух или трех итерациях, мы говорим о шести до девяти месяцах. Это не чрезмерно долго для корпоративного программного обеспечения, но мы начинаем удаляться от того, о чем люди думают, когда они думают о быстрой концепции.
Киран Чандлер: Давайте немного разберем это. Итак, то, что вы говорите, заключается в том, что концепция, по сути, рассматривает только маленькую картину, и для того, чтобы решение действительно работало и доказало свою эффективность, оно должно рассматривать всю большую картину. И второе, что вы упомянули, связано с логистическими сроками, и вы говорите, что концепция обычно довольно короткая, и поэтому мы не учитываем полные логистические сроки, чтобы действительно получить результаты и понять, что происходит. Как долго вам действительно следует упорствовать с концепцией, прежде чем вы увидите какие-либо результаты?
Joannes Vermorelr: Суть в том, что если вы будете ждать, пока вы уточните свои измерения и станет абсолютно ясно, что вы можете измерить преимущества и закодировать их, это займет слишком много времени. Поэтому, как правило, мы предлагаем иметь методологию, которая является высоко капиталистической на каждом шаге и определяется видением. Что я имею в виду под капиталистическим на каждом шаге - это то, что независимо от того, как вы хотите оптимизировать свою цепочку поставок, вам понадобятся данные для выполнения этой оптимизации. Процесс займет некоторое время, но он отчасти независим от того, какого поставщика или решения вы выберете, даже если вы хотите сделать это внутренне или с внешней компанией. Вам нужно будет выполнить этот процесс. Если вы можете выполнить свою инициативу таким образом, чтобы сосредоточиться на том, что не изменится в отношении выбранного поставщика, если таковой будет, в конце инициативы, то вы можете быть высоко капиталистическими. Например, вы не можете оптимизировать то, что не измеряете, поэтому вам следует начать сбор данных для измерений. Это усилие, вероятно, выйдет за рамки того, что вы считаете допустимым для инициативы размером с концепцию доказательства.
Kieran Chandler: Это, вероятно, довольно удивительно для многих наших зрителей, потому что в концепциях доказательства сбор данных должен быть легкой частью, которая предоставляется при начале концепции доказательства. Так почему это так сложно?
Joannes Vermorel: Всегда сложно, потому что реальность имеет свои способы, чтобы убедиться, что ваши попытки концепции доказательства проваливаются самым жалким образом. Но серьезно, давайте рассмотрим реальную ситуацию того, что происходит. Допустим, у вас есть розничная сеть, которая включает несколько складов, несколько производственных единиц и, возможно, несколько пунктов распределения. Теперь вы начинаете свою инициативу, где вы говорите.
Kieran Chandler: Давайте поговорим о клиентах, которые довольны тем, как вы их обслуживаете. Таким образом, вы понимаете, что хотите начать свою концепцию доказательства, и обнаруживаете, что получение всех транзакционных данных сложнее, чем казалось изначально. Почему так?
Joannes Vermorel: Ну, например, вы можете сказать, что заказы клиентов должны быть легкими. Да и нет, потому что у вас может быть много странных ситуаций, например, клиент отправляет вам заказ, который вы не можете выполнить из-за отсутствия товара на складе. Вы добросовестно записываете в системе, что заказ не может быть выполнен. На следующий день клиент размещает еще более крупный заказ. Почему? Потому что вы не выполнили заказ от предыдущего дня. Но если бы вы выполнили первый заказ, возможно, на следующий день не было бы второго заказа. Таким образом, вы хотите отразить исторический спрос, а не только сырой исторический поток заказов от клиента, которые были затронуты по разным причинам. Вы понимаете, что это сложнее, чем кажется.
Kieran Chandler: Что обычно происходит с инициативой концепции доказательства, когда вы сталкиваетесь со всеми этими проблемами?
Joannes Vermorel: Вы пытаетесь найти способы упростить проблемы и неизбежно возвращаетесь к классической концепции доказательства прогнозирования, например, прогнозирования временных рядов по неделям. Вы думаете в терминах прогнозирования спроса на основе исторического спроса, и вы можете сразу же провести обратное тестирование. Вы игнорируете отсутствие товара, акции и все странные факторы. В результате получается нечто, что соответствует определению концепции доказательства, но, делая это, вы полностью отклонились от проблемы, которую пытались решить.
Kieran Chandler: Давайте немного поговорим о обратном тестировании. Это анализ исторических данных в прошлом, составление прогнозов и сравнение их. Почему обратное тестирование на самом деле не работает?
Joannes Vermorel: Обратное тестирование работает с точки зрения статистики, но оно имеет свои ограничения. С точки зрения цепочки поставок, обратное тестирование - это всего лишь маленький числовой инструмент, который является лишь частью всей картины. Если вы начинаете думать о том, чтобы оптимизировать закупочные паттерны ваших команд, оказывается, что, возможно, все эти минимальные объемы заказа не высечены в камне. Возможно, эти редкие покупки вызваны тем, что ваша закупочная команда договорилась о низких ценах, но с чрезвычайно высокими минимальными объемами заказа. Это заставляет вашу команду ставить дополнительную задержку между заказами, что усложняет все и увеличивает сроки поставки.
Что я хочу сказать, это то, что оптимизация - это не только одномерная вещь, такая как уменьшение ошибки с точки зрения точности прогнозирования. Это также о включении и пересмотра всех существующих процессов и корректировке того, что делается, когда это возможно, чтобы оптимизация стала реальной. Кроме того, вам нужно подумать о том, что вы на самом деле измеряете. Проблема заключается в том, что эти небольшие проекты концепции доказательства, которые неизбежно возвращаются к точности временных рядов, в конечном итоге имеют ошибку, выраженную в процентах, а не в долларах. Опять же, мы очень далеки от любых бизнес-фундаментов.
Кирен Чандлер: Итак, настоящая проблема с прогнозированием заключается в том, что вы сосредотачиваетесь только на этом аспекте и не смотрите на большую картину? Это очень специфический тип прогнозирования. Сбор всех необходимых данных сложен, поэтому вы можете быть уверены, что ваша концепция будет классическим прогнозом временных рядов с еженедельными входными данными и еженедельным прогнозом. Я думаю, что то, о чем мы сегодня говорим, исходит из некоторого опыта и боли, которую вы испытали в прошлом и ваших пробных версиях. Итак, какие основные проблемы вы столкнулись при проведении пробных версий?
Жоанн Верморель: Самое худшее в этом заключается в том, что иногда вы можете полностью успешно выполнить пробную версию, и это, вероятно, больше всего болит. Как компания, разрабатывающая программное обеспечение для предприятий, вы не выигрываете каждый потенциальный клиент, поэтому потеря клиентов - это просто часть жизни. Но то, что действительно болит, это когда вы выигрываете пробную версию, потому что, да, в пробной версии вы проявляете себя лучше всего, возможно, с большим отрывом, а затем, когда вы пытаетесь перенести это в производственную ситуацию, все полностью проваливается и не соответствует ни одному из ожиданий клиента. Вы понимаете, что это происходит потому, что вы перешли от игрушечной проблемы к реальной проблеме. Возможно, то, что вы делали для игрушечной проблемы, работало очень хорошо в этом ограниченном контексте с четко определенной метрикой, но полностью игнорировало все основы бизнеса. Когда вы переходите к производственной ситуации, вы понимаете, что ваше решение даже близко не дает ответа.
Самое худшее в этом заключается в том, что поскольку цепи поставок уже несколько десятилетий цифровизированы, для крупных компаний вы понимаете, что решение, которое вы вносите в компанию, будет таким же, как и предыдущие попытки. Оно будет производить массу чисел, которые будут полностью игнорироваться всеми. Неизбежно, все команды цепей поставок возвращаются к своим обычным таблицам Excel, полностью игнорируя дисфункциональные числа, полученные от еще одной системы.
Кирен Чандлер: Давайте теперь рассмотрим вещи с точки зрения компании. Хорошая вещь в пробных версиях заключается в том, что вы можете увидеть различные способы, которыми поставщики программного обеспечения подходят к проблеме и как они реагируют на определенные вызовы. Кроме того, какие альтернативы могут использовать компании вместо пробных версий? Что еще они могут сделать, чтобы увидеть, как разные компании справляются с задачей?
Жоанн Верморель: Альтернатива заключается в том, чтобы сосредоточиться на основах. Я указывал на то, что есть проблема консолидации данных. Современный способ сделать это на данный момент - построить “озеро данных”. Шаг дальше - предоставить некоторую значимую документацию с точки зрения цепи поставок. Чтобы быть успешным, вам нужно сосредоточиться на том, что не меняется. Ваша цепь поставок, вероятно, не изменится в своих самых основных аспектах. У вас по-прежнему будут поставщики, производственные единицы, склады и каналы распределения. Есть много вещей, которые ожидаются относительно стабильными, поэтому сосредоточьтесь на этом. Когда вы консолидируете данные, также консолидируйте соответствующую документацию, потому что большая проблема всегда заключается в семантике данных.
Что означают эти данные? Когда у нас есть дата заказа, это была дата, когда вы произвели заказ для отправки поставщику, дата, когда запись была зарегистрирована в вашей системе или дата, когда ваш поставщик подтвердил получение заказа? Есть дюжина возможностей. Вопрос в том, где все это документировано? Если у вас нет доступа к данным и семантике данных, нет никакой надежды на оптимизацию чего-либо. Опять же, например, когда я описывал подход к количественной цепи поставок, да, есть Lokad как платформа облачных вычислений, чтобы просто выполнять масштабирование всех этих числовых рецептов. Но вещи, которые являются крайне капиталистическими для клиента, это консолидация всех релевантных данных, понимание семантики цепи поставок, создание метрик, которые действительно отражают долгосрочные финансовые интересы вашей компании, что сложно. Создание процессов, которые хорошо сочетаются с физическими ограничениями вашей цепи поставок, и все это находится внутри и в значительной степени независимо от инструментария, который вы используете для выполнения этих числовых расчетов.
Кирен Чандлер: Если мы начнем объединять все вместе и сделаем выводы сегодня, пробные версии существуют в индустрии цепей поставок уже десятилетиями. Я имею в виду, вы действительно можете представить себе время, когда пробные версии вообще не существуют?
Жоанн Верморель: Очевидно, всегда будут молодые люди, которые не знают лучшего и будут просить еще одну пробную версию. Это просто факт жизни. И, возможно, они будут правы, потому что, опять же, есть ситуации, даже в цепях поставок, когда пробная версия действительно является правильным путем. Если у вас есть новый принтер штрих-кода, который, кажется, совместим с системой, в которой есть старые принтеры штрих-кода, но новый просто лучше, быстрее, дешевле, эффективнее и так далее. Это проблема, в которой вы можете купить еще один принтер штрих-кода и протестировать его в своем любимом складе. Таким образом, есть ситуации и проблемы, где пробная версия - это просто правильный путь. Однако, когда вы хотите подумать о задаче оптимизации цепи поставок в целом, которая действительно принимает глобальную перспективу на вашу цепь поставок, я бы сказал, не ожидайте слишком многого от масштабных экспериментов. Просто неизбежно, что вы поймете, что проблема сложная, и если вы не попытаетесь достаточно усердно, вы просто потерпите неудачу, потому что вы даже не попытались достаточно решить проблему.
Кирен Чандлер: Итак, в качестве заключительного ключевого сообщения сегодня, это означает, что пробные версии могут дать вам некоторое представление, но не ожидайте слишком многого, и они действительно не работают в целом?
Жоанн Верморель: Да, и противоположностью пробной версии не должно быть десятилетнее обязательство с поставщиком. Я имею в виду, это тоже еще одна вещь. Это не означает, что если вы не делаете пробную версию, вы не можете сказать: “Предположим, мы можем работать с поставщиком. Мы бы хотели начать инициативы, знаете ли, легкую промышленность, чтобы это не было очень дорого, и затем мы будем двигаться вперед с вами из недели в неделю”. Вместо того, чтобы обращать внимание на то, что мы должны оформлять инициативы в течение десяти недель, это больше похоже на то, удовлетворяет ли вас скорость прогресса инициативы? С недели на неделю вы делаете прогресс с удовлетворительной скоростью?
Если вы выбираете поставщика и через три недели понимаете, что все по-прежнему движется очень медленно, тогда вам следует прекратить, даже в срок, который короче, чем у типичной пробной версии. Вопрос скорее в том, что вы думаете о будущих десяти годах, но это ваше видение. Вы фокусируетесь на элементе, который будет крайне капиталистическим для вашей компании в следующее десятилетие. Но когда дело доходит до выгонки корпоративного поставщика из двери, потому что они просто не доставляют, это скорее еженедельная оценка, где вы пересматриваете, продвигаются ли дела и набирается ли какой-то импульс. Вы ищете все эти маленькие признаки с неопределенным планированием в виду.
Кирен Чандлер: Мы должны остановиться здесь, но мы увидим, удалось ли нам напугать всех.
