What this proves
  • ERP data can be normalized into one UI model
  • Status and bottlenecks can be surfaced without ERP screens
  • A front end can be consistent even when the ERP is not
Filter by
View mode
Summary
0Running
0Idle
0Down
0Setup
0Stale
Adapter checks
0Validation warnings
0Stale rows
v1Contract
Status legend
DownStaleRunningIdleSetup
Adapter run log
Live floor map (mock)
Updated just now Freshness 100% Source iot-snapshot

Dataset not available. Please check the snapshot file.

Case study

ERP Lite: turning black‑box ERP data into a readable floor view.

This demo exists because the real operational pain is not a lack of data. It is the time it takes to interpret ERP screens that were built for transactions, not decisions. Line leads and planners need fast answers about bottlenecks, not another menu tree.

We built ERP Lite to prove a pattern: keep the ERP as the system of record, but normalize the data into a stable, human‑readable model that powers a consistent front end. This creates one view that can sit above SAP, Epicor, or SyteLine without rewriting the entire tool every time the ERP changes.

The goal is a decision surface: one place to see what is running, what is blocked, and what needs attention. That is the difference between “the data exists” and “the data is usable.”

// dataset choice

We chose a public IoT manufacturing dataset because it behaves like a real floor: noisy, continuous, and time‑sensitive. ERP data is often batch‑driven. IoT lets us stress the UI model with real‑time style inputs while staying vendor‑agnostic.

// what the data shows
  • Real sensor rows normalized into machine status.
  • Throughput‑style signals derived from numeric fields.
  • A stable UI model despite noisy upstream inputs.
// UI model (current)
  • Machine, Line, Status, Shift.
  • Throughput, Work Order, Last heartbeat.
  • Summary counts for running, idle, down, setup.
// alignment with ERPs

We will align to ERP connectors, not exports: SAP OData/BAPI, Epicor REST/BAQs, and Infor SyteLine IDOs. The adapter layer maps each ERP to the same UI model so the front end remains consistent while the back end varies.

// architecture sketch
  • ERP connector reads only required fields.
  • Adapter normalizes to the UI model.
  • UI renders status and exceptions only.
// why it matters

This reduces the time it takes to get answers. Instead of searching across ERP modules, users see one clear operational view with the few signals that move the day forward.

// what we will measure
  • Time to identify a bottleneck.
  • Reduction in ERP screen navigation.
  • Faster response to down and idle states.
// what we build next
  • Live refresh + change events instead of static pulls.
  • Role views for floor, planners, and leadership.
  • Exception panels for shortages, late orders, and blocked ops.
  • Expansion to inventory snapshots and work‑order risk.
// adapter contract (v1)
  • Machine: id, name, line, status, shift, throughput, workOrderId, lastHeartbeat.
  • Status precedence: Down, Setup, Idle, Running.
  • Validation: required fields + timestamp parsing.
  • Stale logic: heartbeat > 5 minutes old flagged in UI.