最終更新：2026年11月4日
市場調査に戻る
Boardは、財務、小売、サプライチェーンのチーム向けに企業計画プラットフォームを提供しています。アプリケーションは、需要予測、能力と在庫の計画、財務モデル、シナリオ、報告、承認手順を組み合わせます。顧客と導入パートナーが、これらの活動を結ぶデータモデルと業務ルールを設定します。(1)
総合スコア：5.0/10
| 評価軸 | スコア |
|---|---|
| サプライチェーンへの理解の深さ | 4.4/10 |
| 意思決定と最適化の実質 | 4.0/10 |
| 製品とアーキテクチャの一貫性 | 5.4/10 |
| 技術的透明性 | 6.4/10 |
| ベンダーの真剣さ | 4.8/10 |
Boardの中心的な提案は、設定可能な計画プロセスです。情報を統合し、予測を計算し、前提を調整し、シナリオを比較し、意思決定を計画担当者へ提出します。公開マニュアルは、その背後にある相当の技術開発を示しています。同時に限界も明らかにします。予測と財務連結は、不確実な需要と供給の下で、期待経済リターンによって購買、生産、配分を選ぶ計算を証明しません。
2026年のエージェントの位置付けは、このプロセスに説明と推奨を加えます。公開されたSupply Chain Agentの手順は、依然として人間の評価と経営層のレビューで終わります。現在プレビューとされるBoard MCPは、外部アシスタントからのアクセスを拡張します。いずれの発表も、反復的な意思決定レビューの作業がなくなったことや、新しい数値エンジンの開発を示していません。(21, 22)
最も強い能力は具体的です。文書化された予測手法、実際に導入された生産配分ルール、財務データ準備の自動化、プログラム実行、導入ツールです。主な弱点も具体的です。顧客が保守する計画ロジック、壊れやすい手続き参照、キューブの保守、そして本番コードの隔離が説明されていないR拡張です。
BoardとLokadの比較
Boardは、企業計画の作成、改訂、整合を容易にします。財務モデルは、生産の前提が予算にどう影響するかを説明でき、設定可能な手順は、その前提に責任を負う人々の作業を整理します。経済的な問題として残るのは、アプリケーションが業務行動をどう選ぶかです。
Lokadの定量的サプライチェーンのアプローチは、意思決定そのものから始まります。購買、生産、配分、移動、値下げを行う数量です。需要、補充遅延、その他の不確実性を、それらの財務的結果の評価に組み込みます。目標はネットワーク全体で実行可能な判断を生成し、業務上の失敗が欠けていた費用、制約、利用可能な行動を明らかにした際にロジックを改善することです。この視点はサプライチェーン入門で展開されています。
不確実性によって望ましい行動が変わる場合、この区別が重要になります。期待需要を満たす能力計画でも、ある市場には高額な欠品損失を、別の市場には廃棄する在庫を残すことがあります。両方をダッシュボードに示しても、どちらが起きるか分かる前に確保すべき能力は決まりません。そのためには、確率、経済的影響、依存関係を意思決定計算へ組み込む必要があります。
両方のアプローチで保守は必要です。Boardの顧客とパートナーは、アプリケーションモデルを保守します。Lokadの運用付きサブスクリプションには、データ準備、意思決定の経済性の形式化、結果監視、本番ロジック保守に責任を持つサプライチェーンサイエンティストが含まれます。比較すべきなのは、判断を運用・改善する総作業と、それによる経済的成果です。
予測・計画エンジンが計算する内容
明示された統計手法と限定的な意思決定の意味付け
BoardのBEAM文書は、時系列分類、自動モデル選択、共変量、予測区間を説明しています。間欠的な系列にはCroston-SBAを使い、より滑らかな系列にはARIMA系モデルと単純な基準モデルを競わせます。独立に予測したキューブのバージョンは、下位からの合計または上位からの比例配分で整合できます。予測計算は、対象キューブの集約レベルで実行されます。(2)
この詳細は手法を評価するのに十分です。間欠需要の一定値予測は平均を推定できても、発生時点と数量に関する大きく異なる分布を隠しかねません。その分布が、次の在庫一単位が保有費用に見合うかを決めます。同様に、需要の区間は、需要増と供給業者の遅延が同時に起きる事象を表しません。
階層の整合は算術的一貫性の問題を解きます。しかし、その配分が局所的な代替、欠品損失、期限切れ、顧客固有の需要を捉えることは証明しません。地域全体の合計が正しくても、商品単位の判断が悪いことはあります。適切な試験は、実行可能な粒度での意思決定の財務成績です。
導入済みの生産配分プロセス
Biobestの事例は、特に明確な手順を提供します。営業チームがBEAM予測を修正し、生産拠点が能力見積もりを入力し、アプリケーションのアルゴリズムが業務ルールで能力を配分します。経営側は提案を修正でき、結果はERPの納期回答とMRPの処理へ入ります。生物学的製品は、生産期間が最大16週間に達し、歩留まりも変動します。歩留まりに基づく能力の自動化は、まだ後続プロジェクトとして説明されていました。(3)
これは、導入済みの配分計算と実行経路を示しています。重要な欠落は、ルールが不足と生物学的廃棄をどう評価し、歩留まりの不確実性と需要の不確実性がどう相互作用するかです。経営側の手動変更で今日の悪い配分は直せるかもしれません。しかし、その修正が試験済みの意思決定ロジックにならなければ、同じ判断は反復的な運用費用として残ります。
この事例は、階層の高すぎる位置で予測するために生産の詳細が失われることも指摘しています。集計した精度率を称賛するより、適切な問題設定です。それでも、生産判断は廃棄、可用性、利益率に照らして評価する必要があります。
Foresightは特定可能な連携を通じて外部予測を追加
Board Foresightは、中長期予測に外部の経済指標を組み込みます。文書は、統計モデルの選択と、AIが生成する予測要因の説明を記しています。(5)
連携には追跡可能な境界があります。ユーザーはシングルサインオンでPrevedereがホストするアプリケーションに入り、BoardのデータセットをForesightと交換し、指標や予測をBoardのキューブへ戻します。現在のマニュアルは、14.4以前と比べた追加のデータセット取込機能を示しています。これは、バージョンごとの機能を持つ、提供済みのデータ連携です。(6)
外部指標は独自の予測問題を持ち込みます。公表の遅れ、後日の改訂、不安定な相関、そして集計された事業要因と具体的な補充リスクとの違いです。改訂済みの過去データに対して変数を選ぶと、元の判断時点では実行不可能だったモデルを作りかねません。公開概要は、当時利用可能だったデータ版を考慮する検証を示さず、これらの予測を共同の確率的発注方針へ結び付けてもいません。
技術の歴史：提供された仕組みと拡大する主張
| 時期 | 発表または提供 | 証拠が裏付ける内容 |
|---|---|---|
| 2015年2月 | Board 9でBEAMとインメモリのサーバークラスタを導入。 | 自動化された予測分析と分散プラットフォーム実行は、明示された製品上の約束でした。(18) |
| 2015年頃のBEAM資料 | ARIMA系予測、Croston-SBA、モデル競争を、極めて高速な予測とともに宣伝。 | 数学的手法は明示されましたが、競合との速度比較には再現可能な処理負荷の比較がありませんでした。(19) |
| 2024年、Board 14 | 改訂したDynamicエンジンがメモリ管理と保存の挙動を変更。 | 文書は単一の保存アーキテクチャ、簡素なバックアップ管理、InRamフラグの廃止を説明しています。(16) |
| 2024年11月から2026年 | BoardがPrevedereを買収し、その後Foresightを統合。 | 外部予測が、文書化されたアプリケーションとデータ交換手順になりました。(20, 6) |
| 2026年6月 | Supply ChainとMerchandiser Agentsを発表。 | リスク識別、シナリオ評価、計画担当者への推奨は説明されていますが、業務労力の比較結果はありません。(21) |
| 現在のMCPプレビュー | 外部AIツールが計画の文脈にアクセスし、モデルと対話。 | 新しいインターフェースと権限境界を提案していますが、測定されたサプライチェーン生産性の向上はありません。(22) |
歴史的な弱点は、これらの仕組みから導く結論が拡大していることです。当初の予測手法は、定義された統計作業を行いました。現在のエージェント型の位置付けは意思決定のより広い変化を示唆しますが、公表された手順は依然として、人間が選択肢を評価して計画サイクルを終えることに依存しています。
識別できる技術的進展もあります。Dynamicエンジンの変更とForesightのデータ交換は、プラットフォーム運用と予測範囲に対応しています。未解決の約束は経済面です。これらの変更が、サプライチェーンアプリケーションの保守と運用の作業をどこまで減らし、判断がより良いリターンを生むかです。
Boardのガバナンス説明でも、行動前にAI推奨を人間の監督下に置いています。(23) MCPの宣伝は特に警戒すべき兆候です。既存モデルを別のアシスタントに公開することは、意思決定エンジン開発に比べて安価です。Boardのプレビューにはモデルとの対話が含まれ、将来アプリケーション開発を助ける可能性はありますが、実装時間、回帰試験の労力、本番障害の比較はありません。既存の計画プロセスとの会話が速くなっても、最大の労働依存は残ります。
ソフトウェア構成要素、保守、セキュリティ
文書化された構成要素と境界
| 構成要素または境界 | 証拠と範囲 | 保有費用への影響 |
|---|---|---|
| Boardエンジンと多次元モデル | Board 14は改訂したメモリとディスクの扱いを文書化。 | モデル次元、保存する組合せ、計算構造が、引き続き資源消費を決めます。(16) |
| Azureクラウドインスタンス | 現在のアーキテクチャは専用の顧客環境、本番、任意のサンドボックスを説明。 | 開発、試験、本番の資源には、能力とライフサイクルの管理が必要です。(8) |
| Hybrid Data Pipelineとオンプレミスコネクタ | クラウドサービスが顧客側構成要素に接続し、元システムへの書き戻しに対応。 | 認証情報、対応付け、コネクタ更新、書き戻しの意味付けが組織境界を越えます。(8) |
| Foresight / Prevedere | 別アプリケーションへのアクセスと、データセット・キューブ間の交換を文書化。 | 予測履歴、識別子、更新日程、集約ルールは、交換を通して整合している必要があります。(6) |
| 任意のRserve計算 | Boardが選択したデータをRサーバーへ送り、スクリプト出力を取り込み。 | ランタイム修正、パッケージ依存、実行制御、事故責任が中核モデルの外まで広がります。(7) |
| プラットフォーム開発技術 | マドリードの研究開発求人はAngular/AngularJSとTypeScriptを要求。ASP.NET/C#は優遇、Azure/Kubernetes/Docker経験は加点。 | 求人はアプリケーション開発能力を示し、導入技術は明示的に任意の経験として記載しています。(17) |
文書化された最大の負担は、設定されたアプリケーション自体です。サプライチェーンロジックは、キューブ定義、階層、計算、手続き、外部交換に存在します。新しい調達選択肢や費用解釈の改訂には、それらを横断する協調した変更が必要かもしれません。サブスクリプションとクラウドの料金は、正しさを保つ費用の一部しかカバーしません。
キューブ保守は運用上の義務
BoardのCenter of Excellenceは、通常の消去ではゼロ値の組と古い疎な組合せが残ることを説明しています。構造の掃除には、保守モードでの最適化、モデルのアンロード、またはキューブの抽出、消去、再ロードが必要になる場合があります。保持方針だけでは、蓄積した物理構造は除去されません。(14)
これは予定された作業と復旧義務を生みます。誰かが不要な構造の蓄積を特定し、対象キューブを選び、データを保全し、保守を実行し、結果を確認する必要があります。計画頻度を上げても費用はなくならず、信頼できる保守時間帯と復旧がより重要になります。
手続き開発のガイドも示唆的です。配分の手順は100ステップを超えることがあります。データベース手続きの名前を変えると、呼び出し側を手動更新しない限り参照が壊れる場合があります。Boardはロジックを理解可能に保つため、コメント、グループ化、再利用可能な手続きを推奨します。(15) これはグラフィカルな画面を介して担うソフトウェア開発上の責任です。
導入ツールは役立つが、モデル変更はデータを破壊し得る
Boardはメタデータのスナップショット、パッケージ比較、導入パッケージを提供します。ALMマニュアルは、構造変更で対象データが消えることを警告し、比較用スナップショットを取った後は本番を変更しないよう推奨します。(11)
CLI自動化は導入パッケージを実行でき、REST APIは手続きの実行とモデル構造の確認に対応します。(12, 13) これは再現可能な運用とエージェント支援の開発を支えます。残るのは意味上の試験です。変更した配分ルールが意図通りの意味を持つか、移行後の数量が整合するか、一見成功した実行がより良い判断を生んだかを確かめる必要があります。
クラウド文書は標準のレイアウト上限も公開し、その変更をBoard Supportに限定しています。(8) これにより運用者は明確なエスカレーション経路を得ますが、アプリケーションの構造が現在の資源枠を超える場合、ベンダーへの依存が増えます。
R実行には文書化された隔離設計がない
R連携はBoardデータをRserveへ転送し、与えられたスクリプトを実行し、返されたデータをキューブへ書き込みます。設定は、サーバーまたは仮想マシン、Rserveパッケージの導入、認証や遠隔アクセスなどを含む任意の設定ファイルを説明します。しかし、強制的なネットワーク制限、パッケージ管理、隔離された実行、秘密情報へのアクセス、資源上限は説明していません。(7)
したがって、誤った、または侵害されたスクリプトには、モデルの通常のデータ権限を超える保護が必要です。文書化された連携は、その保護設計をランタイム運用者に委ねています。明確な隔離アーキテクチャなしで実務担当者に本番データの拡張機能を与えることは、重大なセキュリティ上の弱点です。
Boardのクラウドセキュリティ資料は、重大な脆弱性を30日、高い深刻度のものを90日で修復する目安を公表していますが、商業的に合理的な努力という留保付きです。復旧文書は、保持期間付きの日次災害復旧バックアップを説明し、同時に顧客自身のアプリケーションバックアップも求めています。(9, 10) これらは一部の運用責任を定義しますが、別個のR実行境界を解決せず、壊れた意思決定ロジックからの復旧も示しません。
生産性と経済的な説明責任
Coca-Cola Europacific Partnersは、財務データ入力の90%を自動化し、データ転送を24時間から15分へ短縮したと報告しています。説明された導入は、48工場と85倉庫のサプライチェーン財務を対象に、財務連結と要因ベースのシミュレーションを含みます。(4)
これは準備作業の大幅な削減です。ただし、経済評価では範囲が重要です。データ移動と統合の高速化は人員の時間を空けますが、残る判断にはなお計算または人間による行動選択が必要です。事例は総アプリケーション保守労力を定量化せず、以前の作業改善が2026年のエージェントによるものだとも証明していません。
現在のBoardのサプライチェーンページは、顧客全体で30–80%速い意思決定サイクルと二桁の在庫削減を主張していますが、母集団、基準値、費用、測定期間を添えていません。(1) 数値は、導入、パートナー支援、モデル保守、レビュー作業を差し引いた再現可能なリターンを立証できません。
責任の問題は実務的です。計画が過剰在庫を生んだとき、原因が予測、設定ルール、経営側の手動変更、実行のどれかを、誰が判断するのでしょうか。Boardは調査を始められる程度のモデル構造と手順を公開しています。しかし検討した公開事例は、経済的な失敗の閾値、範囲を定めた修復義務、誤ったアプリケーションロジックについてのBoard、パートナー、顧客間の責任分担を定義していません。
サプライチェーンスコア
サプライチェーンへの理解の深さ
| 基準 | スコア |
|---|---|
| 経済的な問題設定 | 5/10 |
| 最終的な意思決定への到達 | 4/10 |
| サプライチェーンに関する概念の明確さ | 5/10 |
| 時代遅れの中心的教義からの自由度 | 3/10 |
| KPIの見せかけへの耐性 | 5/10 |
平均：4.4/10
経済的な問題設定 — 5/10。 財務モデルは、業務上の前提を予算や利益率に可視化します。欠けているのは、不確実性の下で業務上の行動を選ぶ共通の金銭的目的です。財務計画の整合を取っても、次に発注する一個の期待リターンは決まりません。(1)
最終的な意思決定への到達 — 4/10。 Biobestは、計算された配分をERPへ戻す経路を示しています。文書化された最終段階には経営側による修正が含まれ、公開されている製品提案は依然としてシナリオとレビューサイクルを中心に計画担当者の判断を組み立てています。(3)
サプライチェーンに関する概念の明確さ — 5/10。 生産能力、歩留まり、粒度、取り逃した需要が、具体的な顧客業務に登場します。集計値を予測することと、限られた資源の投入を決めることの違いは、一般的な製品説明では十分に掘り下げられていません。(3)
時代遅れの中心的教義からの自由度 — 3/10。 合意予測、S&OPの調整、経営幹部によるレビューが、宣伝されるワークフローの中心に残っています。信頼できる計算へ業務上の意思決定を委ねなければ、こうしたプロセスは継続的な人の関与に比例して膨らみます。(1)
KPIの見せかけへの耐性 — 5/10。 顧客事例では、有用な準備作業の改善と予測業務が区別されています。現在の顧客横断の改善率には、財務的な結論を支える測定情報が足りず、純リターンとのつながりも公表されていません。(1, 4)
意思決定と最適化の実質
| 基準 | スコア |
|---|---|
| 確率的モデル化の深さ | 3/10 |
| 独自性のある最適化または機械学習の実質 | 4/10 |
| 現実の制約への対応 | 5/10 |
| 意思決定の自動化と労働生産性 | 4/10 |
| 現実の業務の複雑さに対する適応力 | 4/10 |
平均：4.0/10
確率的モデル化の深さ — 3/10。 予測区間は、予測に含まれる不確実性の一部を示します。検討した仕組みからは、需要、補充の遅延、歩留まりの同時分布が業務上の行動評価に使われるとは確認できません。これらの不確実性を別々に扱うと、一見魅力的な配分の評価が逆転しかねません。(2)
独自性のある最適化または機械学習の実質 — 4/10。 BEAMが挙げる手法と自動モデル選択は、数値予測の実装を示しています。公開説明には、独自の確率的な経済最適化エンジンは示されていません。Foresightは予測入力を広げますが、意思決定との間に残るこの隔たりを埋めません。(2, 5)
現実の制約への対応 — 5/10。 顧客が設定する配分ロジックは、生産能力と業務ルールを扱い、実行システムへの経路も文書化されています。ルールの経済的な質、不確実な実行可能性の扱い、意思決定間の相互作用は、個別アプリケーションに依存します。(3)
意思決定の自動化と労働生産性 — 4/10。 自動化された準備作業と反復可能な計算は、作業を減らします。エージェントの発表資料には、同等の意思決定品質を維持しながらサプライチェーンアプリケーションの判断、保守、復旧に必要な総労働量をどれだけ減らしたかという測定がありません。(4, 21)
現実の業務の複雑さに対する適応力 — 4/10。 設定可能なプロシージャにより、問題の定式化を変更できます。長い処理列と壊れやすい参照のため、修正にはアプリケーションエンジニアリングが必要です。繰り返される業務上の失敗が、経済的な意思決定の検証済みの改善へ体系的につながることは示されていません。(15)
製品とアーキテクチャの一貫性
| 基準 | スコア |
|---|---|
| アーキテクチャの整合性 | 6/10 |
| システム境界の明確さ | 6/10 |
| セキュリティへの真剣さ | 4/10 |
| ソフトウェアの簡素さと保有費用 | 4/10 |
| プログラムおよびエージェント支援による運用との適合性 | 7/10 |
平均：5.4/10
アーキテクチャの整合性 — 6/10。 多次元エンジンは共通のアプリケーション基盤を提供し、ストレージの変更は特定可能な運用上の問題に対処しています。外部予測とカスタムランタイム拡張は新たな境界を加え、その意味的な整合性をアプリケーション側で保つ必要があります。(16, 6, 7)
システム境界の明確さ — 6/10。 マニュアルは、クラウドインスタンス、顧客側の接続、Foresightとのデータ交換、R処理を区別しています。この明確さは、運用責任の割り当てに役立ちます。ただし、複数システムにまたがる意思決定プロセスの整合性が自動的に保たれるわけではありません。(8, 6, 7)
セキュリティへの真剣さ — 4/10。 復旧責任と修復指針は公開されています。実務者のコードを実行する拡張については、侵害されたスクリプトの影響を制限できる隔離設計が公表されておらず、拡張性に伴う最も重大なリスクへの対応が不十分です。(9, 10, 7)
ソフトウェアの簡素さと保有費用 — 4/10。 キューブの再構築とプロシージャ参照の手動修復には、文書化された保守作業が必要です。継続的な専門人材の費用を意思決定の価値で賄わなければならず、ローコードの画面だけではその負担は減りません。(14, 15)
プログラムおよびエージェント支援による運用との適合性 — 7/10。 プロシージャAPI、構造の検査、スクリプトによるパッケージ展開は、画面操作を超えた自動化を支えます。ここで最も強い根拠は既存の実行インターフェースです。MCPは追加のプレビュー段階にあり、開発上の効果は測定されていません。(12, 13, 22)
技術的透明性
| 基準 | スコア |
|---|---|
| 公開技術文書 | 8/10 |
| ベンダーの仲介なしでの検証可能性 | 7/10 |
| 可搬性とロックインの可視性 | 5/10 |
| 実装方法の透明性 | 7/10 |
| 技術的主張を裏付ける証拠の密度 | 5/10 |
平均：6.4/10
公開技術文書 — 8/10。 マニュアルは、予測手法、アプリケーション構造、API、展開、保守時の挙動を公開しています。最も大きく欠けているのは、経済的な意思決定の目的と、新たに宣伝されるエージェントの詳しい動作です。(2, 11, 13)
ベンダーの仲介なしでの検証可能性 — 7/10。 読者は、営業との接触前に複数の仕組みや運用上の限界を評価できます。ただし、顧客向けに設定された意思決定を再現するには、そのデータ、アプリケーション定義、実行環境が必要です。(14, 15)
可搬性とロックインの可視性 — 5/10。 データ抽出とプラットフォームの展開パッケージは、有用な移動経路を提供します。アプリケーションロジックはBoard固有の構造で表現されるため、別の実行エンジンへの移行には再構築と検証が必要です。(11, 13)
実装方法の透明性 — 7/10。 公開されたプロシージャとALMの指針は、実際の開発作業、故障形態、環境間での反映手順を示します。特定の経済的意思決定アプリケーションを構築し、維持するための総工数は未解明です。(11, 15)
技術的主張を裏付ける証拠の密度 — 5/10。 数値計算とインフラの文書は、プラットフォームに関する複数の主張を支えています。エージェントによる生産性や広範な最適化成果には、モデル設定や財務連結ほど具体的な裏付けがありません。(2, 16, 21)
ベンダーの真剣さ
| 基準 | スコア |
|---|---|
| 公開発信の技術的な真剣さ | 5/10 |
| 技術ロードマップの一貫性 | 5/10 |
| 概念の明確さ | 5/10 |
| 経済的な説明責任 | 4/10 |
| エージェント型ソフトウェア時代における競争力の持続性 | 5/10 |
平均：4.8/10
公開発信の技術的な真剣さ — 5/10。 技術文書は手法を明示し、保守上の危険も認めています。一方、広範なマーケティング表現は、シナリオ支援や外部アシスタントへのアクセスを、相応の運用実績を示さずに壮大な意思決定の主張へと広げています。(15, 21, 22)
技術ロードマップの一貫性 — 5/10。 時系列には、提供済みの予測機能、エンジン改修、買収製品の統合が含まれます。最新のエージェント提案には、はるかに広い約束を裏付けるために必要な作業量の変化の測定がありません。(18, 19, 20, 21)
概念の明確さ — 5/10。 Boardは財務情報と業務情報を明示的なモデルで結び付けています。しかし公開提案では、同期された計画から最適な意思決定へ容易に話が飛び、不確実性の財務的評価が未解決のままです。(1)
経済的な説明責任 — 4/10。 実名顧客の業務と準備作業の指標によって、一部の効果を検討できます。公開資料は導入義務の範囲を定めず、経済的リターンが実現しないサプライチェーンアプリケーションをベンダーがどう是正するかも示していません。(3, 4)
エージェント型ソフトウェア時代における競争力の持続性 — 5/10。 プログラム可能な計算プラットフォームは、有用なアプリケーションを構築・保守するエージェントを支えられます。計画を説明しレビューを案内する画面を中心に据えた製品には、より大きな生産性の課題があります。組織は、日常的な介入がほとんど不要な、信頼できる意思決定ロジックをますます期待しています。(13, 21)
出典
すべての出典の閲覧日は2026年11月4日です。以下の日付は公開日または文書化された更新日です。日付のない顧客事例を現行製品世代のものとは扱っていません。
サプライチェーン計画。現行ページ。現在の製品範囲、合意に基づく計画のワークフロー、顧客横断の成果の範囲。
BEAMの概要。2026年3月31日更新。現在の予測手法、対象キューブの粒度、区間、整合化。
Biobestの生産計画。日付なし。導入済みの予測から配分、ERPへのプロセスと、残る人間の作業。
[4] Coca-Cola Europacific Partnersの計画
Coca-Cola Europacific Partnersの計画。日付なし。財務計画の導入と、報告されたデータ準備の改善。
Board Foresightについて。2026年2月4日更新。Foresightの予測期間、外部要因、モデル選択の範囲。
Foresightの利用開始。2026年3月31日更新。Prevedereのアプリケーション境界と、バージョンに依存するデータ交換。
R連携。2026年3月31日更新。Rserveでの実行、データ転送、セットアップ手順。
クラウドアーキテクチャ。2026年10月7日更新。クラウド環境、連携コンポーネント、既定のレイアウト上限。
クラウドセキュリティ。2026年3月31日更新。公開された脆弱性修復の指針。
クラウドの信頼性と継続性。2026年3月31日更新。災害復旧の保持期間と、顧客によるアプリケーションバックアップの責任。
アプリケーションライフサイクル管理。2026年3月31日更新。メタデータのスナップショット、展開プロセス、データ損失の警告。
CLIによる自動化。2026年3月31日更新。コマンドラインインターフェースを通じたパッケージの定期実行。
BoardのAPI。2026年3月31日更新。プロシージャ実行、クエリアクセス、モデルスキーマのインターフェース。
キューブ保守戦略。日付なし。物理ストレージへの蓄積と、明示的なクリーンアップ操作。
プロシージャ開発の実務。日付なし。プロシージャの複雑さ、参照、開発と保守の実務。
Board 14のDynamicエンジン。2024年6月13日公開、2026年3月31日更新。Board 14におけるメモリ、ストレージ、バックアップの変更。
マドリードのソフトウェアエンジニア。日付のない求人情報。雇用主が記したマドリードのプラットフォーム研究開発職の要件。任意のスキルは別途明示。
Board 9の発表。2015年2月10日。BEAMとインメモリクラスターの発表日が確認できる資料。
BEAMの当初のパンフレット。2015年頃のパンフレット。当初の数値手法と予測速度に関する訴求。
Prevedereの買収。2024年11月13日。Boardの所有者による日付付きの買収発表。
[21] Supply Chain AgentとMerchandiser Agentの発表
Supply Chain AgentとMerchandiser Agentの発表。2026年6月24日。Supply Chain Agentの発表と、計画担当者・経営幹部のワークフロー。
Board MCPのプレビュー。現行ページ。アシスタントによるアクセスとモデル操作のプレビュー範囲。
AIガバナンス。現行ページ。公開された人間による監督と権限のモデル。