Modeling & The Current State (Modeling the “As Is” process is mostly a waste of time)

December 8, 2008

It seems a contentious point of view in Business Process Management – but when we come up to the “Understand Phase” (“As Is” or “Current State” model ), we recommend “time boxing” the work to ensure that the activity is kept at a suitably high level. The intention of this activity is really to create a baseline; a reference point for the BPM project.

Now those who continue with their “legacy thinking” perspective usually decide that it is important to create a detailed description of how work happens. They model everything in sight, trying to create an accurate representation of the work as it happens today. While this is good for the “billable hours” of consulting firms, it does little for the business managers engaged on a journey of change and discovery.

The point is that the amount of work expended here is usually wholly inappropriate to the benefit derived. If your intention is to change the way things happen, gathering a great deal of detail around current work practices is a waste of time. If you are going to improve things (with or without the use of automation), then you will be changing how the process is carried out … i.e. how things happen today will soon become a thing of the past.

Don’t get me wrong, it is absolutely essential to develop a baseline understanding of the ways things are done. It’s just a question of emphasis. The issue for those involved in the exercise is just what degree of detail is required. They should be asking “can we stop now?”

The real purpose of current state modeling is to establish a baseline – so that the team can establish a realistic business case (allowing them to track benefits and improvements during and after implementation), and to identify the areas that require attention.

This is more about a pragmatic assessment of reality and clarification of current performance metrics than it is about process modeling. The metrics in question are those that the customer of the process really cares about (not the detailed cycle times of some low-level sub-process). From a modeling point of view, the need is for enough structure to hang the metrics upon (and perhaps one level of detail below). Anything more than that is a waste of time and resources.

So how much detail do you really need? Well, I normally start with high level outline of the process – the major chunks and then draw a simple high level process model. I recommend a high level BPMN diagram, but I usually seek to contrast that model with a Role Activity Diagram (not the same as a flow diagram with swim lanes, RADs model how the Roles involve change state and synchronize their actions), and perhaps simple Object State Transition Network (how the things moving through the model change state).

With a high-level flow diagram or outline of the process, it is really very straight forward to develop these alternative views, but they really do help people see things differently. I often say that the problem with Flow Diagrams, is that “the more you look at them, the less they mean.” Flow diagrams always look correct – for example, in my recent book “BPMN Modeling and Reference Guide” (authored with Stephen White the main author of the BPMN specification itself), I have yet to receive a note from anyone telling us that we have a major flaw in one of the models (yes, there is at least one). It just looks correct (and this is a book where we tried our very hardest to make sure every model was “right”).

Incidentally, the best reference on RADs is Martyn Ould’s “Business Process Management – A Rigorous Approach.” And for OSTN, I prefer the IDEF3 perspective as it is relatively simple and easy to understand (UML also has similar modeling capabilities).

Coming back to the Understand Phase, in the workshops with the Subject Matter Experts (SMEs), I also seek to understand the volumes of work, any major exceptions and the percentages of items that follow the major paths from decision points. The other thing to understand is the numbers of employees involved in the work (FTEs and the amount of time spent on each area of the process).  From that information you can calculate the costs of undertaking the work and where the money goes. You also need to understand the roles involved, and the capabilities of the staff members who fulfill those roles. All of these become essential ingredients for the business case. Without it you are whistling in the wind (when it comes to asking for funding). Even if you already have the funding, you should do this anyway (it will certainly be needed later).

I could go on here at length, but the point I am trying to make here with this blog post is this … if your consulting provider is asking you to fund a detailed “As Is” phase of work, then you are throwing money away. They are more interested in lining their pockets than assisting the client. The only exception that I can think of is where the process is itself highly regulated (and a rigorous work definition is mandated by law). In such cases, I think you have to draw your own conclusions on how to avoid “analysis paralysis.”


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).


Customer Experience – How To Get It Wrong

October 23, 2008

So now, exhausted after getting conferenced out over the last 3 weeks, I am on my way back across the pond. And I find myself once again confronted by the complete lack of thought on the part of my not so favourite airline (British Airways).  This posting is a bit of a rant … but it has a point. Designing an effective customer experience needs to be reflected in all your processes not just your marketing collateral.

As a regular traveller across the Atlantic, I normally fly Premium Economy as I can usually work and get things done (and that also has the added advantage of letting me actually have somewhere for my long legs). So over the years, I have risen to the lofty ranks of a Gold Card holder. And the benefits I get for that are … er … well I get to check in at the usually empty First Class line, and sit in their lounge (I don’t usually drink while on travel).

Now on the Washington to London flight, those with access to the lounge were always able to have their dinner before getting on the flight in the hope of getting some sleep on the 6 hour red-eye flight. Well not any more, it now seems that this privilege is reserved for those who have agreed to fork over the $4500 for each way (and that’s booking 3 weeks ahead).

Point being that, despite spending around $30-40K per annum with BA, I am now denied this meagre benefit (instead I have to head outside the lounge and spend $15 on a shitty hamburger).

As a Gold Card member you would think that this would entitle you to the odd upgrade – the reality over the last 18 months – nada. No upgrades unless you know someone on board, or get someone to pull strings for you back at the departing airport, or the once in a blue moon when they are really overbooked in the back of the business units (and nobody else is above you in the pecking order … i.e. has a permanent flag on their record saying they are “suitable for upgrade”).

So you start to ask yourself just what is the benefit of putting all of your business into an arrogant waste of space carrier like BA. Yes they “protect the brand” but that is of little consolation to you the regular traveller. And they piss you off with petty rule changes designed to save a few dollars – but in the process, they loose customers.

Where was the cost benefit analysis … let’s tease it apart. Per passenger that are in that category (i.e. gold card holder in Premium Economy), BA get to save perhaps $5 per person (remember they get to save the meal onboard). Lets say that applies to half of the PE travellers … say 12 people. They don’t get to save any staff costs really (same number of people standing around in the dining area). And with 2 flights per night to LHR, that say $120. Or put it another way, less than $1K per week. But along the way they loose a regular customer … and I am sure I am not the only one.

Time to switch back to United … while the service is not great, there are appreciable benefits associated with them. I am not saying their experience is much better, just that you don’t really expect much (and you dont have to pay a premium for it). BA’s marketing is that there is some real benefit … when the reality is there is virtually none (compared with competitors). Their cost cutting program has perhaps trimmed a few dollars here and there from the fixed budget, but they have also trimmed customers.


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.


Legacy Thinking or BPM

November 30, 2006

Expecting Different Results When You Do The Same Things …

I am sure there are more of them – but here are a few that might resonate. I find that so many people are climbing on the band wagon of BPM that they dont even realize it when they are applying exactly the same thinking that caused their existing mess in the first place.

  • “We are going to outsource implementation” … as in we are going to abrogate responsibility and find someone to litigate against once it all goes wrong.
  • “Must get all our processes into a repository” … as in , lets spend 10 man years pouring stuff in the front end only to discover that 80% of it is out of date and we still haven’t got anything implemented.
  • “Functional Requirement Specification” … as in, have you ever seen one that actually stood up to the test of time. Whatever the user signed off on was not what was really wanted.

But it goes deeper than that. We see so-called “experts” exhorting people to adopt one process modeling technique and ditch all others (see
here As Craig points out in his comment “In a way it is like learning a language (spoken or programming) you never really have a true appreciation for communication until you learn a second one.” (corrected typo).

We see many of the same old approaches trotted out with subtly different spin (I am thinking IDEF based decomposition here and all the raft of “methods” that went with it). Sure IDEF has its place, but not at the sharp end of helping people really get to grips with how things get done around here (or step outside their cosy little box). Exactly what ICAM Definition Language (and ICAM stands for Integrated Computer Aided Manufacturing) has to do with white collar office work and services is quite beyond me.

I am sure there must be other good examples of Legacy Thinking out there … a free copy of the book to anyone who can get past my BS filter (you knew there had to be a book aroudn the corner). Expect it end of Q1 2007 (which probably means Q2).