FAQ: 変更管理

Lokadのイニシアチブは、クライアントのサプライチェーンを優れた自動化された意思決定によって最適化することを目指しています。通常、購買注文や在庫割り当ての選択などの日常的な作業を置き換えます。このページでは、このイニシアチブによってもたらされる変更に関する質問や懸念事項、および効果的な管理方法について説明します。Lokadの専門家は常にクライアントのプロセスをサポートするために利用可能です。

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

変更管理の概要

Lokadが開拓し提唱する量的サプライチェーン（QSC）は、従来の視点とは大きく異なります。これらの違いは、Lokadがこのような劇的なサプライチェン改善を実現できる主要な理由です。ただし、QSCイニシアチブの実装に伴う変更管理は、通常、クライアントが考えるよりも簡単です。

たとえば、Lokadは、単に異なる無駄を別の無駄で置き換えるのではなく、多くの不要な接点やプロセスを排除します。したがって、管理される 変更 は通常、次の2つの側面があります：第一に、日常的で繰り返しのサプライチェンの意思決定が自動化されることに適応すること、第二に、従業員が従来のツール（レガシーシステム、スプレッドシート、そしてしばしばその両方）で達成できたものを上回る品質の自動化された意思決定が行われることを受け入れることです。

QSCイニシアチブは、Lokadのサプライチェーンサイエンティストによって主導されます。これらの専門家は、他のソフトウェアベンダーの類似イニシアチブでは通常複数の人々が担当する役割を統合します。サプライチェーンサイエンティストは、システムインテグレーター、データエンジニア、ビジネスアナリスト、データサイエンティスト、サプライチェーンの専門家、プロジェクトマネージャーなどの役割を果たします。サプライチェーンサイエンティスト（SCS）は、Lokadの量的サプライチェーンアプローチを受け入れるために、クライアントに必要なすべてのコーチング、トレーニング、ガイダンス、サポートを提供します。

Lokadの成功した展開（本番環境）は、通常、次の2つの注目すべき結果をもたらします：より良いサプライチェンの意思決定による大幅な節約、および（主に）自動化されたサプライチェンの意思決定による大幅な生産性の節約。

変更管理の観点では、サプライチェンの節約は通常問題ではありません。企業は最終的に解放された運転資本を他の場所に再投資することを決定するかもしれませんが、この種の決定は通常、Lokadのイニシアチブの範囲を超えます。ただし、Lokadによって生み出されるかなりの生産性の節約は、通常、従来のプロセスよりもクライアント企業にとって付加価値の高い他のタスクに再投資されます。

簡単に言えば、Lokad以前、クライアント企業内のサプライチェンの実践活動はほとんどが内向きでした：予測を作成し、予測を計画に変換し、SKUの最小/最大在庫レベルを調整し、発注/生産指示/在庫移動を作成するなどです。

Lokadが本番環境になると、ほとんどの活動は外向きになります：顧客がサービスの品質として認識するもの、サプライヤーが価格をさらに下げるための障害として認識するもの、輸送業者が信頼性の低さの原因として認識するものなどを特定します。

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

サプライチェンの幹部にとって、最大の変更は（ほとんど）持続的な消火活動の排除です。Lokadのソリューションは、厄介なエッジケースに対処するために設計された自動化された意思決定を提供し、乱れた市場の動きを解析するために幹部が割り当てる必要のある帯域幅を大幅に削減します。これにより、サプライチェンの幹部は、サプライチェンの目標とプロジェクトの戦略を立案することに集中できます。これは、サブオプティマルな意思決定の持続的な結果を細かく管理する代わりに、マイクロマネージメントから解放されることを意味します。

よくある質問（FAQ）

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

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

はい。これらのサービスは、Lokadのサプライチェーンサイエンティスト（SCS）によって提供されます。これらの専門家は、実装を管理するだけでなく、クライアント企業とのイニシアチブを主導します。これには、Lokadの数値レシピの妥当性をデプロイする前に、サプライチェーン管理に対して定量的な保証を提供するなど、さまざまなタスクが含まれます。SCSはまた、クライアント企業内でLokadの推奨事項とプロセスの採用をサポートするためのトレーニング資料を提供します。

さらに、これらの専門家は、初期実装を超えたイニシアチブの長期的な成功に取り組んでおり、イニシアチブが「継続的な改善」フェーズに移行する際にも継続的なサポートを提供しています。

サプライチェーン最適化プロセスにおけるSCSの役割の詳細については、Lokadのサプライチェーンサイエンティストに関する講義とサプライチェーンサイエンティストの1日をご覧ください。

1.2 実装のタイムラインとこのタイムラインに含まれるステップまたはフェーズは何ですか？各フェーズの目標は何ですか（プロジェクトの実装キックオフからGo-Liveまで）

実装には通常約6ヶ月かかります。Lokadは_onboardingフェーズ_と_productionフェーズ_を区別しています。オンボーディングフェーズの目標は、Lokadの数値レシピを本番環境に導入することです。オンボーディングフェーズの終わりまでに、クライアントとの協力によって定義された関心のあるサプライチェンの意思決定がロボット化されるべきです。ただし、自動化は通常、実際の意図の副産物です（非常に目立つものです）。_本番_フェーズの目標は、最初に自動化を可能にする数値レシピを継続的に洗練し、改善し、再調整することです。

タイムラインの詳細

_オンボーディングフェーズ_は通常6ヶ月続き、2つのサブフェーズに分けることができます。

• 最初のサブフェーズは、データパイプラインの設定です。目標は、クライアントデータのLokadへの自動抽出のための完全に自動化されたパイプラインを作成することです。データパイプラインの最も要求の厳しい側面は、データの「意味論」を確立し、パイプラインプロセス自体を（ほぼ）完全に信頼性のあるものにすることです。ワンショットのデータ抽出ではなく、データパイプラインは、Lokadが生成するサプライチェンの推奨事項をクライアントの現在のビジネス上の関心事に関連付けるために基本的なものです。

• 2番目のサブフェーズは、クライアント固有の数値レシピ（サプライチェンの意思決定を駆動するソフトウェアロジックの部分）の設計です。目標は、一貫性のある、信頼性のある、無駄のないレシピを実現することです。最初の数値レシピの起草は迅速で、通常1〜2週間以内に終了します。ただし、これらの起草は出発点に過ぎず、それらは担当するサプライチェーンサイエンティストによって連続的な反復で迅速に改善されます。これにより、最初の起草に存在する厄介なエッジケースが迅速に排除されます。

• 3番目のサブフェーズは、_デュアルラン_です。数値レシピはもはや無意味な結果を生み出さず、最適化を制御する経済ドライバーも合意されています。ただし、レシピはまだ本番用ではありません。前に進むためには、デュアルランが開始されます。数値レシピは、既存のプロセスと並行して実行されます。レシピが自動化されているため、組織のオーバーヘッドは低いです。サプライチェーンの実践者は毎日意思決定を比較し、パターン（例：季節性）がどのように展開されるかを確認できます。デュアルランの数週間を経て、本番展開を進めるための信頼が獲得されます。

オンボーディングフェーズの最後に、すべてのステップが満たされている場合、本番展開が開始されます。この展開では、自動化が既存のプロセスを引き継ぎます。この引き継ぎは、クライアントが必要な変更管理を監視する能力に応じて段階的に行われる場合もあります。

最適化プロセスの各ステップの詳細な分解については、タイムラインの概要を参照してください。

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

はい。これらすべての要素とその他の要素は、イニシアチブのための独自の共同手順マニュアル（JPM）にまとめられています。サプライチェーンの科学者（SCS）は、イニシアチブの全期間にわたってJPMを開始および維持する責任を負っています。

ロカッドのJPMは、「なぜ？」という質問に焦点を当てています。JPMは、技術的にあまり詳しくないまたは専門的でない読者にも理解しやすいように書かれています。JPMは、イニシアチブの意図の本質を捉え、イニシアチブ自体が進行するにつれて獲得される基本的な洞察を統合しています。

ロカッドの考えでは、多くの企業のイニシアチブは、実際には読むことが不可能な無益な文書の作成によって妨げられています（つまり、退屈で理解しにくいか、難解な技術的なものです）。このような文書は、作り物のボックスにチェックを入れる以外の目的はありません。さらに、多くのサードパーティ（例：インテグレータ、コンサルタント、さらには社内の官僚主義）は、プロジェクトの文書化において量よりも質を重視する傾向があります。

対照的に、ロカッドのJPMは、読みやすく、読まれることを意図しています。JPMは、SCS自身がイニシアチブを管理するために使用するツールです。JPMに含まれるべき内容についての詳細なガイドラインはありますが、具体的なイニシアチブの特性を考慮して、SCS自身が最も注意と努力を必要とする部分を適切に判断することが最終的に求められます。

ロカッドの文書化の方針については、サプライチェーン向けの執筆の講義を参照してください。

1.4 ロカッドは、プロジェクト管理計画を維持およびベースライン化する責任を負っていますか？プランからの逸脱が発生した場合、それらを明確に伝え、緩和策とともに伝えますか？

はい。リストされた責任は、ロカッドのサプライチェーンの科学者（SCS）が管理しています。クライアント企業とのコミュニケーションの詳細は、通常、イニシアチブ自体の契約条件に依存して定義されます。

プロジェクトクライアント側には、ロカッド側よりも従業員が多い場合があります。そのため、アカウントを担当するSCSの生産性を向上させるために、多くのクライアントはイニシアチブのために1つの連絡先を指定します。この担当者または小さなチームは、プロジェクトクライアント側のすべての関係者に関連情報を伝え、関連フィードバックを求める責任を負っています。

特に複雑なイニシアチブの場合、ロカッドはロカッドとクライアント企業の主要メンバーから構成される専用のステアリング委員会を設置します。この会議は正式な承認を確保するためのメカニズムとして機能しますが、実質的な作業のほとんどは委員会自体の外で行われます。SCSは通常、プロジェクトクライアント側のさまざまなチームと日々のやり取りを行います。これらのチームは、計画からの逸脱について常に最新の情報を受け取り、イニシアチブ全体が進行していることを確認します。これらの日々のやり取りは、ステアリング委員会のセッション中に大量の問題を調査しようとするよりも、問題が発生した際に直ちに対処するためのはるかに効果的な方法です。したがって、ステアリング委員会はイニシアチブのシンクタンクとしてではなく、監督機関として機能します。

注意: 量的なサプライチェーンのイニシアチブでは、頻繁に「ポジティブな逸脱」が発生することが知られています。これらは、イニシアチブの継続的なメンテナンス中に明らかになるレシピの中での有益なサプライズです。本質的には、_逃すにはあまりにも良い_機会です。そのため、ロカッドのコミュニケーション手法の主な利点は、これらのポジティブな逸脱を発生した時点でクライアントに迅速かつ効率的に伝えることができる能力です。これにより、イニシアチブの影響力と機動性が大幅に向上します。

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

はい。ロカッドのサプライチェーンの科学者（SCS）がこれらの業務を担当しています。クライアント企業内でのコミュニケーション管理の詳細は、通常、イニシアチブ自体の契約条件に依存しています。

ロカッドは、クライアント企業本部に滞在している場合には、デイリースタンドアップに積極的に参加します。ただし、通常、私たちのSCSはロカッドのオフィスで作業しています。

私たちは、イニシアチブのすべての文書を共同手順マニュアル（JPM）にまとめています。これは、プロジェクト全体の包括的なガイドとして機能します。 JPMには、ステアリング委員会のレポート（該当する場合）を含むすべての作業セッションのノートが含まれています。

ロカッドはエスカレーション基準とガイドラインを明確にしますが、注目に値するのは、ロカッドのシニアSCSがイニシアチブに関する質問や懸念事項を処理することが期待されているということです。したがって、エスカレーションに関しては、問題の解決は通常、ジュニアSCSからシニアSCSにエスカレーションされます。これは、非常に少数の状況でさらなるエスカレーションが必要な場合を除いて、十分であることが過去の経験からわかっています。

ロカッドは、見かけ上はささいな問題でも、徹底的な分析が必要と考えています。その影響は簡単に解決できますが、根本的な原因が理解されずに放置されると、ささいな問題が再発する可能性があります。これにより、ささいな問題が再発しないようにすることができます。したがって、ロカッドは、直ちに問題を解決し、潜在的な根本原因を特定できる高度な能力を持つ人々を最前線に配置することを好みます。これは、多くのエンタープライズソフトウェアベンダーが頻繁に採用するパターンである訓練されていないサポートスタッフに頼るよりも優れたアプローチです。

したがって、ロカッドの簡潔なエスカレーションプロセスは意図的であり、迅速かつ持続的な解決を保証しています。

1.6 プロジェクト管理計画は、プロジェクト開始フェーズの一環として、すべての利害関係者によって承認されるようにしますか？

はい。より一般的には、ロカッドのサプライチェーンの科学者（SCS）は、各クライアントと交渉および合意されたプロセスに従います。これは、正式な契約条件に従ってイニシアチブ全体で適用される原則です。プロジェクトの開始は確かに重要ですが、ロカッドは最初の日から長期的なコミットメントを必要としないため、この問題は競合他社と比較してもあまり重要ではありません。

供給チェーンが「不必要な」官僚主義や愚かなプロセスの「不足」によってパフォーマンスが低下することは観察されたことがありません。それどころか、不必要な官僚主義や愚かなプロセスは、現代のサプライチェーンにおいて最も一般的な問題です。これらの問題は、他の面で高いパフォーマンスを持つ企業でも見られます。

1.7 ロカッドから派遣された専任のプロジェクトマネージャーが、クライアント企業の本社に常駐し、製品の専門家、ビジネスアナリスト、技術インターフェースの専門家と共に働きますか？

はい、そのような規定がイニシアチブの合意された契約条件の一部である場合は、派遣されます。 ロカッドは、クライアント企業の本社に従業員を常駐させることに反対していませんが、これはイニシアチブのコストを自然に増加させます。私たちのほとんどのイニシアチブはリモートで実施され、イニシアチブの規模に応じて月次または四半期ごとの訪問でサポートされています。この方法は通常、ロカッドの従業員を常時クライアントのオフィスに配置するよりも効率的とされています。ロカッドがクライアント企業の本社に常駐チームを配置することに同意した場合でも、従業員は時間の経過とともに交代します。

このような実践は、ロカッドのサプライチェーンの科学者（SCS）が継続的なトレーニングプログラムの対象となるため、すべての関係者に利益をもたらします。このプログラムは、経験や地位に関係なく、従業員が新しいスキルを習得したり古いスキルを磨き続けることを保証するために重要です。多くの企業ベンダーが従業員を数か月、場合によっては数年間、リモートのクライアント現場で運用することを許可していると私たちは観察していますが、ロカッドは信頼性と効率性の高い高品質のトレーニングプログラムの提供とは互換性がないと確信しています。

特に、ロカッドのSCSの最大の強みの1つは、非常に多様で幅広いスキルセットです。各SCSは、専門家、ビジネスアナリスト、技術インターフェースの専門家、データサイエンティスト、サプライチェーンコンサルタントなど、さまざまな役割を果たすためのトレーニングを受けています。これらの機能は通常、複数の従業員によって果たされ、クライアントにとってはコストの増加につながります。ロカッドでは、各SCSがこれらのすべてのサービスを提供します。

その結果、SCSは非常に生産性が高くなります（人数が少ないため、コミュニケーションの摩擦が少なくなります）し、パフォーマンスレベルも高くなります。実際には、サプライチェーンはエンドツーエンドの一貫性に極めて依存しており、これは少人数で実現しやすいものです。

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

ロカッドの典型的なイニシアチブでは、クライアント企業がイニシアチブのコーディネーターとして経験豊富なサプライチェーンの実践者を指名し、イニシアチブの監督者としてサプライチェーンのエグゼクティブを指名することをお勧めします。コーディネーターは、ロカッドのサプライチェーンの科学者（SCS）チームとクライアント企業との連絡窓口として機能します。コーディネーターは最初に情報の要求を伝え、後でフィードバックの要求を伝えます。同時に、ロカッドのSCSは、関心のあるサプライチェンの意思決定を行うための数値レシピと共に作業します。

オンボーディングフェーズが完了するまで、イニシアチブの進捗状況を毎週のミーティングで確認することをお勧めします。このミーティングには、コーディネーター、監督者、およびロカッドの主要なSCSのアカウントが必ず参加します。他の参加者も必要に応じて参加することができますが、実装/オンボーディングフェーズ全体での連続的な存在は通常必要ありません。

イニシアチブの最初の段階で、データパイプラインの設定にはいくつかのITリソースを割り当てる必要があります。ロカッドはこの点でほとんどの競合他社よりも効率的です。たとえば、クライアントのトランザクションデータをクライアント側でクリーニングや準備する必要なく、自動的に直接抽出します。クライアント企業がベンダーロックインの問題を抱えていない限り、この技術的な設定には1人の貢献者による4週間未満の作業が必要です。データレイクが既に存在する場合は、それよりもはるかに短い時間で済むこともあります。

その後、SCSは既存のプロセスに関する質的な洞察を収集し、すべてのサプライチェーンの優先事項と制約の詳細を把握する必要があります。このプロセスをサポートするために、コーディネーターによって主導される一連のインタビューが通常行われます。その後、SCSが数値レシピを開発した後、これらのレシピによって生成された数値をレビューし、SCSがそれらを改善するために別の一連のインタビューが行われます。

監督者の入力は、ロカッドを企業の高レベル戦略と調整するために重要であり、決定の迷いによるイニシアチブの停滞を防ぐためにも重要です。たとえば、ロカッドは、サービス品質の欠如に関連するコストをモデル化するためのさまざまなオプションを提案することができます。これらのオプションの利点と欠点を非技術的な言葉で説明することができますが、最終的にはいくつかの戦略的な選択肢を選択する必要があります。

もちろん、上記のすべてはイニシアチブの具体的なニーズに依存します。クライアント企業の特定のコンテキストと目標により適した他の組織的なアプローチも検討しています。

詳細については、ロカッドには成功したサプライチェーン最適化の「戦術的および戦略的な実行」に関するいくつかの講義があります。こちらをご覧ください。

2. リソース管理と要件

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

典型的なロカッドのイニシアチブでは、最初の6ヶ月間（オンボーディングフェーズ）において、クライアント企業から約0.5〜2 FTE（フルタイム相当）の従業員リソースが必要です。イニシアチブが本番環境に入ると、少なくとも0.25 FTEのリソースが引き続き必要となります。これらの見積もりは、クライアント企業の規模や複雑さ、および特定のサプライチェーンのニーズによって大幅に異なります。

「典型的な」イニシアチブの各段階で必要なリソースについては、オンボーディングフェーズでは以下のようになります：

• 1ヶ月目と2ヶ月目：データパイプラインの設定には、データオフィサー（通常はクライアントのIT部門の従業員）によるフルタイムの作業が4週間必要です。データオフィサーは、クライアント企業のアプリケーションの状況にかなり詳しい必要があります。データレイクが既に存在する場合、この要件は減少する可能性がありますが、逆に、データパイプラインが複数のビジネスシステム（例：国ごとに1つのERP）と連携する必要がある場合は増加します。データパイプラインが稼働している場合、データオフィサーによるメンテナンスには月に数時間以上は必要ありません。

• 3ヶ月目と4ヶ月目：数値レシピの設計には、イニシアチブのコーディネーター（クライアント側）による週に2〜3日、さまざまなサプライチェーンの実践者による週に最低10時間の高レベルな洞察を提供するための時間、および後でロカッドが生成した数値にフィードバックを提供するための時間が必要です。コーディネーターは、企業とそのサプライチェーンに精通しており、分析作業に慣れていることが期待されます。ただし、このポジションには専門的なITスキルや特定のデータサイエンスのスキルは必要ありません。イニシアチブの週次レビューには、サプライチェーンのエグゼクティブから週に半日が必要です。

• 5ヶ月目と6ヶ月目：要件は前のフェーズと基本的に同じですが、焦点が変わります。コーディネーターは、ほとんどの時間を適切な展開の準備と、影響を受けるすべてのサプライチェーンの実践者とのコミュニケーションに費やします。同様に、サプライチェーンのエグゼクティブは、ロカッドのイニシアチブから生じる新しいプロセスに関連する内部の変更管理を監督します。

プロジェクトの実施と管理 1.2も参照してください。

2.2 製品の移行をサポートするために十分な人員が計画されていることを確認していますか？

はい。ルールとして、ロカッドはオンボーディングフェーズから本番フェーズへの移行時に同じリソース（例：同じサプライチェーンサイエンティスト）を維持することをお勧めしています。適切に維持され、継続的に改善されたソリューションの投資収益率は大きいです。このような課題の解決には、設定して忘れるマインドセットで取り組むのは間違いであり、適切に監視および保守されない限り、どんな技術的なソリューションも必然的に時代遅れになります。

ロカッドがサプライチェーンの意思決定を自動化しているため、サプライチェーンの円滑な運営のためにクライアントのサプライチェーンの実践者全員に新しいプロセスを再教育する必要はありません - 自動化そのものがそれを担当するように設計されています。その結果、ロカッドのイニシアチブによって引き起こされるクライアントのサプライチェーン組織の完全な刷新が、プロジェクトが稼働してからわずか数ヶ月で完了することは珍しくありません。

この効率的なアプローチは、エンタープライズソフトウェアベンダーが稼働するためにしばしば必要とする大規模で高コストな「タスクフォース」とは対照的です。

2.3 製品の移行をサポートするために、クライアント企業本社に十分な人員と知識製品（KP）リソースが配置されていることを保証できますか？

はい、このような規定と要件は、イニシアチブの具体的で相互に合意された契約条件でカバーされています。

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

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

2.4 ビジネス製品オーナーとの要件レビューセッションを実施し、要件を引き出し文書化していますか？

はい。サプライチェーンサイエンティストの最初の目標の1つは、クライアントのサプライチェーンに関するすべての必要な洞察を得ることです。このプロセスは通常、ビジネス製品オーナーを含む関係者とのインタビューを通じて行われます。また、可能であれば既存の文書を注意深くレビューし、これらのインタビューを最大限に活用します。

ただし、ロカッドの主な関心事は、調査されている「問題」の理解ですが、これは常に「要件」のリスト作成によって支援されるものではありません。たとえば、クライアントが「スロームーバー」の特別な処理を必要とすると言及した場合、低ボリュームが対処する必要がある問題であると理解します。ただし、これらのSKUに特別なケースを設定することは、この問題に対処するために利用できる多くのオプションのうちの1つに過ぎません。

この例では、私たちの優先順位は「スロームーバー」の真の性質を特定することです。実際には、クライアントのサプライチェーンの課題を調査した後、問題（スロームーバー）がよりよく理解されると、介入戦略が完全に変わることがあります - これにより、対処が容易になることがしばしばあります。

そのため、ロカッドはクライアントの要件を引き出し文書化しますが、私たちのアプローチは、現状のクライアントのサプライチェーンをそのまま受け入れるのではなく、問題の真の性質を発見することを重視しています。

問題解決とソリューションについての詳細は、問題に恋して-ソリューションよりを参照してください。

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

はい。これらの見積もりは通常、最初の商業提案に含まれています。イニシアチブの準備のためにワークショップが組織される場合、ワークショップの情報をさらに詳細に提案に反映させます。

Lokadプラットフォームはプログラム可能です。したがって、実装は予測的なサプライチェーンの最適化に特化したDSL（ドメイン固有のプログラミング言語）であるEnvisionで書かれたスクリプトによってサポートされることを意図しています。その結果、Lokadは、人々やクライアント企業のビジネスシステム向けの特注の機能やインターフェースを提供するのに特に適しています。

ほとんどのエンタープライズソフトウェアとは異なり、Lokadではプログラム可能性が中核機能です。前述のEnvisionスクリプトは通常の意味でのLokadソリューションの「カスタマイズ」ではありません。また、それらのスクリプトの存在もLokadソリューションのメインライン開発からの逸脱ではありません。むしろ、Lokadの豊富なプログラム可能性は意図された実装パスです。

その結果、見積もり（コスト、スケジュールなど）には非常に高い確度があります。ほとんどのプロジェクトは見積もり/初期予算内に収まります（あらゆる意味で）。これは、Lokadの競合他社のいくつかとは対照的であり、高額な遅延や条件の再定義が一般的です。

このポイントについての詳細は、Lidlの5億ユーロのSAP失敗事例を参照してください。

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

はい。私たちは平均して従業員を3.5年間保持しており、これは同様の市場（北米および西ヨーロッパ）の同様のコホート（ITやITに関連するドメインの優れたエンジニア）と比較してほぼ2倍の雇用期間です。この求人市場は激しく競争があり、改善の余地は常にありますが、これによりLokadは競合他社のほとんどよりも優れています。その結果、Lokadのほとんどのイニシアチブは、毎年同じサプライチェーンサイエンティスト（SCS）を持つことの利点を享受しています。

この保持率は競争力のある給与とLokadがチームのトレーニングに継続的に投資していることに起因します。特に、Lokadが自社ウェブサイトで公開しているサプライチェーンのコンテンツ、特にサプライチェーン講義シリーズは、Lokadが自社スタッフのトレーニングに焦点を当てている副産物と見なすことができます。一般的に、公開されていないトレーニング資料を持たないエンタープライズソフトウェアベンダーは、ほとんど例外なく非公開のトレーニング資料も持っていません（たとえ逆を主張する場合でも）。

後継者計画に関しては、2つの重要なプラクティスがあります。まず、すべてのLokadのイニシアチブには共同手順マニュアル（JPM）が付属しています。JPMは、新しいSCSがイニシアチブの関連する洞察と技術的な詳細に迅速に慣れるために使用される主要なドキュメントです。次に、すべてのイニシアチブには常に主要なSCSと副次的なSCSの両方がいます。副次的なSCSが直接イニシアチブに貢献しない場合でも、Lokadはこの人物が必要に応じてイニシアチブを引き継ぐ準備ができていることを確認するために十分な時間を割り当てます。このプラクティスにより、予期しない休暇/離職に関連する問題は大幅に軽減されます。

3. 役割、責任、およびステークホルダーの管理

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

クライアント企業との協力レベルはさまざまですが、全体的にはエンタープライズソフトウェアベンダーが通常期待されるものよりもはるかに高いです。サプライチェーンの問題はすべての企業にとって同じくらい重要ではないため、サプライチェーンが（認識されている）企業の中核である企業ほど協力関係は強くなります。

「パートナー」という用語は、時間追跡ソフトウェアなどの些細なソフトウェア製品の提供業者まで薄められています。しかし、1年または2年後、ほとんどのクライアントはLokadとの関係を「本物の」パートナーシップとして言及するようになります。彼らはLokadで信頼を得た顔を持っており、そのため、これらの人々（通常はサプライチェーンサイエンティスト（SCS））は彼らのビジネスについて非常によく知っています。さらに、私たちの結果はしばしばCEOや企業の取締役会に直接報告されるほど注目されています。大企業でも同様です。

Lokadとの継続的な協力により、クライアントは自社のサプライチェーンプラクティス全体をポジティブに再構築することができます。最終的には、全体のチェーンが刷新され、クライアントとサプライヤーの両方にポジティブな影響を与えます。Lokadは、クライアント企業に存在する重要な戦略的専門知識を置き換える意図はありません。むしろ、Lokadはサプライチェーンの意思決定プロセスの最も単調で繰り返しの部分を自動化することを望んでいます。このアプローチにより、多くの場合、貴重なクライアントリソースが解放され、より良い用途に再配置されることができます。

3.2 ソリューションの効果を最大化するために、クライアント企業とLokadの両方にどのような役割と責任が期待されますか？

Lokadの量的サプライチェーンイニシアチブには、4つの典型的な役割が関与しています。

• サプライチェーンリーダー： この役割は、量的サプライチェーンイニシアチブにおける経営トップの関与の重要性を強調しています。この人物は技術的な詳細には詳しくなることは期待されていませんが、イニシアチブの戦略的な洞察を理解し、伝える必要があります。彼らの役割はメトリクスやKPIを作成することではなく、むしろそれらを批判的に評価し、全体戦略との整合性を確保することです。

• サプライチェーンコーディネーター： イニシアチブのスムーズな運営を確保するために不可欠な役割であり、この人物はさまざまな内部チームとの橋渡しをします。彼らの主な責任はフィードバックの収集、ステークホルダーとのコミュニケーション、プロセスと意思決定の確認/明確化です。彼らはイニシアチブが既存の企業ワークフローと整合していることを確認する一方で、将来のワークフローの改訂にも柔軟な姿勢を持ちます。

• データオフィサー： データは量的サプライチェーンイニシアチブの基盤であり、この人物はそのアクセシビリティと信頼性を確保します。売上履歴や購買履歴などの包括的なデータセットを抽出することを担当し、データの抽出を自動化しスケジュール化します。彼らの役割はイニシアチブの開始時に最も集中的ですが、その貢献は成功のために重要です。

• サプライチェーンサイエンティスト： この役割は、サプライチェーンコーディネーターからの洞察とデータオフィサーからのデータを統合し、意思決定プロセスを自動化します。データの準備から始まり、サプライチェーンサイエンティストはコーディネーターと緊密に協力してデータの曖昧さを明確にします。それから戦略を具体的な意思決定（再発注数量など）に形式化し、透明性と制御のためのダッシュボードとKPIを実装します。

量的サプライチェーンイニシアチブ内の異なる指定に関する詳細は、プロジェクトの役割を参照してください。

3.3 実装フェーズと本番フェーズのために完全なRACI（責任者/説明責任者/相談者/通知者）テーブルを持っていますか？

はい。クライアント企業が重要であると判断した場合、この情報は明示的にRACIテーブルとして提示することができます。

より重要なことは、サプライチェーンサイエンティスト（SCS）がイニシアチブの進行に応じて適切かつ迅速な判断を下すために、このようなマトリックスを内面化していることです。サプライチェーンの最適化に関連する問題に関しては、問題をどのようにフレーム化するかが重要です。その後、焦点は組織内で問題に最も適した立場にいる人物を特定することに移ります。重要なのは、この分析を迅速に行い、イニシアチブの勢いを保つことです。

このために、LokadのSCSはイニシアチブを先導し、Lokadの数値レシピによって生成される出力の品質に責任を持ちます。

そのため、サプライチェーンの意思決定に責任を持つのは、高度に訓練された専門家の小さな核であり、多くの利害関係者の間で責任を分散する「システム」や「プロセス」ではありません。Lokadの立場は、このようなシステムは責任を希薄にするのではなく、硬直化させる傾向があるということです。したがって、私たちのSCSは、この責任を受け入れ、適切な利害関係者がクライアント企業で協議され、完全に通知されることを確認するように訓練されています。

3.4 プロジェクトに関与するすべての利害関係者の役割と責任をRACI（責任、説明責任、相談、通知）マトリックスを使用して文書化しますか？この文書がすべての関係者によって議論され、合意されることを確認しますか？

はい。このような要素（およびそれ以上）は、共同手順マニュアル（JPM）に収集および文書化されます。JPMは、Lokadのサプライチェーンサイエンティスト（SCS）によって作成されます（クライアント企業から直接収集された洞察を含む）。この文書では、各人の役割と責任のパラメータが詳細に説明されています。

JPMはイニシアチブのための継続的なリソースとしても機能し、クライアント企業に割り当てられたSCSによって書かれます。この文書を彼ら自身の言葉で作成することにより、SCSがクライアントのサプライチェーンと包括的なソリューションを調査、診断、分析するためにかなりの時間を費やしたことが示されます（クライアントの既存の文献を単に反復するのではありません）。

JPMへの修正はクライアント企業と共有されます。JPM自体は、Lokadとクライアント企業の作業セッション中に定期的に議論されます。

関連する注意点として、私たちの経験から、意見の相違が生じる場合、それは通常、クライアント企業内で解決する必要のある組織の問題を反映していることがわかりました。これが、クライアント企業がイニシアチブを監督するサプライチェーンエグゼクティブを任命することをお勧めする理由です。彼らの重要な貢献の1つは、このような場合に仲介役として機能することです。

3.5 プロジェクト作業グループとステアリンググループは、プロジェクトの利害関係者から名前のあるリソースで構成されることを確認しますか？関係者全員が合意する運営リズムを確認しますか？

はい。一般的な原則として、私たちはクライアント企業が必要とするプロセスに従います。合意された要素（およびイニシアチブの進行に伴う変更）は、共同手順マニュアル（JPM）に文書化されます。これには、プロジェクト作業グループとステアリンググループに関する詳細も含まれています。Lokadのサプライチェーンサイエンティスト（SCS）を通じて、これらのプロセスを導入し、監視するために必要なリソースを持っています。

逸話的に、Lokadの最も頻繁に評価される貢献の1つは、サプライチェーンや官僚的な性質のプロセスを簡素化する能力です。時間の経過とともに、私たちは積極的にクライアントのサプライチェーンから不必要な官僚的なレイヤーを取り除くために取り組んでいます。

4. システム移行と稼働開始

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

オンボーディングフェーズの典型的な期間は6ヶ月です。このフェーズはキックオフからLokadが「稼働」するまで続きます。つまり、自動化されたサプライチェーンの推奨事項がクライアントの意思決定プロセスを効果的に導いています。

この期間は、データレイクが既に存在する場合には1ヶ月短縮することができます。よく構築され、文書化されたデータレイクは、オンボーディングフェーズをさらに短縮することができます。逆に、クライアントのソフトウェアやシステム環境が過度に複雑または時代遅れである場合、このフェーズは通常1〜3ヶ月延長されます。

興味深いことに、サプライチェーン自体の複雑さはそれほど影響力を持たないようです。Lokadは、意図した期間内で実現可能な範囲を定義することを目指しています。私たちの経験から、6ヶ月以上続くオンボーディングフェーズは、イニシアチブが停滞するリスクを抱えています。したがって、私たちはこのリスクを軽減するために範囲を積極的に設計しています。

このような遅延は、Lokad自体の技術的なセットアップとはほとんど関係ありません。提案されたタイムラインは、技術的な目的（データ抽出の自動化、数値レシピのテストなど）だけでなく、Lokadのサプライチェーン科学者（SCS）がクライアント企業のすべての具体的な要素に完全に習熟するための時間を提供し、サプライチェーンチームがLokadのアプローチを「消化」するための時間を提供します。これは通常、クライアントの従来のプロセスからの脱却を意味します。

4.2 訪問回数とワークショップの計画はいくつですか？

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

クライアント企業の目標ができるだけ効率的にイニシアチブを維持することである場合、完全にリモートのイニシアチブ（つまり、訪問なし）にも対応できます。私たちは、これを小規模企業（年間売上高が1億ドル未満）や、リモートの貢献者（大規模なeコマース企業など）に概して慣れている企業におすすめしています。Lokadが実施するイニシアチブの約半分がこのカテゴリに属しています。

クライアント企業の目標が変化を成功裏に管理する可能性を最大化することである場合、必要に応じて毎月訪問することにも対応できます。大規模企業（年間売上高が10億ドル以上）の場合、少なくとも1回の四半期ごとの訪問/ワークショップを推奨します。このアプローチは、大規模なチームが関与する場合に特に企業全体のアライメントを促進するのに役立ちます。

西ヨーロッパのクライアントに対しては、訪問時には通常1日だけ滞在することが多く、ワークショップよりも訪問回数が多くなります。西ヨーロッパ以外のクライアントに対しては、訪問時には通常数日間のワークショップが行われ、訪問回数よりもワークショップが多くなります。この違いは、関連する旅費と物流の単純な問題です。

4.3 リモートと訪問ミーティングの理想的なバランスは何ですか？

量的なサプライチェーンイニシアチブの場合、ミーティングの大部分はリモートで行うべきです。ほとんどのミーティングは短時間（30分以下）で、参加者はLokadのサプライチェーン科学者とクライアント企業のサプライチェンプラクティショナーの2人だけです。さらに、リモートミーティングは特定の技術的なタスクにも有益です。すべての参加者は自分自身のコンピュータセットアップにアクセスできるため、大きなモニターにアクセスすることもできます。これは、参加者が複雑なレポートを調査する必要がある場合に特に役立ちます。

ただし、Lokadはクライアントとの訪問ミーティングの価値を過小評価しません。訪問ミーティングは、複雑なアイデアを伝えやすくし、視点を議論し、または期待値を見直すことがより容易になることが多いです。したがって、訪問ミーティングのための定期的なリズム（週次/月次/四半期など）を採用することをお勧めします。Lokadは、特にLokadがクライアントをホストする場合、このような訪問ミーティングを重要なイベントとして扱います。

このアプローチにより、両者はリモートミーティングを簡単で便利で必要な頻度で行うことができます。

4.4 本番環境の品質チェックやインターフェースの設定を含む、ゴーライブの準備評価をクライアント企業のために支援しますか？

はい。実際に、Lokadはゴーライブの準備評価においてクライアント企業を単に支援するだけでなく、Lokadのサプライチェーンサイエンティスト（SCS）の主な責任の一つは、クライアント企業に提供されるエンドツーエンドのソリューションを所有することです。言い換えれば、機械化されたシステム（機械のフリート）が結果を生成しているものの、システムに対して個人的な責任を負うのは人間です。彼らはエンドツーエンドのデータ処理パイプラインの正確さ、関連性、適切さを確保します - クライアントの全体的なビジネス上の懸念も考慮に入れています。

ソフトウェアインターフェースはエラーの発生しやすい性質を持つため、その整合性の評価には特別な注意が必要です。Lokadは、この整合性を入口側（Lokadがクライアント企業から過去のデータを取得するとき）と出口側（Lokadがサプライチェーンの意思決定をクライアント企業に返すとき）の両方で評価します。このタスクには、Lokadが特定の方法論と技術を活用しています。

ゴーライブの準備を確保するためにLokadが活用する技術の種類をよりよく理解するには、サプライチェーンのプログラミングパラダイムをご覧ください。

4.5 クライアント企業の既存の業務アプリケーションから新しい業務アプリケーションへの業務運用のシームレスな移行を管理するための本番移行戦略文書を作成しますか？

はい。移行は当社の共同手順マニュアル（JPM）で文書化されています。この詳細な文書は、Lokadのサプライチェーンサイエンティスト（SCS）によって作成され、サプライチェーンの実践者とサプライチェーンのエグゼクティブがプロセスを理解可能な形で十分に説明するための適切な資料にアクセスできるようにします。SCSは、この文書が非技術的な観客にも理解しやすいようにするために、注釈にはかなりの技術的な内容が含まれる場合があるにもかかわらず、注力しています。

また、Lokadのデュアルランアプローチは、既存のプロセスから新しいソリューションへのスムーズな移行を確実にするために特に適しています。この文脈での「デュアルラン」とは、Lokadがイニシアチブ全体の範囲で既存の意思決定プロセスと同時に実行されるという実践を指します。この実践は、Lokadによる既存の意思決定プロセスのロボット化の性質によってのみ可能になり、LokadのSCSが実際のプロダクション環境で数週間にわたって完全な範囲で満足のいく実行条件で実行されている数値レシピを保証します。その後、Lokadの意思決定が既存のプロセスを上書きします。

このようなデュアルランは、競合他社が提案する代替技術や方法論では通常実現不可能です。実際、彼らはサプライチェーンの意思決定をロボット化していないため、デュアルランに関連するオーバーヘッドが著しいです。その結果、デュアルランは最良の場合でも本番環境を真に反映していない小規模な範囲で実行されます。そのため、このアプローチが採用されると、範囲の後からの拡張は必ずしも防げない本番インシデントにつながります。

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

はい。範囲は常にLokadとクライアント企業の契約に詳細に記載されています。通常、それは一連の場所と/または一連のビジネスシステム上での特定のタイプのサプライチェーンの意思決定（例：在庫の補充または在庫の割り当て）の形を取ります。

タイムラインは通常6ヶ月以内です（キックオフから本番まで）。プロジェクションされたタイムラインは常に商業提案に含まれていますが、契約上で具体的に指定されていない場合もあります。バインディングされたタイムラインは相互のコミットメントを表し、Lokadのイニシアチブの進行ペースは、クライアント企業による特定のステップのタイムリーな実行、特にLokadへのデータパイプラインの構築に依存します。

成功基準に関しては、決定は常にクライアント企業によって単独で行われます。この決定を支持するためのガイドラインを文書化することはできますが、非単独の決定は珍しいです。要するに、クライアントがそう思わない限り、ベンダーはパイロットが成功したと判断する立場にはありません。

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

この微妙なポイントについては、定量的なサプライチェーンイニシアチブの成功を評価するをご覧ください。

4.7 パイロットランの実施を組織化して、a) データの適切性、b) システムの設定とアプリケーションの準備、c) プロセス/システムの遵守、およびd) 目的に適した全体的な適合性を確保しますか？

はい。サプライチェーンの最適化を提供することを目的としたパイロットは、本番で使用するために承認されたプレプロダクションのセットアップと区別がつかないように扱います。

Lokadのサプライチェーン科学者（SCS）チームが上記のすべてに責任を持ちます。私たちの経験では、データの適切性は、数十年前（数十年前）にデジタル化された企業ではほとんど問題になりません。購入、生産、在庫、販売のトラッキングを行うビジネスシステムがある限り、イニシアチブには適切なデータがほぼ保証されます。課題は、サプライチェーンの最適化をサポートするために元々収集されなかったデータを理解することです。

このポイントについては、不正確なデータを参照してください。

5. 変更とリスク管理

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

すべてのクライアントは、Lokadのサプライチェーン科学者（SCS）の完全なサポートを受けることができます。SCSは、サプライチェーンの最適化イニシアチブの技術的および非技術的要件を処理するために訓練されています。SCSは、次のような方法で変更管理プロセスを支援します。

• クライアント企業のサプライチェーン担当者向けの既存プロセスの改善を提案します。

• クライアント企業のメンバー/チームをオンボードするためのトレーニング資料を作成します。

• サプライチェーン管理を支援し、サプライチェーンにもたらされる変更の影響をドルまたはユーロ（またはクライアントの選択した通貨）で数量化します。

変更管理は、SCSにとってかなりの時間を要することに注意する必要があります。各SCSは、変更管理においてサプライチェーンリーダーシップをサポートするために適したスキルと経験を持っていますが、この責任は他のすべての責任と競合します。

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

5.2 本番フェーズでは、変更管理に対するビジョンはどのようなものですか？主なマイルストーンは何ですか？新しい組織は、新しいソリューションの成功した実装後にどのようになりますか？

Lokadが本番に入ると、サプライチェーンの意思決定の一部が自動化されます。その目標は、サプライチェーンの実践を資本主義的な事業に変えることです。サプライチェーンの実践者が費やす時間は、数値レシピの持続的な改善に貢献するようになります。これは、通常のサプライチェーンの実践とは異なります。通常、ある日のほとんどの努力が、会社をさらに1日続けるために割り当てられます。自己付加価値のあるサプライチェーンへの移行は、自然なものです。

• 最初のマイルストーンは、サプライチェーンの実践者がLokadを使用して、ほとんどのレガシープロセスを廃棄できることを認識することです。たとえば、補充数量が頻繁に間違っている場合、毎日の補充数量を見直すことは意味があります。しかし、Lokadの数量は既に正確であり、さらなる見直しは必要ありません。実際、Lokadが生成する数字の中には無駄が0％含まれていることが、本番稼働の主要な基準です。サプライチェーンの実践者がLokadの数字に置ける信頼は、より良い使い道になるため、多くの時間を解放します。

• 2番目のマイルストーンは、サプライチェーンの実践者の中に「早期採用者」がいることです。これらは通常、非付加価値のあるレガシープロセス（たとえば、数字の手動レビューなど）からすばやく離れて、数値レシピを通じたサプライチェーンの継続的な改善に焦点を当てることができる人々です。彼らは、わずかな技術的側面だけでなく、多くの重要な質問に取り組むことができます（たとえば、クライアント企業は正しい視点からサービスの品質を見ていますか？）。

• 3番目のマイルストーンは、サプライチェーンの実践者の大部分が内向きではなく、外向き（クライアントとサプライヤー）を見るようになることです。最終的には、サプライチェーンはクライアント企業の境界を超えたアライメントを提供する必要があります。これにより、収集される洞察のプールが拡大し、数値レシピがさらに洗練されます。

新しい組織は、ソフトウェア会社に近いです。手動で処理される繰り返しのサプライチェーンタスクはほとんどありません（自動化のため）。緊急事態もずっと少なくなります（再び、自動化のため）。ルーチンタスクの削減は、サプライチェーンの実践者にとってタスクの多様性の増加をもたらします。通常、これはサプライチェーンの制御に費やす時間と労力の減少を意味しますが、管理職には、増えた余剰時間と労力を活用するために従業員のスキルアップにより多くの期待が寄せられます。

詳細については、(ソフトウェア) 製品指向のサプライチェーンへの配信を参照してください。

5.3 エンドユーザーのワークフロー変更はどのように扱いますか？まず、Lokadのオンボーディングで、次にLokad自体の進化で。

Lokadが生成するサプライチェーンの意思決定は、ワークフローを必要としません。実際、サプライチェーンの意思決定を生成するすべてのステップを自動化することが望ましい状態です。

ただし、クライアントが明示的に要求した場合、Lokadはレガシーワークフローと同様の「ワークフロー」を導入することができます。これは、変更管理を容易にするためのものであり、数値レシピの成功には必要ありません。クライアントの従業員がLokadが生成する意思決定により慣れ親しんで信頼を寄せるようになると、「ワークフロー」は徐々に簡素化され、最終的には完全に削除されるまで簡素化されます。

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

5.4 Issues & Riskレジスタを管理できますか？それには緩和計画、タスク、責任、タイムライン、ステータス（未着手、進行中、完了、保留中）が含まれますか？Lokadのプロジェクトマネージャーは、すべてのIssues & Risksを追跡し、適時の解決策を確保するか、必要に応じてエスカレーションを管理しますか？

はい。Lokadのプラットフォームには、独自の内部の問題/チケット/タスク管理機能が備わっています。この機能は、ステータス、優先度、割り当て、通知など、このようなツールに一般的に期待されるすべての機能を提供します。さらに、私たちは関連する上位のタイムラインを含む包括的で整理されたイニシアチブのプレゼンテーションを提供する共同手順マニュアル（JPM）を別途管理しています。Lokadのサプライチェーンサイエンティスト（SCS）は、タスクマネージャーの監督を担当しています。彼らは問題や懸念事項が迅速に対処されることを確認します。

エスカレーションは可能ですが、稀です。タスクを管理/レビューする同じSCSが解決も行います。LokadのシニアSCSは、サプライチェーンの専門家、データエンジニア、データインテグレーター、ビジネスアナリスト、データサイエンティスト、プロジェクトマネージャー、変革コンサルタントなど、さまざまな役割を果たしています。

SCSと簡単に連絡を取ることができる能力は、私たちのクライアントが定期的に大きな利点として挙げるものです。クライアントは、問題の満足のいく解決を監督する役割を担当する人物と直接対話することができます。そのため、彼らは何人かの能力を持つ人物に連絡を取るためにいくつかの階層をたどる必要はありません。

SCSの専門外のスキルが必要な問題が発生した場合（例：プラットフォームのアーキテクチャに関する技術的な問題）、彼らは問題の適時な解決を監督し、関連するクライアントの最初の連絡先として行動します。

5.5 ビジネスプロセスの導入と変更、既存プロセスの廃止に対応するための組織変更管理コンサルティングを提供していますか？

はい、クライアント企業がLokadとのパートナーシップに変更管理コンサルティングサービスを含めることを希望する場合は提供します。ただし、Lokadの主要な専門知識はサプライチェーンの予測最適化にあり、変更管理に関しては従来の方法よりも一般的なアプローチを取っています。このアプローチが実施された場合、プロジェクトに関与する第三者の数を制限することになります。

また、クライアント企業がLokadを補完するために変更管理の専門家のサービスを利用することを希望する場合、クライアント企業が適切と判断する範囲で情報を共有してサポートします。

6. カスタマイズとシステムの機能

6.1 カスタマイズ要件の優先順位付けセッションを設定し、製品のギャップによるビジネスへの影響の理解を確保し、カスタマイズのリリースの優先順位について相互合意に達することはできますか？

はい。Lokadのサプライチェーンサイエンティスト（SCS）がこのプロセスを担当しています。実際、この優先順位付けに関してLokadは2つの点で他とは異なります。 まず、SCSはカスタマイズを独立して実装する能力を持っており、リソースとタイムラインに関して明確な洞察を提供することができます。

これにより、クライアント企業は、任意のサプライチェーンの変更の利益とこの変更に関連するコストをバランス良く考慮できる専門家の恩恵を受けることができます。これにより、優先順位付けの品質が大幅に向上します。

また、Lokadの包括的な戦略である「数量的サプライチェーン」は、純粋に財務的な観点を強調しています。したがって、SCSは、ソリューションにもたらされる潜在的な変更の影響の数量的な見積もり（ドルまたはユーロで）をクライアント企業をサポートします。この戦略により、優先すべき問題を議論する従来のボトルネックを回避し、最も大きな財務的影響をもたらす問題に優先順位を付けることで、イニシアチブを洗練させます。

6.2 すべてのビジネスプロセスのフィットギャップスタディを実施し、自動化の機会を特定し、望ましい将来のプロセスを文書化し、製品の機能のギャップを特定した場合には受け入れ可能な回避策を提案できますか？

はい。Lokadのサプライチェーンサイエンティスト（SCS）がこのプロセスを担当しています。イニシアチブの開始時に初期の調査が行われますが、このプロセスは製造フェーズ全体で継続的に行われます。これは、ソリューションの継続的な改善を追求する私たちのアプローチの一部です。

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

したがって、SCSは「パフォーマンスのギャップ」を特定し、対処することに関心を持っています。これには、全体的なパフォーマンスを最適化するために機能を追加または削除することが含まれる場合があります。

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

6.3 プロセスのフィットギャップ分析ワークショップの詳細なアジェンダを提供できますか？クライアント側のSME（専門家）の期待を、ワークショップが始まる少なくとも1週間前に提供できますか？

はい。Lokadのサプライチェーンサイエンティスト（SCS）は、すべてのワークショップのアジェンダを提供します。アジェンダは、イベントの少なくとも1週間前に通知されるようにします。クライアント企業から明示的な指示がある場合、アジェンダを提供するためのタイムラインなどの指示がある場合は、それに従います。指示がない場合、ワークショップを（タイムラインを含む）知的かつプロフェッショナルな方法で構築します。

6.4 製品のカスタマイズ要件文書は、クライアント企業によって共同でレビューおよび承認されますか？

はい、これらの文書はクライアント企業に提供され、その後承認されます。

Lokadのプラットフォームの設計上、通常のエンタープライズソフトウェアの範囲で理解されるような「カスタマイズ」の必要性はほとんどありません。Lokadのプラットフォームはプログラム可能であり、サプライチェーンの予測最適化に特化したEnvisionというDSL（ドメイン固有のプログラミング言語）を使用しています。

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

6.5 クライアント企業が外部システムとのインターフェース接続を確立し、インターフェースのテストと認証を支援しますか？

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

システムのインターフェースは通常、第三者の認証機関によって「認証」されるものではありません。インターフェースは、クライアント企業のIT部門とLokadの間で共同で合意された技術仕様によって「形式的に指定」されます。この技術仕様は、企業間の相互的な義務をサポートします。つまり、クライアント企業は必要なデータをLokadにタイムリーに提供することを約束し、Lokadは同様に結果をタイムリーに返すことを約束します。

6.6 ワークショップ中にインターフェースの仕様書を提供しますか？サンプルメッセージを含めることはできますか？

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

Lokadのサービスの性質上、「サンプルメッセージ」はおそらくテーブルの形式で提供されることが非常に高いです。これは、テーブルがクライアントのためにLokadが生成する出力をより正確に表現しているためです。インターフェースのほとんどの技術仕様は、テーブルとその形式、およびテーブルの抽出パターンと転送スケジュールに焦点を当てています。

6.7 変更依頼とリリース管理プロセスを共有していますか？

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

まず、クライアント専用の変更はSCS自体によって実装されます。これらの変更は頻繁に行われ、オンボーディングフェーズ中にはしばしば1日に複数回行われます。このような変更は、クライアント企業のニーズに直接応えるものであり、両者の間でのコミュニケーションが必要です。

次に、Lokadのプラットフォームを更新します。これは通常、サプライチェーンの予測最適化に特化したEnvisionというDSL（ドメイン固有のプログラミング言語）を介して行われます。これらの変更は、クライアント企業にとって透明なものになるように設計されています。必要な場合、これらの更新の詳細情報を提供することができ、この情報の多くは一般に公開されています。

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 UAT（ユーザー受け入れテスト）のプレプロダクション、プロダクション、およびトレーニング環境を定義されたToBeプロセスに従って構成しますか？

はい。Lokadのプラットフォームの豊富なプログラム可能性により、構成に対して完全な制御を行うことができます。これは、サプライチェーンの予測最適化に特化したEnvisionというDSL（ドメイン固有のプログラミング言語）によって可能になっています。

このアプローチにより、異なる環境が変更の対象とならない部分については同じコードを使用することができます。これにより、環境間の偶発的な違いが減少し、ユーザーを混乱させることなくUATプロセスの整合性を損なうことがありません。

さらに、セットアップを1つのステージから別のステージに進めることは、当社の設計では簡単です。設定変更にはコードベースを使用する方が従来のユーザーインターフェースの方法よりも効率的です。

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

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

Lokadでは、プロダクション環境全体、すべてのプロダクションデータを複製することができますが、データストレージのフットプリントは倍増しません。内部的には、2つの環境間で同一のデータは共有されます。さらに、当社の定数時間設計により、1つの環境のワークロードが他の環境のパフォーマンスに悪影響を与えることはありません。

ただし、ほとんどの企業向けソフトウェアベンダーは、単にメインのセットアップを「クローン」することでこの問題を回避しています。クローニングまたは直接の複製は簡単ですが、無駄です。クローニングは、リソース（人員とマシン）の量が環境の数とともに線形に増加することを意味します。たとえば、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は、数値レシピ（サプライチェーンの最適化に特化したアルゴリズム）の改善に継続的なリソースを割り当てることにより、各クライアントが最新のイニシアチブを持つことを保証しています。

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

8. ポスト実装サポートと監査

8.1 パイロットランの観察結果が文書化され、関係者に割り当てられ、クライアント企業の技術、IT、サプライヤー部門に追跡されることを保証できますか？

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

上位レベルのアクションアイテムはJPMに文書化されます。ただし、マイナーアクションアイテムは通常、Lokadのプラットフォーム上のタスクマネージャーで処理されます。これらのマイナーアイテムは短期間であり、タスクマネージャーはJPMよりも追跡とクロージャーをより良くサポートします。

8.2 システムの使用状況と採用状況を監視するために、十分な品質とコンプライアンスレポートを利用できるようにできますか？

はい。Lokadのサプライチェーンサイエンティスト（SCS）は、通常、公式なキックオフの直前にこの目的のために専用の計測機器を実装します。

さらに、Lokadは、生成されたサプライチェーンの意思決定と実際の意思決定との整合性を追跡することができます。これは、Lokadの推奨事項の実装に影響を与える可能性のあるクライアントのシステムのバグやグリッチなどの潜在的な原因を特定するために行われます。

8.3 アプリケーションの年次監査を実施し、システムの使用状況とエンドユーザーの採用状況を改善するためのフィードバックを提供し、ROI（投資収益率）をより早く実現できますか？

はい、年次監査はエンドツーエンドのソリューションに対して標準の手順です。ただし、Lokadのサプライチェーンサイエンティスト（SCS）は通常、年間を通じて何度もソリューション全体を監査します。年次監査は通常、クライアントのリーダーシップに対する詳細なロードマッププレゼンテーションにつながります。これは、各イニシアチブの_継続的な改善_のアプローチに合致しています。

使用状況に関しては、実際にはSCSは早い段階で積極的に専用のツールを実装して、Lokadが生成するサプライチェーンの意思決定の使用状況、採用状況、コンプライアンスを監視します。年次監査は必要な調整を行う絶好の機会ですが、Lokadのサプライチェーンの推奨事項の採用に関しては、SCSは非常に積極的です。これについては、週次の作業セッションで議論されます。Lokadの推奨事項の採用は、定量的なサプライチェーンイニシアチブにおけるROIの増加の主要な要因です。

8.4 クライアント企業本社に拠点を置く専任の製品サポートチームが、ゴーライブ後少なくとも6か月間製品をサポートすることを保証できますか？

はい。Lokadのサプライチェーンサイエンティスト（SCS）チームがこのタスクを担当します。私たちのSCSは、イニシアチブを継続的に改善し、クライアントへの継続的なサポートを提供するために十分に訓練されています。SCSのオンサイトでの継続的な存在は、クライアントが追求したいと思う場合には、契約上で交渉され、明確化されます。

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

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

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

9.1 クライアント企業の稼働開始のタイムラインに遅れが生じないよう、すべての必須の欠陥と変更要求（重要な優先順位の項目）が優先的に対応され、提供されることを保証できますか？

はい。Lokadのサプライチェーンサイエンティスト（SCS）がこのプロセスを担当しています。当社のプラットフォームは、SCSが迅速かつ自律的に欠陥と変更要求に対応できるように設計されています。

Lokadのプラットフォームはプログラム可能であり、これはEnvisionによって実現されています。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プラットフォーム内に対応するエントリを作成するのは標準的な手続きです。この手続きにより、徹底的な追跡とコンプライアンスが容易になります。