How to Analyze a “To Be” Business Process

Have you been asked to create a “to be” process? Are you wondering what the difference is between “as is” or “to be” process documentation? Wondering if you need both or just one of these types of business processes on your project?

In this article, we’ll define what a “to be” business process is, how to analyze a “to be” business process, and then discuss when it’s an appropriate form of requirements documentation.

(In a companion article, we do the same for “as is” business processes.)

Definition of a “To Be” Business Process

A “to be” business process defines the future state of a business process in an organization. Typically the analysis goal in putting together the future state process is to clarify how the business process will work, at some point in the future, once changes are made. Those changes, as we’ll see, could be technology changes or business process changes.

How to Analyze a “To Be” Business Process

A “to be” business process contains all of the sections in a typical business process model – a description, list of roles, list of steps and exceptions, etc.

(By the way, we address business process analysis techniques in detail in ourBusiness Process Analysis virtual course.)

“To be” business process documentation rarely exists in isolation, nor is it conducted as a stand-alone activity. It is typically one deliverable on the path to creating change within your organization, which means it exists as part of a project.

Since a “to be” process is completed as part of a project, you’ll want to lead a team of stakeholders through the entire business analysis process – starting with getting oriented (perhaps by analyzing or reviewing the “as is” business process documentation, continuing with defining business objectives and scoping the change, and with creating your business analysis plan (particularly important if there is more than one inter-related process to document) and then creating your “to be” process documentation.

These steps might seem overwhelming, but they can be completed relatively quickly to implement a small improvement – perhaps even within one or two very focused meetings. On the other hand, they may happen over the course of several weeks or months for a large scale business process improvement effort that involves supporting technology changes.

When “To Be” Business Process Analysis Is Appropriate

Here are some scenarios when working towards a “to be” or future state business process documentation is appropriate:

• You are working on a project that impacts the business process.
• You are working with a team of stakeholders or subject matter experts toimprove a business process.
• During the roll out of a new technology change, interim business processes are needed to handle special case scenarios, such as active work items received before the change.
• Your technology team has just introduced a new piece of software and the business users don’t know how to use it.
• Your organization is deploying a new product or service and requires one or more new business processes to sell, deliver, and/or implement the service.

In short, if your project creates change, consider creating one or more “to be” business processes to clarify what the change means to the members of the business community. The clarity you create will help the business users embrace the change more fully, enabling your team to create a positive impact within your organization.

SOURCE:  bridging-the-gap.com