Why End Users Love BPM

Where I used to work (a big, now defunct, financial services firm), we automated everything.  In the HR category, we had online, web-enabled processes for time reporting, employee status change, leave requests, bonus calculation, expense reimbursement, and on and on and on.  On the operations side, we had similar online support for PO processing, invoice generation, ordering supplies, and so forth.

You might think that, with all this automation, we were extremely efficient.  Unfortunately, exactly the opposite was true.  Not only did these apps fail to save me any time:  they weren’t really intended to.  Each had its own look and feel, its own data sets, its own supporting team of programmers and SMEs. 

For example, rather than sending HR an email that said, “John X. is transferring from the IT operations group to the systems analysis group,” or something like that, I had to navigate my way through one of the most non-intuitive, confusing, and clunky user interfaces ever designed.  Because this same system was used for a number of HR-related tasks, over the course of my career I spent countless hours hacking my way through a jungle of a UI to complete simple administrative procedures. (Of course, delegation was rarely an option.)  Worse yet, often I ended up having to work with somebody from HR anyway, as they had to jump in to either fix something I’d done wrong, or to bridge a gap in the system itself.

Think about your company’s new employee on-boarding process.  Is it smoothly efficient, built intuitively from easy-to-use components?  Does it cover all aspects of the task, handling approvals, hand-offs, and dependencies in an elegant and transparent manner?  No?  How about invoice approval?  How about expense reporting?

The fact of the matter is that companies are still, in the words of Nobel laureate Arno Penzias, running errands for their computers when the computers should be doing the work for them. We purpose-build systems from scratch, or acquire narrow, off-the-shelf point solutions, when we ought to be devising a general solution that can be applied to the array of processes that businesses run through each and every day. This is the promise of BPM.

It’s also BPM’s best-kept secret.  Ask an average user what BPM is for, and they’ll tell you that it’s for automating manual processes.  The more sophisticated among them might point out that their BPM solution provides a platform for modeling processes and connecting those processes with the data that drives them. 

These are all good answers.  But I suspect that, for the vast majority of corporate end users, the real benefit is more straightforward:  BPM offers a consistent, understandable, and transparent mechanism that is reused over and over again to navigate a wide variety of processes.  The end user can, quite simply, do her job, liberated from the training, troubleshooting, and hair-pulling associated with any large set of unrelated applications.  And, in the end, getting the job done is what BPM is all about.



Advertisements

8 responses to “Why End Users Love BPM

  1. Are you a business user suffering from death-by-a-thousand-apps? I’d love to hear from you! Comment here, or drop me a note at scott.menter [at] bplogix.com!

  2. This was great, and I immediately shared it with a couple of clients. The Arno Penzias line about people "running errands for their computers" was perfect for a situation I’m currently dealing with. The whole series "Why XXX Love BPM" has been great, and I’ll send the collected links out to more clients. I’d say it was worth the price of admission, but the price was "free" – beautiful!Thanks,Alec

  3. Thanks Alec! I’ll definitely agree with one point: Theo is providing a great service by supplying a platform for these discussions.Arno Penzias is an incredible individual, and I, too, refer to the "running errands for our computers" idea frequently. His books are definitely worth a read.Thanks for reading, and for the nice comments!Scott

  4. I don’t agree. End-users don’t love BPM. They may (or may not) like the app that was built with a BPM suite – but most of them don’t and shouldn’t know that it was built with a BPMS. They either love the app or they don’t (and the actual end-user GUI has a lot more to do with that than whether it was implemented in a BPMS).People like simple, usable tools that solve their problems. To get them to "love" an app it needs even more than ease-of-use (even non-useful things can be easy to use) – it needs joy-of-use (the "wow, this toolis really useful and helpful" feeling that we rarely get from business software). Whether those tools are built using a BPMS or any other tool, doesn’t really matter to them. Jacob Ukelson – CTO ActionBase

  5. BPMS technology is better aligned to deliver against these points of contention than other technology stacks. You have more capability to manage, route, resolve, research, report against, and respond to assignments and units of work out of the box with a BPMS than with other technologies. The platform provides uniformity and a starting feature set that aligns us with the idea of using IT to gain greater visibility and control over the work we must perform in our jobs on a day-to-day basis. The potential to deliver a unified experience for the end users where they don’t need to guess at which systems drive which aspect of disparate processes is phenomenal.However – I’ve seen BPMS technology used to build out isolated vertical stacks as well as a enterprise wide orchestration mechanism. I believe most practitioners have seen the technology adopted yet had the same old siloed application approach used to build solutions – resulting in the same problems Theo highlights. From another perspective, I can get from Boston to New York faster and more comfortably driving a car than riding a bicycle – unless I insist on driving the car like a bicycle by alternately pumping the opposing pedals, in which case I’d be tempted to call GM and tell them their vehicle doesn’t work as promised. We need to remember that the BPMS is merely the platform – we need to exercise stronger BPM principles and thought processes focusing on technology and business alignment in deploying the solutions on these platforms to truly realize their potential.

  6. Jacob makes a good point. Using BPM solutions to enshrine bad practice into software doesn’t do anybody any favors. I guess where I’m coming from is that BPM offers the best opportunity to avoid doing that. But, as David correctly points out (and I love the analogy), any tool, used improperly, can produce bad results. The trick is to identify what advantage the tool really offers and then exploit that advantage.I’m loving these comments—thanks for participating!

  7. In my opinion, this is utter tosh. The "vast majority of end users" haven’t a clue what BPM is, and the first time you explain it to them there’s either a sharp intake of breath before they proceed to explain, normally in painfully unnecessary detail, why it couldn’t possibly work with their processes (especially where those processes need to interact with another department); or else, they look at you like you’ve come to make all of them redundant and are therefore the devil incarnate (or at least a close cousin).I agree with the initial assessment that processes in large (and medium) organisations are a long, long, long from in any way being built for end users to use with a computer – normally because those processes are built up over time, and acrete due to mergers, acquisitions, restructures, reorganisations, redundancies, new hires, new directors and managers coming in with new(ish) ideas, and on and on and on.The idea that you could build a cross-company process platform that would survive the various shocks a company goes through over time and that would a) still be relevant and b) still be maintainable whilst c) not costing a fortune in consultant and developer fees seems at best marginal to me. Is it any surprise that most of BPM’s great success stories are from self-contained local organisations (schools, hospitals, local government single departments, single factories, small companies, single departments, and so on) rather than multi-regional, multi-departmental, multi-functional companies?(I used to be a big fan of BPM, but over the last 2-3 years I’ve become increasingly cynical about it as it seems to be more and more a tool for consultants and small/medium IT companies to flog their own agenda. And see the awful travesty that BPMN has become – what should have been a killer concept adoptable by ordinary business people has become a tool for IT nerds to add extra complexity for their own satisfaction. Something that has been wrong with the IT industry since its birth and isn’t going away, it seems.)

  8. Being from the States, I’m not sure about "utter tosh"–is that a good thing? No? Well, I do agree that users don’t know about BPM, per se. The only ones who need to know are the process owners. To the end user, the whole thing should look like a consistent, easy to use, and powerful set of applications customized to their daily operational needs. And if that’s not happening, well, then it’s up to us in the vendor community, and up to people like Theo on the analyst side, to help make BPM realize its promise.

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s