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.

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.

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.

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

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?

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. 

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.