データ抽出パイプライン

このドキュメントは、IT部門が既存のビジネスシステムからデータを抽出し、Lokadのプラットフォーム内でこのデータを利用できるようにするパイプラインを構築するためのガイドとして作成されています。データパイプラインの設定は、数量的なサプライチェーンイニシアチブの最初のフェーズの1つです。このドキュメントでは、Lokadが推奨するアプローチについて説明し、抽出およびLokadプラットフォームで利用可能なデータの範囲、データの形式、データ転送戦略について説明します。

動機と背景

Lokadは、サプライチェーンの課題に対する予測最適化問題の解決を目的とした数量的なサプライチェーンイニシアチブと定義しています。Lokadは、サプライチェーンに関連する予測最適化問題の解決のために設計されたプログラム可能なプラットフォームを提供しています。

典型的な問題には、次のものがあります：

• 補充する在庫数量の決定
• 生産する在庫数量の決定
• 価格を上げるか下げるかの決定
• 在庫をネットワーク内で移動するかどうかの決定

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

問題に対応する数値レシピは、Lokad内で実装することを目指しています。そのため、数値レシピにはLokadのプラットフォーム内で利用可能な関連する企業データが必要です。これにより、次のような疑問が生じます：

• どのデータをLokadに転送する必要があるのか？
• データにはどのような形式を使用する必要があるのか？
• データを更新するためにどのような転送パターンを使用する必要があるのか？

上記にリストされている問題は多岐にわたりますが、関連する入力データは非常に類似しており、通常は企業のコアトランザクション履歴データ（例：過去の販売データ）を通じて提供されます。

クライアントのIT部門は、通常、データ抽出パイプラインの設定とメンテナンスを担当します。次のセクションでは、IT部門に具体的に求められることについて詳しく説明します。

データ抽出パイプラインが作成されると、Lokad側のエンジニア（サプライチェーンサイエンティストと呼ばれる）が数値レシピの設定とメンテナンスを担当します。これらのエンジニアは、通常は「プラットフォーム+エキスパート」サービス契約の一環としてLokadから提供されますが、クライアントがこの能力を内部化することも可能です。ただし、このようなエンジニアが社内にいる場合でも、IT部門ではなくサプライチェーン部門に配置することをお勧めします。

サプライチェーンイニシアチブのこの部分が外部化されているかどうかに関係なく、このドキュメントで概説されている視点は同じです。

ハイレベルな技術的視点

Lokadは、クライアントの既存のトランザクションシステムの上に動作する解析レイヤーです。つまり、LokadはERPを置き換えるのではなく、従来のトランザクションシステムの一部として実装することができない予測最適化機能を補完します。

各Lokadアカウントには、SFTPおよびFTPSプロトコルを介してアクセスできるファイルシステムがあります。ウェブインターフェースも利用可能ですが、このインターフェースは通常、ITの対象ではありません（非専門家ユーザー向けのダッシュボードの提供のために使用されます）。通常、企業が使用するコアトランザクションシステムから抽出された関連データは、フラットファイルとしてエクスポートされ（以下で詳細に説明します）、Lokadのファイルシステムにアップロードされることを期待しています。

合意がない限り、クライアントのIT部門は、フラットファイルがLokadのファイルシステムにアップロードされるまでのデータに関わるすべてのことに責任を持ちます。Lokadのプラットフォーム設計は、部分的なデータ抽出の失敗を処理できるようになっているため（以下で詳細に説明します）、IT部門はこの点においてある程度の自由度を持っています。

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

このようなデータ抽出の実用的な応用はいくつかありますが、Lokadのサプライチェーン最適化イニシアチブを超えるものもあります。マーケティング、ファイナンス、販売チームなど、同じ歴史的な販売データをLokadが最終的に処理する可能性のあるチームやサードパーティの分析システムの適切なデータへの提供のために、トランザクションデータを専用のサービスレイヤーである「データレイク」に統合することをLokadは推奨しています。

データレイクの作成は、Lokadを使用するための要件ではありませんが、会社の運用を容易にする潜在的なアーキテクチャです。データレイクは、会社内に「データプラクティス」が存在しない場合にも、その出現を容易にします。

関連データの範囲

サプライチェーンは、物理的な商品の流れに関連する意思決定を最適化することに関するものです（購買、輸送、生産、販売など）。その結果、予測最適化イニシアチブにとって最も関連性のあるデータは、会社内で発生するいかなるフローを説明するデータです。このデータは通常、クライアントのトランザクションビジネスシステムに存在します。

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

製品カタログ：会社が購入、変換、組み立て、および/または販売する製品（またはアイテム、記事、部品）のリスト。このリストは、多くの意思決定が「製品」レベルで行われるため重要です。階層（カテゴリ、ファミリ、サブファミリなど）が存在する場合は、報告目的や分析目的の両方で関連があります。製品を特定するための構造化属性（色、サイズ、重量、形状など）も有用です。サプライチェーンの観点から製品を説明する任意のデータは関連があります。製品間の関係（BOM（材料の請求書）など）も関連があります。

販売注文履歴：顧客の過去の販売注文のリスト。このリストは、販売はほぼ常に会社が市場需要を推定するために持つ最良の指標ですので重要です。このデータには、取引に関連する金額も含まれるべきです。サプライチェーンの最適化は財務の観点から行われるべきですので、生の注文取引を提供することができる場合は（常に）集計ではなく生の注文取引を提供することが好ましいです。販売注文履歴には、バックログの注文、キャンセルされた注文、延期された注文、変更された注文、返品など、すべての関連データポイントが含まれる可能性があります。このデータに顧客が識別されている場合、匿名化された顧客識別子が関連します（個人データについては後述します）。

発注：顧客の過去の発注、および未受領の発注（まだ受け取られていない）のリスト。このリストは、発注はほぼ常にサプライヤのリードタイムとサービス品質を推定するための最良の指標ですので重要です。未受領の発注は「発注済み在庫」を反映します。発注に関連する取引には金額も含まれるべきです。可能な限り、集計ではなく生の注文履歴を提供することが好ましいです（常に）。発注履歴には、注文日、出荷日、納品日などが利用可能な場合に含まれるべきです。

生産指示：顧客の過去の生産指示（該当する場合）および未実行の生産指示（まだ実行されていない）のリスト。このリストは、これらの指示は会社内で行われる商品の変換フローを反映し、サプライチェーンに存在する可能性のあるボトルネックを特定することができるため重要です。状況によっては、生産には可変収率がある場合や、品質の問題によりバッチが廃棄される場合があります。これらのイベントは関連があります。

在庫移動：複数の場所が存在する場合、顧客の過去の在庫移動のリスト。このリストは、製品の生産プロセスをトリガーするために使用される在庫の起源、または顧客に提供される在庫の起源を明らかにするため重要です。状況によっては、これらの移動のリードタイムは可変する場合があります。その場合、日付の詳細（移動指示日、出荷日、受け取り日など）も関連します。

在庫レベル：顧客のすべてのSKU（在庫管理単位）とその現在の在庫レベルのリスト。このリストは、サプライチェーンの現在の状態を特徴付けるため重要です。業界によっては、在庫の表現は単純なSKUレベルよりも複雑になる場合があります。有効期限も存在する場合があります。一部またはすべての在庫はシリアル番号レベルで追跡される場合があります。シリアル在庫が使用されている場合、シリアル番号のリストとそれに関連する場所のリスト全体が関連します。一般的に、会社が保有する在庫資産の現在の状態を説明する要素はすべて関連します。

価格タグ：商品（および関連するサービス）を提供する際に顧客に請求される価格のリスト。このリストは、顧客の現在の価格ポリシーが以前の請求と異なる場合があるため重要です。新しい価格は将来の需要だけでなく、サプライチェーンの収益性にも影響を与えます。プロモーション、価格の割引、または価格オプションも存在する場合があります。顧客に請求される金額の計算に寄与するすべての要素が関連します。

過去の在庫レベル、過去の価格タグ、および過去の未受領の発注のスナップショットも、ほとんどのサプライチェーンの目的にとって関連があります（ただし、これらのデータはビジネスシステムではほとんど利用できません）。データ抽出パイプラインが準備されているとすぐに、このようなスナップショットはLokad自体で実装できます - クライアントのIT部門の直接の介入なしで。

このリストはすでにかなりのサイズですが、企業にはここにリストされていない場合でも通常は関連するデータソースがあります。一般的なガイドラインとして、サプライチェーン部門にとって情報が有用であれば、予測最適化の目的で関連がある可能性が高く、Lokadに送られるべきです。

準備されたデータの優先スキーマ

上記で引用されている潜在的に関連するデータテーブルのリストは、圧倒することを意図していません。実際には、イニシアチブを本番環境に移行するためには、どのテーブルが必要であるかを特定することが重要です。また、データ抽出を適切に優先することも重要です。これにより、サプライチェーンの科学者がデータ抽出フェーズを超えて最適化フェーズに移行できるようになります。

したがって、Lokadはサプライチェーンの実践の一環として、サプライチェーンの科学者が準備されたデータの優先スキーマを作成し、このドキュメントをイニシアチブの開始時にクライアントのIT部門と共有することをお勧めします。このドキュメントには、データ準備セグメントの最後に利用可能であることが期待されるテーブルとそのフィールドがリストされています。このドキュメントには、要求されたすべてのフィールドの優先順位もリストされています。

このスキーマは、抽出するデータの高レベルの希望リストを提供します。ただし、このドキュメントは、データ抽出段階で生成されるファイルの仕様と誤解されるべきではありません。サプライチェーンの科学者がデータの準備を担当しています。データ抽出パイプラインによって提供されるデータのスキーマが、準備されたデータに関連付けられる「理想化」されたスキーマと大きく異なる場合でも、これは受け入れられます（そして一般的です）。このポイントは、以下の「生のトランザクション抽出」セクションで詳しく説明されています。

データの歴史的な深さ

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

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

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

欠損データ

近代的なビジネスシステムは通常、多岐にわたりますが、不足しているデータが必ずしも多いです。データが欠落していると、数量的なサプライチェーンのイニシアチブの実現可能性が問われます。ただし、組織内の従業員は、供給チェーンの運営に必要な意思決定を行うことができます。要するに、方法があります。Lokadの技術的なアプローチは、従業員と同様に、利用可能なものを最大限に活用することに依存しています。このアプローチは、すべての要件が満たされない限り、最終的なデータ要件を持つ主流のエンタープライズソフトウェアとは逆です。

私たちの経験では、「欠落している」とされるデータは、大まかに2つのクラスに分けることができます。第一に、ビジネスシステムに統合されるべきデータ。第二に、分析システム（例：Lokad）にとって非常に有益と考えられるデータ。

最小注文数量（MOQ）、価格設定の変更、およびサプライヤーの休業期間は、ビジネスシステムから頻繁に欠落しているデータです。しかし、これらのデータはサプライチェーンの最適化の観点から価値があります。このようなデータは、スプレッドシートやメールに散らばっている場合があり、Lokad側で直接的な構造化分析ができません。このような状況に直面した場合、Lokadがコーディングするヒューリスティックスを使用し、アドホックなスプレッドシートを使用することをおすすめします。数値レシピが稼働すると、LokadはクライアントのIT部門と連携してデータをビジネスシステムの一部に組み込みます。さらに、数値レシピ自体がどのデータが本当に重要であるか、どの程度重要であるかを明確にします。

競合他社の価格などの競争情報は、非常に有用と考えられているカテゴリですが、私たちの経験ではこれは自明ではありません。この種のデータを入手するには、しばしば相当なコストがかかります。そうでなければ、企業は既に行っているでしょう。そのため、このようなデータの提供は必須ではありません。いずれにせよ、Lokadの数値レシピは、追加データに関連する実際の財務的利益を後日評価する上で重要な役割を果たします。

生のトランザクション抽出

私たちは、データの元の形式を保持することを強くお勧めします。Lokadに送信されるデータは、会社のビジネスシステムをサポートするRDBMSで見つかる元のテーブルと列の生のコピーにすぎません。データの準備はすべてLokadプラットフォームに委任するべきです。Lokadプラットフォームは、データの準備に特化して設計されています。

データの準備を試みると、必ずデータの損失が生じます。この損失が許容可能かどうかは、関心のある具体的なサプライチェーンの意思決定に依存します。データがLokadのプラットフォームに到達する時点で既に失われている場合、この損失を回復することはできません。生のトランザクション抽出により、ビジネスシステムで利用可能な情報の全体がLokad内でアクセス可能になります。

さらに、データの準備は、ビジネスシステム自体の複雑さに加えて、独自の複雑さのレイヤーを導入します。望ましいサプライチェーンの最適化を提供する数値レシピは、固有の複雑さのクラスに対処することは避けられません。ただし、この数値レシピが以前のデータの準備によって導入された偶発的な複雑さにも対処しなければならない場合、既に困難な問題が非常に困難な問題になります。生のトランザクション抽出により、Lokadが解決すべき問題よりもさらに大きな問題に取り組むことはありません。

ITの観点からは、生のトランザクション抽出はシンプルです。プレーンなテーブルのコピーを使用するべきです（例：SELECT * FROM MyTable）。これはリレーショナルデータベース上のクエリの最もシンプルな形式です。このようなクエリはシンプルであり、フィルタは関与せず、結合もありません。ただし、非常に大きなテーブルには専用の注意が必要です。このポイントについては後述します。

データレイクが存在する場合、データレイクはビジネスシステムで見つかるリレーショナルデータをミラーリングするべきです。すべての主要なデータベースシステムには、組み込みのミラーリング機能があります。データレイクの設定時には、これらの機能を活用することをお勧めします。さらに、データの準備はデータの準備に比べてはるかに簡単です - 特にIT部門の立場からすると、データの準備は特定の問題に大きく依存します。

BI抽出のアンチパターン

Lokadに送信されるデータは、すでに大幅に変更されている（通常は直接エンドユーザーが利用するために）セカンダリソース（例：ビジネスインテリジェンス（BI）システム）からのものではありません。BIシステムからデータを抽出することはERPから抽出するよりも簡単ですが、これにより将来的に解決不可能な問題が生じます。データのトランザクションの側面は失われ、データが日次/週次/月次の時系列に集約されます。

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

データの品質

Lokadの経験では、データの品質の問題はほとんどありません。それどころか、トランザクションビジネスシステム（ERPなど）には通常、正確なデータがあります。不正確なトランザクションデータの入力は稀であり、通常は1000件に1回または2回発生します。バーコードや類似のデバイスを使用する場合、エラー率はさらに低くなります。実際の問題は、データ自体が悪いのではなく、ソフトウェアがデータについて誤った仮定をしていることです。

大規模なB2C小売ネットワークの店舗在庫レベルはほとんど常に不正確です。ただし、Lokadの観点からは、この状況はノイズのあるデータの問題です。このような在庫レベルが（誤って）正確であると仮定されると、結果は無意味になります。私たちは在庫レベルの確率論的な視点でこの特定の状況に取り組み、不確実性を排除するのではなく受け入れます。

結局のところ、Lokadのシステムはこれらの問題に悩むことなくデータを受け取り、クライアントがサプライチェーンを運営できるように設計されています。Lokadは、これらの問題に対処するためにデータの意味論を確立し、これがデータ準備の段階で最も困難な部分を表しています。

個人データ

サプライチェーンの取り組みでは、ほとんどの場合、個人データは必要ありません。したがって、サプライチェーンの観点からは、個人データを資産ではなく負債と見なすことをお勧めします。Lokadのプラットフォームに個人データを転送することは強く desu。実際には、これは通常、個人識別子（名前、住所、電話番号、メールなど）を含むデータベースの列をフィルタリングすることを意味します。

これらの個人識別子は、サプライチェーンの観点から関連性がある場合、不透明な匿名のもので置き換えることができます。たとえば、不透明なクライアント識別子は有用です。なぜなら、これによりLokadは在庫切れのネガティブな影響など、顧客のロイヤリティに関連するパターンを特定できるからです。時系列の観点でのみ動作するほとんどの予測技術とは異なり、Lokadのプラットフォームはトランザクションレベルまでの超細かい履歴データを活用できます。

Lokadの個人識別情報（PII）に関する立場について確信が持てない場合は、当社のセキュリティドキュメントのセクション1、3、および4でこのトピックが取り上げられています。

金融データ

クライアントが購入、変換、販売する商品の金額は、Lokadが提供するサプライチェーン最適化にとって非常に重要です。実際、Lokadは誤差の割合ではなく、リターンのドルを最適化するサプライチェーンの金融的な視点を強調しています。

在庫数量に関連するデータのみを考慮するベンダーとは異なり、Lokadはクライアントの金融データを利用します（利用可能な場合）。論理的には、最も悩ましいサプライチェーンのコストは極端な状況に集中しています。予想外の高い需要は在庫切れを引き起こし、予想外に低い需要は在庫の廃棄を引き起こします。その間では、在庫はうまく回転します。したがって、在庫の意思決定を真に最適化するには、これらのリスクに関して金融的なトレードオフを行う必要があります。Lokadはクライアントの金融データを活用して適切なトレードオフを計算します。

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

データ抽出パイプラインは、Lokadに転送されるデータを自動的に更新します。このセットアップは、ワンショットデータ抽出よりも大きな努力を必要とします。可能な場合は、関連するテーブルの数が多い場合には段階的なアプローチでデータ抽出を自動化することを強くお勧めします。この自動化は、Day 1からインストールされると最も効果的です。ただし、関連するテーブルを特定するために部分的なワンショット抽出を使用することも有用です。このポイントについては、以下のパッセージで説明します。

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

まず第一に、サプライチェーンの専門家の視点からすると、3週間前のデータは古代の歴史です。古いデータから得られる結果は、現在のサプライチェーンの意思決定には関係ありません。ワンショットの抽出では、クライアントのビジネスのスナップショットに基づいた結果が得られます。これは限られた価値の結果を生み出します。さらに、サプライチェーンの専門家は、日々の変動に対応する能力に対する信頼を得るために、分析システムが実際に動作しているのを見る必要があります。

次に、信頼性の高いデータパイプラインを構築することは困難ですが、他の選択肢よりも望ましいです。信頼性の低いデータパイプラインは、最新の在庫レベルにアクセスできないなど、基本的なデータの問題を解決するために分析を行っても解決できません。

通常、スケジュールされた実行を何度も行うことで、抽出プロセスを完璧にするのに時間がかかります。これらの問題を修正する最も確実な方法は、データパイプラインをできるだけ早く実行し始めることであり、これによりLokadは問題を特定し解決することができます。特に、スケジュールされた実行は、推奨されるサプライチェーンの意思決定の提供につながる一連のプロセスのエンドツーエンドのパフォーマンスを評価するための最も安全なオプションの1つでもあります。

第三に、私たちの経験では、数量的なサプライチェーンのイニシアチブの遅れの最も一般的な原因は、データ抽出パイプラインの遅いセットアップです。IT部門は多くのプロジェクトを提供するために頻繁にプレッシャーを受けていることを認識していますが、データ抽出パイプラインの構築は彼らが対処しなければならない追加のタスクです。したがって、IT部門にとっては、ワンショットの抽出のシリーズから始める代わりに、パイプラインの部分を延期することが誘惑されることがあります。このアプローチは実行可能ですが、イニシアチブに遅れをもたらすリスクがあり、Lokadができるだけ早く潜在的な問題のクラス全体を特定することを妨げる可能性があります（前の段落で説明したように）。

データ抽出頻度

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

ほとんどのサプライチェーンの状況では、抽出ルーチンを推奨します。これにより、現在の営業日の終了までのすべての関連する過去のデータが完全に把握できます（例：木曜日の夜に木曜日の営業終了までのすべての関連する過去のデータを抽出します）。データ抽出パイプラインは、業務終了時に実行され、Lokadプラットフォーム内の分析処理が続きます。新鮮な結果は次の営業日の最初から利用できます。

データ抽出の深さ：増分の2+1ルール

データが毎日完全にLokadに再アップロードするには大きすぎる場合、増分アップロードを使用する必要があります。私たちは、このようなアップロードが増分の2+1ルールに従うことを推奨しています：毎日のアップロードの時間ウィンドウは、過去の2週間と現在の週をカバーします。このルールに従うことは、Lokadソリューションの高い信頼性を確保するために重要です。

データ抽出パイプラインは、時折失敗しますが、それはLokadに依存しません。私たちの経験では、優れたIT部門でも年に1〜2回のパイプラインの失敗が発生します。毎日のアップロードが失敗した場合、最後の日のデータが損なわれます。毎日のアップロードが1日だけをカバーしている場合（アップロード間に重複がない場合）、Lokadは部分的に破損したデータ履歴を持つことになります。このデータ履歴の修正には、IT部門による2回目の手動介入が必要であり、最初にデータ抽出パイプラインの正常な動作を妨げた問題の修正に加えて、数日の遅れが生じる可能性があります。その間、Lokadが返す結果は、最近のデータの一部が部分的に破損しているため、悪影響を受けます。

それに対して、毎日のアップロードが過去の2週間と現在の週をカバーしている場合、データ抽出パイプラインの毎日の実行が翌日に完全に回復します。実際、データ抽出パイプラインはIT部門がカバーする日常の操作の一部であるため、通常の運用状態に復帰することは1営業日以内に起こる可能性があります。この回復には、IT部門とLokadのサポートスタッフまたはLokadソリューションのエンドユーザーとの特別なやり取りは必要ありません。データの修正は、2+1の時間ウィンドウをカバーする毎日の上書きによって自動的に提供されます。

2+1ルールは、Lokadの経験に基づくトレードオフを反映しています。時間ウィンドウが長いほど、データ抽出パイプラインは一時的な問題に対してより強力になります。データ抽出パイプラインの問題が1営業日以内に解決できることを期待できますが、IT部門にはより緊急の問題があるかもしれません。実際、データ抽出パイプラインの障害は、IT部門が優先的に解決するより深刻な問題の症状にすぎません。したがって、回復には数日かかる場合があります。2+1ルールは、IT部門が2週間以内にパイプラインを修正できる限り、最適化イニシアチブへの影響を最小限に抑えて通常の運用を再開できるようにします。ただし、時間ウィンドウが長すぎると、増分アップロードが計算リソースの点で重くなり、最初に増分アップロードが導入された理由が台無しになります。

もし過去3週間が100MB未満のデータを表している場合、2+1ルールの月次バリアントを採用することをおすすめします。毎日のアップロードの時間ウィンドウは、過去の2ヶ月と現在の月をカバーします。

関連するテーブルと列の特定

ほとんどのエンタープライズソフトウェアはリレーショナルデータベース上に構築されています。ウェブAPIが存在するかもしれませんが、私たちの経験では、そのようなAPIはスケジュールされたフルヒストリーの抽出において満足のいくパフォーマンスを提供することはほとんどありません。それに対して、Lokadが推奨するSQLクエリは、実行するために結合が必要ないため、実装が容易でかなりパフォーマンスも高いことが頻繁に証明されています。

したがって、ビジネスシステム（例：ERP）がイニシアチブのための関連データソースと見なされ、基礎となるリレーショナルデータベースにアクセスできる場合、関連するテーブルと列の特定が必要です。多くのビジネスシステムには何百ものテーブルと何千もの列が含まれており、そのうちのほとんどはサプライチェーンイニシアチブには関係ありません。一般的な目安として、サプライチェーンイニシアチブには、始めるためには通常数十のテーブルしか必要とせず、データカバレッジを高めるためにも数十のテーブルしか必要としません。

もし会社がビジネスのデータベーススキーマに精通した専門家にアクセスできる場合、この専門知識を活用することはデータベース内の関連するテーブルを特定する最も簡単な方法です。ただし、専門家がいない場合でも、比較的複雑なシステムが存在する場合でも、興味のある領域を特定するためにデータベースを逆解析することは通常1〜2週間で行うことができます。関心のあるシステムに関するアクセス可能な技術文書を活用するだけでなく、データベースの完全なスキーマ抽出から始めることをおすすめします。これには以下が含まれます：

• テーブル名
• 列名
• 列の型
• テーブルのサイズ

この情報をスプレッドシートにまとめることをおすすめします。潜在的なテーブルは、その名前とサイズによって特定できます。最も関連性の高いテーブルは通常、最大のテーブルを詳しく調査することで見つけることができます（最適化されたサプライチェーンイニシアチブのため）。テーブルを調査するためには、数十のデータ行を視覚的に調査することをおすすめします。作業が進むにつれて、観察結果をスプレッドシートに追加してください。

PostgreSQLスキーマ診断

すべてのテーブルと列を抽出するクエリ：

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

参考：https://stackoverflow.com/questions/20194806/how-to-get-a-list-column-names-and-datatypes-of-a-table-in-postgresql

すべてのテーブルサイズを抽出するクエリ：

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

参考：https://stackoverflow.com/questions/21738408/postgresql-list-and-order-tables-by-size

サンプルの行を抽出するためのクエリテンプレート：

select column from table
order by RANDOM()
limit 10000

参考：https://stackoverflow.com/questions/19412/how-to-request-a-random-row-in-sql

Oracleスキーマ診断

すべてのテーブルと列を抽出するクエリ：

SELECT table_name, column_name, data_type FROM ALL_TAB_COLUMNS

すべてのテーブルサイズを抽出するクエリ：

SELECT table_name, num_rows FROM ALL_TABLES

サンプルの行を抽出するためのクエリテンプレート：

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

ファイル形式と転送

Lokadプラットフォームは、プレーンテキスト、フラットファイル形式（通常はCSVまたはTSV形式）およびMicrosoft Excelスプレッドシートを読み書きの両方でサポートしています。ファイルの読み書きセクションでは、LokadのI/O機能について説明しています。Lokadはさまざまなフォーマットオプションをサポートしていますが、以下を推奨します：

• スプレッドシートの代わりにプレーンテキストを使用します（以下の議論を参照）。
• 最初の行には列のヘッダーが含まれ、元の列名と一致します。
• 列名には空白やハイフンが含まれていません。
• 文字エンコーディングにはUTF-8を使用します。
• 小数点以下の数値の**小数点(.)**を使用します。
• 日付はすべてのテーブルで同じ形式を共有します。
• 通貨金額は別の列に通貨を分離します。
• ファイル名は元のテーブル名と一致します。
• /inputは、抽出されたファイルを預けるためにLokad側で使用されるフォルダです（慣例として）。

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

転送に関しては、公開鍵認証を使用したSFTPを推奨します。

パーティションテーブル

Lokadに完全に再アップロードするのが不便なほど大きなテーブルを、日々のベースでインクリメンタルにアップロードするためにパーティション化することをお勧めします。パーティション化により、パーティションがデータの年齢を反映する場合、インクリメンタルなアップロードが可能になります。一般的な目安として、100万行未満のテーブルは通常、パーティション化する価値がありません。

テーブルをファイルのリストにパーティション化する場合、推奨されるファイルの命名パターンは、専用のサブフォルダ（テーブル名に基づいた名前）にファイルをまとめ、各ファイルに対応する抽出セグメントをサフィックスとして付けることです。

/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のスプレッドシートからデータを読み取ることができます。ただし、スプレッドシートは表形式に従っている必要があります（最初の行にヘッダーが含まれ、その後は1行に1つのレコードがあります）。ただし、データ抽出パイプラインでは、スプレッドシートをLokadに転送しないようにする必要があります。

スプレッドシートは、自動データ抽出パイプラインを介して転送されるのではなく、手動でアップロードされる場合には許容されます。手動アップロードは次の場合に許容されます。

• データがまだビジネスシステムに存在しない場合。
• データが非常にまれに更新される場合。

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

ファイルの上書き

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

Lokadに転送するすべての作成（または上書き）するファイルが完了したら、最新の転送のタイムスタンプを含む**/input/end-of-transfer.csv**という名前のファイルを作成（または更新）することをお勧めします。

• LastTransferという名前の単一の列
• 最新の転送のタイムスタンプを含む単一のデータ行（ヘッダーを含めて2行）

このファイルは、新しく更新されたデータを処理するプロジェクトシーケンスをトリガーするために使用できます。

データの健全性

データ抽出パイプラインは信頼性を持って動作する必要があります。Lokadプラットフォーム自体は、抽出データの整合性、完全性、新鮮さを評価するために使用できます。したがって、Lokad内のパイプラインの非常に最初のステップとして、データの健全性ダッシュボードの実装を推奨します。これらのダッシュボードはIT部門向けに設計されています（ただし、それらを担当することは期待されていません）。ダッシュボードの共通の目的は、データの問題を明確にし、IT部門による問題の解決を迅速化することです。この実装は、最適化されたサプライチェーンイニシアチブを駆動する数値レシピの他の部分と同様に、サプライチェーンの専門家によって行われることが期待されます。可能であれば、Lokadチームによって行われます（Platform+Expertsサブスクリプションの場合）。

データ抽出の仕様

データ抽出パイプラインが安定化したら、データ抽出の仕様を作成することをおすすめします。このドキュメントには、すべての予想されるファイルとその列、およびデータ抽出のタイムテーブルがリストされるべきです。データパイプラインの安定化は、イニシアチブの開始から6か月以内に予想されています。このドキュメントは、IT部門とサプライチェーン部門の間で共同で合意されるべきです。このドキュメントには、IT部門がLokadプラットフォームにタイムリーに提供する予定のデータの詳細が含まれています。

データ形式は後日変更される可能性がありますが、IT部門はデータ形式または関連するスケジュールの変更を行う前に、サプライチェーン部門に通知することが期待されています。一般的に、仕様が合意された後は、サプライチェーンの運用はデータ抽出の整合性に依存することが予想されます。したがって、変更がある場合は、サプライチェーン部門はLokad内のロジックをアップグレードするために十分な「猶予期間」を期待する必要があります（変更されたデータ形式に対応するため）。

詳細な仕様を作成するには、かなりの時間と労力が必要ですので、パイプラインが安定化するまでこのドキュメントの作成を延期することをおすすめします。私たちの経験では、最初の数か月間、パイプライン（データ抽出と分析セグメントの両方）は急速に進化します。この急速な進化は、このような仕様の作成の初期試みを非推奨にする可能性があります。

フィードバックループ

Lokadプラットフォーム内で生成されたサプライチェーンの意思決定（例：在庫の補充）は、フラットファイルとしてエクスポートしてビジネスシステムに再統合することができます。このメカニズムは「フィードバックループ」と呼ばれます。私たちの経験から、フィードバックループはイニシアチブの開始から4か月以内に実装されることはまれです。自動化されたサプライチェーンの一部を実行するためには、数値レシピへの信頼が必要であり、この信頼度は数か月かかる場合があります。したがって、フィードバックループはイニシアチブの開始時点では心配する必要はありません。

私たちの経験では、フィードバックループの設定はデータ抽出パイプラインの設定よりもはるかに小さな課題です。たとえば、Lokad内で生成された数値は権威的で最終的なものとされています。それらの数値を実行可能な数値に変換するためにさらにルールが適用される場合（例：適用される最小注文数量）、数値レシピは不完全であり、修正が必要です。一方、Lokadのプラットフォームは、合理的に表形式のデータであれば、どんな形式のデータでも処理および生成する能力を持っています。したがって、フィードバックループのシンプルさは、サプライチェーンの意思決定のシンプルさを反映しています。たとえば、特定の発注が有効かどうかを定義する制約が数十あるかもしれませんが、最終的な発注の内容は部品番号に関連付けられた数量の簡単なリストです。

ただし、Lokadプラットフォームにはクライアントのビジネスシステムへの直接アクセスを提供しないことをおすすめします。代わりに、ファイルはLokadファイルシステム内でタイムリーに利用可能にする必要があります。IT部門は、このデータをビジネスシステムに再インポートする責任を持ちます。これにより、Lokadアカウントの潜在的なセキュリティ侵害が会社内の他のシステムへのアクセスに使用されることはありません。また、これにより、ITがビジネスシステム上で他の操作と競合する場合に、このフィードバック操作を延期することができる能力が提供されます。

フィードバックループには、定義上、実世界のサプライチェーンの操作に関連するデータが含まれるため、このプロセスに専用の仕様を作成することをおすすめします。この仕様はデータ抽出の仕様と類似していますが、データが逆方向に転送されるようになっています。このドキュメントも、IT部門とサプライチェーン部門の間で共同で合意されることが期待されます。