How can we implement voice-directed picking without replacing our entire legacy ERP infrastructure?

Yes. The usual approach is to add a voice execution layer around the legacy ERP/WMS, rather than modify or replace the core system.

Recommended architecture

                LEGACY ERP / WMS
             (system of record)
                     │
          existing API / DB / files
                     │
             ┌───────▼────────┐
             │ Integration /  │
             │ voice middleware│
             └───────┬────────┘
                     │
          pick-task translation
                     │
             ┌───────▼────────┐
             │ Voice engine / │
             │ workflow layer │
             └───────┬────────┘
                     │
              Wi-Fi / private 5G
                     │
          ┌──────────▼──────────┐
          │ Wearable + headset  │
          │     for picker      │
          └─────────────────────┘

Modern voice-picking platforms explicitly support integration with existing WMS/ERP and even legacy home-grown systems, so the ERP does not necessarily need to change.Honeywell SPS+1

1. Keep the ERP as the system of record

Don't make the voice application responsible for inventory accounting.

Have the existing system continue to own:

• Orders and order lines
• SKU/item master
• Bin/location master
• Inventory quantities
• Allocation
• Shipment/order status
• Inventory transactions

The voice layer should primarily execute and confirm work.

For example:

ERP: “Order 48192 requires 12 units of SKU 734 at location A-14-03.” Voice layer:

“Go to A-14-03.” “Confirm location.” “Pick 12.” “Say quantity.” Picker:

“12.” Voice layer sends the confirmation back to the ERP/WMS.

2. Put an integration layer between them

This is the key to avoiding an ERP replacement.

Depending on what your legacy system exposes, the adapter might use:

• REST/SOAP APIs
• Existing web services
• Database views/stored procedures
• Message queues
• Flat-file/SFTP exchanges
• Existing RF-terminal transactions
• Screen/API automation as a last resort

Normalize those interfaces into a small set of voice-oriented transactions such as:

GetNextPick()
GetLocationConfirmation()
ConfirmPick()
ReportException()
RequestReplenishment()
CompleteOrder()

That creates a stable contract between the voice system and the legacy application.

3. Make the voice engine stateful

Don't simply convert ERP screens into spoken instructions.

Create a workflow state machine:

TASK_ASSIGNED
      ↓
NAVIGATE_TO_LOCATION
      ↓
CONFIRM_LOCATION
      ↓
CONFIRM_ITEM
      ↓
ENTER_QUANTITY
      ↓
ERP_CONFIRMATION
      ↓
NEXT_PICK

That lets you handle exceptions intelligently:

• Wrong location
• Short pick
• Damaged product
• Missing product
• Quantity discrepancy
• Substitution
• Replenishment required
• Network interruption

This is particularly important because the picker shouldn't have to understand the quirks of the legacy ERP.

4. Use barcode/location checks alongside voice

Voice doesn't have to replace every existing technology.

A strong implementation is often voice + scanning, where voice directs the worker and scanning provides verification for things such as SKU, pallet, tote, or location.

Commercial systems already support combinations of voice, RF scanning and other data-capture technologies.Honeywell Automation+1

For example:

Voice: "Go to B-17-04."

Picker scans location barcode.

Voice: "Location confirmed. Pick 6."

Picker: "Six."

Voice: "Put in tote 27."

That gives you hands-free operation without sacrificing the auditability of barcode validation.

5. Start with one workflow, not the whole warehouse

I'd pilot one high-volume picking process.

Measure the baseline first:

Don't use vendor-reported productivity improvements as your business case without validating them in your operation. Vendors report gains such as up to ~35% productivity improvement, but actual results depend heavily on workflow, travel distance, SKU characteristics, network performance and worker adoption.Honeywell Automation+1

6. Design for ERP outages

This is one of the most important pieces with a legacy environment.

The voice layer should have:

• Local task/session state
• Transaction IDs
• Idempotent confirmations
• Retry queues
• Offline/error handling
• Duplicate-transaction protection
• Reconciliation reports

For example, if the picker says "12," the middleware should be able to retry the ERP transaction without accidentally posting 24.

7. Don't underestimate warehouse networking

Before deployment, test Wi-Fi specifically along:

• Aisles
• Refrigerated/freezer areas
• Loading docks
• High-bay locations
• Metal-rack corridors
• Charging areas

Voice depends on consistent two-way communication. A voice application that works perfectly at a desk but drops packets in aisle 47 isn't production-ready.

8. Choose hardware separately from the integration

You can use wearable computers/headsets from the major industrial mobility vendors while keeping the ERP untouched. For example, Honeywell describes its current voice platform as combining voice software with rugged wearable hardware and emphasizes deployment while maintaining operational continuity.Honeywell Automation

The important architectural decision is to avoid letting a particular headset or wearable become tightly coupled to your ERP integration. Keep:

ERP ↔ middleware ↔ voice workflow ↔ device

rather than:

ERP ↔ proprietary device application

That makes future hardware changes much easier.

A practical rollout

I'd structure it roughly like this:

1. Map the current pick transaction from order release through inventory decrement.
2. Identify the cleanest existing ERP interface—API if available, otherwise existing transaction/service interfaces.
3. Build the middleware adapter without changing ERP business logic.
4. Implement one voice workflow for a single picking zone.
5. Add barcode verification for location/SKU where appropriate.
6. Run voice and legacy picking in parallel during validation.
7. Compare accuracy, productivity, latency and exceptions.
8. Expand to additional zones/workflows only after the integration proves stable.
9. Later reuse the same layer for replenishment, cycle counting, receiving and put-away. Voice technology is commonly applied beyond picking to these workflows.Honeywell Automation+1

The core idea

Don't make voice an ERP project. Make it a warehouse-execution project.

The legacy ERP remains the authoritative back end. A lightweight integration/middleware layer translates its work into conversational tasks, manages the picker interaction, validates responses, and posts completed transactions back to the existing system.

If you tell me which legacy ERP/WMS you're running (e.g., AS/400, JD Edwards, SAP, Oracle, homegrown), how pickers interact with it today, and roughly how many pickers you have, I can sketch a concrete target architecture and integration sequence for it.

That makes future hardware changes much easier.

ERP ↔ proprietary device application

That makes future hardware changes much easier.

You can add voice-directed picking as a warehouse execution layer rather than replacing your ERP. The common pattern is to leave the ERP (and often the WMS) as the system of record, then insert a voice platform that translates existing picking tasks into hands-free workflows. Many voice solutions are designed specifically to integrate with legacy ERP/WMS environments through APIs, middleware, or host interfaces.NuminaGroup+1

A practical implementation approach

1. Keep your ERP as the source of truth

Your ERP should continue to own:

• Orders
• Inventory availability
• Customer requirements
• Shipment status
• Financial transactions

The voice system should not replace these functions. It should consume work instructions and send confirmations back.

Typical flow:

ERP / Legacy WMS
        |
        |  (orders, pick tasks)
        v
Integration Layer / Voice Middleware
        |
        |  (spoken instructions)
        v
Picker Headset + Mobile Device
        |
        |  (confirmations, exceptions)
        v
ERP / WMS updates

2. Add an integration layer

Depending on your ERP age and capabilities, integration options include:

• REST APIs
• SOAP services
• Database views
• Message queues
• Flat-file exchanges (CSV/XML)
• Existing middleware platforms

A good voice solution should adapt to your ERP instead of forcing ERP customization. Standards-based interfaces are commonly used to connect voice applications with ERP, WMS, order management, and custom host systems.Lucas Systems

3. Start with one high-value picking process

Avoid a warehouse-wide rollout first. Pick a process where improvements are measurable:

Good candidates:

• High-volume case picking
• Repetitive SKU picking
• Cold storage picking
• Full-case distribution
• E-commerce batch picking

Pilot scope:

• 10–20 workers
• One warehouse zone
• One shift
• One product family

Measure:

• Picks/hour
• Pick accuracy
• Training time
• Travel distance
• Short picks
• Labor hours per order

4. Use voice for execution, not decision-making

Your ERP/WMS should continue deciding:

• What orders to pick
• Allocation rules
• Inventory logic
• Priority rules

The voice layer should handle:

• “Go to aisle 12, location B04”
• “Pick quantity 6”
• “Confirm check digit”
• “Report shortage”
• “Move to next task”

This keeps the implementation smaller and reduces risk.

5. Add verification points

Most successful voice deployments use confirmation steps such as:

• Location check digits
• Item confirmation
• Quantity confirmation
• Exception commands

These prevent a picker from accidentally confirming the wrong location or SKU.RFgen Software+1

6. Plan the hardware separately

Typical components:

• Rugged mobile computer or wearable device
• Noise-canceling headset
• Voice software license
• Warehouse Wi-Fi coverage assessment
• Device management

For noisy environments (forklifts, conveyors, cold rooms), headset quality and speech recognition performance matter as much as the software.

7. Avoid common integration mistakes

Mistake: Customizing the ERP heavily Better: create an adapter layer.

Mistake: Automating a bad picking process Better: fix slotting, replenishment rules, and pick paths first.

Mistake: Measuring only speed Better: track accuracy, training time, labor flexibility, and safety.

Mistake: Replacing everything at once Better: deploy voice first, then consider future WMS upgrades separately. Some organizations implement voice before a later WMS transition because it improves operations without forcing a back-end replacement.Lucas Systems

A phased roadmap

Phase 1 — Assessment (2–4 weeks)

• Map current pick workflows
• Identify ERP/WMS interfaces
• Select pilot area
• Define KPIs

Phase 2 — Pilot (6–12 weeks)

• Integrate one workflow
• Train operators
• Compare results against baseline

Phase 3 — Expansion

• Add zones
• Add replenishment, receiving, cycle counting, or packing
• Improve routing and reporting

Phase 4 — Long-term modernization

• Keep the voice layer
• Upgrade ERP/WMS only when business needs justify it

The key architectural decision is: do not make voice picking an ERP replacement project; make it a warehouse productivity project that connects to your existing systems.NuminaGroup+1

Yes—you can add voice-directed picking as a thin execution layer around the legacy ERP, rather than replacing the ERP. This is a well-established integration pattern: voice middleware can sit between the warehouse worker and an existing ERP/WMS, using APIs, files, sockets, browser/RF transactions, or other existing interfaces.Lucas Systems+1

Recommended architecture

                 EXISTING ERP
        ┌─────────────────────────┐
        │ Orders / Inventory      │
        │ Locations / Allocation  │
        │ Pick confirmation       │
        └───────────┬─────────────┘
                    │
             Existing interface
          API / DB view / files / RF
                    │
        ┌───────────▼─────────────┐
        │ Voice Integration Layer │
        │                         │
        │ • Task adapter          │
        │ • Voice workflow engine │
        │ • Validation rules      │
        │ • Retry / offline queue │
        │ • ERP transaction map   │
        └───────────┬─────────────┘
                    │
             Wi-Fi / cellular
                    │
        ┌───────────▼─────────────┐
        │ Rugged mobile device    │
        │ + headset/mic           │
        │                         │
        │ "Go to A-12-04"         │
        │ "Confirm 37"             │
        │ "Pick 6"                 │
        └─────────────────────────┘

The key architectural decision is: don't make speech recognition part of your ERP. Let the voice application translate speech into structured warehouse events, while the ERP remains the system of record.

1. Treat the ERP as the system of record

Your existing ERP continues to own:

• orders
• inventory balances
• item/location master data
• allocation
• pick tasks
• confirmations
• exceptions that affect inventory

The voice layer should generally not maintain a competing inventory database.

Instead, it receives something like:

{
  "task": "PICK",
  "taskId": "847291",
  "location": "A12-04",
  "sku": "123456",
  "quantity": 6,
  "checkDigit": "37"
}

and returns events such as:

{
  "taskId": "847291",
  "locationConfirmed": true,
  "quantityPicked": 6
}

That separation makes the solution much easier to replace or migrate later.

2. Put an adapter in front of the legacy interface

If the ERP has a modern API, use it. If it doesn't, don't automatically embark on an ERP modernization project.

The adapter can consume whatever the legacy system already exposes:

• REST/SOAP APIs
• existing RF transactions
• database views/stored procedures
• scheduled flat files
• message queues
• TCP/socket interfaces
• browser-based transactions

Current voice platforms explicitly support combinations of REST APIs, flat files and socket communications for legacy WMS/ERP environments.Lucas Systems+1

For a particularly old ERP, I'd favor:

ERP → existing export/interface → integration service → voice system → integration service → existing ERP confirmation interface

rather than writing directly into ERP tables.

3. Make the voice workflow stateful—but not the ERP logic

The voice engine should handle the conversational mechanics:

"Go to A12-04." "37." "Pick 6." "6." "Next." It can validate the location check digit, quantity, SKU, etc., before sending the confirmation upstream. Check digits are commonly used precisely to ensure the worker has reached the intended location.Apport

I'd define a finite state machine such as:

TASK_RECEIVED
     ↓
NAVIGATE
     ↓
LOCATION_CONFIRMED
     ↓
ITEM_CONFIRMED
     ↓
QUANTITY_CAPTURED
     ↓
ERP_CONFIRMATION_SENT
     ↓
ERP_CONFIRMED
     ↓
NEXT_TASK

This is important because voice recognition failure and ERP transaction failure are different problems and should be handled separately.

4. Keep scanning as a fallback

Don't make the first version "voice only."

A strong design is voice + barcode:

• Voice directs the worker.
• Voice confirms quantities.
• Barcode validates an item or location when ambiguity/risk is high.
• The existing scanner can remain available for exceptions.

Voice and barcode can coexist rather than forcing an all-or-nothing replacement.BCI

For example:

"Pick 4." Worker scans SKU. "Confirmed. Pick 4." Worker says "4." This is especially useful for look-alike SKUs, regulated products, serial numbers, variable-weight products, or unfamiliar workers.

Start with one narrow workflow

I'd avoid attempting to voice-enable the entire warehouse.

A sensible pilot is:

one facility → one zone → one picking process → one shift → 5–20 users

Measure:

• picks/hour
• lines/hour
• pick accuracy
• short picks
• exception rate
• ERP transaction latency
• voice recognition failure rate
• worker training time
• time spent walking
• system downtime/recovery

There is evidence that voice implementations can improve productivity and accuracy, but vendor-reported percentages vary substantially, so I'd treat those figures as hypotheses to validate in your own operation rather than business-case guarantees.RFgen Software+1

Design for legacy-system realities

The integration layer should include:

Idempotency. If the worker says "confirm 6" and the network times out, retrying must not accidentally post 12.

Local task caching. The worker should be able to finish the current interaction through a brief network interruption, then synchronize safely.

Correlation IDs. Every voice interaction should map back to an ERP transaction/task ID.

Audit trail. Record:

task ID
worker/device
timestamp
spoken intent
interpreted command
ERP request
ERP response
final outcome

Explicit exception paths.

Don't design only the happy path. Give the worker commands for:

• "short"
• "location empty"
• "damaged"
• "wrong item"
• "can't find"
• "repeat"
• "skip"
• "supervisor"

Exception handling is one of the areas that deserves as much workflow design as the normal picking path.Atomoving

Hardware doesn't have to be exotic

Typically you need a rugged mobile device, headset and microphone, plus the software/integration layer.BCI

Before buying hundreds of devices, test:

• Wi-Fi roaming
• noisy environments
• freezer/cold areas if applicable
• forklift vibration
• headset battery life
• microphone performance
• device ergonomics
• speech recognition with your actual workforce/accent mix

Wireless coverage is particularly important because voice interactions are continuous rather than occasional scanner transactions.Shiptify

A practical phased roadmap

That last point is strategically valuable. If you eventually migrate from the legacy ERP to a modern WMS, the workers can potentially keep the same voice workflow while you swap the integration adapter underneath it. That is one of the reasons voice can be deployed before a WMS replacement.Lucas Systems

The core principle

Don't "voice-enable the ERP." Voice-enable the warehouse workflow.

Keep:

ERP → business truth

and introduce:

Voice layer → task execution

with a small, well-defined integration contract between them.

That gives you most of the operational benefits of voice-directed picking while avoiding a risky rip-and-replace ERP project.