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.

Most process design methodologies start by modeling the As-Is processes before proceeding to define the To-Be processes. In our experience, many projects spend more time than is necessary modeling the As-Is, when they should be working towards the future. Time and resources spent modeling the As-Is delay the delivery of the final project, and should only be done to the extent that they add value. In this article, we will discuss the purpose of as-is modeling, common pitfalls which lead to excessive effort and concrete guidance on how to improve results with less effort and expense. While studying, current practices can be valuable, the current process must be flawed or you wouldn’t be replacing it. The last thing you want to do is replicate the flaws of the existing solution.

Why do As-Is Modeling

You can’t improve something which you cannot measure.  This is a basic tenet in six-sigma and many other process improvement methodologies.    Yet few organizations even consider trying to objectively measure any aspect of the quality of the process models which they implement at the core of their process improvement initiatives.   Fortunately, this is an area where the use of a BPM platform offers significant advantages over other technical approaches.  The fundamental difference between a BPM solution and a traditional code solution is the existence of an explicit representation of the business process, including the steps, their sequencing, branching and looping, worker assignments and external interfaces.  This process representation makes it possible to reason about the characteristics of a BPM solution in ways that are much more difficult with other technologies.

If you have been involved in very many BPM projects you have inevitably seen some which progressed through the entire development lifecycle with no major warning signs only to fail when put into production.  They fail because the delivered system does not solve the problem which the business needs solved.  They typically go through a complete lifecycle with verification at each stage.  The Business writes its requirements.  Business Analysts turn these into a functional requirements document, approved by the business.  The development team creates then implements designs and finally QA tests the system and verifies that it satisfies the documented requirements.  Yet in spite of all of this, the resulting system is not usable for its intended purpose. 

One of the persistent criticisms of BPM is that the process definitions are too rigid to accommodate the realities of modern business.  This can deter organizations from properly evaluating how BPM can help them.  The reality is that most BPM tools offer a range of options for building highly flexible and adaptable processes.  In this article, we will briefly explore some of these.

At a recent client meeting, the Chief Architect arrived a few minutes late, clearly upset. When asked what was bothering him, he muttered “Governance is a four letter word”. I am sure that many readers have shared that sentiment at some time, but it needn’t be that way.

Organizations who have adopted BPM as their platform for IT development have an opportunity to both simplify and improve their IT Governance and Compliance processes. All of the advantages which BPM brings to your core business processes are just as applicable to IT Governance.

Thirty years ago, Donald Knuth introduced the notion of literate programming.   He wrote “Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.”   His premise was that over the lifetime of any successful program, far more hours would be spent reading it for purposes of maintenance and enhancement than were originally spent creating it.  Furthermore, most of this would be by people other than the original author.  If this is true, a little more effort in documentation by the original author will be paid back many times.  We believe these principles are even more important in Process Modeling than in traditional programming.