Пайплайн извлечения данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создание data lake не является требованием для использования Lokad, а представляет собой потенциальную архитектуру, упрощающую операционную деятельность компании. Стоит отметить, что data lake также способствует формированию «data practice» в компании – если такой практики еще не существует.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Антипаттерн извлечения 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 использует финансовые данные клиента для вычисления адекватного компромисса.

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

Канал извлечения данных автоматически обновляет данные, передаваемые в 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 как для чтения, так и для записи. Раздел Read and Write Files описывает возможности ввода-вывода 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 (в случае подписки Platform+Experts).

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

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

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

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

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

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

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

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

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