erpkaizen.com is an independent publication. It exists to defend one claim:
an enterprise system is where a company stores what it has learned, and the value of each
improvement to it can be measured.
Most arguments about ERP stop at the level of feeling: easier, cleaner, more modern. Those
words do not survive a budget meeting. This site goes the other way — every piece has to say what
was measured, how, and against which baseline.
The problem
At go-live the process is frozen in the shape imagined by people sitting in a meeting room
months earlier. The business keeps learning after that — seasons shift, customers ask for
something new, a clerk finds a faster way — but the software learns nothing.
The gap gets filled with spreadsheets kept outside the system, with conventions passed on by
word of mouth, and with users quietly adapting to a screen that makes them work in an order their
job does not follow. Nobody files a bug, because nothing errors.
A static system and a compounding one
Static system
- Configuration is fixed at implementation
- Adding a product type means editing source code
- People adapt to the software
- Knowledge lives in the heads of long-serving staff
- Success measured as "it went live"
Compounding system
- Business rules are data, editable in the app
- Adding a product type means adding a catalog row
- The software adapts to how the work is really done
- Knowledge lives in the system and survives departures
- Success measured as improvement you can show
What is a UI improvement actually worth?
This is the question most places avoid, because it sounds unmeasurable. It is measurable —
provided you measure before you change anything. Here is the shape of it, with illustrative
numbers:
TaskCreating a delivery note
Times per day40 notes
Before the change95 seconds each
After the change38 seconds each
Per day40 × 57 sec = 38 minutes
Per year (250 working days)158 hours
In working days≈ 19.8 days
What makes that number mean anything: a baseline taken before the
change, on the same group of users and the same season. Without a baseline, every number that
follows is an anecdote.
Task time is only the easiest thing to measure. The others are usually worth more:
the share of entries that have to be corrected, documents abandoned half-finished, how often
someone has to ask a colleague before they can continue, and the lag between something happening
and it showing up in a report.
Four strands
- Concrete improvements. Real cases: what a screen, a field or a flow changed from and
to, and what that changed for the person using it.
- Measuring the value. What to measure, how to baseline it, and how to separate the gain
caused by the change from the gain caused by the season. The hard part, and the reason this site
exists.
- ERP that is usable. Against the assumption that enterprise software has to be hostile,
and that users owe it their patience.
- Improvement as the operating model. How software absorbs what a business works out,
release after release, instead of freezing the process on the day it was signed off.
Three rules
- A piece without a measurement is an opinion piece.
- Numbers taken from a client system are always anonymised. No company name, no
absolute revenue. A ratio carries the argument; a client's tonnage does not.
- Nothing is being sold here. No "book a demo" button at the end of an article.
Who writes it
The material comes from real work implementing and improving ERP for Vietnamese companies. The
practice behind this publication is NextStar. The site stays independent of that work: if an idea
here is useful, it stays useful even if you never contact anyone.