BPM – Is it a Software Engineering Tool? A Technology? or a Management Discipline?

November 30, 2008

In his excellent posting, Keith Swenson makesmany good points. He points to the range of interpretations of BPM, and particularly highlights the issues associated with its interpretation by software engineers as just another piece of hype on the road to good programs. But I think there is another, perhaps more important strand that is buried in there. As Ketih points out, BPM is about the Management of Business Processes.

As we all know, everyone’s interpretation of the term Business Process is different. In my training (whether that be BPMN, or higher level training on BPM Methods), it is one of the first things I get people to write down (inside the first 5 mins), and not surprise, every definition is entirely different. And when those people are senior managers in a ciompany, their interpretation of the term is invariably what I call “Process as Purpose“. The point is that they see Processes as being more about the purpose than the constraint implied by sequencing of steps. They are there (at the training), because they see the importance of “Managing” their processes. Indeed that concept (Managing Business Processes) as central to the success of their companies.

[[ I am still down in Brazil, and I am really struck by the process sophistication of the people I am meeting. They all get it. I was more than surprised to find two “Business Owners” (people who own significant businesses), giving up 3 days of their time to come on a course around how to structure and run BPM programs. They were cherry picking from the broad range of techniques we covered, but ask yourself whether you could imagine the CEO or COO deciding that they should attend a public training course. That’s what I am getting at about the sophistication of the Brazilian business climate. ]]

Coming back to Keith’s post, he describes a spectrum of BPM interpretation – from pure Software Engineering (where the SW Eng tries to reflect the needs of the business person’s Business Process); through Business Processes being modeled by a business person, then tossed over the fence to a Software Engineer to finish them off; to the Business Process as modeled by the business person, then being directly executed (what he called “Pure BPM”). I am not quite sure I agree with the Pure BPM bit, but I do know what he is pointing to … where the processes of the firm are driven by models (without translation to some intermediate executable format (like say BPEL).

One of the comments on Keith’s post points to the challenges of getting business people to model their own processes and make the resulting collection of stuff useful. He described the usually resulting mess as an “expensive disaster”. And the reason for this is that business people dont usually have the sophistication to understand their business problem as a set of inter-releated processes that between them deliver on the “Process as Purpose” concept I referred to earlier.

Invariably, process modelers (whether IT or business) tend to see a process problem as a single process. They interpret the high level Purpose as a single implementation process (which invariably it is not). They make all sorts of mistakes such as mixing up the “Handle an Instance” with the “Manage the Flow of instances”; they switch from batch mode to handling a single instance; they dont think about the interfaces between processes (handing information from one to another), etc. What they do is try and connect up everything that sounds like an Activity into one convoluted process.

Now software engineers are usually more adept at the necessary abstract thinking, but that doesn’t mean to say that business people cannot wrap their pretty heads around the notions. It is merely a reflection of the fact that they have not had adequate training. What is missing (across this entire industry) is better learning around “Process Architecture” – what “chunks” do you need and why. Poor chunking leads to unnecessary complexity (and even “expensive disasters”).

We are still stuck with decomposition as the prevailing mind set – where sub-processes are always contained within the parent. SOA concepts seek to get around this, but there is also a higher level “Business Services Oriented Architecture”. Processes should not be regarded as some sort of static hierarchy, they are more accurately regarded as a network of interacting instances. Think more jigsaw puzzle than org chart.

When I gave a “Power Breakfast” at the last Gartner BPM Summit on BPM and Process Architecture I had a packed room (it was starting at 7:30 in the morning so these people were keen). I described a set of methods that you could use to go from “What Business Are You In” to what “Processes Do You Need” right down to the SOA components if that is what you wanted to do (I would recommend looking at a BPM Suite first rather than going straight to the SOA software engineers paradise). I only saw one person out of the 90 or so get up and leave, and nearly everyone else gave me their card at the end of it. The room really was comprised of mostly Enterprise Architecture folks from the IT community, all of whom struggle with this transition.

Switching tacks – the vendors BPM Suites are unconciously making this architecture problem worse. With only a few exceptions (Pega, Itensil, BizAgi … I am sure there are others in this category too, these are the ones that spring to mind), vendors interpret the business process problem as being entirely seperate from the data and artifacts associated with the process (business people see them as intertwined). They regard the process relevant data as a set of named value pairs … the information required by Process A is declared on Process A, and must be recreated on Process B and then mapped from one to the other (if the processes need to communicate with each other). That means that there is an extra (unnecessary) layer of complexity for business people trying to reflect their business problem. Moreover, if you change one process, then you need to refactor all the interfaces. This is “software engineering” oriented thinking.

The other approach is to define your data structures (perhaps as an “Entity” defined as an exstensible set of XML artifacts) and then describe the views on those artifacts at the level of the data structure. Then it is merely a matter of associating your processes with the Data Entity, and all the different views become available. Process interfaces become an order of magnitude more accessible (to the business user), you can use any number of processes to support a single case of work, and again it helps move away from the software engineering mindset we find in so many BPM tools (which were often created to solve the problem of Enterprise Applicatin Integration … hence their association with Software Engineering).

Advertisements

Case Handling Discussion

December 16, 2007

Mea Culpa – yes, like others in this space, the challenge is keeping the blog going. Usual story of not managing to keep the clones working properly while I am sleeping. Lots of things to start sharing here … and now that I am out from under the endless train of deliverables and trainign courses, I should be able to find the odd bit of time.

The reason for this long awaited posting … I felt I wanted to pick up on discussions emerging in the BPM space – driven by Henk de Man’s presentation at the OMG meeting last week. He was talking to the need for better modeling approaches to support Case Handling (or Case Management depending on your perspective).

Like James Taylor (name now corrected),  I thought Henk’s presentation was also interesting. And as I pointed out during the session, a great many processes should be viewed in the Case Handling context. Readers might also be interested in the papers I produced that discuss these sorts of issues. But really getting at it from the pov of the Customer and Processes – “Business Processes and Customers – Difficult Domains to Integrate” available in the White Papers section of the BPM Focus web site.

The core of Henk’s presentation was that BPMN style modeling is not much help when trying to capture the essence of Case Handling. His own product has a strong Case Handling orientation and uses “States” and “Events” to enable some of the flexibility that Case Handling apps demand. In my experience, the key differentiating factor (between a tranditional workflow/BPMS app and Case Handling) is that the emphasis is with Case – it may have many processes and documents associated with it.

I suggested to him that he investigate Role Activity Diagrams (a way of modeling at how the Roles involved change state as a result of the actions and interactions that occur). This is perhaps much more appropriate for the state based view he was hankering after. The best reference on this is Martyn Ould’s book “Business Process Management – A Rigorous Approach”

But all should understand that Case Handling approaches have been around for a very long time. They are everywhere you look once you get it in your head. Think of these:

  • Government – State and local government, NGOs, Police, Justice (investigations), Land mgt …
  • Financial Services
  • Insurance – Every claim is an exception
  • Banking – Trade exception handling, premium account management
  • Healthcare – From clinical provision to administrative management and payment
  • Oil & Gas Exploration- Knowledge workers spread thinlyaround the world
  • Pharmaceuticals – Clinical trials, compound development, marketing campaign management
  • Virtually all “professions
  • Wide range of Small to Medium sized contexts
  • All sort of Procurement situations
  • Customer Contact Centers – across virtually all industries, where they validate, identify work items and then resolve … here 80% of all calls are WISMO (What Is the Status of My Order)
  • Even the weekly Staff Meeting is a kind of case handling situation if you look at it from a process point of view.

All of them have continually unfolding, evolving scenarios. That is where BPM needs to concentrate its efforts. The transactional space that has characterised efforts to date is really pretty straight forward. Case Handling involves synchronous interaction with users, long running case resolution situations, multiple process fragments, knowledge work, …

Interesting vendors in this space are few and far between. At one level it is big systems implementations such as Cordys, Pega and Graham Technology. But there is a simpler more accessible level that is best characterised by folks like Itensil (in my mind one of the most itneresting I have come across). I am sure, that with care you could implement TIBCO, Appian and Lombardi to build effective Case Handling situations, but it is really a quesiton of adopting the right style of design thinking. And with more and more of these vendors offering SaaS delivery mechanisms, I think we are going to see an ever increasing level of innovation in this area.


Getting the BPM Message Across

April 27, 2007

Many in business people still struggle to see the role of business process in building better performance (i.e. business results). So I thought I would share this little hook that I developed within one of my consulting engagements. It is based around preparing bread – the components of the bread, the flour, the yeast, the water and then baking it all together for an effective result. In your business it is the dough rising that equates to achieving its performance objectives … however those performance objectives are defined.

Whether aware of it or not, in most businesses the different ingredients are not well aligned or working together as well as they could be. Mixing the metaphors for a moment, they are not rowing together in a coordinated fashion. Business Process Management brings together a range of techniques and approaches—the BPM tool box. The components of this tool box help change agents in the business (the bakers) create their own special sort of dough. At the heart of that is an ongoing enquiry into business processes—if you like the water that binds the flour (your people), with the yeast (the technology).

There may be other subtle ingredients. But cooking is not only about mixing the right quantity of ingredients; it is also how you mix them, and how long you bake the mixture. You might think it is just a question of getting the right measure of ingredients. But first, it is necessary to decide on the sort of bread you want to make, and how it is going to be delivered, to whom. Alongside the choice of people (flour), the most critical element is the water (processes)—the ingredient that binds it all together.

Relatively speaking, adding the technology is the easy part. But it requires a considerable amount of rigor. This rigor is most apparent in the way we understand and model processes—because in the modern BPM technology, it is these models that drive how work is managed and driven through the business. If we want to change the way the business operates, all we then need do is change the models. No programming should be required (or at least only in very specialized cases). As much as is possible, everything is configured with models.

But to develop these models requires a rigorous approach and methodology—one that allows us to bind together (integrate) the people, processes and technology. The problem is that process models are like a bikini—what they reveal is suggestive. But what they hide is vital. (Paraphrasing Levenstein talking about statistics).

This is the central thesis of the BPM Process Modeling Fundamentals training course we have developed within BPM Focus. It not only features the very latest developments in BPMN (developed in collaboration with Stephen White, the main author of the BPMN standard), it also includes complementary techniques that help people really see their processes from a number of different angles. The next iteration of the course is due for delivery in London next week (May 1st and 2nd), then in Washington DC on May 24th-25th and Sydney on June 7th-8th. We are also delivering the course inhouse to a number of corporate clients. It should also be available on-line soon.

It is complemented by another program Ensuring BPM Project Success, which is oriented toward ensuring that BPM Programs are rooted in the organization appropriately (due to run in Washington DC on May 21st and Sydney on June 12th-13th). You could think of this second program as being designed to help you set up to guarantee success in BPM projects (or how to avoid getting egg on your face). It is designed to cure you of the legacy thinking that created the existing mess and provides an actionable methodology and framework for BPM success.


BP Maturity Models

November 30, 2006

Sandy Kemsley in her piece today about BPMM (BPMM tutorial) clearly hasnt seen too many of these things.

Our old friend at Babson (Tom Davenport) has one, Gartner have a collection of slides for $795 (I am sure it is more than that), Bearing Point have one (The
Business Process Maturity Model: A Practical Approach for Identifying Opportunities for Optimization
(overview free from BP Trends) … even a casual search on Google brings up a great number when you put in Business Process Maturity Model. But BPMG dont seem to make it to the first few pages. Every vendor worth its salts in the SOA space has one …

But none that I have seen have anything like the depth and breadth of that which is being discussed at the OMG next week (i.e. BPMM). Personally, I had a real “A Ha” moment (I know I have had a couple in the last 6 months …) during John Alden’s original presentation on the concept in June in Boston … I was writing (thrashing around) my paper on Corporate Agility and Process Innovation (available
free on the BPM Focus web site under White Papers). It was very much about at what point endless standardization of process needs to give way to innovation and personal freedom (the sort of thing that Jon Pyke alludes to in Why Workflow Sucks).


Business Process and Religion – Evangelism – Yes; Fundamentalism – No

November 20, 2006

I see I am going to have to dedicate more time to getting the blog out … but when I look at the broad range of tasks I have to get completed in the next 2 weeks I am back at the office – God knows where I will find the time.

Over the last 20 years I have found myself trying to help a broad range of people understand the various vagaries and wrinkes of business processes. But I have found a real difference in the receptivity between those people who know very little (and want to learn) those who think they know a bit (and want to be impressed). When introduced to a new modelling technique or approach, the common reaction is “why would I want to do it like that, I can always use <whatever technique I know already> to model that. What they seldom consider is what that new technique or approach might do for them, or how it might give them another subtle perspective.

So perhaps you will understand me when I say Business Process is a little bit like Religion – once people have been inured in one branch of the church, they tend to resist attempts by others to engage them (just think about Protestants and Catholics for a second – they have a lot more in common than they realize, yet they still seem to find each other repulsive). And the world of process is not that different. There are a lot of parallels between the differing factions of the business process movement, and those that one can observe in religion.

If you have been trained in UML, then that is what you want to use to model (everything must fit into that UML metamodel); if you grew up with IDEF, then all models appear as though they should be constructed around Inputs, Outputs, Controls and Mechanisms (or some other similar flavor). If Rummler Brache was your thang, then you favor the deployment flowcharts and swimlanes associated with the technique. Whether you have been brought up on LOVEM, BPMN or simple Fortran flowcharts, then the world is often colored by your original christening. It is only when you have been around for a while that you can see the benefits of the different approaches.

Putting all of that slightly different way, and maybe I am stating the obvious – a little knowledge can be dangerous. And in the world of business process, that is certainly the case.

As people search around for the meaning of life (or process) they discover different disciplines (new techniques and approaches). Sometimes, they become converted to a new religeon (say Pi Calculus, or conversational interaction loops of ActionWorflow) and feel it incumbent on themselves to act as missionaries, recruiting new sheep to the fold. Those that dont agree with them are clearly wrong, or misguided, or even worse, seditious. I suppose the point I am making is that while every branch of religion needs its evangelists, fundamentalism tends to alienate potential parishioners. And the problem with religion is that, for most people, once they have got some of it, they tend to shun all other approaches.

So by now, I hope you understand that I see the world of business processes as a pretty broad church. Personally, I am keenly interested in all process related innovation. But I don’t see that as a restrictive covenant that stops me from looking at, or even trying to explain, approaches that do not conform to some purists definition.

Indeed, I believe that it is only when you contrast different perspectives on a business process that you really understand it. You need to be able to step outside the box and see it for what it is. You need to be able to examine the interactions on one hand, and then flip it all around to look at the sequence flows; to look at what is required of the process and separate that from how it is achieved. With luck, the new BPDM metamodel from the OMG will enable the analyst to step around these different perspectives, sharing information between different modeling tools and techniques, without loosing the fidelity of the information.


A Process “A Ha” Moment – Two sides of the same coin – Orchestration and Choreography (and BPDM)

November 2, 2006

I was sitting in the Delphi BPIS Summit a couple of weeks back contemplating my closing keynote address and not completely listening to the speaker (Kevin Fickenscher) at the time who was doing a “call to arms” type of piece about how the world was changing (as if we didn’t know).

I shouldn’t sound disparaging, as the talk was actually very interesting. At one point he started to describe a concept he called “Simultaneity” (is there such a word I was thinking … having looked it up since, I can tell you there is).

He then went on to say that in Perot Systems they have literally thousands of associates working on a single client’s problem (system) at once. Really, what he was getting at was how things in the world often need to happen all at once, in parallel.

And it started a chain of thought – so how do you manage that (sort of problem). Or if you are say, Shell or Nokia with literally hundreds of different functions that need to collaborate on major projects; or indeed any large business attempting to deliver a consistent customer experience … just how do you manage that.

Ahhhh – Process. You need processes to help coordinate the various resources at your disposal. Of course!!

But the problem is that most people still think of process in terms of input output chains of activities borrowed from manufacturing. That notion of process doesn’t help you too much when you are talking about the coordination of multiple actors, operating in parallel.

And that chain of actors is increasingly up and down the value chain, no longer constrained to the familiar boundaries of the organization where command and control principles can apply.

What you need to do (as well) is to start thinking about processes as sets of “interactions.” This is the other side of the coin from the procedural notions of process that we are all so familiar with. Instead of solely focusing on the chains of activities with their (hopefully neat) sets of input-output documents, you also need to think about the protocols and agreements made between the actors. They represent the white space in between the functional silos, the hand-offs and commitments made from one party to another. Indeed, one could start to think about how a process is composed from fragments of interaction.

Having understood the interface requirements for your process, you can start to explore how your part of the business (value chain) wants to implement against that set of needs.

Really we are talking here about the difference between “Process Orchestration” and “Process Choreography”:

  • Orchestration is a term used to describe the traditional notion of managed or directed execution, where activities are carried out, with branching and synchronization of different threads.
  • Choreography is a more abstract notion of process (for most people). It is used to describe the “Interactions” of collaborating entities, each of which may have their own internal orchestration processes.

And this is where the emerging business process standards are starting to come to the rescue. The OMG “Business Process Definition Metamodel” (BPDM) provides the capability to represent the semantics of business process models, independently of the modeling notation. Think of it as a sort of “universal syntax” of process. The central idea is that BPDM is capable of supporting a mapping to the semantics of most common types of process model – whether that is BPMN on one side and Role Activity Diagrams or UML models on the other. As a result it enables the robust exchange of information between models of one type and other types of process models, while preserving the fidelity of the model content (as much as is possible).

At the heart of BPDM is support for both orchestration and choreography. This is going to become critical to modern organizations as the business boundaries change ever more quickly. It is self evident that businesses are constantly reorganizing, merging and splitting their operations, resulting in continuous changes in both the internal boundaries, and that which what owned or outsourced to both collaborators (in the supply chain) and the customer. Yet there is still a common process operating across the value chain. BPDM facilitates this evolving, permeable boundary by identifying and managing the common elements, enabling the modeler to easily transition between them.

Because of this sophistication, BPDM can support a very wide range of usage scenarios. For example, it enables high level, abstract “business capability models” used in the boardroom, to exchange information with lower level, procedural modeling notations used in BPM projects, and then on into process execution environments (BPM Suites).

BPDM will also facilitate the definition of complex inter-company interactions (and between the roles within the company). Such models could be created from scratch, or created through the composition of existing interaction fragments (from a library). The resulting model might then provide the terms of reference for each participants’ own internal orchestration model. In turn, this orchestration model could be teased apart to explore the business interactions that exist between the internal participants (internal roles) and/or used to generate a robust BPEL execution model that directly supported the firms agreed choreography with the other companies.

In this way, the process would not need to be completely ripped apart and redrawn every time there was a change of organizational responsibility. Roles (areas of responsibility) and their interactions could be modeled in an abstract way, then instantiated as needed to meet the requirements of the case in hand.

While most might think of BPMN collaboration diagrams to model interactions, a better approach is to use Role Activity Diagrams which focus on the interactions themselves and how a role changes state as a result of the actions and interactions that occur. So assuming we had tools that supported the BPDM package for BPMN and another tool that had mapped RADs to BPDM, it would be possible to translate between the two with clarity and fidelity. (BTW – the best reference on RADs is Martyn Ould’s book “Business Process Management – A Rigorous Approach

So what does this mean in the real world of organizations like Perot Systems, Nokia or Shell – that business process standards, such as BPDM, will make it easier to model (and therefore understand) the simultaneity in a world where interaction has become as important as procedures (in some cases or more). It also makes it more straight forward to drive those processes using BPM Suites and report on the performance of the individuals and teams involved.


BPM Focus Joins The Blogging Generation

November 1, 2006

Seems I have finally succumbed to the blogging craze. I find that I am tracking so many anyway, and commenting liberally on the work of others, I might as well start doing it from my own space.

BPM Focus (BPMF) is a new member network formed by the recent merger of Enix Consulting and WARIA. The new organisation extends the traditional services offered by WARIA through a range of educational services focused around the BPM arena. The BPMF Learning Framework is a program of BPM Development & Deployment courses incorporating best practices for BPM project delivery and supporting techniques from the very best thinkers in the industry.

You will also find a range of BPM related white papers available on the site, including the acclaimed “Keys To BPM Project Success” paper (registration required).

BPM Focus is also heavily involved in work on Process Standards at the OMG, and provides a certain degree of “outreach” support for the work going on there. You may be interested to read my comment here responding to Sandy Kemsley on developing these standards.

You can expect perhaps a few postings per week on subjects around the BPM space.