Desktop   |  Next Public Course  |  Contact
Home  > Resources > Free Newsletter ... Subscribe

Service QFD and State-Transition Diagram

"How can QFD be used in companies providing a service rather than a product?"

"Can QFD be applied to non-manufacturing?"

"Is QFD relevant to the non-tangibles?"

We sometimes receive these questions, usually from countries who are new to QFD and modern NPD. It appears that in some parts of the world QFD is still perceived to be for manufacturing only, even though numerous case studies have been published on QFD in service.

History of Service QFD

Early applications of QFD in service organizations date back to around 1981, when Ohfuji, Noda, and Ogino applied it to a shopping mall, sport complex, and a retail store [Akao, 1990]. In 1990, 1991, and 1992, Kaneko reported examples of QFD integration with reliability and TQM quality circle activities in Japanese hotels, shopping centers, and hospitals.

In the U.S., service application QFD emerged around 1985 [Mazur, 1993]. This and better understanding of QFD spurred further experimentations that resulted in scores of non-traditional applications and innovative integrations in the US that had not been reported elsewhere. The QFD Institute Proceedings page shows many of these examples.

So, to answer the above questions, yes, QFD can and has been successfully used in both tangible and non-tangible applications for a quarter of a century.

Complexities of Service Process

Then, what should one be aware of when applying QFD to service?

"Service processes present unique challenges. They are complex because both the provider and customer are interacting and reacting to each other at the same moment, and thus each transaction is in itself a new 'product.' Services also contain both usability and emotional components," says Glenn Mazur, executive director of QFD Institute:

"When we plan a service or process, we tend to look at things in terms of what the provider must do to complete the service process. We tend to think in a logic that is provider-oriented.The result is a process that is inconvenient and frustrating to the customers, a service transaction that failed to complete, and defection of once willing customers."

Example of Provider-oriented Service

For example, recently one of our staff was interested in attending an international conference overseas, but he could not register because the registration form required detailed travel information that he did not have at the time. When he finally sent a registration with credit card payment, the conference failed to acknowledge it for weeks until we questioned them.

It turned out, the conference planners were going to process credit card payments in a batch, waiting until two weeks before the conference date, and they would issue a confirmation and receipt at that time. They wanted to streamline obtaining all information at once, such as people's program choice and travel information, and they thought thought it would be more efficient to process applications in a single batch rather than individually as they arrived. This providers' logic, however, ignores the service customer reality. We told them this was not acceptable and why.

First, conference attendees do not necessarily have travel details at the time when they decided to register. Travel arrangements are often made later, so information such as flight number, arrival time, and hotel check-in and check-out dates are not available yet.

Second, issuing an acknowledgement within a reasonable time when someone sends a registration or payment is a minimally expected basic quality nowadays in any service, any country and any business. No acknowledgement caused the customer unnecessary concern as well as doubt about the conference competency. Granted this is an overseas conference requiring expensive international travel, the employer of the attendee may require a proof of registration before he/she is allowed to make travel arrangements.

This type of service process design error is rather common. At any point during the process, it could have resulted in a purchase postponement, incomplete transaction, or cancelled transaction, all of which would be a loss of business and defection of a customer.

Understand the Complexities through State-Transition Diagrams (STD)

How can we better understand service processes? Mazur suggests a cognitive understanding of the customer through QFD and related tools. At the 1995 Symposium, he described an example of using State-Transition Diagram (STD) in order to better understand complexities of a service process, instead of using the standard service flow chart.

STD is one of several powerful software engineering tools that grew out of a need to better understand the often poorly articulated needs of the customer by looking at things from his/her eyes. STD is valuable for certain types of complex logic where multiple transitions among states can occur [Martin].

An STD for a process of "turning on a light" contains these items:

  1. the current state 'light off';
  2. the desired state 'light on';
  3. an arrow showing the transition from off to on
  4. the event triggering the change of state 'switch on'; and
  5. the process that then takes place when the event occurs 'flow electrons'.

image of State-Transition Diagram : Switch On/Off

An event 'switch on' causes a process 'flow electrons' which changes the state from 'light off' to 'light on'.
State-Transition Diagram.

Look for Customer Needs through Each Transition

A service can be viewed as a series of sequential and parallel tasks that achieve a certain purpose of function. Service transactions can also be viewed as different states that a customer passes through on his/her way to a satisfying experience of the service. In other words, a service process is a series of states involving the decision making process and experiences of the customers [Mazur 1993c].

click to view a Cafeteria Service STD exampleFor example, a cafeteria service may contain such states as 'decide where to eat,' 'decide what to eat,' 'pay for food,' 'put food at table,' 'complete meal,' etc. Between any two states is a transition triggered by the customer's decision making and action.

At each transition, we can examine the decision or event that triggers the transition to look for customer needs. We can identify potential failures of the transition and look for opportunities to save a transaction. We can also identify events and tasks that would help move the customer through the transition of the states toward the final state where the customer walks out satisfied and the transaction completes.

Top   |   Training   |   Resources   

© QFD Institute / Glenn Mazur  


Public Courses