BPMN and Executable Businesses: When Will We Learn

A quick look around the blogs and latest articles reveals a lot of discussion (again!) about BPMN and what it is and should be used for. We seem to have endless debates about why and how it is easy for business people vs. why it is not, now we are seeing increasing debate about whether it is the right notation/approach for Business Analysts – I think it is perhaps time for us to remember whose role is what in the organization and what they are supposed to be able to bring to the party, then we can consider what tools, notations etc. might be appropriate.

For the purpose of this post I want to draw the parallel with data modeling, a field that is well established and in which everybody has their part to play. At the lowest level we have our Database Administrator (DBA), they live in the land of "Physical Models" and know that they have to fine tune them, breaking some rules and adding others, so as to ensure that the "Database" performs at its optimal speed. So from a BPMS point of view we can see that there is a definite role for a BPM Administrator, someone who is very familiar with the engine and knows how to find tune the "Execution pr Physical Model" so that the system performs at its peak – For these people BPMN makes sense as a notation as it is very closely tied from the model/code/execute perspective. So I contend that BPMN is the right approach for these people.

Then stepping up a level we have our Data Analyst, these people live in the realm of "Logical Models", they take the inputs from Business and System Analysts and look at the business problems and system requirements from a data perspective and create the logical models from the conceptual models. They know that nobody would expect to implement an efficient database purely from their model and that it requires work and tuning in order to create the optimum physical model from the logical models they create, whether they use Chen, Bachman or UML for notation the Business or Systems Analysts don't really care, for that is the role and domain of the Data Analyst. Could BPMN be used in this area, yes it probably could and we could have BPMS Process Analysts to carry out this role. Again a specialist knowledge is required to ensure that the model is complete and consistent, helped of course by an appropriate modeling tool with model rules being enforced (A point worth noting is that for years many Data Analyst resisted using tools that forced rigor on them, with the result that hundreds and thousands of man hours were wasted building inconsistent models that could not be used to generate good physical models and databases).

Then we come up to our Systems Analysts, whose role was always to look at the business requirements and translate those that required systemizing into specifications that could be implemented, these are the people who also start to take into account hardware platforms, software applications and corporate standards for databases etc. It is their job to help to create and put together the systems that will solve the business problems at hand. As inputs they may well have the "Conceptual Data Model" among other things. But, we know that the conceptual model was just that a collection of "things" that the business saw as relevant data with lines that indicated there was some kind of relationship between them, though not what the relationship was. So we would indeed need a similar role for our BPMS world a BPMS Systems Analyst.

Then we come up to the Business Analyst, whose role is to help the business in identifying and solving business problems which may or may not require systems or systemization. If we really think that we should be turning them into low level implementers then take a look at the IIBA website (www.theiiba.org) and review their Body of Knowledge. I have just finished reviewing the soon to be released version 2.0 and you will see that our Business Analysts has more than enough on their plate already, they have to learn a vast array of skills in order to be effective at what they do, to my mind the last thing they need to be expected to learn is another low level notation, just because some IT people find it too hard to learn the language that the business speaks.

So if we want to have an effective debate about modeling and notations for Business Process I suggest that we talk with true Business Analysts to see what sort of simple "Conceptual" approach makes the most sense for them. Then we can look at what the best way of creating "Logical" models is for our systems analysts and finally we can allow our BPMS Administrators to play till their hearts are content with the BPMN notation that is created and designed for them and for whom it is ideally suited.

Another group of people who I have not yet mentioned are "Architects", a group who are popping up increasingly, either from an Application, Software or Enterprise perspective, but most of whom seem to exist under the wing of the CIO. The business belongs to the business, the Chief Enterprise Architect role is already occupied in business, it is the CEO and contrary to what one senior enterprise architect told me recently – he suggested that I am too old fashioned and that I should just get used to the fact that process would all be automated and businesses would just do without people, that the 21^st century business model was a) Enterprise Architecture b) Business Architecture (using OMG MDA) c) Business Process Models (Using BPMN) and D) Automated Processes; without involving people – an executable business – it is people who will use the systems, it is people who own and run businesses and it is people that systems in the main are supposed to support. So a little more time speaking with people to find out what their problems are will make live a whole lot easier for people to get budget and resource to build and implement systems. If this thinking makes me old fashioned then so be it, but if we truly believe that we are moving to a world of pure system executable businesses without human intervention then it is a sad day for the human race (and one that poses some even more interesting change management issues and barriers)

Of course these are just my opinions and I am sure that there are many who will disagree, but for those that chose to do so, please don't write to me about the origins and purpose of BPMN, I was at the original meeting where the idea was first muted by two people from two vendors in the UK over a beer in London many years ago. I understand exactly why BPMN as originally created – I also accept that it has come a long way since then.

Destination Dubai

Last week saw me attending the IIR BPM conference in Dubai. The event which took place 19th-20th May, was my first opportunity to actual stay in Dubai, usually I am just passing through on my way somewhere else. The agenda seemed impressive and I was very much looking forward to listening to what was happening in the BPM sector in the region, and of course sharing my own observations.

The range of speakers was quite exceptional, as was the number of speakers talking about taking a top down, leadership led approach. If these companies can truly stay the course, then we should be seeing some pretty amazing results over the next few years.

One interesting thing was that many of the speakers came from manufacturing organizations or government agencies, this is in stark contrast to most other conferences I have seen where Banking and Telecoms are the dominate stories, perhaps in an ideal world we could see something that balances and blends the two camps better.

Overview of the Conference Messages

Rather than simply trying to paraphrase all the presentations I thought it might be nice to take pieces from each of them and try stringing them together in such a way as to give those who attended some picks and those who didn't an easy story of what we learned. So I thank all those speakers who either donated "words" or sparked the thoughts for what follows.

Success begins at the top with a promise from the executives "To be the best for the good of tomorrow". Of course all of our tomorrows will be based on the customer and they only exist outside of our organization. Every process and every project we undertake needs to be able to flex and adapt so as to ensure that they are finely tuned to deliver excellence for the customer. By delivering on our promise of excellence to our customers we will find that our costs are kept lower and that are revenues will rise faster.

These things can only be achieved if we are willing and able to continually challenge the current business practices and models and very rules by which we operate, this constant challenging is required if we truly believe that we can and will be world class, not just telling people that we are world class.

These ideals when taken together require us to change our culture, to a culture of change! Although they are driven from the executive suite and reinforced by the actions of business leaders, it is at the management and operational level that we actually need to make the changes that will make the difference. This requires us to provide suitable training and then coach our teams in how they can consistently deliver success. Nobody suggests that the path is easy, it requires persistence and commitment, but building a track record of small quick wins can help us to build credibility. Not all of the benefits we deliver can be seen as hard or concrete benefits, many are of a more softer nature, but even these can and should be quantified as they are very often the most useful ones, especially we are to engineer for constant improvement, and will be in many ways critical to the long term survival of our organizations.

In order to increase our chances of success there are a number of key things that we need to remember. First and foremost it is fundamentally about the customer and becoming even more customer centric, without them we will have no business and it is the delivery of successful customer outcomes that is the ultimate measure of both our corporate and process success.

Skilled Communicators

In addition to the attitude and behavior changes more important might be our skills as and ability to train others as great communicators that will really define how good we can become as organizations.

The great thing about teaching people real communication is that by doing so we are equipping them with skills for the whole of life. Every day in every way we are communicating, we are even communicating when we don't communicate! So the more we understand about what we are doing and saying and how we affect the people around us then the better we will all be.

Something to remember is that one size definitely does not fit all when it comes to communications, food for thought it is frequently stated that only 7% of our message is delivered through the words we use, 38% is delivered according to our tones and tonality and a whopping 55% is delivered through our physiology. So if we are avoiding sitting down with people in either meetings or workshops, then we are giving up on 55% of communication and limiting ourselves to only getting at most 45% of what is possible. Even if these statistics were out, there is still a good chance that words alone word still command only a relatively small percentage. When deciding on the means and manner of communication it is worth remembering that the meaning of communication is the reaction we get.

Putting all this together we realize that it is our ability or inability to communicate that not only decides how successful we will be, but also how successful those around us can be, we could be holding them back instead of helping them forward. These comments on communication serve as a nice reminder that as managers we need to learn to be leaders and to fire up our teams, point them in the right direction and then get out of the way and let them get on with it.

Additional observations

Sometimes we have to remember that Human Interactions is about just that; interactions between human beings!

One amusing comment was over the use of the term BPR, it was suggested that if people kept talking about it then they were still living in the ark, in fact many presenters talked about it, looked pretty human and did not look like they came off an ark, so I decided to have some fun with the "R" in BPR and use the "R" to describe the stages of a BPM process so first we have Realisation – we have a problem, then we have Revelation – analysis reveals the current state and the problems then we have a choice either Redesign or Rengineer the process, before we implement and test the Results to ensure the desired effect then Record and Remind to monitor and constantly improve. The point being it is not about the letters BPR or BPM or BPA or any of them, it is what we mean by it and what we do about it that will dictate our likely success.