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

Это руководство для ИТ-отделов по созданию конвейера, который извлекает данные из существующих бизнес-систем и передаёт их на платформу Lokad. Его настройка — один из первых этапов проекта Количественной цепочки поставок. Документ описывает подход Lokad: какие данные извлекать и передавать на платформу, в каком формате и каким способом.

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

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

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

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

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

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

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

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

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

После создания конвейера инженеры, работающие на стороне Lokad, — специалисты по цепочке поставок — настраивают и сопровождают числовой рецепт. Обычно их работу обеспечивает Lokad в рамках услуги Platform+Experts, но клиент может развивать эту компетенцию и внутри компании. Даже в таком случае мы рекомендуем включать этих инженеров в отдел цепочки поставок, а не в ИТ-отдел.

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

Технический обзор

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

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

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

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

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

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

Объем релевантных данных

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

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

Каталог продуктов: Список продуктов (или товаров, изделий, комплектующих), которые компания покупает, обрабатывает, собирает и/или продает. Этот список важен, так как многие решения принимаются на уровне «продукта». Иерархия (например, категории, семейства, подсемейства), если она присутствует, имеет значение как для отчетности, так и для аналитики. Структурированные атрибуты (например, цвет, размер, вес, форма), характеризующие продукты, также полезны. Как правило, любые данные, описывающие продукты с точки зрения цепочки поставок, являются релевантными. Взаимосвязи между продуктами, например, спецификации (BOM – bill of materials), также имеют значение.

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

Заказы на закупку: Список прошлых заказов компании поставщикам и заказов, поставки по которым ещё не получены. Эти данные почти всегда служат лучшим источником для оценки сроков поставки и качества работы поставщиков. Открытые заказы показывают объём уже заказанных запасов. Нужны также суммы транзакций. При любой возможности следует предоставлять исходную историю заказов, а не агрегаты. Даты заказа, отгрузки и получения тоже следует включать, если они доступны.

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

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

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

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

Исторические снимки уровней запасов, применявшихся цен и открытых заказов на закупку тоже полезны для большинства задач цепочки поставок, хотя бизнес-системы редко их хранят. После настройки конвейера извлечения данных такие снимки можно создавать прямо в Lokad, без участия ИТ-отдела клиента.

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

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

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

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

Эта схема в общих чертах описывает желаемый состав данных. Её не следует путать со спецификацией файлов, создаваемых при извлечении. За подготовку данных отвечают специалисты по цепочке поставок. Схема данных из конвейера может значительно отличаться от «идеализированной» схемы подготовленных данных; это допустимо и встречается часто. Подробнее этот вопрос рассмотрен в разделе «Извлечение исходных транзакционных данных».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В отличие от поставщиков ПО, учитывающих только количество запасов, Lokad использует финансовые данные клиента, если они доступны. Наиболее тяжёлые затраты сосредоточены в крайних ситуациях: неожиданно высокий спрос ведёт к дефициту товара, а низкий — к списаниям запасов. Между этими крайностями запасы оборачиваются нормально. Чтобы действительно оптимизировать решения по запасам, нужно сопоставлять эти риски в денежном выражении. Финансовые данные клиента позволяют Lokad рассчитать подходящий компромисс.

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

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

Существует три основные причины для поддержки подхода с каналом данных.

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

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

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

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

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

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

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

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

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

Конвейер извлечения данных иногда будет давать сбои независимо от Lokad. По нашему опыту, даже у отличных ИТ-отделов бывает 1–2 сбоя в год. Если ежедневная загрузка не проходит, данные за последний день оказываются неполными. Когда загрузки охватывают только один день и не перекрываются, в истории 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. Возможности ввода и вывода описаны в разделе Чтение и запись файлов. Хотя поддерживается широкий набор форматов, мы рекомендуем следующее:

• Текстовый формат используется вместо таблиц (см. обсуждение ниже).
• Первая строка содержит заголовки столбцов и соответствует исходным именам столбцов.
• Имена столбцов не содержат пробелов или дефисов.
• 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 мы рекомендуем сделать панели контроля состояния данных. Они предназначены для ИТ-отдела, но сопровождать их он не должен. Эти панели выявляют проблемы с данными и помогают ИТ-отделу быстрее их устранять. Как и остальной числовой рецепт, их должен реализовать эксперт по цепочке поставок — возможно, команда Lokad при подписке Platform+Experts.

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

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

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

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

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

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

По нашему опыту, настроить обратную связь гораздо проще, чем конвейер извлечения данных. Числа, выдаваемые Lokad, должны быть окончательными и готовыми к использованию. Если к ним нужно применять дополнительные правила, например минимальные объёмы заказа, числовой рецепт ещё не завершён и требует исправления на стороне Lokad. Платформа способна обрабатывать и выдавать любые данные, которые можно разумно представить в таблице. Простота обратной связи отражает простоту самих решений: допустимость заказа могут определять десятки ограничений, но итоговый заказ — всего лишь список артикулов и соответствующих количеств.

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

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