Traditionally, IT organizations have been organized to deliver projects to the business. A set of requirements is delivered, IT does the work to create something to fulfill the requirements, then puts it into production. Such a project approach works for many traditional technologies. IT is used to a build/test/deploy/support cycle, and has usually organized itself around such a cycle.
However, business process management (BPM) is different. In the process lifecycle, you first need to discover the process, with heavy involvement from the business. Before going further, someone needs to make sure that it makes business sense to apply BPM to the process, which requires analysis and planning. Collaboration between the business and IT is critical. The business needs to be engaged early, and throughout the development cycle. Some sort of modeling tool can be used to facilitate this communication, rather than the more traditional approach where IT receives a flowchart drawing and a stack of requirements in a document. This approach can only be effective if there is someone in place to engage with the business and IT, to make sure that any models created follow company standards, and so on.
If you just deploy the completed process into production and stop there, you don't have BPM yet; you only have business process automation. BPM requires that you also measure the processes as they run, to ensure that SLAs are being met, KPIs are tracked, and to give process owners visibility into both active processes and historical data. This enables you to manage the process, which is the 'M' in BPM after all.
Finally, in a true BPM environment, you would look at what you have measured, and try to find a way to optimize the process. BPM is a cycle, where the goal is continuous process improvement. Yes, there are some "commodity processes" you may automate, such as employee onboarding, where the rate of change will be small. But the greatest value from BPM is typically derived by applying it to processes that differentiate your company from your competitors. It is those processes where continuous improvement pays the greatest dividends.
So, what does this difference in the development cycle mean to an IT organization? The answer is that to get the most out of your investment in BPM, you need to look at a different approach. Having worked with different BPM products for over 11 years, I've seen a variety of approaches used to roll out BPM. Lets take a look at a couple of case studies.
The following case studies are based on my experiences over the years. Looking at a number of customer implementations, many of them fall into one of three categories. I have outlined a representative example of each.
After purchasing a BPM product, Customer A decided that the best way to get started with it was to bring in a consulting services company to provide a turn-key implementation. The consultants came in, modeled and implemented the process, and rapidly put it into production.
Six months later, there was still just the one process in production. While Customer A was able to realize business value by applying BPM to one of their processes, they never moved on to the next process. Because they did not build up their own skills, if they were to do another process, they'd have to bring the consultants back in.
In addition to a lack of skills on the IT side of the house, there was nobody working with the lines of business to identify new opportunities for BPM and drive further adoption. They never looked at the business metrics to find ways to improve the process. In fact, two years later, the process is running exactly as implemented by the consulting services company.
Clearly, while this approach provides some business value, it does not drive a widespread adoption of BPM. It does not maximize the possible business value of the software purchase.
Customer B decided to get started with BPM by implementing a process themselves, with mentoring from a consultant. They had already identified the process they wanted to start with. Several resources from IT (some of whom were contract employees) worked with the consultant to get the process up and running. It went into production, which helped the customer realize some value from their purchase.
Six months later, there was still just the one process in production. One of the IT resources was assigned to another project. Two contract employees left to work at other companies. That left nobody with product skills to drive the next project. In fact, two years later, the process was the same, with only some minor modifications.
While there were some IT skills built during the course of the implementation, the IT group viewed the effort as a project. They wanted to implement it the way they were used to doing things in other projects. Once the project was completed, the IT resources went back into the pool for the next project. In addition, there were not any efforts to tie in with the lines of business to help identify additional opportunities for BPM.
As with case 1, while this approach provides some business value, it does not drive a widespread adoption of BPM. It does not maximize the possible business value of the software purchase.
When Customer C purchased BPM software, they decided right from the start to organize a group into a Center of Excellence (COE). This group consisted of dedicated resources, who were charged with the mission of driving BPM adoption across the enterprise. Their charter also included governance, documenting best practices, and growing BPM skills within the company. They used consulting services to help get started, but with the goal of gaining skills for the COE team.
Six months later, the first process was in production, and three other processes were in various stages of their lifecycle. The COE team was working with resources from the lines of business to identify additional opportunities for using BPM. Based on the measurements from business activity monitoring (BAM), they were also working on improving the original process.
The key to Customer C's success was that they didn't take a project view of BPM, but a program view. While they needed to make the first project a success to show a rapid return on investment, their larger goal was to build up a self-sustaining culture of process.
The problem with the turn-key approach in Cases 1 and 2 was that the customers were focused on solving the first process problem, but did not look beyond it. There was nobody documenting existing processes to identify opportunities for process improvement. Any skills gained were not looked at as an asset to build on. While the consultants applied their implementation methodologies, the companies did not look at the engagement as a means to adopt a proven methodology themselves.
Companies A and B got their first processes up and running, but over time, the processes never evolved to keep up with the needs of the business. Over time, the processes will start to become obsolete. This is due to the project only focus. Company C on the other hand had a program focus. They implemented a continuous process improvement cycle, where their processes continue to evolve to keep up with the needs of the business, and where they are always looking for areas of improvement. This results in a much higher return on investment over time.
As the COE has worked through several projects, they have defined standards as well as documenting lessons learned and best practices. When a new BPM project is identified, rather than having to start from scratch, the company can leverage the skills and assets from the COE. This results in faster implementations with higher quality, and a better return on investment.
Applying BPM to a single project can temporarily fix a business pain. Applying the COE approach can enable you to extend BPM out across your enterprise. A single project cannot infuse the culture of process into the enterprise as a BPM COE can.
Another advantage to the COE approach is that of reuse. When you implement the first process, you are learning. You will build artifacts that are optimized for your own business needs in your environment. If you stop after the first process, there is no reuse of course. However, if you can create a second process, there is a good chance that you can leverage something you built the first time around. The more processes that you implement, the more you can reuse your existing assets. The reuse of existing assets enables you to build processes faster, with higher quality, since you're leveraging proven components.
If your company has an SOA strategy, a BPM COE will result in a larger number of processes implemented, which means that you can reuse more of the services created by the SOA team. BPM drives SOA reuse, while SOA enables faster BPM development. While an SOA is not required for BPM, both programs can reinforce and help drive adoption of the other.
I have another reason for mentioning SOA here: in my experience, companies who get the most out of SOA have a COE focused on SOA. In much the same manner as a BPM COE, it provides management and governance, helping drive the adoption of SOA. The COE model has been a proven success for SOA programs. In much the same way, it can help you with BPM.
There are many possible approaches for getting started with a COE from doing it all yourself to bringing in a consultant to help you get started. However you choose to do it, there are a few important points to keep in mind:
- The COE model is a different approach to development. Many organizations resist change because they are comfortable doing things the way they've always done them. It is important to make sure that you have a strong sponsor to set the vision and drive organizational change.
- Part of the COE's mission is to document best practices. You will need to determine how best to document and share these practices.
- A COE builds a repository of reusable process assets such as process fragments, patterns, frameworks and utilities. You should determine how best to store these artifacts so they can be easily found and used in other processes. You will also need to decide how to handle and govern versioning of these assets. The Process Center in IBM Business Process Manager V7.5 enables the sharing of reusable of assets through the versioned Toolkit feature.
- A COE provides governance for the process lifecycle. This is another area where the common repository of the Process Center can help, or you can determine and design your own way of providing governance.
- A COE focuses on building skills, both for themselves and for tutoring other IT groups. You should determine how best to gather, organize and deliver the information you'll need for skills development and transfer.
- A COE provides consulting to the business and IT, helping to determine good candidate processes where BPM can be effective. You should determine what tool sets will be used for process discovery and documentation, as well as how you will work to engage the business during the process lifecycle. Tools such as IBM Blueworks Live can be used for process discovery with the business, feeding models into IBM Business Process Manager.
- You'll need to decide on a process implementation methodology such as agile, waterfall, or a variety of others. If you use IBM Business Process Manager, you might choose to use playbacks to get input from the business as you develop the solution. You'll need to determine how often to do them, what the milestones will be in your development cycle, as well as a strategy for testing and promotion of assets from development to production. This needs to tie in closely with your governance strategy.
- An agile, flexible process should leverage business rules. The COE needs to decide how rules are to be handled. Is there a COE already in place for business rules, or should this fall under the BPM COE? Is there a business rules management system (BRMS) in place already? Will you use the rules capabilities in your BPM solution? Or a combination of both, depending on the type of rules? A COE should decide up front what the strategy is for leveraging rules, so that you don't have to go back later and rework your processes to meet your strategy.
- The COE should align with the strategy of the business. Are you to be focused on improving processes to reduce costs? To improve KPIs such as quality? To save time? Or a combination of all three? By knowing the business strategy, you can better decide which processes are the best candidates for BPM.
To summarize, a COE is often started by writing out a charter, which clearly outlines the goals and objectives to be accomplished. It should spell out: "This is what we are. This is what we do. This is what we will accomplish." Once you have laid out the charter, you can then go about the work of organizing it, staffing it, and getting started on your BPM program.
In this article, you learned how a BPM Center of Excellence can help you get the most out of your investment in BPM software. You learned how traditional IT approaches don't always work for BPM, and how focusing on a program, rather than a project, enables you to derive the greatest business value and ROI on your BPM investment.
IBM Business Process Manager V7.5 Information Center
- IBM Blueworks Live
developerWorks BPM zone: Get the latest technical resources on
IBM BPM solutions, including downloads, demos, articles, tutorials,
events, webcasts, and more.
Journal: Get the latest articles and columns on BPM solutions in
this quarterly journal, also available in both Kindle and PDF versions.