Implementing a project without adequate business process and workflow modeling is like driving in the dark: You can’t be sure what you are going to hit, but you are likely to do some serious damage.
One of the critical mistakes businesses make when planning a project is in forgetting the adage “we don’t know what we don’t know.” All too often, we fund projects to enhance customer service or to improve a security control or upgrade an enterprise system without taking adequate steps to review HOW business is conducted and what these changes, implemented in the name of progress, will do to our workflow.
Some may argue that their company performs business analysis as part of every technology project. However, as a single, often early, step in a technology project, business analysis is typically:
- limited to a handful of use cases directly related to the project scope
- focused on capturing functional and non-functional requirements
- time boxed by the project schedule and/or available budget
Business analysis is frequently treated as an end-to-a-means, not a direct contributor to the overall project value. It is relegated to the rung just above developing operational run books and the SOPs that we have to write when implementing new tech in an enterprise setting.
Enter Business Process and Workflow Modeling
What is different with a business process review is that it is not a byproduct, rather, it is an integral part of a transformational change project. In Six Sigma, it is part of the very first phase, Define. With a business process review, we take a holistic view of the operation, model how business is performed, and identify those critical success factors that must be achieved in order for the business to be successful.
Think about that. What good is it for us to implement changes without taking a thorough assessment of:
- WHAT we do,
- WHY we do it,
- WHEN we do it,
- HOW we do it,
- WHO is involved in making it happen,
- WHAT responsibility and authority do they have,
and especially,
- WHAT are the desired (success) outcomes,
- WHAT needs to happen for each desired / successful outcome.
Though it might sound like what our business analysts do, the problem is that it probably only sounds like what they do. Too often—and truly I hope your business is the exception—we hamstring our analysts by giving them strict boundaries based on funding, scope, and authority.
For instance, when you implement an enterprise-wide control, like data encryption, do you invest the time to have your analysts look at all of the ways that potentially sensitive data is shared internally and externally from your company? Is it an exhaustive analysis or merely a best effort based on the stakeholders who were identified in the project charter?
Have you ever been on a project where someone suggested to “turn it off and see who yells”? It is not as uncommon as we might hope.Mike Courter
It’s usually not a question of whether we have the capability to go further; it’s that we don’t plan to. We have to build it into our project scope. If it’s not part of the work breakdown, baked into our plan, then it is not going to happen. There is only so much time, so much budget, and so we find ourselves making accommodations by restricting the scope of our analysis. Have you ever been on a project where someone suggested to “turn it off and see who yells”? It is not as uncommon as we might hope.
Another consideration is that we might not have the proper authority to analyze our business as a whole. The problem that many businesses face, especially as they grow, is that they build swimlane diagrams and then believe that those boundaries are cast in stone. We build artificial walls to protect our mission—or fiefdom—and those walls lead to delays, miscommunication, disjointed and broken processes.
What about confidentiality?
While we want to increase transparency through our project, we cannot afford to discount the need for confidentiality. Some industries work under the principle of “minimum required” information sharing, which is not only expected, but mandated by law. In those environments, as in your business, you need to maintain appropriate controls on information sharing, even and especially as part of a project. If anything, these types of requirements are perfect examples of where business process and workflow modeling are crucial.
In financial services, there are many nuances that need to be considered when implementing technology and, specifically, security controls. For instance, there is a financial control called a Chinese wall that is implemented between the front and back office to restrict the flow of sensitive information between investment banking and financial brokerage staff within the same company, to control the sharing of information that could lead to or give the impression of insider trading. If you are working in financial services, you would want to be sure that you didn’t provide a way to circumvent this business critical protection.
Around the world, personally-identifiable health information is protected by a number of privacy laws and health-related regulations. In the U.S., this includes HIPPA. If you have visited a medical facility in the States, you have likely had to sign an acknowledgment of your rights under HIPPA. One of the protections provided by the law is that medical providers and facilities maintain the confidentiality, integrity, and availability of your sensitive information. A common approach to securing this information is through password-protecting workstations and devices that store or display sensitive information. Again, understanding both the business process and the supporting workflow provides insight into what is possible or even preferable when making decisions of what to implement. Password-protected screens with a time out feature may work well on a hospital floor, but could prove harmful in an operating room.
In business process and workflow modeling, we take our business in its entirety, identify what is required for us to be ultimately successful, and map critical business processes, with their associated workflows. We can then model the proposed solution in the context of our operating environment and prove whether it will function as described, fulfill our requirements, or break our systems. It is from this lens that we can identify potential improvements to our processes, workflows, systems, and skillsets.
So, how do we do that?
The 7 Tenets of Business Process and Workflow Modeling
It would be easy to make this complicated and try to boil the ocean. The real decision of how to proceed depends a great deal on your culture, your business’ DNA, and your leadership’s philosophy on change.
To keep it simple, I like to boil our methodology down to seven tenets:
- Utilize a comprehensive, holistic approach focused on business outcomes.
- what outcomes are we trying to accomplish by implementing this project?
- what outcomes can we not afford to have happen?
- what outcomes are critical that we must protect for our business to be successful?
- Involve personnel at all levels of the organization.
- Include external forces and requirements.
- Model the workflow between critical business processes.
- Assess responsibilities and address excessive or lacking authorization.
- Maintain backlog of future requirements / features.
- Know what you measure and the story that they tell.
Don’t fall into the trap of documenting project requirements by interviewing a small group of end users or the technology team, or by referencing an external list culled from an industry standard or a vendor’s product feature set. Treat your business as a whole with a comprehensive analysis that focuses on business outcomes:
From the inception of the project, begin involving personnel and resources from all levels of the organization, and continue to involve them, consult them, inform them throughout the project lifecycle. If they are involved in a critical business process, include them: from boots on the ground up through senior business stakeholders.
Robust solutions have wide-reaching impact on our business. One of the gotchas that can bite us as we implement more sophisticated processes and systems is previously unidentified external requirements. It is critical that we address these upfront, as non-compliance can cause loss or interruption of business, and costly fines or fees to remediate after the fact. These external forces and requirements may include local laws, regulations, industry standards, contractual obligations, market forces, customer demand, etc.
Once we define our critical business processes, we need to model the associated workflows. The processes themselves only tell part of the story. The interplay between processes and systems detail how data and transactions travel through the business. They also represent potential risk as changes occur in our operating environment. This is not an either/or. You need both.
It’s an interesting anecdote how frequently we find individuals who still have access to systems and data from a previous role at their current employer. Luckily, most organizations disable access when an employee is terminated. However, entitlement reviews are often not performed in an effective manner or frequently enough to protect critical business functions or sensitive, confidential, or proprietary information.
It is particularly vital to assess the responsibilities and authorization required for effective business operation as we change business functions. And it is detailed work—including use cases, positive path, negative branches, out-of-band request handling, and undocumented workarounds—but well worth the investment.
It is easy to get waylaid, especially as you strive to include the input of personnel at all levels across the company. Not every good idea will be approved. One way to increase transparency—and faith—in your project and of future transformation work is to keep a running list or backlog of requirements and features that may be given future consideration.
Businesses tend to capture a lot of different metrics at the functional level and in aggregate to know how they are performing. These can provide useful insight into critical business functions. Sometimes, we’re surprised by what we don’t—or can’t—capture. Sometimes, the numbers don’t tell the real story, either. It’s important that we strive to understand what we’re they’re telling us and to identify gaps in process, control, or measurement as requirements for future initiatives.
Putting it all together
Once you’ve performed a thorough business process and workflow modeling of your business, the best part is that it is reference-able and reusable. This isn’t a one off analysis for a given project. Sure, you will need to update the model from time to time, as your business evolves, but your advantage is that you have something to update. And isn’t that a great thing to be able to put your finger on? How many businesses can truly say that they:
- know the critical success factors for their business?
- identified business outcomes?
- documented critical business processes?
- modeled business function workflows?
- assessed responsibilities and addressed gaps in authorization?
- know what they measure and how to tell their story?
Where this can get tricky is in the presentation. Business process and workflow modeling can generate a glut of data and documentation about your critical business functions. Remember, before, I said that we didn’t want to boil the ocean. We also don’t want our teams having to drink from the firehose!
The tools and templates that we’ve used in the past for requirements definition are not ample to organize and manage the depth and breadth of discovery, feedback, requirements, decisions, designs, and implementation documentation that we will likely generate as we proceed down this path. The truth is that this type of approach is cross-functional. It borrows from several disciplines, including business analysis, process engineering, integration, project management, project portfolio management, and graphic design.
“Why graphic design?” you may ask. In addition to creating process and workflow diagrams, you need to consider how you will communicate the results of the business process review. Your audience will range from boots on the ground / front line workers to board level stakeholders, so it needs to be presented in a way that is digestible and translates well with various audiences. To pull this off, you definitely need someone on the team who understands how to create a compelling presentation that truly tells the story of what your company does, how it does it, and what is critical to your success.
Michael Courter | COO, Head of Operational Excellence & Program Management Follow @MikeCourter
Mike helps companies achieve operational excellence through transformational change. A certified Scrum Master and Six Sigma Master Black Belt with over 25 years of professional experience, he has served as CEO at Mountain Movers Consulting; President and COO at Threatelligence; Program Manager of Advanced Security Services at Cisco; Lead Architect of Bank of America's Information Security Center of Excellence; and Vice President, Global Technical Security Initiatives at Merrill Lynch.