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 Влияние увеличения времени обработки на решение проблем в IT-отделах.
00:17:15 Проблемы семантики данных и недопонимания в интерпретации данных.
00:19:22 Важность документации для каждого поля данных для обеспечения правильного понимания.
00:21:01 Роли специалистов по цепочке поставок и IT-отделов в понимании семантики данных.
00:23:59 Разнообразие проблем, подпадающих под категорию плохих данных, и выявление первопричин.
Резюме
В этом интервью Киран Чендлер и Жуанес Верморель обсуждают роль данных в оптимизации цепочек поставок и проблемы, с которыми сталкиваются поставщики программного обеспечения и специалисты. Верморель подчеркивает, что основная проблема заключается не в «плохих данных», а в трудностях доступа к данным и их эффективном использовании. Проблемы включают устаревшие системы, недостаточную документацию и неопределенность в распределении ответственности за доступ к данным. Конфликты интересов с интеграторами, проблемы миграции систем, прогнозирование и масштабируемость также создают затруднения. Для того чтобы оптимизировать управление цепочками поставок, компании должны понимать и решать проблемы с данными, инвестировать в качественную документацию, уточнять семантику данных и сохранять реалистичные ожидания, а не обвинять данные в неудачах.
Расширенное резюме
В этом интервью Киран Чендлер и Жуанес Верморель, основатель Lokad, обсуждают роль данных в проектах по оптимизации цепочек поставок и проблемы, с которыми сталкиваются поставщики программного обеспечения и специалисты по цепочкам поставок. Они начинают с рассмотрения идеи, что «плохие данные» часто используются как козел отпущения за неудачу проектов в цепочках поставок. Верморель отмечает, что обвинять данные — это удобный способ уйти от ответственности, чтобы не обрушить критику на людей, которые могут воспринять это лично. Однако он также подчеркивает, что выявление первопричины проблемы имеет решающее значение.
Верморель утверждает, что проблемы, связанные с данными, вероятно, являются основной причиной неудач проектов по оптимизации цепочек поставок, хотя восприятие «плохих данных» зачастую ошибочно. Он утверждает, что у большинства западных компаний на протяжении десятилетий данные были очень точными благодаря использованию штрих-кодов, сканеров штрих-кодов и других технологий. По мнению Вермореля, проблема заключается не в качестве данных, а в сложностях их доступа и использования.
Одна из ключевых проблем эффективного использования данных заключается в получении к ним доступа. Многие компании на протяжении десятилетий используют различные системы планирования ресурсов предприятия, системы управления складом (WMS), системы управления транспортировкой (TMS) и другие программные решения для ведения бизнеса, однако зачастую эти системы неудобны для экспорта данных. Верморель выделяет несколько ситуаций, когда доступ к данным может быть особенно проблематичным:
1 Древние системы: Некоторые компании по-прежнему используют системы возрастом 40 лет, с устаревшими и проприетарными бэкендами, которые делают извлечение данных чрезвычайно сложным. 2 Отсутствие документации: Поставщики программного обеспечения могут не предоставлять достаточную документацию по своим системам, что затрудняет понимание и навигацию по многочисленным таблицам и полям в базах данных. 3 Ответственность и доступ: Определение того, кто отвечает за предоставление доступа к данным, может быть проблематичным, поскольку это затрагивает несколько заинтересованных сторон внутри компании, включая поставщика программного обеспечения, IT-отдел, и специалистов по цепочкам поставок.
Интервью подчеркивает важность понимания и решения проблем, связанных с данными, в проектах по оптимизации цепочек поставок. Хотя качество самих данных обычно не является проблемой, трудности с их доступом и использованием могут приводить к провалу этих проектов. Выявление и устранение первопричин этих проблем является ключевым для обеспечения успеха инициатив по оптимизации цепочек поставок.
Они углубляются в проблемы с данными, которые могут возникать из отношений с поставщиками, интеграции систем и масштабируемости по мере роста компаний.
Одной из ключевых проблем, которые они обсуждают, является потенциал конфликта интересов с интеграторами, которые могут быть больше заинтересованы в продаже собственных решений по оптимизации цепочек поставок, чем в сотрудничестве с выбранным поставщиком компании. Это может привести к тому, что компании оказываются заложниками у интеграторов, что усложняет эффективный доступ и использование их данных.
Еще одна проблема возникает при миграции с одной системы планирования ресурсов предприятия (ERP) на другую, что может привести к снижению качества данных или «интеграции мусора». Хотя отдельные записи данных могут быть точными, процесс переноса исторических данных между системами может сопровождаться ошибками, так как часто отсутствует прямое однозначное соответствие между данными в старой и новой системах. Это может привести к порче данных, что, возможно, не окажет значительного влияния на повседневную деятельность, но может вновь проявиться как проблема при попытках оптимизации цепочек поставок или анализе данных.
Интервью также затрагивает тему прогнозирования на основе исторических данных, что может быть сложно из-за присущей неопределенности будущего. Выявление проблем в исторических данных проще, когда ошибки заметны, например, в виде пробелов или резких изменений в данных. Однако тонкие изменения в семантике или определениях со временем могут привести к труднообнаруживаемым проблемам, особенно при миграции между системами.
По мере роста компаний масштабируемость также может создавать проблемы с данными. Для небольших компаний весь исторический набор данных часто может уместиться на смартфоне, что снижает актуальность оптимизации. Однако по мере роста компаний огромный объем данных может стать проблемой. Обсуждение подчеркивает важность понимания и устранения этих проблем с данными для эффективной оптимизации управления цепочками поставок.
Верморель объясняет, что компании часто сталкиваются с трудностями при извлечении данных из своих ERP-систем, поскольку те не предназначены для предоставления чистых ежедневных выгрузок данных. Это приводит к сложным процессам, которые могут вызывать неправильное извлечение данных и появление ошибок. Отладка и исправление этих проблем могут занять недели вместо часов из-за объема задействованных данных и медленной скорости обработки.
Многие компании считают, что их данные качественные, но на самом деле семантика данных часто остается неясной. Это может привести к недопониманиям и ошибочным расчетам. Например, «дата заказа» может иметь несколько интерпретаций: время, когда заказ был сделан клиентом, время его регистрации в системе или время подтверждения оплаты. Чтобы избежать недоразумений, Верморель предлагает, чтобы компании имели подробную документацию для каждого поля и таблицы в своих системах данных, отражающую сложность их цепочек поставок.
Распространенная проблема в оптимизации цепочек поставок заключается в том, что специалисты могут не уделять достаточно времени проверке данных, что приводит к тому, что поставщики работают с неполной или неясной информацией. Это может создать ситуацию «мусор на входе — мусор на выходе», когда данные не обязательно являются ошибочными, а просто неправильно интерпретируются из-за плохой документации.
Чтобы решить эти проблемы, Верморель подчеркивает важность выявления первопричины проблемы, которая обычно связана с людьми и организационными структурами. Компаниям следует понимать, кто несет ответственность за неудачу, и устранять базовые проблемы, а не просто перекладывать вину на данные. Поставщики также должны честно говорить о сложностях и времени, необходимом для прояснения семантики данных, а не демонстрировать излишний оптимизм для заключения сделок.
Компании должны инвестировать в качественную документацию, четкую семантику данных и реалистичные ожидания, чтобы оптимизировать свою цепочку поставок и предотвращать неудачи, вызванные проблемами с данными.
Полная расшифровка
Киран Чендлер: Сегодня на Lokad TV мы разберемся, почему этот диагноз столь неточен, а также поймем, с какими проблемами, связанными с данными, сталкиваются как поставщики программного обеспечения, так и специалисты по цепочкам поставок. Итак, Жуанес, почему плохие данные так легко использовать в качестве оправдания?
Жуанес Верморель: Во-первых, потому что данные не могут пожаловаться. Никто не станет их защищать, так что вы обвиняете нечто безжизненное, что лучше, чем обвинять коллегу, который воспримет это лично и даст отпор. Но истина в том, что, углубившись в проблему, вина всегда лежит на людях. Обвинять данные — это как пропустить этап выявления первопричины проблемы.
Киран Чендлер: Действительно, гораздо проще критиковать то, что не может дать отпор. Так как же мы можем быть точнее? С какими проблемами мы сталкиваемся?
Жуанес Верморель: Проблемы, связанные с данными, вероятно, являются главной причиной неудач проектов по оптимизации цепочек поставок. Но существует некоторое заблуждение. Когда говорят о «плохих данных», имеют в виду испорченные или неверные числа. Однако у большинства западных компаний данные на протяжении десятилетий были очень точными. Почти никто не вводит неверные номера деталей или не делает опечаток. Они используют штрих-коды, сканеры штрих-кодов и другие технологии, такие как RFID. Поэтому количество действительно плохих данных обычно невелико и недостаточно, чтобы объяснить, почему большинство инициатив, проваливающихся из-за проблем с данными, терпят неудачу.
Киран Чендлер: Если подавляющему большинству западных компаний удается собирать достаточно качественные данные, с какими проблемами мы можем столкнуться, которые заставляют нас думать, что данные не так хороши?
Жуанес Верморель: Первая проблема — это доступ к данным. Вы будете удивлены. Компании на протяжении десятилетий используют различные ERP-системы, WMS, TMS или другое корпоративное программное обеспечение для управления бизнесом, но большинство из этих систем не очень удобны для экспорта данных. В некоторых случаях используются такие древние системы, что даже полноценной реляционной SQL-базы данных нет. В такой ситуации извлечение данных становится действительно сложным, поскольку бэкенд обычно полностью устарел и является проприетарным.
Киран Чендлер: Так кто же отвечает за это?
Жуанес Верморель: Здесь ответственность лежит на нескольких сторонах. Во-первых, это может быть поставщик программного обеспечения, который не предоставил достаточной документации по системе. В худшем случае вы открываете базу данных и понимаете, что ваша ERP-система содержит 2000 таблиц, каждая с 20–200 полями, что является настоящим кошмаром. Это настолько объемно, что вы не знаете, с чего начать. Если же проблема поиска информации связана с поставщиком, то может возникнуть проблема и с интегратором. Проблема с интегратором заключается в том, что может возникнуть конфликт интересов. Некоторые интеграторы могут быть больше заинтересованы в продаже своих собственных решений по оптимизации цепочек поставок, для этого или другого модуля, и когда вы просите их выполнить извлечение данных для вас, вашего внутреннего коллектива или для какой-либо инициативы с другим поставщиком, интегратор может оказаться — как не раз уже случалось — просто не сотрудничающим. Ведь для них стратегически выгодно оставаться неконкурентоспособными. И вот вы оказываетесь в положении заложника у интегратора. Компания, IT-компания, ответственная за настройку, иногда за хостинг и, в целом, за обслуживание ERP-системы или другой компьютерной системы компании. Это еще один тип проблемы с данными. Но, как видите, это имеет очень мало общего с самими данными.
Киран Чендлер: Да, безусловно. Невозможность доступа к вашим данным звучит как серьезное препятствие. А как насчет других проблем, которые могут возникнуть? И еще одна большая головная боль, с которой сталкивается множество наших клиентов, — это миграция с одной ERP-системы на другую. Так что же это может сделать с данными?
Joannes Vermorel: Это нельзя просто закрыть, иначе возникнут проблемы. Вот ситуация, когда у вас может появиться другой тип плохих данных. Но на самом деле проблема возникает, когда интеграция осуществляется некачественно. Обычно я говорю, что записи данных правильные, но когда вы переходите с одной ERP-системы на другую, будь то поставщик, интегратор или ваш внутренний IT-отдел, они пытаются перенести исторические данные из старой системы в новую. Проблема в том, что нет прямого соответствия между, скажем, продажами, зафиксированными в старой системе, и продажами в новой. Возможно, данные организованы иначе, и поэтому нет ясного способа перенести AR из старой системы в новую. В итоге получаются предварительные интеграции, которые могут привести к порче данных, поскольку, если вы, скажем, неправильно реинтегрируете вашу историю, это не остановит ежедневную работу компании. Видите, если данные East Oracle были импортированы некорректно в новую систему, для большинства ежедневных операций это не окажет влияния. И даже если окажется влияние, обычно кто-то быстро исправит ошибку и продолжит работу. Таким образом, это может стать источником постоянного трения, но при этом быстро исчезает, ведь если люди спотыкаются, например, когда коды поставщиков импортированы неверно. Вероятно, у вас нет миллиона поставщиков, так что ваши 100 самых частых поставщиков, скорее всего, будут исправлены в плане устранения некорректных записей в течение двух недель с момента начала использования новой системы. А может быть, и через три месяца практически все ошибочные записи поставщиков будут исправлены. Но проблема в том, что исторические данные остаются, люди не будут возвращаться и исправлять их. Допустим, у вас накопилось пять лет истории, может быть, три
Kieran Chandler: В будущем, насколько легко можно обнаружить проблемы, которые могли возникнуть в прошлом?
Joannes Vermorel: Эти проблемы легко заметить, когда имеются явные недочеты, например, отсутствие данных за несколько месяцев. Однако могут быть и тонкие изменения, которые сложнее отследить, как различия в подсчете продаж, включаются ли мошеннические операции или возвраты. Это может привести к множеству проблем, которые сложно заметить в исторических данных, поскольку само определение наблюдаемых данных менялось со временем, и это не очевидно, если не происходит резкого скачка или подъема.
Kieran Chandler: Еще одна распространенная проблема, с которой сталкиваются наши клиенты, — это масштабируемость. По мере роста компании их данные становятся более запутанными. Какие проблемы может вызвать масштабируемость?
Joannes Vermorel: Когда проблем с масштабируемостью нет, можно просто копировать все данные компании каждый день. Для небольших компаний это может быть приемлемо, ведь их вся история может занимать менее 10 гигабайт. Однако по мере роста компании объем данных значительно увеличивается, и приходится прибегать к инкрементальному извлечению данных. Это означает, что извлекается лишь часть данных каждый день, а некоторые системы не предназначены для такой эффективной или точной обработки. Поэтому приходится применять сложные методы для создания чистого ежедневного извлечения, что в свою очередь влечет за собой потенциальные проблемы.
Kieran Chandler: В итоге вы получаете плохие данные просто потому, что хотите извлекать данные по частям, и это сложно, поскольку система, возможно, не была разработана для такой задачи. Если говорить об отладке, то обычно хочется просто скопировать данные из одного места в другое, и это может быть весьма обыденной проблемой. Если процесс занимает минуту, кто-то из IT-отдела может за пять минут запустить процесс и быть уверенным, что он работает. Однако если процесс занимает шесть часов, это превращается в гораздо более утомительную задачу. Можете объяснить, с какими трудностями сталкиваются в такой ситуации?
Joannes Vermorel: Конечно. Представьте систему, в которой процесс занимает шесть часов. В вашем IT-отделе кто-то запускает процесс, ждет 10 минут, понимает, что он идет слишком долго, и переключается на что-то другое. Возможно, он даже забывает о нем. На следующий день он может обнаружить небольшую ошибку, которая привела к сбою спустя шесть часов. Чтобы воспроизвести проблему, требуется еще шесть часов ожидания. В результате возникают проблемы, которые должны решаться за несколько часов, но из-за возросшей сложности и длительного времени обработки превращаются в утомительный процесс, когда общая задержка становится неделями. Не потому, что на это уходят недели усилий, а потому, что люди запускают процесс, забывают о нем и возвращаются к нему на следующий день. Это приводит к очень медленным итерациям.
Kieran Chandler: Насколько широко распространены эти проблемы? Существует ли множество компаний, которые считают, что их данные хороши, а на деле, при более глубоком анализе, они оказываются не такими уж и хорошими?
Joannes Vermorel: Да, есть еще одна проблема, которую мы не обсуждали, — это семантика данных. Многие компании считают, что их данные хорошие, но на деле данные имеют неизвестную семантику. То есть, например, когда мы говорим о дате заказа, существует множество возможных интерпретаций. Это может быть дата заказа клиента, время размещения заказа на сайте, время регистрации в системе или даже момент, когда платеж был подтвержден как действительный. Может быть 20 различных толкований того, что означает дата заказа.
Когда мы начинаем работать с клиентами, обычно встречаем таблицы и колонки с минимальной документацией. Но когда мы заканчиваем подготовку данных, у нас появляется почти страница документации на каждое поле каждой таблицы. В типичной цепочке поставок около 20 таблиц с 20 полями, так что получается примерно 400 страниц документации, чтобы разъяснить, что означают данные. Люди обычно сильно удивляются этому, но это необходимо для правильного понимания данных.
Kieran Chandler: Joannes, можете рассказать о важности правильного понимания данных при оптимизации цепочки поставок?
Joannes Vermorel: Да, сложность вашей цепочки поставок отражается в этих данных, и если вы не проведете эту работу, то получите данные, которые не сможете правильно интерпретировать. Принцип здесь таков: мусор на входе — мусор на выходе. Дело не в том, что данные ошибочны в смысле неверных чисел, а в том, что вы не понимаете, что они означают. Если у вас есть дата, которую вы не понимаете должным образом, любая вычислительная операция или модернизация приведет к неверным результатам. Таким образом, семантика данных — это ключевой момент, и документация должна быть готова до начала проекта.
Kieran Chandler: Так, кто же виноват, когда речь идет о семантике?
Joannes Vermorel: Я бы сказал, что за это должны отвечать специалисты по цепочке поставок. Большинство из них скажут, что это проблема IT. Но восприятие семантики данных во многом зависит от вашего процесса. Если у вас есть процесс сканирования товаров на входе в склад, который обрабатывается IT-отделом, но они не находятся на месте и не знают, как устроен ваш процесс, то только те, кто непосредственно задействован в генерировании данных, понимают его суть. Моя мысль такова: не ожидайте, что IT-отдел, занимающийся лишь управлением машинами, обеспечением вычислительной мощности, памяти и дисковой системы, будет иметь понимание того, что означают данные. Значение данных — это, как правило, специфичная для бизнеса проблема. Это не IT-проблема. Поэтому вина часто лежит и на специалистах, которые не уделили достаточно времени тому, чтобы правильно сформулировать понятия своими словами и на основе своего понимания. Таким образом, при оптимизации цепочки поставок вы получаете ситуацию, когда поставщик работает с данными практически вслепую. Это приводит к принципу: мусор на входе — мусор на выходе.
Kieran Chandler: Может ли в этом случае виноват быть и поставщик?
Joannes Vermorel: Да, очевидно, что поставщик тоже может быть виноват. Компании типа Coke Ad, занимающиеся оптимизацией цепочки поставок, и когда вина падает на поставщика, это связано с тем, что поставщик старается выглядеть элегантно. Обычно они пытаются минимизировать свои сложности, потому что пытаются продать проблему. Они говорят что-то вроде: «Доверьтесь нам. Это будет проще простого. Мы сделаем это за несколько недель. Бум, мы сделаем это, и все заработает». Реальность такова, что если вы скажете директору по цепочке поставок: «Боюсь, что для уточнения ваших данных потребуется шесть месяцев, и, извините, вы должны были сделать это, но не сделали, так что нам придется сделать это за вас», — очевидно, сложно заключить такую сделку. Поэтому намного проще быть чрезмерно оптимистичным, но это рецепт неудачи. Затем поставщик берет на себя вину, потому что он должен был знать лучше. Возможно, клиент не знает лучше, поскольку это их первый опыт в проведении предиктивного количественного проекта по оптимизации цепочки поставок. Но поставщик, который, по определению, уже имел подобный опыт, должен был знать лучше. Таким образом, если ситуация такова, что таких данных вообще нет, то они должны
Kieran Chandler: Тогда они должны, по сути, предупредить клиента, что на разъяснение семантики данных может потребоваться, возможно, несколько месяцев усилий, чтобы данные можно было квалифицировать как хорошие. Но дело не в том, что изначально они были плохими. Хорошее в этой ситуации — это не противоположность плохому, а скорее противоположность «темным», неквалифицированным или беспорядочным данным.
Joannes Vermorel: Хорошо, и подводя итоги на сегодня, можно сказать, что существует широкий спектр различных проблем, относящихся к плохим данным. Я бы посоветовал стараться выявлять коренную причину проблемы, и чаще всего это люди. То есть, когда я говорю, что проблема — в людях, я не хочу обвинять Джеймса из IT-отдела в том, что он ответственен за беспорядок. Но когда я говорю, что проблема — это люди, нужно четко понимать, кто несет ответственность за неудачу, и, возможно, этого человека поставили в ситуацию, где он не мог ничего сделать, кроме как потерпеть неудачу.
Видите ли, можно прийти к выводу, что Джеймс из IT-отдела потерпел неудачу, но также и то, что сама организация поставила этого бедного Джеймса в положение, в котором у него не было иного выбора, кроме как потерпеть неудачу. Таким образом, интересно, что вы начинаете рассматривать проблему под таким углом, который хотя бы дает подсказки, как ее решить, вместо того чтобы говорить: данные плохи, слишком плохи, плохие данные. А если приступать к новой инициативе, то вы просто повторяете ту же проблему, те же ошибки и в итоге получаете тот же провал в конце дня.
Kieran Chandler: Ладно, если босс Джеймса смотрит, надеюсь, он будет отзывчив. В любом случае, на сегодня это всё. Большое спасибо за внимание, до встречи в следующий раз. Пока!
