When a BPM Failure Is a Huge Success
It's uncommon to have a customer apologizing to you for deploying a flawed process. Here is an example of how this is the best situation that customer could hope for.
We implemented a BPM project for a customer not too long ago, and one of its specific processes is the subject for this blog: An HR process used to request and approve new headcount--the gateway, if you will, to subsequent staffing events such as posting the position, applicant tracking, and ultimately onboarding.
Overview of the Existing Process
Prior to our effort, the simple process was manual, involving routing a paper/fax form from the Hiring Manager to the HR Business Partner (HRBP) to the Business Unit Director. Typical time to completion, involving geographically disparate and traveling approvers, was between 3 to 10 business days. Completion tracking was a bear, and auditing was worse with grainy faxes of faxes printed and filed all over.
Overview of the New Process
The new CEO wanted to apply the screws and approve every staffing request. When this scrutiny occurs, of course, it has consequences elsewhere: if the CEO will be seeing this, the functional VP will want to see it and approve beforehand, and so on.
The new process ended up routing from the Hiring Manager to the HRBP to the Business Unit Director to the HR Staffing director to the Business Unit VP to the HR VP and finally to the CEO. (As an aside, this makes a good case for flexible BPM since the moment the CEO no longer cares to scrutinize each approval, all those superfluous participants will immediately drop off as well--which is what happened after 10 months).
Anyway, the new online, automated process removed the pain points of the existing process while managing increased complexity (e.g. the new routing/approval logic, integration with their Single Sign-On, slick auto-population of form data from their HR system, reports, metrics, context-driven and configured policies: the works, baby!). Completion times were within 24 hours, and usually within 30 minutes. Only if there was an upcoming strategy meeting might there be longer delays for the upper level approvals.
Followup after Deployment
Within a week of the new process rollout, our gleeful project champion turned solemn. She approached me saying again how pleased they were with how we delivered on such a tight timeline, how everything worked exactly as it should, BUT there were a few changes being requested. “Not a problem, this is what we're here for,” says I, as we swiftly folded in the extensions.
The ever appreciative champion comes back the next week and even more solemn, passes along more change requests from the field. Two weeks later, she is thoroughly apologizing for how she clearly had us build the wrong process, plus there were new relatively major changes requested.
I looked her in the eye, and told her flat out: “Are you kidding? This is one of the most successful processes we've ever built.”
She didn't understand how I could be serious, so I explained: “The feedback you're getting proves something very important: THEY ARE USING IT!”
Q: How in the World Is This a Success?
A: Continuous [and Rapid] Improvement
The changes requested, it is interesting to note, were primarily about involving groups previously unknown to the Value Stream, generating new documents and reports for these new participants. These groups basically saw the power and ease of the new process, and realized they could get and provide new value--effectively innovating process benefits, not to mention building some efficient, cross-functional beachheads. Now, that is some positive user adoption!
The key lesson here is that you won't get it perfect the first time, but you may get it “right”. The “right” in this example, was made up of three key items:
- Satisfying the business requirements
- Gaining a compelling customer adoption
- Folding in the feedback to continuously improve #1 and #2
If you hear the Voice of the Customer (VOC) feedback, #3 is imperative for Continuous Improvement. But of course, it is the silent deployments you really have to worry about.
How have you ensured the wheel of Continuous Process Improvement spins for your projects?
