00:00:00 Данные лучше, чем вы думаете
00:03:43 Почему «плохие данные» становятся козлом отпущения
00:07:26 Транзакционные факты против параметрического мусора
00:11:09 Отчетный слой «торта» нарушает принятие решений
00:14:52 Подход «сначала решение» к полезной информации
00:18:35 Автоматизируйте параметры: сроки поставок, сезонность, новизну
00:22:18 Сложность ERP — не плохие данные
00:26:01 Поля дат скрывают множество реальных значений
00:29:44 Семантика подтверждается созданными решениями
00:33:27 Выбросы свидетельствуют о плохих методах, а не о плохих данных
00:37:10 Хранилища данных должны копировать, а не «улучшать»
00:40:53 Качество данных измеряется в долларах
00:44:36 Готовность ИИ: надежные транзакции, семантика прежде всего
00:48:19 Двойной запуск требует полностью автономного выполнения
00:52:02 Игра в перекладывание вины поставщика: предостерегающая история Lidl-SAP
00:55:45 Качество равно пригодности для принятия решений
Резюме
“Плохие данные” часто становятся козлом отпущения. Транзакционные записи большинства компаний — то, что было куплено, продано, отгружено, возвращено — достаточно качественны, иначе компания не выжила бы. Реальный беспорядок возникает из горы параметров, поддерживаемых вручную, и путаницы в том, что на самом деле означают поля (семантика), особенно в разрастающихся ERP. Не «очищайте» реальность, чтобы спасти слабые методы: выбросы зачастую отражают суть бизнеса. Оценивайте данные по результатам: если решения приводят к прибыльному улучшению, данные были достаточными; если выводы безумны, исправьте интерпретацию.
Расширенное резюме
Распространённая жалоба в цепочке поставок заключается в том, что «плохие данные» блокируют прогресс. Однако многое из того, что называют плохими данными, не является плохим или даже ключевым для проблемы. Это часто удобное оправдание — то для поставщиков, которым нужно переложить вину, когда их программное обеспечение не работает, то для аналитиков, обученных на аккуратных наборах данных из учебных заведений, которые поражены необъятностью реальных корпоративных систем. ERP-система с тысячами таблиц не является признаком плохих данных; это свидетельство сложности.
В обсуждении проводится чёткое разделение двух видов «данных». Во-первых, транзакционная реальность: что было куплено, продано, отгружено, возвращено, списано, оплачено — события с финансовыми последствиями. Эта информация обычно надежна по одной простой причине: компании, неспособные сохранить базовую транзакционную точность, долго не просуществуют. Рынки быстро наказывают за такую путаницу. Ошибки существуют, но обычно на низком уровне.
Во-вторых, это гора параметров, поддерживаемых вручную — целевые уровни обслуживания, коэффициенты безопасности запасов, флаги сезонности, сроки поставки введённые операторами. Эти «числовые артефакты» обычно устаревшие, непоследовательные и их дорого поддерживать в масштабах (миллионы SKU умноженные на множество параметров). Но главное, что они часто не нужны. Многие из этих входных данных должны быть выведены на основе исторических наблюдений или автоматизированы с помощью лучших методов. Отнесение их к «основным данным» создаёт самоиндуцированную нагрузку.
Основная скрытая проблема — семантика: что означает поле. Одна и та же колонка может менять смысл со временем, в рамках разных бизнес-процессов, или даже в зависимости от знака (продажа против возврата). Документация обычно скудна в начале. Единственный надежный способ проверки семантики — не бесконечные воркшопы, а проверка интерпретаций: генерируйте реальные решения — что купить, произвести, хранить, оценить — и смотрите, не становятся ли результаты абсурдными. Когда это происходит, проведите обратный анализ, чтобы найти ошибочное предположение.
Это также переосмысливает понятие «шумных данных». Если клиенты иногда заказывают 1, а иногда 100, это не плохие данные — это отражение бизнеса. Методы, рушащиеся под воздействием выбросов, дефектны; данные не должны искажаться для того, чтобы спасти слабую математику.
Наконец, касательно «готовности ИИ»: критерий — не моральная чистота данных, а их пригодность для цели. Если вы знаете, что покупаете, производите и продаёте, можно начинать. Настоящая работа заключается в системном сопоставлении семантики и быстром циклическом улучшении до тех пор, пока решения не станут разумными. В конечном счёте качество — это не слоган, а показатель экономической эффективности решений.
Полный текст
Conor Doherty: Это Supply Chain Breakdown, и сегодня мы разберём, почему ваши данные на самом деле лучше, чем вы думаете. Многие компании говорят нам, что их данные мешают им запускать нужные проекты. Что ж, сегодня мы здесь, чтобы оспорить эту идею. Мы настроены конструктивно.
Кто мы такие? Я — Conor, директор по маркетингу в Lokad. Слева от меня, как всегда, основатель Lokad, Joannes Vermorel. Прежде чем начать, сообщите нам в комментариях: во-первых, откуда вы нас смотрите? Мы в Париже. И во-вторых, соглашаетесь ли вы или считаете ли вы, что основные данные являются узким местом для проектов цифровой трансформации, теми самыми, в которые компании действительно хотят внедриться в наши дни? Оставляйте свои комментарии и вопросы ниже. Мы вернёмся к ним чуть позже.
И на этом, Joannes, передаю слово для обсуждения. Прежде чем начать, немного предыстории: как возникло это обсуждение. Как вы знаете, снимаем занавес: в конце каждого эпизода я говорю: «Эй, если хотите продолжить беседу, свяжитесь с Joannes и со мной лично. Мы будем рады пообщаться.» Всё это действительно. Ну, некоторые так и делают. Они хотят поговорить.
И недавно, как в общих, так и в индивидуальных беседах, мы обсуждали, и постоянной темой для практиков было недовольство состоянием данных: типа, «Мои основные данные — это спагетти», «Мой ERP — как швейцарский сыр», и тому подобное. Но вот в чём дело: именно это мешает мне заниматься всеми тем классными вещами, которые я хочу. Именно поэтому мы и обсуждаем сегодняшнюю тему.
Так, Joannes, почему данные получают такую плохую репутацию в цепочке поставок?
Joannes Vermorel: Можно назвать несколько причин, в зависимости от аудитории.
Для поставщиков, плохие данные — это идеальный козёл отпущения. Это способ вежливо, но решительно возложить вину на клиентов за любой дефект программного продукта. Поэтому это чрезвычайно удобно, и хорошие, талантливые поставщики сумеют убедить клиентов, что всё произошло из-за них, если система развалилась из-за недостаточных практик работы с данными, контроля качества и тому подобного.
Но, по моему мнению, это просто переложение вины. Вторая аудитория — это специалисты по цепям поставок, особенно те, кто участвовал, я бы сказал, в соревнованиях на Kaggle. Они привыкли, особенно в университете, к наборам данных, которые идеально аккуратны, и считают это стандартом. Они думают, что иметь набор данных, включающий пять таблиц, в каждой по пять полей, с обширной документацией для каждого поля, — всё это очень, очень ясно. Для меня это — проблема чрезмерно нереалистичных ожиданий.
В компаниях, например, если взять ERP-системы среднего класса, то речь идёт о 10 000 таблиц. В некоторых таблицах по 50 полей. Вот о чём идёт речь. Здесь возникает проблема: специалисты по данным имеют совершенно необоснованные ожидания относительно того, что такое корпоративные данные на самом деле.
И есть третья группа — практики. Суть в том, что они обычно обращают внимание на параметризацию своей бизнес-системы. Они не смотрят на реальное: устройство, проданное в эту дату, по этой цене. Обычно это не является их заботой. Это не касается ключевых транзакционных событий в прошлом.
Они смотрят так: «О, посмотрите, настройки сезонности, которые мы ввели в APS два года назад, теперь совершенно не соответствуют действительности из-за того или иного.» «Посмотрите, у нас столько корректирующих коэффициентов для формулы резервного запаса, и они тоже не соответствуют действительности», и так далее. Таким образом, когда эти практики жалуются на плохие данные, они выражают недовольство именно числовыми артефактами — вещами, которые не отражают ни прошлое, ни будущее. Они представляют собой своего рода параметризацию политики компании.
И, по моему мнению, если вернуться к первому случаю — поставщику программного обеспечения, проблема в том, что если используемое вами программное решение настолько зависит от этой вручную поддерживаемой параметризации, то можно с уверенностью сказать, что вы идёте ко дну. Таким образом, единственное решение — перестать рассматривать эти вещи как неотъемлемую часть системы. Они не должны вообще входить в картину, чтобы вам не пришлось с ними иметь дело.
Conor Doherty: Так что, поправьте меня, если я не прав, но кажется, вы говорите, что в целом существует две категории данных. То есть, когда люди говорят «данные», они подразумевают две категории. Одна — это, как вы называете, числовые артефакты: то, что они установили для себя, определённые цели, — а другая — это фактические необработанные транзакционные данные, которые вы считаете гораздо более важными.
Joannes Vermorel: Да. То есть, реальные транзакционные данные — это то, что произошло. Снова: вы продали или не продали. Вы заплатили поставщику, оформили заказ, выбрали единицу со склада, уничтожили единицу, которая была скоропортящейся и превысила срок годности, и так далее. Это транзакционные данные, и они обычно превосходны.
Однако во многих бизнес-решениях у вас также есть гора параметров, которые должны поддерживаться операторами — людьми, которые просто работают с системой. И суть в том: зачем вам вообще нужны эти миллионы параметров? Потому что очень часто речь идёт о громадном количестве параметров.
Чтобы представить масштаб: компания с миллионом SKU, что на самом деле не так уж много — если у вас, скажем, 10 параметров на SKU, и я говорю консервативно, это может быть намного больше — 10 параметров на SKU, то получается примерно 10 миллионов параметров, которые нужно поддерживать вручную. И это безумие.
Затем люди говорят: «О, это фигня, потому что мы не можем это действительно поддерживать.» Я бы сказал: да, абсолютно. Но реальность такова, что это на самом деле не нужно. И всё это действительно не передаёт информацию, потому что параметры устанавливались, глядя на остальные данные.
Когда люди устанавливают, скажем, целевой уровень сервиса, они делают это, внимательно изучая транзакционную историю. Таким образом, эта информация на самом деле совершенно преходящая и не должна восприниматься как часть ваших основных данных. Вот почему я говорю: проблема плохих данных намного меньше, чем многие думают. Всё дело в том, что они рассматривают как данные ту большую часть информации, которая ею не является.
Есть и второй аспект, но это уже другая проблема. Это когда люди хотят проводить дополнительный анализ на основе предварительно обработанных данных, особенно тех, что получены из слоя отчетности.
Опять же, я разделяю корпоративное программное обеспечение на три класса: системы источников данных — это ERP без планирования, поскольку планирования там не происходит, — системы отчетности, то есть бизнес-аналитика и все системы для визуализации и отчетности, — и затем системы интеллекта, те, которые занимаются принятием решений.
Единственный источник правды о данных находится в системах источников данных. Но очень часто, потому что люди иногда заблуждаются, или заняты, или по другим причинам, они хотят извлечь данные так, как они представлены в системах отчетности. И здесь мы оказываемся в ситуации, очень похожей на повара.
Представьте, у вас есть кухня, у вас есть все сырьё — мука, сахар, соль — и это система источников данных, сырые ингредиенты. А затем повар, используя систему отчетности, может приготовить торт. У вас есть торт, он отличный, и вы можете его съесть. Он предназначен для потребления человеком, так что это работает.
Теперь вы просите повара: «Просто возьмите этот торт и сделайте с ним что-нибудь ещё.» И именно это и происходит, когда вы пытаетесь использовать данные из вашего слоя отчетности, чтобы, например, запускать процессы принятия решений. Это идёт очень, очень плохо. Дело не в том, что повар плохой; просто если начать с торта, ничего уже не сделать. Это уже готовый продукт. Пытаться отделить сахар, муку и так далее — всё теряется.
Поэтому, если хотите что-то изменить, вам нужно вернуться к исходным ингредиентам. Это также типичная ошибка, которую я наблюдал во многих компаниях: они смотрят на данные в слое отчетности, предназначенные для потребления человеком, и пытаются извлечь эти данные и переработать их для других целей. Это ошибка. Вам нужно вернуться к исходным ингредиентам.
Conor Doherty: Ну, опять же, идея вернуться к исходным ингредиентам, вернуться к вашим фундаментальным данным — на самом деле, у меня есть… как хотите называть источник. Я использую это для фонового контекста, чтобы показать, что мы не просто спекулируем.
Сейчас я смотрю отчет Gartner, в котором опрошены сотни очень крупных компаний, и подтверждено, что большинство фирм даже не измеряют качество данных последовательно. На самом деле, существует лишь ощущение, что наши данные плохи, но это не обязательно подтверждается измерениями.
Итак, здесь два вопроса. Во-первых: удивляет ли вас это в целом? И во-вторых: как люди могут быстро оценить состояние своих данных?
Joannes Vermorel: Во-первых, если смотреть на транзакционные данные, ответ прост: приносит ли ваша компания прибыль? Если да, значит, у вашей компании высококачественные данные. Почему? Потому что я никогда не встречал компанию, которая бы не понимала, что она покупает, продаёт или производит, и при этом выжила.
Если вы даже не знаете этого, вы обанкротитесь со скоростью света. Если вы не знаете, что ваши поставщики отправили вам, с вас возьмут плату несколько раз. Если вы не знаете, что ваши клиенты на самом деле купили, то вы фактически взимаете с них плату неправильно. Всё происходит очень быстро. Это дарвинизм в действии. Рынки безжалостно устраняют эти компании; они исчезают.
Таким образом, как правило: если вы работаете в компании, которая не находится на грани банкротства из-за неэффективного управления, то история транзакций, скорее всего, имеет очень высокое качество. Да, может проскакивать канцелярская ошибка, примерно одна на тысячу — именно такой порядок величины я наблюдаю в большинстве компаний. У вас может быть от, скажем, 0,1% до иногда 0,5% канцелярских ошибок, но это очень, очень мало. Во многих компаниях этот показатель даже ниже.
Теперь, если мы говорим обо всех дополнительных данных — например, у вас есть параметризация в системе, которая позволяет задать целевой уровень сервиса для конкретной товарной единицы (SKU) — что вообще значит иметь здесь данные высокого качества? Это бессмыслица.
Если бы я выступал в роли адвоката дьявола, мне пришлось бы рассматривать, насколько эта настройка приближена к максимизации нормы доходности инвестиций в запасы компании при наличии этого параметра. Мы никогда не будем этого делать. Это слишком сложно. Если вы действительно примете идею о том, что ваша цепочка поставок должна максимизировать норму доходности, отлично, но тогда вы очень-очень быстро отбросите все эти неэкономичные подходы.
Итак, суть в том, что в этой параметризации, да, часто наблюдается много мусора. На самом деле, компании могут с этим справляться, потому что, скажем, специалист по запасам просто посмотрит на рекомендованное пополнение запасов, и это может не показаться логичным, но тот же специалист взглянет на недавнюю историю, учтет несколько моментов, и за минуту скажет: «Хорошо, заказываем 50 единиц», а затем перейдет к следующему SKU.
Итак, да, если вы хотите роботизировать или автоматизировать что-либо, основываясь на этих параметрических данных, их качество очень, очень низкое. Но единственное решение — воспринимать программные системы как системы интеллекта, которые не зависят от этой параметризации, являющейся лишь вспомогательной функцией для процесса, ориентированного на рабочий процесс.
Conor Doherty: Ну, я просто записываю мысль, чтобы развить эту тему, потому что, опять же, где это возможно, я люблю усиливать любые моменты конструктивной мысли.
Наша точка зрения, как хорошо известно всем, кто нас слушает, заключается в том, что цель данных, цель даже просто работы в компании, состоит в том, чтобы вы принимали лучшие решения — решения, которые действительно приносят больше денег. Теперь вы отметили, что лучшие решения не содержатся в системе отчетов; они уже присутствуют в ваших транзакционных данных.
Таким образом, по сути, чтобы люди принимали лучшие решения — определите «лучше» как хотите, поскольку для нас это означает максимизацию нормы доходности — для всех слушающих, если у вас есть транзакционные данные, вы уже можете начинать принимать положительные решения.
Joannes Vermorel: Я заметил, что практически для всех клиентов Lokad — и речь идет о годовом потоке товаров свыше 20 миллиардов, которые управляет Lokad — 99% информации приходит, а на самом деле даже больше, вероятно, 99,99% массы информации, поступает из транзакционных систем.
Кроме того, у вас, вероятно, будет несколько десятков метапараметров — экономических драйверов, которые нужно поддерживать вручную. Но здесь нужно быть очень консервативными, и на практике их всего несколько десятков. Таким образом, качество данных здесь должно быть высоким. Это сложно, но речь идет о очень небольшом количестве важных параметров — таких, которые настолько значимы, что за ними нужно проводить несколько встреч на каждый параметр.
Но в конечном итоге это должен быть стратегический, экономический, высокоуровневый параметр, а не нечто на уровне конкретной товарной единицы (SKU). Все это должно быть полностью автоматизировано, и это возможно.
Вот почему я говорю, что данные обычно отличные, потому что вам нужна транзакционная история. Если вы правильно подходите к проблеме, вам не нужно иметь миллионы параметров, существующих в вашей системе, которые нужно поддерживать вручную и которые могут принимать так много форм.
Многие системы просят специалистов вводить время выполнения. Но зачем вводить время выполнения? Вы наблюдаете его у вашего поставщика. Таким образом, время выполнения должно прогнозироваться, а не вводиться пользователем.
Многие системы просят пользователя классифицировать и, например, спрашивать: «Является ли этот товар сезонным?» Зачем вручную выполнять такие задачи, которые должны быть полностью автоматизированы, даже если у вас есть только этикетка продукта? В наши дни с LLM никогда не было легче автоматизировать такого рода обнаружение. «У меня есть новый продукт; будет ли он демонстрировать сезонные закономерности?» Это довольно просто.
Вам не нужен человек, чтобы вмешиваться и говорить: «О, да, лыжная комбинация, о, да, это будет сезонно. Хорошо, спасибо». Вот реальность: это сверхбазовые вопросы, и все системы просили специалистов постоянно вводить столько очевидных вещей, которые можно полностью автоматизировать.
Даже такие моменты, которые иногда совершенно сбивают с толку: специалисты должны вручную указывать, является ли продукт новым. Зачем нужны люди, чтобы сообщать системе, что это новый продукт? Вы можете заметить, что в истории не было никакой транзакции. Продукт был недавно создан в системе, транзакций ноль — зачем вручную помечать его как новый продукт? Это полная бессмыслица.
Но, опять же, по моему мнению, весь этот мусор в этой области, в этой параметризации всех этих политик, отражает устаревший взгляд на цепочку поставок. Так что, какими бы плохими ни были данные в этом аспекте, они не имеют значения. Важно транзакционные данные, и эти транзакционные данные хороши, потому что ваша компания жива.
Conor Doherty: Ну, по этому поводу — и опять же, это как углубиться немного в причины этого восприятия — потому что бессмысленно просто говорить: «У меня проблема». Скорее, нужно спрашивать: «Хорошо, каковы причины этого? В чем корень проблемы?»
Итак, слушая вас, кажется, что есть… хорошо, я приведу конкретный пример, а вы сможете развить его. Я слышал, и знаю, что вы слышали, одну из версий: «Моя ERP — настоящий беспорядок». И речь идет о системе учета, книге транзакционных данных: «У меня дублируются таблицы, неверно названы столбцы, полный хаос».
Теперь, технически, все транзакционные данные, сырые транзакционные данные, присутствуют. Проблема — если, конечно, есть проблема, и мы можем это обсудить — в том, что миграция вашей ERP привела к хаосу. И пусть будет оговорка: мы не продаем ERP, мы можем работать с чем угодно, так что у нас нет личной заинтересованности.
Но мой вопрос к вам: какова роль выбора программного обеспечения в возникновении эпидемии плохих данных здесь?
Joannes Vermorel: Снова, здесь, я бы сказал, что это неправильные ожидания. Именно так я и говорил, упоминая вторую аудиторию: специалистов по данным, участников конкурсов Kaggle. Я не утверждал, что ERP, системы учета, будут аккуратными и опрятными. Сложность будет зашкаливающей, и это нормально.
Это не плохие данные. Это просто очень сложные и непрозрачные данные — разные проблемы. Да, когда у вас есть 10 000 таблиц, очень сложно определить, где находится уровень запасов. Это сложно, и может занять недели, чтобы отследить, где конкретно находится определенный фрагмент данных в системе. Но, опять же, это не плохие данные.
Затем действительно возникает другая проблема: семантика для любого данного столбца может быть неоднородной. Что я имею в виду? Я имею в виду, что семантика, которую может иметь данный столбец данных, может варьироваться в зависимости от строки. Это усложнение.
Пример: некоторые ошибочные поставщики ERP несколько лет назад решили, что в таблице заказов, если количество положительное, это продажа, то есть продажа клиенту, и дата — это дата транзакции продажи. Но если количество отрицательное, это возврат, то есть дата возврата товара. Это означает, что у меня есть столбец с названием «дата заказа», однако, когда количество отрицательное, это не дата заказа: на самом деле это дата возврата.
Вот что я имею в виду: неоднородная семантика — то, что в одном и том же столбце, в зависимости от строки, в зависимости от определенных условий, иногда, например, после обновления ERP с 1 января 2020 года, дата заказа стала означать нечто иное. Из-за обновления системы семантика изменилась со временем.
Иногда даже команды, работающие в компании, в какой-то момент решают изменить процесс и переопределить, что означает данное поле, и оно получает новую семантику. Так что это очень сложно, да, и их выявление — действительно сложная задача.
Но, опять же, являются ли это плохими данными? Если вы знаете своего поставщика ERP, который, возможно, немного некомпетентен в плане разработки программного обеспечения, и он решил, что «дата заказа» может быть либо датой продажи, либо датой возврата — да, это ошибочно, но плохими ли это данными? Я бы сказал, данные просто хорошие. Просто семантика сбивает с толку.
Мы возвращаемся к тому факту, что для переустановления требуется много работы, и я с этим согласен. Но когда люди говорят: «Плохие данные», я очень часто отвечаю: нет, ваши данные в порядке. Просто нам нужно серьезно поработать над восстановлением фактической семантики ваших данных, а это требует огромных усилий.
Как правило, когда мы начинаем работать с клиентами, у нас обычно даже нет ни одной строки документации на каждое поле, каждую таблицу. Когда мы заканчиваем, у нас обычно получается страница документации на каждое поле, на каждую таблицу, для тех полей, которые действительно важны для инициативы Lokad, а именно оптимизации цепочек поставок.
Тем не менее, 20 таблиц, 20 полей — речь идет о 400 страницах документации. Не о IT-документации: о документации по цепочкам поставок, потому что нам необходимо иметь семантику того, что означает и подразумевает каждое поле с точки зрения цепочки поставок. Так что да, это очень много работы.
Я считаю, что, опять же, под предлогом плохих данных довольно часто многие люди просто не осознают, сколько усилий вкладывается в качественную семантическую проработку. Кроме того, у нас есть некомпетентные поставщики программного обеспечения, которые с удовольствием используют это, чтобы переложить вину за плохие данные на клиента, что является учтивым способом сказать: «Это ваша вина».
Conor Doherty: Ну, на эту тему, я на самом деле… вы, наверное, не знали, что я собирался это сделать, но, естественно, ваша новая книга уже вышла, а в подготовке к этому я на самом деле вернулся к вашей старой книге.
А для тех, кто уже прочитал обе книги Joannes, можете сейчас же доставать свой экземпляр. Конечно, код в последних нескольких сотнях страниц этой книги может быть сегодня не таким актуальным, но первые… я скажу, первые сто страниц по-прежнему очень, очень актуальны.
И для всех, у кого под рукой есть экземпляр: на странице 60, по теме семантики — и опять, это просто для демонстрации того, что речь не идет об абстрактной философии — я приведу очень конкретный пример и задам вам очень конкретный вопрос, но на мгновение я его процитирую, потому что нахожу это весьма познавательным.
Итак, здесь, на странице 60: когда мы говорим о количестве за день, относящемся к конкретной дате, сама дата несет в себе определённые неоднозначности. Это может быть дата, когда клиент сделал заказ. Когда клиент подтвердил предварительный заказ. Когда товар был отправлен клиенту. Когда запись заказа наконец поступила в ERP. Когда запись заказа в последний раз была изменена в ERP. Когда наконец был получен платеж от клиента. Вы упомянули и прочее. Но можно также сказать, когда истёк срок гарантии или возврата.
Теперь, все это конкретные семантические значения для простой даты.
Joannes Vermorel: Да. Для простой даты.
Conor Doherty: Именно. Но суть моего вопроса в том: какой ущерб, скажем, если я выберу один из этих вариантов? Это как дерево решений, где внезапно принятые мной решения кардинально различаются? Это настолько масштабный ущерб? Объясните, почему, чтобы они это поняли.
Joannes Vermorel: Да. Сложность семантики заключается в том, что когда вы ошибаетесь, единственный надежный способ понять, что вы ошиблись, — это то, что в конце конвейера вы получите безумные решения.
Пока у вас не будет полностью автоматизированного конвейера, который генерирует окончательные решения — распределение ресурсов для цепочки поставок: что покупать, что производить, где хранить товары, ваши ценовые уровни для каждого товара — пока у вас нет полностью автономного конвейера извлечения данных, числового алгоритма, генерирующего эти решения, вам не хватает того инструмента, который необходим для оценки, для проверки вашей семантики.
Если в вашей документации указано неверно — вы думаете, что дата заказа была датой, когда платеж был проведён; на самом деле это не так. Это когда вы готовы отправить товар клиенту — документация неверна. Вы этого не заметите. Никто этого не заметит.
Возможно, если вы проведёте глубокий анализ этого поля после двух дней работы, вы сможете это исправить. Но вы должны знать, что изначально была допущена ошибка. Мы говорим о сотнях полей даже для небольшой инициативы. Вы собираетесь проводить многодневные семинары для каждого поля, чтобы удостовериться, что ваша семантика правильная? Это не разумно.
Таким образом, разумный подход — приложить максимум усилий, сделать наилучшее предположение, а затем позволить решению генерироваться на основе этого толкования. И вот, иногда решения оказываются безумными. Когда мы начинаем инициативы, мы генерируем множество по-настоящему безумных решений.
Затем мы смотрим, и люди говорят: «О, это число — полная нелепость». Хорошо. Проведите обратный инженерный анализ того, что привело нас к этому нелепому решению, и затем, отслеживая назад, мы проводим обратное проектирование. Для этого вам понадобятся соответствующие инструменты.
В итоге вы скажете: «А, эта дата — о, мы неправильно поняли». Фактически, время выполнения, применимое в этой ситуации, совершенно иное, потому что мы неверно интерпретировали дату. Хорошо, давайте пересоздадим решение, скорректировав толкование этой даты. О, теперь это выглядит гораздо разумнее. Отлично. Далее.
По сути, единственный способ оценить, корректна ли ваша семантика, — это подвергнуть её испытанию в реальном мире: сгенерировать решение и позволить практикам сказать: «Это имеет смысл?» Если нет, вам нужно вернуться назад.
Ошибка, которую совершают многие альтернативные инструменты, заключается в том, что, когда сгенерированные данные оказываются бессмысленными, они говорят: «О, вам нужно подправить параметры». А я говорю: совершенно нет. Параметры следует корректировать только в том случае, если считается, что именно они являются корневой причиной возникшей проблемы. Если нет, это не решение.
Очень, очень часто проблема в том… Я не могу переоценить значение семантики. Это чрезвычайно сложно. Единственный способ — взглянуть на сгенерированные решения, что становится ещё более проблематичным, поскольку многие инструменты в сфере планирования никогда не генерируют конечные решения, и, таким образом, поставщики программного обеспечения лишают себя самого инструмента, который позволил бы им оценить, правильно ли они понимают семантику.
Conor Doherty: Верно. Опять же, исходя из того, что вы только что отметили: идея данных — мы используем данные для принятия решений, независимо от того, применяете ли вы вероятностное прогнозирование или нет, именно это продвигает подход Lokad. Но, по сути, данные используются для облегчения по крайней мере одного этапа: прогнозирования, после которого следует принятие решения.
Но одно из обычных замечаний, которые мы слышим от практиков: «В данных слишком много шума». В контексте прогнозирования, является ли шум в данных проблемой?
Joannes Vermorel: Совершенно нет. Если, например, ваш бизнес нестабилен — у вас клиенты, которые иногда заказывают одну единицу, а иногда 100 — такова реальность вашего бизнеса.
Многие методы в цепочке поставок, числовые методы, чрезвычайно дефектны. Когда они сталкиваются с чем-то, что можно квалифицировать как статистический выброс, числовой алгоритм начинает работать некорректно. Таким образом, появляется выброс, и система сходится с курса, выдавая полную бессмыслицу.
Затем люди говорят: «О, нам нужно вернуться и изменить эту историю, удалить выбросы». Они утверждают: «Эти выбросы плохие, они — симптомы чего-то плохого…» Здесь я полностью не согласен. Если ваши клиенты действительно заказали 100 единиц в прошлом, это может быть выбросом, но это реальность. Это произошло.
Очевидно, если в вашей системе имеется запись, что было заказано миллион единиц, но такой заказ никогда не создавался, хорошо, это плохие данные. Мы возвращаемся к транзакционным данным: транзакционные данные являются точными.
Но если у вас есть числовой метод, который даёт сумасшедшие результаты из-за того, что столкнулся с выбросом в исторических данных, проблема не в самих данных. Проблема в самом числовом методе, который просто отстой. Вы имеете дело с дефектным методом. Вам следует отказаться от этого метода и использовать что-то, что численно ведёт себя лучше. Вот в чём суть.
Это типичная ситуация, когда данные совершенно в порядке, а поставщики, предлагающие крайне дефектные методы, на самом деле убеждают своих клиентов, что им необходимо вручную корректировать плохие данные, в то время как данные абсолютно корректны, а дефект кроется в самом числовом алгоритме.
Conor Doherty: Ну, это действительно отличная возможность переключиться на… были некоторые… хорошо, два вопроса поступили приватно. Извините, дайте мне секунду, приведу в порядок и сформулирую их как вопрос.
Итак, с точки зрения практиков: «Мы уже создали data lake и, очевидно, у нас есть наш каталог, но наши пользователи, конечные пользователи, говорят, что данные неверны. По вашему мнению, узкое место — в технологиях или в семантике? И как, по вашему мнению, Joannes или Lokad избегают бесконечного переопределения меток?»
Поскольку, как вы уже много говорили о семантике и её важности, всё зависит от того, как вы строите свой data lake. Является ли ваш data lake точной копией записей из системы учёта? Никакой предварительной обработки, никаких улучшений, соединений или фильтров. Это буквально копия один к одному. Возможно, с небольшой задержкой, поскольку данные могут не копироваться в реальном времени из ERP, но, отбросив задержку, это именно та копия данных, какая они и есть.
Joannes Vermorel: Когда люди жалуются на это, мы снова возвращаемся ко второй проблеме с дата-сайентистами: «О, данные не аккуратны и не опрятны. Это совсем не похоже на эксперименты на Kaggle. Мы запутались». Я говорю: к сожалению, это мир, в котором вы живёте. Вы живёте в мире, где информация, содержащаяся в ваших бизнес-системах, чрезвычайно сложна. От этого не уйти. Нет альтернативы.
Так что вы можете жаловаться на это, но это всё равно, что жаловаться на гравитацию. Это просто факт вселенной. С этим нужно смириться.
Очень часто случается, что ситуация далека от идеального сценария, который я описал для data lake, когда это просто ванильная, чистая копия различных бизнес-систем. И вы можете спросить: зачем нужен data lake, если это всего лишь копия? Краткий ответ: потому что вы не хотите создавать нагрузку на вашу ERP-систему, вашу транзакционную систему. Ваша транзакционная система должна оставаться максимально быстрой.
Если у вас есть люди, которые запрашивают: «Я хочу все заказы за последние пять лет, просто сбросьте мне все это», это замедлит систему. Это означает, что кому-то, кто пытается что-то выполнить, придётся ждать несколько секунд, потому что ресурсы будут исчерпаны из-за этого масштабного запроса на извлечение данных. Именно поэтому лучшей практикой является создание реплики, на которой и выполняются эти масштабные запросы, а не на основной инстанции системы учёта.
Возвращаясь к первоначальной мысли: я наблюдаю, что во многих data lake IT-команда совершает серьёзную ошибку. Они повторно обрабатывают исходные данные. Они хотят их улучшить.
В чём же подвох? Подвох в том, что они не генерируют решения. Таким образом, они не понимают семантику. Поэтому вид трансформации данных, который они применяют, гарантированно будет ошибочным, и в итоге вы получите данные, которые не соответствуют вашим ожиданиям, не являются тем, что вам нужно, и их не исправить.
Как бы компетентны и преданы своему делу ни были эти специалисты, им не хватает самого инструмента — обратного проектирования этих безумных решений. По определению, генерировать бизнес-решения — не роль IT. Таким образом, IT может заниматься только инфраструктурой: настройкой баз данных, обеспечением безопасности инстанций, гарантией наличия достаточного объёма оперативной памяти, пропускной способности дисков, инфраструктуры — да.
Но если вам нужна семантика, IT не может заниматься семантикой. Семантика слишком специфична для каждой отрасли. Не стоит ожидать, что специалисты IT станут бухгалтерами, маркетологами, экспертами по цепочке поставок, юристами и тому подобное. Именно поэтому семантика должна находиться в руках практиков. По определению, если вы попытаетесь поручить эту задачу IT, они будут перегружены.
Conor Doherty: Ну, опять же, до меня поступили два предыдущих комментария — как лично по телефону, так и на встречах, — так что я выбираю, какой из них будет лучшим продолжением.
Я собираюсь развить идею конфликта между IT и операционными подразделениями. Буквально, комментарий звучал так: «IT говорит, что наши данные ужасны, а мои операционные сотрудники, практики, которые их используют, говорят, что с данными всё в порядке», потому что, как вы уже отмечали, если вы принимаете решения и зарабатываете деньги, для бизнеса это приемлемо.
Так что вопрос в следующем: как же вы — будучи на нашем месте — объективно оцениваете качество и решаете, что нужно исправить сейчас, что позже, а что просто запустить?
Joannes Vermorel: Рентабельность сгенерированных решений. Если у вас данные, которые якобы плохие, но сгенерированные решения оказываются удачными, разве это плохие данные? Может быть, нет. Возможно, они совершенно не важны. Нам это даже безразлично.
Если у вас есть данные, которые по своей сути несущественны, то факт их корректности или некорректности не имеет значения. Нам это не важно. Вот почему мы в Lokad оцениваем качество данных в терминах долларов: какова отдача от улучшения — что бы это ни значило и что может варьироваться в зависимости от случая — этих данных?
Если улучшение этих данных приносит миллионы долларов в год благодаря более качественным решениям, это невероятно. Это должно стать приоритетом. Вероятно, следует инвестировать. Если же данные могут быть и хуже, и это не имеет значения, тогда нам всё равно.
Вот почему я говорю: единственный способ оценить качество данных… именно поэтому IT не может сделать эту оценку, поскольку она основывается на решениях, которые в конечном итоге генерирует ваш бизнес. Хорошие они или плохие? Всё зависит.
Например, у вас может быть поле, в авиация, где существует множество полей, но одно из них заполнено неполностью для 99% элементов, и очень часто имеется примечание вроде: «Номер C находится в этом месте на компоненте». Являются ли это хорошими или плохими данными?
Реальность такова, что для подавляющего большинства авиационных компонентов определение номера C является очевидным. Вам не нужно примечание, указывающее, где находится номер C. Вы просто его находите, он очевиден, вы его считываете. Но в редких случаях это может быть сложно, и номер находится в месте, которое трудно достичь, зачастую по механическим причинам. В таком случае может присутствовать небольшое примечание, объясняющее, где искать.
Если смотреть с IT-перспективы, можно сказать: «О, вы так непоследовательны в заполнении данных. Посмотрите на это поле: всего около 0.5% элементов имеют установленный этот атрибут». Но реальность такова: да, но это те единицы, для которых это действительно имеет значение.
Так что, снова повторяю: единственный способ оценить, хорошие данные или плохие — это проверить их на практике в процессе принятия решений.
Conor Doherty: Ну, это, фактически, может ответить на следующий комментарий. Опять же, это очень, очень специфичный вопрос, но он затрагивает тему, которую я считаю слоном в комнате: люди сегодня хотят использовать свои данные для ИИ. Они хотят проекты в области ИИ и тому подобное.
Так что вот вопрос от друга канала: «Мы работаем более чем в 40 странах. Мы используем несколько ERP и WMS для управления запасами в 40 странах. Когда наши данные становятся достаточно хорошими для запуска ИИ, и что, по сути, вы делаете в первые 90 дней, то есть в первый квартал?»
Joannes Vermorel: Если в стране вы точно знаете, что покупаете, что производите и что продаёте, то вы готовы к ИИ. Вот и всё. Для нас всегда было так. Таким образом, порог входа невысок. Вот что интересно.
Порог для роботизации процесса принятия решений — называете вы это ИИ или как угодно — достаточно низок и является достаточным. Это то, что мы и делаем. Именно поэтому поддержка параметров, регулирующих все тонкости рабочих процессов для выполнения работы вручную, часто оказывается несущественной, поскольку мы не собираемся их использовать.
В сущности, ИИ полностью бросает вызов разделению труда. Весь рабочий процесс, в котором у вас сначала прогнозисты, затем планировщики, потом бюджети—
ИИ просто обработает данные как монолит, непосредственно полученные из системы учёта, и сразу выдаст решения с поддерживающей инструментальной базой. Это будут экономические драйверы, объясняющие, почему принято именно это решение. Отлично.
Ваша система ИИ — то, что я называю системами интеллекта — по сути представляет собой монолит, который принимает записи и генерирует решения с поддержкой инструментария, и всё.
Когда люди говорят мне: «У нас 40 ERP», я отвечаю: я не думаю, что кто-то имеет 40. Это было бы… Я видел компании… Я видел одну компанию, у которой в одной стране было 17 ERP. Это рекордсмен. Я не буду называть эту компанию. Это очень, очень крупная компания. Одна компания, одна страна. Вот где всё было по-настоящему безумно.
В итоге: вам придётся нести этот труд по восстановлению семантики для каждой ERP отдельно. Это будет больно. Очевидно.
Он спрашивал о первых 90 днях. Обычно нам требуется два месяца, чтобы установить семантику. Это то, что мы делаем для одного набора бизнес-систем, например, для одной страны. Но реальные границы не обязательно совпадают со страной. Они гораздо больше зависят от того, какие IT-системы нам нужно включить в охват: ERP, WMS, платформа электронной коммерции и тому подобное.
Наш охват в значительной степени определяется границами IT-систем, зачастую именно потому, что усилие направлено на установление семантики. Затем, как только у нас будет семантика, первая линия данных, мы начнём итерации по решениям, что обычно занимает около двух месяцев.
Итак: два месяца, чтобы установить конвейер данных и получить первое обоснованное мнение о семантике каждого поля. Но затем вам потребуется ещё два месяца дополнительных итераций, чтобы устранить все безумия, зачастую выявляя неверную семантику, полученную на первой итерации.
Таким образом, за 90… обычно это не 90 дней; это будет, скажем, 120 дней. Вы получите производственные решения без всякой безумности. Это типичная инициатива Lokad.
Но суть в том, что вы должны уметь проводить итерации очень быстро, обычно несколько раз в день, над этими безумными решениями, потому что вы обнаружите так много проблем с семантикой данных.
Conor Doherty: Ну, опять же, и я говорю это только потому, что вы упомянули об этом: вы даёте явный пример того, как мы могли бы это сделать. Основной момент в том, что то, что вы описываете, реализация, будет выполняться параллельно с тем, что мы называем дуальным запуском. Это работает параллельно с тем, что вы делаете сейчас, так что вы сможете своими глазами увидеть разницу.
Joannes Vermorel: Да. Именно поэтому крайне важно иметь полностью автоматизированное решение. Почему? Потому что если ваш параллельный процесс, ваш дуальный запуск, если второй требует много рабочей силы, откуда эта рабочая сила возьмётся?
Предположим, что у компании 15 планировщиков, и все они заняты на 100%. Если бы их загрузка была меньше, в компании было бы всего 12 или 10 планировщиков. По определению, у компаний нет запасных сотрудников, если не наступят особые обстоятельства. Как правило, на большинстве должностей нет лишних сотрудников, которые просто так без дела находятся, служа резервом для тестирования дополнительной системы.
Эти люди уже тратят восемь часов рабочего времени, чтобы просто выполнять свою работу в течение дня. Они могут уделить, возможно, полчаса в день, чтобы быстро взглянуть на другую систему, просто чтобы выявить выбросы, плохие решения, безумные решения, но они не могут провести восемь часов в своей системе, а затем ещё восемь часов в другой системе, где им придётся проходить тот же самый процесс.
Вот почему я считаю, что абсолютно критически важно, чтобы эта новая система принятия решений была полностью автономной; в противном случае, с операционной точки зрения, вы не сможете её внедрить. Это то, чему Локад научился десять лет назад.
Конор Дохерти: Ладно. Опять же, я исчерпал список комментариев, которые были заданы, или мне явно просили: “Please ask you on the air.”
Если говорить о завершении на конструктивной ноте: мы многое обсудили. Что вы видите в следующую неделю — или выберите любой временной горизонт, но не год — например, в ближайшие 30 дней, достаточно простые для внедрения изменения, которые люди действительно могут реализовать, если не для повышения качества, то хотя бы для улучшения внутреннего восприятия мощности текущего состояния их данных?
Йоаннес Верморель: Я не уверен, что в краткосрочной перспективе есть что делать. Для меня это действительно вопрос осознания того, что следует рассматривать как настоящий первичный источник информации, а что — как числовой артефакт. Это не одно и то же.
Как только вы проведёте это разделение и холодно взглянете на ваши реальные, основанные на событиях данные — данные, которые представляют истинные события, имеющие финансовое значение для компании — вы, скорее всего, заметите, что эти данные отличные. Да, они будут неупорядоченными, но они отличные. Так что это не проблема.
Это будет моё послание: плохие данные в компаниях, которые были оцифрованы на протяжении десятилетия и более, никогда не являются проблемой. Локад осуществил более 100 внедрений за последние пятнадцать лет.
Иногда у нас возникали проблемы с системами, которые были слишком медленными для извлечения данных. Это иногда было проблемой. Кстати, именно поэтому вы хотите добавить data lake, потому что иногда мы выполняли, например, “SELECT * FROM table X,” и система на самом деле выдавала исключение недостатка памяти при выполнении этого запроса.
Итак, у нас были случаи, когда извлечение данных было чрезвычайно сложным, потому что система рушилась, когда мы пытались выгрузить данные из неё. Это действительно вызывает озабоченность. Я искренне надеюсь, что вы не окажетесь в такой ситуации, но такое может случиться. Вот почему вам нужно иметь data lake.
Но помимо этих очень технических проблем, связанных с устаревшей инфраструктурой, у нас никогда не было действительно плохих данных. То, что у нас было в избытке, — это чрезвычайно непрозрачные, туманные данные, но по сути это было то, что нужно было решать на стороне Локад.
Так что да, это была большая проблема для нас, но по сути это не была проблема клиента. Клиент просто использовал свою систему так, как и должен. Результат был таков: для того, кто хочет внедрить автоматизированную систему принятия решений поверх этого, это является вызовом. Но ещё раз, вызов заключается в правильной интерпретации данных, а не в обвинении клиента за первоначальный сбор этих данных.
Конор Дохерти: Опять же, мы уже идем час, так что думаю, я могу позволить себе небольшой комментарий с точки зрения маркетинга, но это ключевой момент, который нужно донести.
Одна из вещей, которые я лично усвоил из множества недавних разговоров, заключается в том, что людям не всегда очевидно, что когда мы говорим: “Hey, look, your data is good enough as it is,” они не понимают, что если бы вы работали с Локад или с любым компетентным поставщиком, тогда эта нагрузка ляжет на него.
Так что: вы даёте им данные, вы даёте нам данные. Не то чтобы вам нужно было их обрабатывать. И они должны… опять же, если поставщик…
Йоаннес Верморель: Если поставщик не возьмёт на себя эту нагрузку, это рецепт для поиска козла отпущения.
Конор Дохерти: Именно.
Йоаннес Верморель: Поставщик просто будет обвинять вас, и вы окажетесь в ситуации, когда компания потратит полмиллиарда за семь лет. В итоге отчёт придёт к выводу, что всё было вашей виной, а поставщик просто скажет: “No, nothing to see here. It’s not my fault. Come on.”
Кстати, в случае с Lidl это очень интересно, потому что они возлагали вину на плохие данные по конкретному пункту. SAP сказал: “Oh, Lidl, they drive their analysis on the purchase price, and we drive all our analysis on the selling price, and that was the cause.”
Для меня это звучит так: ребята, это основы семантики 101. Во-первых, проблема тривиальна: это продажная цена или закупочная цена? Да, здесь присутствует семантический вызов: о какой цене идёт речь? Но давайте будем ясны: это не очень тонкое различие нюансов. Что касается семантического различия, то оно очень, очень легко разрешается.
А затем ещё более озадачивает тот факт, что, по-моему, вам нужны оба показателя. Вам нужны и закупочная цена, и продажная цена, чтобы можно было определить маржу.
Так что идея о том, что поставщик через семь лет сумеет свалить вину на клиента, говоря: “Oh, you know what, they are organizing all their supply chain around the purchase price, it’s such a complication for us because we are expecting the selling price,” — это именно тот вид уловок, который можно наблюдать, если поставщик не настроен на предоставление действительно экономически эффективных решений.
Это должно быть отправной точкой; в противном случае, в области цепочки поставок вы столкнётесь с множеством нелепостей. В конце концов, после того как будет потрачено большое количество денег, поставщик сумеет переложить вину на вас, обнаружив плохие данные.
Опять же: если мы не признаём, что имеют значение только решения, существует так много кусочков данных, которые абсолютно несущественны. Очевидно, что эти несущественные данные будут очень низкого качества, и это совершенно нормально.
В ERP-системе 10,000 таблиц. В каждой таблице десятки полей. Должны ли все эти данные быть аккуратными и организованными? Безумие. Зачем вам это вообще нужно? Это слишком дорого.
Таким образом, если вы играете в эту игру с плохими данными с поставщиком, поставщик всегда будет выигрывать, потому что всегда найдётся множество таблиц и полей, где, объективно, данные окажутся хуёвыми и несущественными. Вот ключевой момент: несущественные.
Конор Дохерти: Хорошо. Итак, в заключение: выбирайте поставщика тщательно, если вы сводите всё к одному.
Йоаннес Верморель: Ага. И действительно поймите: когда вы говорите о качестве ERP, какова цель? Какова цель? Не существует такой вещи, как чистота ERP в моральном смысле для компании. Она служит своей цели.
Качество — это пригодность для задачи, и всё.
Конор Дохерти: Вот и всё. Огромное вам спасибо. У меня закончились вопросы. Мы уже идём час, так что, думаю, время истекло.
Как всегда, спасибо за ваши идеи, и спасибо всем за присутствие и за ваши личные сообщения. Как я сказал в самом начале и откуда возникла эта тема, если вы хотите продолжить разговор, свяжитесь с Йоаннесом и со мной лично. Мы всегда рады пообщаться.
Как я говорил на прошлой неделе, и буду говорить каждую неделю, мы замечательные люди. Посмотрите на нас. На этой ноте увидимся на следующей неделе. У меня есть особая тема для следующей недели, так что мы объявим об этом в понедельник. Но на этой ноте, возвращайтесь к работе.
