The first time I saw a growing operation become less manageable the more orders it took was at a corporate catering firm in Ankara. The company was expanding; with 312 employees, it was serving three of the city’s largest institutional clients. The books were clean, logistics were manageable, and customer satisfaction reports read well. Yet the kitchen generated at least two daily emergencies: missing ingredients, incorrect portion counts, last-minute menu changes. Management called it a ‘communication problem.’ I saw something different: an operation where decisions were made before demand ever entered the system — in other words, where the digital flow had never actually begun.Applying MRP to catering is structurally different from applying it to factory production. Standard MRP logic assumes repeating demand, a fixed bill of materials, and predictable lead times. Corporate catering is the structural opposite: every order potentially differs from the last, dietary restrictions aren’t confirmed until the final day, and protocol changes can disrupt kitchen capacity without warning. Any ERP or production planning module installed without encoding this variability ends up as something the finance department validates but the kitchen ignores. My central argument is this: the primary obstacle to digital flow in catering is not software selection — it is failing to define when and in what format customer demand is formally committed to the system. Without answering that question first, every implementation converges on the same dead end.The first thing I did at the Ankara firm was count how many hands a customer request passed through before becoming a production order. The result: eight steps, four of them conducted by phone or email, two face-to-face, only two recorded in any system. Roughly half of the demand flow lived entirely outside digital infrastructure. Menu alternatives existed in the sales team’s memory; portion standards resided in the head chef’s experience; information about unavailable raw materials was in the purchasing officer’s phone contacts. The system could not function independently of those three individuals because it had never received their knowledge. The root of the operational inefficiency was not a technology gap — it was the absence of any defined process for converting operational knowledge into structured data. Before touching the ERP module, that definition had to come first.We restructured the process in three steps. The first was fixing order templates. In catering, the idea that ‘everything is customisable’ is an efficiency liability. The firm had more than 400 active menu combinations at the time; the vast majority were ordered fewer than three times a year. We reduced the menu portfolio to 47 core combinations and assigned a standard bill of materials to each one. From that point on, the ERP’s material requirements engine finally had real data to work with. The second step was designating customer order confirmation as the formal entry point of the digital flow. When a client confirmed by email, the system automatically generated a draft production order, calculated raw material requirements, and routed them for purchasing approval. This single change eliminated the late-breaking procurement requests that had routinely arrived within two working days of production. The third step was opening a ‘recipe deviation’ record for kitchen staff: when actual production differed from the standard recipe, the chef logged it in the system. Within six weeks, those records revealed which menus generated the highest concentration of raw material waste, and purchasing quantities were revised accordingly.The integration point where I encountered the strongest resistance was mobile ERP use. By 2012, the majority of the firm’s staff owned smartphones, but running enterprise applications on those devices was not yet standard practice in Turkish mid-market operations. The idea of kitchen chefs tracking production orders on tablets gained board approval quickly; in practice, most chefs kept their paper lists. This was not a technical failure — it was a habit and trust problem. The chef could not tell whether the number on the tablet screen was real or ‘something the computer estimated.’ To close that gap, we ran 15-minute morning stand-ups in the kitchen for two consecutive weeks, working directly through the tablet screen with the team. As chefs questioned the data and received answers, their confidence in the system grew. User adoption took longer and consumed more energy than the technical installation itself — a pattern I have seen repeat in similar projects.One important boundary needs to be stated plainly: this approach does not apply equally to every catering business model. Corporate meal services and large-scale event catering have sufficiently standardised menu structures to make this method viable. In premium event catering or ‘everything bespoke’ positioning, however, menu standardisation risks eroding the very competitive advantage the business is built on. In that segment, a digital flow can still be built — but it should be anchored in a customer relationship module, not production templates, and planning should be designed around capacity reservation rather than deterministic scheduling. Same software, different configuration: the correct architecture is determined not by the sector but by the business model.By the time we completed the project in Ankara, emergency procurement requests during production had largely disappeared. Measurable raw material waste declined against the prior period. Kitchen chefs embraced the system because it gave them a ready production list each morning rather than additional administrative work. Management was able to review menu pricing using actual cost data for the first time. What had looked like a software project from the outside was in fact an operational structuring exercise. If you are working in a similar institution, ask yourself: how many steps lie between a customer order and a kitchen production list, and how many of those steps leave no digital trace? If the answer is more than two, fixing that gap will return more value than any software purchase you consider before addressing it.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 17, 2012. The English edition has been reviewed and edited by the author.