Last updated: November 4, 2026
Go back to Market Research
Board supplies an enterprise planning platform for finance, retail, and supply chain teams. Its applications combine demand forecasting, capacity and inventory planning, financial models, scenarios, reporting, and approval workflows. Customers and implementation partners configure the data models and business rules connecting these activities. (1)
Overall score: 5.0/10
| Dimension | Score |
|---|---|
| Supply chain depth | 4.4/10 |
| Decision and optimization substance | 4.0/10 |
| Product and architecture integrity | 5.4/10 |
| Technical transparency | 6.4/10 |
| Vendor seriousness | 4.8/10 |
Board’s central proposition is a configurable planning process: consolidate information, calculate forecasts, reconcile assumptions, compare scenarios, and submit decisions to planners. Public manuals expose substantial engineering behind that process. They also expose its limits. Forecasting and financial consolidation do not establish a calculation that chooses purchases, production, and allocations by their expected economic returns across uncertain demand and supply.
The 2026 agent positioning extends this process with explanations and recommendations. The published Supply Chain Agent workflow still culminates in human evaluation and executive review. Board MCP, currently presented as a preview, extends access from external assistants. Neither announcement supplies evidence that the software has removed the recurring decision-review workload or developed a new numerical engine. (21, 22)
The strongest capabilities are specific: documented forecast methods, deployed production-allocation rules, automated financial data preparation, programmatic execution, and deployment tooling. The main liabilities are equally concrete: customer-maintained planning logic, fragile procedure references, cube maintenance, and an R extension whose production-code containment is unexplained.
Board versus Lokad
Board makes enterprise plans easier to assemble, revise, and reconcile. Its financial models can explain how a production assumption affects a budget, while its configurable workflows organize the people responsible for that assumption. The economic question remains how the application selects the operational action.
Lokad’s quantitative supply chain approach starts with the decisions themselves: quantities to buy, produce, allocate, move, or discount. Demand, replenishment delays, and other uncertainties enter the evaluation of their financial consequences. The aim is to produce executable decisions across the network and improve the logic when operational failures reveal a missing cost, constraint, or available action. This perspective is developed in Introduction to Supply Chain.
The distinction matters when uncertainty changes the preferred action. A capacity plan that balances expected demand can leave expensive shortages in one market and disposable inventory in another. Showing the two outcomes on a dashboard does not determine how much capacity should be committed before either becomes known. That requires their probabilities, economic consequences, and dependencies to enter the decision calculation.
Maintenance remains necessary in both approaches. Board customers and partners maintain their application models. Lokad’s managed subscription includes a Supply Chain Scientist responsible for preparing data, formalizing decision economics, monitoring results, and maintaining production logic. The comparison is the total work required to operate and improve decisions, together with the resulting economics.
What the forecasting and planning engine computes
Explicit statistical methods, limited decision semantics
Board’s BEAM documentation describes classification of time series, automated model selection, covariates, and prediction intervals. Intermittent series use Croston-SBA; smoother series enter a competition involving ARIMA-family models and naïve baselines. Independently forecast cube versions can be reconciled through bottom-up summation or top-down proportional allocation. The forecast computation runs at the target cube’s aggregation. (2)
This is enough detail to assess the approach. A constant intermittent-demand forecast can estimate an average while concealing very different distributions of arrival times and quantities. Those distributions determine whether the next unit of inventory earns its carrying cost. Likewise, an interval around demand does not describe the joint event in which demand rises while a supplier delivers late.
Hierarchical reconciliation solves an arithmetic consistency problem. It does not prove that the resulting allocation captures local substitution, stockout losses, expiry, or customer-specific demand. A correct regional total can coexist with poor item-level decisions. The relevant test is the financial performance of the decisions at their executable resolution.
A deployed production-allocation process
Biobest’s case provides an unusually clear workflow. Commercial teams revise BEAM forecasts; production sites enter capacity estimates; an application algorithm allocates capacity under business rules; management can revise the proposal; the result feeds ERP available-to-promise and MRP processes. The biological products involve production times reaching 16 weeks and variable yields. Yield-based capacity automation was still described as a subsequent project. (3)
This establishes a deployed allocation calculation and its execution path. The material omission is how the rules value shortages against biological waste, and how uncertain yields interact with uncertain demand. A management override may correct a bad allocation today. Unless that correction becomes tested decision logic, the same judgment remains a recurring operating expense.
The case also identifies the loss of production detail caused by forecasting too high in the hierarchy. That is a better framing than celebrating an aggregate accuracy percentage. The resulting production decisions still need to be assessed against waste, availability, and margin.
Foresight adds external forecasting, with an identifiable integration
Board Foresight incorporates external economic indicators into medium- and long-range forecasting. Its documentation describes statistical-model selection and AI-generated explanations of forecast drivers. (5)
The integration has a traceable boundary. Users enter a Prevedere-hosted application through single sign-on, exchange Board datasets with Foresight, and return indicators or forecasts into Board cubes. The current manual identifies additional dataset-import capabilities beyond versions 14.4 and earlier. This is delivered data integration with versioned functionality. (6)
External indicators introduce their own forecast problem: publication delays, later revisions, unstable correlations, and the difference between an aggregate business driver and a specific replenishment exposure. Selecting variables against revised historical data can produce a model that could never have run at the original decision date. The public overview does not supply a vintage-aware validation or connect these forecasts to a joint stochastic ordering policy.
Technology history: delivered mechanisms and expanding claims
| Period | Announcement or delivery | What the evidence supports |
|---|---|---|
| February 2015 | Board 9 introduced BEAM and an in-memory server cluster. | Automated predictive analytics and distributed platform execution were explicit product commitments. (18) |
| 2015-era BEAM brochure | ARIMA-family forecasting, Croston-SBA, and model competition were promoted alongside exceptionally fast forecasting. | The mathematical methods were named; the competitor-speed claim lacked a reproducible workload comparison. (19) |
| 2024, Board 14 | A revised Dynamic engine changed memory management and storage behavior. | Documentation describes a single saving architecture, simpler backup handling, and retirement of the InRam flag. (16) |
| November 2024 to 2026 | Board acquired Prevedere; Foresight integration followed. | External forecasting became a documented application and data-exchange workflow. (20, 6) |
| June 2026 | Supply Chain and Merchandiser Agents were announced. | Risk identification, scenario evaluation, and planner recommendations are described; comparative operating-labor results are absent. (21) |
| Current MCP preview | External AI tools can access planning context and interact with models. | A new interface and permission boundary are proposed; no measured supply chain productivity gain is supplied. (22) |
The historical weakness is the widening inference drawn from these mechanisms. The original forecasting methods performed defined statistical tasks. Today’s agentic positioning suggests a broader change in decision-making, yet the published process still depends on people evaluating alternatives and completing the planning cycle.
There is also identifiable engineering progress: the Dynamic engine changes and Foresight data exchange address platform operations and forecasting scope. The unresolved commitment is economic: how far these changes reduce the work of maintaining and operating a supply chain application, and whether their decisions produce better returns.
Board’s governance statement also places AI recommendations under human oversight before action. (23) MCP promotion is a particular red flag. Exposing existing models to another assistant is inexpensive relative to developing a decision engine. Board’s preview includes model interaction, which could eventually help application development, but provides no comparison of implementation time, regression effort, or production errors. Faster conversations with the current planning process leave its largest labor dependency intact.
Software materials, maintenance, and security
The documented components and boundaries
| Component or boundary | Evidence and scope | Ownership-cost implication |
|---|---|---|
| Board engine and multidimensional models | Board 14 documents revised memory and on-disk handling. | Model dimensions, stored combinations, and calculation structure still determine resource consumption. (16) |
| Azure cloud instances | Current architecture describes dedicated customer environments, production and optional sandbox instances. | Development, testing, and production resources require capacity and lifecycle management. (8) |
| Hybrid Data Pipeline and on-premises connector | The cloud service connects to a customer-side component and supports source-system writeback. | Credentials, mappings, connector upgrades, and writeback semantics cross organizational boundaries. (8) |
| Foresight / Prevedere | Separate application access and dataset-to-cube exchange are documented. | Forecast histories, identifiers, update schedules, and aggregation rules must remain consistent across the exchange. (6) |
| Optional Rserve calculation | Board sends selected data to an R server and imports script output. | Runtime patching, package dependencies, execution controls, and incident ownership extend beyond the core model. (7) |
| Platform development technologies | A Madrid R&D recruitment record requests Angular/AngularJS and TypeScript; ASP.NET/C# knowledge is preferred and Azure/Kubernetes/Docker experience is a plus. | The record identifies application-development skills, with the deployment technologies explicitly listed as optional experience. (17) |
The largest documented burden is the configured application itself. Supply chain logic resides in cube definitions, hierarchies, calculations, procedures, and external exchanges. A new sourcing option or revised cost interpretation may require coordinated changes across these structures. Subscription and cloud charges cover only part of the cost of keeping them correct.
Cube maintenance is an operating obligation
Board’s Center of Excellence explains that ordinary clearing can leave zero-valued tuples and obsolete sparse combinations in place. Structural cleanup may require optimization in maintenance mode, unloading the model, or extracting, clearing, and reloading cubes. Retention policies alone do not remove the accumulated physical structure. (14)
This creates scheduled work and a recovery obligation. Someone must identify when the model has accumulated unnecessary structure, choose the affected cubes, preserve data, run the maintenance, and verify the result. More frequent planning does not eliminate this cost; it makes reliable maintenance windows and recovery more important.
The procedure-development guidance is similarly revealing. Allocation sequences can exceed 100 steps. Renaming database procedures can break references unless callers are updated manually. Board recommends comments, grouping, and reusable procedures to keep this logic understandable. (15) These are software-engineering responsibilities carried through a graphical interface.
Deployment tooling helps, but model changes can destroy data
Board provides metadata snapshots, package comparisons, and deployment packages. Its ALM manual warns that structural changes can remove target data, and recommends keeping production unchanged after its comparison snapshot. (11)
CLI automation can execute deployment packages, while REST APIs can run procedures and inspect model structure. (12, 13) This supports repeatable operations and agent-assisted engineering. The remaining work is semantic testing: whether a changed allocation rule still means what the business intends, whether quantities reconcile after a migration, and whether an apparently successful run produced better decisions.
The cloud documentation also publishes default layout limits and reserves changes to those settings for Board Support. (8) This gives operators a defined escalation path, while adding a vendor dependency when an application’s shape exceeds its current resource envelope.
R execution lacks a documented containment design
The R integration transfers Board data into Rserve, executes a supplied script, and writes returned data into cubes. The setup describes a server or virtual machine, an Rserve package installation, and an optional configuration file containing settings such as authentication and remote access. It does not explain enforced network restrictions, package controls, isolated execution, secret access, or resource limits. (7)
A mistaken or compromised script therefore needs protections beyond the model’s usual data permissions. The documented integration leaves the design of those protections with the runtime operator. Giving practitioners a production-data extension without a clear containment architecture is a significant security weakness.
Board’s cloud security material publishes remediation guidelines of 30 days for critical vulnerabilities and 90 days for high-severity ones, qualified by commercially reasonable efforts. Its recovery documentation describes daily disaster-recovery backups with retention periods, while instructing customers to maintain their own application backups. (9, 10) These define some operational responsibilities. They do not resolve the separate R execution boundary or demonstrate recovery from corrupted decision logic.
Productivity and economic accountability
Coca-Cola Europacific Partners reports automation of 90% of financial data input and a reduction in data-transfer time from 24 hours to 15 minutes. The described deployment covers supply chain finance across 48 plants and 85 warehouses, including financial consolidation and driver-based simulations. (4)
These are substantial reductions in preparation work. Their scope matters for the economic assessment: faster data movement and consolidation free staff time, while the remaining decisions still require a calculation or a person to choose the action. The case does not quantify total application-maintenance effort or demonstrate that the 2026 agents caused these earlier workflow gains.
Board’s supply chain page now claims 30–80% faster decision cycles and double-digit inventory reductions across customers, without providing the population, baseline, costs, or measurement period alongside those ranges. (1) The figures cannot establish a repeatable return net of implementation, partner support, model maintenance, and review labor.
The accountability question is practical. When a plan creates excess inventory, who determines whether the cause was the forecast, a configured rule, a management override, or execution? Board exposes enough model and workflow structure to begin that investigation. The reviewed public cases do not define an economic failure threshold, a bounded remediation obligation, or how responsibility for incorrect application logic is divided between Board, the partner, and the customer.
Supply chain score
Supply chain depth
| Criterion | Score |
|---|---|
| Economic framing | 5/10 |
| Decision end-state | 4/10 |
| Conceptual sharpness on supply chain | 5/10 |
| Freedom from obsolete doctrinal centerpieces | 3/10 |
| Robustness against KPI theater | 5/10 |
Average: 4.4/10
Economic framing — 5/10. Financial models make operating assumptions visible in budgets and margins. The missing mechanism is a shared monetary objective that selects operational actions under uncertainty. Reconciling a financial plan does not determine the expected return of the next unit ordered. (1)
Decision end-state — 4/10. Biobest demonstrates a calculated allocation with an ERP return path. The documented end-state includes management revision; the public product proposition still organizes planner decisions around scenarios and review cycles. (3)
Conceptual sharpness on supply chain — 5/10. Capacity, yield, granularity, and missed demand appear in a concrete customer process. The distinction between forecasting an aggregate and committing scarce resources remains insufficiently developed in the general product explanation. (3)
Freedom from obsolete doctrinal centerpieces — 3/10. Consensus forecasts, S&OP reconciliation, and executive reviews remain central to the advertised workflow. These processes scale with recurring human attention unless operational decisions are delegated to dependable calculations. (1)
Robustness against KPI theater — 5/10. The customer evidence separates useful preparation gains from forecasting tasks. The current cross-customer percentage ranges lack enough measurement detail to support a financial conclusion, and no published link connects those ranges to net returns. (1, 4)
Decision and optimization substance
| Criterion | Score |
|---|---|
| Probabilistic modeling depth | 3/10 |
| Distinctive optimization or ML substance | 4/10 |
| Real-world constraint handling | 5/10 |
| Decision automation and labor productivity | 4/10 |
| Resilience under real operational complexity | 4/10 |
Average: 4.0/10
Probabilistic modeling depth — 3/10. Prediction intervals expose some forecast uncertainty. The reviewed mechanisms do not establish joint demand, replenishment-delay, and yield distributions feeding the evaluation of operational actions. Treating those uncertainties separately can reverse an apparently attractive allocation. (2)
Distinctive optimization or ML substance — 4/10. BEAM’s named methods and automatic model selection establish a numerical forecasting implementation. Its public description does not supply a distinctive stochastic economic optimizer; Foresight expands forecast inputs without closing that decision gap. (2, 5)
Real-world constraint handling — 5/10. Customer-configured allocation logic handles capacity and business rules, with a documented route into execution systems. The economic quality of those rules, their treatment of uncertain feasibility, and their interaction across decisions remain application-specific. (3)
Decision automation and labor productivity — 4/10. Automated preparation and repeatable calculations remove work. Agent launch material supplies no measured reduction in the total labor required to decide, maintain, and recover the supply chain application at comparable decision quality. (4, 21)
Resilience under real operational complexity — 4/10. Configurable procedures allow the problem formulation to change. Long sequences and fragile references make corrections dependent on application engineering; the evidence does not show that repeated operational failures systematically become tested improvements to decision economics. (15)
Product and architecture integrity
| Criterion | Score |
|---|---|
| Architectural coherence | 6/10 |
| System-boundary clarity | 6/10 |
| Security seriousness | 4/10 |
| Software parsimony and ownership cost | 4/10 |
| Compatibility with programmatic and agent-assisted operations | 7/10 |
Average: 5.4/10
Architectural coherence — 6/10. The multidimensional engine provides a common application substrate, and the storage changes address identifiable operating concerns. External forecasts and custom runtime extensions add boundaries whose semantics the application must maintain. (16, 6, 7)
System-boundary clarity — 6/10. The manuals distinguish cloud instances, customer-side connectivity, Foresight exchange, and R processing. That clarity helps assign operational ownership. It does not make the resulting multi-system decision process self-consistent. (8, 6, 7)
Security seriousness — 4/10. Recovery responsibilities and remediation guidelines are visible. The practitioner-code extension lacks a published containment design capable of limiting a compromised script, giving the most consequential extensibility risk insufficient treatment. (9, 10, 7)
Software parsimony and ownership cost — 4/10. Cube reconstruction and manual procedure-reference repair impose documented maintenance work. Their recurring specialist cost must be covered by decision value; the low-code interface does not reduce that obligation by itself. (14, 15)
Compatibility with programmatic and agent-assisted operations — 7/10. Procedure APIs, structural inspection, and scripted package deployment support automation beyond screen interaction. The strongest evidence here is the existing execution interface; MCP remains an additional preview with unmeasured development benefits. (12, 13, 22)
Technical transparency
| Criterion | Score |
|---|---|
| Public technical documentation | 8/10 |
| Inspectability without vendor mediation | 7/10 |
| Portability and lock-in visibility | 5/10 |
| Implementation-method transparency | 7/10 |
| Evidence density behind technical claims | 5/10 |
Average: 6.4/10
Public technical documentation — 8/10. Manuals expose forecasting methods, application structure, APIs, deployment, and maintenance behaviors. The largest omissions concern the economic decision objective and the detailed operation of the newly promoted agents. (2, 11, 13)
Inspectability without vendor mediation — 7/10. A reader can assess several mechanisms and operating limitations before a sales engagement. Reproducing a configured customer’s decisions still requires its data, application definitions, and runtime. (14, 15)
Portability and lock-in visibility — 5/10. Data extraction and platform deployment packages provide useful movement paths. Application logic remains expressed through Board-specific structures; migration to another execution engine would require reconstruction and validation. (11, 13)
Implementation-method transparency — 7/10. Public procedure and ALM guidance identifies actual development work, failure modes, and promotion steps. The unresolved element is the total effort required to build and sustain a particular economic decision application. (11, 15)
Evidence density behind technical claims — 5/10. Numerical and infrastructure documentation supports several platform claims. Agentic productivity and broad optimization outcomes have much less concrete support than model configuration and financial consolidation. (2, 16, 21)
Vendor seriousness
| Criterion | Score |
|---|---|
| Technical seriousness of public communication | 5/10 |
| Technology roadmap integrity | 5/10 |
| Conceptual sharpness | 5/10 |
| Economic accountability | 4/10 |
| Defensibility in an agentic-software world | 5/10 |
Average: 4.8/10
Technical seriousness of public communication — 5/10. Engineering documentation names methods and acknowledges maintenance hazards. The broader marketing language turns scenario support and external assistant access into sweeping decision claims without equivalent operating evidence. (15, 21, 22)
Technology roadmap integrity — 5/10. The chronology includes delivered forecasting, engine revisions, and acquisition integration. The latest agentic proposition has not supplied the measured change in work needed to substantiate its much broader promise. (18, 19, 20, 21)
Conceptual sharpness — 5/10. Board connects financial and operational information in an explicit model. Its public proposition still moves too easily from synchronized plans to optimal decisions, leaving the financial evaluation of uncertainty unresolved. (1)
Economic accountability — 4/10. Named customer processes and preparation metrics allow some benefits to be examined. Public evidence does not bound implementation obligations or specify how the vendor remedies a supply chain application whose economic returns fail to materialize. (3, 4)
Defensibility in an agentic-software world — 5/10. A programmable calculation platform can support agents that build and maintain useful applications. An interface centered on explaining plans and guiding reviews faces a stronger productivity challenge: organizations increasingly expect reliable decision logic that runs with little recurring intervention. (13, 21)
Sources
All sources were accessed on November 4, 2026. Dates below identify publication or documented updates; undated customer stories are not assigned to the current product generation.
Supply chain planning. Current. Current product scope, consensus-planning workflow, and cross-customer performance ranges.
BEAM overview. 2026-03-31 update. Current forecasting methods, target-cube resolution, intervals, and reconciliation.
[3] Biobest production planning
Biobest production planning. Undated. Deployed forecast-to-allocation-to-ERP process and remaining human work.
[4] Coca-Cola Europacific Partners planning
Coca-Cola Europacific Partners planning. Undated. Financial planning deployment and reported data-preparation gains.
About Board Foresight. 2026-02-04 update. Foresight’s forecasting horizon, external drivers, and model-selection scope.
[6] Getting started with Foresight
Getting started with Foresight. 2026-03-31 update. Prevedere application boundary and versioned data exchange.
R integration. 2026-03-31 update. Rserve execution, data transfer, and setup instructions.
Cloud architecture. 2026-10-07 update. Cloud environments, integration components, and default layout limits.
Cloud security. 2026-03-31 update. Published vulnerability-remediation guidelines.
[10] Cloud reliability and continuity
Cloud reliability and continuity. 2026-03-31 update. Disaster-recovery retention and customer application-backup responsibilities.
[11] Application lifecycle management
Application lifecycle management. 2026-03-31 update. Metadata snapshots, deployment process, and data-loss warnings.
CLI automation. 2026-03-31 update. Scheduled package execution through command-line interfaces.
Board APIs. 2026-03-31 update. Procedure execution, query access, and model-schema interfaces.
[14] Cube maintenance strategy
Cube maintenance strategy. Undated. Physical storage accumulation and explicit cleanup operations.
[15] Procedure development practices
Procedure development practices. Undated. Procedure complexity, references, and development-maintenance practices.
Board 14 Dynamic engine. 2024-06-13; updated 2026-03-31. Board 14 memory, storage, and backup changes.
[17] Software Engineer, Madrid
Software Engineer, Madrid. Undated recruitment record. Employer-authored Madrid platform R&D requirements; optional skills identified separately.
Board 9 launch. 2015-02-10. Dated BEAM and in-memory cluster launch.
BEAM original brochure. 2015-era brochure. Original numerical methods and forecasting-speed positioning.
Prevedere acquisition. 2024-11-13. Dated acquisition announcement from Board’s owner.
[21] Supply Chain and Merchandiser Agents launch
Supply Chain and Merchandiser Agents launch. 2026-06-24. Supply Chain Agent launch and planner/executive workflow.
Board MCP preview. Current. Preview scope for assistant access and model interaction.
AI governance. Current. Published human-oversight and permission model.