ERP system for a restaurant group: how to phase it in

If you have decided a restaurant group needs an ERP, the next decision matters more than the choice of supplier: what you switch on first.

An erp system for restaurant groups fails far more often from being switched on all at once than from being the wrong product. This article is about sequencing, and about the three things that decide whether it survives its first year.

Before going further, be sure you actually need one. The companion article on whether an ERP is right for a restaurant has a five minute test, and a single site almost always answers no.

The three things that decide whether it sticks

Somebody owns it. Not uses it. Owns it, by name, for years. Every ERP that quietly died did so because the person who understood it left and nobody replaced them.

Reality feeds it automatically. Any part of the system that depends on a human remembering to enter something will drift within a quarter. Whatever is entered by hand should be small and infrequent.

People can see the point. A site manager who gains nothing from the extra work will do it badly, and their data is the data everything else rests on. Give each site something back in the first month, even something small like a report they used to build themselves.

The order to switch things on

Start with the module where re-entry hurts most and where the data is already clean.

1. Purchasing and supplier invoices. This is usually the worst re-entry in a group and the easiest to verify, because an invoice is a document with a number on it. Get it right and the finance team feels the benefit immediately.

2. Stock, but only at the level you can actually count. Ambition kills stock modules. Start at the level your team already counts reliably, then go deeper once that is trusted.

3. Consolidated sales. This is where a group stops adding up four laptops by hand. It is also where a mistake is most visible, so do it after the first two have earned trust.

4. Staff and scheduling, last. It touches the most people and it is the one most likely to make somebody's week worse. Move it once the rest is boring.

"The groups that succeed switch on one thing at a time and let each one become boring before starting the next. The ones that struggle try to go live everywhere on the first of the month."

— Tanzeel ur Rehman, co-founder of Get Menu

The Dutch tax detail to get right early

Consolidated reporting is only worth having if the numbers underneath it are correct, and food service is not a single VAT rate.

The Belastingdienst publishes the VAT tariffs and what falls under each. In a group, the risk is not that one site gets a rate wrong. It is that two sites classify the same item differently, and the consolidated report averages the difference into something nobody can trace.

Fix the item classification before consolidating anything. Agree it once, centrally, and check it site by site.

What the ERP will not do, at any size

An ERP is a back-office system. It does not take an order from a customer, and it never will.

Your restaurant pos system handles money at the counter. Beside it sits the ordering layer, which handles everything that happens away from the counter and needs no hardware:

A group that is phasing in an ERP still has customers ordering tonight, which is why the ordering layer is worth running first: it is live in a week, it needs nothing from the ERP, and what it records can feed the ERP later.

• Stamps and tiers for your regulars, automatic discounts attached, the card in the wallet through Google's loyalty card format and no app to install.
• Every order can produce a tax invoice carrying your registration number, downloaded as a PDF without an account.
• A code on each table, designed to look like yours, with the print pack emailed to whoever prints it.
• Group ordering: everyone orders from their own phone and the table gets one bill.
• Your colours and logo on the wallet card, set in a designer, and the card updates itself as stamps land.
• A spreadsheet does the typing: upload it and the whole menu lands in one go.
• A branded page, not a listing: 12 page layouts so the menu reads as yours, and a link you can put anywhere.
• Options and add-ons with their own prices, and required choices the kitchen can rely on, all edited by you in the browser.
• Priced at the moment of checkout, every line, from the menu as it is now rather than as it was when the page opened.
• The order arrives and 3 messages leave in about 2 seconds: a confirmation to the customer the moment it lands, a ticket for the kitchen, a link for the rider with the pin dropped at checkout.
• Sold out means hidden: stock counts on items and options fall with the orders, and zero greys the dish out.

That last line matters for a group specifically. Site-level separation with a single owner view is the normal setup rather than an upgrade, and it is often the reporting people thought they needed the ERP for.

What to measure in the first ninety days

A rollout without a measure of success becomes a rollout that is never finished. Agree these before the first module goes live, and check them monthly.

Re-entry removed. Count how many times one number was typed before, and how many times it is typed now. If that count has not fallen, nothing has actually improved.

Time to close the month. This is the honest headline number for a finance team, and it should drop.

Site manager effort. Ask them directly whether their week got worse. If it did and nothing came back to them, the data quality will follow within a quarter.

Number of disagreements. How often do two reports of the same thing differ? That count should fall towards zero, and if it does not, the problem is item classification rather than the software.

Write the four down, with today's figures beside them, before anyone signs anything. Six months in, they are the only defence against a project that feels busy and has changed nothing.

Before you sign

Ask what a phased rollout looks like in their proposal and whether the price assumes going live everywhere at once. Ask who at their end owns your project after the first three months. Ask how your data comes out if you stop.

Our own pricing is on the pricing page rather than in this article, and the trial runs 15 days with no card. Payment stays with you: cash or your own card machine, with no online payments anywhere in our system, so no card details are held in it, and old order details clear automatically after 120 days.

Frequently asked questions

Which ERP module should a restaurant group start with?

Purchasing and supplier invoices. It is usually the worst re-entry in the business and the easiest to check, because every invoice is a document with a number on it.

Can we go live everywhere at once?

You can, and it is the most common way these projects fail. One module at a time, letting each become boring before the next, takes longer on paper and less time in practice.

Is Get Menu an ERP system for restaurant groups?

No. It is the ordering, menu, stock and loyalty layer that runs beside your counter system. It does not do finance, purchasing or payroll.

Do we still need a POS if we have an ERP?

Yes. An ERP does not take an order or handle payment at the counter. Those are different systems doing different jobs.

How do customers pay?

Cash or your own card machine when the food arrives. Our software carries the order and never touches the money.