Gamifying the ERP: Your Next Business System Will Look Like an RTS

Nobody has ever loved an ERP

Ask a field technician what they think of the company system and you will get a fairly consistent answer. It is slow, it asks for things twice, and it is the last thing standing between them and going home.

That is the real problem gamification is being asked to solve. Not boredom exactly, but friction. The data the business needs sits at the end of somebody's long day, and the system does nothing to make entering it feel worth doing.

So the pitch arrives: add points, badges and a leaderboard. Turn the job into a game.

That is the shallow version, and it is usually dead inside a quarter. Points for jobs closed produces jobs closed, not jobs done properly. A leaderboard across work that is not comparable just tells six people they are losing at something they never entered. And a badge on a screen nobody opens changes nothing at all.

The genuinely interesting idea is not the reward layer. It is the interface.

The good mechanics are in simulation and strategy games

Think about what Factorio actually is. It is a real-time simulation of several thousand interacting entities, with throughput, dependencies, queues, bottlenecks and failure states, presented so clearly that a player can glance at the screen and know that iron is backing up at the smelters. No spreadsheet. No report. You look, and you know.

SimCity and Cities: Skylines solved something similar with overlays: one map, and a series of switchable layers over the top for traffic, power, water, land value and pollution. The city does not change; what you are being told about it does.

Software Inc has you allocating teams and specialists across projects with visible workload and morale. RimWorld's work priorities grid is, structurally, a resourcing matrix — who does what, in what order, with what skill — and it is far more readable than most scheduling modules we have been asked to replace. Anno is supply chain management with a camera.

These games are all doing the job an ERP is meant to do: taking an overwhelming amount of interdependent state and making it legible enough to act on, in real time, under pressure. They have been iterating on that problem for thirty years with an audience that will quit instantly if the interface fails them. Enterprise software has been iterating on the same problem with a captive audience that cannot quit.

Guess which discipline is further ahead.

Your ERP is already a factory. It just refuses to draw itself.

Take an operations business — say a lift company, since that is where a lot of our work sits. The system already knows:

• Jobs at various stages, each with dependencies that must clear before the next stage can start
• Technicians with skills, tickets, locations and finite hours
• Stock in bays, some of it allocated, some of it on order, some of it holding up a job
• Vehicles, plant and equipment, each with a holder and a service date
• Warranty claims, invoices, quotes and leads, all sitting at some point in a pipeline

That is a production simulation. Every one of those things has a state, a rate and a bottleneck. But it is presented as eleven separate list views, and the bottleneck is only discovered when someone rings up about it.

A game would not do that. A game would put it on one board, colour the thing that is stalling, and let you click on it.

The mechanics translate almost directly:

• Alerts that come to you. A strategy game does not make you scan for problems. It tells you where the problem is and gives you a key to jump there. A job whose install date has slipped inside its lead time should announce itself.
• Overlays instead of screens. One view of the operation with switchable layers — capacity, risk, margin, geography, age of last contact — rather than a different page per question.
• Selection and command. Select several jobs, issue one instruction. Batch actions are just unit control groups.
• Rates, not totals. Games show throughput and trend, because a total tells you nothing about whether you are winning. Most ERP dashboards show totals.
• Speed and pause. Being able to run the schedule forward and watch where it breaks is scenario planning people will actually use, because it feels like playing rather than modelling.
• Fog of war. Honestly rendering what the business does not know yet is more useful than a confident number. A site with no access notes is unexplored territory, and it should look like it.

This is already starting to happen

A fortnight ago PGSimCity appeared: an open-source tool that turns PostgreSQL's internals into an interactive 3D city running entirely in the browser. Client connections arrive from the north. The shared buffer pool sits as a grid at the centre of town. Write-ahead logging is routed to its own district in the east, and the maintenance yard in the west houses the checkpointer, the background writer and the autovacuum crews. You can starve the thing deliberately — restrict its working memory and watch sort operations spill to temporary files, or hold a transaction open and watch table bloat set in.

It is a database, drawn as SimCity, and it works.

Two details matter more than the novelty. The first is how it was built. The author has said it began as a single prompt, out of curiosity about what a current model could do, then ran to billions of tokens before being calibrated by hand against the PostgreSQL source. A rendered, interactive, spatially coherent visualisation of a genuinely complex system, prototyped over a weekend by one person who happened to be a domain expert. Five years ago that was a funded team and six months.

The second is the reaction. It went to the top of Hacker News with hundreds of comments, and a version for ClickHouse followed almost immediately. Developers started listing what they would build the same way — Kubernetes, observability dashboards, deployment pipelines, with one person cheerfully proposing Factorio as the visual metaphor for infrastructure state. The appetite is not in question.

The warning is in the same story

Read the responses closely and the criticism is remarkably consistent, and all of it is about the interface. Too much happening at once. Pop-ups covering the thing you were trying to look at. No obvious place to start or stop. Plenty of people said it was beautiful and that they could not tell what it was telling them. One observation cut deepest: your own brain's limits are also your reader's limits, and if a machine builds something too dense for a person to hold, its accuracy does not save it.

That is the whole risk of this trend in one paragraph.

Rendering is not distillation. Putting your operation in three dimensions with particle effects and thirty live counters does not reduce cognitive load, it relocates it. The reason Factorio is legible is not that it is 3D — it mostly is not — it is that decades of design work went into deciding what to leave out, what to encode as colour, what to encode as motion, and what to show only when it matters.

There is a second line worth taking on the chin: if your software needs a guided tour to be comprehensible, the tour is not the fix.

So the discipline this trend demands is subtraction. One question per view. A default state that is calm. Detail on demand rather than by default. If a manager cannot look at the board for four seconds and correctly name the thing most at risk, the visualisation has failed, however good it looks in a demo.

Why this becomes the trend now

Three things have changed at once.

The rendering layer got cheap. A bespoke visual interface used to be the most expensive part of a project and the first thing cut. It is now the sort of thing that can be prototyped in a day and thrown away if it does not earn its place. That changes what is worth trying.

The volume of state went up. Businesses are running more integrations, more automated processes and more agents doing work in the background. There is more happening inside the system than any person can read as a list.

The human role shifted. As routine execution gets automated, the person's job stops being data entry and becomes supervision — noticing, approving, intervening, redirecting. That is not a form-filling job. That is a commander's job.

And a commander's interface is a real-time strategy game. One board, live state, alerts that come to you, the ability to select something and issue an order, and an honest signal about where the front line is.

If you want to move in this direction

1. Fix the friction first. Count the taps in your three most common tasks. A beautiful command view sitting over a workflow that still takes eleven taps to log a service call is decoration.
2. Pick the one question that costs you money. Usually it is which jobs are about to slip, and why. Build the board that answers that question and nothing else.
3. Choose the lightest representation that works. A well-designed board or map with colour and rates beats a 3D city for almost every operational purpose. Save the rendered environment for training and onboarding, where the spatial metaphor genuinely earns its keep.
4. Design the alert before the visual. What should interrupt someone, and what should wait until they look? Get that wrong and people stop looking at all.
5. Test it at four seconds. Show it to someone who was not in the room and ask what is wrong with the business right now. Their answer is your score.
6. Retire what nobody opens. Including the thing you were proud of.

What this means for the gamification question

Keep the mechanics that respect people and drop the ones that rank them. Instant, specific feedback when someone submits something. Visible progress towards a finish line, with the remaining work named. Shared targets rather than a ladder that sorts colleagues. Onboarding structured as a sequence of small wins, because that is the one place classic game structure fits perfectly.

Then aim the real effort at the interface, and at making the honest path the easy one — pre-fill what the system already knows, ask once, put the camera one tap away, and let people finalise the job on the tablet before they get in the ute.

Do that and you may find you never needed the badges. What people actually wanted was a system that showed them the state of things and let them do something about it. Games have been delivering that for thirty years. It is about time enterprise software caught up.

Talk to us about your system

If your team is avoiding the system you paid for, or you are running an operation out of eleven list views and a group chat, the problem is usually findable in an afternoon. We build custom ERP, field service and operations platforms for Australian businesses, and we are happy to look at what you have before anyone talks about rebuilding it.

Get in touch through itsybytesy.com.au and we will arrange a time.

Further reading: InfoQ on PGSimCity and the Hacker News discussion.