Tales of a BA: Framing processes with the SIPOC diagram

Being a Business Analyst on a new project can be daunting, and it’s even harder when you’re new in the organization too! In this situation, one of the best techniques to quickly frame a business process and the context around a new project is the SIPOC diagram. In this first episode of Tales of a BA, we’ll see how William, our newly hired BA at Universal Gizmos, uses it to get a better understanding of his new project, in his new organization.

You’ll need a good 10 minutes to read this article and get the most value of it.  If you don’t have enough time in front of you, email yourself a reminder!

A new day at Universal Gizmos Inc.

Today is the first day of Wiliam Anderson at the head office of Universal Gizmos (UG), an international organization operating on 3 continents and selling a large portfolio of gizmo solutions to its customers.  William was hired as a Business Analyst in the UG’s Business Solutions Center of Excellence.

William didn’t know a lot about the organization before getting hired, but he hopefully found interesting information about UG in the latest annual report available on the company’s website. He previously worked as a Business Systems Analyst in a large manufacturing company, so he has some business knowledge that could help him to integrate his new role.

He was given his first project assignment quickly but didn’t get so much information about it. William’s director told him that Simon Jackman, UG’s Human Capital VP, was pushing really hard to solve a major problem in the new hire onboarding process: the major delays in the process were making new employees inefficient and were giving them a bad first impression of UG.  William was one of the lucky new hires that got all he needs on his first day, but most employees are waiting for as long as one week to be up and running (while the company goal is to have no delay at all!)

The various subprocesses of the new hire onboarding process were already being analyzed by William’s new colleagues.  William was tasked to work on the access rights management subprocess required by new employees (to get things such as access cards, systems logins, etc.)

Johan, another BA in William’s team, guided him on some preliminary work done on this process in the past for another initiative. William decided to start with the partial SIPOC diagram that was produced at this time to prepare his first workshop with Simon and get a better grip on the access rights management process.

The SIPOC Diagram in a nutshell

Why use the SIPOC diagram?

The SIPOC diagram is one of the BABoK proposed methods to support the Process Analysis technique. It’s a simple yet powerful table that summarizes the boundaries of a business process. It’s quick to build compared to process diagrams but doesn’t provide much information about what’s going on inside the process.

Its simplicity also makes it a good starting point for almost anyone in an organization, since it doesn’t require a specific notation knowledge to be understood.

It’s very helpful when starting a new project since it defines what should be included in the scope and what should stay outside of it, based on business processes, not on underlying systems.  You can use the SIPOC diagram as a tool to capture and structure critical information in the early phases of a project, as well as a key document to help stakeholders to focus on a given scope until the delivery of a project.

Looking for more information? Check this and this. You can also take a look at the Process Analysis technique in the BABoK (section 10.34).

What’s in a SIPOC diagram?

From its name, you can easily guess the basic elements that can be found in the SIPOC diagram.

Suppliers & Inputs

Every process is triggered by one or many inputs, coming from one to many suppliers (with the notable exception of time-based inputs, like the first day of the month, or every hour).  Identifying these inputs draws a clear line of where your process begins, and of what activities are inside and outside the processes under study.

Processes

This part of the diagram is used to highlight the main steps of the processes you’re looking at.  The key point here is to go to a level of details where you can see a sequence of high-level tasks, but not each steps to complete the tasks nor the exceptions in the process.  As a rule of thumb, you could find 5 to 7 high-level steps in this section.

A thing not to forget when identifying activities in this section is to think about the various subprocesses.  For example, if you’re looking at a “Create order” process, you would probably have to look at its variations such as “Modify order” or “Cancel order” since they probably share common steps and common problems.

Outputs & Customers

If processes do not always start with input, they will at least deliver one output to a customer.  Otherwise, why are you performing all the tasks described earlier?  As suppliers & inputs define some boundaries of your processes, the outputs & customers will also contribute to defining these limits.

---

These elements are the basic components of the SIPOC diagram.  However, I like to add some additional information to it to provide more context around the processes being analyzed.

Process Owner

If you can find a clear, identifiable, accountable owner for your process, stop whatever you’re doing right now and go buy a lotto ticket.  The process owner is the real human person (not the department, nor the committee) who can take and enforce decisions regarding how the process can be conducted.  He’s invaluable when you need to manage stakeholders or when you face challenges.  He (or she!) is also very hard to find 🙂

Interactions in the value chain

A process does not live on its own in an organization; it interacts continuously with other processes to deliver value to the whole organization.  Therefore, you can’t analyze a process without looking at how it interacts with the others.

I like to distinguish relationships (hard dependencies) from (interfaces) soft dependencies. The first type implies that process X must be completed or have reached step Y before our process can start. For example, you can’t start the packaging process before the manufacturing process is done.  The latter does not wait for other processes but uses data produced by them.  For example, the generation of monthly reports for the board uses information from the sales, manufacturing and HR processes, but doesn’t need them to be “completed” before it can be started.

Process Objectives

Having a problem can be a synonym of failing to reach an objective; otherwise, why would you have a problem?  However, this objective is not always clearly stated, which can lead to misinterpretations down the road. I usually add the process objectives to the SIPOC diagram to define more clearly the process being documented, since when stakeholders can’t agree on common objectives, it’s usually a sign that the process is not well understood.

How to fill the SIPOC diagram?

I like to use the SIPOC diagram to structure the information you can gather from different sources (like written documentation, interviews, etc.) at the beginning of a project.  Since it’s a very simple diagram, it’s also easy to work collaboratively with stakeholders to define its content.

The best way to start filling a SIPOC diagram is to start with the high-level steps of a process (since these are often the most known part of the diagram), and then fill the other elements as they are discovered.

Once completed, the diagram will become your reference to define your project scope. This doesn’t mean that it can’t evolve over time as you discover new information, but updates to the SIPOC diagram must be done with a shared agreement among stakeholders (and your process owner!)

The SIPOC diagram in action at Universal Gizmos

Using the various pieces of information provided by his colleague Johann, William was able to prepare a partial SIPOC diagram that he used in his first workshop with Simon, the Human Capital VP.  He also invited Martin Smith, the Corporate Security Director, as well as Mary Temple, the Real Estate Operations Director, who are both involved closely in the access rights management process.

William didn’t know a lot about the processes.  He knew that the employee initiated the request on the corporate intranet, request that was reviewed then approved before being processed.  The processing of the request was different depending on the type of access required, and some of these types were requiring actions from external partners (such as the real estate manager in some offices). Moreover, this process was a sensible once, since it was interrelated with many other processes such as the new hire onboarding process. This led him to create the first version of a SIPOC diagram.

During the workshop, William used the SIPOC diagram to share his knowledge of the process so far, which initiated some interesting discussions on its various dimensions. William was able to fill in the blanks after the workshop based on the conversations they had had.  Simon, Martin, and Mary had no difficulty to review the diagram after the meeting, and everyone agreed on its content.

William was all set up for his next mission 🙂

Get the exclusive SIPOC diagram prepared by William!

Learning Business Analysis is all about applying concepts to real-life situations. With the Tales of a BA series, you have the unique opportunity to get not only reusable templates but also real deliverables prepared by William as he works his way through various projects at Universal Gizmos.

In the next episode of Tales of a BA

While gathering information about the business processes he has to study, William also captured important data about other dimensions of his project.  In the next episode of Tales of a BA, we’ll see how William can use stakeholders analysis to get a better understanding of the organization and improve his interventions with the various stakeholders he’ll meet on his journey.