Review of Lanner, Simulation and Digital Twin Software Vendor

By Léon Levinas-Ménard

Last updated: November 4, 2026

Lanner’s Witness, now developed by Haskoning, is simulation software for manufacturing, logistics, and service operations. Users construct models of resources, material flows, queues, and operating rules, then compare changes to equipment, capacity, layouts, and schedules. Haskoning also provides model development, consulting, and training. (1, 14)

Overall supply chain score: 6.0/10.

Dimension	Score
Supply chain depth	6.0/10
Decision and optimization substance	6.4/10
Product and architecture integrity	5.4/10
Technical transparency	6.6/10
Vendor seriousness	5.8/10

Witness has substantial engineering content. Its customer accounts explain why apparently sensible changes can damage performance: more vehicles can increase congestion, and faster machinery can overload downstream handling. Its strongest contribution is making those interactions calculable before committing capital. The weaker part is the passage from a credible process model to repeated economic decisions. A model can faithfully reproduce an existing operation, including its inefficient planning habits, without identifying the most profitable way to change it. (3, 6, 16)

Haskoning discusses validation and shows continued investment in model-building tools. Nevertheless, its public cases rarely quantify prediction errors, the economic effect of wrong recommendations, or the continuing labor required to keep models useful. Those gaps matter when a digital twin is presented as an ongoing decision capability. (8, 9, 11)

Lanner versus Lokad

Consider a manufacturer deciding whether to add machines, increase buffers, or change production priorities. Witness is well suited to representing the physical consequences: queues, shared resources, blocking, rework, and changes in throughput. The Safran case, for example, follows individual parts through machining and quality-control alternatives to examine lead times and investment choices. (4)

Lokad’s approach starts with recurring decisions—what to buy, produce, allocate, or expedite—and evaluates their economic consequences across uncertain futures. The relevant comparison is whether the computation prices the trade-offs affecting the business as a whole, including demand, supply delays, stockouts, and capital tied up in inventory. This is the design perspective developed in Introduction to Supply Chain.

Witness offers considerable freedom to build a custom economic model. That freedom leaves substantial work to the modeler: defining what can change, assigning probabilities, valuing outcomes, and making the results actionable. A physically detailed factory model and a financial objective are complementary requirements; neither substitutes for the other. Lokad likewise requires maintained customer-specific logic and Supply Chain Scientist work. Both approaches should be judged by the quality of decisions produced and the cost of revising that logic when reality exposes a mistake.

Technology history and roadmap integrity

The history shows a durable simulation product, with successive changes in presentation and deployment.

Period	Documented development	Assessment
2012	Lanner’s Winter Simulation Conference paper describes programmable process elements, costing, heuristic optimization, Six Sigma functionality, and optional 3D views.	The computational foundation predates digital-twin branding. The paper explicitly treats visualization as a communication aid that can distract from solving the problem.
2019–2020	Haskoning acquires Lanner in 2019. A July 2020 Hanford case describes Witness.io parallel execution and machine-learning analysis developed with sister company Ynformed.	Cloud delivery has an identifiable workload benefit. The AI claim concerns bottleneck analysis, with surrogate models still described as work in progress.
2023	Witness 26, under Twinn, adds faster property editing and improved undo functionality.	These are concrete improvements to the work of maintaining models.
2026	Witness 28 improves state reporting, experiment inputs, and material-handling controls. A separate brewery demonstration links a knowledge graph to model reconstruction.	The release strengthens the established modeling workflow; the demonstration explores a more programmatic way to maintain it.

Sources: (2, 10, 11, 13, 17).

The Hanford account identifies a task and reports a before-and-after operating measure. Its remaining weakness is attribution: the published result combines data preparation, parallel execution, and analysis, without isolating the contribution of machine learning. The current account still describes surrogate modeling as development work; it supplies no subsequent benchmark establishing that capability. (7, 17)

The January 2026 article also proposes conversational access to simulation. Easier questioning can help an occasional user, but a chatbot does not select the economically relevant experiments, validate the model, or eliminate repeated human scenario review. The stronger engineering direction is automating model reconstruction and testing; its value depends on how much maintenance it actually removes. (13)

What the computation does

Nonlinear physical interactions are a real strength

At Ford Valencia, competing AGV suppliers proposed markedly different fleet sizes. Witness helped establish a workable configuration, then showed that adding vehicles to a particular circuit would increase blocking without raising output. A separate experiment found that reassigning an apparently idle vehicle would interrupt the assembly line. These are substantive examples of system-level constraints: local utilization and installed capacity can be misleading guides to investment. (3)

Britvic’s model connected factory handling with site traffic. It led to one-way aisles and clarified staffing and running-cost implications of a new bottling line. At Safran, one model covered five production lines, including quality inspection, rework, and detailed lead-time accounting. These applications address physical interactions that static capacity spreadsheets tend to suppress. (4, 5)

The optimization mechanism is also identifiable. Lanner’s 2012 technical paper describes a user-defined objective, parameter ranges, combination constraints, replications, and search based on simulated annealing and tabu methods, with an interface for other algorithms. Such search can evaluate irregular simulation responses without pretending the process is linear. It still searches the choices encoded by the modeler. If an economically important action or cost is missing, more search cannot recover it. (2)

Stochastic simulation needs credible forecasts

The Malaysia food-production case includes throughput variability, breakdowns, and conveyor sensor logic. Witness can therefore represent uncertainty on the production side, not merely change a demand number between deterministic scenarios. (16)

Sampling uncertain inputs is the easy part. The demanding work is establishing their distributions, dependencies, and future relevance. A simulation of demand growth, machine failures, rework, and supplier delays should preserve relationships that alter the value of an investment or operating decision. Independent random draws can produce convincing detail while missing correlated overloads or supply interruptions.

Haskoning’s August 2025 discussion usefully identifies idealized cycle times, unvalidated constraints, missing process logic, and stale layouts as sources of error. It recommends mistrusting assumptions and progressively validating models against operations. Its 2024 methodology also distinguishes software verification from comparison with the real system. (8, 9)

What remains missing from the reviewed customer cases is a numerical account of predictive reliability: how well the model anticipates queue lengths, output variability, lead-time tails, or the relative performance of competing decisions on subsequent operations. A digital twin forecasts a high-dimensional future. Agreement on its assumptions, attractive animation, and additional simulation replications do not establish that those forecasts are reliable.

This distinction is particularly important for capital expenditure. A small error in the predicted bottleneck can reverse which investment pays. Accuracy should be assessed at that decision boundary, with the economic penalty of choosing badly, rather than reduced to a generic percentage of similarity between a model and the factory.

Reproducing a planning process can preserve its defects

DS Smith required a model of corrugator scheduling, downstream operations, and planners’ interventions. Haskoning describes reproducing the deckling algorithm and the ways planners alter jobs, split runs, and respond to storage constraints. This is necessary when predicting what the existing organization will do. It also creates a strategic limit: a faithful reproduction of current habits does not determine whether those habits deserve to survive. (6)

The next improvement may require a different decision space—new ways of batching orders, accepting customer work, or pricing urgency—not a better search over the existing scheduling controls. This is the issue discussed in Holimization: the formulation itself must evolve. Witness is programmable enough to support such revisions, but their business value depends on engineering judgment and retesting, not merely simulation speed.

Productivity, model maintenance, and ownership cost

The Hanford case provides a useful productivity measure: an 80-scenario question reportedly fell from 20–25 working days to 2–4 days. Witness.io distributed runs across dedicated simulation cores, while a custom application reduced input handling and results processing. This measures a defined analytical task. The account also says the modeling team doubled in size as its use expanded, so elapsed-time savings should not be converted into an unsupported headcount reduction. (7)

Customer-specific modeling is substantial software work. DS Smith’s application involved hundreds of variables and thousands of lines of code, followed by a month of refinement against past production. Small changes could strongly affect results. Haskoning’s consulting offer explicitly supports either delivery by its specialists or development of an internal customer capability. Training includes advanced courses. (6, 14, 15)

The ownership cost therefore includes more than licenses and compute: observing operations, interpreting data, changing rules, checking that an old calibration still holds, and ensuring the model remains understandable when its original author leaves. Reusable model components can reduce that burden. Undocumented exceptions accumulate it.

There are concrete improvements. Witness 28 allows Data Tables to feed Experimenter directly, reducing extra variables maintained solely to run experiments. The release also improves material-flow inspection. Access to the new version requires an active support agreement. These mechanisms and obligations are more useful for estimating ownership cost than a broad claim that modeling is easy. (11, 12)

The 2026 brewery demonstration maps a reference process into an ontology hosted in Azure Digital Twins. A Python application transfers changes through XML modules to rebuild the Witness model. This could remove repeated editing when physical assets change. It also creates another representation to maintain: the graph, the mapping, and the simulation must continue to mean the same thing. The published demonstration supplies no deployment-scale maintenance measurement or automatic validation result. (13)

Software bill of materials and security

Component or interface	Documented role and scope	Operational implication
Windows desktop application	Current Witness requirements list Windows desktop and server versions, 8 GB RAM, and 1 GB installation storage.	The core has a modest published installation footprint; detailed experiments can require additional memory and cores.
Witness logic and external libraries	Current documentation supports custom logic and C++, C#, VB.NET, or Python libraries.	Model extensions add executable dependencies and require their own maintenance and access controls.
OLE DB, COM, Excel, SQL experiment repository	Lanner’s 2012 paper describes data access, external execution, custom interfaces, and stored experiments.	These dated interfaces explain how bespoke applications have been assembled around the engine.
Witness.io	The Hanford application runs parallel simulations through a web service.	Parallelism exchanges elapsed time for compute and requires orchestration of inputs and results.
Azure Digital Twins, Python, XML	Components of the January 2026 brewery demonstration.	A graph-to-simulation bridge adds synchronization work; it is a documented demonstration architecture.

Sources: (1, 2, 7, 13).

The main costs are model development, validation, and maintenance of the surrounding integrations. The public material does not expose the current cloud service’s full runtime and storage architecture or demonstrate how execution costs scale with a realistic changing model.

External practitioner code is the more immediate security concern. The current feature page promotes extension languages but does not explain enforced restrictions on files, network destinations, credentials, dependencies, or resource consumption. A mistaken script or compromised library should not inherit unrestricted access to operational data. Local desktop execution requires protection too: separation of experiment credentials from production write access, constrained execution, and recoverable model state. (1)

Improved undo helps recover an editing mistake; it is not containment for executable code. The reviewed release material and integration demonstration do not document an enforced sandbox or a governed promotion path from experimental extensions to production-connected applications. (10, 13)

Economic results and accountability

The named examples contain useful decision evidence. Ford reports operating with its selected AGV configuration and avoiding unnecessary vehicles. Britvic identifies changed traffic flows and staffing implications. Safran uses simulations to support millions of euros of investment, which is an amount evaluated, not a measured return generated by the software. (3, 4, 5)

Public evidence is much thinner on the full economic result: implementation and upkeep costs, realized benefits against a credible alternative, error costs, and correction after a recommendation disappoints. A detailed factory model can influence a large investment without contributing that investment’s entire return.

The methodology emphasizes stakeholder involvement and agreement on assumptions. That is useful for defining the work, but consensus cannot make a false assumption true. Accountability needs a record of the prediction, the resulting action, the observed outcome, and who must revise the model when they diverge. The public methodology describes validation activity; it does not define a remedy or economic obligation if expected gains fail to materialize. (8, 9, 14)

Supply chain score

Each of the 25 criteria has equal weight.

Supply chain depth

Criterion	Score
Economic framing	6/10
Decision end-state	5/10
Conceptual sharpness on supply chain	6/10
Freedom from obsolete doctrinal centerpieces	7/10
Robustness against KPI theater	6/10

Average: 6.0/10.

Economic framing — 6/10. Investment and operating costs enter customer studies, but the common valuation of uncertain demand, scarce capacity, and alternative actions remains a modeling assignment. Physical performance is better evidenced than risk-adjusted economic optimization. (4, 5)

Decision end-state — 5/10. The cases lead to concrete equipment and process choices. Recurring execution still depends on users translating analysis into action; the documented end-state is primarily decision support. (3, 14)

Conceptual sharpness on supply chain — 6/10. The models handle interacting flows and resource limits. The principal gap is connecting that physical representation to customer demand, uncertain external supply, and economic choices across the wider chain. (4, 16)

Freedom from obsolete doctrinal centerpieces — 7/10. The modeling environment permits process-specific reasoning rather than requiring a standard inventory classification or consensus-planning ritual. Reproducing inherited planner behavior can nevertheless preserve its weaknesses. (6, 8)

Robustness against KPI theater — 6/10. Published examples connect analysis to identifiable operating changes. Predictive accuracy and attributable net returns remain largely unquantified, leaving considerable room between convincing illustrations and measured economic reliability. (3, 7, 16)

Decision and optimization substance

Criterion	Score
Probabilistic modeling depth	6/10
Distinctive optimization or ML substance	6/10
Real-world constraint handling	8/10
Decision automation and labor productivity	5/10
Resilience under real operational complexity	7/10

Average: 6.4/10.

Probabilistic modeling depth — 6/10. Operational variability is part of the modeled system. The public evidence does not establish joint calibration of demand and supply uncertainty or prospective reliability of the resulting decision rankings. (9, 16)

Distinctive optimization or ML substance — 6/10. The search mechanism has a published technical basis, and the analysis pipeline has a concrete application. Neither establishes a broadly reusable economic decision policy or an independently measured ML advantage. (2, 7)

Real-world constraint handling — 8/10. Blocking, quality-dependent routing, and shared movement paths can overturn simple capacity assumptions. The customer examples show why those interactions alter investment decisions. (3, 4, 5)

Decision automation and labor productivity — 5/10. Defined analytical work becomes faster, but specialists still formulate experiments, interpret results, and maintain models. The newer integration demonstration has no measured total-labor outcome. (7, 13)

Resilience under real operational complexity — 7/10. Iterative validation can expose missing behavior and revise the model. The approach supports correction of the formulation, while published evidence stops short of a routine failure-to-retest loop after deployment. (6, 8, 9)

Product and architecture integrity

Criterion	Score
Architectural coherence	7/10
System-boundary clarity	6/10
Security seriousness	3/10
Software parsimony and ownership cost	5/10
Compatibility with programmatic and agent-assisted operations	6/10

Average: 5.4/10.

Architectural coherence — 7/10. A sustained simulation core supports model editing, experimentation, and reporting. Additional graph and cloud representations introduce integration obligations whose costs are not yet quantified. (10, 11, 13)

System-boundary clarity — 6/10. The core modeling product and consulting role are clear. The current cloud execution boundary, customer-code responsibilities, and production connection controls are less transparent. (1, 7, 14)

Security seriousness — 3/10. Extension power is advertised without inspectable containment. The missing safeguard is enforced limitation of what practitioner code and its dependencies can access or alter. (1, 13)

Software parsimony and ownership cost — 5/10. Model maintenance can dominate the comparatively modest desktop footprint. The product improves authoring efficiency, but complex custom logic, expert support, and revalidation remain continuing costs. (6, 11, 12, 15)

Compatibility with programmatic and agent-assisted operations — 6/10. Data-driven reconstruction creates a useful path beyond manual editing. Demonstrated production automation and safe agent access remain narrower than the proposed possibilities. (13)

Technical transparency

Criterion	Score
Public technical documentation	7/10
Inspectability without vendor mediation	6/10
Portability and lock-in visibility	5/10
Implementation-method transparency	8/10
Evidence density behind technical claims	7/10

Average: 6.6/10.

Public technical documentation — 7/10. Papers, release notes, and methodology articles expose meaningful mechanisms. Current deployment security and detailed cloud internals are much less accessible. (2, 8, 11)

Inspectability without vendor mediation — 6/10. The public cases reveal enough model behavior to assess the technical approach. Reproducing their conclusions requires customer inputs and models that are not published. (3, 6)

Portability and lock-in visibility — 5/10. External interfaces and model exchange support integration. They do not establish that a customer’s executable process semantics can move economically to another simulation engine. (2, 13)

Implementation-method transparency — 8/10. Scoping, data preparation, validation, and experimentation are described alongside difficult customer work. Buyers can identify substantial responsibilities before treating the software as a ready-made solution. (6, 8, 9)

Evidence density behind technical claims — 7/10. Several cases explain the modeled interaction and resulting operational choice. The missing layer is reproducible predictive error and financial attribution across deployments. (3, 4, 16)

Vendor seriousness

Criterion	Score
Technical seriousness of public communication	6/10
Technology roadmap integrity	7/10
Conceptual sharpness	6/10
Economic accountability	4/10
Defensibility in an agentic-software world	6/10

Average: 5.8/10.

Technical seriousness of public communication — 6/10. Candid discussion of imperfect inputs supports the engineering narrative. Broad digital-twin and AI claims still exceed the published evidence on autonomous decisions and quantified prediction quality. (9, 13)

Technology roadmap integrity — 7/10. Dated releases show continued work on the established product. The long-running surrogate-model ambition lacks a published delivery benchmark, but the history contains identifiable improvements rather than a sequence of labels alone. (7, 10, 11, 17)

Conceptual sharpness — 6/10. The vendor understands that local improvements can harm the system and that assumptions need validation. It is less explicit about when the objective and available choices must be redesigned rather than further analyzed. (3, 6, 9)

Economic accountability — 4/10. Named applications and specific operating changes support practical relevance. Public commitments do not define attributable net gain, economic failure, or remediation when model-informed choices underperform. (4, 5, 14)

Defensibility in an agentic-software world — 6/10. Domain modeling, nonlinear process representation, and accumulated validation knowledge remain valuable. Retaining that value requires reducing model-maintenance and decision-review labor, beyond adding conversational access. (6, 11, 13)

Sources

The sources below were accessed on November 4, 2026. Customer outcomes are vendor-published accounts unless stated otherwise. Historical technical descriptions retain their original date and scope.

[1] Witness simulation modelling software

Witness simulation modelling software. Published: Undated; accessed 2026-11-04.

[2] WITNESS Simulation Software, Anthony Waller, Winter Simulation Conference

WITNESS Simulation Software, Anthony Waller, Winter Simulation Conference. Published: 2012.

[3] Ford Valencia AGV strategy

Ford Valencia AGV strategy. Published: 2024; year indicated in body.

[4] Safran Aircraft Engines production model

Safran Aircraft Engines production model. Published: Undated.

[5] Britvic site logistics

Britvic site logistics. Published: Undated.

[6] DS Smith production scheduling simulation

DS Smith production scheduling simulation. Published: Undated.