Over the years, business process modelling has, at various times, been a big part of my life. From using a pencil, paper and stencils to draw process diagrams in the mid 80’s, through pushing the first generation of CASE tools to their limits, I eventually got into modelling environments from vendors such as Rational, Select, Protosoft and Casewise.

Along the way, I read most of the books, practised (or at least experimented with) many of the methodologies, and from time to time have preached the gospel according to one guru or another.

While a bit of an old cliché of a publication now, one the books I related to the most during the 90’s was Michael Hammer’s “Reengineering the Corporation”. This was because I had spent so much time as a business analyst uncovering poor or outdated processes then running into resistance in the form of dogma, politics or just plain old inertia when trying to persuade people that processes should be changed. Hammer’s book helped by legitimising the whole idea of challenging accepted wisdom in the quest for business optimisation.

The other thing it did was point out to the masses that it’s the business objective that matters the most, and I can’t help thinking of this principle when I read the numerous articles that have been appearing recently that put the business process as the pivot point for everything. I guess if you are an engineer and have grown up with a systems background and mindset, this is progress, but it’s still missing the point as any practising business analyst worth their salt will tell you.

This might sound like I am being picky—after all, modelling processes is an integral part of any business analysis exercise. But if you lose sight of the fact that addressing business objectives and achieving the right business outcomes are the real measures of success, you can easily end up perpetuating bad practices or missing opportunities for improvement. This is relevant to discussions around outsourcing, implementation of software packages, SOA, Web 2.0 and the exploitation of many other emerging technologies and ideas.

Focussing on outcomes, though, sometimes throws up some surprises. I had an interesting conversation, for example, with the CIO of a large global hi-tech manufacturing company a few weeks ago. When I asked him what the biggest initiative was within the company right now he said it was replacement of their old SAP system. When I then asked what it was going to be replaced with, he said “SAP”.

The logic behind this was that when the original system was put in, they ended up customising it significantly to match their existing business processes. Ten years down the line, this has translated to high maintenance costs, lack of flexibility and the customisations being an impediment to keeping the system current and up to date with the latest releases from the vendor.

However you might think this reflects on the nature of the SAP solution, the CIO in question said that one of the biggest lessons the company had learned over the past ten years was that you should not be a slave to the notion of there being a single “right” or “best” process for getting something done. There are usually more ways than one to skin the proverbial cat.

Given this, he told me the philosophy with the new implementation is to adopt standard SAP processes wherever possible, on the basis that a) they are now very configurable, b) tweaking the way you do things is often less costly and risky than paying a consultant to modify standard application functionality, c) it’s going to be cheaper and less hassle in the long run from a maintenance and upgrade perspective, and d) standard processes from a vendor like SAP are likely to reflect industry best practice anyway. Of course there will be areas where it makes sense to deviate from the standard, e.g. for competitive reasons or because the cost or risk of adjusting the process is prohibitive, but the message was to think of these as the exception rather than the norm.

This mindset and approach, which is clearly focussed on the most efficient way of achieving the desired business outcomes, is much more mature than all of those out there who seem to be obsessed with the nirvana of ultimately flexible applications that are able to shape themselves around whatever esoteric processes you might invent. As the guy I was talking to pointed out, if you are executing some routine accounting or administration process differently to the tens of thousands of other SAP customers out there, you have to ask yourself why—and maybe even be a little concerned.

At the other end of the spectrum, trying to apply too much process oriented rigour in those fast moving environments at the edge of many businesses can be an impediment to the creation of business advantage. Technologies like SOA, portals and mash-ups are destined to empower users in driving the business forward in innovative and ever changing ways, and if such activity leads to the kind of results we want, and the appropriate controls are in place to deal with things like security, privacy and compliance, who cares if the processes don’t stay still for long enough to be mapped in the traditional manner.

So, counter intuitive though it seems, using business objectives and outcomes as the pivot point for your thinking can lead equally to the adoption of canned processes from the likes of SAP, and the embracing of relatively unconstrained Web 2.0 and social computing ideas.

From a practical perspective, the lesson is to keep your eye on the ball and not get too obsessed with trying to analyse, model and re-design everything from first principles for the sake of it. In many areas it just isn’t worth it, and in others, the model will never keep up with the business.