iSixSigma

Identifying High-Level Requirements Using SIPOC Diagram

Often 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 (Define, Measure, Analyze, Improve, Control) 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.

Handpicked Content :   Preventing Conflicts Through Stakeholder Management

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

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

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: 

  1. Initialize renewal
  2. Review accounts renewing
  3. Formulate renewal
  4. Review/assign account executive
  5. Review/assign underwriter
Handpicked Content :   iSixSigma Publisher Katie Barry Introduces Redesigned Website

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. 

Handpicked Content :   Introducing the iSixSigma Editorial Advisory Board

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?

The table below 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. 

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 with 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/account executive
> Assigned account 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.

You Might Also Like

Comments 9

  1. Paul-M

    Excellent practical example expressed in very simple terms. Thank you

    0
  2. kimberley james

    this was very useful!

    0
  3. Max

    Very cool and informative, thanks.

    0
  4. Tomk

    Well presented. Great technique. Thanks!

    0
  5. Andy

    Short and straight to the point. Thanks

    0

Leave a Reply