Проблемы с данными в цепи поставок

00:00:07 Обвинение плохих данных в проектах цепи поставок.
00:00:33 Почему плохие данные являются легким оправданием для неудачи проекта.
00:01:42 Проблемы с плохими данными и неправильные представления о их качестве.
00:03:16 Трудности доступа к данным из систем управления предприятием (ERP) и проблемы с поставщиками.
00:06:32 Проблемы, возникающие при миграции между системами управления предприятием (ERP) и повреждение данных.
00:08:01 Решение проблем с неправильными записями данных и их влияние на системы управления предприятием (ERP).
00:09:48 Прогнозирование и выявление проблем в исторических данных.
00:11:37 Как изменение семантики и определений может привести к проблемам с данными.
00:12:20 Проблемы масштабируемости и оптимизация извлечения данных по мере роста компаний.
00:14:45 Проблемы при создании чистых ежедневных выгрузок и возможность ошибок в данных.
00:16:02 Влияние увеличения времени обработки на решение проблем в отделах информационных технологий.
00:17:15 Проблема семантики данных и недоразумения в интерпретации данных.
00:19:22 Важность документации для каждого поля данных для обеспечения правильного понимания.
00:21:01 Роль практиков в сфере цепи поставок и отдела информационных технологий в понимании семантики данных.
00:23:59 Различные проблемы, связанные с плохими данными, и выявление их корневых причин.

Резюме

В этом интервью Киран Чандлер и Жоанн Верморель обсуждают роль данных в оптимизации цепи поставок и проблемы, с которыми сталкиваются поставщики программного обеспечения и практики в сфере цепи поставок. Верморель подчеркивает, что основная проблема заключается не в “плохих данных”, а в доступе к ним и их эффективном использовании. Среди проблем можно выделить устаревшие системы, недостаточную документацию и ответственность за доступ к данным. Также возникают проблемы с конфликтами интересов с интеграторами, проблемы при миграции систем, прогнозирование и масштабируемость. Для оптимизации управления цепью поставок компании должны понимать и решать проблемы с данными, инвестировать в правильную документацию, уточнять семантику данных и иметь реалистичные ожидания, а не винить данные в неудачах.

Расширенное резюме

В этом интервью Киран Чандлер и Жоанн Верморель, основатель Lokad, обсуждают роль данных в проектах оптимизации цепи поставок и проблемы, с которыми сталкиваются поставщики программного обеспечения и практики в сфере цепи поставок. Они начинают с того, что обращаются к представлению о том, что “плохие данные” часто используются в качестве козла отпущения для неудачи проектов в сфере цепи поставок. Верморель указывает на то, что обвинение данных является удобным способом избежать обвинений в адрес людей, которые могут воспринять это лично и возразить. Однако он также подчеркивает, что понимание корневой причины проблемы является важным фактором.

Верморель утверждает, что проблемы, связанные с данными, вероятно, являются главной причиной неудачи проектов по оптимизации цепочки поставок, но восприятие “плохих данных” часто ошибочно. Он утверждает, что большинство западных компаний имеют точные данные уже десятилетия благодаря использованию штрих-кодов, сканеров штрих-кодов и других технологий. Реальная проблема, по мнению Вермореля, заключается не в качестве самих данных, а в сложностях доступа и использования этих данных.

Одной из основных проблем эффективного использования данных является доступ к ним. Многие компании уже много лет используют различные системы планирования ресурсов предприятия (ERP), системы управления складом (WMS), системы управления транспортом (TMS) и другие программные решения, но эти системы могут быть сложными для работы с экспортом данных. Верморель выделяет несколько сценариев, в которых доступ к данным может быть особенно проблематичным:

1 Старые системы: Некоторые компании до сих пор используют системы, которым уже 40 лет, с устаревшими и собственными бэкэндами, что делает извлечение данных чрезвычайно сложным. 2 Отсутствие документации: Поставщики программного обеспечения могут не предоставлять достаточной документации для своих систем, что затрудняет понимание и навигацию по многочисленным таблицам и полям в базах данных. 3 Ответственность и доступ: Определение, кто несет ответственность за предоставление доступа к данным, может быть сложной задачей, так как в этом участвуют несколько заинтересованных сторон внутри компании, включая поставщика программного обеспечения, отдел информационных технологий и практиков цепочки поставок.

Интервью подчеркивает важность понимания и решения проблем, связанных с данными, в проектах по оптимизации цепочки поставок. В то время как качество самих данных обычно не является проблемой, трудности в доступе и использовании данных могут способствовать неудаче этих проектов. Выявление и устранение корневых причин этих проблем является важным условием для обеспечения успеха инициатив по оптимизации цепочки поставок.

Они также рассматривают проблемы с данными, которые могут возникать в результате взаимоотношений с поставщиками, интеграции систем и масштабируемости при росте компаний.

Одной из ключевых проблем, о которой они говорят, является потенциал конфликта интересов с интеграторами, которые могут быть более заинтересованы в продаже своих собственных решений по оптимизации цепочки поставок, чем в сотрудничестве с выбранным поставщиком компании. Это может привести к тому, что компании оказываются заложниками своих интеграторов, что затрудняет эффективный доступ или использование их данных.

Еще одна проблема возникает при миграции с одной системы планирования ресурсов предприятия (ERP) на другую, что может привести к низкому качеству данных или “грязной интеграции”. В то время как отдельные записи данных могут быть точными, процесс миграции исторических данных между системами может привести к ошибкам, так как часто нет прямого однозначного соответствия между данными в старых и новых системах. Это может привести к повреждению данных, что может не иметь существенного влияния на повседневную деятельность, но может возникнуть как проблема при попытке оптимизации цепочки поставок или проектов по обработке данных.

В интервью также затрагивается прогнозирование на основе исторических данных, что может быть сложным из-за неопределенности будущего. Обнаружение проблем в исторических данных проще, когда проблемы видны, такие как пропуски или внезапные изменения в данных. Однако незаметные изменения в семантике или определениях со временем могут привести к более сложным проблемам, особенно при миграции между системами.

По мере роста компаний масштабируемость также может вызывать проблемы с данными. Для малых компаний весь исторический набор данных часто помещается на смартфон, что делает оптимизацию менее проблематичной. Однако с увеличением размера компаний объем данных может стать проблемой. В дискуссии подчеркивается важность понимания и решения этих проблем с данными для эффективного управления цепочкой поставок.

Верморель объясняет, что компании часто сталкиваются с проблемами извлечения данных из своих систем планирования ресурсов предприятия (ERP), так как эти системы не предназначены для предоставления чистых ежедневных приращений данных. Это приводит к сложным процессам, которые могут привести к неправильному извлечению данных и ошибкам. Отладка и устранение этих проблем могут занять много времени, занимая недели вместо часов, из-за объема данных и медленного времени обработки. L3 При росте компаний масштабируемость также может привести к проблемам с данными. Для малых компаний весь исторический набор данных часто помещается на смартфоне, что делает оптимизацию менее проблематичной. Однако, по мере роста компаний, объем данных может стать проблемой. В дискуссии подчеркивается важность понимания и решения этих проблем с данными для эффективного управления цепями поставок.

Vermorel объясняет, что компании часто сталкиваются с проблемой извлечения данных из своих систем планирования ресурсов предприятия (ERP), поскольку эти системы не предназначены для предоставления чистых ежедневных приращений данных. Это приводит к сложным процессам, которые могут привести к неправильному извлечению данных и возникновению ошибок. Отладка и исправление этих проблем могут занимать много времени, недели вместо часов, из-за объема данных и медленного времени обработки.

Многие компании считают, что у них есть хорошие данные, но на самом деле семантика данных часто неясна. Это может привести к недоразумениям и вводящим в заблуждение расчетам. Например, “дата заказа” может иметь несколько интерпретаций, таких как время, когда заказ был размещен клиентом, время его регистрации в системе или время подтверждения оплаты. Чтобы избежать неправильных толкований, Верморель предлагает, чтобы компании имели подробную документацию для каждого поля и таблицы в их системах данных, отражающую сложность их цепи поставок.

Распространенной проблемой в оптимизации цепей поставок является то, что практики могут не уделять достаточно времени квалификации своих данных, что приводит к работе поставщиков с неполной или неясной информацией. Это может привести к ситуации “мусор на входе, мусор на выходе”, когда данные не обязательно неверны, но их неправильно понимают из-за плохой документации.

Чтобы решить эти проблемы, Верморель подчеркивает важность выявления корневой причины проблемы, которая обычно связана с людьми и организационными структурами. Компании должны понимать, кто несет ответственность за сбой и работать над устранением основных проблем, а не просто обвинять данные. Поставщики также должны быть честными относительно вызовов и времени, необходимого для уточнения семантики данных, вместо того, чтобы быть чрезмерно оптимистичными, чтобы закрыть сделки.

Компании должны инвестировать в правильную документацию, четкую семантику данных и реалистичные ожидания, чтобы оптимизировать свою цепь поставок и предотвратить сбои, связанные с проблемами данных.

Полный текст

Кирен Чандлер: Сегодня на Lokad TV мы собираемся понять, почему это такое неточное диагностическое средство, а также понять, с какими проблемами данных могут столкнуться как поставщики программного обеспечения, так и практики в области цепей поставок. Итак, Йоанн, почему плохие данные так легко становятся оправданием?

Йоанн Верморель: Во-первых, потому что данные не могут жаловаться. Никто не будет их защищать, поэтому вы обвиняете что-то инертное, что лучше, чем обвинять коллегу, который будет воспринимать это лично и отвечать. Но на самом деле, когда вы идете к корневой причине, всегда люди несут ответственность за проблему. Обвинение данных - это как пропуск этапа выявления корневой причины проблемы.

Кирен Чандлер: Определенно легко обвинять то, что не будет противиться. Так как мы можем быть более точными? Каковы некоторые проблемы?

Йоанн Верморель: Проблемы, связанные с данными, вероятно, являются главной причиной сбоев в проектах оптимизации цепей поставок. Но есть некоторые заблуждения. Когда люди говорят “плохие данные”, они имеют в виду поврежденные или неправильные числа. Однако для большинства западных компаний у них есть очень точные данные уже десятилетия. Почти никто не вводит неправильные номера деталей или делает опечатки. Они используют штрих-коды, сканеры штрих-кодов и другие трюки, такие как RFID. Таким образом, количество действительно плохих данных обычно является очень незначительной долей и недостаточно для объяснения того, почему большинство инициатив, которые терпят неудачу из-за проблем, связанных с данными, на самом деле терпят неудачу.

Кирен Чандлер: Если подавляющее большинство западных компаний собирают довольно хорошие данные, с какими проблемами мы можем столкнуться, которые заставляют нас думать, что данные не так хороши?

Йоанн Верморель: Первая проблема - получение доступа к данным. Вы были удивлены. Компании работают с различными вариантами систем планирования ресурсов предприятия (ERP), WMS, TMS или другого корпоративного программного обеспечения для ежедневного функционирования своих компаний уже десятилетия. Но большинство из этих систем не очень удобны для экспорта данных. В некоторых случаях у вас есть системы, которые настолько старые, что у них даже нет нормальной реляционной SQL-базы данных в основе системы. В такой ситуации действительно сложно извлечь данные, потому что бэкэнд обычно полностью устарел и проприетарен.

Кирен Чандлер: Итак, кто отвечает за это?

Жоанн Верморель: Здесь есть несколько ответственностей. Во-первых, у вас может быть поставщик программного обеспечения, который не предоставил никакой значимой документации о системе. В худшем случае вы открываете свою базу данных и понимаете, что ваша система планирования ресурсов предприятия (ERP) содержит 2000 таблиц, каждая из которых имеет от 20 до 200 полей, и это кошмар. Это совершенно огромно, и вы не знаете, с чего начать. Даже если вы знаете, где искать, у вас может возникнуть проблема с поставщиком, а затем с интегратором. Проблема с интегратором заключается в том, что у вас может возникнуть конфликт интересов. Некоторые интеграторы могут иметь яркий интерес продать вам свой собственный рецепт оптимизации цепочки поставок для этого модуля или другого модуля. И когда вы просите их сделать для вас извлечение данных, чтобы вы могли работать с другим поставщиком или с другой инициативой, интегратор может быть неприветливым. Потому что для них это просто не в их стратегическом интересе быть конкурентоспособными. И здесь у вас возникает ситуация, когда компания фактически становится заложником интегратора. Компания, ответственная за настройку, иногда хостинг и общее обслуживание ERP или другой компьютерной системы компании. Так что это еще одна проблема с данными. Но вы видите, это имеет очень мало отношения к данным.

Кирен Чандлер: Да, конечно. Не иметь доступа к своим данным звучит как довольно серьезное препятствие. А как насчет других вызовов, которые могут возникнуть? Одна из больших проблем, с которыми сталкиваются многие наши клиенты, - это миграция с одной системы ERP на другую. Как это может повлиять на данные?

Жоанн Верморель: Это может вызвать проблемы. Вот ситуация, когда у вас может возникнуть другой тип плохих данных. Но здесь проблема заключается в некачественной интеграции данных. Я скажу, что обычно данные вводятся правильно, но когда вы переходите с одной системы ERP на другую, поставщик или интегратор или ваш отдел внутренней информационной технологии пытаются перенести исторические данные из старой системы в новую систему. Проблема в том, что у вас нет однозначного соответствия между тем, что было продажей в старой системе и тем, что является продажей в новой системе. Возможно, вещи просто организованы по-другому, и поэтому нет ясного способа отчетности о дебиторской задолженности от старой системы к новой системе. И в результате у вас могут возникнуть временные интеграции, которые могут привести к повреждению данных, если вы неправильно перенесете свою историю. Это не помешает вашей компании работать в повседневной жизни. Если, например, данные о продажах в старой системе неправильно импортированы в новую систему, то для большинства ежедневных операций это не будет иметь никакого влияния. И даже если это повлияет, обычно кто-то быстро исправит неправильные данные и продолжит работу. Это может быть источником постоянного трения, но в первую очередь оно быстро исчезает, потому что если люди сталкиваются, например, с неправильно импортированными кодами поставщиков, то вероятность того, что у вас есть миллион поставщиков, невелика. Так что ваши 100 наиболее частых поставщиков, вероятно, будут исправлены в течение двух недель с момента начала использования новой системы. И, возможно, через три месяца вы исправите каждую неправильную запись о поставщике. Но проблема заключается в том, что исторические данные не будут исправлены. Допустим, у вас было пять лет истории, может быть три

Кирен Чандлер: В будущем насколько легко обнаружить эти проблемы, которые могли возникнуть в прошлом?

Жоанн Верморель: Легко обнаружить эти проблемы, когда есть видимые проблемы, такие как отсутствие данных в течение нескольких месяцев. Однако могут быть и более тонкие изменения, которые сложнее заметить, например, различия в подсчете продаж, включение или исключение мошенничества или возвратов. Это может привести к множеству проблем, которые трудно обнаружить в исторических данных, потому что само определение данных, с которыми вы работаете, меняется со временем, и это неочевидно, если нет заметного скачка или изменения.

Кирен Чандлер: Еще одна проблема, с которой сталкиваются наши клиенты, - это масштабируемость. По мере роста компании их данные становятся все более запутанными. Какие проблемы может вызвать масштабируемость?

Жоанн Верморель: Когда у вас нет проблем с масштабируемостью, вы можете просто копировать все данные компании каждый день. Для маленьких компаний это может быть управляемо, так как их вся история может занимать менее 10 гигабайт. Однако, по мере роста до крупных компаний, у вас появляется гораздо больше данных, и вам нужно перейти к инкрементному извлечению данных. Это означает извлечение части данных каждый день, и некоторые системы не предназначены для эффективной или точной обработки этого. Поэтому вам приходится делать сложные вещи, чтобы создать чистое ежедневное извлечение, и в процессе вы подвергаете себя потенциальным проблемам.

Кирен Чандлер: Итак, в итоге вы получаете плохие данные только потому, что хотите делать инкрементное извлечение данных, и это сложно, потому что система, возможно, не была разработана для этой задачи. Когда вы думаете о поиске ошибок, вы просто хотите скопировать данные из одного места в другое, и это может быть очень скучная проблема. Если процесс занимает минуту, кто-то из вашего IT-отдела может потратить пять минут, запустить процесс и быть уверенным, что он работает. Однако, если процесс занимает шесть часов, он становится более утомительным. Можете ли вы объяснить сложности в этой ситуации?

Жоанн Верморель: Конечно. Представьте, что у вас есть система, в которой процесс занимает шесть часов. В вашем IT-отделе кто-то запускает процесс, ждет 10 минут, понимает, что это занимает слишком много времени, и занимается чем-то другим. Они могут даже забыть о нем. На следующий день они могут заметить небольшую ошибку, которая вызвала сбой через шесть часов. Чтобы воспроизвести проблему, потребуется еще шесть часов задержки. В результате вы сталкиваетесь с проблемами, которые можно было бы исправить всего за несколько часов, но из-за большей сложности и длительного времени обработки это превращается в очень утомительный процесс, где общие задержки становятся неделями. Не потому, что это недели усилий, а потому что люди запускают процесс, забывают о нем и возвращаются на следующий день. Это делает итерации очень медленными.

Кирен Чандлер: Насколько широко распространены эти проблемы? Есть ли много компаний, которые действительно считают, что у них очень хорошие данные, но на самом деле, когда вы посмотрите на них под поверхностью, они не такие уж и хорошие?

Жоанн Верморель: Да, есть еще одна проблема, о которой мы не говорили, - это сама семантика. Многие компании считают, что у них хорошие данные, но на самом деле данные имеют неизвестную семантику. Что я имею в виду, например, когда мы говорим о дате заказа, есть много потенциальных интерпретаций. Это может быть дата заказа клиента, время размещения заказа на веб-сайте, зарегистрированное в системе или даже время подтверждения оплаты как действительной. Может быть 20 различных интерпретаций того, что означает эта дата заказа.

Когда мы начинаем работать с клиентами, мы обычно сталкиваемся с таблицами и столбцами с небольшой документацией. Но когда мы заканчиваем подготовку данных, у нас есть почти одна страница документации на каждое поле каждой таблицы. Типичная ситуация в снабжении имеет около 20 таблиц с 20 полями, так что мы говорим о 400 страницах документации, чтобы прояснить, что означают данные. Люди обычно очень удивляются этому, но это необходимо для правильного понимания данных.

Кирен Чандлер: Жоанн, можете ли вы рассказать о важности правильного понимания данных в оптимизации цепочки поставок?

Жоанн Верморель: Да, это просто сложность вашей цепочки поставок, которая отражается в этих данных, и если вы не выполняете эту работу, вы получаете данные, которые вы не понимаете должным образом. Таким образом, это мусор на входе, мусор на выходе. Не то чтобы данные были мусором в том смысле, что числа неправильные, но вы не знаете, что они означают. Так что, если у вас есть данные, которые вы не понимаете должным образом, какие бы вычисления или модернизацию вы ни сделали, это приведет к чему-то вводящему в заблуждение. Таким образом, семантика данных - это ключевой вывод, и документация должна быть на месте, прежде чем вы сможете начать проект.

Кирен Чандлер: Итак, кто виноват, когда дело доходит до семантики?

Жоанн Верморель: Я бы сказал, что ответственность должна лежать на практиках цепочки поставок. Большинство из них скажут, что это проблема информационных технологий. Но то, как вы видите семантику данных, действительно зависит от процесса, который у вас есть. Если у вас есть процесс, при котором вы сканируете товары при входе на склад, потому что у вас есть такой процесс, информационные технологии не знают, как именно настроен ваш процесс. Единственные люди, которые знают точно, потому что эти данные - это просто результат процесса, который генерирует, они находятся в первом месте в системе. Так что мой посыл заключается в том, что не стоит ожидать от информационных технологий, которые просто управляют машинами, обеспечивая достаточное вычислительное пространство, пропускную способность памяти и диска, иметь понимание того, что означают данные. Значение данных обычно является очень специфичной для бизнеса проблемой. Это вообще не проблема информационных технологий. Так что, как правило, вина также часто лежит на стороне практиков. Практики не уделили достаточно времени, чтобы правильно квалифицировать это своими словами и своим пониманием. Таким образом, когда речь идет об оптимизации цепочки поставок, вы получаете поставщика, который начинает обрабатывать эти данные наполовину слепым. Это приводит к мусору на входе, мусору на выходе.

Кирен Чандлер: Итак, поставщик также может быть виноват?

Жоанн Верморель: Да, очевидно, поставщик также может быть виноват. Компании, такие как Coke Ad, занимающиеся оптимизацией цепочки поставок, и обычно, когда виноват поставщик, это потому, что поставщик пытается быть хитрым. Обычно они пытаются минимизировать свои проблемы, потому что они пытаются продать проблему. Они говорят такие вещи, как: “Доверьтесь нам. Это будет проще простого. Мы сделаем это за несколько недель. Бум, мы сделаем это так, и это сработает”. Реальность заключается в том, что если вы скажете директору цепочки поставок: “Боюсь, что только для квалификации ваших данных потребуется полгода, и извините, вы должны были это сделать, но вы этого не сделали, поэтому мы должны сделать это за вас”, очевидно, трудно закрыть такую сделку. Так что намного проще быть чересчур оптимистичным, но это рецепт для неудачи. Тогда поставщик должен нести ответственность, потому что он должен знать лучше. Возможно, клиент не знает лучше, потому что это первый раз, когда он пытается выполнить проект по предсказательной количественной оптимизации цепочки поставок. Но поставщик, который, по определению, вероятно, не в первый раз делает это, должен знать лучше. Таким образом, если ситуация диагностики, когда такие данные отсутствуют, то они должны

Кирен Чандлер: Тогда они должны, по сути, предупредить клиента, что им может потребоваться несколько месяцев усилий, чтобы прояснить семантику данных, чтобы данные могли быть признаны хорошими. Но это не значит, что они были действительно плохими с самого начала. Так что хорошее не является противоположностью плохого в этой ситуации; это просто то, что хорошее больше похоже на противоположность темных данных или неквалифицированных данных или беспорядочных данных.

Жоанн Верморель: Хорошо, и чтобы завершить сегодня, существует широкий спектр различных проблем, которые фактически попадают под это понятие плохих данных. Я бы сказал, попытайтесь определить корень проблемы, и обычно это люди. Я имею в виду, очевидно, когда я говорю, что проблема в людях, вы не хотите винить Джеймса из отдела информационных технологий в ответе за беспорядок. Но когда я говорю, что проблема в людях, вам нужно точно понять, кто несет ответственность за неудачу, и, возможно, этот человек оказался в ситуации, когда он не мог ничего сделать, кроме как потерпеть неудачу.

Вы видите, что можно прийти к выводу, что Джеймс из IT-отдела потерпел неудачу, но также организация сама поставила этого бедного Джеймса в положение, где у него не было другого выбора, кроме как провалиться, говоря реалистично. Таким образом, интересно, что вы начинаете видеть проблему с такого ракурса, который хотя бы дает вам подсказки о том, как вы ее исправите, вместо того, чтобы говорить, что данные были плохими, очень плохими, плохими данными. И затем, если бы вы предприняли еще одну инициативу, вы бы просто повторили ту же самую проблему, те же самые ошибки и в конечном итоге столкнулись с тем же провалом в конце дня.

Киран Чандлер: Ладно, если начальник Джеймса смотрит, надеюсь, он проявляет сочувствие. В любом случае, это все на этой неделе. Большое спасибо за внимание, и увидимся в следующий раз. Пока!