Build Your BRM Toolkit With Business Process Models
Sitting at the intersection of providers and business partners, a business relationship manager’s job is to stimulate, surface, and shape demand—thus contributing to and representing the strategy for both functions.
Unfortunately, the day-to-day job probably feels far from this definition of a BRM. If a large part of your job is listening to your business partners prescribe what they want, chasing down operational issues, or trying to figure out how a project went off the rails, you’re not alone in your frustration.
Although the journey to creating a strategic capability roadmap and earning the position of strategic partner can be a long one, it’s worth it. One of the most effective and practical tools to mature business relationships and support demand shaping is business process modeling.
Business Process Modeling
Before discussing how the use of business process models can benefit the BRM role, it’s important to take a deeper look at the terms “process” and “process model.” First, some basic definitions:
- A process answers the question of what the business does. It can be accomplished in many ways, but always has a beginning and end with defined inputs and outputs. A process can decompose into sub-processes.
- A procedure illustrates how something (e.g., the process) is accomplished, describing the specific steps required for the outcome in detail. While many individuals consider this the definition of a process, it’s important to make this distinction to remove ambiguity. Process models illustrate processes, and flowcharts illustrate procedures.
Think of it this way: the process of you driving to work can be accomplished many ways, but it always starts with you at home and ends with you at work, regardless of the many potential paths. A process is the map showing you the different routes you can take between the beginning and end, while the procedure is the turn-by-turn instructions of a specific route.
Another important distinction is process vs. capability. Both share the interrogative “what” but operate at different levels. A capability is the expression of what an organization needs in order to perform core functions.
It sits in the business conceptual layer; above a process—so in our process of driving to work, a capability related to this could be the ability to drive.
In this context, process modeling is the defining and analyzing of the primary process or business scope and breaking it down to all relevant sub-processes. Therefore, the process model describing your drive to work might look something like this:
Image Source: Andrew Cornell
The process model is structured hierarchically, like a capability model. Each box answers the question, “What?” but at a practical, contextual level. Its intent is to capture and structure all relevant processes for a particular business process scope, but not the order or frequency in which they are executed.
In our example model, “Plan Route” and “Start Car” are two processes that make up “Prepare to Drive,” but their order of execution is irrelevant. In fact, if you have a car pool companion, they might occur simultaneously. Additionally, “Remove Snow from Vehicle” might be an important part of “Prepare to Drive,” but hopefully would be unnecessary for most of the year.
Remember, a process model is not a detailed diagram showing every step of what the business does. Procedure-level detail should be avoided, as it would become far too complex to support demand shaping and project initiation processes. Resist putting in too much detail—the general rule is no more than three to seven sub-processes per process.
The Value of Business Process Modeling
Process modeling provides several benefits to the BRM:
Captures Optimal Level of Detail
The process model creates an easy-to-understand, fluid model to illustrate business processes within a specific context. The process model can be used as a starting point for facilitating high-level conversations related to strategic capabilities or capturing additional details as part of the requirements phase of a systems development lifecycle (SDLC). It provides flexibility to add or change details as you proceed through an SLDC, without changing the overall outcomes or goals.
Provides a Means of Building Trust
People often love to talk about what they do, but are less amenable to a conversation about their capabilities. Building up to that conversation requires building trust with your business partners, and building trust requires taking a genuine interest in them. Through the process model, BRMs ask the simple but powerful question, “What do you do?” and must listen to the answer with intent.
Redirects Discussions from Tactical to Strategic
Often, business partners will begin conversations by being prescriptive with their needs. Taking the time to build a process model to frame the context of their requests changes the conversation from “What do you want me to do?” to “How does this fit into the strategy?”
Do that often enough, and soon the conversation will always start with strategy in mind.
Builds a Solid Base of Business Knowledge
Each process model becomes an easily referenced base of knowledge about that business function. It can be continually leveraged to allow others (business analysts, architects, etc.) to quickly understand the business function’s context. Because of its level of detail, the process model stays relevant for longer and is easy to maintain.
Further, process models can be linked and combined over time, providing even greater insight to the business’ overall functioning.
Helps Shape Demand and Rationalize Portfolios
Using a process model in your demand-shaping process will allow you to better understand how multiple demand items are related to a common process, helping to shape the “true” demand. In addition, by comparing the process models of different business functions, you can identify common processes that can be supported by common technologies or capabilities.
Process Model Success Stories
A Tale of Two Business Functions: Case Study 1
One of my first BRM roles was supporting operations at an energy company. My two most prominent business partners were the electric and gas delivery business functions. These business functions rarely worked together, operating instead as independent entities.
Soon after taking on the BRM role, the electric delivery business embarked upon a replacement project for a critical system used to manage electric outages. This system helped identify an electric outage, and then assisted in dispatching field personnel to restore power. The electric delivery “technical services team” (read: shadow IT) was busy focusing on working with the service manager in charge of monitoring the electric grid to gather project requirements. As the BRM, I convinced the technical services team to allow me to get involved with this process up front.
The first step was to frame the context of the project by using a business process model. Originally operating under the assumption that the process was about “managing electric outages,” many other sub-processes were soon identified. In fact, the system handled infinitely more turn-ons, turn-offs, disconnects, and reconnects than emergency power-restore activities.
This provided a whole new perspective on the project: it wasn’t a project about managing and responding to electric outages, but a project about managing all electric service delivery requests. Operating under the original, narrower assumption would have severely limited the scope and the success of the project.
Shortly after the electric project took off, I became involved with an effort within the gas delivery function to replace their aging (and unsupported) field force management system. The prevailing thought was that systems used by the electric business function would never work for the gas business function—the geographic footprints were different, the activities were different, the sizes of the business functions were different…gas was just different than electricity.
Despite this mindset, I took the same approach of building a process model, explaining to my gas business partners how we almost missed some key processes in the electric project.
After completing the process model for the gas project, I met with my business partners to see if they agreed that it accurately reflected their business—and they agreed that it did. I then revealed to them that with the exception of only a few processes, the process model was identical to the one we used for the electric project.
The vendor we used to support the electric business function’s needs easily accommodated the gas business, so the models were combined into one model, highlighting which processes were gas- or electric-specific. The electric and gas business functions were combined into one business function: Energy Delivery.
Process models facilitated their merge by analyzing demand from separate business functions, resulting in tremendous synergy for the company.
Moving Up the Maturity Model: Case Study 2
Helping to create a BRM practice from the ground-up typically places you near the bottom of the relationship maturity model. I found myself in this situation while working for a large retailer.
One of my business partners was the proprietary products division, responsible for producing, branding, and licensing private label products for sale in the company’s retail locations. I was called into a meeting with the vice president and several of his direct reports to discuss the need for a tool to help track and report their ideas for new products. They already possessed a customized SharePoint site (created by shadow IT) intended to facilitate their product lifecycle.
However, the adoption of this application was extremely low. In fact, it was barely used because it was considered too rigid. Nonetheless, I was told that if IT could simply copy this application, add some data fields, and create a new view, that’s all they would need—quite simple and convenient.
Just like too much convenience food can hurt your health, too much convenience IT can hurt your business’ success.
There was more to the story. What was driving the discussion in the first place was the increased emphasis on product innovation across the company. Because of the tremendous success experienced by the proprietary products division, the vice president was asked to oversee innovation in other divisions, where other specialty products were being developed in isolation.
The actual pain point was how to measure and report innovation at the company and how to make it more effective. In order to accomplish this, then, I first needed to gain an understanding of what product innovation was at the company.
After communicating my need to understand the processes context surrounding product innovation before modifying any system, I received a few funny looks. At a minor impasse, we agreed that I should set up a few meetings with the immediate stakeholders to discuss their “requirements.”
I began meeting with the various stakeholders in the department. While the conversations naturally evolved towards the details of what they wanted, it gave me the opportunity to ask questions about what they did in their areas and why, as well as what they thought a good innovation process should include.
My intent, of course, was to document it all in a process model. In one of my last “requirements” meetings, I found out about another meeting being hosted by the vice president on the topic of innovation—to which I was not invited.
So I invited myself. Sometimes it’s what you have to do.
Only after I gently suggested I could learn something that could help with the IT aspects of the project was I allowed joining. During the meeting, much of the discussion centered around what needed to be done; often diving down into the details of the data that should be captured to help the process.
During a pause in the conversation, I asked if I could present something I was working on and handed out copies of the process model. I explained how the process model could be used to standardize the company’s processes around innovation, but was also useful to IT as the basis for requirements, architecture, and design.
I paused.
The room was silent as the vice president studied the process model. Finally, he looked up.
“This is exactly what we need.”
My relationship to the business partner strengthened that day—no longer did I have to “invite myself” to meetings.
Andrew Cornell is a business management professional with more than 20 years of experience in IT, spent primarily in process analysis and relationship management roles across multiple business functions. His passion for converging technology with business objectives led him to implement BRM functions at two separate billion+ dollar companies. Andrew holds a degree in Industrial and Systems Engineering from Ohio State University and an MBA from University of Dayton. He lives in Colorado, where he enjoys sharing his love of the mountains with his wife and four children.
Andrew,
Great article, hits very close to home. Could you tell me what app you used to create the Drive to Work hierarchal diagram?
Thank you,
Kendall Finnigsmier, BRMP
Newmont Mining Corp.
Thanks, Kendall.
I use MS Visio Professional (must be Pro version), taking advantage of it’s data graphics functionality and linking an excel spreadsheet with all the process data in it.
There are some expensive enterprise architecture tools out there, but the cost + complexity can be less than ideal for the purpose.
Using Visio can be a bit cumbersome to start, but once you have some basic data graphic templates completed, its rather straightforward and effective.
Andrew,
This was an extremely insightful article that really simplified a sometimes confusing process. Incorporating the templates really helped to tie everything together for me. I’m now inspired to dig into my Visio Pro and set up some templates.
Great job and thank you for your commitment to excellence.
Jeff
Thank you for the kind comments, Jeff.
If you are a member of the BRM institute, I have started a blog post in the BRM tools section. I’m sure the templates I use can be made available to BRM Institute members.
Otherwise, you can look me up on LinkedIn.
What’s the common KPIs used by BRM during meetings with the business?