FAQ: チェンジマネジメント

Lokadのイニシアティブは、優れた自動化された意思決定によりクライアントのサプライチェーンを最適化することを目指しており、通常、発注書や在庫配分の判断といった日常の単調な作業を置き換えます。このページでは、このイニシアティブがもたらす変化に関する疑問や懸念、そしてその効果的な管理方法について説明します。Lokadのエキスパートは、プロセスのナビゲートをサポートするため、常にクライアントの支援にあたります。

対象読者: サプライチェーンおよび/または計画部門。
最終更新日: 2023年12月19日

チェンジマネジメントの概要

Lokadが先駆け提唱する定量的サプライチェーン（QSC）は、従来のアプローチとは大きく異なります。これらの違いは本質的であり、Lokadがこれほど劇的なサプライチェーン改善を実現できる根幹となっています。とはいえ、QSCイニシアティブに伴うチェンジマネジメントは、クライアントが通常考えるよりも容易です。

例えば、Lokadは無駄な接点やプロセスを排除することで、単に一つの無駄を別の無駄に置き換えるのではなく、大幅な改善をもたらします。つまり、管理すべき_変化_は通常二重です: 第一に、日常的かつ反復的なサプライチェーンの意思決定が自動化されたという事実への適応、第二に、その自動化された意思決定の品質が、従来従業員が他の手段（既存システム、スプレッドシート、またはその両方）で達成していたものを上回ることを受け入れることです.

A QSCイニシアティブは、Lokadの Supply Chain Scientists により先導されます。これらの専門家は、他のソフトウェアベンダーによる類似のイニシアティブで複数の人が担うべき多くの役割を統合します。Supply Chain Scientistは、システムインテグレーター、データエンジニア、ビジネスアナリスト、データサイエンティスト、サプライチェーンの専門家、プロジェクトマネージャー（その他の役割も含む）として機能します。Supply Chain Scientists（SCS）は、Lokadの定量的サプライチェーンアプローチを採用するために必要なコーチング、トレーニング、指導、および支援をクライアントに提供します.

Lokadを（本番環境で）成功裏に展開すると、通常、2つの顕著な成果が得られます。一つは、より良いサプライチェーンの意思決定による大幅なコスト削減、もう一つは、主に自動化されたサプライチェーンの意思決定による大幅な生産性向上です.

チェンジマネジメントの観点からは、サプライチェーンのコスト削減は通常問題になりません。企業は最終的に解放された運転資本を他の分野に再投資することを決定するかもしれませんが、そのような判断は通常、Lokadイニシアティブの範囲を超えています。しかし、Lokadによってもたらされる大幅な生産性向上は、従来のプロセスよりもはるかに高い付加価値をもたらす他の業務に再投資されるのが一般的です.

要するに、Lokad導入前は、クライアント企業内のサプライチェーン担当者の活動はほぼ完全に内部志向であり、予測を作成し、その予測を計画に転換し、SKUの最小/最大在庫レベルを調整し、発注書や生産指示書、在庫移動などを作成していました.

Lokadが本番環境で稼働すると、ほとんどの業務は外向きになり、クライアントが質の高いサービスと認識する要素、サプライヤーがさらなる価格低減の障壁と感じる要因、運送業者が信頼性の低さの根本原因と捉える要素などを特定するようになります.

これらの洞察は、SCSによる継続的なサポートを通じて、Lokadのソリューションに常に組み込まれていきます.

サプライチェーンの経営者にとって、最大の変化は、日常的なトラブルシューティングのほぼ完全な解消です。Lokadのソリューションは、厄介な例外ケースに対応するための自動化された意思決定を提供し、不規則な市場行動を解析するために経営者が割くべきリソースを大幅に削減します。これにより、サプライチェーンの経営者は、非効率な意思決定の結果を細かく管理するのではなく、サプライチェーンの目標やプロジェクトの戦略策定に専念できるようになります.

よくある質問 (FAQ)

1. プロジェクトの実装と管理

1.1 実装プロジェクト管理サービスを提供していますか？

はい。これらのサービスは、LokadのSupply Chain Scientists（SCS）によって提供されます。これらの専門家は、実装の管理だけでなく、クライアント企業とのイニシアティブを先導します。これには、Lokadの数値的手法の有効性を、実装前にサプライチェーン管理に対して定量的に保証する、といった多くの業務が含まれます。SCSはまた、クライアント企業がLokad推奨の実務やプロセスを採用できるよう、トレーニング資料を提供します.

さらに、これらの専門家は初期実装を超えてイニシアティブの長期的な成功にコミットし、イニシアティブが「継続的改善」フェーズに移行する際の継続的なサポートを提供します.

Supply Chain Scientist および Supply Chain Scientistの1日 のLokadの講義をご参照いただき、最適化プロセスにおけるSCSの役割についての詳細をご確認ください.

1.2 実装のタイムラインと、タイムラインに含まれるステップまたはフェーズはどのようになっていますか？ 各フェーズの目標は何ですか？（プロジェクト実装のキックオフから本稼働まで）

最初から最後まで、実装は通常約6ヶ月を要します。Lokadは、オンボーディングフェーズ と プロダクションフェーズ を区別します。オンボーディングフェーズの目標は、Lokadの数値的レシピを本稼働に移すことです。オンボーディングフェーズの終了時には、クライアントと協力して定義された対象のサプライチェーン意思決定が自動化されている必要があります。しかし、自動化は実際の目的であるサプライチェーンパフォーマンスの向上の副次的な効果に過ぎません。‘プロダクション’フェーズの目標は、最初に自動化を可能にした数値的レシピを、継続的に洗練・改善・再調整することです.

タイムラインの内訳

オンボーディングフェーズは通常6ヶ月続き、2ヶ月ごとの3つのサブフェーズに分けられます.

• 最初のサブフェーズは、データパイプライン の設定です。目標は、クライアントのデータをLokadに抽出するための完全自動化されたパイプラインを構築することです。データパイプラインで最も要求されるのは、データの‘セマンティクス’（意味）の確立と、パイプラインプロセス自体を（ほぼ）完全に信頼性あるものにすることです。単発のデータ抽出と比較して、データパイプラインは、Lokadが生成するサプライチェーン提言を、クライアントの現状のビジネス課題に適合させるために不可欠です.

• 2番目のサブフェーズは、クライアント固有の数値的レシピ（サプライチェーンの意思決定を推進するソフトウェアロジック）の設計です。目標は、一貫性があり、信頼性が高く、無駄のないレシピを構築することです。初期の数値レシピの起草は迅速に行われ、通常1～2週間以内に完了します。しかし、これらの草案は出発点に過ぎず、担当のSupply Chain Scientistによって反復的に改善され、初期の草案にあった厄介な例外が速やかに排除されます.

• 3番目のサブフェーズは、_デュアルラン_です。数値的レシピはもはや無意味な結果を出さず、最適化を推進する経済的要因も合意されています。しかし、レシピはまだ本番運用レベルではありません。前進するために、デュアルランが実施され、数値的レシピは既存プロセスと並行して実行されます。自動化されているため、組織的なオーバーヘッドは低く、サプライチェーン担当者は日々の意思決定を比較し、季節性などのパターンの展開を確認できます。数週間のデュアルランを通じて、本稼働への展開に十分な信頼が得られます.

オンボーディングフェーズの終了時、すべてのステップが満たされれば、本稼働への展開が開始されます。この展開は、自動化が既存のプロセスに引き継がれることから成り、クライアントのチェンジマネジメント対応能力に応じて段階的に進められる場合もあります.

タイムラインの概要 をご覧いただき、最適化プロセスに含まれる各ステップの詳細な内訳をご確認ください.

1.3 Lokadは、プロジェクトの範囲、スケジュール/タイムライン、重要なマイルストーン、リソース、成果物、責任分担、コスト管理計画、品質管理計画、リスク管理計画、及びステークホルダー管理とコミュニケーション計画を詳細に記したプロジェクト管理計画を文書化し、公開していますか？

はい。これらすべての要素、その他も含め、特有のJoint Procedure Manual (JPM) にまとめられ、イニシアティブの全期間にわたってSupply Chain Scientists（SCS）がJPMの作成と維持を担当します.

LokadのJPMは、『なぜ？』という疑問に焦点を当てています。JPMは丁寧に作成され、技術に詳しくない層や専門家でない層にも十分に理解可能なことを意図しています。JPMは、イニシアティブの背後にある意図の本質を捉え、進行中に得られる基本的な洞察を統合します.

Lokadの見解では、多く（あるいはほとんどすべて）の企業イニシアティブは、実際には読みにくい（すなわち、退屈で理解不能なほど技術的な）役に立たない文書の作成によって妨げられています。そのような文書は、形だけのチェックリストを埋める以外の目的を果たしません。さらに、システムインテグレーター、コンサルタント、さらには社内の官僚機構など、多くの第三者は、プロジェクトの文書化において、品質よりも量を重視する傾向があります.

これに対して、LokadのJPMは_読みやすく_、かつ_読まれる_ことを目的としています。JPMは、SCS自身がイニシアティブを管理するためのツールです。JPMに何が含まれるべきかについての詳細なガイドラインは存在しますが、最終的には、イニシアティブの具体的状況を踏まえ、どの点に最も注意と労力を注ぐべきかをSCSが判断することになります.

供給チェーンのための書き込み の講義をご覧いただき、Lokadのドキュメンテーションに対する理念についてさらに詳しくご確認ください.

1.4 Lokadは、プロジェクト運営委員会の承認を条件として、プロジェクト管理計画の維持およびベースラインの設定に責任を負いますか？ もし計画から逸脱が生じた場合、その逸脱と緩和策を明確に伝達しますか？

はい。これらの責任は、LokadのSupply Chain Scientists（SCS）によって管理されています。クライアントとのコミュニケーション管理の詳細は通常、イニシアティブ自体の契約条件に依存し、そこで定義されます.

クライアント側でLokad側よりもはるかに多くの従業員がプロジェクトに関与する場合があるため、アカウントを担当するSCSの生産性向上のため、多くのクライアントはイニシアティブの単一の連絡窓口を指定します。この担当者または小規模チームが、クライアント側の全関係者に対して関連情報の伝達およびフィードバックの収集を担います.

特に複雑なイニシアティブの場合、Lokadは、Lokad側とクライアント企業側の主要メンバーからなる専用の運営委員会を設置します。この会議は正式な承認を得るための仕組みとして機能しますが、実際の実質的な作業の大部分は委員会外で行われます。SCSは通常、クライアント側の各チームと日々連絡を取り、計画からの逸脱について継続的に情報を更新し、イニシアティブ全体が軌道に乗るよう努めます。これらの日常的なやり取りは、運営委員会の場で大量の問題を検証するよりも、発生した技術的課題を議論し解決する上ではるかに効果的です。したがって、運営委員会は、イニシアティブのためのシンクタンクというよりも、監督機関として機能します.

注意: 定量的サプライチェーンのイニシアティブでは、「プラスの逸脱」に頻繁に遭遇することが知られています。これは、イニシアティブの継続的な維持管理中に明らかになる、レシピにおける有益なサプライズです。実質的には、見逃すにはあまりにも好条件な機会です。このように、Lokadのコミュニケーション手法の主な利点は、これらのプラスの逸脱を発生した際に迅速かつ効率的にクライアントへ伝達できることで、イニシアティブの影響力と機敏性を大幅に向上させる点にあります.

1.5 日次スタンドアップ、週次作業グループのステータス報告およびレビューセッション、並びに月次の運営委員会報告とレビューセッションを含むコミュニケーションプランを文書化しますか？ また、エスカレーションの基準を明確にし、これらの詳細についてクライアント企業とLokadとの間で相互合意を確保しますか？

はい。これらの業務は、LokadのSupply Chain Scientists（SCS）によって担当されます。クライアント内でのコミュニケーション管理の詳細は、通常、イニシアティブ自体の契約条件に依存します.

Lokadは、クライアント企業本社に出向している際には日次スタンドアップに積極的に参加します。しかし通常、SCSはLokadのオフィスで業務を行います.

イニシアティブに関するすべての文書はJoint Procedure Manual (JPM) に統合され、これがプロジェクト全体の包括的なガイドとして機能します。JPMには、作業セッションの記録、（該当する場合は）運営委員会の報告書などが含まれます.

Lokadはエスカレーションの基準とガイドラインを明確にしていますが、重要なのは、LokadのシニアSCSがイニシアティブに関するあらゆる疑問や懸念に対応することが期待されている点です。したがって、エスカレーションの場合、問題の解決は通常、ジュニアSCSからシニアSCSへと引き継がれます。これまでのところ、これで十分であり、さらなるエスカレーションを必要とするケースはほとんどありません.

Lokadは、外見上些細な問題であっても徹底的な分析に値すると見なしています。たとえその影響が容易に解決できたとしても、根本原因が理解・対処されなければ、些細な問題が将来の問題を引き起こす可能性があります。これにより、些細な問題が常習化するのを防ぎます。したがって、Lokadは即時の問題に対処し、同時にその根本原因を特定できる非常に有能な人材を前線に配置することを重視しています。このアプローチは、同じ問題に継続して対処する未熟なサポートスタッフに依存するよりも優れた方法です―これは、多くのエンタープライズソフトウェアベンダーがあまりにも頻繁に採用しているパターンでもあります.

したがって、Lokadの簡潔なエスカレーションプロセスは意図的に設計されており、迅速かつ永続的な解決を保証します。

1.6 プロジェクト開始フェーズの一環として、全ステークホルダーによるプロジェクト管理計画の承認を保証しますか？

はい。より一般的には、LokadのSupply Chain Scientists (SCSs)は、各クライアントと交渉・合意されたプロセス（正式な契約条件に基づく）に従います。この原則は、プロジェクトの開始から完了に至るまで一貫して適用されます。プロジェクトの開始は確かに重要ですが、Lokadが初日から長期的な関与を要求しない点を考慮すると、特に競合他社と比べると、この点はそれほど大きな懸念事項ではありません。

注目すべきは、官僚主義やその他の無駄なプロセスが不足しているためにサプライチェーンのパフォーマンスが低下する事例は一度も見られなかったということです。むしろ、不要な官僚主義や無意味なプロセスこそが、現代のサプライチェーンにおいて最も一般的な問題であり、たとえ高いパフォーマンスを示しているように見える企業においても存在します。

1.7 Lokadから専任のプロジェクトマネージャーをクライアント企業本社に配置し、製品の専門家、ビジネスアナリスト、および技術インターフェースの専門家が同行する形で展開しますか？

はい、そのような規定がプロジェクトの契約条件に含まれている場合は実施します。 Lokadはクライアント企業本社に従業員を常駐させることに反対しているわけではありませんが、当然ながらその場合、プロジェクトのコストは増加します。ほとんどのプロジェクトはリモートで実施され、プロジェクトの規模に応じて月次または四半期ごとの訪問でサポートされます。この手法は、常にLokadの従業員をクライアントのオフィスに配置するよりも効率的であるとすべての関係者から認識されています。なお、たとえLokadがクライアント本社に常駐チームを配置することに同意したとしても、従業員は時間の経過とともにローテーションします。

このような手法はすべての関係者に利益をもたらします。なぜなら、LokadのSupply Chain Scientists (SCSs)は継続的なトレーニングプログラムを受けており、このプログラムは従業員が経験や年次に関係なく新たなスキルを習得し、既存のスキルを磨き続けるために重要だからです。多くのエンタープライズベンダーが従業員をリモートのクライアント先で数ヶ月、場合によっては数年にわたって運用させているのに対し、Lokadはこの手法が高品質なトレーニングプログラムの確実で効率的な提供とは両立しないと確信しています。

特に、LokadのSCSの最大の強みのひとつは、その非常に多様で広範なスキルセットにあります。各SCSは、専門家、ビジネスアナリスト、技術インターフェースの専門家、データサイエンティスト、サプライチェーンコンサルタントなど、複数の役割を果たすよう訓練されています。通常、これらの機能は複数の従業員によって遂行され、クライアントへのコスト増加を招きますが、Lokadでは各SCSがこれらすべてのサービスを提供します。

その結果、SCSは非常に生産性が高く（人数が少なければコミュニケーションの摩擦も減少します）、より高いパフォーマンスを発揮します。実際、サプライチェーンはエンドツーエンドの一貫性に大きく依存しており、これは少人数であれば容易に実現できます。

1.8 実装フェーズにおいて、どのような組織体制を提案しますか？リソースはどこに割り当てるべきでしょうか？

典型的なLokadのプロジェクトでは、クライアント企業が経験豊富なサプライチェーン実務者をプロジェクトのコーディネーターとして任命し、さらにサプライチェーンの責任者としてエグゼクティブを配置することを推奨します。コーディネーターは、LokadのSupply Chain Scientists (SCSs)とクライアント企業との連絡窓口となります。コーディネーターは、まず情報の要求を伝達し、その後フィードバックの要求を伝えます。同時に、LokadのSCSは、求められるサプライチェーンの意思決定を導くための数値レシピに取り組みます。

オンボーディングフェーズが完了するまで、プロジェクトの進捗をレビューするために週次ミーティングを推奨します。このミーティングには必ずコーディネーター、スーパーバイザー、およびクライアント側の主要なLokad SCSが参加します。他の参加者は必要に応じて参加できますが、実装またはオンボーディングフェーズ全体で継続的な参加は通常不要です。

プロジェクト開始直後に、データパイプラインのセットアップのためにいくつかのITリソースが割り当てられる必要があります。Lokadはこの点で、ほとんどの競合他社よりも効率的です。たとえば、クライアント側でのクリーニングや準備を必要とせずに、クライアントのトランザクションデータを自動的かつ直接抽出します。クライアント企業がベンダーロックインに陥っていない限り、この技術的セットアップは単一の担当者で4週間未満で完了し、場合によってはデータレイクが既に整備されている場合はさらに短期間で済みます。

次に、SCSは既存プロセスに関する質的インサイトおよびサプライチェーンの優先事項と制約の詳細を収集する必要があります。このプロセスをサポートするために、コーディネーターが主導する一連のインタビューが通常実施されます。その後、SCSが数値レシピを作成した段階で、これらのレシピが生成した数値をレビューし、SCSが精緻化・改善するための別の一連のインタビューが行われます。

スーパーバイザーの意見は、Lokadが企業の採用するハイレベルな戦略と整合性を取るため、また優柔不断によるプロジェクトの停滞を防ぐために重要です。たとえば、Lokadはサービス品質の欠如に伴うコストをモデル化するための様々なオプションを提案することができます。これらのオプションのメリットとデメリットを技術的でない言葉で説明できますが、最終的にはいくつかの戦略的選択が必要となります。

当然、上記のすべてはプロジェクトの具体的なニーズに依存します。クライアント企業の状況や目標により適した他の組織アプローチについても柔軟に対応可能です。

詳細については、Lokadは成功するサプライチェーン最適化の戦術的および戦略的実行に関するいくつかの講義を用意しています。

2. リソース管理と要件

2.1 クライアント企業でのプロジェクト実施に必要な人員要件、具体的にはリソースの数とその専門性は何ですか？プロジェクトの各フェーズおよびサブフェーズごとに、リソースの正確な人数を定義できますか？

典型的なLokadのプロジェクトでは、初期6ヶ月（オンボーディングフェーズ）において、クライアント企業から約0.5～2 FTE（フルタイム換算）のリソースが必要です。本稼働に移行すると、最低でも0.25 FTEが引き続き必要になると推定されます。当然、これらの見積もりはクライアント企業の規模、複雑性および特定のサプライチェーンニーズにより大きく変動します。

「典型的な」プロジェクトの各段階で必要なリソースについて、オンボーディングフェーズでは以下のとおりです：

• 1ヶ月目と2ヶ月目: データパイプラインのセットアップには、通常クライアントIT部門に所属するデータ担当者による4週間分のフルタイム作業が必要です。データ担当者はクライアント企業のアプリケーション環境に精通している必要があります。データレイクが既に整備されている場合、この要件は軽減されますが、逆に複数のビジネスシステム（例：国ごとのERP）が絡む場合は増加します。一度データパイプラインが稼働し始めると、その維持管理はデータ担当者による月数時間程度で済むはずです。

• 3ヶ月目と4ヶ月目: 数値レシピの設計には、プロジェクトコーディネーター（クライアント側）による週2～3日の作業、および各種サプライチェーン実務者による週最低10時間の高度なインサイト提供と、その後のLokadによる数値へのフィードバックが必要です。コーディネーターは企業やそのサプライチェーンに精通し、分析業務に慣れていることが期待されますが、この役割に専門的なITスキルや特定のデータサイエンススキルは求められません。また、プロジェクトの週次レビューにはサプライチェーン責任者による週半日の作業が必要です。

• 5ヶ月目と6ヶ月目: 要件自体は前フェーズと基本的に同じですが、焦点が変わります。コーディネーターは主に適切なロールアウトの準備と、影響を受けるすべてのサプライチェーン実務者とのコミュニケーションに時間を割くようになります。同様に、サプライチェーン責任者はLokadのプロジェクトから生じる新たなプロセスに関する内部チェンジマネジメントを監督します。

詳細はプロジェクト実装と管理 1.2も参照してください。

2.2 製品移行を支援するために十分な人員が計画されていることを保証しますか？

はい。一般的な目安として、Lokadはオンボーディングフェーズから本稼働フェーズへの移行時に、同じ量のリソース（例：同じSupply Chain Scientists）を維持することを推奨します。十分に維持管理され継続的に改善されるソリューションの投資対効果は非常に大きいです。一度設定して放置する考え方では、どんな技術ソリューションも適切に監視・維持されなければ必然的に、そして継続的に、時代遅れや陳腐化へと向かってしまいます。

なお、Lokadはサプライチェーンの意思決定を自動化しているため、クライアントの全サプライチェーン実務者を新たなプロセスに再訓練する緊急性は特にありません。自動化自体がその役割を果たすよう設計されているため、Lokadのプロジェクトによって引き起こされるサプライチェーン組織の完全刷新が、本稼働開始から数ヶ月で完了することは珍しくありません。

この効率化されたアプローチは、本稼働を実現するためにエンタープライズソフトウェアベンダーが求める大規模かつ高コストな「タスクフォース」とは大きく対照的です。

2.3 製品移行を支援するために、クライアント企業本社に十分な人員および知識プロダクト（KP）リソースが常駐していることを保証できますか？

はい、そのような規定と要件はプロジェクトの具体的かつ相互に合意された契約条件に含まれています。

詳細はプロジェクト実装と管理 1.7も参照してください。

詳細はリソース管理と要件 2.2も参照してください。

2.4 ビジネスプロダクトオーナーとともに要件レビューセッションを実施し、要件を引き出して文書化しますか？

はい。Supply Chain Scientistの初期目標の一つは、クライアントのサプライチェーンに関する必要なインサイトをすべて獲得することです。このプロセスは通常、ビジネスプロダクトオーナーを含む関連ステークホルダーへのインタビューを通じて実施されます。また、可能な場合は既存の文書を注意深く確認し、インタビューを最大限に活用できるよう努めています。

しかし、Lokadの最優先事項は、調査対象の「問題」を理解することであり、単に「要件」を列挙するだけでは十分にその理解が進まない場合があります。たとえば、クライアントが「スロームーバー」の特別な取り扱いを要求した場合、私たちは低ボリュームが対処すべき懸念であると理解します。しかし、これらのSKUを特別扱いするのは、この懸念に対処するための多くの選択肢の一つに過ぎません。

この例では、私たちは「スロームーバー」の真の性質を明らかにすることを優先します。実際、クライアントのサプライチェーンの課題を調査した結果、スロームーバーとは不適切な価格設定、バンドル、または割り当てが原因であるSKUである可能性が示されるかもしれません。一度問題（スロームーバー）がより深く理解されれば、介入戦略は全く異なるものとなり、対処が容易になることが多いです。

このように、Lokadはクライアントのすべての要件を引き出して文書化しますが、現状のサプライチェーンをそのまま受け入れるのではなく、問題の真の本質を発見することに重点を置いています。

問題と解決の二律背反についての詳細は、解決策ではなく問題に恋してをご参照ください。

2.5 システムインターフェースを含むカスタマイズが必要な機能について、作業量、コスト、スケジュールの見積もりを提供し、プロセスのフィットギャップ分析ワークショップ後にそれらを共有しますか？

はい。これらの見積もりは通常、初期の商業提案に含まれています。プロジェクト準備のためにワークショップが開催される場合、その情報をもとに提案をさらに精緻化します。

Lokadプラットフォームはプログラマブルであり、実装はサプライチェーンの予測最適化に特化した弊社DSL（ドメイン固有プログラミング言語）Envisionで記述されたスクリプトによってサポートされることを意図しています。その結果、Lokadは、人向けであろうとクライアント企業のビジネスシステム向けであろうと、カスタム機能やインターフェースの提供に非常に適しています。

ほとんどのエンタープライズソフトウェアとは異なり、プログラマビリティはLokadの中核機能です。前述のEnvisionスクリプトは、通常の意味でのLokadソリューションの「カスタマイズ」ではなく、また、これらのスクリプトが主要な開発ブランチから逸脱しているわけでもありません。むしろ、Lokadの豊富なプログラマビリティこそが、意図された実装経路なのです。

その結果、我々の見積もり（コスト、スケジュール等）には極めて高い確実性が伴います。ほとんどのプロジェクトはあらゆる面で初期見積もり／予算内に収まります。これは、費用のかかる遅延や契約条件の再検討が一般的なLokadの競合他社とは対照的です。

この点に関する詳細は、Lidlの5億ユーロSAP失敗事例のケーススタディをご参照ください。

2.6 契約期間中にサービスを提供する主要な人員を維持するための合理的な定着戦略を実施および維持しますか？また、Lokadの主要な人員ポジションごとに積極的な後継計画を維持しますか？

はい。私たちは従業員を平均3.5年間保持しており、これは北米や西欧などの類似市場における同様のグループ（ITの優秀なエンジニアやIT関連分野）の雇用期間のほぼ2倍に相当します。この職種は非常に競争が激しく、常に改善の余地はあるものの、結果としてLokadはほとんどの競合他社を大きく上回っています。その結果、Lokadのプロジェクトの多くは、前年から同じSupply Chain Scientists (SCSs)を継続して活用できるという恩恵を受けています。

この従業員の定着率は、競争力のある給与と、Lokadによるチーム育成への継続的な投資によるものです。特に、Lokadが自社ウェブサイトで公開しているサプライチェーン関連コンテンツ、特に一連のサプライチェーン講義は、Lokadが自社スタッフの育成に注力している結果としての副産物と見ることができます。一般に、公開のトレーニング資料を持たない企業向けソフトウェアベンダーは、非公開のトレーニング資料も持たないことがほとんどです（たとえその逆を主張したとしても）。

後継計画に関しては、私たちは2つの重要な実践を行っています。まず、すべてのLokadの取り組みにはJoint Procedure Manual (JPM)が付随しており、これは新しいSCSが取り組みの関連知見や技術的側面を迅速に把握するための主要な文書となっています。次に、各取り組みは常に主要なSCSと補助のSCSの両方を持っています。たとえ補助SCSが直接取り組みに貢献しなくても、必要が生じた際にこの人物が取り組みを引き継げるよう、Lokadは十分な時間を割いています。この実践により、予期せぬ休暇や離職に伴う複雑な問題が大幅に軽減されます。

3. Roles, Responsibilities & Stakeholder Management

3.1 クライアント企業との協力関係はどの程度ですか？

クライアントとの協力のレベルは様々ですが、全体としては通常の企業向けソフトウェアベンダーに期待される以上に高いものとなっています。サプライチェーンに関する関心はすべての企業で同じ重要性を持つわけではないため、サプライチェーンがその活動の（認識された）基盤となっている企業においては、協力関係がより強固になる傾向があります。

「パートナー」という用語は、些細なソフトウェア製品（例えばタイムトラッキングソフトなど）を提供する業者でさえも『パートナー』と呼ばれるほど希薄化しています。しかし、1、2年経過すると、ほとんどのクライアントはLokadとの関係を真の意味での『本物の』パートナーシップと捉えるようになります。彼らは信頼を勝ち取ったLokadの顔ぶれと接しており、その結果、通常はサプライチェーンサイエンティスト（SCS）がクライアントのビジネスに精通しています。さらに、我々の成果は多くの場合、CEOや取締役会に直接報告されるほど注目に値するものと評価されています。

Lokadとの継続的な協力により、クライアントは自社のサプライチェーン全体を積極的に再構築することが可能となります。最終的には、サプライチェーン全体が刷新され、クライアントとサプライヤーの双方に良い影響を与えます。なお、Lokadはクライアント企業内に存在する重要な戦略的専門知識を置き換える意図はありません。むしろ、サプライチェーンの意思決定プロセスにおける最も平凡で反復的な側面を自動化することにより、クライアントの貴重なリソースを有効活用できるようにすることを目指しています。

3.2 ソリューションの効果を最大化するために、クライアント企業内およびLokad内でどのような役割と責任体制を期待しますか？

Lokadの量的サプライチェーン取り組みには、通常4つの典型的な役割が関与しています。

• サプライチェーンリーダー： この役割は、量的サプライチェーン取り組みにおけるトップマネジメントの関与の重要性を強調します。技術的な詳細に深入りすることは期待されませんが、取り組みの戦略的な洞察を理解し伝達することが求められます。彼らの役割は、指標やKPIを作成することではなく、それらを批判的に評価し、挑戦して全体戦略との整合性を確保することです。

• サプライチェーンコーディネーター： 取り組みを円滑に運営するために不可欠な役割であり、様々な内部チーム間の橋渡しを行います。主な責任は、フィードバックの収集、ステークホルダーとの連絡、プロセスや決定事項の確認および明確化です。既存の社内ワークフローと取り組みが整合するよう努め、将来的なワークフローの見直しにも柔軟に対応します。

• データオフィサー： データは量的サプライチェーン取り組みの根幹であり、この人物はデータのアクセス性と信頼性を確保します。販売や購買履歴など包括的なデータセットの抽出を任され、自動化とスケジュール管理を担当します。初期段階での役割が特に重要ですが、その貢献は取り組みの成功に不可欠です。

• サプライチェーンサイエンティスト： この役割は、サプライチェーンコーディネーターの洞察とデータオフィサーのデータを組み合わせ、意思決定プロセスを自動化します。データ準備から始まり、データの不明点を明確にするためにコーディネーターと密接に連携します。その後、再発注量など具体的な意思決定に向けて戦略を具体化し、透明性と管理のためにダッシュボードやKPIを実装します。

量的サプライチェーン取り組みにおける各役割の詳細については、project rolesを参照してください。

3.3 実装フェーズおよび本稼働フェーズのための完全なRACI（責任、説明責任、相談、通知）表はありますか？

はい。必要と判断される場合、クライアント企業の要望に応じて、この情報は明示的なRACI表として提示することができます。

さらに重要なことに、サプライチェーンサイエンティスト（SCS）は、この種のマトリックスを内在化し、取り組みの進行に合わせて迅速かつ適切な判断を下すために活用しています。サプライチェーンの最適化に関する問題では、問題をどう定義するかが肝心であり、その後、組織内で誰が最も適切に対応できるかに焦点が移ります。いずれにしても、このすべての分析は取り組みの勢いを保つために迅速に行われなければなりません。

そのため、LokadのSCSは取り組みの先頭に立ち、Lokadの数値アルゴリズムによって生成された成果の品質に対して責任を持つよう任されています。

このように、Lokadが生成するサプライチェーンの意思決定は、多数のステークホルダー間で責任を分割する複雑な「システム」や「プロセス」ではなく、少数の高度に訓練された専門家集団によって担われます。Lokadは、そのようなシステムが責任を希薄化させる傾向にあると考えています。したがって、我々のSCSはこの責任を担い遂行するよう訓練されており、クライアント企業の関係するステークホルダーが十分に相談され、情報が共有されることを保証します。

3.4 プロジェクトに関与するすべてのステークホルダーのために、RACI（責任、説明責任、相談、通知）マトリックスを用いて役割と責任を文書化しますか？また、この文書が関係者全員で議論され、合意されることを保証しますか？

はい。これらの要素（その他も含む）はすべて、Joint Procedure Manual (JPM)にまとめられ文書化されています。JPMは、クライアント企業から直接収集した洞察をもとに、Lokadのサプライチェーンサイエンティスト（SCS）によって作成されます。この文書には、各人の役割と責任の詳細なパラメータが記載されています。

JPMは、取り組みの継続的なリソースとして機能し、クライアント企業に配置されたSCSによって執筆されます。彼ら自身の言葉でこの文書を作成することで、SCSがクライアントのサプライチェーンおよび包括的なソリューションについて、既存の文献を単に繰り返すのではなく、十分な調査、診断、分析を行ったことが示されます。

JPMに対するいかなる改訂もクライアント企業と共有され、JPM自体はLokadとクライアント企業との作業セッション中に定期的に議論されます。

関連する点として、経験上、もし意見の不一致が生じた場合、それは通常、クライアント企業内で解決すべき組織的な問題を反映しています。これが理由で、クライアント企業には取り組みを監督するサプライチェーンエグゼクティブの任命を推奨しています。彼らの主な貢献の一つは、そのような場合に仲介役を果たすことです。

3.5 プロジェクト作業グループおよびステアリンググループが、プロジェクトのステークホルダーから指名されたメンバーで構成されることを保証しますか？また、運営リズムがすべての関係者で合意されることを保証しますか？

はい。一般原則として、クライアント企業と正式に合意した必要なプロセスには従います。合意された要素（および取り組みの進行に合わせた変更）は、プロジェクト作業グループとステアリンググループの詳細を含むJoint Procedure Manual (JPM)に文書化されます。LokadのSCSを通じて、これらのプロセスの導入と監視に必要なリソースが確保されています。

逸話的に言えば、Lokadが最も高く評価される貢献の一つは、サプライチェーンまたは官僚的なプロセスを問わず、プロセスをシンプル化する能力です。時間の経過とともに、クライアントのサプライチェーンから余分な官僚的層を積極的に取り除くよう努めています。

4. System Transition & Go-Live

4.1 キックオフから本稼働までの移行期間はどのくらいですか？

オンボーディングフェーズの典型的な期間は6ヶ月です。このフェーズはキックオフから始まり、Lokadが「本稼働」状態、すなわち自動化されたサプライチェーン推奨がクライアントの意思決定プロセスを効果的に導く段階で終了します。

すでにdata lakeが整備されている場合、この期間は1ヶ月短縮される可能性があります―しっかりと構築され文書化されたデータレイクはオンボーディングフェーズをさらに短縮することができます。逆に、クライアントのソフトウェアやシステム環境が過度に複雑または旧式の場合、このフェーズは通常1～3ヶ月延長されます。

興味深いことに、サプライチェーン自体の複雑さは、それが意外にも想定されるほど影響を及ぼしません。Lokadは意図された期間内に実現可能な、十分に明確なスコープを定義するよう努めているからです。私たちの経験では、6ヶ月以上続くオンボーディングフェーズは、取り組みが停滞するリスクを伴います。したがって、このリスクを軽減するために、スコープの設計を積極的に行っています。

このような遅延は、Lokad自体の技術的なセットアップとほとんど関係がありません。全体として、提案されたタイムラインはデータ抽出の自動化や数値アルゴリズムのテストなどの技術的目的だけでなく、LokadのSCSがクライアント企業の細部にまで精通し、サプライチェーンチームがLokadのアプローチを「理解」するための時間も提供するものです―これは通常、クライアントの従来のプロセスからの逸脱を意味します。

4.2 現地訪問は何回計画していますか？また、現地でのワークショップは何回を予定していますか？

現地訪問とワークショップの回数は、クライアント企業との具体的な契約条件の一部として交渉されますが、旅費がLokadの料金に影響を与える可能性があることに留意する必要があります。したがって、現地訪問の有無は最終的にはクライアント企業が決定し、Lokadは希望する頻度に対応します。

クライアント企業の目的が取り組みをできるだけ効率化することである場合、完全リモートでの取り組み、すなわち現地訪問なしでも十分対応可能です。このアプローチは、年間売上が1億米ドル未満の小規模企業や、リモートでの参加に慣れている企業（例：大手eコマース企業）に推奨されます。Lokadが実施する取り組みのおよそ半数がこのカテゴリに該当します。

クライアント企業の目的が変革の成功率を最大化することである場合、私たちは月に一度、必要に応じてさらに頻繁な現地訪問で対応することに前向きです。大企業（年間売上が10億米ドル以上）には、少なくとも四半期に一度の現地訪問またはワークショップを推奨します。このアプローチは、特に大規模なチームが関与する場合に、全社的な整合性の確立に役立ちます。

西ヨーロッパのクライアントの場合、現地では通常、1日程度の現地訪問がワークショップより多く行われる傾向があります。一方、西ヨーロッパ以外のクライアントには、現地訪問よりも複数日に及ぶワークショップが多くなる傾向があります。これは、旅費や物流の問題による単純な違いです。

4.3 リモートと現地での会議の理想的なバランスは何ですか？

量的サプライチェーン取り組みにおいては、会議の大部分がリモートで行われるべきです。ほとんどの会議は短時間（30分以内）で、参加者はLokadのサプライチェーンサイエンティストとクライアント企業のサプライチェーン実務者という2名のみです。さらに、リモート会議では各参加者が大画面モニターを含む自前のコンピュータ環境にアクセスできるため、特定の技術的タスクに有益です。特に、複雑なレポートの調査が必要な場合に役立ちます。

しかし、Lokadはクライアントとの現地会議の価値を過小評価していません。現地での会議は、複雑なアイデアの伝達、視点の議論、および双方の期待の再調整を容易にします。したがって、現地会議は定期的なリズム（例：毎週、毎月、四半期ごと…）で実施することを推奨します。特に、Lokadがクライアントを招く場合、これらの現地会議は重要なイベントと位置付けられます。

このアプローチにより、両者はリモート会議を控えめで便利、かつ必要な頻度で開催することが可能となります。

4.4 インターフェースの設定を含め、本稼働準備状況を評価するために、クライアント企業の生産環境に対する品質チェックを支援しますか？

はい。実際、Lokadは本稼働のための準備評価を支援するだけでなく、その範囲を超えています。Lokadのサプライチェーンサイエンティスト（SCS）の主要な責任のひとつは、クライアント企業に提供するエンドツーエンドのソリューションの品質を管理することにあります。つまり、機械化されたシステム（多数の機械）が結果を生成していても、そのシステムに対して個人が責任を持つのです。彼らは、エンドツーエンドのデータ処理パイプラインの正確性、関連性、適切性を確保し、クライアント全体の事業上の懸念も考慮に入れます。

エラーが発生しやすい性質を持つソフトウェアインターフェースには特別な注意が必要であり、SCSはその整合性の評価に十分な能力を備えています。Lokadは、この整合性をイングレス側（クライアント企業から履歴データを受け取る際）とエグレス側（クライアント企業にサプライチェーンの意思決定を返す際）で評価します。このタスクには、特定の手法と技術が活用されています。

Lokadが本稼働準備を確実にするために利用する技術の種類については、プログラミング paradigms for supply chainをご参照ください。

4.5 クライアント企業における事業運営の円滑な移行（既存の業務アプリケーションから新たな業務アプリケーションへの移行）を管理するために、プロダクション移行およびマイグレーション戦略文書を作成しますか？

はい。移行は当社の共同手順マニュアル (JPM) に記載されています。この詳細な文書は、Lokad のサプライチェーン・サイエンティスト (SCS) により作成され、サプライチェーン担当者およびサプライチェーン管理者の両者が、理解しやすい言葉でプロセスを十分に説明した優れた資料にアクセスできるようにしています。SCS は、（一部の付属資料はかなり技術的であることがあるものの）この文書が非技術者にも理解可能となるよう注力しています。

また、Lokad のデュアルラン手法は、レガシープロセスから新ソリューションへの円滑な移行を確実にするために独自の適合性を有しています。「デュアルラン」とは、Lokad がイニシアチブの全範囲にわたってレガシーの意思決定プロセスと並行して運用される手法を意味します。この手法は、Lokad によるレガシー意思決定プロセスが自動化されているおかげでのみ実現可能であり、SCS によって実装された数値レシピが実際の運用条件下で十分な期間にわたり動作することを事前に確認し、Lokad の意思決定がレガシープロセスを上回る状況であることを保証します。

このようなデュアルランは、通常、競合他社が提案する代替技術や手法では実現不可能であることに留意する必要があります。実際、彼らはサプライチェーンの意思決定を自動化していないため、デュアルランに伴うオーバーヘッドが大きくなります。その結果、デュアルランはせいぜい限られた範囲で実施され、実際の運用環境を十分に反映できないものとなります。その結果、このようなアプローチが採用されると、範囲の後からの拡大が、完全な範囲でのデュアルランによって完全に予防可能であった生産上のインシデントを必然的に引き起こすことになります。

4.6 クライアント企業によるレビューと承認のため、パイロットランの範囲、タイムライン、および成功基準を提供しますか？

はい。範囲は常に Lokad とクライアント企業との契約書に詳細に記載されています。通常、これは特定のタイプのサプライチェーンの意思決定（例えば、在庫補充もしくは在庫配分）を、所定のロケーションおよび/または事業システムに対して実施する形をとります。

タイムラインは通常、6ヶ月以内（キックオフから実運用まで）です。予測されたタイムラインは常に当社の商業提案に含まれていますが、契約書に明記されていない場合もあります。この拘束力のあるタイムラインは双方の約束を表し、Lokad イニシアチブの進行速度は、特にデータパイプラインの構築など、クライアント企業による特定のステップがタイムリーに実行されることに依存します.

成功基準に関しては、その決定は常にクライアント企業によって一方的に行われます。当社はこの決定を支える指針を文書化することができますが、一方的でない決定は異例です。要するに、クライアントがそう考えない場合に、ベンダーがパイロットの成功を決定する立場にあるべきではありません.

詳細は Project Implementation & Management 1.2 もご覧ください.

この微妙な点については、定量的供給チェーンの成功の評価 をご参照ください.

4.7 パイロットランの実施を組織し、a) データの適合性、b) システム構成およびアプリケーションの準備状況、c) プロセス/システムの準拠、d) 全体の目的適合性を確保しますか？

はい。経験則として、パイロットは、サプライチェーン最適化を提供することを目的としている場合であっても、実際に生産に移行する『本当の』イニシアチブと同様に扱います。あらゆる意味において、サプライチェーン最適化に関しては、適切なパイロットは生産利用が承認されたプリプロダクション環境と区別がつかないほどです.

Lokad のサプライチェーン・サイエンティスト (SCS) チームが、上記すべての項目を担当します。私たちの経験では、デジタル化が既に何年（場合によっては数十年）も前に進んでいる企業では、データの適合性はほとんど問題になりません。購入、生産、在庫、および販売が記録されるビジネスシステムがあれば、イニシアチブはほぼ確実に十分なデータを持つといえます。課題は、もともとサプライチェーンの最適化を支援するために収集されなかったデータの意味を理解することにあります.

この点に関する詳細は bad data をご覧ください.

5. 変更とリスク管理

5.1 イニシアチブの実施に伴う変更管理を支援するために、クライアント企業にはどのようなサポートを提供しますか？

すべてのクライアントは、Lokad のサプライチェーン・サイエンティスト (SCS) の全面的なコミットメントを受けており、彼らはサプライチェーン最適化イニシアチブにおける技術的および非技術的要求事項に対処するための訓練を受けています。SCS は次のようなさまざまな方法で変更管理プロセスを支援します：

• クライアント企業が雇用するサプライチェーン担当者に対して、既存プロセスの改善を提案する。

• クライアント企業のメンバー／チームのオンボーディング用にトレーニング資料を作成する。

• サプライチェーンにもたらされる変更の影響を、ドルまたはユーロ（あるいはクライアントが選択する通貨）で定量化することにより、サプライチェーン管理を支援する.

変更管理は、SCS にとってかなりの時間的コミットメントを要する可能性があることに留意する必要があります。それぞれの SCS は、サプライチェーンのリーダーシップが変更管理を行う際に適した独自のスキルと経験を有していますが、この任務は他のすべての業務と競合します.

したがって、Lokad と各クライアントとの間で交渉された契約条件には、イニシアチブを支援するために利用可能なリソースの量、すなわち SCS チームの規模が明記されています。当社の商業提案では通常、SCS が一定の変更管理サポートを提供することを想定しています。しかし、クライアントから明示的に要請されない限り、当社の提案には通常、「大規模な」変更管理サポートは含まれていません.

5.2 プロダクションフェーズにおいて、変更管理に関してどのようなビジョンをお持ちですか？主なマイルストーンは何ですか？新しいソリューションが成功裏に実装された後、新組織はどのような姿になるのでしょうか？

Lokad がプロダクションに入ると、サプライチェーンの意思決定の一部が自動化されます。その目的は、サプライチェーンの実務を資本主義的な事業へと転換することにあります。サプライチェーン担当者が費やす一時間ごとに、数値レシピの継続的な改善に貢献する必要があります。これは、ある日の大部分の努力が会社をもう一日営業するために割かれるという「主流」のサプライチェーン実務とは一線を画しています。もちろん、こうした付加価値のあるサプライチェーンへの移行は段階的に進行します.

• 最初のマイルストーン は、サプライチェーン担当者に、Lokad がレガシープロセスの大部分を廃棄できることを認識させることです。例えば、日々の補充数量が頻繁に誤っている場合は、見直すことに意味があります。しかし、設計上、Lokad の数量はすでに正確であり、再検討の必要はありません。実際、Lokad が生成する数値に不合理な部分が 0% であることが、プロダクション稼働の主要な基準となっています。サプライチェーン担当者が Lokad の数値に寄せる信頼は、当然、多くの時間を有効活用する余裕を生み出します.

• 第二のマイルストーン は、サプライチェーン担当者の中から数名の「早期導入者」を確保することです。これらは、例えば手動で数値をチェックするなど、価値を生まないレガシープロセスから迅速に脱却し、数値レシピを通じたサプライチェーンの継続的改善に専念できる人々です。彼らは、些細な技術的側面を超えて、多くの重要な課題（例：クライアント企業がサービスの質を適切な視点で評価しているかどうか）に取り組み始めることができます.

• 第三のマイルストーン は、大多数のサプライチェーン担当者が内部ではなく外部（顧客やサプライヤー）に目を向けるようになることです。最終的に、サプライチェーンはクライアント企業の境界を超えた整合性をもたらさなければなりません。これにより、収集された知見のプールが拡大し、数値レシピのさらなる洗練に寄与します.

新しい組織はソフトウェア企業に非常に近いものとなります。反復的なサプライチェーン作業は手作業で処理されることがほとんどなく（反復作業が自動化されているため）、緊急事態も大幅に減少します。日常業務の削減は、サプライチェーン担当者にとって作業の多様性を増加させる結果となります。通常、これはサプライチェーンの管理に充てる時間と労力が減少する一方で、余剰となった時間と労力を活かすために、従業員のスキル向上を経営陣に求めることにつながります.

この移行の詳細については、(Software) Product-oriented Delivery for Supply Chain を参照してください.

5.3 エンドユーザー向けのワークフロー変更をどのように扱いますか？まず、Lokad のオンボーディング時、次に Lokad 自身の進化においてです.

設計上、Lokad によって生成されるサプライチェーンの意思決定にはワークフローは不要です。実際、サプライチェーンの意思決定を生成するすべてのステップを自動化することが望ましい配置となっています.

しかし、クライアントから明示的に要請があれば、Lokad はレガシーのものと同様の「ワークフロー」を導入することが可能です。これは、あくまでも変更管理を容易にするためであり、数値レシピの成功に必須な要件ではありません。クライアントの従業員が Lokad の生成する意思決定に慣れ、信頼を深めるにつれて、「ワークフロー」は徐々に簡素化され、最終的には完全に削除されます.

Lokad の進化に関しては、当社のプラットフォームはプログラム的であり、Envision（当社のドメイン固有プログラミング言語）によって管理されています。Envision の変更やアップデートは自動化されたスクリプトにより行われ、このプロセスは Lokad がホストするサプライチェーンイニシアチブに影響を与えないようにプログラムされています.

5.4 緩和計画、タスク、責任、タイムライン、およびステータス（未着手、進行中、完了、保留）を含む課題およびリスク登録簿を維持できますか？また、Lokad のプロジェクトマネージャーが、すべての課題およびリスクの追跡、迅速な解決の確保、または必要に応じたエスカレーションの管理を担当しますか？

はい。Lokad のプラットフォームには、独自の内部イシュー／チケット／タスクマネージャーが備わっています。この機能は、ステータス、優先順位、割り当て、通知など、一般的に期待されるすべての機能を提供します。さらに、私たちはイニシアチブの全体像と関連する高レベルのタイムラインを包括的かつ整理された形で提示する共同手順マニュアル (JPM) を別途管理しています。Lokad のサプライチェーン・サイエンティスト (SCS) がタスクマネージャーの監督を担当し、課題や懸念が迅速に対処されるようにしています.

エスカレーションは可能ですが、まれです。同じ SCS がタスクの管理・レビューを行い、それを解決します。Lokad の上級 SCS は、サプライチェーンの専門家、データエンジニア、データインテグレーター、ビジネスアナリスト、データサイエンティスト、プロジェクトマネージャー、チェンジコンサルタントなど、幅広い役割を担っています.

SCS に容易に連絡できる点は、我々のクライアントがしばしば大きなメリットとして挙げる点です。クライアントは、複数の官僚的な階層を経由して（おそらく）助けてくれる人物と話をするのではなく、即座に課題の満足な解決を監督する担当者と直接やり取りできます.

もし、SCS の専門領域外のスキルを要する問題（例：プラットフォームのアーキテクチャに関する技術的な問題）が発生した場合でも、SCS は問題の迅速な解決を監督し、該当クライアントの最初の窓口として機能します.

5.5 事業プロセスの導入および変更、ならびに既存プロセスの廃止に対応するための、組織変更管理コンサルティングを提供しますか？

はい、クライアント企業が Lokad とのパートナーシップに変更管理コンサルティングサービスを含めることを希望する場合は提供します。ただし、Lokad の主要な専門知識はサプライチェーンの予測最適化にあり、変更管理ではないことに留意する必要があります。当社の変更管理アプローチは、サプライチェーン実務よりも従来型のものとなっています。このアプローチを採用すれば、プロジェクトに関与する第三者の数を制限することが可能です.

もしくは、クライアント企業が Lokad を補完するために変更管理の専門家のサービスを維持することを好む場合、クライアント企業が適切と判断する範囲でサポートいたします.

6. カスタマイズおよびシステム機能

6.1 カスタマイズ要件の優先順位を決定するためのセッションを実施し、製品のギャップによるビジネスへの影響を理解し、カスタマイズのリリース優先順位について相互合意に達しますか？

はい。Lokad のサプライチェーン・サイエンティスト (SCS) がこのプロセスを担当しています。実際、この優先順位付けに関して、Lokad は二つの点で際立っています. 第一に、SCS はカスタマイズを独自に実装する能力があり、そのため、リソースおよびタイムラインの観点から何が問題となるのかについて明確な洞察を提供できます.

これにより、クライアント企業は、特定のサプライチェーン変更の利益とそれに付随するコストとを容易に比較検討できる専門家の恩恵を受けるため、優先順位付けの質が大幅に向上します.

第二に、「定量的供給チェーン」―これは Lokad の包括的な哲学です―は、純粋に財務的な視点を強調しています。したがって、SCS は、ソリューションに導入される可能性のある変更の影響を、（ドルまたはユーロで）定量的に見積もる点でクライアント企業を支援します。この戦略は、何を優先すべきかについての従来の議論によるボトルネックを回避することで、イニシアチブを洗練させます。代わりに、Lokad は、最も大きな財務的影響をもたらす課題を優先することで、このプロセスを合理化します.

6.2 すべてのビジネスプロセスのフィットギャップ調査を実施し、自動化の機会を特定し、望ましい将来のプロセスを文書化し、製品機能のギャップを明らかにできますか？また、製品機能のギャップが特定された場合に、許容可能な代替策を提案できますか？

はい。Lokad のサプライチェーン・サイエンティスト (SCS) がこのプロセスを担当しています。イニシアチブの開始時に初期調査が実施されますが、このプロセスはプロダクションフェーズ全体にわたって継続的に行われます。これは、ソリューションの継続的改善を追求する我々のアプローチの一環です.

サプライチェーン最適化に関して言えば、ギャップは「機能性」の問題ではなく「パフォーマンス」の問題であることがほとんどです。例えば、課題は補充数量を生成する（機能性）だけでなく、生成された数量が最も利益をもたらすものであることを保証する（パフォーマンス）ことにあります。

したがって、SCSは「パフォーマンスギャップ」を特定し対処することに注力しており、場合によっては追加機能の導入やソリューションの再設計が必要になることもあります。これには、全体的なパフォーマンスを最適化するために、機能を追加_または_削除することが含まれる場合があります。

関連して、Lokadのプラットフォームはプログラム可能です。したがって、認識される「機能性のギャップ」も、数行のEnvision codeを導入（または微調整）することで対処することができます。このプログラム可能性こそが、Lokadが各顧客に合わせたテーラーメイドのソリューションを提供できる理由です。

6.3 ワークショップ開始の少なくとも1週間前に、プロセスフィット・ギャップ分析ワークショップの詳細なアジェンダおよび顧客側のSME（主題専門家）の期待内容を提供できますか？

はい。Lokadのサプライチェーンサイエンティスト（SCS）は各ワークショップのアジェンダを提供します。イベントの少なくとも1週間前にアジェンダが通知されることを保証します。もし顧客企業からアジェンダの提出期限など明確な指示がある場合はそれに従い、指示がない場合は、顧客側で必要なすべてのステップを含むタイムラインを賢明かつプロフェッショナルな方法で構成します。

6.4 製品カスタマイズ要件のドキュメントが、顧客企業と共同でレビューおよび承認されることを保証しますか？

はい、これらのドキュメントは顧客企業に提供され、その後承認されます。

なお、Lokadのプラットフォーム設計の選択は、『カスタマイズ』の必要性を大幅に排除していることにご留意ください。少なくともエンタープライズソフトウェア業界で一般的に理解される意味でのカスタマイズは不要です。Lokadのプラットフォームはプログラム可能であり、サプライチェーンの予測最適化に特化したDSL（ドメイン固有プログラミング言語）であるEnvisionを活用しています。

したがって、Lokadのソリューションは常に、顧客企業の特定のニーズに完全に合わせた意味で「カスタマイズ」されています。しかし、そのカスタマイズは、ソリューションがLokadの主要製品ラインの一部として維持される方法で提供されます。これがLokadの好む（そして意図的に設計された）アプローチであり、保守性の問題を引き起こすことはありません。

6.5 顧客企業が外部システムとのインターフェース接続を確立し、それらのテストおよび認証を行う際に支援しますか？

はい。Lokadのサプライチェーンサイエンティスト（SCS）は、顧客企業が運用するシステムとLokadとの間のインターフェースの設定、テスト、検証、および文書化の支援を行います。ネットワーキングやセキュリティプロトコルなど、低レベルの技術的側面に対しては、Lokad内のITリソースが補完する場合もあります。

システムのインターフェースは通常、第三者の認証機関によって「認証」されることはありません。インターフェースは、顧客企業のIT部門とLokadとの間で共同で合意された技術仕様によって「正式に定義」されます。この技術仕様は両社の相互の義務を支えるものであり、すなわち、顧客企業は必要なデータを期限内にLokadに提供し、Lokadは結果を期限内に返すことを約束します。

6.6 ワークショップ中に、サンプルメッセージを含むインターフェース仕様書を提供しますか？

はい、Lokadはワークショップ中にインターフェース仕様書を提供します。サンプルメッセージは、顧客企業の希望に応じて含めることができます。

ただし、Lokadのサービスの性質上、「サンプルメッセージ」は、顧客に提供される出力をより正確に表現するテーブルの形をとる可能性が非常に高いです。参考までに、インターフェースの技術仕様の大部分は、テーブルおよびそのフォーマット、テーブル抽出パターン、転送スケジュールに焦点を当てています。

6.7 変更要求およびリリース管理プロセスを共有しますか？

はい。Lokadのサプライチェーンサイエンティスト（SCS）がこのプロセスを担当します。なお、Lokadには通常のエンタープライズソフトウェアとは異なる、2つのレベルの変更とリリースが存在することに留意してください。

第一に、顧客専用に行われる変更はSCS自らによって実施されます。これらの変更は、特にオンボーディングフェーズ中に1日に複数回行われるほど頻繁に発生し、顧客企業のニーズに直接応えるため、双方の間で大いにコミュニケーションが取られます。

第二に、Lokadのプラットフォームは、通常、サプライチェーンの予測最適化に特化したDSLであるEnvisionの更新を通じてアップデートされます。これらの変更は顧客企業にとって透明性を持たせるよう設計されており、必要に応じて詳細が提供され、その多くが公開されています。

Lokadのプラットフォームの進化については、Envision VM Environment and General Architectureを参照してください。

7. ユーザー受け入れテスト (UAT)

7.1 コンテキスト固有のデータとシステム構成を用いたUAT（ユーザー受け入れテスト）環境の設定において、顧客企業を支援しますか？

はい。Lokadのサプライチェーンサイエンティスト（SCS）がこのプロセスを担当します。Lokadはこの支援のために、独自の方法論と技術革新を提供しています。

方法論の観点では、当社は、項目を企業の投資収益率（ROI）の降順にランク付けする優先順位リストの設計を好みます。この点は、エンドユーザーが膨大でほとんど無関係なデータをレビューするために時間を無駄にしないようにするために非常に重要です。

技術面では、Lokadのプラットフォームは、任意のイニシアチブに対して複数の環境を同時にサポートするように特別に設計されています。これらの環境は当社のマルチテナントSaaSプラットフォームの標準機能であり、計算リソースおよびシステム管理時間の両面で最小限のオーバーヘッドで導入することができます。

また、User Acceptance Testing 7.3も参照してください。

7.2 定義されたToBeプロセスに従い、UAT（ユーザー受け入れテスト）のプレプロダクション、本番、およびトレーニング環境を構成しますか？

はい。Lokadのプラットフォームが高度なプログラム可能性を有しているため、構成を完全に制御することが可能です。これは、サプライチェーンの予測最適化に特化したDSLであるEnvisionによって実現されています。

このアプローチにより、変更の対象とならない全ての部分で可能な限り同じコードを使用し、異なる環境で同一の構成を利用することができます。これにより、環境間で意図せず生じる違いが大幅に減少し、ユーザーの混乱やUATプロセスの整合性の損失を防ぎます。

さらに、当社の設計により、あるステージから次のステージへのセットアップの移行が容易になります。構成変更にコードベースを使用する方法は、従来のユーザーインターフェース方式よりも効率的です。

7.3 製品（必要なインターフェースを含む）のために、顧客企業および外部システム向けに、個別のUAT（ユーザー受け入れテスト）、データ移行、本番前（プレプロダクション）、本番、トレーニング環境を提供しますか？

はい。Lokadのプラットフォームは、任意のイニシアチブに対して複数の環境を同時にサポートするように特別に設計されています。これらの環境は当社のマルチテナントSaaSプラットフォームの標準機能であり、計算リソースおよびシステム管理時間の両面で最小限のオーバーヘッドで導入することができます。

Lokadでは、本番データを含む全生産環境の複製を、データストレージの使用量を倍増させることなく実現します。内部的には、両環境間で同一のデータは共有されます。さらに、当社の一定時間設計により、ある環境のワークロードが別の環境のパフォーマンスに悪影響を及ぼすことはありません。

しかしながら、ほとんどのエンタープライズソフトウェアベンダーは、主要なセットアップを単に「クローン」することでこの問題を回避しています。クローン、すなわち単純な複製は容易ですが非効率的です。クローン化は、環境の数に応じてリソース（人員および機器）の使用量が線形に増加することを意味し、例えば3つの環境では元のコストが3倍になります。規模の大きなサプライチェーンでは、これが相当な費用に直結します。

7.4 UAT（ユーザー受け入れテスト）が相互に合意されたタイムライン内に完了するよう、すべての欠陥の迅速な解決を保証しますか？

はい、「解決」および「欠陥」の詳細な定義について合意が得られることを条件とします。全体として、Lokadのサプライチェーンサイエンティスト（SCS）が、イニシアチブの核心目標である投資収益率の向上を損なうすべての問題の解決を担当します。一般的なシナリオでは、SCSが適切な対応策とそれに対応するタイムラインを提案し、顧客企業がそれを検証または更新します。

サプライチェーンに関しては、_完璧なソリューション_は存在せず、ただより良いまたは悪い_トレードオフ_が存在することを強調することが重要です。言い換えれば、2つ以上の価値が完全に対立している問題は本質的に解決できません。

例えば、消費期限切れの生鮮在庫は無駄ですが、生鮮製品を扱う場合、その無駄を完全に排除すると、結果として_サービス品質_の問題が生じます。死蔵在庫と品切れの間でバランスを見つける必要がありますが、どちらもある意味で欠陥といえます。

要するに、SCSはファイル読み込み時のパーシングエラー（ソフトウェアバグ）の修正など、発生する「些細な」問題を解決できます。しかし、定量的サプライチェーンソリューションの究極の目標は「問題解決」ではなく、投資収益率（ドルまたはユーロ）の向上にあります。Lokadは、サプライチェーンのトレードオフに対して知的かつ財務的に駆動されたアプローチを通じて、このような形の「解決」を達成します。

7.5 UAT（ユーザー受け入れテスト）のシナリオ、テストケース、およびテストデータのレビューにおいて、顧客企業を支援しますか？

はい。Lokadのサプライチェーンサイエンティスト（SCS）がこのプロセスを担当します。

しかし、サプライチェーン最適化に関しては、生産環境全体より小さいデータセットでは通常十分ではありません。実際、エンドツーエンドのサプライチェーン視点を反映するためには、シナリオ、テストケース、およびテストデータはほぼ生産環境と同規模である必要があります。この要件はLokad固有のものではなく、サプライチェーンの本質によるものです。

7.6 UAT（ユーザー受け入れテスト）フェーズ中に、顧客企業本社でのオンサイトサポートを保証しますか？

はい。オンサイトサポートは、Lokadと顧客企業との間の契約に基づいており、この点は常に顧客ごとに交渉されます。

なお、Lokadとの定量的サプライチェーンイニシアチブは継続的なサプライチェーン改善を特徴としているため、固定のUAT期間は存在しません。テストは通常、2か月目の終わりに開始され、4か月目にピークを迎え、6か月目以降に安定します。

数値的レシピ（サプライチェーン最適化に特化するアルゴリズム）の洗練に継続的なリソースを充てることで、Lokadは各顧客が最新のイニシアチブを維持できるようにしています。

また、Project Implementation & Management 1.7も参照してください。

8. 導入後サポート＆監査

8.1 パイロット実施での観察事項が文書化され、必要なアクション項目が顧客企業の技術、IT、サプライヤー部門にまたがる関係者に割り当てられ、その後完了まで追跡されることを保証できますか？

はい。Lokadのサプライチェーンサイエンティスト（SCS）は、各イニシアチブのために共同手順マニュアル（JPM）を作成・維持します。これには、イニシアチブに関するすべての重要な洞察が含まれており、特に、一部のセクションや付録が非常に技術的であるにもかかわらず、非技術者にもアクセス可能なように設計されています。

主要なアクション項目はJPMに文書化されます。しかし、些細なアクション項目は通常、Lokadのプラットフォーム上のタスクマネージャーで処理されます。これらの些細な項目は短命であり、タスクマネージャーはJPMよりも効果的に追跡および完了させるのに役立ちます。

8.2 システムの使用状況および採用状況を監視するために、十分な品質およびコンプライアンス報告書が利用可能であることを保証できますか？

はい。Lokadのサプライチェーンサイエンティスト（SCS）は、通常、正式なキックオフ直前のオンボーディング最終段階で、この目的のための専用計測手法を実装します。

さらに、Lokadは生成するサプライチェーン上の意思決定と実際の意思決定との整合性を追跡することができます。これは、Lokadの推奨事項の実装に影響を及ぼす可能性のある、顧客システム内のバグや不具合などの潜在的な乖離要因を特定するために行われます。

8.3 アプリケーションの年間監査を実施し、システムの利用およびエンドユーザーによる採用を改善するためのフィードバックを提供し、より迅速にROI（投資収益率）を実現しますか？

はい、エンドツーエンドの全ソリューションの年間監査は標準的な運用手順です。とはいえ、Lokadのサプライチェーンサイエンティスト（SCS）は、通常、年内に複数回全体の監査を行います。年間監査は通常、顧客の経営陣への詳細なロードマップの提示につながり、これは各イニシアチブに対する当社の_継続的改善_のアプローチに沿ったものです。

使用状況に関しては、実際、SCSが早期に専用ツールを積極的に実装し、Lokadが生成するサプライチェーンの意思決定への利用、採用、およびコンプライアンスを監視します。年間監査は必要な調整を行う優れた機会を提供しますが、Lokadのサプライチェーン推奨の採用に関しては、我々のSCSが非常に積極的です。この点は、定量的サプライチェーンイニシアチブでROI向上の主要な原動力であるため、毎週の作業セッションで議論されます。

8.4 顧客企業本社に拠点を置く専任の製品サポートチームが、製品の稼働開始後少なくとも6か月間サポートを継続することを保証できますか？

はい。Lokadのサプライチェーン科学者（SCS）のチームがこのタスクを担当します。私たちのSCSは、イニシアチブを継続的に改善し、クライアントに継続的なサポートを提供するための十分な訓練を受けています。SCSの継続的な現場常駐は、クライアントがそれを希望する場合、契約上の合意により交渉および明確化されます。

関連する注意点として、Lokadは特にクライアント側において、ソリューションの改善への活発で継続的な取り組みを維持することを強く推奨します。私たちの経験では、継続的な改善努力を段階的に廃止すると、イニシアチブの強さが損なわれることがあります。アプリケーション環境でのささやかな調整や制約など、クライアント側でのあらゆる変更がLokadによって生成される意思決定の品質に影響を与える可能性があるため、積極的な監視と継続的な改善が推奨されます。

さらに、プロジェクト実施と管理 1.7も参照してください。

9. インシデントと欠陥管理

9.1 クライアント企業の本稼働タイムラインの遅延を避けるために、すべての必須の欠陥および変更要求（重大かつ高優先度の項目）が優先的に取り扱われ、提供されることを保証できますか？

はい。Lokadのサプライチェーン科学者（SCS）がこのプロセスを担当しています。私たちのプラットフォームは、彼らが欠陥や変更要求に迅速かつ自律的に対処できるように設計されています。

Lokadのプラットフォームはプログラム可能であり、これはサプライチェーンの予測的最適化に特化したドメイン固有プログラミング言語であるEnvisionによって実現されています。このプログラム可能性により、SCSは迅速に修正を提供し、イニシアチブに対する要求された変更を、一般的な企業向けソフトウェアでは見られない精度で実施できます。

技術面だけでなく、LokadのSCSは、欠陥や変更要求に対応するために必要な人数を自然に減らす多数の重要な役割を遂行するための訓練も受けています。これらの役割には、サプライチェーンの専門家、ビジネスアナリスト、データサイエンティスト、データエンジニア、システムインテグレーターが含まれます。そのため、彼らはクライアントの主要な優先事項を念頭に置きながら、修正や更新を提供するための十分な訓練を積んでいます。

さらに、カスタマイズとシステム機能 6.2も参照してください。

9.2 すべての欠陥とユーザビリティの問題をタイムリーに解決するための欠陥監視メカニズムを実施できますか？

はい、Lokadのプラットフォームには独自のタスク/チケット/問題管理システムが備わっています。これらの機能により、問題のタイムリーな解決状況を正確に追跡することができます。これらの解決は、Lokadに雇用されているサプライチェーン科学者（SCS）のチームによって対処されます。

しかし、「欠陥」と「ユーザビリティの問題」を一緒くたにすることは適切ではありません。例えば、不正確な需要予測は「欠陥」です。それはサプライチェーンに悪影響を及ぼします。しかし、クライアント企業が運営する市場状況によっては、この「欠陥」は修正されるのではなく、緩和されるだけの場合があります。サプライチェーンの予測的最適化においては、解決策は常にトレードオフであり、ある欠陥を解決すると、別の欠陥（できれば小さいもの）が生じる可能性があります。

対照的に、ユーザビリティの問題は通常、対処が簡単です。したがって、この種の問題については、問題に対処しても通常他の問題を生じないため、タイムリーな解決を保証することに積極的かつ責任を持って取り組みます。

9.3 リリーステスト（本番前）中に遭遇した欠陥が、クライアント企業のリリース本稼働タイムラインに影響を与えないよう、タイムリーに対処および修正されることを保証できますか？

はい。特定された欠陥がクライアント固有のコードベース（Envisionで記述された）に関するものであれば、それらの欠陥はLokadのサプライチェーン科学者（SCS）によって修正されます。特定された欠陥がLokadのプラットフォームに関するものであれば、それらの欠陥はLokadのソフトウェアエンジニアリングチームによって修正されます。

いずれの場合も、Lokadのリリースプロセスでは、欠陥がリリース（本稼働）前に特定および修正されることを確認するために、徹底的なテストが行われます。

9.4 クライアント企業が電話、メール、オフィスコミュニケーター、またはインシデント管理ツールへの直接入力などのいずれかのチャネルを通じて報告する可能性のあるインシデントに、どのように対処しますか？

サプライチェーン科学者（SCS）は、報告の出所に関係なく、すべてのインシデント報告を最大限に真剣に取り扱います。Lokadとクライアント企業との契約上の合意により、プロジェクトに割り当てられるSCSの数およびクライアントが直接サポートを受けることが期待できる週あたりの時間が明示されます。

解決策 は、典型的なインシデントに対して、SCSがタスク/チケット/問題管理システムに新しいエントリを作成することから始まります。これにより、インシデントの追跡が保証されます。

次に、SCSは問題の診断を行います。もしその問題がLokad側での修正を必要とする場合、SCSは問題解決のために必要なリソースを直ちに動員します — 通常はSCS自身が行います。

最後に、問題が対処された後、SCSは、報告された問題が最終的に問題なしと診断された場合であっても、その根本原因を評価します。通常、_どこかに_対処すべき根本的な問題が存在します。根本原因に対処することにより、Lokadは将来的に類似の問題を積極的に排除します。

9.5 インシデント管理ツール以外のチャネル（例えばメールなど）を通じて欠陥が報告された場合、適切な追跡とコンプライアンスのために、報告された時点でツールに欠陥を登録しますか？

はい。タスク/チケット/問題管理システム以外のチャネルを通じて報告を受けた場合、Lokadプラットフォーム内に対応するエントリを作成することが標準的な慣行です。この慣行により、徹底的な追跡とコンプライアンスが促進されます。