Don't use BPM as a replacement for process and system simplification.
A couple of years ago I inherited a BPM system. This system came from one of the major application providers and was a fine product. We used this BPM system to support our client onboarding process. Now, client onboarding should be a pretty straightforward process. Not in our case. In our case, we had so customized the onboarding process that we had a nearly infinite number of combinations. In order to support this nearly infinite number of combinations, we had also so customized our BPM product that the vendor could no longer recognize the product as its own. I had one engineer entirely dedicated to maintaining BPM and writing the enhancements and on-going customizations. The process was so complex that a BPM system was in fact a necessity.
Being somewhat passionate about process standardization and simplification, I questioned the level and variety of our client onboarding options.
Q: Why do we let our clients pretty much make up how we will get them started?
A: Well, because this is one way that we provide superior customer service.
Q: Have we not defined any best practices that would deliver a better onboarding experience?
A: Sure but we let our clients vary from that best practice as much as they want because that is how we deliver superior customer service.
Q: Do these variations come with a cost in terms of time to onboard and errors?
A: Sure but we accept those as the cost of providing superior customer service.
Q: But do these errors and a long time to onboard create a superior customer service or do they degrade it?
(The process owners had no answer for this.)
I convinced them to do an experiment in process simplification. We mapped out the current process, defined the best practice (that is, what onboarding steps were essential to get the job done while also reducing the errors and the onboarding timeline) and then piloted this with a few clients and gauged the results and their reactions. There was quite a bit of pushback to the experiment. Our dedicated BPM engineer wondered what his life would be like if we stopped supporting customizations and stopped asking for more. The process owners were concerned that I was trying to ruin their lives and their superior customer service. But, they got pretty energized as we tapped into their experience to define best practice. The client pilots were a resounding success. On average, we reduced the onboarding timeline by over 50% and eliminated the errors. As we expanded the pilot, we encountered a few customers who insisted on using the non-standard, complex approach. But, since there were so few of these, we could accommodate their requests and still have the vast majority follow the standard way. And speaking of the standard way, we standardized the entire workflow and eliminated -- except for those few exceptional customers -- the variances. This standardization meant we no longer needed our BPM system.
Our topic this month is BPM, so please don't get me wrong and think that I am opposed to BPM. All I ask is that we first standardize and simplify the processes we are hoping BPM will manage -- process standardization and simplification yields benefits far beyond system design and use.
0 comments:
Post a Comment