Most hospitals buy a system before the process is defined. The software then reproduces the workflow that was not working before, and the problem becomes more expensive than it was, because it is now written into a licence.
This article describes the sequence that works instead: first the assessment of the ordering chain, then the requirements, then the selection, then the implementation. It is written for commercial directors, IT leads and heads of food service.
Why the software is rarely the problem
Meal supply in a hospital is a chain: ordering on the ward, documentation of diets and allergies, production planning in the kitchen, picking, distribution and returns. If the chain breaks at one point, the result shows up at the end as incorrect trays, as additional production or as waste.
A system placed on top of an unclear process makes the break faster and documents it, it does not fix it.
The wider context is covered in our article Why hospital digitalisation projects fail (in German).
Process assessment: what comes before any system selection
The ordering chain from ward to kitchen
Who records what and when, how a short notice change reaches production, how long the chain takes today, and where information is copied out or retyped.
Diet and allergen logic as a data model
Diets and allergies are not a free text field but a structure with rules, exclusions and responsibilities. If the hospital does not define that structure up front, the software vendor defines it.
Interfaces as a requirement, not an afterthought
Which data has to come from the hospital information system, which from materials management, and which flows back. We phrase the interface demand as a requirement towards the vendors. We do not program interfaces.
From requirements to vendor selection
Requirements that make offers comparable
A requirements document describes process steps, data objects, roles and interfaces precisely enough for vendors to price the same task. Without that basis, hospitals compare presentations rather than deliverables.
Evaluation matrix and selection process
Criteria, weighting and scoring logic are fixed before the vendor sessions. Functional coverage, interface capability, operating model, master data effort and hospital references are scored separately and documented.
DSC-Consult does not develop or operate software. We define the software strategy, run the vendor selection together with the hospital, and implement the third-party system as part of the overall project delivery. Independent of any system vendor.
Implementing the selected third-party system
Master data and migration
Recipes, components, diet codes, ward structure. The effort almost always sits in the master data, not in the installation.
Parallel operation and cut-over during live operations
A hospital kitchen cannot shut down. The cut-over runs ward by ward or meal by meal, with a fallback level in place.
Training, roles and ownership after go-live
Who maintains recipes, who changes diet rules, who decides when something fails. Without named roles, operations fall back to the old routine.
How to measure whether it worked
The following indicators are useful:
- Share of incorrect trays
- Time from the diet instruction to the effective change in production
- Return rate
- Food waste per catering day
- Number of manual re-entries
The baseline values have to be measured before the implementation, otherwise nothing can be evidenced afterwards.
Frequently asked questions
Do we need the software first or the process first?
The process first. A system selection only works once the requirements are known. Whoever selects first adopts the process logic of the vendor.
Does DSC-Consult build its own solution?
No. DSC-Consult neither develops nor operates software. We define the software strategy, guide the selection and implement the chosen third-party system within the project.
Who implements the system, the vendor or the consultancy?
Both, with a clear split. The vendor is responsible for its product. DSC-Consult is responsible for the process, master data, interface requirements, schedule and the handover into regular operations.
How long does an implementation take?
The duration is driven by three factors, namely the number of wards, the state of the master data and the number of interfaces.
Can we run the selection ourselves and only outsource the implementation?
Yes, that is a common split. The downside is that requirements which were not captured properly during the selection reappear as change requests during implementation.
Does this apply to staff catering and the cafeteria as well?
Yes, the logic is the same. The rule sets differ, the sequence does not.
Discuss the digitalisation of your meal supply
Dr. Julius Bornschein. Direct contact: jb [at] dsc-consult [dot] com