The guide · The systems
The SaaS guide.
Choosing, rescuing and getting more from the software your trade and your business run on. Read what you need, then book the call.
Choosing an ERP or MES
An ERP or MES is the longest relationship a manufacturer has with a piece of software. Most of the pain people blame on the product comes from picking it on the demo. Here is how to pick it on your own requirements, and what to make of the AI features every vendor now shows.
Requirements from the floor, not the brochure
Walk the process before you look at a product. Write down what has to be true for quoting, order entry, scheduling, the floor, shipping and invoicing, in your words, with the exceptions everyone knows about. Then rank them. A system has hundreds of features; ten of them decide whether it works for you. Knowing the ten before the first demo is the whole difference between choosing and being sold.
Run the demo on your ugliest data
Every demo runs beautifully on the vendor's data. Bring yours. A real week of orders, a real job with a rework loop, the drawing with three revisions, the customer with the odd invoicing rule. Ask them to run it in front of you. Where the presenter says that would be configured later, write it down; that is where your money will go.
What the AI features are worth
Every system now shows an assistant. Ask three things about it. What data does it work on, yours or a sample. What can it change, or is it read-only. Which parts have shipped and which are on a roadmap. Over five years the question that matters most is whether the system gives an AI a governed way in at all, because that path is what the next decade of automation will run through. A single clever feature today matters far less.
The costs not on the quote
Data migration and the cleanup it forces. Training, and the weeks of lower output while people learn. Customization, which is cheap to add and expensive to keep, because every custom piece is a reason you cannot upgrade. The second-year subscription. The internal owner's time, which is the cost most often forgotten and most often the reason a rollout stalls. Add them up before you compare quotes, or the comparison is fiction.
Buy, configure or build
Most small manufacturers should configure a standard system and change a few of their own habits to fit it. Building your own sounds cheap and rarely is. Heavy customization of a standard system is the worst of both: you pay for the product and then pay again to stop it being the product. The exception is a genuinely unusual process that is your advantage; protect that one and let the rest conform.
How we help
Requirements written from your floor. A shortlist that fits your size and your industry. Demo scripts built on your data, and a scoring sheet so three demos can be compared honestly. The questions to ask about data, exit and the AI path. What fits comes first, partner or not.
What a system really costs
Every vendor's quote is a true number and an incomplete one. The rest of the cost is on your side of the table: the data, the training, the customization you will regret, the second year, and the people. Here is how to add it up so three quotes can be compared honestly.
What the quote leaves out
Data migration and the cleanup it forces. Training, and the weeks of slower output while people learn. Customization, cheap to add and expensive to keep. The subscription in year two, when the launch discount ends. Integrations to the systems the ERP does not replace. Hardware and scanners on the floor. And the one nobody writes down: the internal owner's time. Put each on its own line before you look at a vendor's total.
The five-year column
Lay every quote out over five years, not one. Licence or subscription each year, implementation once, the support tier you will actually need, the upgrades, and the customization you plan to ask for with a line for what it costs to keep through each upgrade. A system that is cheapest in year one is often the most expensive by year five, and the vendor knows that when they price the first year.
Customization is a loan
Every custom piece is code the vendor did not write, will not test, and will not carry through the next upgrade for free. Some customization is right, for the one process that is your advantage. Most of it is a habit the business could change more cheaply than the software. Count each request as a loan with interest, and ask whether the process could bend instead.
Your people's time
A rollout takes a person inside the business half their week for six months, and that person is usually the one who already runs the office. What they stop doing is a cost. What it does to them is a cost. Plan the backfill, or plan for the rollout to stall in month four when they burn out, which is the most common reason they do.
How we help
The five-year sheet, built with you, filled from your data and each vendor's real numbers. The customization list scored as keep, bend or drop. The internal owner named and backfilled. Then three quotes compared on the total, not the front page. What fits comes first, partner or not.
In the middle of an implementation
Most ERP and MES rollouts do not fail at the start or at the end. They fail in the middle, quietly, when the data migration is late, the scope has grown, the internal owner is exhausted and the vendor's team has moved on to the next customer. If that is where you are, it is a common place to be and a recoverable one. Here is what usually went wrong and what to do now.
Where rollouts really fail
Data that was never cleaned before it was migrated, so the new system is confidently wrong. Scope that grew one reasonable request at a time until the plan no longer fit the budget. Customization that made the system yours and unupgradeable. An internal owner who was given the project on top of a full-time job. A vendor whose best people were on the sale and whose newest people are on the delivery. Rarely the software itself.
The honest checkpoint
Stop and write down four things. What works today, tested by your people on your data. What is built but untested. What is promised but not built. What has been paid. That page is usually the first time everyone in the room has seen the same picture, and it is the basis for every decision after it. We write it with you, and we write it without a stake in the answer.
Scope, back to the ten things
Go back to the requirements that mattered when you chose the system, the ten that decide whether it works for you. Everything else in the current scope is a candidate for later, or for never. Cutting scope in the middle of a rollout feels like failure and is almost always the move that saves the project. A system that does the ten things on time beats one that does forty things next year.
Data, the part nobody wants to do
If the migrated data is wrong, nothing else matters, and no go-live should happen on it. Cleaning the item master, the customer list and the open orders is dull work that the vendor will not do for you and the internal owner has no time for. It needs a person, a deadline and a definition of clean. It is the most common thing we end up organising in a stalled rollout, and the most common reason the rollout stalled.
An independent eye on go-live
Someone in the room who reads the plan, sits in the vendor meetings, checks the test results against your requirements rather than the vendor's checklist, and tells you plainly whether the date is real. Not to run the project, which stays yours, and not to sell you anything, but to be the person whose only interest is that it works. That is what an owner's representative is, and a stalled rollout is exactly when one pays.
The system you already run
Most manufacturers who want to replace their ERP are using a third of it. The rest was never configured, never trained, or was replaced by a spreadsheet the week after go-live. Before you buy again, it is worth finding out what the system you have could do, what an AI layer could add to it, and whether the honest answer is still to switch.
The audit nobody does
List the modules you own. Mark the ones in daily use, the ones half used, the ones never turned on. Then list the spreadsheets that have grown around the system and what each one does. The picture is usually the same: the system could do most of what the spreadsheets do, and nobody set it up because the rollout ran out of time. That is a configuration project, not a purchase, and it costs a fraction of a replacement.
What an AI layer can add now
If the system's maker has shipped an assistant, or a governed way for an AI to read the data, a good deal of what you wanted from a new system may be available on the old one: orders read from email, invoices matched, reports written, status questions answered. Ask the vendor the one question, whether an AI can read and act on your data, and what it costs. An old system with a real AI path can outlast a new one without.
Training, again
The people who were trained at go-live have left, and the ones who replaced them learned from the ones who were leaving. A day of training on the system you own, on your data, for the people who use it now, is the highest-return spend in this whole subject and the one most often skipped. Do it before you judge the system.
When switching is the honest answer
The vendor has stopped developing it, or has no AI path and no plan for one. It cannot do one of the ten things your business now needs, and configuration cannot make it. The customization has made it impossible to upgrade. Your people have tried and it still fights them. Any one of those is a real reason. Wanting a new demo is not, and we will say so.
How we help
The audit, in a few days, with your people. A configuration plan for the modules worth turning on. The AI question put to your vendor, and the answer read for what it is worth. A plain recommendation: keep and fix, keep and add, or replace, with the costs of each, and the one that fits, partner or not.
Choosing software built for your trade
Every trade has software written for it: the restaurant has its point of sale, the practice its practice system, the contractor its field service app. Written for the trade, it already knows the jobs. The question is whether it knows yours.
What specialist software gets right
It speaks the trade. The restaurant system knows about covers, courses and tips. The property system knows about units, leases and late fees. You configure it rather than build it, it arrives with the reports your trade expects, and the people you hire have often used one like it. For most small businesses that is a better start than a general system and six months of setup.
Where it falls short
It is built for the average business in the trade. If the way you work is the reason customers choose you, the specialist system may push you toward the average. It can also be an island: good at the trade's jobs and poor at talking to the accounts, the payroll or the next system you add. Check both before you fall for the demo.
Comparing three honestly
Write down the ten things that have to be true, in your words, before any demo. Give each vendor the same script built on your own jobs, not theirs. Score as you watch. Ask for two customers your size in your trade and call them. The vendor that is nervous about the script is telling you something.
Where AI comes in
Most trade systems now ship AI features: drafted replies, suggested schedules, summaries of the day. Ask what each one reads, whether it can be switched off, and what it costs after the trial. The page on AI in your business systems has the one question to put to every vendor.
How the systems talk to each other
A small business ends up with five or six systems, and the hours go into the gaps between them: the order typed from the shop system into the accounts, the hours copied from the time app into payroll. Closing the gaps is usually worth more than any new system.
The three ways systems connect
A built-in connection, where the two vendors have already done the work and you switch it on. An automation tool in the middle, which watches one system and acts in another. And a custom link, written for you against each system's published interface. In that order they get more flexible, more expensive, and more likely to need someone to look after them.
What breaks
A vendor changes something and a connection quietly stops. A field means one thing in one system and another in the next. Two systems both think they own the customer record, and they disagree. Every connection needs an owner, a way to notice it has stopped, and a rule about which system is right when they differ.
The question before you buy
Ask for the list of built-in connections, then ask which of them a customer your size actually uses. Ask whether the system has a published interface and what it costs to use. A system that cannot talk to your accounts is a system someone will be retyping into, every week, for years.
Where AI comes in
AI tools are only as useful as what they can reach. An assistant that can read the booking system, the job history and the accounts can answer real questions; one that can read none of them can only write. Connections come first, and they are what makes the AI worth paying for.
One system, or several?
The suite vendor says one login and one database. The specialist says their tool is the best at the thing that matters most. Both are true, and the answer depends on which job in your business cannot be done badly.
What one system buys you
One customer record, one login, one bill, one support line, no connections to break. The modules are rarely the best at anything, and the weakest module is the one you will live with every day. For a business whose jobs are ordinary, that trade is usually a good one.
What several buy you
The best tool for the job that makes you money. A booking system customers love, a quoting tool your estimators trust. The price is connections to set up and look after, several vendors, and staff learning several screens. It pays when the specialist tool changes a number you care about.
The usual right answer
A solid core for the money and the customer record, and one or two specialist tools where your business is different, connected properly. Resist a fourth and fifth tool until the first connections have run clean for a quarter.
Switching without losing a year
The new system is chosen and everyone is relieved. Then the switch takes six months instead of six weeks, because nobody planned the data, the training or the week when both systems are live. The switch is where the money is lost.
Move less than you think
Open customers, open jobs, current prices, current stock, and the balances. History can often stay in the old system, read-only, for the few times someone needs it. Every year of history you move is data to clean, map and check, and most of it will never be opened again.
Pick the date on purpose
Your quietest month, not your busiest. The start of a period, so the accounts line up. Not the week someone key is on holiday. Put it in the calendar before the vendor puts theirs, and hold it.
Train on your own work
Training on the vendor's sample company teaches people the buttons. Training on your own jobs, in a test copy with your data, teaches them the work. Run a real week through the test copy before the date. What breaks there is cheap to fix.
The week both are live
Decide in advance which system is the record from which moment, and tell everyone. Keep the old one read-only. The page on data migration covers the cleaning; the page on implementations in trouble covers what to do when the date slips.