00:00:03 Обзор подготовки данных в науке о данных.
00:00:46 Недооценка сложностей подготовки данных.
00:02:01 Типичная продолжительность проекта по подготовке данных.
00:03:19 Проблемы скорости и точности подготовки данных.
00:06:07 Важность документирования подготовки данных.
00:08:00 Интерпретация ‘даты заказа’ в цепях поставок.
00:09:02 Сложности интерпретации данных после обновления системы.
00:10:07 Понимание семантики данных для избежания ошибок.
00:10:15 Исследование случая: особенности системы цепи поставок.
00:14:53 Необходимость документирования данных в бизнес-операциях.
00:16:01 Важность отслеживания данных в цепях поставок.
00:17:24 Расширение объема данных в автоматизированном принятии решений.
00:18:42 Риски полагаться на отдельных лиц для воспоминания о данных.
00:19:02 Проблемы и ожидания в подготовке данных.
00:20:13 Подготовка данных как комплексное усилие всей компании.
00:21:56 Оценка правильности интерпретации данных на основе реальной эффективности.
00:23:02 Последствия неправильной интерпретации данных и важность их отслеживания.
00:24:37 Трудности и результаты неправильной подготовки данных.
00:24:49 Понятие ‘хорошей’ подготовки данных.
Резюме
В этом выпуске Lokad TV ведущий Киран Чандлер и основатель Lokad Жоанн Верморель обсуждают тонкости подготовки данных в науке о данных, процесс, который часто недооценивается, но в настоящее время приобретает приоритет из-за соответствия требованиям GDPR. Верморель подчеркивает, что подготовка данных, которая часто занимает несколько месяцев и требует значительных ресурсов, является важной для предотвращения проблемы “мусор на входе, мусор на выходе”. Для этого необходимо преобразовать несогласованные или неполные данные в понятный формат, что требует тщательной документации. Процесс является сложным и зависит от многогранных проблем бизнеса и исторического контекста данных. Верморель выступает за распределенный подход, включающий различные организационные команды, и подчеркивает, что эффективная подготовка данных должна быть доступной и способствовать ясному принятию решений.
Расширенное резюме
В выпуске Lokad TV, ведущим которого является Киран Чандлер, он и основатель Lokad Жоанн Верморель обсуждают сложную, но важную роль подготовки данных в области науки о данных. С учетом роста требований GDPR, данные становятся ключевым фокусом для многих руководителей, с оценкой, что компании в настоящее время тратят более 450 миллиардов долларов только на подготовку данных. Целью подготовки данных является преобразование необработанных, часто несогласованных или неполных данных в формат, который легко интерпретировать и применять.
Верморель говорит о частом недооценении сложности подготовки данных. Несмотря на то, что бизнесы вкладывают значительные ресурсы в этот процесс, множество проектов отстает от графика или выходит за рамки бюджета. По словам Вермореля, большинство ошибок в ИТ-системах можно связать с проблемами на этапе подготовки данных. Он объясняет, что многогранные проблемы бизнеса проявляются в виде шагов подготовки данных, что добавляет сложности в задачу.
Что касается сроков, Верморель предлагает, что крупные проекты по подготовке данных могут занимать не менее нескольких месяцев, часто до шести месяцев. Хотя предполагается, что улучшенные инструменты или более масштабируемое программное обеспечение должны ускорить процесс, он указывает на то, что уровень зрелости всей экосистемы замедляет прогресс. Чтобы действительно избежать проблемы “мусор на входе, мусор на выходе”, данные сначала должны быть задокументированы и прояснены. Этот процесс, по его мнению, способствует увеличению сроков.
На вопрос о возможности ускорения этого процесса Верморель объясняет, что это не так просто, как просто добавить больше ресурсов. Данные, с которыми работают, изначально не были созданы для целей подготовки данных, а являются побочным продуктом корпоративных систем. Например, он описывает, как основная функция системы точки продажи - обработка платежей клиентов, а не сбор данных. Однако, даже эти системы производят данные, которые могут быть несогласованными или содержать ошибки из-за практических операционных причин, таких как ошибки штрих-кода. Для эффективного использования этих несоответствий требуется обширная подготовительная работа для оптимизации цепи поставок.
Верморель также говорит о важности документации в подготовке данных. В Lokad проект по подготовке данных обычно начинается с менее чем одной строки документации на поле таблицы и заканчивается одной страницей документации на поле таблицы. Эта всесторонняя документация является важной для предотвращения проблемы плохого качества входных данных, приводящей к плохому качеству выходных данных или “мусор на входе, мусор на выходе”. Шестимесячный срок подготовки данных, следовательно, включает в себя процесс создания этой обширной документации.
Верморель начинает с того, что обращается к сложностям и потенциальным неправильным интерпретациям, которые могут возникнуть из одного простого фрагмента данных: даты исторического заказа. Он объясняет, что ‘дата’ не так проста, как может показаться, так как существует несколько потенциальных интерпретаций, например, когда клиент щелкнул по товару, когда он подтвердил свою корзину, когда платеж был обработан или когда товары стали доступными на складе.
Он указывает на то, что интерпретация таких данных может меняться со временем из-за обновлений системы или изменений в деловых практиках. Таким образом, важно понимать не только сами данные, но и исторический контекст, в котором они были созданы. Если эти сложности не учитываются, бизнесы могут столкнуться с проблемой “мусор на входе, мусор на выходе”, где неправильные интерпретации приводят к принятию плохих решений.
Верморель подчеркивает пример с одним из клиентов Lokad, чтобы проиллюстрировать свою точку зрения. Этот клиент работает в требовательной промышленной среде с короткими сроками поставки, где точное количество заказанных товаров является важным. В системе клиента есть функция, при которой, если поставленное количество не соответствует заказу, весь заказ отклоняется и возвращается. Это приводит к ситуации, когда, если они получают немного больше, чем заказано, им приходится изменять исходный заказ в системе, чтобы соответствовать поставленному количеству. Это обходное решение позволяет им принять поставку и
избежать нарушений в их промышленной деятельности.
Однако этот процесс используется опытными поставщиками, которые теперь поставляют немного больше, чем заказано, зная, что это будет принято. Это приводит к заказам, которые кажутся завышенными по сравнению с фактическими потребностями, создавая данные, которые искажают результаты работы команды по закупкам. Верморель подчеркивает, что эту сложность необходимо задокументировать, чтобы избежать неправильных интерпретаций. Он настаивает на том, что проблемы возникли не из-за плохой работы команды по закупкам, а из-за ограничений в системе и того, как пользователи справлялись с этими ограничениями.
Переключаясь на другую тему, Верморель говорит о том, кому важны исторические данные, помимо компании Lokad, которая использует их для вероятностного прогнозирования. Он указывает на то, что компании тщательно контролируют деньги, которые они ожидают получить или заплатить, и те, кто этого не делают, исчезают со временем. Это, по его словам, является формой “дарвинизма” в бизнесе. Он предлагает, что компании, которые обращают внимание на свои финансовые операции со временем, естественным образом заботятся о своих исторических данных.
Разговор переходит к подготовке данных. Верморель подчеркивает, что данные по своей природе не являются “чистыми” или полностью понятными. Он предлагает, что подготовка данных - это не только вопрос информационных технологий; это о понимании всех аспектов бизнес-данных для решения всех бизнес-задач. Отдел информационных технологий, отмечает он, не может ожидать, что он овладеет каждым бизнес-аспектом и не должен нести единоличную ответственность за подготовку данных.
Верморель предлагает распределенный подход, включающий разные команды с различной экспертизой в организации. Данные, относящиеся к закупкам, например, должны включать команды по закупкам. Аналогично, данные, необходимые для оценки поставщиков, должны включать команды по снабжению. Такой подход может использовать необходимые идеи для эффективной подготовки данных.
Обращаясь к вопросу о том, как быть уверенным в интерпретации данных, особенно когда информация неполная, Верморель связывает это с научными теориями; невозможно знать, что теория верна, но ее можно проверить, когда она выдерживает проверку. Правильность подготовки данных устанавливается, когда принимаемые решения, основанные на интерпретации, являются правильными. Если неправильная подготовка данных приводит к бессмысленным решениям, причину можно проследить, исправить и переоценить.
Затем Верморель описывает, как должна выглядеть хорошая подготовка данных, особенно в сложных сценариях цепочки поставок. Он сравнивает ее с хорошо написанной книгой, предоставляющей актуальные деловые идеи и перспективы, а не только технические детали. Она должна быть доступной и распространяться по всей организации, способствуя общему пониманию. Для ее поддержания требуется постоянное усилие по документированию, поддержке и пониманию данных.
Наконец, Верморель подчеркивает, что подготовка данных должна быть интерпретацией правильного понимания самих данных. Как только это понимание установлено и поддерживается, логические операции с данными становятся довольно простыми. Хорошая подготовка данных является как хорошо написанным руководством, так и общим пониманием, которое позволяет принимать ясные и эффективные решения в цепочке поставок.
Полный текст
Киран Чандлер: В сегодняшнем эпизоде мы будем говорить о подготовке данных, одном из основных аспектов науки о данных. Учитывая недавние законы о соблюдении GDPR, данные очень важны для многих руководителей. Это большой бизнес, согласно последнему исследованию, компании тратят более 450 миллиардов долларов только на подготовку данных. Подготовка данных заключается в преобразовании сырых данных в понятный формат, чтобы их можно было использовать с пользой. Это нелегкая задача, учитывая, что данные поступают из разных источников и часто могут быть несогласованными, неполными и содержать ошибки. Итак, Джоаннес, почему мы сегодня говорим о подготовке данных? Ведь если эти компании инвестируют более 450 миллиардов долларов, это должно быть то, что мы уже понимаем.
Joannes Vermorel: Да, абсолютно. Подготовка данных - это область, которая довольно хорошо известна, но систематически недооценивается в плане изменений. Интересно, потому что большинство проектов по подготовке данных не успевают сдать в срок и превышают бюджет. Основная проблема заключается в том, что многие фактические ошибки, которые вы видите в ИТ-системах, программном обеспечении предприятия в целом, связаны с проблемами на уровне подготовки данных. Это чрезвычайно сложно. Несмотря на то, что это хорошо известная проблема, основная проблема заключается в том, что бизнес-сложности возникают снова на этапе подготовки данных, что делает ее неограниченной областью. Нет окончательного рецепта для подготовки данных.
Kieran Chandler: Сколько времени должно занимать подготовка значительного объема данных?
Joannes Vermorel: Я никогда не видел крупномасштабного проекта по подготовке данных, который занял бы меньше нескольких месяцев. Обычно это больше похоже на шесть месяцев. Можно возразить, что с помощью лучших инструментов и более масштабируемого программного обеспечения это должно быть быстрее. Однако реальность в том, что в экосистеме так мало зрелости, что для практически любой компании, кроме некоторых чемпионов по данным, таким как Google, сначала данные должны быть задокументированы и уточнены. С этими данными нужно сделать столько вещей, чтобы избежать проблемы “мусор на входе, мусор на выходе”. Поэтому это занимает пару месяцев, и шесть месяцев - разумная цель, если вовлечена сложная поставочная цепочка.
Kieran Chandler: Шесть месяцев звучит довольно долгим периодом времени. Есть ли способ ускорить этот процесс? Если я крупная организация, не могу ли я просто бросить больше людей на эту проблему?
Joannes Vermorel: Здесь возникает конкретная проблема: можно ли нанять девять женщин, чтобы родить ребенка за один месяц? Проблема заключается в понимании типа проблем, с которыми мы имеем дело. Во-первых, данные, которые у вас есть, не были созданы для того, чтобы быть данными в первую очередь. Это побочный продукт вашей корпоративной системы, которая просто управляет вашей компанией. Давайте возьмем пример программного обеспечения точки продажи, что-то, где вы можете заплатить в супермаркете. Его основная функция - обработка клиентов, которые хотят выйти из магазина, заплатив то, что они должны заплатить. Так что, если штрих-код по какой-либо причине не сканируется, кассир, скорее всего, будет сканировать продукт с похожей ценой дважды. В конце концов, вы заплатите правильную цену, но в плане данных у вас будет учет продукта дважды.
Kieran Chandler: Один продукт, учтенный ноль раз, может создать проблемы в плане управления запасами, потому что ваши электронные записи становятся неточными. Это не хорошее решение, и рекомендуется его избегать. Но реальность в том, что если у вас есть выбор между решением проблемы с данными и позволением вашей компании работать более плавно, те, кто работает на месте, люди, которым нужно физически управлять поставочными цепочками, всегда будут предпочитать решение, которое не нарушает поток товаров, клиентов, услуг и всего остального. Работа компании является главной задачей, а данные - только побочным продуктом второго порядка. Они никогда не рассматриваются как гражданин первого класса. Вот почему всегда есть все эта работа, которую нужно выполнить, потому что данные не были собраны только для того, чтобы вы могли оптимизировать поставочную цепочку. Отсюда все эти проблемы?
Joannes Vermorel: Действительно, отсюда и все эти изменения.
Kieran Chandler: Давайте поговорим о той документации, о которой вы упоминали ранее. Что вы ожидаете увидеть в этой документации и как она помогает? Просто чтобы понять, если мы вернемся к шестимесячному периоду, какой объем документации мы ожидаем?
Joannes Vermorel: Правило, которое можно применить, заключается в том, что, как правило, когда мы в Lokad начинаем проект, у нас меньше одной строки документации на таблицу на поле. Обычно у нас даже этого нет. Мы начинаем много проектов, где у нас даже нет одной строки документации на таблицу в ERP, MRP, WMS или любую другую систему, используемую для управления вашей цепочкой поставок. Когда мы заканчиваем, у нас получается одна страница документации на поле на таблицу. Так что, если у вас есть 20 таблиц с 20 полями, мы говорим о 400 страницах документации. Да, на создание этих 400 страниц документации требуется шесть месяцев.
Kieran Chandler: Звучит как огромное количество документации. Она действительно все нужна?
Joannes Vermorel: Все это нужно, если вы хотите избежать мусора на выходе.
Kieran Chandler: Почему так?
Joannes Vermorel: Рассмотрим практический случай: предположим, у меня есть таблица с названием ‘заказы’. Она содержит мои исторические заказы и имеет дату. Но это просто? Разве мы действительно говорим о том, о каком виде даты идет речь? Это дата, когда клиент щелкнул на товар, чтобы положить его в корзину на сайте электронной коммерции? Или когда клиент подтвердил корзину и сделал оплату? Или когда оплата была подтверждена процессором кредитных карт? Или когда запись была зарегистрирована в системе? Или когда заказ на покупку был последний раз изменен в системе? Есть около 20 различных интерпретаций только для этого поля ‘дата’.
Кроме того, если у вашей компании есть более десятилетнняя история, вероятно, что тонкая грань интерпретации ‘даты заказа’ изменилась со временем. Вы можете оказаться в ситуации, когда произошло обновление системы, и семантика этого столбца изменилась.
Это также не является чем-то единообразным для всей вашей истории. Затем могут возникнуть дополнительные сложности, такие как крайние случаи. Например, эта дата должна быть датой, когда клиент подтвердил корзину, за исключением случая, если платеж в конечном итоге был отклонен как мошенничество. В этом случае это дата и время, когда заказ был отклонен как мошенничество.
Опять же, это на самом деле не очень хорошее решение, но компании, управляющие сложными цепочками поставок, имеют сложные системы и много истории. Так что IT не обязательно было сделано идеально с первого дня, и вам приходится справляться со всеми этими историческими сложностями. Они отражаются в этой документации. Если вы не учтете все эти сложности, у вас возникнут проблемы при анализе этих данных.
Kieran Chandler: Чтобы принять оптимальное решение для вашей цепочки поставок, вы можете столкнуться с проблемой ‘мусор на входе, мусор на выходе’, если неправильно интерпретируете данные. Так что вы хотите сказать, что все дело в уточнении семантики данных, верно?
Joannes Vermorel: Именно. Вам нужно понимать, что данные - это не просто числа. Они представляют различные факторы, которые могут быть объединены в одной ячейке. Здесь речь идет не только о понимании программного обеспечения, которое производит данные, но и о том, как люди взаимодействуют с программным обеспечением. Ваша документация должна учитывать человеческий аспект того, что делают люди.
Kieran Chandler: У вас есть хороший пример того, как один из ваших клиентов сталкивался с этой проблемой в прошлом и как это повлияло на их компанию?
Joannes Vermorel: Да, я могу привести пример. У нас был клиент, который вел очень требовательную операцию, требующую высокого уровня доступности. Они передавали заказы с очень короткими сроками поставки своим поставщикам. Их система имела интересную особенность. Если количество поставленных товаров не соответствовало запрошенным изначально, то весь заказ должен был быть отклонен и отправлен обратно поставщику.
Предположим, например, вы заказали 1000 единиц, но поставщик доставил 1050 единиц, тогда вам придется отклонить это. Проблема в том, что если вы отклоните это, это может привести к серьезным операционным проблемам. Система не позволяла им изменять количество, поэтому в итоге, когда поставленные количества не соответствовали заказанным количествам, они изменяли исходный заказ, чтобы отразить поставленное количество.
Kieran Chandler: Итак, вы хотите сказать, что они меняли исходный заказ, чтобы соответствовать тому, что было доставлено?
Joannes Vermorel: Именно. Однако это привело к другой проблеме. Поставщики заметили эту практику. Они поняли, что могут поставлять больше, чем было заказано, зная, что компании нужны эти поставки. Они не доставляли чрезмерное количество, но что-то, что компания рассмотрела бы как приемлемое.
В данных это выглядело так, будто исходный заказ был на большее количество. Это привело к странной ситуации, когда заказы казались слишком большими по сравнению с тем, что было нужно, что создавало впечатление, что команда закупок плохо выбирала правильные количества. Однако проблема не была в команде закупок, а в ограничениях системы и том, как люди справлялись с этими ограничениями.
Все эти детали нужно было задокументировать, чтобы избежать неправильных выводов. Команда закупок не была плохой в своей работе. Проблема заключалась в том, что у них была система с ограничениями, с которыми они просто пытались справиться.
Kieran Chandler: Система порождает все эти странные побочные эффекты. Для того, чтобы понять это, нужна целая страница объяснений, но нет пути к выходу. Это просто сложность самого бизнеса, которая отражается в этих данных. Давайте отойдем от этих хитрых поставщиков. Это определенно забавный пример. Итак, вы упомянули аспект “человека”. Очевидно, в Lokad мы используем исторические данные для составления вероятностных прогнозов на будущее. Кто еще на самом деле интересуется историческими данными, кроме нас?
Joannes Vermorel: Обычно все, что действительно касается суммы денег, которую вы ожидаете получить или заплатить, привлекает большое внимание. Не то чтобы люди не обращали внимания, но компании, которые не тесно контролировали деньги, которые они должны получить, обычно исчезали со временем. Это как дарвинизм в действии. Если вы даже не обращаете внимания на это, вы просто исчезаете. Вот почему, пять веков назад, итальянскими монахами была изобретена двойная запись бухгалтерии. Если вы не обращаете внимания, ваш монастырь просто рушится из-за плохих практик бухгалтерии. Это не совсем новая проблема, но сейчас много данных, которые раньше не считались критическими, становятся таковыми.
Для примера, чтобы правильно учитывать дефицит товара в прошлом, вы учитывали то, что вы закупаете, чтобы знать, сколько вы должны платить поставщикам, и то, что вы продаете, чтобы знать, сколько вам должны платить ваши клиенты. Но что насчет отслеживания исторического дефицита товара? Пока у вас есть практикующий специалист по цепочке поставок, который решает, какое количество товара закупать вручную и помнит, что были некоторые странные периоды с дефицитом товара, вам не нужно иметь эти исторические записи. Они являются частью вашей системы.
Проблема в том, что как только вы хотите перейти к чему-то более количественному, например, к тому, что мы делаем в Lokad с автоматизированными решениями для всех этих рутинных задач, таких как определение объема заказа, точные записи о исторических уровнях запасов становятся намного важнее. В противном случае, ваша автоматизация неправильно интерпретирует, что является продажами, а что было недостатком спроса.
Если вы хотите иметь более высокую степень автоматизации в своей компании, то вам нужно обратить внимание на более широкий спектр данных, а не только на сырые бухгалтерские данные. Ваш бухгалтер не заботится о ваших днях без товара, но ваше программное обеспечение для оптимизации цепочки поставок будет. Вам нужно расширить круги данных, которые действительно являются частью вашей области, которые задокументированы, и где вам нужен контроль качества и гарантия.
Кирен Чандлер: Итак, мы довольно сильно полагаемся на этого одного человека, который помнит, что произошло в прошлом. Разве нам не следует быть лучше подготовленными к данным, поступающим в реальном времени? Разве отдел информационных технологий или кто-то еще не должен готовить эти данные и убедиться, что они чистые с самого начала? Кажется, что это более простой способ сделать вещи.
Жоанн Верморель: Да, но проблема не в компетентности IT. Нет такой вещи, как чистые данные. Дело в том, что данные не естественным образом понимаются достаточно глубоко, и не все бизнес-аспекты должны быть должным образом освещены.
Кирен Чандлер: Часто говорят, что компании инвестируют миллиарды в искусственный интеллект, но реальность в том, что сложность самого бизнеса проявляется в этой задаче, в этом вызове подготовки данных. И говорить “о, отдел информационных технологий должен заботиться об этом”, значит ожидать, что IT будет управлять компанией и знать обо всех бизнес-аспектах.
Жоанн Верморель: Абсолютно, это создает организационную проблему, потому что вы ожидаете, что IT будет таким же экспертом в области управления персоналом, маркетинга, закупок и так далее. Я имею в виду, вы ожидаете полного владения всеми бизнес-аспектами от IT-отдела. Но это слишком много. Отдел информационных технологий уже должен иметь дело со всеми изменениями в IT, поэтому не следует ожидать, что они будут решать каждую бизнес-проблему в компании. В качестве альтернативы, вы можете переопределить IT как всю вашу компанию, но это противоречит цели.
Вернемся к рассматриваемому случаю, подготовка данных должна быть достаточно распределенным усилием внутри компании, потому что, в конечном счете, только люди, которые могут предоставить уровень понимания, необходимый для подготовки данных, связанных, скажем, с закупками, являются команды по закупкам. Аналогично, если вы хотите создать оценочную таблицу поставщика и иметь данные, подготовленные с достаточной точностью, чтобы это действительно имело смысл, вам придется обратиться к вашим командам, ответственным за поставки.
Каждый раз, когда вы решаете проблему, вам нужно вовлекать специалистов по этой проблеме внутри вашей компании, потому что они люди, которые дадут вам необходимое понимание для подготовки данных, чтобы они имели смысл. Это не строго проблема IT. Речь идет о сборе всего необходимого понимания, чтобы при обработке данных вы не получили данные, которые не имеют смысла с точки зрения бизнес-проблемы, которую нужно решить.
Кирен Чандлер: Итак, мы еще не дошли до этого, судя по всему. Некоторые компании уже там, но они являются исключением, а не правилом. Как можно быть уверенным, если у вас нет всей информации и есть пробелы, которые вы интерпретируете, что ваша интерпретация является правильной? Могут быть множество возможностей.
Жоанн Верморель: Абсолютно, и это интересный момент, потому что это похоже на научные теории. Вы никогда не знаете, что ваша теория правильна, вы просто знаете, что она достаточно хороша и когда она проверяется на практике, она работает. У вас нет ничего лучше, чтобы сделать ее работу лучше.
Итак, что это означает для подготовки данных? Это означает, что вы знаете, что ваша подготовка данных правильна, когда в конце конвейера данных решения, которые вы автоматически генерируете на основе этой интерпретации, являются правильными. Если у вас есть правильные решения, это означает, что ваша логика оптимизации эффективна, ваши слои машинного обучения точны и многое другое. В основном, невозможно получить правильные решения, сгенерированные неправильной интерпретацией. Обычно, когда вы неправильно интерпретируете и подготавливаете свои данные, они настолько искажают ваши результаты, что нет никаких шансов, что они будут работать.
В итоге, нет обходного пути, кроме как выполнить подготовку, быть уверенным в ней, а затем генерировать решения. Если решения не имеют смысла, вы возвращаетесь назад, отслеживаете проблему до ее корневой причины - часто это подготовка данных - и исправляете ее. Если в конечном итоге решения, которые выдает ваша система, имеют смысл для практика, который использует свой собственный человеческий разум для их оценки, то вы знаете, что вы все сделали правильно.
Киран Чандлер: Вы можете сказать, что вы считаете, что они должны быть правильно подготовлены, но обычно все сводится к оттенкам серого. Практик поставщиков цепочки поставок может сказать: “Это хорошее решение, но его можно улучшить. Например, если мы учитываем цену наших конкурентов, потому что это объясняет необычные скачки или падения спроса, и у нас еще нет этих данных”. Так что это не черно-белая ситуация.
Жоанн Верморель: Мы много говорили о трудностях с подготовкой данных и о том, как выглядит плохая подготовка данных. Но чтобы подвести итоги, как выглядит хорошая подготовка данных? В средне сложной ситуации цепочки поставок хорошая подготовка данных будет выглядеть как хорошо структурированная книга. Давайте представим это как книгу из 400 страниц с одной страницей на таблицу или двадцать полей в 20 таблицах. Но этого недостаточно, чтобы это была просто книга, она должна быть хорошо написанной.
Если вы напишете что-то ужасно скучное, никто не будет его читать, и это не будет иметь никакого влияния на вашу организацию. Так что она должна быть хорошо написанной. И под хорошо написанным я имею в виду, что она должна быть читаемой. Она также должна быть написана с бизнес-точки зрения. Это не документация по ИТ. Подготовка данных на самом деле не является проблемой ИТ, это скорее о наличии всех бизнес-инсайтов.
Действительная перспектива в бизнесе всегда что-то меняется. Если конкурентная среда в вашей отрасли меняется, то меняется и действительная перспектива по данной проблеме. Так что эта книга должна быть хорошо написанной и поддерживаться.
Это очень распределенное усилие в вашей компании, потому что, например, только команда мерчандайзинга имеет правильное понимание и перспективу, чтобы знать, как должны быть задокументированы таблицы мерчандайзинга в первую очередь. Эта подготовка данных выглядит как чистые, хорошо написанные материалы, которые широко распространены и доступны в вашей компании.
Интересно то, что после того, как у вас есть все эти инсайты, преобразование данных, которое является логикой, становится простым толкованием действительного понимания самих данных. Вам нужно приложить огромное количество усилий, чтобы понять данные, задокументировать их, написать и поддерживать их. Но после того, как вы все это сделали, написание логики становится простым. Так что как выглядит хорошая подготовка данных? Это похоже на хорошо написанную книгу, общее понимание, своего рода библию цепочки поставок, которая является внутренней для вашей компании.
Киран Чандлер: Звучит здорово! Итак, оттенки серого данных, это будет новый бестселлер, выходящий из организации?
Жоанн Верморель: Возможно, кто знает?
Киран Чандлер: Хорошо, мы надеемся, что вам понравился сегодняшний эпизод о подготовке данных. Как всегда, свяжитесь с нами, если у вас возникнут дополнительные вопросы, и до новых встреч на Lokad TV. До свидания на данный момент.
