POCs don’t work in quantitative supply chain optimization
Proofs of concept are one of the most frequent requests we get from our prospect clients looking to try out our 供給チェーンの最適化 サービス. Yet, we frequently decline such requests; first because they hurt client’s company itself, and second because they also hurt Lokad in the process. Since POCs – or proofs-of-concept – are so widespread in B2B software, it is usually hard to grasp why they can be downright harmful in the specific case of 量的供給チェーン 最適化 (1). In this post, we gather our findings on POCs, considering them to be a supply chain “anti-pattern".
POCs do not cost less
One core assumption behind the POC methodology is that POCs cost less than the real thing. Unfortunately, this assumption is nearly always incorrect.
First, establishing a small scope within an entire supply chain network only barely moves the needle. In the past, ソフトウェアベンダー struggled with scalability problems and actual full-scale deployments did typically require heavy upfront hardware investments, potentially bundled with software licenses such as databases. Without these investments, it was not even possible to start processing data. Yet, in today’s age of クラウドコンピューティング, this constraint does no longer exist, and if an app is designed correctly, nothing extra is required to start processing data. The cloud computing bill will increase only marginally for every additional client, but all in all, this cost is negligible compared to, say, the costs involved in establishing a discussion with the prospect. Second, the bulk of initial efforts consists of データの質の検証, followed by a proper identification oed in establishing a commercial B2B relationship with the client.
Worse still, having more data typically makes things easier, not harder, whenever 統計的予測 is involved. Therefore, by restricting the data scope, POCs tend to make things more difficult, and hence more costly, when compared to addressing the full scope of 課題. Our experience indicates that even when POCs focus on only 5% of the entire supply chain network, these 5% typically involve almost the entire complexity of the network as a whole. Actually, it is precisely because POCs embed nearly all the complexity of a full-scale project, that POCs would be expected to make sense in the first place.
Dismissing the complexity is indeed not an option. If your supply network includes コンテナ輸送 and working with unreliable suppliers, how could a POC possibly be convincing if these elements are not been factored into the initiative? If any specific constraint is ignored, such as MOQs (最小発注数量), the numerical results end-up unusable.
The costs beyond the POC are driven by the efforts to be put on both sides, both by Lokad and its client, in managing the full complexity of the supply chain. Those costs are driven by the specificities of the business being considered, the scale having only a marginal impact on costs.
POCs increase the odds of failure
POCを選択する際、企業はしばしば自社のサプライチェーンを改善するために「試すこと」に終始します。しかし、この特定のケースでは、私はヨーダの言葉を引用したいと思います。「やるかやらないかだ。試すことはない。」ソフトウェアベンダーの主張にもかかわらず、サプライチェーンの最適化は困難です。POCの問題は、失敗する余地があまりにも多いことです。
- 販売履歴の抽出は非常に複雑です。 しかしながら、需要を表すデータなしにサプライチェーンを最適化することは決して成功しません。
- 在庫レベルは正確ではありません。 技術は最も明らかな逸脱を自動検出し、再計算の優先順位付けを支援することができます。しかし、サプライチェーンマネージャーがファントム在庫に対処することは珍しくありません。
- どんな場合でも予測は悪いままです。 企業は不確実な未来を受け入れることを学ぶべきであり、この不確実性を望まないでください。確率的予測は将来の不確実性を特にうまく捉えることができます。
複雑さはボールを投げ出すための多くの言い訳です。
ソリューションが簡単で予期せぬものであると期待される状況もあります。例えば、新しい従業員のための新しいメールアカウントを作成する場合などです。しかし、サプライチェーンの最適化はほとんど常に困難です。会社が数年以上存在している場合、サプライチェーンの「簡単な」部分はすでに数年前に行われています。残されたのは「困難な」部分です。
私たちの経験では、ほとんどのPOCはプロジェクトの初期段階で失敗します。チームがまだデータの問題に苦しんでいるときです。しかし、これはソリューション自体の在庫最適化について何も言っていません。なぜなら、ソリューションはテストされることはありません。
POCはサプライチェーンの最適化イニシアチブを脇道にそれます
POCは、まさに「生産」の視点ではない視点を強調します。経営陣はベンチマークを作成したり、KPIを確立したりすることを求めています。しかし、あるKPIが最適化自体よりも計算が困難である場合はどうでしょうか？また、そのKPI自体が示唆に富んでいるとしても、改善のための実行可能なオプションを提供していない場合はどうでしょうか？
私たちの経験から、POCは通常、生産の観点からは必要のない考慮事項によって迷走します。これらの要件に対処しようとすることは、通常、POCを毒する原因となります。なぜなら、POC自体が本番よりもさらに大きな課題になるからです。
また、POCの主な目的は安心感を求めることであり、ほとんどのPOCはゴールドプレートのアンチパターンに苦しんでいます。クライアント企業がベンダーに対して自社のあらゆる側面を捉えるために圧力をかけるため、その結果得られるソリューションは、生産の観点からはあまりにも脆弱すぎて役に立ちません。
私たちは、多くのPOCが「架空の」問題で失敗しているのを目撃してきました。たとえば、数千のSKUで経験的にテストされた最良の予測モデルが、季節性のある他の利用可能なモデルよりも優れている場合、これは問題と見なすべきでしょうか？疑問はありません、そのビジネスが季節的であるかどうかは: そうです。しかし、この場合に将来の需要を予測するための最も良い方法が、単に季節性を無視することである場合はどうでしょうか？これは問題と見なすべきでしょうか？私たちの経験では、この単一の「問題」が多くのPOCでブロッキングの問題とされてきましたが、サプライチェーンの専門家自身が最終的な発注数量が妥当であると認めていました。
本番に進み、必要に応じてプロジェクトを見直す
POCは通常、次世代のソリューションが進行中のビジネスを維持する必要がある実務者にとって、邪魔と見なされることがあります。私たちの経験からは、直接本番に進む方が安価でリスクが少ないということがわかっています。ただし、適切な方法論を用いる必要があります。
まず、データの「物流」による失敗は選択肢にありません。測定しないものを最適化することはできません。データが意味を持たない場合、すべての最適化試みも無意味になります。成功は要件です。そうでなければ、数年後には会社が存在しなくなるかもしれません。投資するべき努力のほとんどは、このデータの物流に関連しており、この投資はほぼ完全に本番のソリューションの検討から分離することができます。これは良いことです！最適化ソリューションが何らかの理由で不十分である場合、投資は失われることなく、より良い代替ソリューションにリダイレクトする必要があります。
次に、本番に直接進むことが目標であるとしても、数字が問題なく受け入れられるわけではありません。古いプロセスからできるだけ多くの低ハンギングフルーツを選びながら、新しいプロセスを磨き上げる必要があります。
その後、通常は数十の問題が発生します。これらを整理することが重要です：
- 古いプロセスにすでに影響を与えていた問題。良いプロセスと良いテクノロジーは問題を明らかにします。これは欠陥ではなく美徳です。
- ソフトウェアの導入では修正できない問題。倉庫でSKUのピッキングが信頼性に欠ける場合、需要予測モジュールがそれを信頼できるものにすることは期待できません。
- 実際の問題と期待の不一致。統計的な予測は非常に直感に反するものです。定量的な測定が示すことを期待に優先させないでください。
- ソリューションを大幅に再設計しなければ解決できない設計上の問題。これは通常、ソフトウェアが課題に対処するための正しいアプローチを持っていない場合に起こります。
最後のポイントでは、別のソリューションを検討する必要があります。ただし、上記のように、これはイニシアチブの終わりではなく、別のベンダーとの協力の始まりにすぎません。
POCのアイデアを捨てることは、そのイニシアチブに投資された全体の勢いを失うことを意味します。さらに、ほとんどのPOCは誤った理由で失敗するため、実際の課題はほとんど触れられていないため、将来の試みの成功率はほとんど改善されません。
本番に直接進むことは、実際には思われるほどリスクが少ないです。これにより、POCの場合に無視されがちな一連の失敗を防ぐのに役立ちます。それは改善を得るために実際に必要なものに焦点を絞り、願望的な考えを置き去りにすることを強制します。重大なベンダーの失敗に直面した場合、会社は内部の勢いを活かして別のベンダーに切り替えることができます。これは通常、POCの場合に起こる勢いの喪失を防ぐのに役立ちます。
(1) サプライチェーンを最適化する方法は多くあります：プロセスの改善、サプライヤーの改善、輸送業者の改善、採用の改善… この記事では、定量的な最適化に焦点を当てています：統計的な予測と/または数値ソルバーを通じて対処できるサプライチェーンの課題。
(2) 幻の在庫を修正することは、すべての在庫最適化プロセスに利益をもたらします。在庫評価の見直しと改善にも同様のことが言えます。
