Running a single restaurant is hard enough. Imagine running a whole chain of restaurants scattered across various locations! Multi-chain restaurants face a whole other level of challenges, especially when it comes to managing their operations. This blog explores these operational issues faced by multi-chain restaurants.
Single location restaurants have it relatively easy from an operational angle. You have a store where raw materials are purchased and stored, then issued to various cost centers (if applicable), such as kitchen/bar/brewery, etc. You then track inventory at both the store and the outlet where sales are recorded. Boom, done!
Again this depends on the type of establishment and can further be simplified if they are selling only food. In that case, there is no split of cost centers (or any other name you want) and less operational headache.
We have often come across multi-chain restaurants that struggle with mimicking their backend operations, more from a tech point of view. It’s impossible to track with MS Excel. Moreover, some rudimentary softwares are too inflexible to handle the complexity of operations.
When the enterprise is till about 2-4 locations, it’s not too difficult to manage operations. The owner spends a lot of time, running through scores of Excel sheets on a daily basis. Eventually it starts affecting them, as they plan for scale. Only then do they figure out that scaling is arduous until they sort the backend.
Let us take an example of multi-location enterprises and their operations. We would also cover them from transfer, approval, returns, data visibility, and access control angles.
Most chains have individual stores till about 3 locations. And then, at some stage, a central kitchen and central store come into the picture. There are several advantages to centralizing the store and kitchen, but that’s a different topic altogether.
Typical flow is likely to be:
- Suppliers provide raw materials to the CS (Central Store) with or without purchase orders
- Central Kitchen (CK) requests raw materials from the CS
- Individual sales locations may request raw materials from the CS
- CK produces semi-finished/finished goods
- Sales locations request semi-finished/finished goods from CK
- For each request, necessary transfers are made
If you are wondering why sales locations have an associated ‘virtual’ store, this is to track inventory and consumption granularly, if that’s your need. If your sales location doesn’t take raw materials from CS, you won’t need a sub-store. Note that this will require another level of indent/transfer.
The above chart might vary a bit, but well-established multi-chain restaurants typically follow this process. As you can see this flow can be quite challenging to implement from a software angle, as there are nuances and complexities.
Let’s break this down step-by-step:
Step 1: Purchase
A purchase order is optional in some enterprises, and mandatory in some cases. In some multi-chain restaurants, it could be possible that every PO is also reviewed and approved. Again, approval can be single-level or multi-level. In some cases, POs only above a ‘threshold’ may need approval.
Who would want to sit and approve every small order? Also, what happens when the approver(s) are not available? Do we need to skip or find alternate at each level? In case of some orders, should we also consider auto-approval after a pre-decided time-lapse? Also, what happens when a PO is returned, with a note? And say, there are 3 levels, how do you handle approval at 1 level and reject at the next level? What about spot/cash purchases where a PO cannot be placed?
These are some of the things a product owner/manager needs to consider while designing the flow. Some of these can get quite messy from an implementation point of view. Furthermore, many of these need to be ‘configurable’. When I say configurable, we can look at the below options.
- Does your PO require approval?
- How many levels?
- Email addresses, and title of each approver.
- Alternate approver/auto approval for time-lapse.
- Threshold amount that requires approval.
Step 2: Indents and transfers
A restaurant’s different locations place indents (a.k.a requisitions) to one or many central units. There are 2 types of indents – raw material (SKU), and semi/finished good (recipes). Some enterprises don’t follow indents and transfer the ‘items’ directly too.
It would be a wise idea to segregate SKU vs recipe transfers, the main reason being simplicity and ease of use. The form essentially takes the list of items and quantity required, with additional notes or specific terms.
Similar to a few angles we considered for POs, following are a few considerations as a product owner:
1) Should we show ‘current stock level’ and ‘stock level at destination’?
2) Should we show the individual price and total?
While the above points look harmless at first sight, one needs to also consider use cases where a centralized location is company-owned & the indentee is a franchisee. Also, some enterprises don’t want their staff to face complex forms, leading to increased confusion. It is pertinent that we know the cost of a transfer, as it needs to be apportioned to the receiving location. It ends up as a purchase, gets added to stock in receiving location, and gets debited from transferring location.
For a franchisee use-case, the company owner may not want the franchisee to even know how much inventory they hold. What purpose does it serve? From the requester’s view, all he bothers about is, “Send me these items”. The transferee needs to figure out how to provide what’s asked.
Mark up:
Another issue is the ‘mark-up’ rates. Typically company owners with franchised locations mark up both raw material and semi-finished goods. This gets invoiced and paid. If we allow prices to be shown “by default”, the franchisees will be up in arms and the owner isn’t going to have a good time!
However, in some cases, it might make sense to show this information. A user can make ridiculous mistakes with data entry (abnormally high quantity entries) and typically the transferee validates the request. Showing price in these cases will alarm the user and he can make necessary corrections at his end itself. Smarter tech platforms can even automatically highlight ‘perceived anomaly’ with data entry.
Say, the average consumption of ‘Paneer’ in a location is 300 kgs/month, averaged over the last 3 months. Suppose there are 15 indents per month, say every 2 days. We can also see the past indents and figure that the requested quantity ranged between 10-30kgs.
While we don’t have to worry about the lower end, the high end can act as an alarm threshold. Say, an entry in an indent used 200 kgs as opposed to 20, or even say 50 kgs. In this scenario, the system can throw a popup, “Are you sure, bud? Seems too high!”
Solution:
A good way to handle these ‘optionality’ is to make things configurable. The enterprise can choose whether their prices or stock levels need to be made visible to the requester. This applies even if all locations are company owned and operated. This provides much-needed flexibility to the user.
Approvals for indents (some enterprises follow), in my opinion, are a criminal waste of time and an additional burden. We have come across some enterprises who ‘demand’ that they have 2 to 3 level approvals for indents. The state machine for this can be tedious – to’s & fro’s, reporting angle, use-case of a chef or a finance controller not being available, and not being able to approve within a designated time. This can probably work for a very large well-oiled enterprise with enough manpower but is unlikely to work for SMEs.
Typically, the approver also doesn’t have enough contextual ‘information’ if the asked quantity is right/wrong. On what basis will they approve or make corrections? A CS of a 10-12 location chain, for instance, receives about 1000 indents a month. At the same time, the CK receives about 600 a month. Good luck going through approval hoops!
Since a lot of indents are placed on a daily basis, a software provider could think of how this can be automated (semi). I have also come across softwares trying to fully automate this. But unfortunately, they have some pitfalls that can potentially hurt your operations (a different topic altogether).
An easy way to reduce manual effort & semi-automate indents is to create pre-defined templates. It could be a template for Mon-Tue, Weekends, Staff items, and whatever is ordered at a regular frequency. The user then creates a requisition from the indent and adjusts the quantity depending on need, the volume of sales, stock availability, etc.
Step 3: Transfer and Returns:
One of the most common questions we face is how does the receiver approve the transfer? This question arises, arguably due to legacy reasons or some operators needing to fix accountability on both the transfer/receiver sides. This usually arises when the quantity transferred does not match the quantity received, i.e there has been some ‘loss’. What are these losses?
- Transferror ‘intentionally’ sends a lesser quantity than entered into the system
- Items get damaged in transit
- Items are received in toto but damaged by receiving side
Providing a ‘receiver’ approval in some cases is just an added complexity. This is because the receiver can always fake that items were not received as ‘sent’ and take some home. Or if you allow edits to the receiver, he can always adjust and show that a lesser quantity was received or some items just didn’t arrive. In these cases, the transferor and receiver are up in arms, each backing their stance. In addition to this, there will be no proof of malpractice from either end.
Solution:
The key in these situations is to fix accountability at one end, something the software implementor can choose. In EagleOwl, we decided to fix the accountability on the transferring side. A transfer once done, cannot be edited by the receiver, ever. If there is an issue with the quantity or number of items, the receiver is free to return those items by doing a reverse transfer! This way, there is a clear trace of item flow and the transferor has to explain how or why he got them back.
But yes, mistakes can happen while transferring, so the transferor can edit a transfer to correct the mistakes. Similarly, if there is a wastage at either end, they can record accordingly. But what happens when there is damage or waste during transit? Who is responsible? As I said earlier, fix it at one end, in our case we believe the transferor takes the responsibility.
With such a flow in place, it eases the operational process and brings in more efficiency, also helps keep a clean account of inventory at both ends. Different platforms might handle this in different ways, but we believe this fixes accountability and also creates flexibility.
In conclusion:
Above are use cases that most multichain restaurants face on a daily basis. At times they also adapt depending on the software flow. The software provider also faces varied and differentiated requirements from different chains, but then they need to know that not all requirements are feasible, depending on how they have designed the flow. However, for most practical purposes, some of the suggestions above would suffice.
EagleOwl is a robust BOH solution that helps multi-chain restaurants increase their efficiency and profitability. With our software restaurant chains are able to increase their profitability by up to 25%. Get in touch with us today to know how.