Case study · B2B SaaS · Manufacturing OEE
Closing the two gaps that kept Prochiz on Excel.
Evomo is an IoT-based OEE platform for manufacturing. At Prochiz, a cheese manufacturer, the platform tracked downtime — but didn't calculate what that downtime cost, and had no way to assign or track corrective action. Two features were designed to close those gaps — both inside the existing IA.
Role
UI/UX Designer
Timeline
2 sprints · Mar–Jun 2022
Client
Cheese mfg · B2B SaaS
Focus
Loss calculator & Issue tracker
Process
Artifact analysis→Persona definition→Feature design→Sprint reviews & iterationTL;DR
The loss calculator adds expected-loss columns (pcs and value) to the Pareto view. Prochiz's monthly reports required this — it was filled in manually before. The issue tracker adds PIC assignment, corrective action logging, and status tracking. The weekly per-line report now generates automatically as a side effect of using the tracker.
00 / Context
Evomo connects shop-floor IoT data to management decisions.
Overall Equipment Effectiveness — a 0–100% score for how productively a factory runs. 100% means no downtime, no defects, running at full speed.
How Evomo works
IoT sensors
Data collected
OEE dashboard
Manager reviews
Decision & action
IoT sensorsOn every machine
Sensors installed on each machine automatically detect when it starts and stops. No manual logging required from operators.
Drag or click to explore each step
01 / The Problem
Prochiz's monthly operation had five workflows Evomo didn't cover.
Click the priority gaps to see which feature was designed to close them.
Evomo already had
OEE target not in platform
Reports built manually in Excel
Yield data entered manually in Excel
Expected losses not calculated
Click to expand ▾
No owner, tracking, or record
Click to expand ▾
Priority matrix — Impact vs Effort
02 / Discovery
Both gaps were visible in the CSV before the first interview.
Prochiz shared their monthly reports, downtime logs, and production spreadsheets as CSVs. Two things stood out immediately: a column for expected production loss that Evomo didn't fill, and a corrective action column tracked separately in Excel. Interviews with the Engineer and Plant Manager confirmed both.
Two gaps confirmed in interviews
Monthly reports included an expected production loss column per downtime event
Confirmed by the Plant Manager: this column is required for management reporting. Evomo didn't compute it. Prochiz filled it in manually every month.
Downtime logs had a corrective action and owner column
Confirmed by the Engineer: tracking who owns a problem and what was done is standard on the floor. Evomo had no assignment or status tracking — handled in a separate Excel sheet.
Three personas
Plant Manager
Users
Plant, Engineering, QC, Production Supervisor
Pain
Too much time processing data. Hard to align floor with management.
Access
Dashboard · Analysis · Chat · Download reports
Director
Users
Dir, HoM, HoMS, BU Head, Engineering Head
Pain
OEE data arrives late. Can't verify accuracy. No factory-wide view.
Access
Dashboard · Analysis (Production & Downtime) · Download reports
Engineer (Admin)
Users
Engineer (Admin)
Pain
Floor data gaps make accurate production plans unreliable.
Access
Full config: Runtime · Machine · Schedule · Reason · Product
03 / Design Decisions
Loss calculator and issue tracker — two features, one workflow.
Both features extend what's already in Evomo. No new pages. No new navigation. The loss calculator adds a column where Prochiz needed one. The issue tracker turns the same downtime event into an actionable record.
Feature 03
Expected Losses
One column added to the Pareto view. No new page.
The data was already there — downtime duration, cycle time, product price. The only missing piece was the calculation and where to show it. A new page would have required a navigation step every time. A column requires nothing extra.
Why this column matters
Downtime logged as minutes is a time problem. The same event expressed as 340 pieces and Rp 4.2M is a business problem. The column doesn't add new data — it changes what the data means.
Formula
Expected Loss (pcs) = Downtime (min) ÷ Cycle Time (min / pcs)
Expected Loss (value) = Expected Loss (pcs) × Product Price (Rp / pcs)
Cycle time and product price are pre-configured by the Engineer (Admin) in platform settings.
Pareto view — the added pcs column (expected losses) highlighted.
Feature 04
Core FeatureProblem Tracker — log it, assign it, close it, report it.
Why it matters
The weekly per-line report was assembled by hand in Excel every week. The tracker doesn't create new reporting work — it turns the act of closing an issue into the data source for that report.
The loss-reduction chain
01
Problem occurs
Machine stops, downtime logged
02
Loss quantified
Expected losses (pcs) auto-calculated
03
PIC notified immediately
Tracker opened → assignee alerted
04
Weekly report
Closed issues aggregated per production line
Role walkthrough
Operasional (create)
-Bf5-cM2v.png)
Tapping a downtime block opens the Input Reason modal. Start/end times are pre-filled from the sensor. Operasional selects a reason, adds a note, submits.
Timestamps come from sensors — no manual entry. Manual input is still available for edge cases.
Dashboard — downtime auto-logged
%20-%20dashboard-DHkPxRFE.png)
On the operator dashboard, downtime is automatically logged from sensor data. Tapping a downtime card opens the Input Reason modal.
Input Reason — step-by-step flow
%20-%20input%20reason-b0OAXNjX.png)
Inside the modal: select a reason from the list, add a note, then submit. Start and end times are pre-filled — no manual time entry needed.
Superadmin
Superadmin opens the issue list, selects an issue, assigns a PIC. Status moves from Open to Assigned.
Pareto view — reviewing downtime reasons
Superadmin reviews downtime reasons and loss values in the Pareto view. Clicking a dot on the chart then selecting 'Pilih Sebagai Issue' converts it into a tracked issue.
Issue list → Edit Issue
On the Issues page, Superadmin selects Edit on the relevant issue. The Edit Issue dialog opens — status is changed and a PIC is assigned to take ownership.
Edit Issue — status, PIC, and corrective instructions
Inside the dialog: select a status, assign a PIC, and write corrective instructions in the Tindakan Perbaikan field before submitting. The assigned PIC receives a notification.
Operasional (fix)
-pTgI_XMw.png)
Operasional opens the assigned issue, sets it to In Progress, logs the corrective action, then closes it.
Notification — assigned issue alert
%20-%20notifikasi-CDtv2TAo.png)
Once Superadmin assigns a PIC, Operasional receives a notification on the dashboard. Tapping it navigates directly to the Issues list.
Issue list → Edit Issue
%20-%20issue%20list-BqEp_DsC.png)
Operasional finds the assigned issue in the list and selects Edit. The dialog opens — status is updated to In Progress to signal work has started.
Log corrective action and close
%20-%20edit%20issue-BpFZyTUm.png)
Operasional logs the corrective action taken in the Tindakan Perbaikan field, sets status to Close, and submits. The issue is resolved and recorded.
Prototype walkthrough
Design decisions
Issue creation from the Pareto row
The expected-loss figure stays visible while logging. A separate page breaks that context.
Superadmin: Open first, then assign PIC
Open means acknowledged but unassigned. Assigning before reviewing skips the accountability step.
Operasional entry point is a notification
Floor staff don't watch a dashboard. A push notification is the only reliable handoff signal.
Three statuses only
Every person interviewed used exactly these three states. Pending approval didn't exist in their process.
Session tied to the operator, not the line
Same line, different shift, different context. The session field makes weekly reports attributable.
Closed issues feed into Trends
Closure isn't the end. Each resolved issue becomes input for the next Pareto cycle.
04 / Outcomes
Two gaps closed.
Before and after for each.
| Job | Before | After |
|---|---|---|
| Expected loss calculation | Calculated by hand | Auto-computed in the Pareto view |
| Problem tracking & weekly line report | Manual ledgers + Excel report built weekly per line | Downtime → Issue tracker → PIC notified → weekly report auto-generated |
Plant Manager — weekly BoD presentation
The Plant Manager presents per-line OEE to the Board of Directors every week. Before: two tools assembled into one deck. After: both are in Evomo.
Loss calculator
Per-downtime loss in pcs and value, directly from the Pareto view. No separate calculation.
Issue tracker
The weekly aggregated view shows what broke, who fixed it, and what was done — per line. No Excel.