Конвейер извлечения данных

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

Мотивация и контекст

Lokad определяет количественную инициативу в сфере оптимизации поставок как инициативу, которая предоставляет числовой рецепт, автоматизирующий принятие решений (или по крайней мере рекомендаций) в условиях вызовов, связанных с поставками. Lokad предлагает программную платформу, разработанную для решения проблем предиктивной оптимизации, связанных с поставками.

Типичные проблемы включают:

• Принятие решения о количестве товара для пополнения запасов
• Принятие решения о количестве товара для производства
• Принятие решения о повышении или понижении цен
• Принятие решения о перемещении товаров внутри сети

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

Числовой рецепт, который решает интересующую проблему, предназначен для реализации в рамках Lokad. В результате числовой рецепт требует, чтобы соответствующие данные компании были доступны на платформе Lokad. Это приводит к следующим вопросам:

• Какие данные должны быть переданы в Lokad?
• Какой формат следует использовать для данных?
• Какие схемы передачи следует использовать для обновления данных?

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

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

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

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

Высокоуровневая техническая перспектива

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

Каждая учетная запись Lokad поставляется с файловой системой, к которой можно получить доступ через протоколы SFTP и FTPS. Также доступен веб-интерфейс, хотя этот интерфейс обычно не предназначен для нашей ИТ-аудитории (а скорее для предоставления панелей инструментов для неспециалистов). Мы ожидаем, что соответствующие данные, обычно извлекаемые из основных транзакционных систем, используемых компанией, будут экспортированы в виде плоских файлов (подробнее об этом ниже) и загружены в файловую систему Lokad.

Если не оговорено иное, отдел ИТ клиента несет ответственность за все, что связано с данными до момента загрузки плоских файлов в файловую систему Lokad. Дизайн платформы Lokad таков, что он может обрабатывать частичные сбои при извлечении данных (подробнее об этом ниже), поэтому отдел ИТ имеет некоторую свободу в этом отношении.

После того, как данные становятся доступными для Lokad, серия скриптов Envision (Envision - это разработанный Lokad язык программирования, специфичный для предметной области) обрабатывает их и генерирует оптимизированные решения в сфере поставок, которые представляют интерес.

Существует несколько практических применений такого извлечения данных, многие из которых выходят за рамки инициативы по оптимизации цепи поставок Lokad. Маркетинговые, финансовые и продажные команды - чтобы назвать только три - являются потенциальными получателями тех же исторических данных о продажах, которые в конечном итоге обрабатывает Lokad. По этой причине Lokad рекомендует объединить транзакционные данные в отдельный слой обслуживания - “озеро данных” - который зарезервирован исключительно для предоставления таких данных соответствующим командам и аналитическим системам сторонних поставщиков (например, платформе Lokad).

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

Объем соответствующих данных

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

Как уже упоминалось ранее, платформа Lokad достаточно гибкая в своих возможностях обработки, поэтому нет жестких требований к данным. Скорее всего, клиент не сможет предоставить многие из перечисленных ниже элементов данных, и Lokad способен работать в рамках таких ограничений. Таким образом, список ниже пытается быть максимально полным в определении полезных источников данных, не требуя строгого предоставления каждого из них.

Каталог продуктов: Список продуктов (или товаров, статей, деталей), которые компания покупает, преобразует, собирает и/или продает. Этот список важен, потому что многие решения принимаются на уровне “продукта”. Иерархия (например, категории, семьи, подсемьи), если она есть, является актуальной - как для целей отчетности, так и для аналитических целей. Структурированные атрибуты (например, цвет, размер, вес, форма), которые характеризуют продукты, также полезны. Как правило, любые данные, описывающие продукты с точки зрения цепи поставок, являются актуальными. Отношения между продуктами - например, BOM (списки материалов) - также являются актуальными.

История заказов на продажу: Список исторических заказов на продажу клиента. Этот список важен, потому что продажи почти всегда являются лучшим прокси для оценки рыночного спроса компании. Эти данные должны включать денежные суммы, связанные с транзакциями, так как оптимизация цепи поставок должна выполняться с финансовой точки зрения. (Эта финансовая перспектива будет рассмотрена позже более подробно.) Если возможно, предоставление сырых заказов, а не ежедневных/еженедельных/ежемесячных агрегатов, всегда предпочтительно. (Этот момент также обсуждается более подробно ниже.) История заказов на продажу может включать отложенные заказы, отмененные заказы, отложенные заказы, измененные заказы, возвраты и т. д., все это потенциально значимые данные. Если клиенты идентифицируются в этих данных, анонимные идентификаторы клиентов становятся значимыми. (Личные данные имеют свой собственный раздел ниже.)

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

Заказы на производство: Список исторических заказов на производство клиента (если применимо) и ожидающие заказы на производство (которые еще не выполнены). Этот список важен, потому что эти заказы отражают поток трансформации товаров, который происходит внутри компании, а также позволяют нам выявить узкие места, которые могут существовать в цепи поставок. В зависимости от ситуации производство может иметь переменную отдачу или иногда партии могут быть списаны из-за проблем с качеством. Эти события являются значимыми.

Движения запасов: Список исторических движений запасов клиента, если присутствуют несколько местоположений. Этот список важен, потому что он проливает свет на происхождение запасов, используемых для запуска процессов производства или обслуживания клиентов. В зависимости от ситуации сроки выполнения этих движений могут быть переменными. Если это так, то также важны детали дат (дата трансфера заказа, дата отправки, дата получения).

Уровни запасов: Список всех SKU (единиц учета запаса) клиента с их текущим уровнем запаса. Этот список важен, потому что он характеризует текущее состояние цепи поставок. В зависимости от отрасли представление о запасах может быть более сложным, чем простые уровни SKU. Могут также присутствовать сроки годности. Часть или весь запас может отслеживаться на уровне серийных номеров. Если используется серийный учет запасов, важен весь список серийных номеров и связанные с ними местоположения. Более общим образом, все элементы, описывающие текущее состояние активов запасов, удерживаемых компанией, являются значимыми.

Ценники: Список цен, применяемых клиентом при обслуживании товаров (и, возможно, связанных услуг). Этот список важен, потому что текущая ценовая политика клиента может отличаться от того, что он ранее взимал. Новые цены влияют на будущий спрос, а также на прибыльность решений в цепи поставок. Могут также присутствовать акции, скидки или варианты ценообразования. Все элементы, которые влияют на расчет того, что взимается с клиентов, являются значимыми.

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

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

Приоритизированная схема подготовленных данных

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

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

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

Историческая глубина данных

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

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

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

Отсутствующие данные

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

На нашем опыте, существуют две широкие категории “отсутствующих” данных, которые следует различать: во-первых, данные, которые должны быть интегрированы в бизнес-систему; во-вторых, данные, которые считаются чрезвычайно полезными для аналитической системы (например, Lokad).

Минимальные заказные количества (MOQ), скидки на цены и закрытые недели поставщиков - это данные, которые часто отсутствуют в бизнес-системах. Однако эти данные ценны с точки зрения оптимизации цепи поставок. Такие данные могут быть разбросаны по электронным таблицам и электронной почте, что мешает прямому структурированному анализу на стороне Lokad. Когда сталкиваются с такими ситуациями, мы предлагаем использовать эвристику (которую должна написать Lokad) и использовать специальные электронные таблицы (которые будут загружены в Lokad). Как только числовой рецепт станет операционным, Lokad свяжется с IT-отделом клиента, чтобы включить данные в бизнес-систему(ы). Кроме того, сам числовой рецепт уточняет, какие данные действительно важны и в какой степени.

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

Извлечения сырых транзакций

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

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

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

С точки зрения ИТ, сырые транзакционные извлечения являются простыми. Следует использовать простые копии таблиц (например, SELECT * FROM MyTable), которые являются самой простой формой запросов к реляционной базе данных. Такие запросы просты, так как в них нет фильтров, и эффективны, так как в них нет объединений. Очень большие таблицы требуют некоторого специального внимания. Этот момент рассматривается ниже.

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

Антипаттерн извлечения BI

Данные, которые должны быть отправлены в Lokad, не должны происходить из вторичного источника (например, системы бизнес-аналитики (BI)), где данные уже были широко изменены, обычно в пользу прямого потребления конечными пользователями. Хотя извлечение данных из системы бизнес-аналитики проще, чем из ERP, это неизбежно создает неразрешимые проблемы впоследствии. По своей сути, транзакционные аспекты данных теряются, так как данные агрегируются в ежедневные / еженедельные / ежемесячные временные ряды.

Кроме того, многие трудно визуализируемые, но важные сложности, такие как многострочные заказы, исключаются из систем бизнес-аналитики (например, кубов BI). Эти детали ценны, так как они отражают суть ситуаций в цепочке поставок, которые должны быть решены.

Плохие данные

По опыту Lokad, случаи плохих данных редки. Напротив, транзакционные бизнес-системы (например, ERP) обычно имеют точные данные. Неправильные записи транзакционных данных редки и обычно возникают один или два раза на 1000 записей. При использовании штрих-кодов или подобных устройств, уровень ошибок еще ниже. Настоящая проблема заключается в том, что программное обеспечение делает неправильные предположения о данных, а не в том, что сами данные плохие.

Уровни запасов в магазинах для крупных розничных сетей B2C почти всегда неточны. Однако с точки зрения Lokad, эта ситуация является случаем шумных данных, а не плохих данных. Если такие уровни запасов (неправильно) считаются точными, результаты будут бессмысленными. Мы подходим к этой конкретной ситуации с вероятностной точки зрения уровней запасов, принимая неопределенность, а не отвергая ее.

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

Персональные данные

Практически никогда инициатива в сфере цепочки поставок не требует персональных данных для работы. Таким образом, с точки зрения цепочки поставок, мы рекомендуем рассматривать персональные данные как обязательство, а не как актив. Мы настоятельно отговариваем от передачи персональных данных на платформу Lokad. На практике это обычно означает фильтрацию столбцов базы данных (см. обсуждение ниже), содержащих персональные идентификаторы (например, имя, адрес, номер телефона, электронная почта и т. д.).

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

Если вы не уверены в позиции Lokad относительно персональной идентифицирующей информации (PII), этот вопрос рассматривается в разделах 1, 3 и 4 нашего документа по безопасности.

Финансовые данные

Денежные суммы за товары, купленные, преобразованные и проданные клиентом, имеют первостепенное значение для оптимизации цепочки поставок, которую предоставляет Lokad. Фактически, Lokad акцентирует внимание на финансовой составляющей цепочки поставок, оптимизируя доллары прибыли по отношению к процентам ошибки.

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

Поток данных против одноразового извлечения

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

Существуют три основных причины, чтобы поддерживать подход с потоком данных.

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

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

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

В-третьих, по нашему опыту, наиболее частой причиной задержки квантитативных инициатив в сфере поставок является позднее настройка конвейера извлечения данных. Мы признаем, что отделы информационных технологий часто испытывают большое давление для выполнения множества проектов, и создание конвейера извлечения данных - это еще одна задача, с которой им приходится справляться. Таким образом, для отдела информационных технологий соблазнительно отложить часть с конвейером, вместо этого начав с серии одноразовых извлечений. Хотя такой подход является жизнеспособным, он представляет риск задержки инициативы, а также предотвращает Lokad от выявления целых классов потенциальных проблем как можно раньше (как описано в предыдущем абзаце).

Частота извлечения данных

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

Для большинства ситуаций в сфере поставок мы рекомендуем режим извлечения данных, который предоставляет полную картину данных до завершения делового дня текущего дня (например, извлечение в четверг вечером всех соответствующих исторических данных до завершения делового дня в четверг). Конвейер извлечения данных запускается в конце рабочего дня, и аналитическая обработка - в рамках платформы Lokad - следует. Свежие результаты становятся доступными с самого начала следующего рабочего дня.

Глубина извлечения данных: правило 2+1 для приращений

Когда объем данных слишком велик, чтобы загружать их полностью в Lokad каждый день, следует использовать инкрементные загрузки. Мы рекомендуем использовать такие загрузки в соответствии с правилом 2+1 для приращений: временное окно ежедневной загрузки охватывает последние две полные недели, а также текущую. Соблюдение этого правила важно для обеспечения высокой надежности решения Lokad.

Конвейер извлечения данных иногда может сбоить - независимо от Lokad. По нашему опыту, даже отличные отделы информационных технологий испытывают 1-2 сбоя конвейера в год. Если ежедневная загрузка не удалась, последний день данных подвергается риску. Если каждая ежедневная загрузка охватывает только один день (без перекрытия между загрузками), у Lokad остается частично поврежденная история данных. Исправление этой истории данных со стороны Lokad требует второго ручного вмешательства от отдела информационных технологий, помимо исправления того, что помешало нормальной работе конвейера извлечения данных. Это “исправление истории данных” может быть отложено на несколько дней - так как это необычная операция для отдела информационных технологий. В то же время результаты, возвращаемые Lokad, отрицательно сказываются, так как некоторые недавние данные оказываются частично поврежденными.

Напротив, если каждая ежедневная загрузка охватывает последние две полные рабочие недели, а также текущую, неудачный ежедневный запуск конвейера извлечения данных получает полное восстановление на следующий день. Действительно, поскольку конвейер извлечения данных является частью рутинных операций, выполняемых отделом информационных технологий, восстановление нормального состояния работы вероятно произойдет в течение одного рабочего дня. Для этого восстановления не требуется никакого специального взаимодействия между отделом информационных технологий и службой поддержки Lokad или конечными пользователями решения Lokad. Исправление данных автоматически доставляется через перезаписи, которые происходят ежедневно в рамках временного окна 2+1.

Правило 2+1 отражает компромисс на основе опыта Lokad: чем дольше временное окно, тем устойчивее становится конвейер извлечения данных по отношению к временным проблемам. Хотя мы можем надеяться, что любые проблемы с конвейером извлечения данных могут быть решены в течение одного рабочего дня, у отдела информационных технологий могут быть более насущные проблемы. Фактически, сбой конвейера извлечения данных может быть только симптомом более серьезной проблемы, которую отдел информационных технологий приоритезирует для решения. Таким образом, восстановление может занять несколько дней. Правило 2+1 гарантирует, что если отдел информационных технологий сможет исправить конвейер в течение двух недель, операции могут быть возобновлены как обычно с минимальным влиянием на инициативу оптимизации. Однако, если временное окно слишком долгое, то инкрементная загрузка становится слишком тяжелой с точки зрения вычислительных ресурсов, что противоречит самой причине введения инкрементных загрузок.

Если последние три недели представляют менее 100 МБ данных, мы предлагаем использовать месячный вариант правила 2+1: временное окно ежедневной загрузки охватывает последние два полных месяца, а также текущий.

Определение соответствующих таблиц и столбцов

Большинство корпоративных программных продуктов построены на основе реляционных баз данных. Хотя веб-API могут существовать, по нашему опыту, такие API редко обеспечивают удовлетворительную производительность при запланированных полных исторических извлечениях. Напротив, прямой запрос к базе данных с использованием SQL часто оказывается простым в реализации и достаточно производительным, так как рекомендуемые Lokad SQL-запросы не требуют выполнения соединений.

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

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

• название таблицы
• название столбца
• тип столбца
• размер таблицы

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

Диагностика схемы PostgreSQL

Запрос для извлечения всех таблиц и столбцов:

SELECT column_name, data_type
FROM information_schema.columns
WHERE table_name = '‘table_name'’;

См. также https://stackoverflow.com/questions/20194806/how-to-get-a-list-column-names-and-datatypes-of-a-table-in-postgresql

Запрос для извлечения всех размеров таблиц:

select table_name, pg_relation_size(quote_ident(table_name))
from information_schema.tables
where table_schema = '‘public'’

См. также https://stackoverflow.com/questions/21738408/postgresql-list-and-order-tables-by-size

Шаблон запроса для извлечения выборки строк:

select column from table
order by RANDOM()
limit 10000

См. также https://stackoverflow.com/questions/19412/how-to-request-a-random-row-in-sql

Диагностика схемы Oracle

Запрос для извлечения всех таблиц и столбцов:

SELECT table_name, column_name, data_type FROM ALL_TAB_COLUMNS

Запрос для извлечения всех размеров таблиц:

SELECT table_name, num_rows FROM ALL_TABLES

Шаблон запроса для извлечения выборки строк:

set colsep ,
set headsep off
set pagesize 0
set trimspool on
spool c:/temp/oracle/output/foo_my_table.csv
SELECT * FROM FOO_MY_TABLE FETCH FIRST 10000 ROWS ONLY;
spool off

Форматы файлов и передача данных

Платформа Lokad поддерживает простые текстовые форматы файлов (обычно форматы CSV или TSV), а также электронные таблицы Microsoft Excel, как для операций чтения, так и для операций записи. Раздел Чтение и запись файлов документирует возможности ввода-вывода в Lokad. Хотя Lokad поддерживает довольно разнообразный набор опций форматирования, мы рекомендуем следующее:

• Простой текст используется вместо электронных таблиц (см. обсуждение ниже).
• Первая строка содержит заголовки столбцов и соответствует исходным именам столбцов.
• Имена столбцов не содержат пробелов или дефисов.
• Используется кодировка UTF-8 для символов.
• Точка (.) является разделителем десятичных дробей.
• Даты имеют одинаковый формат во всех таблицах.
• Денежные суммы выделяют валюту в отдельный столбец.
• Имя файла соответствует исходному имени таблицы.
• /input - это папка на стороне Lokad, используемая по соглашению для размещения извлеченных файлов.

Если размер извлеченного плоского файла превышает 100 МБ, рекомендуется сжать файл с помощью GZIP.

В отношении передачи данных рекомендуется использовать SFTP с аутентификацией по открытому ключу.

Разделенные таблицы

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

При разделении таблицы на список файлов рекомендуется использовать следующую схему именования файлов: собрать файлы в отдельную подпапку внутри /input (названную по имени соответствующей таблицы) и добавить суффикс к каждому файлу, соответствующий извлеченному сегменту:

/input/mytable/mytable-2022-10-17.csv
/input/mytable/mytable-2022-10-18.csv
/input/mytable/mytable-2022-10-19.csv
/..

Даже если все строки внутри файла имеют одно и то же значение “даты” (соответствующее значению в имени файла), рекомендуется оставить этот столбец “даты” в файле.

Microsoft Excel

Платформа Lokad поддерживает чтение данных из электронных таблиц Microsoft Excel, при условии, что таблица имеет табличный формат (первая строка содержит заголовки, затем одна запись на строку). Однако конвейер извлечения данных должен избегать передачи электронных таблиц в Lokad.

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

• Данные еще не существуют в бизнес-системах.
• Данные обновляются очень редко.

/manual - это папка на стороне Lokad, используемая по соглашению для получения файлов, загруженных вручную.

Перезапись файлов

Файлы в файловой системе Lokad представляют данные, как они видны Lokad. Перезапись существующих файлов - рекомендуемый способ обновления извлеченных таблиц, которые не являются разделенными. В случае разделенной таблицы ожидается создание одного нового файла для каждого периода (один файл в день, или неделю, или месяц).

После того, как все файлы, которые должны быть созданы (или перезаписаны), переданы в Lokad, рекомендуется создать (или обновить) файл с именем /input/end-of-transfer.csv, который содержит:

• один столбец с именем LastTransfer
• одна строка данных (две строки, если учитывать заголовок) с отметкой времени самой последней передачи

Этот файл может быть использован для запуска последовательности проектов, которая обрабатывает свежие обновленные данные.

Здоровье данных

Конвейер извлечения данных должен работать надежно. Сама платформа Lokad может использоваться для инструментирования вывода конвейера извлечения данных и оценки целостности, полноты и актуальности извлеченных данных. Таким образом, в качестве первого шага конвейера в Lokad рекомендуется реализовать панели управления здоровьем данных. Эти панели предназначены для IT-отдела (хотя не ожидается, что они возьмут их на себя). Общая цель панелей управления - выявить любые проблемы с данными и ускорить их решение IT-отделом. Эта реализация, как и остальная числовая рецептура, обеспечивающая оптимизированную поставку, должна быть выполнена специалистом по цепочке поставок, возможно, командой Lokad (в случае подписки на Платформу+Эксперты).

Спецификация извлечения данных

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

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

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

Обратная связь

Решения по цепочке поставок (например, пополнение запасов) , созданные в рамках платформы Lokad, могут быть экспортированы в виде плоских файлов для повторной интеграции в систему(ы) предприятия. Этот механизм называется обратной связью. Наш опыт показывает, что реализация обратной связи маловероятна в течение четырех месяцев после начала инициативы. Доверие к числовому алгоритму, необходимому для автоматического управления даже частью цепочки поставок, является значительным, и такая уверенность может занять несколько месяцев. Таким образом, обратная связь не является проблемой на старте инициативы.

Наш опыт показывает, что настройка обратной связи является гораздо меньшей проблемой, чем настройка конвейера извлечения данных. Например, цифры, созданные в рамках Lokad, ожидается, что будут авторитетными и окончательными; если есть дополнительные правила, которые должны быть применены для превращения этих цифр в действенные числа (например, применение MOQ), то числовой алгоритм неполон и требует исправления со стороны Lokad. С другой стороны, платформа Lokad имеет возможность обрабатывать и создавать любую форму данных, пока они являются разумно табличными. Таким образом, простота обратной связи разработана для отражения простоты решений по цепочке поставок. Например, может быть десятки ограничений, которые определяют, является ли данный заказ на закупку действительным или нет, но содержание окончательного заказа на закупку является простым списком количеств, связанных с номерами деталей.

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

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