The past year has seen business process management (BPM) achieve tremendous growth in the enterprise, but there continues to be a good deal of misunderstanding about BPM itself. At its core, BPM is about automating and streamlining manual processes. These processes may represent a diverse range of tasks, from citizens renewing their passports via online Web applications to an employee requesting paid time off from the HR department.
The overarching idea with BPM is to automate manual processes that consume employees’ valuable time and energy — time that would be better spent in other capacities. As simple as this may sound in theory, there remains a great deal of confusion about BPM and how to properly deploy it within an organization. You can ask five different experts for their definition of “BPM” and receive five distinctly different answers.
To that end, it’s helpful to illustrate specific BPM use cases to give a better idea of how BPM works when successfully implemented.
Reality Check
One major point that’s often overlooked at the beginning of a BPM deployment is how to properly model a process. You should model processes after how employees actually work, rather than how they should work in a perfect world.
The first step to this end should be to identify a benchmark for how people currently perform a given function at an optimal level of output and fix a model of that — you can do this graphically, though it can also be done in a simple document. Once you’ve established these benchmarks based on actual performance, you can establish a workflow model that you wish to implement.
There’s a lot of knowledge at work that goes undocumented in an unstructured way, through emails, phone calls, chats and other means. Organizations can use BPM in order to surface that information, and capture it in a basic flow model that shows how people are currently working. Before deciding which tasks or steps performed by people in an existing process can be improved — with integrated software, for example, or even automated entirely — it’s important to recognize the realities of their environments.
Individuals in an organization, department, or group may not realize how the process in which they are involved is connected to another process, which is connected to another process — and so on. End-to-end business can be complicated, and it’s important to take a graded approach, rather than focusing changes on the “big picture” from the get-go.
That’s not to say the big picture isn’t important. But while keeping the larger focus in mind, start with a smaller, more easily managed project that will produce measurable results. Some common examples of processes that are easier to manage include internal processes like filing expense reports, purchase orders and other administrative tasks.
Start Small
I recommend that companies start with simple, visible, low-risk internal projects before moving on to increasingly critical processes. However, the first implementation should be one in which real improvement actually makes a difference to the organization. No one will be impressed if the first application of BPM results in “improvements” like better handling of useless, unnecessary, or truly unimportant tasks.
As a concrete example, my team recently worked with a large local authority in France to help them better log and track requests to repair roads. We worked with seven members of their IT team to implement their initial process, which focused on repair requests.
After they became comfortable with that automated process, they started to model other small processes that were essential to managing their system, such as setting up and taking down user accounts. Modeling these common workflows offered them a way to manage all of the accounts and keep them synchronized.
By automating processes, new users are able to enter an organization and instantly get access to a company intranet or email accounts with LDAP. Likewise, their system no longer has accounts for people who leave the organization. The overall aim here is to save IT teams a great deal of time, freeing them up to address other critical issues.
When new employees join a company, there are a lot of associated processes to complete and emails to send. An enormous amount of time was saved by automating basic recurring requests. BPM helps IT teams do mundane tasks quickly, especially if there isn’t already a system in place for those activities.
Buy-in Requires Collaboration
One final point to stress concerning implementing BPM in your organization: You should encourage as much collaboration as possible between developers and end-users throughout the deployment process. IT can invest a lot of time developing the “perfect” BPM application, but unless the end-users who will be employing the process in their actual work become involved, there’s no guarantee that the two sides will ultimately sync up.
A quick-and-dirty test deployment during development to get hands-on user feedback and check the usability of online forms can make all the difference between a BPM deployment that is quickly adopted and one that is quickly abandoned.
There is no end-all, be-all guide to successfully deploying BPM, because organizations use BPM for many functions and to achieve a variety of goals. However, there are certain best practices that can lead to success.
What I want to stress here is that BPM offers tremendous potential to organizations seeking to improve efficiency and ROI, but it takes a thoughtful approach. Begin with well-defined goals that keep the big picture in mind. Then take things one step at a time and build on successes, all while encouraging active collaboration between process designers and process stakeholders.
Loading ...
