Developing the project plan, which is the next step in the definition phase, is frequently the easiest for IT staff because Six Sigma plans are no different from the project plans that IT professionals are used to creating. Like all project plans, the one the team developed included milestones, deliverables, and dependencies. To provide a clear linkage back to the process model, the team used the five phases of DMAIC as summary tasks, and broke down individual steps within them. This use of shared terminology helped non-IT staff understand the project plan.
Customers and Their Requirements
The final steps in the definition phase are to identify customers, their requirements, and the relative priority of those requirements. The objectives of these steps are to ensure that the project is addressing the right problem and to align project deliverables with customer expectations.
When identifying customers, the team realized that there were two different groups.
The ultimate customer was the employee whose records were to be changed (e.g., the VP of Marketing). Although it was critical to satisfy those customers, it was equally important to address the needs of intermediate customers such as the vice-president’
s assistant, who actually filled out the forms. Both use the services delivered by the payroll/HR system and the keypunch department. While their requirements are similar, the team discovered some important differences in their perspectives.
Similar to the creation of a project plan, identifying customer requirements is a task with which most IT departments are comfortable. Virtually every IT project has as one of its preliminary tasks the definition of requirements. Within Six Sigma organizations, however, this process includes additional steps that may not be part of the traditional requirements definition phase.
Obtaining customer requirements can be accomplished in a number of ways, including interviews, surveys, and reviews of complaint logs. The XYZ team chose interviews because it had a limited number of customers, could afford the time, and believed it would get more information by encouraging open-ended answers rather than asking customers to choose from a menu of predefined responses.
When the team conducted its requirements definition, it discovered that in addition to the processing time and accuracy requirements it had expected, customers identified other requirements, notably the time required for them to complete the input form and the desire for confirmation of system updates. Similarly, while they were interviewing customers, the team members learned that many were frustrated
by the need to enter what seemed like arcane system codes, such as a “1” for “full-time employee” or “9” for “retired.” Although these codes and their translations were listed on the input form, their use frustrated the customer. This discovery of new requirements is common and is one of the primary reasons for the requirements definition step.
Where the XYZ team’
s process initially differed from standard requirements definition was the application of SMART criteria to ensure that the requirements were specific.
This was a fairly rigid process that resulted in each requirement being carefully scrutinized and rewritten to ensure that all possible ambiguities were removed. As shown on Exhibit 3, rather than phrasing the first requirement as “Requesting the change must be easy,” the team worked with the customers to clarify “easy.”
When the team had completed the definition of requirements, it asked the customers to give each requirement an importance ranking. The customers understood that this ranking would be used in subsequent steps to ensure that the proposed solution addressed the most critical problems. As shown in Exhibit 3, the team established an importance ranking scale of 1 to 10 but used only four values: 1, 4, 7, and 10. The reason for this was to simplify customer decision making and to make final rankings more definitive.
Exhibit 3. Sample Customer Requirements
Customer: VP of Marketing
Output: Updated Payroll/HR Records
Requirement
Importance
(1, 4, 7,
10)a
Completing input form requires no more than one minute
1
Completing input form does not require the customer to use any 4
system codes
Updates are applied to system the day form is completed
7
Updates are correct the first time
10
Customer receives confirmation that updates have been applied within 7
eight working hours of the system update
Customer: Assistant to VP of Marketing
Output: Updated Payroll/HR Records
Requirement
Importance
(1, 4, 7,
10)a
Completing input form requires no more than one minute
10
Completing input form does not require the customer to use any 7
system codes
Updates are applied to system the day form is completed
4
Updates are correct the first time
7
Customer receives confirmation that updates have been applied within 4
eight working hours of the system update
a Importance scale: 1 = Unimportant; 4 = Moderately important; 7 = Very important; 10 = Mandatory.
THE MEASUREMENT PHASE
As noted above, the purpose of the measurement phase is to validate and quantify the problem statement by identifying and measuring the various steps in the current process. The XYZ team began by constructing a SIPOC chart. SIPOC is another Six Sigma acronym, this one for Supplier, Input, Process, Output, and Customer. Its purpose is to provide a high-level understanding of the problem and process. For this project, the SIPOC elements were as shown in Exhibit 4.
Exhibit 4. SIPOC Elements
Category
Supplier
Employee needing HR/payroll records updated; assistant to employee Input
HR/payroll system update form
Process
Keying of data; system update
Output
Updated records
Customer
Employee needing HR/payroll records updated
When the team completed its SIPOC, it noted that the supplier and the customer were, in many cases, the same. Although this is not typical for most processes, it was a key point for this project and was instrumental in determining the proposed solution.
Once the team had developed a SIPOC chart, it expanded the “process” section into a separate process map. As shown in Exhibit 5, the process map outlines the prima ry steps in the current process. The team confirmed these steps with customers and measured the elapsed time between steps. Because there were a number of “hand-off” steps, including the mailing of forms to keypunch, the elapsed time from first obtaining the form to updating the records could be as long as one week. The team knew it could — and would — improve that.
Exhibit 5. Current Process Map
THE ANALYSIS PHASE
With measurement complete, the team began to analyze the data it had gathered. In doing so, it determined that the root cause of the problem was the inherent design of the process with its hand-offs. Although the fact that keypunch was measured by the number of transactions it processed rather than by the number of transactions it processed accurately was identified as a secondary problem, the team believed that resolving that problem would result in only a marginal improvement in customer satisfaction and reduced processing time. The primary opportunity for improvement was in streamlining the process.
TIME FOR IMPROVEMENT
The team then moved into the improvement phase, where it brainstormed a number of solutions. The first solution to be considered was the imaging front end that the VP of Marketing had proposed. Although the team recognized that an imaging front end would address the first portion of its goal statement (ensuring that 99 percent of all updates are processed the same day they are received), it did not believe that this solution would improve customer satisfaction or accuracy.
Ultimately, the team determined that an intranet-based employee self- service approach would have the greatest chance of satisfying customer requirements. The team based its recommendation on the following facts:
§ The supplier of input and the customer were frequently the same person.
§ Virtually everyone in the company had easy access to a workstation and was computer literate.
§ Employees were already accessing the intranet to obtain the blank input forms.
§ Keying data would take most employees less time than completing and mailing a paper form.
§ Employees had a vested interest in data accuracy and would be less likely to make errors than keypunch.
The next step was to validate the proposed solution. This process consisted of two major steps: developing a revised process map (Exhibit 6) and ranking the proposed process improvements’
effect on customer requirements.
Exhibit 6. Proposed Process Map
The team constructed a process improvement ranking spreadsheet to provide an objective, clearly quantified measurement of the effect each step would have (Exhibit 7). The team’s first action was to take the requirements customers had identified without the importance ranking they had assigned and determine how well each proposed improvement would satisfy that requirement. To create clear distinctions, the team used the same 1, 4, 7, 10 scale that customers had used for their importance ranking. As shown in Exhibit 7, an online front end would have a high impact on the requirement to enter data in less than one minute, but would not significantly affect the requirement to eliminate system codes.
Exhibit 7. Process Improvement Ranking
Improvement
Steps and Effects
Replace
Use pull
Provide
keypunch
down