FAQ: Change Management

対象読者: サプライチェーン部門および／または計画部門。

最終更新日: 2023年12月19日

変更管理の概要

定量的サプライチェーン（QSC）は、Lokadが提唱し先駆けた概念であり、従来の見方とは大きく異なります。この違いは本質的であり、Lokadが劇的なサプライチェーンの改善を実現できる根幹となる理由です。とはいえ、QSCイニシアチブの実施に伴う変更管理は、クライアントが一般的に考えるよりも容易です。

例えば、Lokadは単に無駄な作業を異なる無駄に置き換えるのではなく、多くの不要な接点やプロセスを排除します。したがって、管理すべき変更は通常二重になります。まず、日常的で反復的なサプライチェーンの意思決定が自動化されるという事実に適応すること、次に、これらの自動化された意思決定の質が、従来のツール（レガシーシステム、スプレッドシート、あるいはその併用）で従業員が達成していたものを上回るという点を受け入れることです。

A QSCイニシアチブは、Lokadのサプライチェーンサイエンティストによって主導されます。これらの専門家は、同様のイニシアチブにおいて通常は複数の人が担うであろう多くの役割を統合します。サプライチェーンサイエンティストは、システムインテグレーター、データエンジニア、ビジネスアナリスト、データサイエンティスト、サプライチェーン専門家、プロジェクトマネージャー（その他多数の役割を含む）として機能します。SCSは、クライアントがLokadの定量的サプライチェーンアプローチを採用するために必要なコーチング、トレーニング、指導およびサポートをすべて提供します。

Lokadの本稼働への成功した展開は、通常、より良いサプライチェーンの意思決定による大幅なコスト削減と、（ほぼ）自動化されたサプライチェーンの意思決定による生産性の大幅な向上という2つの顕著な成果をもたらします。

変更管理の観点から見れば、サプライチェーンのコスト削減は通常問題にはなりません。企業は、解放された運転資本を他の分野に再投資することもありますが、こうした決定は通常、Lokadイニシアチブの範囲を超えたものです。しかし、Lokadによって生み出される大幅な生産性向上は、通常、レガシープロセスでは生み出せなかった、クライアント企業にとってより大きな付加価値をもたらす他の業務へ再投資されます。

要するに、Lokad導入以前は、クライアント企業内のサプライチェーン担当者の活動はほぼ内向きでした。すなわち、予測を作成し、その予測を計画に変換し、SKUごとに最小・最大在庫レベルを調整し、発注書／生産指示書／在庫移動の作成などを行っていました。

Lokadが本稼働すると、ほとんどの活動は外向きになります。つまり、顧客がサービスの品質と認識する点、供給業者がさらなる価格引き下げの障壁と認識する点、運送業者が自らの信頼性の低下の根本原因と捉える点などを特定することになります。

これらの洞察は、その後、SCSの継続的なサポートを通じてLokadのソリューションに継続的に取り入れられます。

サプライチェーン幹部にとって最大の変化は、日々の火消し作業の（ほぼ）排除です。Lokadのソリューションは、面倒な例外対応を処理するために設計された自動化された意思決定を提供し、執行役員が市場の不規則な動向を解析するために割かなければならない労力を大幅に削減します。これにより、サプライチェーン幹部は、最適ではない決定の結果をミクロ管理するのではなく、戦略的なサプライチェーン目標やプロジェクトの立案に専念できるようになります。

よくある質問（FAQ）

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

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

はい。これらのサービスは、Lokadのサプライチェーンサイエンティスト（SCS）によって提供されます。これらの専門家は実装の管理だけでなく、クライアント企業とのイニシアチブを主導します。これには、Lokadの数値ソリューションの有効性を展開前に示すための、サプライチェーン管理への定量的な安心感の提供など、さまざまなタスクが含まれます。SCSは、クライアント企業内でLokadの推奨するプラクティスやプロセスの採用をサポートするためのトレーニング資料も提供します。

さらに、これらの専門家は、イニシアチブが『継続的改善』フェーズに移行した後も長期的な成功に向けた継続的なサポートを提供し、初期の実装を超えてコミットし続けます。

Lokadによる「サプライチェーンサイエンティストについて」と「サプライチェーンサイエンティストの一日」の講義も参照いただき、最適化プロセスにおけるSCSの役割についての詳細をご確認ください。

1.2 実装のタイムラインと、そのタイムラインに含まれるステップまたはフェーズはどのようになっていますか？

最初から最後まで、実装には通常約6か月かかります。Lokadはオンボーディングフェーズと本稼働フェーズを区別します。オンボーディングフェーズの目的は、Lokadの数値レシピを本稼働に導入することです。オンボーディングフェーズの終了時には、クライアントとの共同定義により、対象となるサプライチェーンの意思決定が自動化されている必要があります。

タイムラインの内訳

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

• 1～2か月目: データパイプラインの設定 - 最初のサブフェーズでは、データパイプラインの設定を行います。目的は、クライアントデータをLokadに抽出するための完全自動化されたパイプラインを作成することです。データパイプラインで最も求められるのは、データの『意味論』を確立し、パイプラインプロセス自体を（ほぼ）完璧に信頼できるものにすることです。

• 3～4か月目: 数値レシピの設計 - 第二のサブフェーズでは、クライアント固有の数値レシピ、すなわちサプライチェーンの意思決定を駆動するソフトウェアロジックの設計を行います。目標は、一貫性と信頼性があり、余計な妥協のないレシピの実現です。初期の数値レシピの起草は迅速に行われ、通常1～2週間以内に完了します。

• 5～6か月目: デュアルラン - 第三のサブフェーズはデュアルランです。数値レシピはもはや無意味な結果を出さず、最適化を導く経済的要因が合意されています。レシピは従来のプロセスと並行して実行され、数週間のデュアルランを通じて本稼働への信頼が醸成されます。

オンボーディングフェーズの終了時に、すべてのステップが満たされれば、本稼働のロールアウトが開始されます。これは、従来のプロセスを自動化に移行させることを意味します。

1.3 Lokadはプロジェクト管理計画を文書化し、公開していますか？

はい。これらすべての要素およびその他の事項は、イニシアチブ専用の共同運用マニュアル（JPM）にまとめられます。サプライチェーンサイエンティスト（SCS）は、イニシアチブの全期間にわたりJPMの作成および維持の責任を担います。

LokadのJPMは「なぜ？」という疑問に焦点を当てています。JPMは読みやすく、技術に詳しくないまたは専門外の人々にもほぼ理解できるよう意図されており、イニシアチブの背後にある意図の本質を捉え、進行中に得られる基本的な洞察を統合します。

Lokadの見解では、多く（あるいはほとんど）の企業イニシアチブは、実際には読むのがほぼ不可能な、退屈で極めて技術的な無用の文書が作成されることで妨げられています。こうした文書は、形式上のチェックボックスを埋める以外には何の目的も果たしません。さらに、多くの第三者（例：システムインテグレーター、コンサルタント、さらには社内の官僚組織）は、プロジェクト文書化において質よりも量を重視する傾向があります。

これに対し、LokadのJPMは読みやすく、実際に読まれることを意図しています。JPMはSCS自らがイニシアチブを管理するためのツールでもあります。JPMに何が含まれるべきかについては包括的なガイドラインがありますが、最終的には、イニシアチブの具体的な状況を踏まえて、最も注意と労力を必要とする点についてSCSが適切な判断を下すことになります。

Lokadのドキュメンテーションに関する理念については、「サプライチェーン向け文章作成」の講義をご参照ください。

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

はい。これらの責任は、Lokadのサプライチェーンサイエンティスト（SCS）によって管理されています。クライアント企業とのコミュニケーションの具体的な管理方法は、通常、イニシアチブ自体の契約条件に依存して定義されます。

時には、クライアント側のプロジェクト関与者がLokad側よりも大幅に多い場合があり、そのため、アカウントを担当するSCSの生産性を向上させるために、クライアントはイニシアチブの単一の連絡窓口を指定します。この担当者または小規模なチームが、プロジェクトクライアント側の全関係者に対して、関連情報の伝達およびフィードバックの収集を担当します。 特に複雑なイニシアチブの場合、LokadはLokad側とクライアント側の重要メンバーで構成される専任の運営委員会を設置します。この会合は正式な承認を得るための仕組みとして機能しますが、実際の実質的な作業の大部分は委員会外で行われます。SCSは通常、クライアント側の様々なチームと日々連絡を取り合い、計画からの逸脱について絶えず報告し、イニシアチブ全体が軌道を逸れないようにします。こうした日々のやり取りは、運営委員会の会合で大量の問題を扱うよりも、発生した技術的な問題について議論し解決するためにはるかに効果的です。したがって、運営委員会自体は、イニシアチブのシンクタンクではなく、監督機関として機能します。

注：定量的サプライチェーン・イニシアチブでは、しばしば「ポジティブな逸脱」が発生します。これは、イニシアチブの継続的な保守の過程で明らかになる有益なサプライズであり、見逃すにはあまりにも価値のある好機です。このように、Lokadのコミュニケーションアプローチの大きな利点は、発生次第これらのポジティブな逸脱を迅速かつ効率的にクライアントに伝達できる点にあり、イニシアチブの効果と機敏性を大幅に向上させることにあります。

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

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

Lokadは、クライアント企業本社に常駐している場合、毎日のスタンドアップに喜んで参加します。ただし、通常はSCSはLokadのオフィスで業務を行います。

我々は、イニシアチブのすべての文書を統合し、プロジェクト全体の包括的なガイドとして機能する共同運用マニュアル（JPM）にまとめます。JPMには、運営委員会の報告（該当する場合）を含む、すべての作業セッションの議事録が含まれます。

Lokadはエスカレーションの基準とガイドラインを明確にしていますが、重要なのは、LokadのSenior SCSがイニシアチブに関する疑問や懸念に対処することが期待されるという点です。したがって、エスカレーションについては、問題の解決は通常、Junior SCSからSenior SCSへと段階的にエスカレーションされます。歴史的に見ても、これで十分であり、さらに上位へのエスカレーションを必要とする状況は極めて少ないです。

Lokadは、たとえ見かけ上些細な問題であっても、徹底的な分析に値すると考えています。影響は容易に解決できる場合であっても、根本原因が理解され対処されなければ、将来的に同じ問題が再発する可能性があります。これにより、些細な問題が再発する事態を未然に防ぎます。したがって、Lokadは、即時の問題解決と根本原因の特定双方に対処できる高度な能力を持つ人材を前線に配置することを好みます。このアプローチは、同じ問題に対して継続的に対応する、未熟なサポートスタッフに依存するよりも望ましいものです――これは多くのエンタープライズソフトウェアベンダーがあまりに頻繁にとるパターンです。

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

1.6 プロジェクト開始フェーズの一環として、すべての利害関係者によるプロジェクト管理計画の承認（サインオフ）を確実に行いますか？

はい。一般的に、Lokadのサプライチェーンサイエンティスト（SCS）は、各クライアントとの間で交渉・合意されたプロセスに従います。この原則は、プロジェクトの開始から完了まで、イニシアチブ全体に適用されます。プロジェクトの開始は確かに重要ですが、Lokadが初日から長期的なコミットメントを要求しないことを考えれば、これは比較的小さな問題です――特に競合他社と比較すると。

なお、官僚主義やその他の無駄なプロセスが『欠如している』ためにサプライチェーンのパフォーマンスが低下するという事例は、これまで一度も見られていません。むしろ、不要な官僚主義や不必要なプロセスこそが、現代のサプライチェーンにおける最も一般的な問題であり、高性能に見える企業においても存在します。

1.7 Lokadから専任のプロジェクトマネージャーをクライアント企業本社に常駐させ、製品の専門家、ビジネスアナリスト、技術インターフェイスの専門家を同行させますか？

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

このような実践はすべての関係者に利益をもたらします。なぜなら、Lokadのサプライチェーンサイエンティスト（SCS）は継続的なトレーニングプログラムを受けているからです。このプログラムは、従業員が経験や年功に関わらず新しいスキルを習得し、既存のスキルを磨き続けるために不可欠です。多くの大企業のベンダーが従業員を遠隔のクライアントサイトで数か月、あるいは数年にわたって稼働させることを許容していることを観察していますが、Lokadはこの実践が高品質なトレーニングプログラムの信頼性と効率的な提供には適合しないと確信しています。

特に、LokadのSCSの最大の強みの一つは、非常に多様で幅広いスキルセットです。各SCSは、専門分野のエキスパート、ビジネスアナリスト、技術担当窓口、データサイエンティスト、サプライチェーンコンサルタントなど、さまざまな役割を果たすように訓練されています。これらの機能は通常、複数の従業員が担うため、クライアントにとっては大幅なコスト増加を意味します。Lokadでは、各SCSがこれらすべてのサービスを提供します。

その結果、SCSは非常に生産性が高く（人が少ないほどコミュニケーションの摩擦が少なくなり）、また高いパフォーマンスレベルを発揮する傾向にあります。実際、サプライチェーンはエンドツーエンドの一貫性に大きく依存しており、これは少人数で達成する方がはるかに容易です.

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

典型的なLokadのイニシアチブでは、クライアント企業が経験豊富なサプライチェーンの実務者をイニシアチブのコーディネーターとして任命し、同時にサプライチェーンの上級管理者をイニシアチブの監督者として指名することを推奨します。コーディネーターは、Lokadのサプライチェーンサイエンティスト（SCS）チームとクライアント企業との連絡窓口として機能します。コーディネーターは最初に情報のリクエストを中継し、その後フィードバックのリクエストを中継します。同時に、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週間のフルタイム作業が必要です。データ担当者は、クライアント企業のアプリケーション環境に精通している必要があります.

• 3〜4ヶ月目： 数値的レシピの設計には、イニシアチブのクライアント側コーディネーターによる週2〜3日、及び高レベルの洞察を提供するために各種サプライチェーン実務者から週最低10時間の作業が必要で、後にLokadが生成した数値に対するフィードバックが求められます.

• 5〜6ヶ月目： 要件は前段階と本質的に同じですが、重点が変わります。コーディネーターはほとんどの時間を、適切なロールアウトの準備と、影響を受ける全てのサプライチェーン実務者とのコミュニケーションに費やします.

詳細については Project Implementation & Management 1.2 を参照してください.

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

はい。経験則として、Lokadはオンボーディングフェーズから本稼働フェーズへの移行時に、同じ量のリソース（例：同じサプライチェーンサイエンティスト）を維持することを推奨します。適切に維持され継続的に改善されるソリューションの投資収益率は非常に大きなものです.

Lokadがサプライチェーンの意思決定を自動化することを考えると、サプライチェーンの稼働を維持するために、クライアントのすべてのサプライチェーン実務者を新しいプロセスのために再訓練する必要は厳密にはありません ― 自動化そのものがそれを担うように設計されています.

この合理化されたアプローチは、本稼働に移行するためにエンタープライズソフトウェアベンダーが通常要求する大規模かつ高コストな「タスクフォース」とは対照的です.

2.3 製品移行をサポートするために、クライアント企業の本社に十分な人材およびナレッジプロダクト（KP）リソースを現地に確保できると保証できますか？

はい、そのような規定および要件は、イニシアチブの具体的かつ相互に合意された契約条件に含まれています.

See also Project Implementation & Management 1.7.

See also Resource Management & Requirements 2.2.

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

はい。サプライチェーンサイエンティストの最初の目標の一つは、クライアントのサプライチェーンに関するすべての必要な洞察を獲得することです。このプロセスは通常、ビジネスプロダクトオーナーを含む関連する利害関係者へのインタビューを通して実施されます。また、可能な場合には、これらのインタビューを最大限に活用するため、既存の文書の慎重なレビューも行います.

しかし、Lokadの最も重要な関心事は、リストアップされた「要件」によって常に助けとなるわけではない、「調査対象の問題」の本質を理解することです。例えば、クライアントが「スロームーバー」の特別扱いを求めた場合、私たちは低ボリュームが対処すべき懸念事項であると理解します。しかし、これらのSKUを特別扱いすることは、この懸念に対処するために利用可能な多くのオプションの一つにすぎません.

この例では、私たちの優先事項は「スロームーバー」の真の性質を特定することです。実際、クライアントのサプライチェーン上の課題点を調査した後、「スロームーバー」が不適切な価格設定、パッケージング、および/または割当によって発生したSKUである可能性があることが判明するかもしれません。問題（スロームーバー）がより良く理解されると、介入戦略が全く変わり、しばしば解決しやすくなります.

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

問題と解決策の二分法については、「ソリューションではなく、問題に恋する」を参照してください.

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

はい。これらの見積もりは、通常、最初の商業提案に含まれます。イニシアチブの準備のためにワークショップが開催された場合、その情報を元に提案をさらに洗練します.

Lokadプラットフォームはプログラム可能です。したがって、実装はサプライチェーンの予測最適化専用の社内DSL（ドメイン固有プログラミング言語）であるEnvisionで記述されたスクリプトによってサポートされるように設計されています。その結果、Lokadは、従業員向けであれ、クライアント企業の業務システム向けであれ、オーダーメイドの機能やインターフェースの提供に特に適しています.

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

その結果、我々の見積もり（費用、スケジュールなど）には非常に高い確実性が付随しています。プロジェクトの大多数は見積もり/初期予算内（すべての意味で）に収まります。これは、費用のかかる遅延や条件の再定式化が一般的な、いくつかのLokadの競合他社と対照的です.

この点については、Lidlの5億ユーロSAP騒動に関するケーススタディを参照してください.

2.6 契約期間中にサービスを提供する主要な人材を維持するための合理的な保持戦略を実装・維持し、さらにLokadの各主要人材ポジションに対して積極的な後継計画を維持しますか？

はい。私たちは従業員を平均3.5年間保持しており、これは北米や西ヨーロッパの同様の市場におけるITやIT関連分野の有能なエンジニアの就業期間のほぼ２倍です。この職種セグメントは非常に競争が激しく、常に改善の余地はあるものの、これによりLokadは多くの競合他社を大きく上回っています。その結果、ほとんどのLokadのイニシアチブは、年をまたいで同じサプライチェーンサイエンティスト（SCS）から恩恵を受けています.

この人材保持は、競争力のある給与とLokadがそのチームのトレーニングに継続的に投資していることによるものです。特に、Lokad自身のウェブサイトで公開しているサプライチェーン関連のコンテンツ、特にサプライチェーン講義のシリーズは、Lokadが自社スタッフのトレーニングに注力していることの副産物と見なすことができます。一般的に、公開トレーニング資料を持たないエンタープライズソフトウェアベンダーは、ほとんどの場合、非公開のトレーニング資料を持つこともほとんどありません（たとえ彼らが必ずその逆を主張するとしても）.

後継計画に関しては、2つの重要な実践があります。まず、すべてのLokadのイニシアチブには共通の運用手順書（JPM）が付属します。JPMは、新たなSCSがイニシアチブに関連するすべての洞察と技術的詳細を迅速に把握するための主要な文書です。次に、すべてのイニシアチブには常に主担当および副担当のSCSが配置されます。副担当のSCSが直接イニシアチブに貢献しなくても、必要に応じてこの人物がイニシアチブを引き継げるように十分な時間が割り当てられます。この実践は、予期せぬ休暇や離職に伴う問題を大幅に軽減します.

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が生成するサプライチェーンの意思決定に責任を持つのは、多くのステークホルダー間で責任の一部を委譲する精緻な「システム」や「プロセス」ではなく、少数の高度に訓練されたスペシャリストの中核です。Lokadの見解では、このようなシステムは責任を希薄化する傾向があり、むしろ責任を明確にするものではありません。したがって、当社のSCSはこの責任を引き受け運用するよう訓練されており、クライアント企業の関連するステークホルダーが十分に相談され、情報を共有されることを保証します。

3.4 プロジェクトに関与するすべてのステークホルダーについて、RACI（責任、実行責任、参画、通知）マトリックスを用いて役割と責任を文書化しますか？また、この文書がすべての関係者によって議論され、合意されることを保証しますか？

はい。これらすべての要素（その他も含む）は、共同運用マニュアル（JPM）に集約・文書化されています。JPMは、Lokadのサプライチェーンサイエンティスト（SCS）が（クライアント企業から直接収集した洞察を踏まえて）作成し、この文書において各人の役割と責任のパラメータが詳細に記述されています。

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

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

なお、経験上、万が一意見の相違が生じた場合、それは通常、クライアント企業内で解決すべき組織的な問題を反映しています。これが、クライアント企業にサプライチェーンエグゼクティブを任命してイニシアティブを監督することを推奨する理由の一つです。彼らの主な役割の一つは、このような場合に仲介役を務めることです。

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

はい。原則として、我々はクライアント企業が必要と判断し、正式に合意したプロセスに従います。合意された要素（およびイニシアティブの進行に伴う変更事項）は、プロジェクトのワーキンググループやステアリンググループに関する詳細を含む共同運用マニュアル（JPM）に文書化されます。Lokadのサプライチェーンサイエンティスト（SCS）を通じて、これらのプロセスを導入および監視するための必要なリソースを確保しています。

逸話的に、Lokadが最も評価される貢献の一つは、サプライチェーンや官僚的なプロセスを問わず、プロセスを簡略化する能力です。時間の経過とともに、クライアントのサプライチェーンから不要な官僚的層を積極的に排除するよう努めています。

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

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

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

もしデータレイクが既に整備されていれば、この期間は1ヶ月短縮される可能性があります―十分に整備され文書化されたデータレイクはオンボーディングフェーズをさらに短縮することができます。逆に、クライアントのソフトウェアやシステム環境が不必要に複雑または時代遅れの場合、このフェーズは通常1〜3ヶ月延長されます。

興味深いことに、サプライチェーン自体の複雑さは一見思われるほど影響力があるわけではなく、Lokadは意図された期間内に実現可能な、十分に精密なスコープを定義するよう努めています。我々の経験では、6ヶ月を超えるオンボーディングフェーズはイニシアティブの停滞リスクを伴います。したがって、このリスクを軽減するために、スコープの設計を積極的に行っています。

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

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

現地での訪問およびワークショップの回数は、クライアント企業との具体的な契約条件の一部として交渉されます。ただし、旅費がLokadの料金に影響を及ぼす可能性があることに留意してください。そのため、現地訪問の有無は最終的にはクライアント企業が決定し、Lokadは希望される頻度に応じます。

クライアント企業の目標がイニシアティブをできるだけスリムに保つことであれば、完全にリモートでの実施、すなわち現地訪問なしでも対応可能です。このアプローチは、年間売上高が1億USD未満の小規模企業や、リモートでの協力に慣れている企業（大手eコマース企業など）に推奨され、Lokadが実施するイニシアティブのおよそ半数がこのカテゴリーに該当します。

クライアント企業の目標が変革の成功率を最大化することであれば、毎月の現地訪問（必要に応じてさらに頻繁に）も対応可能です。大企業（年間売上高が10億USD以上）の場合は、少なくとも四半期ごとに1回の現地訪問またはワークショップを推奨します。このアプローチは、特に大規模なチームが関与している場合に、社内全体の整合性を確立するのに役立ちます。

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

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

定量的サプライチェーンイニシアティブでは、会議の大部分はリモートで行うべきです。ほとんどの会議は30分以内の短時間で、参加者はLokadのサプライチェーンサイエンティストとクライアント企業のサプライチェーン担当者の2名のみです。さらに、リモート会議は、各参加者が大型モニターを含む自分のコンピューター環境を利用できるため、特定の技術的タスクに有益です。特に、参加者が複雑なレポートを調査する必要がある場合にその効果を発揮します。

しかし、Lokadはクライアントとの現地会議の価値を過小評価していません。現地会議は、複雑なアイデアを伝え、視点を議論し、また双方の期待を見直すのに有利です。したがって、現地会議は定期的なリズム（例：週次、月次、四半期ごとなど）で開催することを推奨します。特に、Lokadがクライアントを招いて開催する場合、これらの現地会議は重要なイベントとみなされます。

このアプローチにより、双方ともリモート会議を控えめで便利かつ、必要な頻度で実施することが可能になります。

4.4 稼働開始の準備状況を評価するために、生産環境の品質チェック（インターフェースの設定を含む）をクライアント企業が実施する際に、あなたは支援しますか？

はい。実際、Lokadはクライアント企業の稼働開始準備評価の支援に留まらず、エンドツーエンドのソリューションに対する責任も担います。つまり、機械化されたシステム（多数のマシンの群れ）が結果を生成する場合でも、そのシステム全体に対して個人が責任を負うのです。彼らは、エンドツーエンドのデータ処理パイプラインの正確性、関連性、適切性を保証し、クライアント全体のビジネス課題も考慮に入れます。

エラーが発生しやすいソフトウェアインターフェースは特別な注意を要し、SCSはその完全性の評価を支援するための十分な体制が整っています。Lokadは、クライアント企業から履歴データを取得する入口側と、サプライチェーンの意思決定を返す出口側の双方で、その完全性を評価します。このタスクには、Lokadが特定の方法論と技術を活用しています。

稼働開始の準備を確実にするために、Lokadが活用する技術の種類については、サプライチェーン向けプログラミングパラダイムを参照してください。

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

はい。移行は当社の共同運用マニュアル（JPM）に文書化されています。この包括的な文書はLokadのサプライチェーンサイエンティスト（SCS）によって作成され、サプライチェーンの実務担当者とエグゼクティブが、プロセスを十分に理解できる優れた資料にアクセスできるようになっています。SCSは、この文書が非技術的な読者にも理解可能であるよう特に努めています（ただし、一部の付録はかなり技術的な内容を含む場合もあります）。

また、Lokadのデュアルランアプローチは、従来のプロセスから新ソリューションへの円滑な移行を確実にするために特有のものです。この「デュアルラン」とは、Lokadがイニシアティブの全範囲にわたって従来の意思決定プロセスと並行して稼働する実践を指します。これは、Lokadによる従来意思決定プロセスのロボット化された特性のおかげで可能となり、LokadのSCSが実装した数値レシピが実際の稼働開始前に数週間、全範囲で本番環境下で安定して稼働していることを保証します。

なお、このようなデュアルランは、競合他社が提案する代替技術や方法論では通常実現できません。実際、競合他社はサプライチェーンの意思決定をロボット化していないため、デュアルランに伴うオーバーヘッドが大きくなります。その結果、デュアルランはせいぜい生産条件を十分に反映しない狭い範囲でのみ実施され、スコープの後期拡大が、完全なスコープでのデュアルランがあれば完全に防げたはずの生産事故に繋がることになります。

4.6 パイロットランのスコープ、タイムライン、および成功基準を、クライアント企業にレビューおよび承認してもらうために提供しますか？

はい。スコープは常に、Lokadとクライアント企業との契約に詳細が記載されています。通常、これは特定の拠点や業務システムにおける、在庫補充や在庫配分などの特定のサプライチェーン意思決定の形態をとります。

The timeline is typically under 6 months (from kick-off to production). While a projected timeline is always included in our commercial proposal, it might not be specified in the contractual agreement. The binding timeline represents a mutual commitment, and the pace of the Lokad initiative depends on the timely execution of certain steps by the client company, notably the construction of a data pipeline to Lokad.

成功基準に関しては、意思決定は常にクライアント企業によって一方的に行われます。私たちはこの意思決定を支持する指針を文書化することはできますが、一方的でない決定は通常考えにくいです。つまり、クライアントがそう判断しない限り、ベンダーがパイロットを成功と決定すべきではありません。

詳細は Project Implementation & Management 1.2 を参照してください。

この繊細な点については、Assessing the Success of a Quantitative Supply Chain Initiative をご参照ください。

4.7 データの適切性、システム構成とアプリケーションの準備状態、プロセス／システムの遵守、及び全体の目的適合性を保証するために、パイロットランの実施を組織しますか？

はい。原則として、供給チェーンの最適化を目的としたパイロットを、本番導入を前提とした「実際の」プロジェクトと同様に扱います。実質的には、供給チェーン最適化に関して、十分なパイロットと本番使用が承認された事前生産環境は区別がつきません。

Lokadのサプライチェーンサイエンティスト（SCS）チームが上記すべての責任を担います。私たちの経験では、何年も（あるいは何十年も前に）デジタル化を実施した企業では、データの十分性に問題が生じることはほとんどありません。購入、製造、在庫、販売を追跡する業務システムが存在すれば、そのプロジェクトはほぼ必ず十分なデータを持っています。重要なのは、本来供給チェーンの最適化を支援するために収集されなかったデータをどのように活用するかという点です。

この点に関する詳細は bad data を参照してください。

5. 変更とリスク管理

5.1 プロジェクト実施に伴う変更管理を支援するため、クライアント企業にどのようなサポートを提供できますか？

すべてのクライアントは、Lokadのサプライチェーンサイエンティスト（SCS）の全面的なコミットメントを受けます。彼らは供給チェーン最適化プロジェクトの技術的および非技術的要求に対処するための訓練を受けており、以下のように変更管理プロセスを支援します：

• クライアント企業に雇用されている供給チェーン担当者向けに、既存プロセスの改善を提案すること。
• クライアント企業のメンバー／チームを対象としたオンボーディング用のトレーニング資料を作成すること。
• 供給チェーンにもたらされた変化の影響を、ドル、ユーロまたはクライアントの選択する通貨で定量化し、供給チェーン管理を支援すること。

変更管理は、SCSにとってかなりの時間的コミットメントを必要とする場合があることに留意する必要があります。各SCSは供給チェーンリーダーシップの変更管理支援に特有のスキルと経験を有していますが、これは他のすべての業務と競合します。

したがって、Lokadと各クライアント間で交渉される契約条件には、プロジェクト支援に利用可能なリソース、すなわちSCSチームの規模が明示されています。通常、私たちの商談書ではSCSによるある程度の変更管理サポートが想定されていますが、クライアントから明示的に要求されない限り、「大規模」な変更管理支援は反映されません。

5.2 生産フェーズにおける変更管理のビジョンは何ですか？主要なマイルストーンは何ですか？新たな解決策の成功した実装後、新しい組織はどのようなものになりますか？

Lokadが本番稼働すると、供給チェーンに関する意思決定の一連が自動化されます。その目的は、供給チェーン業務を資本主義的な取り組みに転換することにあります。供給チェーン担当者が費やす各時間が、数値レシピの継続的改善に寄与すべきです。これは、ほとんどの労力が日々の営業維持に費やされる従来の主流の供給チェーン業務とは一線を画します。当然ながら、付加価値のある供給チェーンへの移行は段階的に進行します。

• 最初のマイルストーンは、供給チェーン担当者が、Lokadにより従来のプロセスの大部分を廃棄できると認識することです。たとえば、日々の補充数量を再検討するのは、それらの数量が頻繁に誤っている場合には意味があります。しかし、設計上、Lokadが出す数量は既に正確であり、再検討の必要はありません。実際、Lokadが生成する数値における0%の不正確さが、本番稼働の主要な基準となります。供給チェーン担当者がLokadの数値に信頼を寄せることで、多くの時間が有効に活用されるようになります。

• 次のマイルストーンは、供給チェーン担当者の中からいくつかの「早期採用者」を確保することです。彼らは通常、手動で数値を確認するといった付加価値の低い従来プロセスから早期に脱却し、供給チェーンの継続的改善に数値レシピを活用できるようになる人物です。彼らは、単なる技術的な細部を超えた多くの重要な課題に取り組み始めます（例えば、クライアント企業がサービス品質を正しい視点から評価しているかどうかなど）。

• 三番目のマイルストーンは、大多数の供給チェーン担当者が内向きではなく外向き（クライアントやサプライヤーに焦点を合わせる）になることです。最終的には、供給チェーンがクライアント企業の枠を超えた連携を実現する必要があります。これにより、得られる洞察の幅が広がり、数値レシピがさらに洗練されます。

新しい組織は、ソフトウェア企業に非常に近い形態となります。反復的な供給チェーン業務の多くは手動で行われず（自動化により）、また緊急事態も大幅に減少します。ルーチンタスクの削減により、供給チェーン担当者の業務の幅は広がります。通常、これは供給チェーン管理に費やす時間と労力が減少する一方で、増えた余剰時間と労力を活かすために従業員のスキル向上を管理陣に求めることを意味します。

この転換の詳細については、（ソフトウェア）製品指向配信による供給チェーン をご参照ください。

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

設計上、Lokadが生成する供給チェーンの意思決定はワークフローを必要としません。実際、供給チェーンの意思決定を生み出す全てのステップは自動化されることが望ましいのです。

しかし、クライアントから明示的にリクエストされた場合、従来のワークフローを模倣する「ワークフロー」を導入することが可能です。これは変更管理を円滑にするためのものであり、数値レシピの成功に必須の条件ではありません。クライアントの従業員がLokadの生成する意思決定に慣れ、信頼を築くにつれて、この「ワークフロー」は段階的に簡素化され、最終的には完全に撤廃されます。

Lokadの進化に関しては、我々のプラットフォームはプログラム可能であり、Envision（我々のドメイン固有プログラミング言語）によって管理されています。Envisionへの変更やアップデートは自動スクリプトを通じて実施され、このプロセスはLokadがホストする供給チェーンプロジェクトに影響を及ぼさないように設計されています。

5.4 課題とリスクの管理登録簿を、軽減計画、タスク、責任、タイムライン、状態（未着手、進行中、完了、保留）を含めて維持することは可能ですか？また、Lokadのプロジェクトマネージャーがすべての課題とリスクを追跡し、必要に応じて迅速な解決やエスカレーションの管理を行う責任を持ちますか？

はい。Lokadのプラットフォームは独自の内部課題／チケット／タスク管理システムを備えており、これは状態、優先順位、担当、通知など、通常期待される機能を全て提供します。さらに、我々は共同手順マニュアル（Joint Procedure Manual: JPM）を別途維持しており、そこにはプロジェクトの概要とすべての主要なタイムラインが包括的かつ整理された形で記載されています。Lokadのサプライチェーンサイエンティスト（SCS）がこのタスク管理システムの監督を担当し、問題や懸念に迅速に対応するよう努めています。

エスカレーションは可能ですが、稀な事例です。同じSCSがタスクの管理・レビューとその解決を一手に担います。Lokadの上級SCSは、供給チェーン専門家、データエンジニア、データ統合者、業務分析者、データサイエンティスト、プロジェクトマネージャー、変更コンサルタントなど、多岐にわたる役割を担います。

SCSに容易に連絡を取れる点は、クライアントが大きなメリットとして挙げるポイントです。クライアントは、複数の官僚的層を経由することなく、問題の迅速な解決を監督する担当者に直接連絡することができます。

もし、SCSの専門外のスキル（例：プラットフォームのアーキテクチャに関する技術的問題）が必要な場合でも、彼らは問題の迅速な解決を監督し、該当するクライアントの第一の連絡窓口として機能します。

5.5 業務プロセスの導入および変更、ならびに既存プロセスの廃止に伴う組織の変更管理コンサルティングを提供していますか？

はい、クライアント企業がLokadとのパートナーシップに変更管理コンサルティングサービスを含むことを希望する場合は提供します。なお、Lokadの主たる専門分野は供給チェーンの予測最適化であり、変更管理自体は専門外である点に留意してください。我々の変更管理のアプローチは、供給チェーン実務に比べて従来型のものであり、この手法を採用することで、プロジェクトに関与する第三者の数を制限することが可能となります。

また、クライアント企業がLokadを補完するために変更管理専門家のサービスを別途保持することを希望する場合、クライアントが適切と判断する範囲でサポートを提供いたします。

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

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

はい。Lokadのサプライチェーンサイエンティスト（SCS）がこのプロセスを担当します。実際、Lokadはこの優先順位付けにおいて二点で優れております。まず、SCSは自らカスタマイズを実装でき、そのため資源やタイムラインの観点から何が問題となるかを明確に把握できます。

これにより、供給チェーンにおける変更のメリットとそれに関連するコストをバランス良く評価する、専門家の意見をクライアント企業が享受できるため、優先順位付けの質が大幅に向上します。

第二に、Lokadの包括的な理念である「Quantitative Supply Chain」は、純粋に財務的視点を重視しています。したがって、SCSは、解決策に加えられる潜在的変更がもたらす影響を（ドルまたはユーロで）定量的に見積もるサポートを提供します。この戦略により、従来の何を優先すべきかという議論のボトルネックを回避し、財務的な影響が最も大きい課題を優先することが可能となります。

6.2 自動化の機会を特定し、望ましい将来のプロセスを文書化するとともに、製品機能におけるギャップを特定するフィットギャップ調査を実施できますか？また、製品機能のギャップが確認された場合、許容可能な回避策を提案できますか？

はい。Lokadのサプライチェーンサイエンティスト（SCS）がこのプロセスを担当します。初期調査はプロジェクト開始時に実施されますが、このプロセスは本番フェーズを通じて継続的に行われ、解決策の継続的改善の一環となっています。

供給チェーン最適化に関しては、ギャップは単なる「機能性」の問題ではなく、「パフォーマンス」の問題であることがほとんどです。例えば、補充数量を生成する（機能性）のみならず、生成された数量が最も利益をもたらすものであるか（パフォーマンス）が問われます。

そのため、SCSは時として追加の機能やソリューションの再設計が必要となる「パフォーマンスギャップ」の特定と解決に取り組みます。これには、全体的なパフォーマンス最適化のために機能の追加または削除が含まれます。

関連して、Lokadのプラットフォームはプログラム可能です。このため、認識される「機能性ギャップ」は、Envisionコードの数行を追加または調整することで対処できます。このプログラム可能性こそが、Lokadがクライアントごとにカスタマイズされたソリューションを提供できる理由です。

6.3 ワークショップ開始の少なくとも1週間前に、クライアント側のSME（Subject Matter Expert）の期待事項を含む、フィットギャップ分析ワークショップの詳細なアジェンダを提供できますか？

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

6.4 製品のカスタマイズ要件書を、クライアント企業と共同でレビューし承認を得ることを保証しますか？

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

なお、Lokadのプラットフォーム設計の選択により、いわゆる「カスタマイズ」の必要性は大幅に低減されます―少なくとも企業ソフトウェア業界で一般的に理解される意味でのカスタマイズはそうです。Lokadのプラットフォームはプログラム可能であり、供給チェーンの予測最適化に特化したDSL（ドメイン固有言語）であるEnvisionを活用しています。

したがって、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のプラットフォームをアップデートします。通常、これはサプライチェーンの予測最適化に特化した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では、生産データをすべて含むプロダクション環境全体の複製が、データストレージの使用量を倍増させることなく行われます。内部的には、2つの環境間で同一のデータは共有されます。さらに、我々の一定時間設計により、1つの環境の作業負荷が別の環境のパフォーマンスに悪影響を与えないことが保証されます。

しかし、ほとんどのエンタープライズソフトウェアベンダーは、主要なセットアップを単に「クローン」することでこの問題を回避します。クローン、すなわち単純な複製は容易ですが、資源の無駄遣いとなります。クローンは、環境の数に比例して必要なリソース（人員および機器）が増加することを意味し、例えば3つの環境では元のコストが3倍になります。どんなに大規模なサプライチェーンであっても、これはかなりのコストに直結します。

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

はい。『解決』と『欠陥』の微妙な定義について合意できれば、という前提で。全体として、Lokadのサプライチェーンサイエンティスト（SCS）が、取り組みの核心であるROIの向上を妨げるすべての問題の解決を担当します。一般的なシナリオでは、SCSが適切な対策とそれに伴うタイムラインを提案し、クライアント企業がそれを検証または必要に応じて更新します。

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

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

要するに、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が非技術者にも理解しやすいように設計されている点です（一部のセクションや付録はかなり技術的ですが）。

高レベルのアクション項目は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が生成する決定の質に影響を与えるため、積極的な監視と継続的な改善が推奨されます。

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

9. インシデントおよび欠陥管理

9.1 クライアント企業の稼働スケジュールに遅延が発生しないよう、必須の欠陥および変更リクエスト（クリティカルおよび高優先度の項目）を優先的に対応し、提供することを保証できますか？

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

Lokadのプラットフォームはプログラム可能であり、これはサプライチェーンの予測最適化に特化したDSL（ドメイン固有プログラミング言語）であるEnvisionによって実現されています。このプログラム可能性により、SCSは迅速に修正を提供し、要求された変更を実施することが可能であり、エンタープライズソフトウェアでは稀にしか見られない精度を実現します。

技術面を超えて、LokadのSCSは、サプライチェーン専門家、ビジネスアナリスト、データサイエンティスト、データエンジニア、システムインテグレーターなど、複数の重要な役割を果たすよう訓練されており、これにより欠陥や変更リクエストに対応するための必要な人員が自然に削減されます。彼らは、クライアントの主要な優先事項を念頭に置きながら、修正およびアップデートを提供するための十分な訓練を受けています。

また、Customization & System Functionality 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は報告された内容が最終的に問題ではないと判断された場合でも、その真の根本原因を評価します。通常、どこかに対処すべき根本的な問題が潜在しており、その問題に対処することで、Lokadは将来的に類似の問題を積極的に排除します。

9.5 インシデント管理ツール以外のチャネル（例：メール）から欠陥が報告された場合でも、適切な追跡とコンプライアンスのために、欠陥が報告された直後にツールに登録されますか？

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