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, интересны исторические данные, учитывая, что компания использует их для вероятностного прогнозирования. Он отмечает, что компании внимательно следят за деньгами, которые они ожидают получить или заплатить, и те, кто этого не делает, со временем исчезают. По его словам, это своего рода бизнес-дарвинизм. Он предполагает, что компании, которые обращают внимание на свои финансовые транзакции с течением времени, естественно заботятся о своих исторических данных.
Разговор переходит к подготовке данных. Верморель подчеркивает, что данные не являются по своей сути «чистыми» или полностью понятными. Он утверждает, что подготовка данных – это не только задача ИТ; речь идет о понимании всех аспектов бизнес-данных для охвата всех сторон бизнеса. ИТ-отдел, как он отмечает, не может быть ожидаемо освоить каждую бизнес-сторону и не должен нести единоличную ответственность за подготовку данных.
Верморель предлагает распределённый подход, в котором участвуют разные команды с разной экспертизой в организации. Данные, относящиеся к закупкам, например, должны включать закупочные команды. Аналогично, данные, необходимые для оценки поставщиков, должны включать команды по закупкам. Такой подход позволяет получить необходимые инсайты для эффективной подготовки данных.
Обсуждая, как быть уверенным в корректности интерпретации данных, особенно когда информация неполная, Верморель проводит параллель с научными теориями: невозможно знать, что теория верна, но её можно подтвердить, если она выдерживает проверку. Корректность подготовки данных устанавливается, когда принятые на основе интерпретации решения оказываются верными. Если неправильная подготовка данных приводит к нелогичным решениям, причину можно отследить, исправить и пересмотреть.
Далее Верморель описывает, каким должна быть качественная подготовка данных, особенно в сложных сценариях цепочек поставок. Он сравнивает её с хорошо написанной книгой, предоставляющей релевантные бизнес-инсайты и перспективы, а не просто технические детали. Она должна быть доступной и распространяться по всей организации, способствуя общему пониманию. Это требует постоянных усилий по документированию, поддержанию и пониманию данных.
Наконец, Верморель подчеркивает, что подготовка данных должна базироваться на достоверном понимании самих данных. Как только это понимание установлено и поддерживается, логические операции с данными становятся достаточно простыми. Хорошая подготовка данных представляет собой одновременно и хорошо написанное руководство, и общее понимание, которое позволяет принимать четкие и эффективные решения в цепочке поставок.
Полная транскрипция
Kieran Chandler: В сегодняшнем эпизоде мы обсудим подготовку данных, один из основополагающих элементов науки о данных. Учитывая недавние законы о соблюдении 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: Рассмотрим практический пример: допустим, у меня есть таблица с названием “orders”. Она содержит мои исторические заказы и включает дату. Но настолько ли это просто? Мы действительно говорим о том, какой именно датой является это значение? Это дата, когда клиент кликнул на продукт, чтобы положить его в корзину на сайте электронной коммерции? Или когда клиент подтвердил корзину и произвел оплату? Или когда оплата была подтверждена процессором кредитных карт? Или когда запись была внесена в систему? Или когда заказ на покупку был в последний раз изменен в системе? Существует около 20 различных толкований для одного только поля “date”.
Кроме того, если у вашей компании более десятилетней истории, вероятность такова, что тонкие нюансы интерпретации поля “order date” со временем изменились. Может случиться так, что при обновлении системы семантика этого столбца изменилась.
Кроме того, это не то, что естественным образом однородно на протяжении всей вашей истории. Затем могут возникнуть дополнительные сложности, такие как пограничные случаи. Например, эта дата должна означать тот момент, когда клиент подтвердил корзину, за исключением случаев, когда оплата в конечном итоге была отклонена как мошенническая. В этом случае это дата и время, когда заказ был отклонен как мошеннический.
Снова, это вовсе не идеальный дизайн, но компании, управляющие сложными цепочками поставок, имеют сложные системы и долгую историю. Таким образом, ИТ не обязательно было реализовано идеально с первого дня, и вам приходится справляться со всеми этими историческими осложнениями. Они в итоге отражаются в этой документации. Если вы не учтете все эти сложности, у вас возникнут проблемы при анализе данных.
Kieran Chandler: Чтобы принять оптимизированное решение для вашей цепочки поставок, вы можете столкнуться с проблемой “плохие данные – плохой результат”, если неправильно интерпретировать данные. Так что вы говорите, что все дело в прояснении семантики данных, верно?
Joannes Vermorel: Именно. Нужно понимать, что данные — это не просто числа. Они представляют собой различные факторы, которые могут быть объединены в одной ячейке. Речь идет не только о понимании программного обеспечения, которое генерирует данные, но и о том, как люди взаимодействуют с этим программным обеспечением. Ваша документация должна учитывать человеческий фактор в действиях людей.
Kieran Chandler: Есть ли у вас хороший пример из практики, как один из ваших клиентов столкнулся с этой проблемой в прошлом и как это повлияло на их компанию?
Joannes Vermorel: Да, могу привести пример. У нас был клиент, который управлял крайне требовательной операцией, требующей высокого уровня доступности. Они передавали заказы на закупку своим поставщикам с очень короткими сроками исполнения. В их системе была интересная особенность проектирования: если количество доставленных товаров не совпадало с изначально запрошенными величинами, то весь заказ на закупку должен был быть отклонен и возвращен поставщику.
Предположим, вы заказываете 1000 единиц, но поставщик доставляет 1050 единиц, тогда вам пришлось бы отклонить заказ. Проблема заключается в том, что если вы его отклоните, это может привести к серьезным оперативным проблемам. Система не позволяла им изменять количество, поэтому в итоге, когда количество доставленных товаров не соответствовало заказанным, они изменяли исходный заказ на закупку так, чтобы он отражал доставленное количество.
Kieran Chandler: То есть, вы говорите, что они изменяли исходный заказ на закупку так, чтобы он соответствовал доставленному объему?
Joannes Vermorel: Именно. Однако это открыло еще одну проблему. Поставщики подметили такую практику. Они поняли, что могут доставлять больше, чем было заказано, зная, что компании нужны эти поставки. Они не доставляли бы возмутительные объемы, а именно столько, сколько компания готова принять.
В данных это выглядело так, как будто первоначальный заказ был на большее количество. Это приводило к странным данным, где заказы на закупку казались слишком большими по сравнению с реальными потребностями, что создавало впечатление, что команда закупок плохо выбирает правильные объемы. Однако проблема заключалась не в команде закупок, а в ограничениях системы и в том, как люди справлялись с этими ограничениями.
Все эти детали нужно было задокументировать, чтобы не прийти к неверным выводам. Команда закупок не была некомпетентна. Проблема заключалась в том, что у них была система с ограничениями, с которыми им приходилось работать.
Kieran Chandler: Система генерирует все эти странные побочные эффекты. Для понимания этого требуется целая страница разъяснений, но избежать этого не получится. Все дело в сложности самого бизнеса, которая отражается в этих данных. Давайте уйдем от упоминания хитрых поставщиков. Это, безусловно, любопытный пример. Итак, вы упомянули аспект человеческого фактора. Очевидно, что в Lokad мы используем исторические данные для построения вероятностных прогнозов будущего. Кто еще, кроме нас, действительно заботится о исторических данных?
Joannes Vermorel: Обычно всё, что непосредственно влияло на сумму денег, которую вы ожидали получить или заплатить, привлекало большое внимание. Дело не в том, что люди не обращали внимания, но компании, которые не тщательно отслеживали ожидаемые доходы, со временем исчезали. Это как дарвинизм в действии. Если вы даже не обращаете на это внимание, вы просто исчезаете. Именно поэтому, как и пять столетий назад, двойная бухгалтерия была изобретена некоторыми итальянскими монахами. Если вы не обращаете внимания, ваш монастырь просто разваливается из-за плохой бухгалтерской практики. Это не совсем новая проблема, но существует множество данных, которые раньше не считались критическими, а теперь становятся критически важными.
Чтобы привести пример, для правильного учета дефицита товара в прошлом вы учитывали то, что закупали, чтобы знать, сколько должны платить поставщикам, и то, что продавали, чтобы знать, сколько клиенты должны платить вам. Но как быть с отслеживанием исторического дефицита товара? Пока у вас есть специалист по цепочке поставок, который вручную определяет объемы закупок и помнит, что были странные периоды дефицита, вам не нужны эти исторические записи. Они являются частью вашей системы.
Проблема в том, что как только вы захотите перейти к чему-то более количественному, как мы делаем в Lokad при автоматизации рутинных задач, таких как определение объема заказа, наличие точных записей о исторических уровнях запасов становится гораздо важнее. В противном случае ваша автоматизация неправильно интерпретирует, что является продажей, а что отсутствием спроса.
Если вы хотите, чтобы в вашей компании работала более высокая степень автоматизации, вам нужно обращать внимание на более широкий спектр данных, а не только на бухгалтерскую отчетность. Ваш бухгалтер не интересуется днями дефицита запасов, но ваше программное обеспечение для оптимизации цепочек поставок будет. Вам нужно расширить круг данных, которые действительно входят в сферу вашего внимания, которые задокументированы и для которых необходим контроль качества и уверенность в их корректности.
Kieran Chandler: Значит, мы сильно зависим от одного человека, который помнит, что происходило в прошлом. Не следует ли нам лучше подготовиться к поступающим данным? Не должен ли ИТ-отдел или кто-то еще заниматься подготовкой этих данных и обеспечивать их чистоту с самого начала? Это кажется более простым способом решения.
Joannes Vermorel: Да, но проблема не в компетентности ИТ. Чистых данных не существует. Суть в том, что данные не воспринимаются с достаточной глубиной, и не все бизнес-аспекты должным образом охвачены.
Kieran Chandler: Часто говорят, что компании инвестируют миллиарды в искусственный интеллект, но на самом деле именно сложность самого бизнеса проявляется в задаче подготовки данных. И утверждение: “ах, пусть этим займется ИТ-отдел”, эквивалентно ожиданию, что ИТ будет управлять компанией и знать каждый аспект бизнеса.
Joannes Vermorel: Абсолютно, это внезапно создает организационную проблему, потому что вы ожидаете, что ИТ будет экспертом не только в области информационных технологий, но и в управлении персоналом, маркетинге, закупках и так далее. То есть вы ожидаете полного освоения всех бизнес-аспектов от ИТ-отдела. Но это слишком много требовать. ИТ-отдел уже и так справляется со всеми изменениями в сфере технологий, так что от него не следует ожидать решения каждой бизнес-проблемы. Либо, можно переопределить ИТ как всю вашу компанию, но это сводит на нет всю идею.
Возвращаясь к рассматриваемому случаю, подготовка данных должна выполняться в разрезе всей компании, поскольку, в конечном итоге, единственные, кто может предоставить необходимую глубину понимания для подготовки данных, относящихся, скажем, к закупкам, — это команды закупок. Аналогично, если вы хотите создать систему оценки поставщиков и подготовить данные с нужной точностью чтобы это имело смысл, вам придется поговорить с командами, ответственными за снабжение.
Каждый раз, когда вы решаете проблему, вам необходимо привлекать специалистов по этой проблеме из вашей компании, потому что именно они дадут необходимое понимание для подготовки данных, чтобы все имело смысл. Это не сугубо ИТ-проблема. Речь идет о сборе всех необходимых знаний, чтобы при обработке данных вы не получили информацию, не имеющую смысла с точки зрения решаемой бизнес-проблемы.
Kieran Chandler: По всему видно, что мы еще не достигли этого уровня. Некоторые компании уже на этом уровне, но они исключение, а не правило. Как вы можете быть уверены, если у вас нет всей информации и имеются пробелы в интерпретации, что ваша трактовка верна? Возможностей может быть множество.
Joannes Vermorel: Абсолютно, и это интересный момент, потому что это похоже на научные теории. Вы никогда не можете быть уверены, что ваша теория правильна, вы просто знаете, что она достаточно хороша, и когда на практике её проверяют, она работает. У вас нет ничего лучшего, чтобы заставить её работать лучше.
Так что же это означает для подготовки данных? Это означает, что вы можете быть уверены в корректности подготовки данных, когда в конце конвейера данных автоматически генерируемые решения основаны на правильной интерпретации. Если решения правильны, это означает, что логика оптимизации эффективна, ваши слои машинного обучения точны и многое другое. Фундаментально, невозможно получить правильные решения, если интерпретация неверна. Обычно, если вы неправильно интерпретируете и подготавливаете данные, это так сильно искажает ваши результаты, что работа системы становится невозможной.
В итоге, не обойтись без подготовки данных — выполните её, будьте уверены в ней, а затем принимайте решения. Если решения окажутся бессмысленными, отступите, проследите проблему до её корневой причины — зачастую это подготовка данных — и исправьте её. Если, в конечном итоге, решения, полученные из вашей системы, кажутся логичными специалисту, использующему свой здравый смысл, значит, вы все сделали правильно.
Kieran Chandler: Вы можете сказать, что, по моему мнению, данные подготовлены правильно, но обычно все сводится к оттенкам серого. Специалист по цепочке поставок может сказать: “Решение хорошее, но его можно еще улучшить. Например, если бы мы учитывали цены наших конкурентов, потому что это объясняет необычные всплески или падения спроса, а этих данных у нас еще нет.” Так что ситуация не черно-белая.
Joannes Vermorel: Мы много говорили о трудностях подготовки данных и о том, как выглядит плохая подготовка данных. Но в итоге, как выглядит качественная подготовка данных? В ситуации со средней сложностью цепочки поставок качественная подготовка данных выглядит как хорошо структурированная книга. Представьте себе книгу в 400 страниц, где на каждую таблицу или двадцать полей в 20 таблицах приходится одна страница. Но недостаточно, чтобы это была просто книга, она должна быть хорошо написана.
Если вы напишете что-то невероятно скучное, никто этого не прочтет, и это не окажет никакого влияния на вашу организацию. Поэтому оно должно быть хорошо написано. И под “хорошо написано” я подразумеваю, что это должно быть читабельно. Также это должно быть написано с бизнес-точки зрения. Это не ИТ-документация. Подготовка данных — это действительно не ИТ-проблема, это скорее вопрос наличия всех бизнес-идей.
Действительная точка зрения в бизнесе всегда подвержена изменениям. Если конкурентная среда в вашей отрасли меняется, то и правильная точка зрения на проблему меняется. Поэтому эта книга должна быть хорошо написана и поддерживаться в актуальном состоянии.
Это очень распределенная задача в вашей компании, потому что, например, только команда мерчендайзинга обладает достаточным пониманием и перспективой, чтобы знать, как именно должны быть задокументированы таблицы мерчендайзинга. Подготовка данных должна представлять собой чистые, хорошо написанные материалы, которые широко распространены и доступны в вашей компании.
Интересно то, что как только вы получите все эти инсайты, преобразование данных, то есть логика, становится прямым толкованием правильного понимания самих данных. Требуется приложить огромное количество усилий, чтобы понять данные, задокументировать их, записать и поддерживать. Но как только всё это сделано, написание логики становится простым. Так что же представляет собой хорошая подготовка данных? Это как хорошо написанная книга, общее понимание, своего рода священная книга цепочки поставок, предназначенная для вашей компании.
Kieran Chandler: Звучит отлично! Значит, данные с оттенками серого станут новым бестселлером от организации?
Joannes Vermorel: Возможно, кто знает?
Kieran Chandler: Ладно, надеемся, что вам понравился сегодняшний эпизод о подготовке данных. Как всегда, свяжитесь с нами, если у вас возникнут дополнительные вопросы, и до встречи в следующий раз на Lokad TV. Пока!
