B
y Debra Thomas, iSixSigma Contributing WriterOften times it almost seems as if the people who run a business and the people developing and implementing the information technology (IT) systems for the business do not speak the same language. So it was with a project team that had developed a high-level, future-state process map for a renewal process in the insurance industry. The business people on the team needed to identify, document and convey the business needs to the IT group that was responsible for developing the automated workflow system for the new process.
The team, composed of business and IT people, discussed the high-level business needs, the kind of information needed by the IT group to develop the appropriate solution, and how best to gather and document those requirements. Several models/tools to gather requirements were described, which sounded very much like the information required in a SIPOC (suppliers, inputs, process, outputs, customers) diagram.
The SIPOC diagram is a tool that is typically used in the Define phase of a Six Sigma DMAIC project to identify process outputs and the customers receiving those outputs. Once the customers are identified, voice-of-the-customer data can be collected and customer requirements can be defined. The SIPOC diagram also helps scope the project, provides a high-level view of the workflow and helps ensure that all team members are seeing the project the same way.
SIPOC Helps Communications
It was apparent that by putting a bit of a twist to the standard SIPOC diagram, the business team could document the high-level business requirements in a language they understood, and also provide the high-level business requirement information needed by the IT group to begin work to develop and automate electronic workflow for the new process.
Figure 1 shows the high-level process map for the renewal process in this case study.
| Figure 1: Insurance Renewal High-Level, Future-State Process Map |
|  |
|
|
A typical SIPOC diagram (Figure 2) was created for the high-level insurance renewal process. To define the high-level business requirements, the elements captured in a typical SIPOC diagram were placed as headings in each of five columns.
| Figure 2: SIPOC Diagram for High-Level Insurance Renewal |
|  |
|
|
Each process step in the high-level process map was decomposed or broken down into a little more detail, although still high level. For example, Step 1: Initialize Renewal Process, in the high-level, future-state map was broken down into five more discrete activities, specifically:
- Initialize Renewal
- Review Accounts Renewing
- Formulate Renewal
- Review/Assign Account Executive
- Review/Assign Underwriter
These more detailed process steps were then listed from the first step to the last step in the column labeled "Process." In this example, only a small portion of the project (five activities) are presented and described. In the original study, there were a total of 39 activities listed under the five original high-level steps of the renew insurance coverage process.
The team identified and documented the suppliers, inputs, outputs and customers for the first activity, and then did the same for the next four activities, until all five activities in Step 1 were complete. Team members seemed to find it easier to first identify the items that were the outputs of the activity, followed by the customers of those outputs, then the inputs required by the activity, and finally the suppliers of each of the inputs.
Questions Asked to Complete SIPOC
The following questions were repeatedly asked by the team as it worked through each of the activity boxes in order to fill in the high-level business requirements:
- Outputs: What information, data, report, eligibility status, etc., comes out of this activity or is produced as a result of this activity?
- Customers: Who or what receives whatever it is that comes out of this activity?
- Inputs: What data, supplies, system, tools, etc., are required for this activity, or who is needed to perform the action?
- Suppliers: Who or what functional organization, system, report, database, etc., supplies or provides whatever it is that is needed as an input to this activity?
Table 1 shows the high-level business requirements that were defined for Step 1: Initialize Renewal Process. The team worked in a similar manner to identify the high-level business requirements for each of the 39 activities in all five of the original process steps. For this case study, various company specifics were coded and otherwise protected to ensure confidentiality.
Table 1: High-Level Business Requirements for Initialize Renewal Process |
Suppliers | Inputs | Process | Outputs | Customers |
(Identified
Fourth) | (Identified
Third) | | (Identified
First) | (Identified
Second) |
| Step 1: Initialize Renewal Process |
> Actuarial
> Reporting Database
> System A
> System D
> System E
> System F
> System F1
> System B
> Sales
> PRE
> TS | > Renewal/Anniversary Date
> Current Rates
> Current Plan Design
> Membership
> Census
> Claims Info
> Policy Type Codes
> Market Segment Indicator
| Initialize
Renewal | > Entry into Workflow
> List of Monthly Renewals
> Non-Conformance Daily/Report
> Cycle Time Data/Report
| > Underwriting |
> PRE
> SRE | > Rating | Review
Accounts
Renewing | > List of Rated Renewals w/Initial Status
> Non-Conformance Daily/Report
> Cycle Time Data/Report | > Underwriting |
> System A
> Data Repository
> System G
> System F1
> System C
> TS
> PRE
> SRE | > SRE Inputs
> System C
> Current Rates
> Prior Manuals
> Coverage
> Customer ID
> Medicare Primary Indicators GL
> Group ID
> Section ID
> Association Number
> Association Type
> Prior Effective Date
> Rate Effective Date
> Original Effective Date
> Plan IDs
> TEFRA Indicator
> Protected Class Indicator
> SIC Code
> Current Commission Amount
> Capitation (Historical/Prospective)
> Duration
> Experience Period | Formulate
Renewal | > Formula Renewal
> Non-Conformance Daily/Report
> Cycle Time Data/Report | > Underwriting |
| > System A | > Manager Decision | Review/Assign
Account
Executive | > Updated Group/Acct. Executive
> Assigned Acct. Executive
> Non-Conformance Daily/Report
> Cycle Time Data/Report | > Marketing
> Sales
> Client Services |
> System A
> Data Repository
> PRE | > Last Year's Underwriter Assignments
> Business Rules | Review/Assign
Underwriter | > Assigned Underwriter
> Updated List of Underwriter Assignments
> Non-Conformance Daily/Report
> Cycle Time Data/Report | > Underwriting |
This was a win from both the business and the IT perspectives on the project. The business team identified the high-level business requirements in terms they understood, while at the same time, the information defined was what the IT team needed in order to do its development work. There were fewer problems from misunderstandings because the project team was working in a language that made sense to the business people and that met the needs of the IT people.
About the Author: Debra Thomas works for a major health insurer on implementation of an enterprise-wide process improvement initiative. She is a certified Master Black Belt and earned her Six Sigma Black Belt while working at Motorola. She has worked for Johnson & Johnson, Motorola, Tellabs and a homebuilding/construction company where she held roles in quality engineering/quality management, business quality, customer quality, strategic quality and Six Sigma initiatives. Ms. Thomas has used Six Sigma tools and methodologies in manufacturing, engineering, construction and transactional environments. She can be reached at dthomasjob@hotmail.com.
