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

Related Posts by Categories



Widget by Hoctro | Jack Book
For blog comments policy see this post
blog comments powered by Disqus