データ抽出パイプライン

本書は、既存の業務システムからデータを抽出し、そのデータをLokadプラットフォーム内で利用可能にするためのパイプラインをIT部門が構築する際のガイドとして作成されています。データパイプラインの整備は、定量的サプライチェーン・イニシアティブの最初期段階の一つです。本書では、Lokadが推奨するアプローチとして、抽出してLokadプラットフォーム上で利用可能にすべきデータの範囲、データ形式、データ転送戦略を取り上げます。

動機と背景

Lokadは、サプライチェーンの課題に対する意思決定、または少なくとも推奨事項の生成を自動化する数値レシピを提供する取り組みを、定量的サプライチェーン・イニシアティブと定義しています。Lokadは、サプライチェーンの予測最適化問題を解くための、プログラム可能なプラットフォームを提供します。

代表的な課題には、次のものがあります。

• 在庫補充量の決定
• 生産すべき在庫量の決定
• 値上げまたは値下げの決定
• ネットワーク内で在庫を移動すべきかどうかの決定

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

対象となる問題に取り組む数値レシピは、Lokad内で実装されることを想定しています。その結果、この数値レシピでは 関連する 企業データをLokadプラットフォーム内で利用可能にする必要があります。これにより、次のような問いが生じます。

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

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

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

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

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

技術的概要

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

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

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

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

このデータ抽出には、Lokadによるサプライチェーン最適化以外にも多くの用途があります。例えば、マーケティング、財務、営業の各チームも、Lokadが処理する販売履歴データを活用できます。そのためLokadは、取引データを専用の配信層である「データレイク」に集約することを推奨します。この層は、社内の関係チームやLokadなどの外部の分析システムにデータを提供する用途に特化させます。

データレイクはLokadを利用するための必須条件ではなく、企業の運用を容易にするための構成の一つです。また、社内にデータ活用の実務がまだ根付いていない場合、データレイクはその確立にも役立ちます。

関連データの範囲

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

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

商品カタログ: 企業が購入、加工、組み立て、販売する製品や品目、部品の一覧。多くの意思決定は商品単位で行われるため、この一覧は重要です。カテゴリ、商品群、サブ商品群などの階層があれば、報告と分析の両方に役立ちます。色、サイズ、重量、形状など、製品を記述する構造化された属性も有用です。サプライチェーンの観点から製品を記述するデータは、原則としてすべて関連します。部品表（BOM）など、製品間の関係を表すデータも重要です。

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

発注情報: 顧客企業の過去の発注と、未入荷の発注の一覧。発注情報は、仕入先のリードタイムとサービス品質を推定するうえで最良の手がかりになることがほとんどです。未入荷の発注は、発注済み在庫を表します。取引金額も含めてください。可能な限り、集計値ではなく生の発注履歴を提供することを常に推奨します。発注日、出荷日、納品日などの日付も、利用可能であれば含めてください。

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

在庫移動: 複数拠点がある場合の、顧客企業の在庫移動履歴。生産や顧客への供給に使う在庫がどこから来たかを示すため、この一覧は重要です。移動にかかるリードタイムが変動する場合は、移動指示日、出荷日、入荷日も必要になります。

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

価格表: 顧客企業が商品や関連サービスに適用する価格の一覧。現在の価格方針は過去のものとは異なる可能性があるため、この一覧は重要です。最新の価格は、将来の需要とサプライチェーンの意思決定の収益性を左右します。販促、数量割引、価格オプションなども対象です。顧客への請求額の計算に関わる要素はすべて関連します。

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

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

優先順位を付けた準備後データのスキーマ

上記の関連する可能性のあるテーブル一覧は、作業量の多さで圧倒するためのものではありません。実際には、本番稼働に不可欠なテーブルと、あれば望ましいテーブルを区別することが重要です。また、サプライチェーンサイエンティストがデータ抽出から最適化へ進めるよう、抽出作業に適切な優先順位を付ける必要があります。

そのためLokadは、サプライチェーンサイエンティストが優先順位を付けた準備後データのスキーマを作成し、取り組みの開始時に顧客企業のIT部門と共有することを推奨します。この文書には、データ準備が終わった時点で利用できるべきテーブルと各フィールド、および要求するすべてのフィールドの優先順位を記載します。

このスキーマは、抽出してほしいデータの概要を示すものであり、抽出段階で生成するファイルの仕様ではありません。データ準備はサプライチェーンサイエンティストの責任です。抽出パイプラインが提供するデータのスキーマが、準備後の「理想化された」スキーマと大幅に異なっていても問題はなく、実際によくあります。この点は、後の「生の取引データの抽出」で詳しく説明します。

抽出する履歴の期間

抽出する履歴の期間については、二つの問いを区別する必要があります。どこまで過去にさかのぼって抽出すべきか、そしてサプライチェーンの取り組みを成功させるには最低限どれだけの履歴が必要か、という問いです。

原則として、10億行未満のテーブルでは利用可能な履歴をすべて抽出することを推奨します。期間を切り詰めると、サプライチェーンの長期的な変化を評価するのに役立つデータを失う可能性があります。フィルタリングはLokad側のデータ準備で行うため、転送するデータが増えても、計算資源の消費が増えるとは限りません。

履歴の期間に最低要件はありません。例えば半年分しかなければ、季節性などの統計的なパターンは推定できません。しかし、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週間前のデータは大昔のものです。古いデータから得た結果は、今の意思決定には役立ちません。一度限りの抽出では、企業の履歴のある一時点に基づく結果しか得られず、価値も限定されます。また、日々の変動に対応できると信頼するには、担当者が実際に稼働するシステムを見る必要があります。

第二に、信頼性の高いデータパイプラインを構築するのは難しくても、他の方法より望ましい選択です。信頼できないパイプラインは、定量的サプライチェーンの取り組み全体を危険にさらします。最新の在庫レベルを取得できないといった根本的な問題は、どれだけ分析しても解決できません。

抽出プロセスを完璧にするには、多数の定期実行が必要となることが多いです。なぜなら、発生する問題の中には断続的なものがあるからです。これらの問題を解決する最も確実な方法は、できるだけ早くデータパイプラインの運用を開始し、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未満なら、2+1ルールの月単位の方式を推奨します。毎日のアップロードで、直前の完了した2か月と今月のデータを送ります。

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

ほとんどのエンタープライズソフトウェアはリレーショナルデータベース上に構築されています。Web APIが存在する場合もありますが、我々の経験では、スケジュールされた全履歴抽出に関してそれらのAPIは満足のいくパフォーマンスをほとんど提供しません。逆に、Lokadが推奨するSQLクエリは結合を必要としないため、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スプレッドシートでの読み書き操作をサポートしています。Read and Write Files セクションには、LokadのI/O機能が記載されています。Lokadは多様なフォーマットオプションをサポートしていますが、以下を推奨します:

• プレーンテキストをスプレッドシートの代わりに使います（後述）。
• 先頭行には、元のカラム名を使った見出しを置きます。
• カラム名に空白やハイフンを含めません。
• 文字コードはUTF-8にします。
• 小数点には**ピリオド（.）**を使います。
• 日付の形式をすべてのテーブルで統一します。
• 金額の通貨は別のカラムに記載します。
• ファイル名は元のテーブル名と一致させます。
• /input は、抽出されたファイルを預けるために慣例として使用されるLokad側のフォルダです。

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

転送には、公開鍵認証を使うSFTPを推奨します。

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

毎日全体を再アップロードするのが困難なほど大きなテーブルは、パーティション分割することを推奨します。パーティションがデータの経年を反映していれば、増分アップロードが可能となります。経験則として、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 というファイルを作成（または更新）することを推奨します:

• LastTransferという名前のカラム一つ
• 最新の転送日時を記録したデータ行一つ（見出しを含めると二行）

このファイルを使って、更新されたデータを処理するプロジェクトの実行シーケンスを開始できます。

データの健全性

データ抽出パイプラインには信頼性が必要です。Lokadプラットフォーム上で出力を監視し、抽出データの整合性、完全性、鮮度を評価できます。Lokad内の処理の最初の段階として、データの健全性を確認するダッシュボードの実装を推奨します。これはIT部門が利用するもので、IT部門が管理を担うことを想定したものではありません。データの問題を明らかにし、IT部門による解決を早めることが目的です。数値レシピの他の部分と同じく、サプライチェーンの専門家が実装します。Platform+Experts契約では、Lokadのチームが担当する場合があります。

データ抽出の仕様書

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

データ形式は後から変更できますが、形式や抽出スケジュールを変更する前に、IT部門はサプライチェーン部門へ通知する必要があります。仕様に合意した後は、サプライチェーンの本番運用が抽出データの整合性に依存するためです。サプライチェーン部門には、新しい形式に合わせてLokad内のロジックを更新できるよう、変更前に十分な猶予期間を設ける必要があります。

詳細な仕様書には相応の時間と労力がかかるため、パイプラインが安定してから作成することを推奨します。当社の経験では、最初の数か月は抽出部分も分析部分も急速に変化します。この時期に仕様書を作っても、すぐに古くなる可能性が高いからです。

フィードバックループ

Lokadが生成した在庫補充などのサプライチェーンの意思決定は、フラットファイルとして出力し、業務システムへ戻せます。この仕組みをフィードバックループと呼びます。当社の経験では、開始から四か月以内に実装することはまれです。サプライチェーンの一部でも自動運転に任せるには数値レシピへの強い信頼が必要で、その形成には数か月かかる場合があります。そのため、取り組みの初期段階でフィードバックループを心配する必要はありません。

当社の経験では、フィードバックループの構築はデータ抽出パイプラインよりはるかに容易です。Lokadが出す数値は、そのまま使える最終的な確定値であるべきです。例えばMOQの適用など、実行可能な数値にするための追加ルールが必要なら、数値レシピは未完成であり、Lokad側で修正しなければなりません。また、Lokadはある程度表形式になっていれば、どのようなデータも処理・生成できます。フィードバックループの単純さは、意思決定自体の単純さを反映しています。発注の妥当性を決める制約は数十あっても、最終的な発注内容は、部品番号と数量を対応させた単純な一覧です。

ただし、Lokadプラットフォームに顧客企業の業務システムへの直接アクセスを許可しないことを推奨します。ファイルはLokadのファイルシステムに適時に用意し、業務システムへの取り込みはIT部門が担当します。これにより、Lokadアカウントが侵害されても、それを足がかりに社内の他のシステムへアクセスすることはできません。また、IT部門が業務システムで行う別の処理と競合する場合は、取り込みを延期できます。

フィードバックループは実際のサプライチェーン運用に関わるデータを扱うため、専用の仕様書を作成することを推奨します。内容はデータ抽出の仕様書に対応しますが、データの転送方向が逆になります。この文書もIT部門とサプライチェーン部門で合意する必要があります。