Where AR and VR Earn Their Place in ERP

AR and VR in ERP gets dismissed as demo theater. Most of the time the dismissal is correct. The vendor demo shows a headset, a holographic dashboard, and a stock-photo executive nodding thoughtfully. The customer asks what the actual operator does with it. The vendor changes the subject.

There are three production use cases where AR or VR earn their place in an ERP workflow. There are two more that the demos love but the customers can't actually deploy. This post separates them, and ends with the architectural pattern that explains the difference.

Three use cases that earn their place

1. Vision-guided warehouse picking

A picker walks 8 to 14 miles per shift in a busy distribution center. Most of that walking is between picks, not picking. The ERP knows where every SKU is. The picker has to translate aisle and bin codes into a route in their head, walk to each location, scan, and confirm.

An AR head-up display (HUD) replaces the cognitive translation step. The picker sees the next pick location as a turn-by-turn overlay, the SKU and quantity as a label, and a visual confirmation as they scan. The ERP's pick list becomes a guided path.

The measured impact on real deployments: pick rate up 15 to 30 percent, pick error rate down by half, training time for new pickers compressed from weeks to days. The technology has been viable since 2016 (Vuzix, RealWear, Google Glass Enterprise) and has only gotten better. The ERP integration is straightforward (the pick list is already in the WMS module; the HUD reads it).

This is the case where AR has the cleanest cost-benefit. The hardware is cheap relative to labor. The integration is shallow. The user (the picker) does not need training to use the interface; the interface is the work.

2. Field service remote expert + asset overlay

A technician arrives at a customer site to service an industrial pump, a power transformer, a wind turbine, a refrigeration unit. The technician knows what they are doing for the common faults. The uncommon faults require an expert who isn't on-site.

The traditional solution is a phone call. The technician describes what they see; the expert tries to picture it. The fault gets misdiagnosed; the truck rolls again next week.

The AR solution is a video stream from the technician's headset or phone to the expert, with the ability for the expert to annotate the technician's field of view. The expert circles the fitting that needs to be checked. The arrow stays on the fitting as the technician moves their head. The ERP's asset record (last service date, prior fault history, IoT sensor readings) overlays alongside.

The measured impact: first-time-fix rate improves from typical 60-70 percent to 85-90 percent, truck rolls reduced by 20-30 percent, expert utilization improves because one expert can support five technicians instead of riding along with one.

The ERP integration is real but bounded. The asset record needs to feed the AR layer. The session needs to log to the customer record. The IoT data needs to be queryable at the headset. None of this is exotic; all of it requires real engineering work to plumb.

3. Manufacturing training and SOP walkthrough

A new operator needs to be certified on a line. The traditional certification is shadow-an-experienced-operator, study the SOPs, then attempt the line under supervision. The cycle is 4 to 12 weeks depending on complexity. The experienced operator's time is the bottleneck.

The VR alternative is an immersive walkthrough of the line in a simulated environment. The operator practices the procedure (start-up sequence, recipe change, fault response) without consuming line time. The simulation is built from the ERP's work-instruction library and the MES's recipe definitions. The operator's performance in the simulation feeds back into the training record.

The measured impact: certification time compressed by 40-60 percent, line downtime for training reduced (no need to take the line down for the simulation), retention improved (operators retain the procedural memory better with active practice than with reading).

This use case requires more upfront investment than the previous two (the VR environment has to be built; the training content has to be authored). The payback is on the second or third certified operator if the line is high-complexity, or the tenth if low. Mid-market manufacturers can struggle to justify it; large-volume manufacturers cannot justify not doing it.

Two use cases that the demos love but customers can't deploy

Executive dashboards in VR

The pitch: an executive puts on a headset and walks through a virtual operations center, sees real-time KPIs as holographic charts, drills down by reaching out and grabbing data points. Every ERP vendor has shown some version of this since 2017.

The failure mode: executives do not put on headsets. They look at their phones, their laptops, and printed weekly summaries. The barrier is not technical (the visualizations work). The barrier is behavioral. A VR session takes 5 minutes of context switch and disrupts whatever the executive was doing. A glance at a Slack alert takes 5 seconds.

Every deployment we have seen of executive-VR-dashboards has ended in shelfware. The hardware sits in a credenza. The product team that built it moves on.

Showroom and trade-show VR product demos

The pitch: a manufacturer or distributor builds a VR experience that lets a customer "walk through" a configured product, see the full catalog in a virtual showroom, customize options in real time.

The failure mode: the audience for the demo is a small subset of the audience for the product. Trade-show foot traffic engages with the demo as a novelty, not as a purchasing aid. Showroom traffic still wants to physically touch the product. The ERP integration (real-time pricing, configurator constraints, lead times) is correct but underused.

The cost is high (custom VR build per product line) and the impact is hard to measure. The cases where this earns its place are very narrow: one-of-a-kind capital equipment with no physical sample (jet engines, large turbines), bespoke architecture projects (architectural visualization predates VR-in-ERP), and a few niche industrial cases.

The architectural pattern that explains the difference

The three earn-their-place cases share a structural trait. The ERP is the record of truth; AR or VR is the input/output surface for an operator whose work happens in physical space.

The pick list lives in the WMS. The picker's hands are in the warehouse. The HUD is the interface between them.

The asset record lives in the FSM module. The technician's hands are at the customer site. The headset is the interface between them.

The work instruction lives in the MES. The trainee's hands are simulating the procedure. The VR environment is the interface between them.

The two cases that don't earn their place lack this trait. The executive's work does not happen in physical space; it happens in conversations, emails, and decisions. VR is a worse interface for those than the screens they already use. The trade-show attendee's hands aren't doing anything that the demo helps with; the demo is entertainment, not work.

The principle: AR or VR earns its place when an operator does physical work that an ERP record needs to inform. It does not earn its place when the work is informational and the ERP record is already accessible by other means.

The integration shape to look for

If you are evaluating an AR or VR investment alongside an ERP project, three questions cut through the demo theater.

1. Who is the operator? Name a specific role (warehouse picker on shift B; field tech servicing distribution transformers; line operator certifying on bottling line 4). If the answer is "executive" or "customer at trade show," the cost-benefit is fragile.
2. What physical thing is the operator doing? Picking, scanning, repairing, training. If the operator is reading or talking, AR/VR is a worse interface than a screen.
3. What ERP record does the operator need to consult or update? Pick list, asset record, work instruction, batch record. If the answer is "dashboard," you have the executive-VR problem in disguise.

When all three questions have specific, operational answers, AR or VR is worth a real evaluation. When any answer is vague, the project will look great in the demo and never make it past the pilot.

Closing

AR and VR in ERP is a real category with three real use cases. It is not a transformative wave that subsumes the rest of the application surface. The vendor demos that pitch it as such are setting customer expectations the technology cannot meet, and the customer disappointment that follows hurts the genuinely useful cases.

At AvanSaber we treat AR and VR the way we treat any other integration: it earns its place by reducing operator effort or error in a specific named workflow, and it does not earn its place anywhere else. If you are evaluating an AR or VR investment, the three-question framework above is the one we use with clients.