データ抽出パイプライン

This document is intended as a guide for IT departments to construct a pipeline that extracts data from existing business systems and makes this data available within Lokad’s platform. The setup of a data pipeline is one of the earliest phases of a quantitative supply chain initiative. The document covers the approach that Lokad recommends, including the scope of the data to be extracted and made available on the Lokad platform, the format of the data, and the data transfer strategies.

social-data-extraction-pipeline

動機と背景

Lokadは、サプライチェーン上の課題に対する意思決定（または少なくとも推奨）を自動化する数値的なレシピを提供する取り組みを定量的サプライチェーン・イニシアティブと定義しています。Lokadは、サプライチェーンに関連する予測最適化問題の解決を目的として設計されたプログラムプラットフォームを備えています。

initial-phases-of-a-quantitative-supply-chain-initiative

代表的な問題としては：

  • 在庫補充量の決定
  • 生産すべき在庫量の決定
  • 価格の増減を決定する
  • ネットワーク内で在庫を移動すべきかどうかの決定

企業がこれらの意思決定を最適化することに成功すれば、通常は運営コストの削減、運転資本必要量の削減、及びサービス品質の向上が見込まれます。最低限、企業はコスト、キャッシュ、サービスのバランスを見直し、全体的なサプライチェーン戦略により合致させることができるはずです。

The numerical recipe, which addresses the problem of interest, is intended to be implemented within Lokad. As a result, the numerical recipe requires relevant company data to be made available within Lokad’s platform. This leads to the following questions:

  • どのデータをLokadに転送すべきか？
  • データにはどのフォーマットを使用すべきか？
  • データ更新のためにどの転送パターンを使用すべきか？

上記の問題は多岐にわたるものの、関連する入力データは非常に似通っており、通常は企業の主要な取引履歴データ（例：過去の売上）を通じて提供されます。

クライアントのIT部門は通常、データ抽出パイプラインの設定と維持管理を担当します。今後のセクションでは、IT部門に具体的に求められる事項について詳細に説明します。

データ抽出パイプラインが構築されると、Lokad側のエンジニア、すなわちサプライチェーンサイエンティストが、数値的レシピの設定と維持管理を担当します。これらのエンジニアはしばしば「Platform+Experts」サービス契約の一環としてLokadから提供されますが、クライアントがこの能力を内製化することも可能です。しかし、このようなエンジニアが社内にいる場合でも、IT部門ではなくサプライチェーン部門に配置することを推奨します。

このサプライチェーンイニシアティブの一部が外部委託されているか否かにかかわらず、本書で述べられる観点は同じです。

技術的概要

Lokadは、クライアントの既存の取引システムの上に機能する分析層です。言い換えれば、LokadはERPの代替ではなく、従来の取引システムでは現実的に実装できない予測最適化機能を補完するものです。

各Lokadアカウントには、SFTPおよびFTPSプロトコルを介してアクセス可能なファイルシステムが付属しています。ウェブインターフェースも利用可能ですが、このインターフェースは通常、IT担当者向けではなく、むしろ非専門ユーザー向けのダッシュボード提供を目的としています。関連データは、通常、企業で使用されている主要な取引システムから抽出され、フラットファイルとして（下記で詳述）エクスポートされ、Lokadのファイルシステムにアップロードされることが期待されます。

preferred-file-types-to-be-transferred-to-lokad

別途合意がない限り、クライアントのIT部門はフラットファイルがLokadのファイルシステムにアップロードされるまでのデータに関するすべてのことを担当します。Lokadのプラットフォーム設計は、部分的なデータ抽出の失敗を処理できるようになっているため（下記参照）、IT部門にはある程度の裁量が認められています。

データがLokadで利用可能になると、一連のEnvisionスクリプト（EnvisionはLokadが開発したドメイン固有プログラミング言語）がそれらを処理し、最適化されたサプライチェーンに関する意思決定を生成します。

このようなデータ抽出にはいくつかの実用的な応用例があり、その多くはLokadのサプライチェーン最適化イニシアティブを超えたものです。例えば、マーケティング、財務、営業チームなど（ほんの一例です）が、最終的にLokadが処理する同じ過去の売上データの恩恵を受ける可能性があります。このため、Lokadは取引データを専用のサービス層、すなわち「data lake」に統合することを推奨しており、これにより適切なチームやサードパーティの分析システム（例えばLokadのプラットフォーム）に対してそのデータを独占的に提供します。

flow-of-files-from-client-company-to-lokad-via-data-lake

data lakeの構築はLokadを使用するための必須条件ではなく、あくまで企業の運用を容易にするための一つのアーキテクチャです。注目すべきは、data lakeが企業内で「データ活用」の実践を促進する点にも寄与するということです（既にそのような実践が存在しない場合に特に）。

関連データの範囲

サプライチェーンとは、物理的な商品の流れに関する意思決定を最適化することです（購買、輸送、生産、販売など）。その結果、予測最適化イニシアティブにおいて最も関連するデータは、企業内で発生するあらゆる流れを記述するデータであることがほとんどです。このデータは通常、クライアントの取引ビジネスシステムに存在します。

前述のとおり、Lokadのプラットフォームはその処理能力において非常に柔軟であるため、データに関して厳密な要件は存在しません。おそらく、クライアントは以下に列挙される多くのデータ項目を提供できないでしょうが、Lokadはそのような制約下でも運用可能です。したがって、以下のリストは、各データ項目の厳格な提供を要求することなく、有用なデータソースをできる限り網羅的に特定することを目的としています。

商品カタログ: 企業が購入、変換、組み立て、及び/または販売する製品（またはアイテム、記事、部品）の一覧。このリストは、多くの意思決定が「商品」レベルで行われるため重要です。もし存在するならば、階層構造（例：カテゴリ、ファミリー、サブファミリー）は、報告目的および分析目的の両方で関連性があります。また、製品を特定する構造化属性（例：色、サイズ、重量、形状）も有用です。サプライチェーンの観点から製品を記述する任意のデータは有用といえます。部品表（BOM）のような、製品間の関係性もまた重要です。

受注履歴: クライアントの過去の受注履歴の一覧。このリストは、売上が市場需要を推定するための最良の代理値であることがほとんどであるため重要です。このデータには、取引に関連する金額が含まれている必要があります。なぜなら、サプライチェーンの最適化は財務の観点から実施されるべきだからです。（この財務の視点は後でより詳細に再検討されます。）可能な限り、日次／週次／月次の集計値ではなく、生の注文取引データを提供することが（常に）望ましいです。（この点についても下記でより詳細に議論されています。）受注履歴には、保留中の注文、キャンセルされた注文、延期された注文、変更された注文、返品など、潜在的に関連するデータポイントが含まれる場合があります。もしこのデータ内でクライアントが特定される場合、匿名化されたクライアント識別子が関連してきます。（個人データについては後述のセクションがあります。）

発注書: クライアントの過去の発注書の一覧および保留中の発注書（まだ受領されていないもの）。このリストは、発注書が供給業者のリードタイムおよびサービスの質を推定するための最良の代理値であることがほとんどであるため重要です。保留中の発注書は「注文中在庫」を反映しています。発注書には、取引に関連する金額も含める必要があります。可能な限り、生の注文履歴を提供することが（常に）望ましいです。発注履歴には、利用可能であれば、注文日、出荷日、納品日などの関連日付が含まれるべきです。

生産オーダー: クライアントの過去の生産オーダー（該当する場合）および保留中の生産オーダー（まだ実行されていないもの）の一覧。このリストは、これらのオーダーが企業内で発生する商品の変換フローを反映するとともに、サプライチェーンに存在する可能性のあるボトルネックを特定するのに役立つため重要です。状況に応じて、生産は歩留まりが変動したり、品質上の問題でバッチが廃棄されたりする可能性があります。これらの事象は関連性があります。

在庫移動: 複数のロケーションが存在する場合の、クライアントの過去の在庫移動の一覧。このリストは、生産プロセスを起動するためあるいはクライアントにサービスを提供するために使用される在庫の起源を明らかにするため重要です。状況に応じて、これらの移動のリードタイムは変動する可能性があります。その場合、日付の詳細（転送注文日、出荷日、受領日）も関連性があります。

在庫レベル: クライアントのすべてのSKU（ストック・キーピング・ユニット）とその現在の在庫レベルの一覧。このリストは、サプライチェーンの現状を特徴付けるため重要です。業界によっては、在庫の表現が単純なSKUレベル以上に複雑な場合もあります。賞味期限なども存在する可能性があります。全てまたは一部の在庫がシリアル番号レベルで追跡される場合、シリアル番号の全一覧とそれに関連するロケーションも関連します。一般的に、企業が保有する在庫資産の現状を記述するすべての要素が重要です。

価格表: 商品のサービス提供時（場合によっては関連サービスも含む）にクライアントが実施している価格の一覧。このリストは、クライアントの現行の価格ポリシーが従来の料金体系と異なる可能性があるため重要です。新しい価格は将来の需要に影響を与えるだけでなく、サプライチェーンにおける意思決定の収益性にも影響します。プロモーション、値引き、または価格オプションも存在する場合があります。顧客に請求される金額の計算に寄与するすべての要素が関連します。

過去の在庫レベル、過去の価格表、及び過去の保留中の発注書のスナップショットも、ほとんどのサプライチェーンの目的において関連します（ただし、これらのデータはビジネスシステム上ではめったに利用できません）。データ抽出パイプラインが整備され次第、このようなスナップショットはクライアントのIT部門による直接の介入なしに、Lokad内で実装することが可能です。

このリストは既にかなり多岐にわたっていますが、企業の場合、ここに挙げられている以上に関連するデータソースが存在することがほとんどです。経験則として、サプライチェーン部門にとって有用な情報は、予測最適化の目的においても関連性が高く、Lokadに提供されるべきです。

整備されたデータの優先順位付けされたスキーマ

上記で挙げた潜在的に関連するデータテーブルの一覧は、圧倒されるためのものではありません。実際には、イニシアティブを本番環境に移行するために必要なテーブルと、あれば良い程度のテーブルを識別することが重要です。また、サプライチェーンサイエンティストがデータ抽出フェーズを超えて最適化フェーズに移行できるように、抽出を適切に優先順位付けすることも重要です。

したがって、サプライチェーンの実践の一環として、Lokadはサプライチェーンサイエンティストが整備されたデータの優先順位付けされたスキーマを作成し、イニシアティブ開始時にこの文書をクライアントのIT部門と共有することを推奨します。この文書は、データ準備セグメントの終了時に利用可能であると想定されるテーブルおよびそのフィールドを一覧にしており、要求されたすべてのフィールドのそれぞれの優先順位も記載されています。

このスキーマは、抽出されるデータに関する大まかな希望リストを提供するものです。しかしながら、この文書をデータ抽出段階で生成されるファイルの仕様と誤解してはなりません。データ準備はサプライチェーンサイエンティストの責任領域です。データ抽出パイプラインにより提供されるデータのスキーマが、整備されたデータに関連する「理想化された」スキーマと大幅に異なる場合でも、それは許容され（また一般的です）、この点は以下の「Raw transactional extracts」セクションでより詳細に再検討されます。

データの過去の深さ

抽出されるデータの歴史的深さに関しては、通常、二つの異なる懸念があります。第一に、データ抽出はどこまで過去に遡るべきか？第二に、サプライチェーンイニシアティブが成功するために必要な最小限の歴史的深さは何か？

一般的に、行数が10億未満のすべてのテーブルについて、利用可能な全履歴の抽出を推奨します。履歴を編集することは、サプライチェーンの長期的な進化を評価するために関連する可能性のあるデータの喪失につながります。いずれにせよ、フィルタはデータ準備の一環としてLokad側で実装されるため、より多くのデータを転送することが必ずしもLokadの計算リソースの増加を意味するわけではありません。

歴史的深さに関して、最小限の要件は存在しません。システムの履歴が短い（例：6ヶ月）場合、季節性などの特定の統計パターンは推定できません。しかし、Lokadイニシアティブ以前に関心のある意思決定を行う必要があるサプライチェーン実務者も同じ制約を受けています。Lokadの数値的レシピは、クライアントには希薄に見える場合であっても、利用可能な任意の履歴の深さを活用する形で実装されます。

欠損データ

現代のビジネスシステムは通常非常に大規模であるにもかかわらず、欠落していると思われるデータが大量に存在することは否定できません。データが欠落していると認識されると、定量的サプライチェーンの取り組みの実現可能性が疑問視されます。しかし、どれだけデータが「欠落」していても、組織内の従業員は必要な意思決定を行い、サプライチェーンを運用しています。要するに、方法はあるのです。Lokadの技術的アプローチは、まるで従業員が行うかのように、利用可能なもので最大限のことを行うことに依存しています。このアプローチは、完全なデータ要件を提示し、すべての要件が満たされなければ動作しない主流の企業向けソフトウェアとは対極にあります。

私たちの経験では、区別すべき「欠落」データには大きく分けて2つのクラスがあります。ひとつはビジネスシステムに統合されるべきデータ、もうひとつは（Lokadのような）分析システムにとって非常に有益と考えられるデータです。

最小発注数量（MOQ）、価格の割引、仕入先の休業週といったデータは、ビジネスシステムから欠落していることが多いです。それにもかかわらず、これらのデータはサプライチェーン最適化の観点から価値があります。これらのデータはスプレッドシートやメールに散在しているため、Lokad側で直接構造化された分析を行うことが困難です。このような状況に直面した場合、私たちはLokadがコード化するヒューリスティックスや、Lokadにアップロードされるアドホックなスプレッドシートの使用を提案します。数値レシピが稼動すれば、LokadはクライアントのIT部門と連携し、データをビジネスシステムに組み込むようにします。さらに、数値レシピ自体が、どのデータが本当に重要であり、どの程度重要であるかを明確にします。

競合他社の価格などの競合インテリジェンスデータは非常に有用だと考えられるカテゴリーですが、私たちの経験ではそれが自明であるとは限りません。逸話的には、この種のデータを取得するには多大なコストがかかることが多く、そうでなければ企業はすでに実施しているはずです。このため、そのようなデータの提供は必須ではありません。いずれにせよ、Lokadの数値レシピは、後日、追加データに起因する実際の財務上の利益を評価する上で重要な役割を果たします。

生の取引抽出

私たちは、データの元の形式を保持することを強く推奨します。Lokadにプッシュされるデータは、企業のビジネスシステムを支えるRDBMSに存在する元のテーブルおよびカラムの生のコピーにすぎないべきです。すべてのデータ準備は、データ準備専用に設計されたLokadプラットフォームに委ねられるべきです。

データ準備を試みると必然的にデータ損失が生じます。この損失が許容できるかどうかは、対象となるサプライチェーンの意思決定の具体的内容に依存します。もしデータがLokadのプラットフォームに到達する時点で既に失われているなら、その損失を回復することはできません。生の取引抽出は、ビジネスシステム内で利用可能なすべての情報がLokad内でアクセス可能となることを保証します。

さらに、データ準備はビジネスシステム自体の複雑さに加えて、独自の複雑さの層をもたらします。確かに、望ましいサプライチェーン最適化を実現する数値レシピは、内在する複雑性に対処せざるを得ません。しかし、その数値レシピが事前のデータ準備によってもたらされた偶発的な複雑性にも対処しなければならない場合、既に困難な問題が不必要に難解なものになってしまいます。生の取引抽出は、Lokadが解決すべき問題以上の大きな問題に直面することを防ぎます。

ITの観点から、 生の取引抽出はシンプルです。単純なテーブルコピー（例：SELECT * FROM MyTable）を使用すべきであり、これはリレーショナルデータベースに対する最も基本的なクエリ形式です。そのようなクエリは、フィルターが含まれず結合も行われないためシンプルであり、また高速に動作します。ただし、非常に大きなテーブルについては、専用の対策が必要となります。 この点は以下で説明します。

データレイクが存在する場合、そのデータレイクはビジネスシステムに存在するリレーショナルデータをミラーリングするべきです。主流のデータベースシステムはすべて、組み込みのミラーリング機能を持っています。データレイクの設定時には、これらの機能を活用することを推奨します。さらに、データのミラーリングはデータ準備よりもはるかに容易です―特にIT部門にとっては、データ準備が対処すべき具体的な問題に大きく依存するためです。

BI抽出のアンチパターン

Lokadに送信されるデータは、既に大幅に変更され、通常は最終ユーザー向けに最適化された二次的な情報源（例：ビジネスインテリジェンス（BI）システム）から取得されるべきではありません。BIシステムからのデータ抽出はERPから抽出するより簡単ですが、結果として今後解決できない問題を引き起こすことになります。設計上、データは日次、週次、月次のタイムシリーズに集約されるため、取引の側面が失われます。

さらに、複数行に及ぶ注文など、視覚化が難しいが重要な複雑性は、BIキューブなどのビジネスインテリジェンスシステムから排除されます。これらの詳細は、対処すべきサプライチェーンの本質を反映しているため、非常に価値があります。

不良データ

私たちの経験では、不良データの事例は稀です。むしろ、ERPのような取引ベースのビジネスシステムは通常、正確なデータを保持しています。不正確な取引データの入力は稀であり、通常は1000件に1～2件程度発生します。バーコードなどのデバイスが使用される場合、エラー率はさらに低くなります。本当の問題は、データそのものが悪いのではなく、ソフトウェアがデータについて誤った前提を置いている点にあります。

大規模なB2C小売ネットワークの店舗内在庫レベルはほぼ常に不正確です。しかし、Lokadの観点からすれば、これは不良データではなくノイズの多いデータの事例です。もしそのような在庫レベルを（誤って）正確であると仮定すれば、結果は全く意味をなさなくなります。私たちは、この特定の状況に対して、在庫レベルを確率的に捉え、不確実性を否定するのではなく受け入れるアプローチを取っています。

要するに、Lokadのシステムはデータを受け入れ、クライアントがこれらの懸念を気にせずにサプライチェーンを運用できるように設計されています。Lokadは、これらの問題に対処するためにデータセマンティクスを確立しており、これがデータ準備段階で最も困難な部分となっています。

個人データ

サプライチェーンの取り組みには、運用のために個人データがほとんど必要ありません。したがって、サプライチェーンの観点からは、個人データは資産ではなく負債として扱うことを推奨します。個人データをLokadのプラットフォームに転送することは強く控えるべきです。実際には、これは通常、個人識別子（例：氏名、住所、電話番号、メールアドレスなど）を含むデータベースカラムをフィルタリングすることを意味します。

これらの個人識別子は、サプライチェーンの観点から情報が重要である場合、不透明な匿名識別子に置き換えることができます。たとえば、不透明なクライアント識別子は、在庫切れの悪影響など、顧客の忠誠度に関連するパターンをLokadが特定するのに役立つため、有用です。ほとんどの予測技術が時系列の視点でしか運用できないのとは異なり、Lokadのプラットフォームは取引レベルにまで及ぶ超詳細な履歴データを活用できます。

Lokadの個人を特定可能な情報（PII）に対する立場について不明な点がある場合は、当社のセキュリティドキュメントのセクション1、3、および4でこのトピックが扱われています。

財務データ

クライアントが購入、加工、販売する商品の金額は、Lokadが提供するサプライチェーン最適化にとって極めて重要です。実際、Lokadはサプライチェーンに対して、誤差の割合ではなく利益額を最適化するという財務的視点を強調しています。

在庫数量に関するデータのみを考慮するベンダーとは異なり、Lokadは、利用可能な場合、クライアントの財務データを活用します。論理的には、最も重大なサプライチェーンコストは極端な状況に集中します。予期せぬ高い需要は在庫切れを生み、予期せぬ低い需要は在庫評価損を引き起こします。その中間では、在庫は問題なく循環します。したがって、在庫意思決定を真に最適化するためには、これらのリスクに関して財務的なトレードオフを行う必要があります。Lokadは、クライアントの財務データを利用して適切なトレードオフを計算します。

データパイプライン vs ワンショット抽出

データ抽出パイプラインは、Lokadに転送されるデータを自動的に更新します。この構成は、ワンショット抽出よりも大きな労力を要します。可能であれば、関連テーブルの数が多い場合は段階的なアプローチであっても、データ抽出の自動化を強く推奨します。この自動化は、初日から導入されると最も効果的です。しかし、関連テーブルを特定するために用いられる部分的なワンショット抽出も有用な場合があります。この点については以下で説明します。

データパイプラインアプローチを支持する主な理由は3つあります。

第一に、サプライチェーンの担当者の観点からは、3週間前のデータは既に過去のものです。陳腐化したデータから得られる結果は、現代のサプライチェーンの意思決定にとっては無意味です。ワンショット抽出では、クライアントのビジネス履歴の1回限りのスナップショットに基づく結果しか得られず、それは限定的な価値しか持ちません。さらに、サプライチェーン担当者は、分析システムが実際に稼動している様子を見なければ、日々の変動に対応できるという信頼を得ることができません。

第二に、非常に信頼性の高いデータパイプラインの構築は困難ですが、他の方法よりも望ましいです。信頼性の低いデータパイプラインは、最新の在庫レベルなどの基本的なデータ問題を、いくら分析を重ねても解決できないため、定量的サプライチェーンの取り組み全体を危険にさらします。

抽出プロセスを完璧にするには、多数の定期実行が必要となることが多いです。なぜなら、発生する問題の中には断続的なものがあるからです。これらの問題を解決する最も確実な方法は、できるだけ早くデータパイプラインの運用を開始し、Lokadが問題を特定・解決できる状態にすることです。特に、定期実行は、推奨されたサプライチェーン決定を導く一連のプロセス全体のエンドツーエンド性能を評価する上でも、最も安全な選択肢のひとつです。

第三に、私たちの経験では、定量的サプライチェーンの取り組みが遅れる最も一般的な原因は、データ抽出パイプラインの構築が遅れることです。IT部門は多くのプロジェクトを抱えており、データ抽出パイプラインの構築は彼らが対処しなければならない追加のタスクとなります。そのため、IT部門としては、パイプライン部分を後回しにして一連のワンショット抽出から始める誘惑に駆られます。このアプローチは実行可能ですが、取り組みの遅延を招くリスクや、前述のとおりLokadが潜在的な問題の全カテゴリーをできるだけ早く特定するのを妨げるリスクを伴います。

データ抽出の頻度

月次または四半期の計算であっても、抽出部分および分析部分を含むすべてのデータパイプラインを少なくとも1日1回は更新することを推奨します。一見すると直感に反するかもしれませんが、私たちの経験では、頻繁な自動更新こそが高信頼性のエンドツーエンドプロセスを実現する唯一の方法です。

ほとんどのサプライチェーン状況では、当日の営業終了までの完全なデータ像を提供する抽出ルーチン（例：木曜日の夕方に、木曜日の営業終了時点までのすべての関連する歴史的データを抽出する）が望ましいです。データ抽出パイプラインは業務終了時に実行され、続いてLokadプラットフォーム内で分析処理が行われます。新鮮な結果は、翌営業日の始業とともに提供されます。

データ抽出の深さ：インクリメントに対する2+1ルール

毎日全量のデータをLokadに再アップロードするのが難しい場合は、増分アップロードを利用すべきです。こうしたアップロードは、インクリメントに対する2+1ルール、すなわち日次アップロードの時間窓が直近の2完全週と当週を含むようにするルールに従うことを推奨します。このルールに従うことは、Lokadソリューションの高い信頼性を確保するために重要です。

データ抽出パイプラインは、Lokadとは無関係に、時折失敗することがあります。私たちの経験では、優れたIT部門でさえ年に1～2回のパイプライン失敗を経験します。日次アップロードが失敗すると、その日の最後のデータが損なわれます。もし各日次アップロードが1日分のみをカバー（アップロード間で重複がない）している場合、Lokadは部分的に破損したデータ履歴を抱えることになります。この履歴をLokad側で修正するには、最初にデータ抽出パイプラインが適切に動作しなかった原因を修正する作業に加え、IT部門による二度目の手動介入が必要となります。この「データ履歴の修正」は、IT部門にとって通常ではない作業であるため、数日遅れる可能性があります。その間、Lokadが返す結果は、一部の最新データが部分的に破損しているため、悪影響を受けます。

逆に、各日次アップロードが直近の2完全営業週と当週をカバーしていれば、日次実行が失敗した場合でも、翌日には完全に回復します。実際、データ抽出パイプラインはIT部門の日常業務の一環であるため、通常の運用状態への復帰は1営業日以内に実現される可能性が高いです。この回復には、IT部門とLokadのサポートスタッフまたはソリューションのエンドユーザーとの間で特別な連携は必要ありません。データの修正は、2+1の時間窓をカバーする日次上書きによって自動的に実現されます。

2+1ルールは、Lokadの経験に基づくトレードオフを反映しています。時間窓が長ければ長いほど、データ抽出パイプラインは一時的な問題に対してより耐性を持つようになります。私たちは、データ抽出パイプラインの問題が1営業日以内に解決されることを期待できますが、IT部門にはより喫緊の問題があるかもしれません。実際、パイプラインの失敗は、IT部門が優先して解決すべき、より深刻な問題の兆候に過ぎない可能性があります。したがって、回復に数日を要する場合もあります。2+1ルールは、IT部門が2週間以内にパイプラインを修正できる限り、最適化の取り組みに与える影響を最小限に抑えながら通常の運用を再開できることを保証します。しかし、時間窓が長すぎると、増分アップロードが計算資源を過度に消費し、増分アップロードを導入した本来の目的を損なってしまいます。

もし過去3週間のデータ量が100MB未満であれば、我々はmonthly版の2+1ルールの採用を推奨します：日次アップロードの期間は、直近の2完全な月と現在の月をカバーします。

関連するテーブルとカラムの特定

ほとんどのエンタープライズソフトウェアはリレーショナルデータベース上に構築されています。Web APIが存在する場合もありますが、我々の経験では、スケジュールされた全履歴抽出に関してそれらのAPIは満足のいくパフォーマンスをほとんど提供しません。逆に、Lokadが推奨するSQLクエリは結合を必要としないため、SQLを用いてデータベースを直接クエリする方法は実装が容易で、かつ性能も十分であることが多いです。

したがって、ビジネスシステム（例：ERP）が本取り組みの関連データソースと判断され、かつ基盤のリレーショナルデータベースにアクセスできる場合、関連するテーブルとカラムの具体的な絞り込みを行わなければなりません。多くのビジネスシステムは数百のテーブルと数千のカラムを含みますが、そのほとんどはサプライチェーンの取り組みにとって無関係です。経験則として、サプライチェーンの取り組みでは、初期段階で必要となるテーブルは十数個程度、十分なデータカバレッジを得るためにはせいぜい数十個で十分です。

もし企業内にビジネスのデータベーススキーマに詳しいエキスパートがいる場合、その専門知識を活用するのがデータベース内の関連テーブルを特定する最も簡単な方法です。しかし、エキスパートがいない場合でも、逆解析により関心のある領域の特定は通常1～2週間程度で可能です（かなり複雑なシステムでも）。対象システムに関して入手可能な技術文書を活用することに加え、我々は以下を含むデータベースの完全なスキーマ抽出から始めることを推奨します:

  • “the table name”
  • “the column name”
  • “the column type”
  • “the table size”

これらの情報はスプレッドシートにまとめることを推奨します。潜在的なテーブルは、その名前とサイズによって特定できます。最も関連性の高いテーブルは通常、大きなテーブルに存在するため、まず最大のテーブルの綿密な検査から始めることを推奨します。テーブルの検査には、数十行のデータを目視で確認する方法をお勧めし、その観察結果は作業の進行に合わせてスプレッドシートに追記してください。

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のI/O機能が記載されています。Lokadは多様なフォーマットオプションをサポートしていますが、以下を推奨します:

  • Plain text はスプレッドシートの代わりに使用されます（以下の議論を参照）。
  • The first row はカラムヘッダーを含み、元のカラム名と一致します。
  • Column names は空白やハイフンを含みません。
  • UTF-8 が文字エンコーディングに使用されます。
  • Dot (.) は小数点として、小数値の区切りに使用されます。
  • Dates all は全てのテーブルで同じフォーマットを共有します。
  • Monetary amounts は通貨を別のカラムに分離します。
  • The file name は元のテーブル名と一致します。
  • /input は、抽出されたファイルを預けるために慣例として使用されるLokad側のフォルダです。

抽出されたフラットファイルが100MBを超える場合は、GZIPを使用してファイルを圧縮することを推奨します。

転送に関しては、SFTP with a public key authentication の使用を推奨します。

パーティション分割されたテーブル

毎日全体を再アップロードするのが困難なほど大きなテーブルは、パーティション分割することを推奨します。パーティションがデータの経年を反映していれば、増分アップロードが可能となります。経験則として、100万行未満のテーブルは、パーティション分割にかかる労力に見合わないことが多いです。

テーブルを複数のファイルにパーティション分割する場合、推奨されるファイル命名パターンは、各テーブルの名前で名付けられた専用のサブフォルダ（/input内）にファイルをまとめ、各ファイル名に抽出されたセグメントを接尾辞として付与するものです:

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

たとえファイル内の全行が同じ “date” 値（ファイル名に見られるものと一致）であっても、この “date” カラムはファイルの一部として保持することを推奨します。

Microsoft Excel

Lokadのプラットフォームは、スプレッドシートが表形式（最初の行にヘッダーがあり、その後各行にレコードがある）であれば、Microsoft Excelスプレッドシートからのデータ読み込みをサポートします。ただし、データ抽出パイプラインではスプレッドシートの転送は避けるべきです。

スプレッドシートは、自動データ抽出パイプラインによって転送される代わりに、手動アップロードされる場合にのみ許容されます。手動アップロードが許容されるのは、次の場合です:

  • ビジネスシステムに（まだ）データが存在しない場合。
  • データの更新頻度が非常に低い場合。

/manual は、手動でアップロードされたファイルを受け取るために慣例として使用されるLokad側のフォルダです。

ファイルの上書き

Lokadのファイルシステム内のファイルは、Lokadで見たデータそのものを表しています。パーティション分割されていない抽出テーブルを更新するためには、既存ファイルの上書きが推奨されます。一方、パーティション分割されたテーブルの場合、原則として各期間（1日、1週間、または1ヶ月ごと）に1つの新しいファイルが作成されることが期待されます。

作成または上書きされる全てのファイルがLokadに転送されたら、以下を含む /input/end-of-transfer.csv というファイルを作成（または更新）することを推奨します:

  • “a single column named LastTransfer”
  • “a single data line (two lines when counting the header) with a timestamp of the most recent transfer”

このファイルは、最新の更新データを処理するための project sequence を起動するために使用できます。

データの健全性

データ抽出パイプラインは確実に動作しなければなりません。Lokadプラットフォーム自体を使用して、抽出パイプラインの出力を計測するとともに、抽出データの整合性、完全性、および新鮮性を評価することができます。したがって、Lokad内のパイプラインの最初のステップとして、データ健康ダッシュボードの実装を推奨します。これらのダッシュボードはIT部門向けに設計されています（ただし、IT部門が直接管理することは期待されていません）。ダッシュボードの目的は、データに関する問題点を明らかにし、IT部門による迅速な解決を促進することにあります。この実装は、最適化されたサプライチェーン取り組みを推進する他の数値レシピと同様、サプライチェーンの専門家、または場合によってはLokadチーム（Platform+Expertsサブスクリプションの場合）によって行われることが期待されます。

データ抽出の仕様書

データ抽出パイプラインが安定したら、データ抽出の仕様書を作成することを推奨します。この文書には、期待される全てのファイルとそのカラム、ならびにデータ抽出のスケジュールが記載されるべきです。パイプラインの安定化は、取り組み開始から6ヶ月以内に達成されることが期待されます。この文書は、IT部門とサプライチェーン部門が共同で合意する必要があります。文書には、IT部門が適時にLokadプラットフォームに提供することが期待されるデータの詳細な条件が記されています。

データフォーマットは後日改訂される可能性がありますが、データフォーマットまたはそれに関連するスケジュールを変更する前に、IT部門がサプライチェーン部門に通知することが求められます。一般的に、仕様が合意されると、サプライチェーンの運用は、データ抽出の整合性に基づいて行われることが想定されます。したがって、変更があった場合、サプライチェーン部門は、Lokad内のロジックを改訂されたデータフォーマットに対応させるための十分な「猶予期間」を期待すべきです。

詳細な仕様書の作成は多大な時間と労力を要するため、パイプラインが安定するまでこの文書の作成を遅らせることを推奨します。我々の経験では、最初の数ヶ月間、データ抽出および分析セグメントを含むパイプラインは急速に進化します。この急速な進化により、初期の仕様書作成の試みは陳腐化する可能性が高いです.

フィードバックループ

Lokadプラットフォーム内で生成されるサプライチェーンの意思決定（例：在庫補充）は、フラットファイルとしてエクスポートされ、ビジネスシステムに再統合されることができます。この仕組みはフィードバックループと呼ばれます。我々の経験では、取り組み開始から4ヶ月以内にフィードバックループが実装される可能性は低いことが示唆されています。サプライチェーンの一部を自動運転にするために必要な数値レシピへの信頼は大きく、その信頼を構築するには数ヶ月を要するため、フィードバックループは取り組み開始時の懸念事項ではありません.

我々の経験では、フィードバックループの構築はデータ抽出パイプラインの構築に比べればるかに小さな課題です。例えば、Lokad内で生成される数値は権威があり最終的なものと見なされるため、それらの数値を実用的な数字に変換するためにさらにルール（例：MOQの適用）が必要であれば、その数値レシピは不完全であり、Lokad側で修正する必要があります。一方、Lokadプラットフォームは、ある程度表形式であればあらゆる形のデータを処理・生成する能力を持っています。したがって、フィードバックループのシンプルさは、サプライチェーンの意思決定のシンプルさを反映するように設計されています。例えば、特定の発注書が有効かどうかを定義するために数十の制約が存在する可能性がある一方で、最終的な発注書の内容は、部品番号に紐づけられた数量のシンプルな一覧に過ぎません.

しかし、Lokadプラットフォームにクライアントのビジネスシステムへ直接アクセスを許可すべきではありません。代わりに、ファイルはLokadのファイルシステム内で適時に利用可能とすべきです。IT部門がこれらのデータをビジネスシステムに再度インポートする責任を負うことで、万が一Lokadアカウントのセキュリティが侵害された場合でも、会社内の他のシステムにアクセスされるリスクを低減できます。また、これにより、ビジネスシステム上でITが実施する他の操作と競合する場合、フィードバック処理を延期することが可能となります.

フィードバックループは定義上、現実のサプライチェーン運用に関するデータを伴うため、このプロセス専用の仕様書を作成することを推奨します。この仕様書はデータ抽出の仕様書と同様ですが、データが逆方向に転送される点が異なります。この文書も、IT部門とサプライチェーン部門が共同で合意することが期待されます.