Service Engineering (Five-Phase Development with Resource, Process and Product Model)
When you need this method
Your offering grows around services nobody ever designed. A customer asks for something, someone says yes, and the promise quietly turns into an offering. There is no description of what exactly gets delivered, no defined sequence, and no plan for who needs to be able to do it. The gap only shows up when you scale: every employee delivers something different, effort per project varies widely, new hires cannot be onboarded, and margin differs from case to case.
Approach
- 1Collect and appraise ideas before developing anything. Each idea is checked early for feasibility and market potential, and the phase ends with a documented decision for or against implementation.
- 2Gather requirements from two directions and set them against each other: what the customer wants and what the company can actually deliver. The requirements rated most important become the specification for every later step.
- 3Design the service in three separate models. Product model: service content, service outcomes, and the quality and performance standards. Process model: the delivery sequence, documented in order to remove non-value-adding steps, redundant handovers and media breaks. Resource model: selection and qualification of staff, equipment, and supporting technology.
- 4Draft the marketing concept in the same phase rather than at launch, so that the market and customer view feeds back into the design instead of confirming it afterwards.
- 5Implement inside the company, not on slides: write work instructions, prepare training, procure equipment, and assign responsibilities and decision rights.
- 6Run the launch with testing, roll-out and start-up monitoring, and make final adjustments from customer and employee feedback.
- 7Before the next project, classify what type of service is being built and adapt the phase sequence to it, instead of running every case through the same drill.
Typical application
A typical B2B SaaS in an industrial setting sells an implementation service alongside the licence, grown over the years rather than designed. Two experienced consultants deliver it, each in their own way, effort per project varies by more than a factor of two, and a third consultant cannot be brought up to speed. The team designs the service after the fact. The product model states which four outcomes the customer receives and which standards apply. The process model lays out the seven-week sequence, including the points where the customer has to supply input. The resource model states what qualification a consultant needs and which templates and tools are ready. After that the service can be priced as a fixed fee, and a new consultant is productive within a quarter.
Limits and counter-indications
The method is a sequential phase model and therefore inflexible. Real projects rarely run strictly one step after another, opportunities to parallelize go unused, and the sequence has to be adapted to the type of service before each project. The authors of the guide state themselves that describing the sequence achieves nothing on its own as long as responsibilities, decision rights, resources and methods are left undefined. The measured effect is real but small: in a study of more than 500 development projects, a formalized development process was positively associated with development performance, yet more weakly than the mere existence of a service development strategy, and all four factors together explained 14 percent of the variance. For heavily software-driven, iteratively built offerings, the more open three-stage layout of DIN SPEC 33453, which sets no fixed start and end point, fits better. And the method ends at market launch; running and improving the service in operation is not part of it.
How to measure impact
For each newly launched service, check whether the product model, the process model and the resource model existed in writing before roll-out, and alongside that track the time from idea approval to market launch and the revenue share of services launched in the past three years.
Related methods
Sources
- 1.Meiren & Barth: Service Engineering in Unternehmen umsetzen. Leitfaden für die Entwicklung von Dienstleistungen, Fraunhofer IRB Verlag, Stuttgart 2002 (ISBN 3-8167-6049-x) (opens in a new tab) · Fraunhofer-Institut für Arbeitswirtschaft und Organisation IAO / Fraunhofer IRB Verlag (Volltext über Fraunhofer Publica) · 2002 · investment, consulting and analyst firms, industry bodies and public agencies · describes the methodCarries the full method. The phase model comprises idea generation and appraisal, requirements analysis, service design, service implementation and market launch; from the constitutive definition of a service via potential, process and outcome, the guide derives resource model, process model and product model as design deliverables and adds a market dimension. The guide names its own limits: the rigidity of the sequential flow, the need to adapt it to the type of service, and unused opportunities to parallelize. Limit of the source: a practitioner guide from a publicly funded German research project, not evidence of effectiveness; the phase model itself follows the 1998 DIN technical report on service engineering.
- 2.Edvardsson, Meiren, Schäfer & Witell: Having a strategy for new service development, does it really matter?, Journal of Service Management 24(1), 25-44, 2013 (opens in a new tab) · Emerald / Journal of Service Management (Postprint über Linköping University Electronic Press) · 2013 · academic and scholarly literature · evidence of effectivenessTests the value of a formalized development process across more than 500 service development projects in Germany, Sweden and Switzerland. The association with development performance is positive and statistically meaningful (regression coefficient 0.14) but weaker than that of an existing service development strategy (0.24); all four factors together explain 14 percent of the variance. The managers surveyed rated formalization the least important of the four factors. Limit: a cross-sectional self-report survey, not causal evidence; the process construct was measured with two items.
- 3.Rechtien: Neue Dienstleistungen spezifizieren (zur DIN SPEC 33453 Entwicklung digitaler Dienstleistungssysteme), technische kommunikation 6/2019 (opens in a new tab) · technische kommunikation (tekom Deutschland) · 2019 · practitioner source · provides the contextPlaces the successor standard in context: DIN SPEC 33453, published in 2019 for digital service systems, describes a three-stage flow of analysis, design and implementation with no fixed start and end point, so that companies can enter wherever they stand. It was produced by consortia from the German federal funding initiative on service innovation through digitalization together with practitioners and academics. Limit: a trade article about the standard, not the standard text itself; it evidences the existence and basic layout of the newer procedure, not its effectiveness.
Origin: Fraunhofer IAO (Meiren/Barth)