Many a company has gotten caught up in the enthusiasm that comes with a great-sounding new idea. It is great when that idea turns into a profitable new product or service. But it can be a disaster when a lot time and money is invested only to end up with a dud. How great would it be to have the means to evaluate the feasibility of an idea before going too far down the road?

That is exactly the kind of decision-making capability that comes from using Design for Lean Six Sigma (DFLSS) to design products, services or processes. DFLSS is the subset of Lean Six Sigma tools that encompasses everything from going deep into customer needs, to defining design specifications for products and services, to evaluating alternative solutions.

It is that last capability – evaluating solutions – that proved invaluable for a major international banking company. Like all banks , it sometimes had to deny loan applications. Obviously the company would prefer to give more customers a “yes” answer because of the likelihood those customers will do more business with them in the future, but it would be fiscally irresponsible to accept applicants who did not meet the bank’s risk appetite.

The proposed solution: Find a way to partner with a subcontract provider willing to assume the greater risk so that the bank could tell more customers “yes.” Besides letting the bank increase customer retention, anticipated benefits included $6 million in increased revenue per year. But could the bank create a process that would offset the costs and ultimately be profitable? They turned to DFLSS techniques to answer that question.

Designing the Process

Though DFLSS has been used primarily for designing products, the basic tools are perfectly suited to process design as well. The beginning work in DFLSS is always the same – identifying functional requirements for what is being designed and defining specific performance targets for those requirements.

For example, the banking team knew going in that management had three performance criteria:

1. Providing a quick answer to denied applicants.
2. Achieving profitability right away (i.e., the costs would be offset by revenue).
3. Closing out the loan quickly.

The questions the team had to answer were: “What was a quick answer?” or “What was a quick close?” And, “What were the likely internal costs and payback to the bank?” (i.e., what the bank would have to charge for referrals to the third-party lender in order to be profitable). To get answers, the team interviewed key users of the proposed process – the people who would be involved in referring denied loan applicants to the third party, as well the third party staff involved in reviewing those applications. The final list of performance criteria included:

• Having confidence that customers understood the bank would be forwarding their application information to a third party (target value of 85 percent satisfaction with the “privacy disclosure” statement).
• Informing the customer of the initial denial within three days of receiving the application.
• Reviewing any denied loan within one day for potential referral to the new process.
• Establishing a five-day window for the subcontractor to get an offer to the customer.
• Closing the loan within 30 days of the initial application.
• Keeping the bank’s risk to a minimum.

With these target performance criteria in hand, the team then turned its attention to designing the actual process. They identified key tasks in the process (such as the initial review of the denied loan to determine if it should be referred) and discussed alternative ways to perform those tasks. They used a common DFLSS tool called a Pugh matrix to compare the alternatives and select the one that would best meet the performance criteria. A portion of the Pugh matrix used to compare alternatives for an early step in the process (revealing to customers the need to disclose information to a third party) is shown in the table below.

Pugh Matrix Used to Compare Alternatives for Performing Process Tasks
	Concept – Disclosure Delivery
Key Criteria	Manual Generation: Verbal Explanation	Manual Generation: Written Explanation	Auto- Generation: Verbal Explanation	Auto- Generation: Written Explanation	Importance Rating
Quick Decision	S	S	S	S	5
Quick Closing	S	S	S	S	4
Desired Product/ Pricing Delivered	+	+	+	+	4
Professional Treatment	+	–	+	–	3
Minimal Documentation	+	+	+	+	3
Minimal Bank Risk	–	+	–	+	3
Cost/Difficult of Implementation	S	S	–	–	3
Sum of Positives	3	3	3	3
Sum of Negatives	1	1	2	2
Sum of Sames	3	3	2	2
Weighted Sum of Positives	10	10	10	10
Weighted Sum of Negatives	3	3	6	6

In the end, the team sketched out a proposed 20-step process – which included several contingency paths– with well-defined requirements and performance targets.

DFLSS Simulations to the Rescue

Having the completed DFLSS analysis to draw from, the team could define a lot of the likely attributes of the process, such as cycle time, queues, staff time required for processing the loans, and more. The team initially defined two scenarios it wanted to test:

1. Fixed Resources: Seeing how many loans per hour could be handled, assuming that current staffing levels were maintained.
2. Target Volume: Determining what staffing levels would be needed if they could reach 60,000 denied loan referrals per year.

The team created a software simulation model of the new process flow, using the estimated task times, resource levels, and other constraints. With the proposed process complete, the team first tested Scenario 1, running the data three months into the future. As it turned out, the team never got around to testing Scenario 2 because the results from Scenario 1 showed that this process could never be profitable under current conditions: Staffing would be stretched beyond capacity even if there were only three loan referrals per hour (the equivalent of about 5,400 referrals per year). The predictions showed that process performance would be uniformly abysmal, never reaching above a one sigma level (about 30-percent yield) for any of the key steps in the process.

The economics of that level of capability were simply unfavorable, so bank management decided to abandon this effort. (Fortunately for the team, its hard work and competent analysis were still recognized and the project results certified so the members all got credit for their participation.)

Conclusion: When a Failure Is Success

Design techniques like simulations are common when people want to test new products, but are not applied as often in process design situations. As the banking company discovered, however, DFLSS allows process parameters to be defined so specifically, that a new idea can be tested with simulations.

Though this project was a failure in the sense that the bank did not get a new line of business, bank management was pleased with the outcome because it prevented them from investing heavily in a process that would ultimately prove unprofitable. Best of all, the bank knows exactly what kind of economic conditions might change the equation, so if the market shifts, it can quickly put the referral process in place.