00:00:07 サプライチェーンプロジェクトにおける不良データのスケープゴート化。
00:00:33 なぜ不良データがプロジェクト失敗の口実になりやすいのか。
00:01:42 不良データに関する課題とその品質に対する誤解。
00:03:16 ERPシステムからのデータアクセスの困難さとベンダーとの課題。
00:06:32 ERPシステム間の移行時に発生する問題やデータ破損。
00:08:01 誤ったデータエントリーへの対応とそれがERPシステムに与える影響。
00:09:48 過去データの予測と問題点の発見。
00:11:37 進化するセマンティクスや定義の変更が如何にデータ問題を引き起こすか。
00:12:20 企業の成長に伴うスケーラビリティの問題とデータ取得の最適化。
00:14:45 クリーンな日次抽出を行う際の課題とデータエラーの可能性。
00:16:02 長い処理時間がIT部門の問題解決に与える影響。
00:17:15 データのセマンティクスと解釈の誤解に関する問題。
00:19:22 各データフィールドの適切な理解を保証するためのドキュメントの重要性。
00:21:01 サプライチェーン実務者とIT部門によるデータセマンティクスの理解の役割。
00:23:59 不良データの傘下に存在する問題の幅と根本原因の特定。
概要
このインタビューでは、キアラン・チャンドラーとジョアンネス・ヴェルモレルが供給チェーン最適化におけるデータの役割と、ソフトウェアベンダーや実務者が直面する課題について議論します。ヴェルモレルは、主要な問題は「不良データ」ではなく、データへのアクセスと効果的な利用にあると強調しています。課題としては、旧式のシステム、不十分なドキュメンテーション、そしてデータアクセスの責任所在が挙げられます。統合業者との利害対立、システム移行の問題、予測やスケーラビリティにも問題が生じます。サプライチェーンの最適化のためには、企業はデータの問題を理解し対処し、適切なドキュメンテーションに投資し、データセマンティクスを明確にし、データに失敗の責任を転嫁するのではなく現実的な期待を保たなければなりません。
詳細な概要
このインタビューでは、キアラン・チャンドラーとLokad創設者のジョアンネス・ヴェルモレルが、サプライチェーン最適化プロジェクトにおけるデータの役割と、ソフトウェアベンダーおよびサプライチェーン実務者が直面する課題について議論します。彼らは、サプライチェーンプロジェクトの失敗の口実として「不良データ」がしばしば利用されるという考え方に焦点を当て、その原因追及の重要性を強調します。ヴェルモレルは、データを非難することが、自分に対して個人的に責められる可能性のある人物を非難するのを回避するための都合の良い手段であると指摘し、問題の根本原因を理解することの重要性を強調しています。
ヴェルモレルは、データに関連する問題がサプライチェーン最適化プロジェクトの失敗の最大の原因である可能性が高いと主張していますが、「不良データ」という認識はしばしば誤解に基づいていると述べています。彼は、多くの西洋企業がバーコード、バーコードスキャナー、その他の技術の活用により、何十年にもわたって正確なデータを保持してきたと指摘します。ヴェルモレルによれば、真の問題はデータ自体の品質ではなく、データへのアクセスとその活用の難しさにあるのです。
データを効果的に活用する上での主要な課題の一つは、データへのアクセスを確保することです。多くの企業は、エンタープライズ-リソース-プランニング（ERP）システム、倉庫管理システム（WMS）、輸送管理システム（TMS）など、さまざまな企業向けソフトウェアを長年にわたって使用していますが、これらのシステムはデータのエクスポートに関しては扱いにくいことが多いです。ヴェルモレルはいくつかのシナリオを特定しており、データへのアクセスが特に問題となる場合があると指摘しています：
1 古いシステム: 一部の企業では、40年前のシステムを今なお使用しており、時代遅れでプロプライエタリなバックエンドにより データ抽出が非常に困難となっています。 2 ドキュメント不足: ソフトウェアベンダーは、システムに関する十分なドキュメントを提供しない場合があり、それにより データベース内の多数のテーブルやフィールドを理解し、ナビゲートするのが難しくなります。 3 責任とアクセス: データへのアクセス権を誰に付与するかを決定することは、複数の 企業内のステークホルダー、ソフトウェアベンダー、IT部門、およびサプライチェーン実務者を含む関係者が関与するため、課題となります。
このインタビューでは、サプライチェーン最適化プロジェクトにおけるデータ関連の課題を理解し、対処することの重要性が強調されています。データ自体の品質が問題となることは通常ありませんが、アクセスや利用の困難さがこれらのプロジェクトの失敗に寄与する可能性があります。したがって、これらの課題の根本原因を特定し対処することが、サプライチェーン最適化の成功を確実にするために不可欠です。
また、企業の成長に伴い、ベンダーとの関係、システム統合、スケーラビリティに起因するデータの問題にも掘り下げています。
彼らが議論する主要な問題の一つは、統合業者との利害対立の可能性です。統合業者は、企業が選んだベンダーと協力するよりも、自社のサプライチェーン最適化ソリューションを販売することに関心がある場合があり、これにより企業が統合業者に事実上人質状態に陥り、データへのアクセスや効果的な活用が難しくなることがあります。
別の課題として、あるERPシステムから別のシステムへ移行する際に、データ品質の低下や「ゴミ統合」と呼ばれる現象が発生することがあります。個々のデータエントリーは正確であっても、システム間で過去のデータを移行するプロセスにおいて、旧システムと新システム間で直接的な一対一の対応が存在しないため、エラーが導入される可能性があります。これにより、日常業務には大きな影響を与えない場合でも、サプライチェーン最適化やデータ解析プロジェクトにおいて再び問題として浮上するデータ破損が発生することがあります。
また、将来の不確実性から過去のデータに基づく予測がいかに困難であるかにも触れています。例えば、データのギャップや急激な変化など、問題が明らかな場合は、過去データ内の問題点を発見しやすくなります。しかし、時間の経過とともにセマンティクスや定義が微妙に変化することで、特にシステム間の移行時には、検出が困難な問題が生じることがあります。
企業が成長するにつれて、スケーラビリティがデータの問題を引き起こす可能性も出てきます。小規模な企業では、全ての過去データをスマートフォンに収めることができ、最適化があまり問題にならないのに対し、企業が大きくなるとデータ量そのものが課題となります。この議論は、サプライチェーン管理を効果的に最適化するためには、これらのデータ問題を理解し対処することの重要性を強調しています。
ヴェルモレルは、企業がERPシステムからデータを抽出する際に苦労することが多いと説明しています。なぜなら、これらのシステムは、クリーンな日次データの増分を提供するようには設計されていないため、複雑なプロセスが生じ、誤ったデータ抽出やバグの発生につながる可能性があるからです。関与するデータ量や処理の遅さから、これらの問題のデバッグや修正には数週間もの時間がかかることもあります。
多くの企業は自社のデータが優れていると考えていますが、実際にはデータのセマンティクスが不明瞭な場合が多く、それが誤解や誤った計算を招く原因となります。例えば、「注文日」には、顧客が注文を出した時刻、システムに登録された時刻、または支払いが確認された時刻など、複数の解釈が存在します。誤解を避けるために、ヴェルモレルは、企業がサプライチェーンの複雑さを反映した各フィールドやテーブルごとの詳細なドキュメントを用意すべきだと提案しています。
サプライチェーン最適化における一般的な問題として、実務者が十分な時間をかけずにデータの検証を行うため、ベンダーが不完全または不明瞭な情報を扱う事態が発生することがあります。これにより、データそのものが必ずしも誤っているわけではなく、ドキュメントの不備によって誤解され、「ごみ入力・ごみ出力」の状況に陥る可能性があります。
これらの問題に対処するために、ヴェルモレルは、通常、関与するのは人や組織構造である問題の根本原因を特定することの重要性を強調しています。企業は、誰が失敗の責任を負うべきかを理解し、データを単に非難するのではなく、根本的な問題の解決に努めるべきです。また、ベンダーは、契約を締結するために過度に楽観的になるのではなく、データセマンティクスの明確化に必要な課題と時間について正直に伝えるべきです。
企業は、サプライチェーンを最適化し、データに起因する失敗を防ぐために、適切なドキュメンテーション、明確なデータセマンティクス、そして現実的な期待に投資する必要があります。
完全な文字起こし
Kieran Chandler: Lokad TVでは、本日、なぜこれがこれほど不正確な診断となるのか、また、ソフトウェアベンダーとサプライチェーン実務者の双方が直面する可能性のあるデータ課題について理解を深めます。では、ジョアンネス、不良データがなぜこんなにも簡単な言い訳となるのでしょうか？
Joannes Vermorel: まず第一に、データは文句を言えないからです。誰もデータを弁護しないため、非生物的なものを非難することになり、それは、個人的に責められて反論してくる同僚を非難するよりはましなことです。しかし現実には、根本原因にたどり着くと、常に問題の原因となるのは人間であるということがわかります。データを非難することは、根本原因の特定というステップを省略しているのと同じです。
Kieran Chandler: 確かに、反論しない対象を攻撃するのはとても簡単です。では、どのようにより正確に問題に取り組むことができるのでしょうか？どのような課題があるのでしょう？
Joannes Vermorel: データに関連する問題は、おそらくサプライチェーン最適化プロジェクトの失敗の最大の原因です。しかし、いくつかの誤解があります。「不良データ」と言うと、多くの場合、破損または誤った数値を意味します。しかし、ほとんどの西洋企業では、何十年にもわたって非常に正確なデータを保持しており、誤った部品番号の入力やタイプミスがほとんど見られません。彼らはバーコード、バーコードスキャナー、RFIDのような技術を利用しています。したがって、本当に不良なデータの量は通常非常にごくわずかであり、データ関連の問題によって失敗する多くのイニシアティブを説明するには不十分です。
Kieran Chandler: ほとんどの西洋企業がかなり良質なデータを収集しているとすれば、実際にはデータがそれほど良くないと感じさせる要因として、どのような課題が存在するのでしょうか？
Joannes Vermorel: 最初の問題は、データへのアクセスです。驚くかもしれませんが、企業は何十年にもわたり、さまざまな種類のERP、WMSやTMS、その他の企業向けソフトウェアを用いて日々の運営を行ってきました。しかし、これらのシステムの多くは、データのエクスポートに関してはあまり使いやすくありません。場合によっては、システムを支える適切なリレーショナルSQLデータベースすら持たないほど古いシステムも存在し、そのような状況では、バックエンドが完全に時代遅れでプロプライエタリなため、データの抽出が非常に困難となります。
Kieran Chandler: では、その作業の責任は誰にあるのでしょうか？
Joannes Vermorel: ここでは、複数の責任主体が存在します。まず、システムに関する有意義なドキュメントを提供しなかったソフトウェアベンダーが挙げられます。最悪の場合、データベースを開いてみると、ERPシステムに2,000のテーブルが存在し、それぞれが20から200のフィールドを持っていることに気づき、まさに悪夢のような状況に陥ることもあります。どこから手を付ければよいかわからないほど膨大です。さらに、どこを見るべきかを巡ってベンダーとの問題が発生する可能性もあり、次に、統合業者との問題が挙げられます。統合業者に関しては、利害対立が発生する可能性があります。統合業者の中には、自社のサプライチェーン最適化のレシピ、例えばこのモジュールやあのモジュールなどをあなたに販売することに強い関心を持つ場合があります。そして、あなたが基本的にデータ抽出を依頼すると、内部チームやその他のベンダーと進めようとするイニシアティブにおいて、統合業者は—実際、これまで何度も見受けられたことですが—単に協力的でないことがあります。なぜなら、彼らにとっては、競合しないことが戦略的利益にかなうからです。そして、ここでは、企業があたかも人質状態に陥っているかのような状況、つまり統合業者によって実質的に人質に取られている状況が生じるのです。企業、すなわちERPやその他のシステムの設定、時にはホスティング、さらには全体の維持管理を担当するIT企業にとって、これはまた別のデータ問題となります。しかしご覧の通り、この問題はデータ自体とはほとんど関係がありません。
Kieran Chandler: はい、間違いありません。データにアクセスできないことは大きな障壁のように聞こえます。ところで、他にどのような課題が発生する可能性があるでしょうか？多くのクライアントが大きな頭痛の種として抱える問題の一つに、あるERPシステムから別のERPシステムへの移行があります。それがデータにどのような影響を及ぼすのでしょうか？
Joannes Vermorel: 問題を引き起こすような締めくくりはできません。つまり、別の種類の不良データが発生する状況です。しかし、ここで問題なのは、いわゆるゴミのような統合が行われた場合のデータです。通常、データエントリ自体は正確ですが、あるERPシステムから別のERPシステムへ移行する際、ベンダーや統合業者、あるいは社内のIT部門が行おうとするのは、旧システムから新システムへ履歴データを移行することです。問題は、旧システムで受け取った売上と新システムの売上との間に一対一の対応関係がないことです。もしかすると、データの整理方法が異なるため、旧システムから新システムへ売掛金（AR）を明確に報告する方法がないのです。そして、そうして暫定的な統合を行うと、履歴の不適切な再統合が原因でデータが破損する可能性があります。とはいえ、不適切な履歴の再統合をしても、日々の業務が完全に停止するわけではありません。例えば、旧システムのOracleデータが新システムへ誤って取り込まれたとしても、日常業務の大部分には影響がありません。そして、もし影響が出たとしても、通常は誰かがすぐに誤った部分を修正し、業務を進めるでしょう。確かにこれは継続的な摩擦の原因になるかもしれませんが、問題はすぐに解消されることが多いです。例えば、サプライヤーコードが誤って取り込まれた場合、企業全体で数百万のサプライヤーが存在するわけではないので、最も頻繁に利用される上位100社程度のサプライヤーに関しては、新システム使用開始日から2週間以内に誤ったデータエントリの修正が行われる可能性が高いです。おそらく、3ヶ月後にはほぼすべての誤ったサプライヤーのエントリが修正されるでしょう。しかし問題は、履歴データについては、過去にさかのぼって修正が行われない点にあります。例えば、5年分の履歴があったとしたら、もしかすると3…
Kieran Chandler: 将来的に、過去に発生した可能性のあるこれらの問題を見つけるのはどれほど容易でしょうか？
Joannes Vermorel: 数ヶ月分のデータ欠損のような明らかな問題がある場合はそれらを見つけるのは簡単です。しかし、売上の集計方法の違いや、不正や返品が含まれるか否かなど、見落としやすい微妙な変化もあります。これにより、データの定義そのものが時間とともに変わってしまい、顕著な急増や変動がない限り、履歴データの中でそれらの問題を発見するのは難しくなります。
Kieran Chandler: 私たちが関わる顧客に共通するもう一つの問題はスケーラビリティです。企業が成長するにつれて、データはどんどん散らかっていきます。スケーラビリティがもたらす問題とは何でしょうか？
Joannes Vermorel: スケーラビリティの問題がなければ、毎日会社の全データをそのままコピーすることも可能です。小規模な企業では、全履歴が10ギガバイト未満であるため管理が可能かもしれません。しかし、大企業になるとデータ量が格段に増え、インクリメンタルなデータ取得、つまり毎日データの一部だけを抽出する方法が求められます。しかし、一部のシステムはこの方法に効率的かつ正確に対応できるよう設計されていないため、毎日のクリーンな抽出を構築するために複雑な手法を採用せざるを得ず、その過程で潜在的な問題に直面してしまいます。
Kieran Chandler: 結局、インクリメンタルなデータ抽出を行おうとすることで悪いデータになってしまうのですね。そしてシステム自体がその用途に最適化されていないため、取り扱いが面倒になる。デバッグを考えれば、単にある場所から別の場所へデータをコピーするだけのはずですが、もしそのプロセスが1分で完了するなら、IT部門の誰かが5分でプロセスを起動して正しく動作することを確認できるでしょう。しかし、もしプロセスが完了するまで6時間かかるならば、作業は非常に煩雑になります。この状況での課題について説明していただけますか？
Joannes Vermorel: もちろんです。プロセスの完了に6時間かかるシステムを想像してみてください。IT部門の誰かがプロセスを開始し、10分間待って「長すぎる」と気付き、他の作業に移ってしまうかもしれません。場合によっては、そのプロセス自体を忘れてしまうこともあるでしょう。翌日、6時間後に発生した小さなバグに気づき、クラッシュが起きたことがわかります。問題を再現するためには、さらに6時間の遅延が必要になります。その結果、本来数時間で解決できるはずの問題が、複雑さと長い処理時間により、最終的には全体の遅延が数週間にまで膨らんでしまうのです。これは、実際に労力が数週間必要になるというよりも、人々がプロセスを開始しては忘れ、翌日になってから対処するために起こる現象です。このため、反復作業が非常に遅くなってしまいます。
Kieran Chandler: これらの問題はどの程度広範囲に発生していると言えますか？多くの企業が自社のデータは非常に良好だと信じているものの、実際にはその裏側を見るとそれほどではない、ということはあるのでしょうか？
Joannes Vermorel: はい、まだ話していなかったもう一つの問題として、セマンティクスそのものがあります。多くの企業は自社のデータが良好だと信じていますが、実際にはそのデータが持つ意味が不明確な場合が多いのです。例えば「注文日」という項目についてですが、クライアントが注文した日、ウェブサイトで注文が行われた時刻、システムに登録された時刻、あるいは支払いが有効と確認された時刻など、解釈の余地は多岐に渡ります。つまり、注文日の意味は20通りもの解釈が存在し得るのです。
クライアントとの作業を開始すると、通常は文書化がほとんどなされていないテーブルやカラムに遭遇します。しかし、データの準備が完了すると、各テーブルの各フィールドに対してほぼ1ページ分の文書が出来上がります。典型的なサプライチェーンの状況では、約20のテーブルに20のフィールドがあり、データの意味を明確にするだけで約400ページの文書が必要になるのです。これに多くの人が驚くのですが、データを正しく理解するためには必要不可欠です。
Kieran Chandler: Joannes、サプライチェーン最適化においてデータを正しく理解することの重要性についてお話しいただけますか？
Joannes Vermorel: はい、このデータに反映されているサプライチェーンの複雑さは非常に大きく、もしこの作業を怠れば、正しく理解できないデータに頼ることになってしまいます。つまり「ゴミが入ればゴミが出る」ということです。数値自体が間違っているというよりも、そもそもデータの意味がわからないのです。もし理解できない日付があると、どんな計算や近代化の試みも誤った結果に終わってしまいます。したがって、データのセマンティクスが最も重要なポイントであり、プロジェクトを開始する前にしっかりとした文書化が必要不可欠なのです。
Kieran Chandler: では、データのセマンティクスに関しては誰が責任を負うべきなのでしょうか？
Joannes Vermorel: 私は、サプライチェーンの実務者が主導すべきだと考えます。多くの人はこれをITの問題だと考えがちですが、実際にデータの意味の捉え方は、運用しているプロセスに大きく依存します。例えば、倉庫の入口で製品のスキャンを行うプロセスがある場合、IT部門は現場に常駐していないため、実際のプロセスがどのように構築されているかを正確には把握していません。このデータは単にプロセスの結果として生成されるものであり、最初に現場で動いている人々だけがその本質を理解しているのです。ですから、単に機械の管理や、ソフトウェアが十分なメモリ、帯域、ディスクを持っているかどうかを確認するだけのIT部門に、データの意味を理解するための洞察やスキルがあると期待すべきではありません。データの意味は通常、ビジネス固有の問題であり、決してITの問題ではありません。したがって、責任はしばしば実務者側にもあるのです。実務者は自分たちの言葉と理解で適切に定義するための時間を十分にかけていないため、サプライチェーン最適化の際に、結果としてデータを半分盲目的に扱うベンダーに依存してしまい、それが「ゴミが入ればゴミが出る」という状況を招くのです。
Kieran Chandler: では、ベンダーにも責任がある可能性はあるのでしょうか？
Joannes Vermorel: はい、もちろんです。サプライチェーン最適化を行う企業、例えばCoke Adのような企業においても、ベンダーに問題がある場合があります。多くの場合、ベンダーはスマートに見せようとし、問題を軽視しようとするためです。「安心してください。これは朝飯前です。数週間で終わらせます。バンッ、と解決しますよ」といった具合に話すのです。しかし、実情としては、サプライチェーンの責任者に「データの検証だけで6ヶ月かかる上、あなたがすべきことを怠ったので、我々が代わりにやらなければならない」と伝えると、このような契約をまとめるのは非常に難しいのです。過度な楽観主義に走るのは容易ですが、それは失敗の素となります。そして、ベンダーは本来もっと分かっているはずなのに責任を問われることになります。クライアント側が分かっていないのは、初めて予測的かつ定量的なサプライチェーン最適化プロジェクトに取り組むからかもしれませんが、定義上、ベンダーはそれが初めてではないはずです。彼らはもっと分かっているはずなのです。したがって、この種のデータが存在しないという診断結果になれば、ベンダーは
Kieran Chandler: つまり、データを適切なものと認定できるようにセマンティクスを明確にするために、数ヶ月にも及ぶ作業が必要になるとクライアントに警告すべきということですね。しかし、最初からデータが本当に悪かったわけではない。つまり、この場合、良いデータというのは単に悪いデータの反対ではなく、むしろ暗いデータ、未検証のデータ、または乱雑なデータの反対に近いということです。
Joannes Vermorel: さて、今日の締めくくりとして、実際には「悪いデータ」の傘の下に含まれる様々な問題が存在するということを申し上げたいと思います。問題の根本原因を特定することが重要ですが、その多くは人に起因します。もちろん「人」が問題であると言っても、IT部門のJamesをその混乱の責任者として非難するわけではありません。しかし、問題が「人」にあると言うならば、誰がその失敗の責任を負うべきなのか、またその人が失敗以外の選択肢を持たない状況に置かれていた可能性があることを正確に理解する必要があります。
ご覧の通り、IT部門のJamesが失敗したという結論もあり得ますが、同時にその組織自体がこの可哀想なJamesを他に道がない状況に追い込んだ、という現実も浮かび上がってきます。つまり、データが悪いと単に片付けるのではなく、問題解決の手がかりとなる視点から見ることで、どう修正すべきかのヒントが得られるのです。さもなければ、別のプロジェクトを行っても、同じ問題や同じエラーを繰り返し、最終的には同じ失敗に終わってしまうでしょう。
Kieran Chandler: では、もしJamesの上司がこれを見ているなら、情けをかけてあげてほしいですね。とにかく、今週はこれで以上です。ご視聴ありがとうございました。また次回お会いしましょう。では、さようなら。
