Business process maps are a growing area within business analysis. But many BAs are cut out from the business process. Others of you aren’t yet in a business analyst role, but would like to get experience with this technique so you are more qualified to fill a business analyst role.
Business processes are everywhere and most of any typical organization’s processes are largely unmapped. And that means there are many BA opportunities ripe for the plucking, whether you are employed as a business analyst or not.
But what processes should you or could you map? Let’s look at five processes that are almost always worth documenting.
#1Â – Process to Implement Software Changes
You might think that if you come from the IT side, you don’t have much in the way of business processes. However, the business includes the information technology team, and there are many processes within the technology team that could often benefit from being documented and clarified.
One of the most valuable processes to get a handle on tends to be how software changes are implemented. The Implement Software Changes process could include the following steps:
- Identify and approve the change, which could involve many decision-makers with varying levels of influence and authority.Â
- Create the software code to implement the change.
- Test the change and validate the new code works as expected.
- Fix any defects or deployment issues.
- Release the change to a test and/or production environment. Again, this can often involve many decision-makers and gate-keepers and include sub-processes for each system component involved in the release package.
At a high-level, you could capture your entire release as is process. Alternatively, any one of these steps could be a process in and of itself, which leads us to our next opportunity – the process to test a software system.
#2 – Process to Test a Software System
This one happens to be my personal favorite – the test process – and that’s because this is the process I conquered before moving into my business analyst role. Typically the test process is documented in a test plan. If you are in QA and look closely at your test plan, you might be surprised to find the seeds of a process flow within it. When I was a QA engineer, my test process included:
- A set of preconditions determining that the system was ready to test.
- The business users to get involved in the test process and the criteria for identifying them on a new project.
- Specific areas of the software application I needed each business user to evaluate.
- The steps for anyone testing to submit a defect for resolution.
- The communication path from me to the development team about the defect (and then back to the business user as a resolution was found and made).
Whether or not you have the title of Quality Assurance Engineer, if you are involved in the validation of software (or any other validation process for that matter), the process you use to test the system, communicate the issues you find, and follow up to ensure those issues are resolved is worthy of a business process model.
And if you are not part of the technology team (which is the case for many of our Business Process Analysis participants), I think you’ll find processes to map everywhere you look. Let’s look at a couple of the most common processes for which mapping efforts can be particularly valuable.
#3 – Process to Resolve Support Issues
Do customers, clients, users, or even members other departments send you issues that need to be resolved? How are these handled? Issue resolution is one of the most troublesome processes for nearly any organization or team. And that’s because issues often need to be bounced around between team members and departments until all the right information related to the issue is discovered, organized, and acted upon.
This process might be called Support Customers, Resolve User Queries, Deliver on Service Level Agreements, or Manage Support Requests. It could involve any of the following complexities:
- How issues are escalated from one department to the next.
- Who is responsible for what type of issue.
- Who screens the issues as they come in and assigns them for resolution.
- How issues are monitored for timely resolution.
- What the communication path is throughout the life of an issue.
The benefits of clarifying this process are significant. Issues represent “time suck” and issues that fall off everyone’s radar can represent significant risks to the business – losing a top client or failing to meet a public commitment. By clarifying the hand-offs, escalations, and expectations, you can often introduce simple changes to improve the process and gain significant operational efficiencies.
#4 – Process to Create Reports
Reports are everywhere in today’s organizations. Monthly financial reports. Weekly reports on unresolved issues. Technology stability reports. Customer activity reports. Sales reports. Past due reports. Marketing campaign effectiveness reports.
And creating all of these reports takes real time from dedicated employees like you.
But often the process of report creating is not as streamlined as we’d like. Perhaps we need to gather data from multiple different systems and compile it together. Perhaps we need others to gather some of that data for us, and that other person never seems to have the time and waits until the 11th hour.
And once the report is done, we might not even know who looks at it and what insight they glean from it.
There is a lot of value to be gained from evaluating the reporting requirements and process.
- Are there opportunities to streamline the creation and reconciliation process?
- What is the business purpose of the report? Is all the data needed?
- Is the timeframe and frequency correct?
- Could this report or parts of it be created in an automated fashion?
- Could we combine reports and alleviate some overhead?
Answering questions could save you and your organization significant time and could even be the first step to a more formal reporting system or a business intelligence project.
And while all of the processes above could definitely be relevant in a non-profit organization, there is one process area we’ve seen multiple participants tackle when volunteering their time to work with non-profits organizations. We’ll cover that next.
#5 – Process to Manage Volunteers
Volunteers are often the lifeblood of a non-profit organization. But they offer up many challenges. They must be found, screened, convinced of the value of donating their time, assigned to an appropriate activity, oriented, trained, scheduled, and monitored. Because if you don’t do these things, the volunteer’s time ends up being wasted.
But often this process is ad hoc and that detracts from the volunteer’s experience and puts the brakes on growth. That makes it a perfect process to be mapped.
Other common processes in a non-profit organization would include Accepting Donations, Managing Sponsors, and Organizing Events.
Find a Process to Map
Interested in learning more about how to take these processes and turn them into a formalized business process model? In Business Process Analysis, we’ll walk through a step-by-step process for mapping and documenting a business process. You’ll also have the option to receive individual instructor feedback on your model and 8Â PDs or CDUs towards your IIBA certification or re-certification, and/or 8 PDUs or Contact Hours towards PMI certification or re-certification.
