OK, you have completed a successful pilot BPM project and your organization is now committed to a major enterprise BPM initiative. There are many steps you need to undertake now, too many for a single article such as this, but in this article we will explore one which is often overlooked. The BPM industry, both tool vendors and consultants, like to talk about how much simpler it is to develop solutions with BPM than with traditional programming tools. While this is certainly true, too many organizations interpret this as license to short-cut the disciplines which they have found to be necessary in all other forms of solution development. This article will discuss the importance of modeling standards, provide guidelines on how to develop appropriate standards and perhaps most important how to make them an integral part of your process.
For any other software development platform your organization uses you certainly have development standards. Some are likely generic applying to many platforms while others are specific to a given tool. Similarly you need to develop BPM modeling standards before you begin to expand beyond the initial pilot. Before we get into the standards development process, let’s briefly review the objectives of development standards.
Now that we have established goals of modeling standards, what are the sources for guidance in developing them. One of the first sources should be your tool vendor. Most provide best practice guidance in documentation and examples of some form. A few, unfortunately, will want to charge you for consulting to provide this. Each tool supports a different set of features and has unique characteristics, especially related to performance. Best practices for one tool are frequently bad design in another. The vendor is by far the best source of this information. There are many books, articles and web-sites offering best practice guidance. For an example of some of our thinking on this, please look at BPM Antipatterns. If you look at several sources one of the first things you will notice is that the “experts” do not agree. How do you choose among conflicting advice? One key is to understand the author’s goals. Many organizations use BPMN purely for documentation of processes, not execution. Different standards are appropriate for these two purposes. If you can, try to understand the author’s background. What are the goals of their recommendations and do they align with yours. When advice from an independent expert conflicts with your vendor’s advice, follow the vendor. In our own work we always favor clarity and simplicity. We may not use every feature a tool offers, but we find the trade-off favoring clarity to be important.
Identifying a set of standards is only the beginning of the process. You need to make them an integral part of the team’s daily practice. The first step is producing a standards guide document. We recommend a numbered list of simple rules. We have found an effective format to be:
In most cases, this will fit on a single page. For most organizations, an internal web site will be the preferred delivery vehicle. Providing links to each rule makes it easy for modelers to find the applicable rule. It is useful to group related rules in a hierarchy, rules for tasks, rules for gateways etc.
It is important to define the right number of rules. If there are too many, modelers will struggle to learn and follow them. If there are too few, they will not achieve the desired outcome.
We find 30-50 rules to be an effective scope. Be sure to include both positive and negative rules: You must do X, you must never do Y. Do not include rules which are enforced by your tool, focus on the activities where your team has discretion and needs guidance. In some areas, particularly user interfaces, your existing standards will be applicable. Do not duplicate those, reference them.We find it very helpful to create a sample project with small executable processes illustrating many of the rules. As in the documentation, include examples of both recommended and not recommended practices. Explaining a deadlock in a parallel flow should be sufficient, but if new modelers can execute it, they will acquire a better understanding. Be sure to use the same terminology in the documentation and examples. We are often able to use the example processes in the documentation.
Best practice training is essential. It should be done after the team has had product training, and preferably a little hands-on experience, but before they begin serious work on a project. If you built the example processes describe above, you should use them in training. Unlike in the guidelines, it is appropriate to demonstrate and explain rules which are enforced by the tool.
When new members join your team mentoring is critical for success. Whether they come from a traditional programming background or something else, BPM will require new and different ways of thinking about problem solving. Having an expert work alongside and provide guidance can avoid the frustrations which often arise. Many times I have heard developers say “I could do this quicker in Java”. That attitude cannot be allowed to fester. Mentoring will help people become successful more quickly and become champions of BPM rather than skeptics.
Peer reviews should be part of your development process for BPM, just as with any other solution development platform. The focus of the peer review must be on whether the process meets the functional requirements of the business, but it is also the best time to formally enforce best practices compliance. We find a simple spreadsheet to be a good tool for this, with a row for each rule. The review provides feedback for the modeler, and gives the reviewer an opportunity to explain why the rule is important in the specific context. It also provides valuable feedback on your rules. You can learn which rules are violated most often and use that to improve your documentation and training. If you identify common modeling errors not covered by your rules, then you can add appropriate rules. Your best practices are not static, they are part of a continuous improvement process.
As your BPM projects evolve into a true enterprise wide initiative, you may find it useful to invest in more automated data collection. Analyzing hundreds of peer review spreadsheets is not practical, yet they contain much valuable information. You can replace the spreadsheet with a web based form with a database back-end. Then you can run queries and reports to identify trends across all projects. It is possible to do even better by automating much of the data collection. BPMN defines an XML serialization for process models. This can be programmatically analyzed to verify compliance with many types of rules. Furthermore, it can be used to calculate many other metrics which are not realistic for manual verification. You can learn more about this at Process Analysis.
Success with BPM is a long journey, and too many organizations fail to reach the full potential. It is rarely a straight path; there are many pitfalls and landmines waiting to obstruct you. One of the surest ways to improve your success is to learn from those who are further along. We hope that the ideas presented here will help you along your way.
There are no products in your shopping cart.
| 0 Items |
Membership at BPMInstitute.org includes access to our other communities
