市場調査に戻る
NETSTOCKは主に中小企業向けに、在庫予測、補充、サプライヤー分析、共同計画のクラウドソフトウェアを提供する。ERP記録を取り込み、在庫方針と推奨発注を計算し、計画担当者が解決する例外を示す。製品群は、買収したDemand Works事業を通じて販売・業務計画も扱う。1 18
総合サプライチェーン評価：5.4/10
| 評価軸 | 点数 |
|---|---|
| サプライチェーンの深さ | 5.0/10 |
| 意思決定と最適化の実質 | 5.2/10 |
| 製品とアーキテクチャの一貫性 | 6.2/10 |
| 技術的透明性 | 6.0/10 |
| ベンダーの真摯さ | 4.6/10 |
NETSTOCKには、文書化された補充エンジン、業務改善を報告する実名顧客、特に情報量の多い公開マニュアルがある。不確実性の処理は予測誤差だけでなくサプライヤー実績も含む。中心的な限界は意思決定の枠組みだ。補充はサービス目標、在庫バッファー、カバー期間に従い、発生する例外を計画担当者が解決する。ソフトウェアが不確実な将来にわたり、購買、移動、能力確保の最も利益を生む組合せを選ぶとは文書から確認できない。2 3
AI拡張は、その枠組みの周囲で説明と優先付けを強める。経済的に評価された自動化についての公開実績はかなり弱い。宣伝では潜在的節約が達成済み節約に変わり、多数の推奨事項がシステム運用労働の削減測定に代わる。エージェントが要約やサプライヤー連絡を一般的にするほど、この弱点は重要になる。9 20 21
NETSTOCKとLokad
NETSTOCKは顧客チームが運用するパッケージ計画アプリを販売する。Lokadはプログラム可能なサプライチェーン基盤とサプライチェーンサイエンティストを組み合わせ、顧客のデータ準備、確率的予測、経済目的、実行可能な意思決定ロジックを開発・維持する。したがって違いは仕事の分担にもある。方針設定を操作して例外を確認するのか、自動意思決定過程を依頼して継続的に改善するのか。Lokadの方法は在庫最適化の提供内容で説明される。
NETSTOCKの利点は、比較的明確なアプリ範囲と利用しやすい運用文書である。式と画面は、独自の最適化モデルを先に定義せずに採用できる、従来の在庫慣行を表す。Lokadには経済性のより深い明文化が必要だ。どの不足が利益を壊し、どの在庫が陳腐化リスクを生み、どの制約が実際に効くか。このモデル化にはサプライチェーンサイエンティストの継続作業を含む費用がかかる。
NETSTOCKの対応する限界は、選んだフィルレートが経済目的ではないことだ。需要と納品の変動が同じ二品目でも、利益、代替可能性、期限、現金需要が違えば別の購買判断が必要になる。個々に妥当なバッファーのネットワークが共有資金と資源を最善に使うとは限らない。NETSTOCKは運用方針を文書化する。Introduction to Supply Chainで展開されたLokadの設計思想は、不確実性下の金銭的判断を中心に置く。3
生産性比較には各ソリューションを維持する全員を含める必要がある。NETSTOCKの計画担当者、ERP管理者、支援担当者も、Lokadのサプライチェーンサイエンティストと同じく計上すべきだ。表計算の時間だけが減り、継続モデル保守を測らなければ比較は不完全である。
補充エンジンの仕組み
予測、在庫閾値、実際の発注
予測マニュアルは、月次の品目・拠点履歴と、一定、トレンド、季節、散発モデルのバックテストを説明する。需要型に応じて移動平均、加重平均、平滑化、季節パターンを使う。履歴のない品目はゼロ予測から始まり、前身品目へのリンクや手入力が出発点を与える。季節グループは関連品目が季節プロファイルを共有できる。これは難しい需要パターンの処理が文書化された統計予測であり、公開された機械学習上の画期的発明ではない。6
発注は、手持ちと未着供給を足し引当を引いた正味在庫を、安全在庫とリードタイムをカバーする所要量と比較する。補充が発動すると目標は補充周期も含む。将来カバー計算は、それぞれの将来期間の予測で連続する期間を数量へ換算する。そのため、各期間に固定の過去平均を掛けるのでなく、季節のピークに反応する。2 7
これは単なる画面助言でなく、業務数量を生む。限界は規則に埋め込まれた目的だ。システムは方針で定めた目標へ補充する。公開文書は、現金不足時の競合購買の金銭的順位や、異なる商品間で値引き、期限、失注をどう比較するかを示さない。各発注が在庫方針を守っていても、その選択が経済性を左右しうる。
需要と供給の不確実性
安全在庫は目標フィルレート、補充周期、リードタイム、予測リスク、供給リスクを含む。最低発注量は実効補充周期を延ばすことがある。需要と供給にはそれぞれ変動の尺度と日数で表すバイアス補正があり、計算を毎日更新する。したがってNETSTOCKは固定バッファーや需要だけの不確実性余裕を実質的に超える。3
予測リスクのマニュアルは、過少予測の変動と系統的バイアスを分ける。現在予測の重みと履歴不足時の代替設定も示す。サプライヤー手法は遅配と数量不足を考慮し、過去実績周りの散らばりと計画リードタイムに対する偏りを分け、両方でバッファーを調整する。4 5
この開示はリスクを考慮した補充を支える。しかし将来需要、納品日、納品量の校正済み同時分布や、それらの依存性は示さない。需要急増と供給元の混雑は同時に起こりうる。別々のリスク値へ圧縮すると、購買を不利または緊急にする組合せが見えなくなることがある。
経済的問題は欠品保護より広い。余剰品は期限切れになり、希少な空間を使い、より利益のある商品の購入を妨げる場合がある。サービス目標は競合する帰結を解決しない。欠ける証拠は、それらを一緒に価格評価し、実績が誤った仮定を示すと導入済み方針を改善する意思決定モデルである。
設定、生産性、保有コスト
NETSTOCKは年間契約で、Essentials、Advanced、Commercialの開始価格を月900、1,500、2,000ドルと公表する。上位パッケージには拡張予測、再配分、コンテナ構成などが加わり、SSOはCommercialに登場する。導入期間は通常六週間から十週間で、データとERPの複雑さに依存する。完全非公開の企業向け見積りより、ライセンス範囲を評価しやすい開示である。10
継続設定は別の費用だ。サプライヤーリスクの設定には、少ない入荷履歴に対する既定値、最小・最大リスク、バイアス上限、極端なリードタイムのフィルターがある。文書は全体上限が品目差を隠すと警告する。リスク余裕を減らせば在庫を解放できるが不足への曝露は増え、その交換が妥当かは経済判断として残る。24 25
Event Correctionは、乱れた販売月を選んだ通常月に置換し、リードタイム計算から購買月を除外できる。設定は全品目へ一律適用される。基礎過程が変わったなら例外的観測の除去は妥当だが、再発リスクを表すなら危険だ。モデルに不都合だからといって混乱が無関係になるわけではない。どの履歴が有益かを判断し、結果の購買を確認する作業が残る。23
新しいDemand Planning業務は、計算、作業、最終という予測状態を追加する。計画担当者は値を修正・上書きし、反応性と季節性を調整し、プロファイルを再利用して後続利用向けに確定する。この制御は柔軟性を与える一方、誰かが維持すべき状態を生む。変更した仮定は承認予測と補充計算へ届く必要があり、その効果を後から評価しなければならない。26
AI機能が自動化するもの
AI Opportunitiesは、拠点間再配分を含め、不足、余剰、過剰発注の九種類を特定する。拠点権限を守り、利用者に推奨確認とフィードバックを求める。AI Packは画面と品目状態を説明し、データ問題を特定し、安全在庫を説明し、サプライヤーや顧客向けメール案を作る。これらは特定可能な製品機能だ。8 9
主に既存の分析担当者の業務を速める。メール案でも、納入を早める、取り消す、代替する、不足を受け入れるという本質的選択は操作者に残る。価格ページはAI Order Optimizerを、発注行を確認対象として示す機能と説明する。名称だけでは購買ポートフォリオの新最適化を証明しない。10
現在のAIページは、Regaloによる計画時間のほぼ半減と、Nightingaleによるチーム一名追加に相当するとの証言を載せる。労働削減を支えるが、元の作業量も全過程に残る作業も明かさない。同ページはすべての行動を明示的に利用者に残す。個別確認の高速化と、品揃え、拠点、サプライヤー、例外に比例して増える労働は共存できる。21
顧客成果と経済的責任
Adventure Operationsは、フィルレート95%を維持しつつ一年未満で過剰在庫を30%超削減したと報告する。これは全在庫30%削減ではないという違いが重要だ。事例は、毎月ほぼ二週間の分析準備を自動報告へ置換し、在庫削減後の空き倉庫を賃貸したとも説明する。賃料は業務改善を財務利益へ結び付けるが、金額も導入・運用全費用も公表しない。15
B&Gは十八か月で欠品61%削減とフィルレート80%から93.6%への改善を報告する。六か月は表計算をNETSTOCKと並用し、責任者は市場変化に合わせた予測修正の継続必要性を説明する。要約欄はNetSuiteと別の過剰在庫成果を挙げるが、本文はBusiness Centralと欠品数値を挙げる。この編集上の不一致は、正確な実績記録としての信頼性を弱める。16
The Little Potato Companyはフィルレート90.9%から98%への上昇を報告し、流通需要を生産と部材調達へ結ぶと説明する。有限能力計画は既達成導入でなく将来段階とされる。範囲は単純な完成品購買より広いが、成果は統合能力最適化を検証しない。17
GRPI事例はAIへの寄与帰属に特に示唆を与える。約150万ドルの過剰在庫発見、可視性向上、同一供給元からの購買調整を説明する。発見は在庫価値の回収ではない。NETSTOCKとFishbowlとともに行ったERPデータ整理と業務変更も強調する。それらは導入の費用と実質の一部である。28
顧客証拠は旧手順に対する実務改善を裏付ける。しかし契約料、導入、データ修復、設定、継続計画時間を差し引いた一般的純収益は示さない。説得力ある経済評価は、検出した余剰残高をすべて回収可能節約とせず、廃棄損と失注を含む実際の購買と帰結を追う。期待収益が出ないとき、欠陥モデルや慢性的データ失敗を誰が修正するかも特定するだろう。
技術の歴史と実現
NETSTOCKの歴史は、確立した在庫アプリが計画、さらにAI支援運用へ拡大する姿を示す。重要なのは、その名称の下で数値エンジンと運用労働がどれだけ変わったかだ。
| 時期 | 公開証拠 | 実現と経済的意味 |
|---|---|---|
| 2009–2021年 | 買収発表はNETSTOCK創業を2009年、Strattamの過半投資を2020年、Demand Works買収を2021年12月とする。Demand Worksは機械学習として宣伝された予測と有限能力計画を持ち込んだ。18 | 実際の製品群が加わった。しかし学習アルゴリズムや共同経済最適化は説明・実証されない。 |
| 買収後 | 顧客移行ページはDemand Works文書とダウンロードをShareFileに残し、専用IBP支援アドレスを保持。19 | 共通所有だけでは一つの文書化されたエンジンにならない。現在の安全文書もInventory AdvisorとPredictor IBPを区別する。 |
| 2025年8月 | Opportunity Engineが百万件の推奨を突破。NETSTOCKは顧客75%に50,000ドル超と評価された機会を少なくとも一つ示したと発表。20 | 推奨量と潜在価値は、完了行動、実現利益、純労働削減を測らない。 |
| 2026年2月 | NETSTOCKは42テラバイト、1,300億件のデータ湖、200億ドル超の潜在在庫価値創出、エージェント型AIへの道筋を宣伝。前年12月の追加をSafety Stock ExplainerとInventory Email Agentsと特定。22 | データ量は予測校正や購買改善の証拠でない。名指しされた機能は既存業務周辺の支援を広げる。 |
| 現在の製品 | 公開マニュアルは在庫・リスク計算を詳しく説明し、AI方針ページは顧客75%が50,000ドル以上の節約を得るとする。3 21 | 強まった節約主張は以前の潜在機会統計との整合説明が必要だ。顧客群の会計は伴わない。 |
2021年買収発表は、手法や比較評価を示さずDemand Worksの機械学習を挙げる。分離された文書が続き、その主張が何を届けたかの明確な公開説明はない。18 19 後のエージェント表現は将来意図を具体化するが、実証された生産性はなお人による推奨処理に依存する。
精度宣伝も似た問題を持つ。NETSTOCKの統計記事は、三か月先の機械学習予測精度90%という外部由来の主張を、指標、集約、データ、品目・拠点実績なしに繰り返す。それらの定義から離れた百分率は補充品質を立証しない。需要を滑らかな集計へまとめても、個々の購買がより利益を生む証拠にはならない。27
ソフトウェア構成要素とセキュリティ
公開技術証拠は、複数技術による従来型Webアプリを説明する。また一般的な「クラウドSaaS」より具体的な展開モデルも示す。
| 要素または境界 | 帰属可能な証拠 | 帰結 |
|---|---|---|
| アプリ開発 | 日付不明の雇用主紹介はRuby/Rails、Java、C#/.NET Core、JavaScript、Vueを挙げる。13 | 複数実行環境の保守が必要。現行製品モジュールへの対応はない。 |
| データとメッセージング | 同紹介はPostgreSQL、MySQL、Redis、RabbitMQを挙げる。13 | 永続化、キャッシュ、メッセージングの各責任は非公開。 |
| 配布と運用 | 本番に近いDocker開発環境、Gitレビュー、段階展開、マイクロサービスへの漸進移行を説明し、KubernetesとTerraformも挙げる。13 | サービス分割の時期と現在範囲は不明確。 |
| ERP転送 | コネクターは通信サーバー経由で圧縮CSVを交換。通常入力は毎日で出力はより頻繁に返る。12 | リアルタイムAIは日次入力を最新化しない。速い分析と新しい元データは別能力。 |
| ホスティング | 安全文書はLinode、Hetzner、Ionos、地域別AWSを挙げる。11 | 場所と選択肢であり、各顧客が四社すべてを必要とする証拠ではない。 |
| 報告アクセス | Data Sourceは資格情報とIP許可一覧で保護したMySQL接続を公開する。14 | 具体的な抽出経路だが、実行可能な計画モデルは公開しない。 |
要素数は保守の問いを生む。どのデータベースと実行環境が不可欠か、どれが買収製品に属するか、更新をどう調整するか。根拠あるモジュール対応と現行版方針のほうが、長い技術一覧より答えを与える。雇用主紹介には.NET Core 2.0さえあり、情報の鮮度は不確かで、現在使用する版は確定できない。
セキュリティマニュアルは、顧客別アプリ・データベース実体、顧客が制御する支援アクセス切替、一時的支援資格情報、可視アクセスログを指定する。認証の文言より具体的なアクセス制限だ。任意の二要素認証、暗号化して地理的に分離した日次バックアップの十四日保持、自動フェイルオーバーの不採用も文書化し、後者は明示的に費用抑制のためとする。11
この可用性の選択は運用に反映すべきだ。購買が日次計算に依存するなら、アプリ停止時の実用的対応が必要である。AI文書はモデル供給者の境界、プロンプトインジェクション対策、推奨を業務制約へ照らす方法を示さない。人の実行を必須にすれば無人実行は減るが、助言の妥当性や全AI処理段階の機密保護は証明されない。
サプライチェーン評価
サプライチェーンの深さ
| 基準 | 点数 |
|---|---|
| 経済的な枠組み | 5/10 |
| 意思決定の到達点 | 7/10 |
| サプライチェーン概念の明晰さ | 6/10 |
| 時代遅れの原則からの独立性 | 3/10 |
| KPIの見せかけへの耐性 | 4/10 |
平均：5.0/10
経済的な枠組み — 5/10。 在庫投資とサービス損失は重要で、空いた倉庫の具体的用途も事例にある。最適化目標はなお方針から導く在庫位置だ。高いフィルレートも少ない在庫も、最も価値ある購買を選んだ証拠ではない。3 15
意思決定の到達点 — 7/10。 推奨発注は文書化された戻り経路でERPへ届く。予測報告だけより実行に近い。発注承認は、競合する資金用途から最善を自動選択・実行することとはなお異なる。2 12
サプライチェーン概念の明晰さ — 6/10。 数量不足を含むサプライヤー変動と系統的遅延の分離は、実際の購買問題を反映する。未解決なのは、そのリスクを代替や延期を含む選択肢の経済性へ結ぶことだ。5
時代遅れの原則からの独立性 — 3/10。 フィルレート目標、カバー期間、在庫分類、計画担当者の介入が構成原理のままだ。運用制御として便利でも、明確な経済目的の代わりにはならない。3 10
KPIの見せかけへの耐性 — 4/10。 実名事例は特定できる業務変更を示すが、宣伝は潜在機会、実現節約、区別のない精度を安易に行き来する。比較に必要な会計はない。16 20 21 27
意思決定と最適化の実質
| 基準 | 点数 |
|---|---|
| 確率モデルの深さ | 6/10 |
| 独自の最適化またはMLの実質 | 4/10 |
| 現実の制約への対応 | 6/10 |
| 意思決定の自動化と労働生産性 | 5/10 |
| 現実の業務複雑性への耐性 | 5/10 |
平均：5.2/10
確率モデルの深さ — 6/10。 供給と需要の両方が不確実性余裕へ寄与する。足りないのは、別々の要約をバッファーに換えるのでなく、共同の将来挙動と経済結果の分布を検証済みで表現する段階だ。4 5
独自の最適化またはMLの実質 — 4/10。 予測手法は従来構造と分かる程度に文書化される。独自の数値優位を示す公開実験はなく、生成支援自体は補充目的を変えない。6 9
現実の制約への対応 — 6/10。 最低数量、将来需要期間、ネットワーク再配分、生産・部材依存は有意義な機能だ。個々の制約が表現されても、それら全体の協調配分を示さない。3 7 8 17
意思決定の自動化と労働生産性 — 5/10。 報告と診断は大きな手作業をなくせる。残るボトルネックは誰かが判断し実行する行動の流れだ。判断量が増える際の総労働変化を示す全過程の公開測定はない。15 21
現実の業務複雑性への耐性 — 5/10。 混乱後に仮定を変える手段はある。持続改善には方針失敗の診断、再定式化、結果の再テストも要る。そうしなければ全体的履歴補正と上書きが増え、経済性は示されない。holimizationが扱う問題である。23 26
製品とアーキテクチャの一貫性
| 基準 | 点数 |
|---|---|
| アーキテクチャの整合性 | 6/10 |
| システム境界の明確さ | 7/10 |
| セキュリティへの真摯さ | 7/10 |
| ソフトウェアの簡潔さと保有コスト | 6/10 |
| プログラム的・エージェント支援運用への適合性 | 5/10 |
平均：6.2/10
アーキテクチャの整合性 — 6/10。 アプリとコネクターの関係は理解できる。買収製品と複数実装技術は、どの計算がモデルを共有し、どれが別調整を要するかなど重要な内部境界を残す。12 13 19
システム境界の明確さ — 7/10。 転送文書は抽出、通信、アプリ処理、結果返却を分ける。一般的統合主張より、実際の鮮度と実行限界を評価しやすい。12
セキュリティへの真摯さ — 7/10。 テナント分離と制限・観察可能な支援アクセスは有用な設計機構だ。AI処理境界と復旧保証はそれほど明示的でない。評価は監査バッジでなく、Lokadの安全原則と整合するこれらの機構に基づく。11
ソフトウェアの簡潔さと保有コスト — 6/10。 公開価格は費用の重要部分を示す。より大きな不確実性は、ベンダーの複数実行環境保守に加え、方針制御とデータ維持の労働だ。10 13 24
プログラム的・エージェント支援運用への適合性 — 5/10。 ファイル交換とデータベースアクセスは実用的な統合経路だ。顧客が全意思決定ロジックをプログラムで版管理、テスト、置換できるとは公開仕様から確認できない。対話説明はその境界をなくさない。12 14
技術的透明性
| 基準 | 点数 |
|---|---|
| 公開技術文書 | 8/10 |
| ベンダー仲介なしの検証可能性 | 6/10 |
| 移植性と囲い込みの可視性 | 5/10 |
| 導入手法の透明性 | 6/10 |
| 技術主張を支える証拠の密度 | 5/10 |
平均：6.0/10
公開技術文書 — 8/10。 重要な既定値、リスク補正、発注規則、業務限界を説明する。残る空白は厳密な数値実装、現在の展開依存、AIサービス内部である。2 4 24
ベンダー仲介なしの検証可能性 — 6/10。 読者は営業実演前に計画ロジックの多くを再構成できる。計算再現と代替経済方針の試験には、公開資料にないアクセスが依然必要だ。6 7
移植性と囲い込みの可視性 — 5/10。 データベース抽出が文書化され、解約方針は三か月保持期間中の全データ出力を提供する。記録の出力は予測設定、決定規則、別エンジンでの動作の移植性を証明しない。11 14
導入手法の透明性 — 6/10。 コネクターと設定ガイドは実際の導入・運用作業を特定する。事例はデータ整理と並行運用を加えるが、全作業量や反復するモデル失敗の責任分担は測らない。12 16 28
技術主張を支える証拠の密度 — 5/10。 補充文書はAI差別化の主張より強い。データ湖規模も提案件数も、判断改善の再現可能な検証ではない。6 20 22
ベンダーの真摯さ
| 基準 | 点数 |
|---|---|
| 公開発信の技術的真摯さ | 4/10 |
| 技術ロードマップの一貫性 | 5/10 |
| 概念の明晰さ | 5/10 |
| 経済的責任 | 4/10 |
| エージェント型ソフトウェア時代の競争優位 | 5/10 |
平均：4.6/10
公開発信の技術的真摯さ — 4/10。 マニュアルは宣伝が曖昧にする制約を露呈するほど正確だ。速い提案でも元記録の遅延はなくせず、機会評価を黙って達成節約に変えてはならない。12 20 21
技術ロードマップの一貫性 — 5/10。 買収した計画能力と後のAIツールは製品内の対応を特定できる。過去の機械学習表現と現在のエージェント志向には、総労働を減らし数値判断を実質改善する進歩の実証がなお欠ける。18 22
概念の明晰さ — 5/10。 NETSTOCKは実務的な補充失敗を理解し、原因を伝える。概念上の限界は、目標方針の管理改善を最適化の十分な証拠とする点で、良い判断を定める金銭的交換条件は未発達だ。3 5
経済的責任 — 4/10。 顧客記録は有用な結果を含むが、広い節約主張も事例も全費用補正を公表しない。データ修復と継続介入が大きくなると、許容できる経済結果の責任は不明確である。15 21 28
エージェント型ソフトウェア時代の競争優位 — 5/10。 ERP接続、業務知識、稼働中の補充計算にはチャット以上の実質がある。守れる機会は判断そのものの自動化と改善だ。説明やメール助手を増やしても継続計画作業の多くは残る。8 9
出典
全出典を2026年11月4日に閲覧。以下の日付は、存在する場合の公開日または表示更新日である。
Netstock製品。製品範囲と想定業務利用者。
発注水準の説明。在庫位置、発注契機、補充目標計算。
安全在庫の理解。日付2026-09-15。リスク入力と発注量の相互作用。
予測リスクと補正の説明。日付2026-09-15。需要変動、偏り、設定。
供給リスクと補正の説明。日付2026-06-04。計画バイアスから分離した納品・数量不確実性。
需要型と販売予測生成の説明。日付2026-05-26。予測群、モデル選択、少ない履歴での動作。
将来カバー期間の説明。カバーを数量へ換算する連続将来期間。
AI Opportunities機能。日付2026-08-21。九種類の機会、アクセス境界、残る確認業務。
AI Pack機能。日付2026-08-21。説明、データ問題診断、メール作成。
Netstock製品パッケージ。開始価格、年間条件、パッケージ境界、導入期間。
セキュリティと準拠。日付2026-02-26。分離、支援アクセス、バックアップ、ホスティング、退出時保持。
ERPコネクター。日付2026-02-09。抽出頻度、通信経路、戻りファイル。
NETSTOCK雇用主紹介。雇用主に帰属する技術一覧と開発手順。日付不明。
IP許可一覧。日付2026-02-26。報告データベースアクセスとネットワーク制御。
Adventure Operations事例。余剰削減、サービス、報告作業、解放空間。
B&G事例。顧客成果と不一致のある要約欄。
[17] The Little Potato Company事例
The Little Potato Company事例。流通、部材計画、達成フィルレート、計画中の能力拡張。
NETSTOCKがDemand Worksを買収。日付2021-12-06。投資家発表と過去の機械学習主張。
[19] Demand WorksがNetstockの一部へ
Demand WorksがNetstockの一部へ。買収後の顧客支援と文書配置。
[20] Opportunity Engineが百万件の推奨を突破
Opportunity Engineが百万件の推奨を突破。日付2025-08-28。潜在機会価値の当初表現。
当社のAI方針。現在の節約表現、顧客発言、人の行動。
Netstockが29%成長を達成。日付2026-02-18。データ湖規模、潜在価値、エージェント型ロードマップ。
イベント補正の説明。日付2026-02-26。履歴補正と全体適用。
サプライヤーリスク限度：最大補正。日付2026-02-26。リスク上限、フィルタリング、明示された業務トレードオフ。
サプライヤーリスク既定値。日付2026-02-24。供給元観測が少ないときの既定値。
需要計画：予測の調整。修正、承認、保持される設定。
在庫管理統計の総覧。必要な測定定義なしの精度主張。
GRPI事例。発見された余剰在庫、サプライヤー群分け、導入作業。