It started simple enough: someone calls and a staff person answers the phone. Over time, email and online forms were added. Individual programs created their own branches with their own phones, inboxes and forms. In an attempt to be more responsive, a phone tree was added and later expanded. Years later, a tangle of inputs and redirects created such complexity that no one at the organization knows exactly which paths lead where – or how many constituents ever actually got their question answered.
Business processes have a life of their own. As we add layers we can lose sight of the original goal. We begin to create shortcuts and create tribal knowledge where a small few truly understand the inner workings of the process tree. And, most disconcerting, we can no longer consistently deliver services.
This is especially problematic if you are about to embark on a new technology project. Not having a handle on business process is likely to result in the existing business process challenges will be replicated in the new technology environment or the project will be delayed as you stop and remap business processes mid-project.
In this post, we will step through an approach to business process analysis and streamlining. This is a recommended precursor to starting any new project. Completing this work in advance can help separate process from technology problems – and may directly inform the technology you choose to implement.
1. Define goals & anticipated outcomes
Begin at the beginning. What are the core needs by major functional areas? How well are these needs being met today? And, what goals will we set for improvement?
For example, let’s say you have been tasked with streamlining your grant application processes. You hear about the difficulty of getting grants out the door from members of the team. After submitting a grant there are persistent concerns final edits were not included and quality controls sometimes miss critical application requirements. You also find out it typically takes 60 days to submit a grant resulting in missed submission deadlines or grants to never be pursued as there simply was not time. You might begin with the following:
- Ensure staff can draft, review, finalize and submit grant applications effectively
- Enable quality controls throughout the process
- Decrease time to submit a grant from 60 to 30 days
You have stated the purpose of the exercise, identified a key obstacle to be removed and you have defined an efficiency metric to measure progress.
2. Document affected organization structure
Next, you should document the affected organization structure. The goal is to ensure you have a handle on the parties involved in the processes.
For example, you might be analyzing gift processing at your organization. Start at a high-level and walk through the affected groups. Each business unit soliciting gifts plays a role (ex. Major Gifts, Direct Mail, Planned Giving, etc.). High-volume management brings in Direct Mail vendors responsible for segmentation, production, and cashing and caging. Banks and merchant accounts must also be accounted as that is where the revenue actually is. Development operations might be responsible for logging gifts in the CRM application. Finance is ultimately concerned with reconciliation. Your affected parties are:
- Business Units by Revenue Stream
- Major Gifts
- Planned Giving
- Direct Mail
- Online / Digital
- Events / Peer-to-Peer
- External Vendors
- Segmentation Vendor
- Production Vendor
- Cashing and Caging Vendor
- Banks and Merchant Accounts
- Internal Operations and Admin
- Development Operations
- Finance
You effectively defined all of the parties surrounding the process group. They will provide the detail enabling you to document the current state. Eventually these groups will be impacted by any proposed changes.
3. Document current state
Next, we take a granular look at how everything works. Step through each activity and be sure to explore each fork in the road. After mapping the entire process, test your documentation by walking through each step as an end-user. This step is about fully mapping the current state – not evaluating or attempting to solve process challenges as you find them.
For example, if you were tasked with streamlining a student application process your steps may include documenting all points of entry including both online and offline applications as well as any other applicant support channels made available to the student. As you drill into the online application be sensitive to capture every step in the sequence, every point of exit and inquiry. Capture when someone gets stuck on a step and asks for help. Be careful to note any dead-ends or drop-offs such as when an individual gets to a certain point, is unable to proceed and then must begin again or roll-back to an earlier step.
You can test the above example by walking through each step of your process diagram as though you were an applicant. What happens when you call the support number before starting? What happens when you call the support number midway through? And so on, until you have fully stress-tested your documentation.
Again, the goal of this step is not to prescribe a solution – it is to objectively document the current state, faults and all. Not until you have a complete picture should you begin to seek solutions – as solving one minor problem may have unexpected consequences elsewhere in the process if the entire solution is not fully understood. Your list is likely to begin to grow of minor issues in need of addressing.
4. Define Business Process Groups
Next, we will look for common purpose across the process groups – and begin to identify those areas sufficiently similar as to allow grouping. This is really our first work towards streamlining. If we can find similar processes and bring them into alignment – we can gain efficiency while also improving customer service.
For example, let’s picture you having been tasked with streamlining external communication processes for your organization. You had previously documented a dozen points of entry as an individual might call a specific program area, development operations to update information, or just request generation information about services. You also identified each path had rotating staff responsible for their specific area. Looking at it overall, it stands out everything is customer-service-oriented – and could make for a logical grouping as a centralized set of business process.
5. Recommend and Document Change
The final step in your analysis is to document these changes and make recommendations to streamline processes. The recommendation is likely to include many minor consolidations, such as reducing the number of inboxes, phone numbers, etc. It is also likely to clean-up major drop-off points where significant effort is lost on an application or where effort must be duplicated to resolve a problem. You are likely to note routing disconnects where someone is unaware they have been tagged for follow-up or their next step is needed.
Larger recommendations may indicate a need to consolidate or group business processes and realign around larger needs. Many individuals tagged with a small piece of customer service may see those responsibilities consolidated into a centralized customer service team for all in-board requests.
As you document the recommendations, focus on the following:
- Distinguish between technology, people or process changes (e.g. those changes that are symptoms of the tools and technology available, indicate a need to train or otherwise support the people involved or those that are simply a matter of modifying process)
- Indicate how quickly a change might be implemented. Simple changes may be able to go into effect immediately whereas others might require larger change or investment.
- Note who will be impacted by each change
- Clearly indicate next steps to move forward
Summary & Conclusions
Challenges in business process are often rooted in having a great starting point but evolving needs over time. To meet those needs we layered new processes or process short-cuts into place. Each successive solution only complicates the situation – and slowly we lost efficiency or even lose track of all the increasing layers.
Our first step was to take a breath and assess what we hoped to accomplish – what the goals were for the anticipated end-state. From there, we documented all of the players involved as we will need their input to understand the present state and eventual buy-in to the changes ahead. We then create and test a thorough written accounting of all processes at a granular level. By grouping those processes we are able to begin to identify logical places for streamlining. And, finally we provide recommendations as to how and when to meet the goals we set at the beginning.