When should I use process modeling?

I'm trying to capture the requirements of a business process by doing interviews, but I think I'm missing some details. I've heard of process modeling as another way to capture details. How and when would I use process modeling as part of my requirements capture work?
Process modeling is a great tool at several points in the requirements lifecycle. It can help you analyze and understand the business need, identify and analyze gaps, and represent the goal state in a concise, easy-to-read format.

First, a clarification: Process models are generally used to show the details within a process—they don't usually dwell on the wider context within which the process resides. A good process model shows the start and end points of a process, but doesn't provide a lot of detail outside the process. This focus can help a team understand and express what truly needs to change in a very concrete and detailed way.

Process modeling is particularly useful for quickly understanding the current state—how a process works now, before any changes are made. After all, if a project's goal is to change and improve a current business, it's critical to truly understand exactly how that process works now. If you have limited time but need to get an end-to-end picture of how things currently work, gathering the right subject matter experts and putting together an "as-is" process model is a good strategy. Process modeling helps you and others arrive at a common understanding of who is involved in the current business process and what steps are required to complete it, and by extension, how it can be improved.

The same kind of process modeling can then be used to define how a process should work in the future—the "goal state." Given the improvements (such as efficiency or costs) that a project is intended to achieve, what elements of the current process could be changed, and how? Modeling both the as-is state and the goal or "to-be" state yields a very clear understanding of the gaps between current operation and desired operation, and what exactly will have to change to get there.

Process modeling is especially useful when a project is tackling changes to a large, complex area of the business. If you break the target business function into its component sub-functions and processes, you can apply process modeling to create consistent visuals of the various processes, identify their common start and end points, and communicate where the processes overlap. Getting a clear visual picture will help you organize and manage the requirements process for the project and ensure that all the areas of the complex process are addressed.

How to do Business Process Modeling: The most effective process models have two separate formats: a visual format like a flow chart, and an accompanying text description or narrative. Including both formats acknowledges and accommodates the fact that not everyone processes information the same way. Leave room in your model to add notes—for example, clarifying questions that you want to ask the business subject matter experts, reminders of issues that need to be addressed or resolved, comments about inputs and outputs, and starting points for other processes that tie into the one at hand.

Start capturing the current As-Is or Current State process by defining the boundaries of the process—the initiation and completion steps. From there, define the sequence of tasks, decisions or questions, and products generated during execution of the process. This sequence is usually captured as a process flow chart with accompanying explanatory text that elaborates on the diagram.

Once you've got a draft, review it with those involved in the process and with associated stakeholders. They will help to refine the detail and provide insight into hidden issues. When you have a broad perspective and as complete an understanding of the process as possible, finalize the documents through a review with the primary project team and stakeholders. Your goal in this review should be to get agreement that the model reflects the current process well enough to provide a solid baseline for future analyses.

Defining the To-Be or Future State processes follows a similar approach. However, the challenge here will be to accurately capture the input from each process stakeholder, as this will be more like gathering requirements than documenting an existing activity. One helpful approach is to use a simplified version of the As-Is / Current State process flow as a starting point, and allow the process participants and stakeholders you interview to mark it up to reflect their vision of the recommended process changes.

©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy

Get Our Newsletter
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues.

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
Learn more about ProjectConnections, our contributors, and our membership levels and product options.