A hypothetical BPM business case …

Ian Gotts wrote a great post in which he discusses a hypothetical business case for BPM. Ian is a proponent of well-documented processes (as his product Nimbus provides). His post fits well into the theme of my last two posts and thus I want to share with you my comment on his post also here.

Ian writes in his post:

“If you have poorly documented and followed processes, you won’t even be able to identify the potential costs downstream – let alone measure them. (Note processes must be documented AND followed to be valuable) So, like the iceberg, you only see a small part of the problem. Assuming an iceberg is a problem is looking at an iceberg from the Titanic’s rather than the penguin’s perspective.”

YES, a process that is not documented can’t be measured because it doesn’t exist. But the question is how one can measure the improvement of something from not existing to existing. Especially if it is utterly abstract. I just wrote a song and it is now much better than before I wrote it? Hmm … What can be measured is how bad the first process implementation was as it certainly isn’t what people did before. The only relevant measure is the actual outcome (or customer experience in a free market business). Achieving the same or better outcome with less effort can reduce costs but that does not require a defined process either. It requires transparency and understanding and maybe some constraint rules.

“So to illustrate my point, I received a letter a few days ago from HM Revenue & Customs, the UK equivalent of the IRS. A largish organisation with some 100,000 employees dotted all over the UK.”

CLEARLY, it is obvious that processes in government are driven by legislation that even the government people don’t understand. I am sure that is not the way any free market business wants to operate. So process governance is normal to public servants … they are trained not to think, but just execute as defined. The result is the following:

“So one small process error (not testing the application correctly has spawned:
–    A badly letter written, proofed, printed and sent to 10,000+ of people
–    A spike in hits on website to get phone details
–    Calls to call centres and local offices
–    Back office process to log and action my confirmation”

ABSOLUTELY correct that processes are really about content – the letter that was sent out and the form you might need to fill (web or paper does not matter). So process flows alone are irrelevant and don’t improve the process if there is no content or it is not managed as integral part of it. In fact, if you manage the content and its state – PRESTO, you have a process. No flowchart needed and people understand it without ever looking at a diagram. (Yes, a flow can be used for simple one-at-a-time content state changes … let’s not argue).

YES, the process does not end when the letter is sent. As it solicits a response it could actually be an email with a hyperlink to a webpage. But even that response has to be handled properly. As much as governments would like they will find it hard to treat people as numbers and shear across them with the same flow-diagram. In the end that doesn’t work. People are people. Call centers with automated answering scripts and automaton-operators don’t work either. Why not empower public servants and citizens to collaborate freely (bound by some rule constraints, obviously).

“And the people best placed to identify the problems and recommend the best solutions are those at the sharp end, on the shop floor, at the grass roots. You know.  The ones who are the lowest paid people in the company.”

YES, I could not agree more that the people who have the knowledge are the ones at the grass roots on the shop floor. I am not sure how more often I must say that we need to empower them by allowing them to work unrestricted from flow-diagrams, but helping them to focus on process goals. Especially if letters have to be sent out to a large number of people and many of those letters are ONE-TIME letters, making sure that they are designed and sent consistently is key. Creating a flow-diagram won’t help. Enabling collaboration on the letter design and sign-off by the legal people, supervisors and experts becomes essential and ensuring that the letter will be sent exactly as designed to the right people at the right time is the software trick needed. BPM doesn’t do that.

“Assuming a salary of £10,000 and 200 days worked per year the loaded cost is £55 per day.

So the original process cost of £6.88 vs the option HMRC selected which is £37,93.

How many little process issues cause internal problems and then have a convoluted, wasteful and ill thought-through processes to correct them.”

I am in agreement with Ian that ‘processes’ as above can be improved by using software. I just do not see that this situation would be improved by designing a BPM process flow. The argument that documentation improves the understanding of downstream cost consequences is without basis. Therefore the ROI that Ian attributes is truly hypothetical. It is an assumption and no more. I propose that the ROI will be achieved by empowering people (which even works for government employees) and not by encoded processes.

I am the founder and Chief Technology Officer of Papyrus Software, a medium size software company offering solutions in communications and process management around the globe. I am also the owner and CEO of MJP Racing, a motorsports company focused on Rallycross or RX, a form of circuit racing on mixed surfaces that has been around for 40 years. I hold 8 national and international championship titles in RX. My team participates in the World Championship along Petter Solberg, Sebastian Loeb and Ken Block.

Posted in Adaptive Case Management, BPM
One comment on “A hypothetical BPM business case …
  1. […] Process and Documentation – Max J. Pucher YES, a process that is not documented can’t be measured because it […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Max J. Pucher

Max J. Pucher - Chief Architect ISIS Papyrus Software

© 2007-17
by Max J. Pucher. All rights reserved.
Real World Statistics
  • 216,893 readers

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 9,038 other followers

%d bloggers like this: