市場調査に戻る
INFORMは、製造、流通、物流、航空、金融サービス向けの業務計画ソフトウェアを開発しています。ADD*ONEスイートは、需要計画、在庫補充、量産計画を組み合わせます。ERPに接続し、予測、購買推奨、生産計画を計算します。顧客は、オンプレミス、INFORMのSaaS、自社クラウドのいずれでもADD*ONEを展開できます。1
サプライチェーン総合評価：5.0/10
| 評価領域 | 点数 |
|---|---|
| サプライチェーンへの理解の深さ | 5.8/10 |
| 意思決定と最適化の実質 | 5.2/10 |
| 製品とアーキテクチャの整合性 | 5.2/10 |
| 技術的透明性 | 4.0/10 |
| ベンダーの真摯さ | 4.6/10 |
INFORMには業務上の実質があります。ソフトウェアは補充を決め、生産制約を調整し、顧客は在庫や事務作業の削減を報告しています。弱点は、確認できるこれらの機能と、AIによる包括的最適化という主張との隔たりです。公開資料では、数値的目的も不確実性のモデル化も十分に明かされず、その意思決定がサプライチェーン全体の経済的リターンを最大化するとは確認できません。
運用モデルは、予測、計画パラメーター、自動化された標準ケース、人による例外処理の組み合わせです。多くの作業を減らせますが、例外によって費用、供給、利用可能な行動に対するソフトウェアの理解を変える必要が生じると、限界が見えます。公開文書は、計画担当者がシステムをどう使うかに比べ、基盤の意思決定ロジックをどう修正しテストするかを十分に説明していません。
INFORMがAIの失敗を技術ではなく組織に帰しているため、この制約は特に重要です。業務の事実を取り込み、不完全なデータを表現し、失敗を診断可能にすることは、製品の技術的責務です。これを主として組織の問題と扱えば、約束したリターンへの責任が弱まります。19
INFORMとLokadの比較
比較するのは、業務の意思決定をどう生み、改善するかです。INFORMは、既存の計画プロセスを中心に業界別アプリケーションを提供します。ADD*ONEは、計画担当者が設定、監督、補足するシステム内で、発注と生産を計算します。Lokadとの重なりは、購買、在庫、生産の意思決定です。
Lokadの在庫最適化アプローチは、不確実な未来における行動候補の金銭的結果から始めます。需要、供給、リードタイムの不確実性から、優先順位付きの購買、配分、生産判断を生成します。サプライチェーンサイエンティストが、実行可能な意思決定ロジックとデータ準備を維持します。Introduction to Supply Chainに示された広い設計思想は、組織を予測に合意させるより、経済的な意思決定を継続的に改善することです。
この違いは、最適とされる計画が失敗したときに重要になります。仕入先の遅延、不良ロット、高価な最低発注量によって、モデルが結果を見落としたりデータを誤読したりしたと分かる場合があります。生産的な対応は、実行ロジックを改め、関連する意思決定全体で修正をテストすることです。Holimizationは、問題そのものに対するこの継続作業を説明しています。
INFORMの公開根拠は、検証・改訂できる経済モデルより、確立した業務機能と実名顧客の成果のほうが充実しています。比較には、両社の専門家、顧客による確認、後続のモデル変更の費用と、それらが生む金銭的改善を含める必要があります。
ADD*ONEは実際に何を決めるのか
購買と生産は実務に使える結果を出す
Inventory Optimizerは、補充する品目、数量、時期、仕入先を特定します。公開範囲には、最低発注量、リードタイム、在庫目標、倉庫間移送が含まれます。重要な行動であり、実行を自動化する機会があります。2
量産計画は、工程間のロットサイズ、段取りのグループ化、材料の可用性、機械能力、最小生産量、ロット制限へと意思決定空間を広げます。INFORMは、費用に基づく外注と内製・購入の代替案も説明しています。実装には顧客固有の実行可能性の考え方が含まれます。3
これらは需要ダッシュボード以上の仕組みです。同時に中心的な問いを浮かび上がらせます。どの費用と不確実性が選択を決めるのかという問いです。能力と材料の制約を組み合わせることは有益ですが、販売機会の損失、供給遅延、期限切れ、運転資本、希少資源の代替用途が同じ計算へどう入るかは分かりません。
INFORMのオペレーションズリサーチの説明は、目的と制約の数学モデルを作り、その後に良い決定や最適な決定を探索すると述べます。ADD*ONEの定式化、ソルバーの名称、再現可能な比較は示しません。5 したがって、数学的な最適性も会社の研究実績も、そのサプライチェーンモデルの経済的妥当性を証明しません。
需要の区間だけでは同時不確実性は示せない
Demand AI Forecasting Serviceは、需要予測とリスク区間を提供します。評価案は三年分の販売データを使う六か月のバックテストです。公開ページには、予測の起点、調整用データの分離、較正、実際の発注期限での比較が明記されていません。4
供給側が欠けていることは重大です。補充日、利用可能数量、生産歩留まりも不確実なら、需要分布だけでは足りません。入力の仮定が材料の時間どおりの到着を保証すれば、計画は安く見えます。リードタイムの入力や別シナリオの検証だけでは、将来供給の学習された分布、需要との依存関係、意思決定選択への組み込みは示せません。
同じ問題は商品間や工程間にもあります。安全在庫と共通の計画システムがあっても、代替、共通仕入先、能力の競合、相関する欠品を一体的に扱うとは限りません。INFORMは、この主張の評価に必要な表現と較正を公開していません。
量産ページは、能力が限られていても納期を守り、配送遅延を避けることも約束します。3 供給や能力不足によって約束が両立しなければ、どんな最適化ソフトウェアも保証できません。そのとき経済的に意味がある課題は、どの約束をどの期待費用で断念するかを選ぶことです。実行可能性の約束は、そのトレードオフを隠します。
予測の合意は設計に残っている
ADD*ONE Demand Planningは、品目、顧客、地域、商品群ごとの表示と、需要についての全社合意を支援します。S&OPの提供内容は部門をつなぎ、シナリオで計画を調整します。24 25
集約は事業を把握する助けになりますが、平滑な地域予測が、個別品目・拠点の必要数量を検証するわけではありません。関連する予測は、意思決定の粒度と期間で評価すべきです。合意プロセスに価値があるのは、その追加情報が後段の決定を十分に改善し、調整作業を回収できる場合だけです。
INFORMの公表する割合にも同じ厳密さが必要です。需要ページの「最大90%」は計画作業の削減、在庫ページの97.5%は顧客の商品可用性です。どちらも予測精度の結果ではありません。24 26 より本質的な弱点は、予測手法と評価が不十分なため、予測改善を追加の金銭的リターンに結び付けられないことです。
顧客成果、生産性、設定保守
四つの事例が、提案の異なる部分を明らかにします。
| 顧客 | 公開された結果と範囲 | 経済的な解釈 |
|---|---|---|
| hagebau connect | ADD*ONEおよび他の在庫削減施策により、六か月で在庫が30%減少。Microsoft Business Centralに接続し、手動の調達工程を置き換えています。7 | 実名顧客の在庫改善ですが、複数施策の成果であり、解放された資金は継続利益ではありません。 |
| A. Raymond GmbH & Co KG | 25,000品目と13,000資源について、平均在庫価値が約10%、段取り時間が10%、手動計画の所要時間が60%超減少したと報告しています。8 | 段取りの改善は生産費用の要因に届いています。計画時間の短縮だけでは、総人員削減は特定できません。 |
| medi | ADD*ONEを2016年から使用。数百万規模の在庫削減、定型発注の自動化、補充不要となったフルタイム職一人分を報告します。9 | 補充しなくてよくなった職は具体的な労働成果です。在庫の主張にはなお純リターン計算がありません。 |
| Schäferbarthold | 一品目に最大30社の仕入先があり得ます。ADD*ONEが仕入先と発注の選択を支援し、納品可能性は10%超改善したとされています。10 | 仕入先選択は単一調達先の補充より実質的に豊かです。指標の基準値と改善費用は不明です。 |
A. Raymondはさらに、納入指示の予測可能性がほぼ倍増したと報告しますが、指標を定義していません。8 特定の予測誤差や金銭的利益には換算できません。それでも事例には認識できる業務変更があります。限界は、便益と利用料、実装、顧客の労働、継続支援との照合がないことです。
mediの説明は、自動化率の見出しから消える保守を示しています。要件が変わると、担当者は新しい選択条件を作ります。INFORMとmediは、仕入先の確認をADD*ONEに戻すポータルを共同開発し、2023年夏から使用しています。9 これは実際の継続対応とアプリケーション開発です。同時に、有用な自動化の費用には、プロセスを適応させる人も含まれることを意味します。
INFORMの2026年7月の自動化記事は、その依存を明示します。補充時間、サービスレベル、倉庫費用率、仕入価格、例外閾値、優先順位、エスカレーションルールを維持しなければなりません。標準ケースは自動処理し、未解決の乖離は計画担当者に渡します。6
この設定も意思決定ソフトウェアの一部です。仕入先の悪化には、リードタイムの解釈、利用可能な購買代替案、待機費用の見直しが必要かもしれません。バッファを増やす、警告を加えるだけなら、旧モデルを維持したまま高価にしてしまいます。公開資料は、これら相互作用するルールのバージョン管理、履歴再実行、回帰テスト、ロールバックを説明していません。
したがって2022年以降の生産性の問いは、計画担当者がリストを速く処理できるかより厳しいものです。修正された失敗は再利用可能なロジックになって将来の待ち行列を減らすのか、それとも組織は引き続き人を雇って失敗を認識・解決させるのか。mediの既存自動化は信頼できる基準を与えます。新しいAI機能は、同等の経済成果で、さらに労働を削減する必要があります。
別提供の予測サービスは、意思決定と上書きを明示的に人へ残し、既存プロセスを保ちます。4 可能な貢献は限定的です。よりよい入力と、より少ない予測保守です。自律的なサプライチェーン意思決定には別の実証が必要です。
技術の歴史：業務の継続性と拡大するAIの主張
INFORMは1969年にオペレーションズリサーチから始まり、その後、生産、物流、航空、人員管理、リスク管理の別々の製品を築きました。11 重要な歴史は、それぞれの製品内で具体的な機能がどう提供されたかです。
| 時期 | 公開された主張または提供 | 記録から確認できること |
|---|---|---|
| 2017年 | 航空顧客フォーラムで、遅延予測や他の空港業務への機械学習を議論しました。27 | 用途と顧客の議論は特定できますが、記事には導入モデルの定量的成果がありません。 |
| 2018年12月 | 物流記事はクラウドAI経路計画を推進し、100%の定時配送を約束しました。12 | 説明された仕組みは制約付き輸送計画です。絶対的なサービスの約束は、不確実な業務で可能な範囲を超えています。 |
| 2019年6月 | 機械学習の記事は、製造工具データのクラスタリングを含め、教師あり・教師なし学習を説明しました。13 | 限定的な技術課題は特定できますが、企業全体の一般的知能は示しません。 |
| 2024年の回顧 | INFORMはSYNCROTESSの初導入を1984年、SaaS版を2014年とし、中核アルゴリズムの概念は今も使われていると述べました。14 | 長寿命の業務ソフトウェアと提供済みの展開変更があります。後のML追加は、比較測定ではなく主張として示されます。 |
| 2025年9月 | ニューラルネット記事は、暦、産地、価格、販促を用いた生鮮食品予測を説明しました。16 | 妥当な予測課題ですが、構成と比較測定された性能は非公開です。 |
| 2026年3～5月 | PSAアントワープのEuropa Terminalが、ストラドルキャリアと自動積上げクレーン向けIntegrated Terminal Schedulerの導入を開始しました。岸壁クレーンの統合は2026年後半に予定されていました。18 | 実際の段階導入で、残る統合と完了作業を区別しています。 |
| 現在のプレビュー | 航空ウェビナーは、GS WorkforcePlusのFSI API向けMCPサーバーを予告します。17 | インターフェースのプレビューで、スケジューリングエンジンの改善は示されていません。 |
記録は技術の継続性と特定可能な導入を示します。同時に、AIという言葉が、経路計画、クラスタリング、予測、インターフェースという異なる仕組みを覆っていることも示します。個々の有用性では、共通の知能という主張は検証できません。
探索的なコンテナ管理ウェビナーは、ブロックチェーンの便益を疑問視し、製品提供を約束しません。15 歴史上より強い懸念は、広い便益の主張と、ほとんど明かされない手法との隔たりです。
MCPプレビューの新規性には懐疑が必要です。既存APIを包めば連携を簡単にできますが、スケジュールの品質を改善したり計画ロジックの保守をなくしたりはしません。対象はGS WorkforcePlusで、ADD*ONEの能力は独立に評価すべきです。17 プレビューには追加的な生産性の測定がありません。
現在の顧客記録は、AI用語の広さよりも、取り組みの継続をよく試します。medi向けの個別VMI開発と段階的なターミナル導入は、継続的な技術作業を示します。その経済性と後の改訂費用は、機能の提供ほど明らかではありません。
ソフトウェア構成表とシステム境界
| 構成要素または境界 | 帰属を確認できる役割 | 評価 |
|---|---|---|
| ERP接続、オンプレミス・SaaS・顧客クラウドへの展開 | ADD*ONEの公開された連携・ホスティング選択肢。1 | 運用モデルによって、更新、インフラ、障害への責任が異なる形で顧客へ移ります。 |
| EU内のAWS、HTTPSインターフェース、保守されたPythonクライアント | INFORMが運用するDemand AI Forecasting Service。4 | データ転送境界が定義された別の予測サービスです。 |
| Java/KotlinとWebアプリケーション | 日付のないINFORM Portugalの求人は、BIを含む顧客プロジェクトを特定します。21 | その開発チームに帰属しますが、ADD*ONEエンジンは特定しません。 |
| Spring/Spring Boot、JPA/SQL、Angular、Maven、JUnit、Git | 同じ求人に挙がるスキルで、複数は代替条件です。21 | 開発環境の根拠であり、全INFORM製品の導入構成表ではありません。 |
| ADD*ONEの中核データベース、最適化ソフトウェア、計画実行環境 | 確認した製品文書には名称がありません。 | 資源需要、パッチ負担、構成上の依存を独立に評価できません。 |
予測サービスは、外向きの接続を通じてデータのスナップショットを受け取ります。Pythonクライアントがあることは、サービス内で実務担当者のコードを実行することを意味しません。4
ADD*ONEで経済的に重要な不明点は、完全な決定を作るために何を一緒に運用する必要があるかです。マスターデータ同期、予測更新、最適化、例外処理、発注の戻し、そして仕入先ポータルです。ネットワークが動いていても、各意味の境界で誤りが生まれ得ます。買い手には、仕入先確認、利用可能在庫、すでに確定した発注を照合する明確な責任者が必要です。
INFORMは、機能、品目数、同時利用者数、連携要件で在庫ソリューションの料金を定めます。2 これらは所有コストの一部にすぎません。全期間の費用には、顧客ルールの変更、ERP変更に伴う接続保守、更新テスト、個別部品の改訂も含まれます。その計算なしに、自動化の主張から安価な拡張性は証明できません。
セキュリティには検証可能な技術が必要
INFORMは協調的な脆弱性開示方針を公表しています。通常は五営業日以内に受領を確認し、その確認後十営業日以内に初期回答を行い、情報の検証に応じて追加報告します。通常、別の秘密保持契約なしに報告を受け付けます。22
2026年10月22日の告知は、最近のPHP脆弱性を評価し、必要な更新を適用して、影響のある公開資産を保護したと述べます。顧客の対応は不要としていますが、対象製品のバージョンや具体的修正は特定しません。23 これは公開のインシデント連絡の根拠ですが、バージョン情報がないため独立検証は限られます。
ADD*ONEの資料は認証と審査を強調します。1 そこからは、最小権限の接続、テナント境界、破損状態からの復旧、管理者のミスの封じ込めは分かりません。Lokadのセキュリティ原則では、こうした仕組みが危険への露出を決めます。
Demand AIは、顧客データ処理から外部AI提供者を除外します。4 これは処理境界の一つを定めますが、隔離、特権アクセス、復旧の詳細は非公開です。公開根拠では、認証をこれらの設計特性の代用にすることは正当化できません。
モデルが失敗したとき、誰が責任を負うのか
INFORMの2026年7月30日のAIプロジェクト失敗に関する記事は、弱いモデルが原因だという説明を冒頭で退けます。例は、在庫の不良が判明したのにシステムへまだ反映されず、計画担当者が推奨を拒否するというものです。明確な責任、業務への統合、人の文脈知識を求める一方、全動作の承認はボトルネックになるとも認めています。19
この例は、その区別を崩します。在庫品質とデータの鮮度は意思決定問題に影響します。それを表せず、更新漏れを検知できず、再利用可能な修正を支援できないシステムには、技術的な限界があります。品質検査は顧客が管理していても、観測が推奨へ変わる過程の大部分はベンダーが管理します。
成功した決定はAIに、失敗した決定は組織の準備不足に帰すのは、非対称な提案です。改善策は、範囲を定めた運用合意です。顧客が提供すべき事実、システムによる失敗検知、診断する担当者、ベンダーの修正作業、全費用後のリターン測定を定める必要があります。
INFORMの7月の自動化記事も、自動化はもはや技術的課題ではないとし、従業員の信頼を主な障壁とします。6 定型発注の処理は技術的に成熟しているかもしれません。しかし高価な例外を、その解釈を何度も人に戻さず自動化することは、はるかに難しい主張です。
8月の自律性の記事は、定型自動化と人の管理を要する決定を区別します。20 適切な統制かもしれませんが、エンジンがどれだけ労働を減らせるか、繰り返しの修正なしに動けるほど結果をモデル化しているかは決まりません。
ADD*ONEが宣伝する満足保証は、見込み顧客のデータを用いる販売前の演習です。1 購入前の問題発見には役立ちます。しかし公開説明は、導入後の財務目標、総費用の境界、期待した利益が出ない場合の是正責任を定めません。
サプライチェーン評価
サプライチェーンへの理解の深さ
| 評価基準 | 点数 |
|---|---|
| 経済的な問題設定 | 6/10 |
| 意思決定の到達点 | 8/10 |
| サプライチェーンに関する概念の明確さ | 6/10 |
| 時代遅れの中核理論からの独立 | 4/10 |
| KPIの見せかけへの耐性 | 5/10 |
平均：5.8/10。
経済的な問題設定 — 6/10。 購買と生産は費用と資源の競合用途を含みます。しかし財務目的が非公開のため、組み合わせた決定が不足、過剰、遅延、資本を一貫して評価するかは確認できません。2 3
意思決定の到達点 — 8/10。 ADD*ONEは実行可能な補充・生産の選択に到達し、顧客の業務実績があります。これらの行動の財務的最適性は未確認です。2 9
サプライチェーンに関する概念の明確さ — 6/10。 仕入先の代替と多段階生産は重要な依存です。同時に不確実な経済システムとして扱うことは裏付けられていません。3 10
時代遅れの中核理論からの独立 — 4/10。 予測の調整、サービス目標、例外監督が構成原理として残ります。それらのパラメーターが外から設定した代理指標ではなく、財務最適化の結果であることは示されていません。6 25
KPIの見せかけへの耐性 — 5/10。 実名の業務成果は主張に実質を与えます。しかし未定義の予測可能性指標と、費用を計上しない改善率のため、見出しの数値を純経済成果に換算できません。7 8
意思決定と最適化の実質
| 評価基準 | 点数 |
|---|---|
| 確率的モデル化の深さ | 3/10 |
| 最適化または機械学習における独自の実質 | 5/10 |
| 現実の制約への対応 | 7/10 |
| 意思決定の自動化と労働生産性 | 7/10 |
| 現実の業務の複雑さに対する回復力 | 4/10 |
平均：5.2/10。
確率的モデル化の深さ — 3/10。 リスク調整した決定には、需要と供給の双方に較正された確率が必要です。共同モデルがないため、選んだ数量と時期を評価できません。4
最適化または機械学習における独自の実質 — 5/10。 INFORMは認識可能な予測・最適化課題を説明しています。しかし独自の数値的貢献を判断するのに十分な定式化、再現可能な処理負荷、統制された比較を公開していません。5 16
現実の制約への対応 — 7/10。 生産には相互作用する資源・ロット制限が含まれ、相応の顧客適用があります。重要な相互作用のうち何を省略・簡略化したかを評価するには、公開詳細が不足しています。3 8
意思決定の自動化と労働生産性 — 7/10。 mediの補充不要となった職は、具体的な生産性成果です。しかし例外、設定、個別拡張に残る労働があり、無人運用モデルへ一般化できません。9
現実の業務の複雑さに対する回復力 — 4/10。 事例には仕入先との協働と適応があります。ただしモデル失敗を、目的、データの意味、可能な行動のバージョン管理・再実行可能な変更に変える方法は説明されていません。業務の柔軟性は専門家の介入に依存します。9 19
製品とアーキテクチャの整合性
| 評価基準 | 点数 |
|---|---|
| アーキテクチャの一貫性 | 6/10 |
| システム境界の明確さ | 7/10 |
| セキュリティへの真摯さ | 4/10 |
| ソフトウェアの簡素さと所有コスト | 4/10 |
| プログラムによる運用・エージェント支援運用との適合性 | 5/10 |
平均：5.2/10。
アーキテクチャの一貫性 — 6/10。 ADD*ONEは接続された計画機能と提供済みの連携を示します。しかし数値・保存アーキテクチャは不透明で、モジュール間の一貫性や重複を検証できません。1 9
システム境界の明確さ — 7/10。 ADD*ONEのERP接続と展開選択肢には特定可能な役割があります。一方、顧客データと個別拡張を照合する責任は、そこまで明確に文書化されていません。1
セキュリティへの真摯さ — 4/10。 公開された報告方針とインシデント告知は、封じ込め、最小権限、独立した復旧を示しません。導入済みのこれらの制御は、ほとんど文書化されていません。22 23
ソフトウェアの簡素さと所有コスト — 4/10。 顧客記録は継続的な設定・拡張作業を示します。構成要素別の運用費用モデルも、意思決定を保守する費用も公開されていません。2 9
プログラムによる運用・エージェント支援運用との適合性 — 5/10。 業務連携は自動行動を支えます。別製品のMCPプレビューは、数値的決定やライフサイクル管理の改善を測定していません。2 17
技術的透明性
| 評価基準 | 点数 |
|---|---|
| 公開技術文書 | 4/10 |
| ベンダーの仲介なしでの検証可能性 | 3/10 |
| 移植性とロックインの可視性 | 4/10 |
| 実装方法の透明性 | 5/10 |
| 技術的主張を支える根拠の密度 | 4/10 |
平均：4.0/10。
公開技術文書 — 4/10。 機能ページは業務の入力と出力を説明します。数学的定義、展開構成、実行可能な例はほぼありません。2 3 5
ベンダーの仲介なしでの検証可能性 — 3/10。 評価はデモと顧客データを使う演習に大きく依存します。買い手は公開資料から独立して意思決定計算を再現できません。1
移植性とロックインの可視性 — 4/10。 ホスティングの柔軟性と外部システム接続は、いくつかのインフラ制約を減らします。しかし設定された意思決定ロジック、過去の実行、個別拡張の移植性は文書化されていません。1 9
実装方法の透明性 — 5/10。 顧客事例は連携、組織変更、ベンダーとの協働を明らかにします。数値挙動を維持するための検証と変更管理の全体像は公開されていません。7 9
技術的主張を支える根拠の密度 — 4/10。 実名事例は本番利用を示します。しかし比較決定実験や公開数値手法は、最適化の主張の広さに見合いません。5 8
ベンダーの真摯さ
| 評価基準 | 点数 |
|---|---|
| 公開発信の技術的な真摯さ | 4/10 |
| 技術ロードマップの整合性 | 6/10 |
| 概念の明確さ | 5/10 |
| 経済的な結果への責任 | 3/10 |
| エージェント型ソフトウェア時代の競争優位の持続性 | 5/10 |
平均：4.6/10。
公開発信の技術的な真摯さ — 4/10。 理解できる業務説明と、絶対的な納品約束や広範なAI主張が共存します。その約束は実行不可能性と、高価な失敗の中から選ぶ必要を隠します。3 12
技術ロードマップの整合性 — 6/10。 長寿命の製品、提供済み仕入先ポータル、段階的ターミナル導入は、発表を超えた継続性を示します。次々に使われるAIの呼称がもたらした貢献は、そこまで明確に測定されていません。9 14 18
概念の明確さ — 5/10。 INFORMは重要な業務制約と、定型決定と重大な決定の違いを理解しています。しかしモデル失敗の組織的説明は、技術責任を業務文脈から都合よく切り離しています。19 20
経済的な結果への責任 — 3/10。 公開成果には、TCOを差し引いた照合や、失敗と是正に関する明確な合意がありません。AIの不足を組織へ帰す明示的な傾向により、この未定義の境界は特に重要です。1 19
エージェント型ソフトウェア時代の競争優位の持続性 — 5/10。 業務連携と確立した意思決定エンジンには価値が残ります。その維持には、モデル改訂と例外除去の生産性向上が必要です。アシスタントへのアクセスと従来の計画プロセスだけでは、その進歩を示せません。9 17
出典
すべての出典は2026年11月4日に閲覧しました。日付のないページは、その日に利用可能だった提供内容を説明しています。
INFORMの資料、日付なし。製品範囲、ホスティング選択肢、連携、販売前評価。
[2] ADD*ONE Inventory Optimizer
INFORMの資料、日付なし。購買判断、業務入力、料金の要因。
INFORMの資料、日付なし。生産制限、実行可能な計画という主張、費用に基づく代替案。
[4] Demand AI Forecasting Service
INFORMの資料、日付なし。予測手順、人の決定境界、API、ホスティング、データ利用。
INFORMの資料、日付なし。数学的最適化の取り組みに関するベンダーの説明。
INFORMの資料、2026年7月20日公開。自動化の前提、維持すべきパラメーター、未解決の例外。
INFORMの資料、日付なし。複数施策に帰属する在庫成果とERP連携。
INFORMの資料、日付なし。生産範囲と、個別に定義された業務成果。
INFORMの資料、日付なし。長期導入、労働成果、継続設定、仕入先ポータル。
INFORMの資料、日付なし。仕入先選択と納品可能性の主張。
INFORMの資料、日付なし。起源と独立した製品群の発展。
INFORMの資料、2018年12月11日公開。初期のAI経路計画の宣伝と、絶対的な定時性の約束。
INFORMの資料、2019年6月17日公開。限定的な機械学習課題についての当時の説明。
INFORMの資料、2024年11月27日公開。過去の導入日とアルゴリズム概念の継続。
INFORMの資料、日付なし。便益を明示的に問う探索的ウェビナー。
INFORMの資料、2025年9月11日公開。生鮮食品予測の例と説明の限界。
[17] Aviation WorkforcePlus Product Exchange
INFORMの資料、日付なし。別の航空製品のMCPインターフェースのプレビュー。
[18] PSAアントワープEuropa Terminalへの導入
INFORMの資料、2026年5月27日公開。完了した初期段階と、後に予定するクレーン統合。
INFORMの資料、2026年7月30日公開。失敗の組織への帰属と不良在庫の例。
INFORMの資料、2026年8月20日公開。定型自動化と人の監督に関するベンダーの区別。
[21] Software Developer Java/Kotlinの求人
INFORMの資料、日付なし。ポルトガルのチームと開発環境を特定する雇用主文書。
INFORMの資料、日付なし。報告、回答期間、開示条件。
INFORMの資料、2026年10月22日公開。ベンダーの評価と修正声明。
INFORMの資料、日付なし。予測階層、計画プロセス、労働削減の主張。
INFORMの資料、日付なし。部門横断計画とシナリオプロセス。
INFORMの資料、日付なし。在庫へのアプローチと顧客の可用性指標。
INFORMの資料、2017年11月8日公開。空港予測アプリケーションに関する初期の議論。