Guides / Operating intelligence
Almost every operation this size has had a dashboard built at some point. Most of them get opened twice. Six numbers get used. How they reach you matters more than what they look like. And the data underneath has to be right first.
You've probably lived through this one. Somebody builds a dashboard. It looks good in the meeting. Two people open it that week, one opens it the next, and within a month it's a browser tab nobody has clicked since. The data was fine. The charts were fine. It still died.
I ran a machine shop for a decade and then built exactly this kind of thing for manufacturers, so I have been on both ends of that. Dashboards aren't bad. They just ask you to remember to go and look, and the people who most need the numbers have the least slack in the day to go looking.
Ask for a dashboard and you'll list twenty numbers. Watch what you actually ask about out loud in a normal week and it's about six. These are the six that stick:
Most of those need two systems to answer. Backlog and on-time delivery live in the ERP. Cash and receivables live in the books. Quoting often lives in a spreadsheet. That split is the actual reason nobody has a single clean read, and it's a plumbing problem rather than a charting one.
The version that keeps getting used isn't a dashboard at all. It's a short read that arrives on its own.
For a mid-size manufacturer I work with, that's an owner's morning brief. Overnight, a job reads the ERP and the accounting system, assembles the numbers, and emails one page: cash-flow forecast, current backlog, sales month to date. He reads it before he is on the floor. No logging in, no running three reports, no remembering that the dashboard exists. Alongside it runs a monthly KPI briefing: on-time delivery, quality, scrap, quoting and sales, with the trend filled in, dropped straight into the spreadsheets the team already used.
It works for a dull reason. It removes the step where a busy person has to decide to go and look. That step is where dashboards die. Everything else about the two approaches is the same data doing the same arithmetic.
None of this rules out a screen. If you have people who genuinely live in a dashboard, build one. Just don't assume the screen is the point. The point is that somebody knows the number.
Now the part where I'd talk you out of it. A KPI read is arithmetic on top of what your systems already recorded. It inherits every problem underneath it, and it inherits them silently, presented in a clean layout that makes them look authoritative.
Do it in this order: pick the six numbers you'd actually act on, check the data behind each one is real, fix what isn't, then automate the delivery. Doing it in the other order produces a very tidy report that quietly misleads you, which is worse than having no report at all.
Nothing gets replaced. Your ERP stays the system of record and your accounting stays where it's. What gets added is a thin layer that reads both on a schedule, does the assembling and the arithmetic once, and delivers the result where you'll actually see it. It runs on infrastructure I host and keep running, working on top of the systems you already have.
It starts with a paid Diagnostic, where the real work is deciding which numbers are worth the trouble and which of them your data can honestly support today. Then a Build, quoted up front, so you know the price before it starts. No hourly billing and no per-seat license.
Both of the things described above are deployed and in daily and monthly use at a mid-size manufacturer, reading its real ERP and its real books. The monthly briefing gave a controller back hours every month-end by filling in the spreadsheets that used to be assembled by hand. The systems and the results are real; the client stays anonymous.
See selected work →Usually not at your size, and I would rather say so. A warehouse plus a BI license plus somebody to maintain both is a real ongoing cost, and it earns its keep when many people are exploring data in lots of directions. If what you actually need is six numbers delivered reliably every morning, that's a much smaller piece of work and it doesn't need a platform underneath it.
That's normally the whole point. The questions worth answering tend to need the ERP and the accounting system together, which is exactly why they have never been on one page. Reading both and doing the arithmetic in one place is the work.
Then you have learned the most valuable thing available, and you have learned it before you made a decision on it. It happens often. A daily read makes bad data visible fast, while people still remember the day in question, which is usually what finally gets the entry cleaned up.
I do. I build it, host it, and keep it running on managed infrastructure, with an ongoing care plan covering hosting, monitoring, fixes, and small adjustments as your operation changes. Term and price by agreement. It isn't something that gets handed to you to look after.
Related reading. The numbers behind a KPI read have to come out of your ERP first, which is the subject of JobBOSS custom reports, M1 ERP reporting and the rest of that series. If the ERP and the books don't talk yet, start with JobBOSS QuickBooks integration. On project work rather than production runs, the status read looks different: software for machine builders.
First call's free. About 30 minutes, a straight conversation about how your operation really runs, not a demo. If there's something worth building, I'll say so; if there isn't, I'll say that too.