12 February 2008 by Jim Sinur
|
Printable version | Email to a friend |
Basic Best Practices for BPM |
|
|
|
|
|
While we have some more advanced clients using our software, the vast majority of clients are trying to start BPM efforts and/or extend their initial benefits that have convinced them that BPM needs to permeate their organization. For those organizations that are in the beginning stages of BPM and/or are examining a rejuvenation of their BPM efforts, I wanted to document some of the critical best practices for early BPM success. Keep in mind that these basic practices should be considered for all BPM projects. I intend on delivering on some intermediate and advanced best practices in future blog postings. Consider this as BPM Best Practices 101. Proposition: (Picking the Right Process) It is important to propose the right BPM efforts (some would call these efforts projects) for a sure success. I would suggest that picking a safe process is “OK” for a proof-of-concept, but after that it would be important to pick a visible process that might be considered a “killer flow”. That is a process that everyone (or near everyone) would agree is important to do well and one which delivers future savings. In fact, BPM efforts that focus towards processes that have a potential for strong cost savings do the best in convincing those to “pile on” with BPM. It is just as important to make sure these processes are driven by the business. While there could be a high cost saving with internal IT processes, they do not have credibility with business professionals. Ideally, your early BPM efforts deal with crossing functional lines, so that lessons can be learned in balancing functional excellence with overall process excellence. The lessons learned here will help in the more advanced BPM efforts down the road. People: (Establishing the Right Culture).
There has to be a commitment to having the involvement of strong subject matter experts. This is more than using the marginal time of a business professional. There has to be a measured set of outcomes and time commitments that need to be monitored by a visionary leader and/or an independent party/unit (e.g. project office). Second, there has to be a strong partnership between business and IT. The business brings the knowledge and needs and IT brings the support and technical problem-resolving skills. Last, and most important, is to gain the trust of the workers who are involved in the process today. They are likely to be threatened by the implied changes that may occur in their job skills, steps and content. This is something that is earned by listening and implementing their good ideas and dealing with their concerns/feelings. Process: (Understanding the Real Process). It is imperative to have a keen understanding of the real process. This is much easier said than done. Even if you pick the right people, there has to be a melding of each of their respective understandings. Completing the process discovery step is critical in taking a BPM effort to success. Many successful organizations will arrange a workout session where good process discovery practices prevail (see blog Process Discovery Done Right (R5) ). Care should be taken in trying to uncover shadow processes as they contain “land mines” in them. One of the best ways to deal with this is by verifying the process discovery outcome with key process participants. It is easy to delude oneself that the process is simple and all will cooperate with the outcome of the process workout sessions. Quite often existing processes do not have good documentation or may be imbedded in a legacy-packed or custom application, and discovery will require some patience and diligence, but starting with a high level end-to-end process and drilling down in future iterations works well. Project: (Pulling the Right Levers) Even if you get all of the above correct, there is still a missing piece to the BPM puzzle. A process effort must have a rapid development process that starts with a kernel process and leverages multiple iterations to show quick progress. It is easy to get stuck in process discovery too long to try and get the process perfect in the modeling stage. This is a temptation that must be avoided with disagreements dealt with by utilizing a trial-and-error approach. For those organizations with easy-to-use simulation tools, this might be a help as well. It is important to have frequent reviews to realize benefits and qualify results. By using a dynamic-iteration-development method, this will put a premium on tools with agile features such as business simulation, dynamic business rule changes, and SOA, where the process involves technology and/or transactional components. Do it, try it, fix it !!!! How successful you are on an initial BPM effort will determine if you live another day, so doing some initial planning and reading will help you. There are a number of resources and BPM gurus that you can start with, but I would say that all will include the above basic areas of attention. Many of the experts will try and take you further, but you have to crawl before you walk, walk before you run, and run before you can attempt a marathon. |
|
| BPM | |
|
|
|
| posted by Jim Sinur at 4:28 PM ET | comments [0] | trackbacks [2] | |
|
|


Based on my observations and conversations with thousands of business and IT professionals, many BPM efforts are at the early stages and revolve around picking the right BPM process and achieving early successes.
There is more to having the right atmosphere around a BPM effort than just having really motivated and smart people. While it is important to have strong communicators that thrive on risk and the success of others that are to complete follow-on efforts, there are additional important issues to wrestle with in a successful BPM effort. First and foremost, gathering the right mix of people is imperative.