Stormchasing - the art of business process management

Image via Wikipedia

I don't get a lot of time to watch television, but when I do, one of the first channels I usually turn to is the Discovery Channel. The main reason for this is the excellent documentaries and the second reason is for Storm Chasers.

In theory Storm Chasers as a concept shouldn't work. It is a reality TV series following a group of meteorological geeks chasing tornado's in the American mid-west. It generally consists of long shots of people driving SUV's as well as some - usually- very dark shots of clouds stretching from horizon to horizon. All this is usually done in quite inclement weather.

What keeps me coming back to watch is the same thing that attracts people to all sorts of reality TV - it's to see real people in real, unscripted situations trying to beat the odds. Storm Chasers has the usual mix of personalities some of which are guaranteed to start sparking off each other - but what they also have (and one the things that sort of attracts me more) is technology. Lot's of technology.

There are two key groups of people in the chase. One are meteorologists who are trying to survey tornado's and are attempting to capture information to help understand the forces behind these awesome spectacles. The other side are a small group of film-makers who want to take a huge IMAX camera into the eye of a tornado and film it. They - basically - have a large camera which they have mounted on a specially adapted 16,000 pound armour-plated SUV (That's right, 16,000 pounds).

Between them they use lots of electronics. The researchers even have their own Doppler radar dish on wheels (known as the DOW), as well as internet weather, lot's of complex weather measuring apparatus running through computers and computer algorithms. Yet they only seem to actually achieve their objective once every 6 to 10 tornadoes.

Why?

The reason is that they still need human intervention. The data is purely that - it is data. It is the actual state of play at a given situation. The forecast is purely that, it is a possible situation at a time in the future. The glue holding all this together is the human interpreting the data.

Now before you start wondering why I am giving you a report on some Discovery Channel reality TV show and click away I want to pose a simple question to you: How is the Storm Chaser's paradigm like managing your business processes?

Well, I see three similarities:

1) They both start with understanding what you already have.
The technology and data they have is used to create an 'as-is' situation. They need to know what the current state of play is before they can start to forecast what the future will look like (or in their case where a tornado might touch down). Sure, there are schools of thought which disagree with collecting an as-is state, but I believe that in the world of business process (as in the world of Storm Chasing) you need to know where you are starting from to work out where you are going.

2) Both can use technology to the detriment of the ultimate solution
One thing that is constantly being referenced on the program is the all powerful nature of the DOW (The Doppler-on-wheels) which is revered as the key piece of technology that is driving them forward. Whilst lots of other items are used, the key decider about future direction is the DOW. Thus it has taken on a significance out of proportion with the actual value it delivers. This is particularly true given the fact that it is a data provider and still needs interpretation. To illustrate this fact, in a recent episode a rival group of Storm Chasers - armed with just a Dell laptop and wireless internet connection - managed to make exactly the same deduction about where a tornado would land as the DOW did. This is a prime example of relying too much on the technology as a solution to the problem rather than as a human enabler. How often do we do that in our day-to-day lives as process analysts? How many times have we relied on some magical BPM tool (or similar technology) as the solution to all our problems? And how often has this proven to not be the case?

3) They still need human intervention to make things work 100%
As mentioned previously, the ability of the technology to make a precise prediction about where a tornado is expected to touch down is minimal. Sure, there are general predictions but when you want to get a truck into the middle of a tornado, you need to be a bit more precise than 'general'. In order to finesse the location they rely on the experience and expertise of other people. They have a weather forecaster on board who isolates potential danger areas at the beginning of the day and then the team leader will make a decision about where to send the equipment to intercept based on that (except often he ignores the data and recommendation and goes somewhere else). Furthermore, despite the presence of several $100,000's worth of equipment and vehicles all the data is being funnelled through the team leader to help make the prediction. So far his ability to accurately forecast - especially in a quickly changing environment - has been less then optimal. But this is a failing on behalf of the individual and his decision making skills rather than the human intervention itself. In the business world as well there are often decisions that need to be made around processes to make them 100%. As with the Storm Chasers, these decisions do not always accurately occur within the system and rely on human intervention. Again - as with the Storm Chasers - management style and ability will predicate the success of these decisions.

I found it very interesting to see the parallels between the world of the Storm Chasers and the world of the business process analysts. Although I'm not sure I want to spend my working life driving a 16,000 truck through the eye of a tornado for a living!

Review: Lombardi Blueprint - Modeling software

One of the problems that many companies have these days is the fact that they wish to be able to get their processes documented with minimal fuss and training. This isn't possible with a lot of the tools available on the market. Many of them are either expensive or complicated or both.

Microsoft Visio is cheap(ish) but doesn't handle multiple users at the same time - it doesn't impose a methodology on you and not everyone can get their head around the "templates and lines" concept.

What is needed is a tool which will work the way people think: You drop your thoughts into some sort of basic structure, add as much or as little information as you want and let the free/cheap software take care of it

That's where Lombardi Blueprint comes in. The software itself is SaaS (i.e there is no download and it all runs off the web) and it comes in two versions: Free and Licenced ($50 per user per month with extended functionality that is cut down if the free version is used after the end of the trial period). Blueprint was the tool that was used in Tillamook County Creamery Association's project that I wrote about in February

What I liked about it:

• It's actually very simple to use. You can literally sit there and type in a list of 'activities' which can be at various levels. For each activity all you then need to do is add in a couple of bits of information to classify and quantify the data and the system does the rest
• It's intelligent: it can create full, BPMN standard process maps based on your input
• It's not difficult to learn (I picked it up with very little instruction)
  
• It allows multi-user collaboration on-line
• It has in-built revision history for when things don't work out exactly how you would like
  
• It has publishing facilities to get your thoughts off the PC and onto paper

What didn't I like about it

• It uses the concept of 'milestones' - which are arbitrary groupings of processes as a means of modelling these processes Not everyone uses milestones in their modelling.
  
• The printout is not customisable and is, frankly, lacking in finesse.
• Was not able to test it with 'large' process maps, so unable to validate whether there is a problem here or not
  
• No third party export functionality
  

I'll cover these in detail but let's go through an exercise to see how it works.

To use the software you will need a user profile creating with Lombardi. This means signing up and accepting the email link supplied. Incidentally the terms and conditions are fairly lengthy and are displayed in a scrolling window on the sign-up screen which shows about 5 lines at a time (Lombardi - Stick them in a separate screen and make them easy to read! Not hiding anything in there are you?)

Once you have access to the system you will see a couple of default examples provided by Lombardi which will allow you to see exactly what the system can do. It's worth looking at the different examples to see the approach that Lombardi have taken in documenting the process (admittedly each of the examples are fairly simple or rudimentary - but it's always the same with any software demo).

You can create a project to start with. This groups all your information together and makes it easily accessible.

The whole ethos of this software is that you need very little 'knowledge' about process to work this. All you need is knowledge about HOW you do your role. You start by typing in some items on the Discovery Map.

The Discovery map
This is, basically, a screen which identifies 'blocks' of work - at whatever level you wish. Each block of work (or activity) can have some text associated with it and details such as inputs and outputs as well as business owners and participants. The sequence in which these blocks are entered determines the sequence in which the process 'flows' from one block to the next. (Click here for a screenshot of the Discovery map)

What I particularly like about this style of documentation is that it is 'non-inclusive'. By that I mean that there is only a bare minimum amount of information that you have to provide (An activity name), but any other information can be supplied to make it easier. I can foresee this being very useful in facilitated sessions or other process discovery activities when the users can talk around what they do and the information they give can be captured as they talk. Sometimes a lot of information is supplied and sometimes a little. At this point if there are any attachments that exist they can be linked to a particular process step or activity for further review. It as assumed during process discovery that activities are performed sequentially. No decisions are included at this point (although textual information about decisions can be added at the relevant point). This is also the point at which information can be entered about who performs or owns this activity. All of the entered information in stored against the process and can be regurgitated onto either word or PowerPoint documentation.

But the beauty comes when you have entered this information and changed the view to 'process diagram'.

The Process Diagram
The system will automagically sequence the information into swimlanes, with the appropriate flow between boxes. The diagrams will be created in BPMN standard notation.

This is, of course, just the start of the diagramming. You can then start to manipulate the model any way you like. Decisions can be added, sub processes created automatically, and message events, conditional splits and exception events can all be added too. They cool thing about this particular part of the tool is that as soon as you move one of the activities between swimlanes it automatically updates the appropriate information behind the scenes, thus maintaining the integrity of your documentation.

It should also be worth remembering that this is not a fully featured 'Visio' like tool. In fact it is pitched as the tool that people would use as a way of replacing Visio. But at the moment there are some layout issues associated with the tool. For example I added a conditional split to a diagram. The layout was altered to include the conditional split and it included a link to one of the existing boxes I had entered (which was good) The second branch of the conditional split went to a new process sink. However I actually wanted to direct this to a different activity on the diagram but was unable to. After several minutes messing around trying to make this happen I was ended up deleting the conditional split and starting again (Click here for a screenshot of the Process Map)

I like some of the simple but useful tweaks that Lombardi have added to this tool. For example each of the activity boxes can be colour/color coded. The coding is totally arbitrary but you can, for example, assign a red colour to activities that are risk related, a blue to activities that are input tasks and a green to activities that are output (these are totally user defined). Any colours entered on the Discovery map are carried forward to both the process diagram and the associated documentation.

Blueprint also supports linked processes. This means you can create a 'sub-process' which has a number of repeatable steps and then add that process to a diagram. Sub processes can be shared between diagrams making this a nice little feature to have.

Once you are happy with this you can select the documentation view

Documentation
This view allows you to take your input and create PowerPoint or word slides from it. The screen changes to display a simple structured layout for the data you have entered. Behind this is also the additional data and information you have entered in the process discovery phase. From here there are icons to output to word or to Powerpoint. The Powerpoint output is predefined and the template used to create this can be modified within Powerpoint itself. There is no facility to format the output prior to it leaving Blueprint.

I was deeply disappointed with the Word document layout. It appeared to be a fairly simple graphic dump of the data into a word document with minimal attempt to structure or format it appropriately. The data is also dropped in as a read-only table which may not be to everyone's taste.

Reservation: I'm not sure how this will work for very large diagrams (which, of course, you should never have) or for diagrams that drill down to multiple levels of detail. Can you have 4 or 5 levels of drill down?

Summary
Ultimately the driver behind this is that the end users can create and manage their own process diagrams whilst then allowing the final output to be fed into the Lombardi Teamworks tool to actually build processes to support the processes being modeled. If you are not using the Lombardi Teamworks tool there is still a great deal of benefit in using something like this as a means of capturing data from your users. Getting data out of the tool would then be something that would need to be considered as I couldn't identify either an XML output or a BPML type output so that this could be used as a source for third party applications. I would certainly encourage anyone with the Teamworks tool to look at using this for their process discovery. It is quick, simple and reasonably sophisticated. The linkage with Teamworks makes things useful. If you aren't using Teamworks but still want a swish process discovery tool, this is a useful one to have. My reservation about the transfer of data to third party apps still stands though.

Click here to go to Lombardi's website and sign up for a blueprint account.

Thoughts from The Project Challenge conference

Image by Cappellmeister via Flickr

I spent some time yesterday (March 25th) at the Project Challenge conference in Birmingham's NEC.

Project Challenge is a free conference focused on projects, programmes, process and resource and takes place twice a year in March and November. It has a number of focus areas (as detailed on the web site) and I was there following an invitation to present in the Process Performance Zone.

The beauty of this sort of conference is twofold:

1. It is free to attend. There is no cost to attendees (although companies who are exhibiting have a cost for their stands which covers overheads for the show as well), which basically means the opportunity cost of attending is restricted to a day or two of your time and, maybe, an overnight stay in a local hotel
2. There are, literally, dozens of seminars, presentations and discussions taking place over the two days on such varied topics as Putting Process at the Heart of the Organisation, Five dimensions of professionalism and Do you feel confident? - Applying Risk Analyses Techniques to Project Management. This means that the wide spread and varied subect matter should be to everyone's taste

Alongside this there are several exhibitor stands showing products related to project management, process management and training.

I was in a conversation with Mark McGregor (who is involved in the organisation of the conference) and he was mentioning, though, that one issue they continually come across with these conferences is the reluctance of major BPM vendors to be involved in either exhibiting or sponsoring. After a couple of moments of discussion we came to the conclusion that it is because they vendors are probably unsure of how to pitch their products to a room full of non-IT individuals.

Basically when vendors pitch to projects it is usually an IT focused group that are involved. The vendors talk about the functionality, the user interface, the import and export functions and the cost. there tends to be very little discussion of some of the less tangible deliverables such as 'what can this tool do to help me improve my ROI?', or 'How, exactly will this help me as a financial accountant' do my job better?' It was an interesting point of view and one I will be putting to a senior director of a BPM vendor next week in a discussion I have planned for her.

My presentation went well. I was discussing 'Implementing Business Process management by Stealth' to cover situations when a company wishes to build a business process capability in their organisation but doesn't have senior management backing. Initially I was concerned about the level of attendance as the discussion ahead of me had only 6 people attending (one of whom was actually a colleague of the presenter from the same company). In a room that seated about 70 that was a bit discouraging. Luckily as the time for my presentation approached the seats started to fill up until I had upwards of 60+ folk waiting to hear me speak.

My thanks to all those who approached me after the presentation and for the discussion that ensued. Thanks also to Kate for looking after me while I was there.

The Dangers of "Getting Used to it"

Craig over at 'The Process Ninja' has a great little post about the dangers of 'Getting used to it'

As he says:

It's easy getting used to something not being quite right, but we have to continually challenge and question the way things are done. Continuous improvement is all about setting up regular reviews where we need to ask some hard questions. Don't be afraid to tear up a process and start again

I think it's important for people to try and understand that just because you are in a 'comfortable' mode with the way you do something it doesn't mean that it's always the best way of doing it. Nor does it mean that you can't find a different, more efficient way of doing it

Head over to The Process Ninja blog and see if there's something there you recognise in his post

Ryanair's process issues.

Image via Wikipedia

A couple of months ago over on the 'Flying Cafe' blog, I wrote a post about what I considered to be a misleading airline ticket pricing strategy. The airline - Ryanair - had advertised a 'free flight' which ultimately could have cost me as much as £105 including taxes and the 'additional charges' they levy.

This follows a discussion on the Linked-In Business Process Group where Steve Towers was positing that Ryanair's business model had improved as a result of a proposal to remove check-in desks at the airport. He called this the removal of a 'Moment of Truth' in the process. I argued against this saying that Ryanair may have a cost saving business model (although their profit percentage has decreased steadily over the last 3 years despite rapidly increasing revenue), but as a model for creating satisfied customers it leaves a lot to be desired.

Well this week I actually took the flight and I wanted to post a few thoughts on some of the process issues I picked up whilst flying with them.

I checked in at Bournemouth Airport for a flight to Southern Spain. I had one bag and a set of golf clubs. The bag had been paid for as part of the check in (an additional charge over and above the original ticket price), but the golf clubs had not. The process was as follows:

* Queue up
* Give details to check-in lady
* Show passport
* Check one bag in
* Take second bag (golf clubs) round to another desk
* Queue up
* Give details to second check-in lady
* Pay for second bag
* Receive confirmation slip/receipt
* Take second bag (golf clubs) back to first desk.
* Queue up
* Give confirmation slip/receipt to first check-in lady
* Receive boarding card
* Take clubs to a third check-in area
* Show boarding card to guard behind glass screen
* Drop clubs on conveyer belt - hope they get treated well and arrive at destination.


16 steps including three queue's to check in one bag, one set of clubs and receive a boarding card. Multiply this by 180 people on a plane (although not all of them will have additional charges to pay) and pretty soon you can see the issue with this particular process. Compare this with a similar flight I took to the US a couple of years ago:

• Queue up
• Hand passport to check-in lady
• Put bags on belt
• Select 'Aisle' or 'window'
• Receive boarding pass
• Drop clubs on an oversized baggage belt nearby

As you can see this was significantly less hassle and more efficient.

Of course looking at this from Ryanair's point of view there is no efficiency to be gained by changing the process. There is no financial gain to them, merely improvement in their customer service. However Ryanair have made it perfectly clear that their priority is extracting the maximum amount of revenue from each customer rather than providing a peaceful and efficient service to them. Therefore a change to the check in procedure would not benefit them at all.

If you would like to see my overall thoughts on 'The Ryanair Experience' then click here.

For those of you who know about these things, is this similar to the modus operandi of Southwest Airlines or do they tend to go more for customer service as well as cheap fares?

The benefit of BP(m) in today's market

The BBC has an interesting article about some of the challenges facing Hertz Car rental in the current environment.

One of the more interesting facets of this discussion is how Hertz themselves reduced costs and improved service by simply looking at one facet of their operations and improving the business process surrounding it.

Simply stated, they removed the large buses which circulate Heathrow Airport and pick up people from the terminals to take them to the off-site rental location. These were replaced with smaller 'mini-bus' type vehicles which visited one or two of the terminals at a time and then returned with their passengers. This simple move reduced journey times between the terminals and the rental facility by 50%.

For Michel Taride, president of Hertz Europe, the restructuring of the bus service at the Heathrow branch is an example of the "speed and depth of the transformation" Hertz is going through.

"We are proud to have done a lot of what companies are now forced to do while we were in good shape," he says, explaining that staff members are being urged to get involved in planning and improving how work is being done.

In addition to this, staff have changed the way they work as the company has adopted the Japanese Kaizen management philosophy that aims to eliminate waste by standardising processes. In addition to this they reckon that Hertz (and presumably other rental car companies) could benefit from greater automation in the area of processes and paperwork. This, again, will reduce costs and improve service.

This philosophy by Hertz is a prime example of the benefits that a company can achieve by looking at how they manage and operate their business processes. One very famous (although slightly tangiential) example is American Airlines. They discovered several years ago that by removing one olive from every First Class meal they could save $40,000 per year. The service is not reduced at all and the benefit hits the bottom line instantly. Of course, $40,000 on a company with the turnover of American Airlines is minimal, but it is an example of how a litle bit of thought can bring great benefits to companies.

In these times of cost cutting and belt tightening, it is incumbent on companies to try and get the best out of their existing assets and to look at ways of reducing waste, increasing efficiences and 'doing more with less'.

Any examples you have come across of a 'simple' change that has reaped large benefits?

BP(m) - It's the BUSINESS, not the technology

I recently talked about a comment made by the late Dr Geary Rummler ("The father of the swimlane") where he said that BPM conferences were becoming more about the technology than anything else. The last few Gartner conferences that he attended 'looked more like vendor showcases' than serious business conferences.

In a related conversation I was part of with Theo Priestley ("The Process Maverick") from Touchworlds, we were discussing evaluation criteria for BPM software and he was always amazed how so many criteria were technical rather than business related.

Personally I am aligned with both of these perspectives. Many people (and organisations) when they start to look at reviewing/updating/or creating their business processes look at some sort of tool to support and manage this. As soon as a tool is brought into the equation the project starts to become an IT project and the business, somehow, becomes secondary.

I actually put a lot of the blame for this squarely at the foot of the business. They tend to abdicate a lot of responsibility when it comes to IT because they see IT as being 'a necessary evil' to help them get things done, but about which they know very little.

I'm here to tell you that's just plain wrong. Not only is it wrong, it's stupid. (I'm an ex-IT guy here so I kinda/sorta know what I'm talking about).

Remember that IT as a function would not exist without a business to support it. There are no completely IT based businesses in existence. Even Microsoft is a business about IT rather than an IT business. Same for the small company at the end of the street that exists to help you repair and upgrade your desktop PC at home. It is still a business (albeit one that has IT at it's core).

What this means is that the IT function cannot exist in a vacuum and must be integrated with the rest of the business to be able to add value. Implementation of the package you purchase to help manage your business processes must be run as a business project which has IT involvement rather than as an IT project. I've seen it too many times in organisations: They bring in the IT folks (usually including me..) then completely abdicate responsibility for being involved. It suddenly becomes 'an IT project' and the business develops selective blindness and selective hearing when it comes to being involved "I'm sorry, we can't help you with that this week it's our month end process and no-one is available", "I'm sorry, the user you want to speak to who has all the knowledge of that process is at a two day offsite team building meeting so you'll have to wait until she comes back". The excuses start to mount up and pretty soon the IT project will either fall behind (incurring the wrath of the 'user's who are waiting for the project to finish) or the IT function will start to make decisions about things such as functionality which the users should be making. Either way you're on a hiding to nothing

So how should a BPm package be implemented?

Firstly make sure that this is positioned, run, and managed as a business project. The business must drive it, the business must own it and the business must take responsibility for it. IT, of course, should be involved - especially if there is a package being implemented - but they should be subservient to the business project (Naturally IT could look upon this as a large, internal IT project and treat it as such, but in the context of the overall project their part is merely a sub-set).

Secondly: look at this from a business point of view. Make sure the business is driving the requirements. Choose your BPM tool based on business needs rather than IT needs (See this post for more on selection criteria for BPM tools). Of course you need to consider all the criteria suggested in the text and associated comments of that post, but primarily this should be regarded as a business decision using business criteria. Anything else will result in sub-optimal results. Driving this from a business point of view will also gain better traction with the user base. They will feel more connected with the resulting application and, hopefully, they will use this to best effect when looking at the design of their new processes.

To summarise: Treat your BP(m) implementation as a strictly IT project and you risk alienating your users and delivering a sub-optimal solution. Include them in the process, let them lead the project, and the benefits will increase exponentially.

A lot of the items discussed here (and more) are touched upon in my eBook 'The Perfect Process Project'. More details on this can be viewed here.

---

For more about me check out my "About Me' page

All information is Copyright (C) G Comerford

Comments on 'Criteria for Choosing your BPM Tool'

There are some interesting comments being added to the discussion on 'Criteria for choosing a BPM tool'

If you haven't already read this post it might be worth spending 10 minutes looking at it. If you have already read it you might want to look at the comments and see whether they match your own criteria...

Feel free to add your own.

---

Reminder: 'The Perfect Process Project' is still available. Don't miss the chance to get this valuable insight into how to make business processes work for you.

Click this link and follow the instructions to get this book.

---

For more about me check out my "About Me' page

All information is Copyright (C) G Comerford

Raiders of the Lost Process

Image via Wikipedia

Sometime in the mid-1980s three gentlemen sat down in a room in Southern California and held a "facilitated session" to design a new product they were looking at. Each of the gentlemen in the room had had success designing similar products in the past and it was felt that combining the expertise of all three of them would result in a world beating product. They were correct - the product they designed went on to become one of the bestselling products in its market. But we'll cover that in more detail later.

Recently a document has been released which details conversations that took place in that room in California back in the mid-1980s. Having read the document I was pleasantly surprised at how similar their session turned out to a standard process facilitation session, of which I have run many. Of the three people in the room one was quite obviously "the leader". He had very firm ideas about how he wanted the product developed but, at the same time, he was willing to listen to the views of the other to gentlemen in the room. Of the other two gentlemen in the room, one of them was obviously very experienced in his particular field of endeavour. The other one had a very particular skill which, though not apparent in the end product, was actually a key component of the process.

The three gentlemen in the room were: George Lucas, Steven Spielberg, and Larry Kasdan. The product they were creating was "Raiders of the Lost Ark". I fully recommend any movie buff to spend a couple of hours reading through the 126 page document to understand the thought process that goes behind creating a blockbuster movie. It is very enlightening.

But that isn't the point of the post. What I want to talk about in this post is the process of facilitating a session such as this. I'll do this by making reference to certain incidents which occurred during the story conference for "Raiders of the Lost Ark".

George Lucas, the boss, had decided in his own mind that he was going to make a movie which was based on the old 1930s republican serials. He wanted a sympathetic hero, lots of action, and cliffhangers every ten minutes or so. Stephen Spielberg, the wunderkind director coming off Close Encounters of the Third Kind, was anxious to make sure that the movie have lots of visual appeal for the audience. Lawrence Kasdan, the writer, was interested in producing a screenplay which had good characters, good plotting, and would make a good movie. In theory the three individuals in the room had everything needed to create one of the highest gross movies of all time. This, indeed, is exactly what they did.

Reading the transcript of the session it is obvious that Lucas is driving the process. He has gone into the session with an almost fully formed idea about the story and the various plot points. Spielberg spends most of the first third of the session listening, with only the occasional clarifying question. Kasdan says very little. However, once the overall plot is laid out (a plot which will subsequently change very little) both Spielberg and Kasdan start to interject their own thoughts and comments into the narrative. Lucas, anxious to keep his vision intact, does initially responded with counter arguments, if only to later realise that the expertise of the other gentlemen in the room is improving the end product whilst still adhering to his initial vision and concept.

What is also interesting to observe is a few of the cycles that the group go around. One of the discussions concerns "the girl" (who later turns out to be Marion Blackwood in the movie) and how she should be portrayed. She was initially identified as being a "double agent" and everybody agreed that this was a good idea. But, as the discussions developed, she moved away from being a spy and more towards being the genuine love interest. This parallels the kind of discussions a lot of groups have during process facilitation session's where an understanding is reached about the function of a particular activity or task within a process, only for this understanding to be changed at a later point when further information comes to light.

Another interesting phenomena from the session was the introduction of plot points which would not used at this point but were recycled later. An example of this is the love interest being a spy, as mentioned above. This plot device was used in the sequel to the movie "Indiana Jones and the Temple of Doom". During process facilitation sessions it often happens that somebody will throw something into the mix which appears to be relevant to the conversation, and can be pursued by the participants for quite a while, before the group comes to the realisation that this is not a relevant topic of discussion and it gets shelved. However, the mere fact that this has been discussed does raise the profile of a particular activity, and identifies the fact that it can't be ignored and has to be placed somewhere within a process flow - even if that is not the process flow currently under discussion.

Now let's try reconcile his back to standard process facilitation criteria. If you read my post on facilitating a process session, I make reference to a number of key criteria: Get the right people in the room: Go around in circles: Capture everything. From the three paragraphs above you can see that in this particular instance the right people were put into the room (Lucas, Spielberg, Kasdan), they did go around in circles (the discussion of the girl), and they did capture everything (the mere fact that this document exists as a reference indicates that everything was captured, and was later used in the subsequent movie to identify some of the set pieces that appeared there). In addition to that I talk about taking a lot of time, and it is obvious from reading the discussion (which was transcribed from a number of audio cassettes) that the three individuals concerned were in no hurry to rush to a conclusion.

I also talk about making sure you understand terminology. There are several occasions in the conversation when Kasdan and Spielberg ask for clarification from Lucas about phrases or terminology that he has used. A lot of this surrounds the actual Ark of the Covanant itself, where Lucas has obviously done some research and knows more about the mythology of the Ark than the other two gentlemen in the room.

So, my question to you, is: if the three of the greatest filmmakers in the world use process facilitation techniques to create a blockbuster movie, why don't you use them to help define your processes?

---

Reminder: 'The Perfect Process Project' is still available. Don't miss the chance to get this valuable insight into how to make business processes work for you.

Click this link and follow the instructions to get this book.

---

For more about me check out my "About Me' page

All information is Copyright (C) G Comerford

An Apology...

This post was originally going to be the outcome of a discussion I had had with a Director of Strategy at one of the largest BPM vendors globally.

However, due to various circumstances out of my control the interview has been rescheduled and now postponed. Or maybe it has been cancelled. I am working through a third party intermediary to get this organised and it is proving extremely difficult to pin down the status.

I am of the opinion that as this intermediary hasn't responded to a note I sent over a week ago asking for clarification then the meeting is cancelled.

However should the meeting actually end up rescheduled I will, of course, bring it to you as soon as possible.

My thanks to any of you who answered my recent call for question to pose to this Director. I am sorry nothing has come of it yet.

---

Reminder: 'The Perfect Process Project' is still available. Don't miss the chance to get this valuable insight into how to make business processes work for you.

Click this link and follow the instructions to get this book.

---

For more about me check out my "About Me' page

All information is Copyright (C) G Comerford

Your criteria for choosing a BPM tool?

Image via Wikipedia

When you want to buy a BPM tool, what are your evaluation criteria?

I am monitoring and participating in a discussion on Linked In about the criteria people use to choose a BPM tool. There are a couple of interesting points that are surfacing.

The discussion involves a couple of vendors and a couple of consultants. This, ideally, gives both sides of the discussion : what do the vendors think is the ideal criteria and what do the consultants think is ideal based on their interaction with the customers?

Initially a vendor identifed 10 points as potential criteria:
1) Provides process execution and state management
2) Offers model-driven composition environment (product modelling studio)
3) Interacts/integrates with EDMS and CM
4) Enables collaboration
5) Integrates with other apps (SOA)
6) Enables BAM and event-based notifications
7) Provides simulation and optimizaton
8) Includes business rules engine/capabilities (e.g., roles, responsibilities, policies, procedures, approvals, deadlines, integrations, etc.)
9) Provides overall admin, security
10) Provides a registry for process components

Fundamentally there is nothing wrong with these criteria. However that same vendor indicates that the ACTUAL questions that customers ask are:

- Is it easy to use for my developers, business analysts and users?
- Does the product really work? (Does is have a good modelling environment? Can I easily create forms and ties those forms together with the workflow model to launch applications? How configurable is it?)
- How are other companies like me using the product? Have they had success?
- How fast can I get something implemented?
- Is it the right price?
- Does your company and/or partner have experience developing/deploying applications like I need?
- Is your company strong and well positioned to succeed over the long run?

Again I like these criteria. They seem closer to real-life issues and questions than a hypothetical list of criteria that a vendor would like a customer to ask.

One respondant (again a software vendor, but focused on the Open Source arena) identified the following 5 criteria from his market research:
1. license price
2. maintenance price
3. implementation costs (what fits some of the criteria you mentioned)
4. vendor locking
5. user basis

This is interesting because, of course, he is looking at a cost or price bias when dealing with his customers.

I suspect that in an ideal situation customers should be focusing on getting a tool which is both suitable for their needs, easy to use, well supported and well priced. I think they realise that - at the end of the day - a BPM package is not necessarily distinguished by its functionality and cost but more by the ability of that tool to fit the needs of the job it is being supplied for. After all if there was one 'best tool' in the BPM space it would dominate the market to such an extent that Gartner would not need to produce a Magic Quadrant every year or so. The current MQ indicates that the market is quite tightly bunched around the central point of the 4 quadrants with a few minor outliers. This indicates to me that either all companies are looking for a similar thing (and the vendors are catering for that) or the market is so widely spread in terms of user requirements that the software has developed to be general enough to deal with most of these requirements. I suspect it's a combination of both

What are your five main criteria for choosing a BPM solution?

---

Reminder: 'The Perfect Process Project' is still available. Don't miss the chance to get this valuable insight into how to make business processes work for you.

Click this link and follow the instructions to get this book.

---

For more about me check out my "About Me' page

All information is Copyright (C) Gary Comerford

2 Interesting developments from the "Process Cafe".

Image via Wikipedia

A couple of items came across my desk today which I wanted to pass out to you, my readers:

1) A Virtual Business Process Conference
I am linked in with a group of individuals who are looking at the concept of merging virtual environments with the world of business processes. There are a number of underlying reasons for doing this, but one of these is to allow processes to be designed and prototyped in a virtual world. The prospects are quite exciting. The group itself - under the leadership of Theo Priestley - has started things moving by creating a virtual Business Process Conference. The conference is called Process 2010 and will take place in March next year. This BPM showcase offers the most up to date insight on business process strategy and operational agility and will feature process excellence studies and successes across all industries, Workshop tutorial sessions and Keynotes on both old and new methods, and looking at advancing process management using new combinations of techniques and tools such as GIS (Geospacial Information), Workflow Artificial Intelligence and Virtual World Process Simulation. So why 'virtual'?: as Theo say's:

In today’s current economic climate, cost reduction is king. What better way to reduce over-burdening costs for flights and accommodation as well as the attendance price than to remove them entirely. No need for ‘justification’ kits or lengthy arguments on ROI.

By far the two biggest advantages are that (a) with the price of a single ticket, you can broadcast your attendance within your organisation so more people can actually gain advantage of keynote speeches, presentations and workshop sessions. You’ll be assigned an Avatar per attendee thus increasing the scope for coverage should you purchase more than one ticket and (b) Sponsorship and marketing packages not normally within reach of smaller organisations can now be accommodated and advertising space can be reserved according to your budget available.

Networking is obviously another great usage of the world space, and with the ability of Skype you can hold private conversations without finding a huddle space in a dark corner of the bar.

Holding this event in a virtual world brings other advantages:

• Reduces travel time, expenses, and headaches
• Removes the need to reserve blocks of hotel rooms
• Weather conditions are no longer a factor (it’s always sunny in a virtual environment!)
• BYO food and drink, convenience breaks to suit you not everyone else.
• No long walks between presentation and exhibit locations: Avatars can teleport and fly (don’t worry, you’ll be taught how by our hosts)
• No lines at the toilets or the bar….

If you are interested or want more details click over to the conference page here and register as either a participant, a sponsor or a speaker. I am very interested in this and am fully intending to either speak or participate when the time comes.

Image via Wikipedia

2) An Amsterdam based TOGAF Training course.
PROMIS Solutions from Switzerland are holding one of their regular TOGAF training courses for those of you interested in Enterprise Architecture and this time it is in Amsterdam. As this will be the first course they have given in the Netherlands they have decided on an introductory fee of 1.400 EUR for the 5 day course including the Open Group certification cost. This is excellent value for the course. The course runs from 11. May until 15. May (five days). If you wish to participate then please check out the Pro-Mis training web-page and contact them directly. Mention GCP Consulting to make sure they know how you heard about them.

(After registration you will receive a course confirmation, the invoice and detailed information about the location as well as on transformation and lodging if required. Payments have to be credited to the account at the latest four week before the start of the training course. Training courses can be cancelled until four weeks in advance without any charges. For cancellations less than four weeks in advance 50% of the training course price will be due, if no acceptable replacement can be found. For cancellations on the day of training or non-attendance the total training fee will be due).

The Hole in the system

Image via Wikipedia

One of the things that people are very prone to do with processes is to leave some sort of a 'hole' in the system.

I was reading one of the multitude of blogs I read daily when I came upon an excellent post from Havi Brooks at The Fluent Self. In this post Havi was talking about 'The hole in the system'.

Basically, she explains, most people define 'systems' around themselves but leave some sort of a hole in there which causes problems later on.

Specifically she gives 3 examples:

1) "The baby-bathwater thing": Which is where systems are in place but are subverted because of some emergency situation
2) "The misguided assumption thing": Which is where systems are bypassed based on assumptions that would not have been made had the system been followed
3) "The 'not allowing for stuff going wrong' thing". Where systems only account for the ideal situation to occur and are not designed to cope with occurrences where things don't happen as designed.

What struck me about the post (and the three examples quoted) is that they are pretty universal - especially when applied to business processes. When I look at processes in place in business today they tend to be designed from the point of view of 'this is what should happen' rather than 'this is what can happen' it's a subtle difference, but very important.

There are, of course, whole industries that have sprung up to deal with the different scenarios detailed above - things like decision management systems for example. But am I the only one who thinks that it might be a good idea to design your systems correctly in the first place? How many times have people fallen into the trap of designing a business process - for example - to match a specific piece of software functionality but then suffered when that software can't cope with a customer who comes in with an emergency (The 'baby-bathwater thing')? It happens all too often. This is not to denigrate business decisons systems at all, but merely to look at specific probems through a different prism.

I am a firm believer that processes should be designed to be tool independent. That way when you change your underlying ERP or CRM system (for example) you don't actually need to redesign your processes. Havi says:

It seems to me as though most challenges that tend to come up in these situations have two sources.

Maybe the system is flawed. There’s a spot where things get stuck, jammed, or fall through and get lost. Or a great system is already in place, but we’re just not using it. Which is the flaw.

Fundamentally Havi is speaking of the two bugbears that dog any system's implementation: Putting in a system that works but isn't used correctly or putting in a system that doesn't work correctly.

So how do we solve these two problems?

I would say we don't.

Or, more particularly, we can't. It is fundamental in human nature that we seek the easiest solution. Generally the easiest solution is that which needs the least amount of work, or that which produces the ideal result the quickest. This can be the kind of thinking that produces systems that don't work correctly. Alternatively we can spend time, money and effort in creating virtually foolproof systems only to then have the users bypass these systems when an 'emergency' arises. But let's also look at the opposite side of that equation. How many time have you rung the bank, or some other 'call centre' system and asked them to do something only to be told that 'the system won't let us do that'? This is an example of a system that has been designed to work in one way but which we now want to subvert by not following the process. The well designed system has had safeguards built in that will not allow you to do anything like this. But at the end of the day you end up as a dissatisified customer. So is the system working correctly?

Yes it is. It is working absolutely as designed. But is it working in the best way for the customer?

I don't think so.

Perhaps the solution is to make systems more flexible? Maybe we need to try and ensure that users can perform the tasks they wish (regardless of what those tasks are) and then manage the fall-out using something such as decisions or rules based systems. But somehow I can't help feeling that this is tantamount to creating another 'hole in the system'

Thanks to Havi for the original post.