We've all been there: first day on a new job, and the veteran is there to show you the ropes. If you're lucky, the veteran is an experienced and motivated teacher, and you can feel free to ask any question you like. How does this part work? Where do these go? What is this thing? Who is responsible for approval? Ask those, and you'll get a solid, helpful answer that will help you do the job the way the veteran does, which is what you really want out of any job, right?
Just don't ask him "Why?"
Not because the veteran doesn't want to go into why, most likely. No most likely, he simply doesn't know. Doesn't know why the processes he's been doing for years are structured the way they are. Most likely the person who taught him didn't know, and you probably won't either.
For those of us in the role of business process management, this lack of knowledge is a key stumbling block when we begin to map out a process for refinement. Without context, it can be very difficult to assess the value of a particular step in a process, which makes changing or removing that step a risk.
For example, in a data entry process, there is a step that requires someone to copy a value from a system, paste it in a particular spreadsheet, and save the spreadsheet. During the interviews, it becomes obvious that no one knows why this step occurs, what the spreadsheet is for, or when the step was added to the process.
It seems like an obvious quick-win: Stop the step, and save several minutes of wasted time. But is it wasted? Certainly it isn't adding value to the group doing the data entry, but then it obviously was never intended to. So, who (or, if you are in an organization with automated data systems, what) is using the data collected in that spreadsheet? And why?
It certainly could be a complete waste of time. That spreadsheet is perhaps sitting completely unused and is of no use to anyone. But then again, it could be populating an important forecasting tool, or a strategic report, or the CEO's dashboard. It doesn't make sense to recommend the elimination of a step until you understand its purpose. Let the Wild Goose Chase commence.
In any organization that has been around long enough to have had a high percentage of the original members move on, there are going to be mystery processes. These are things that people do because they've always done them, and no one is really certain why. The role of business process management can often be one part Indiana Jones, and one part Sam Spade: piecing together clues left behind by employees long gone, or inferring meaning through questioning innocent bystanders who "really-have-no-idea-why-it's-done-like-this-but-it's-a-pain-so-if-it-isn't-important-it-would-be-great-if-we-could-stop".
Sometimes, there is a pearl at the bottom of that deep dive. Sometimes you rediscover a lost truth and can provide a "why" to the veterans and newbies alike for them to pass on to future employees, and for a more permanent record in a document or wiki. That "why" can tell you if the step is a waste or not, and you can act on it appropriately.
Sometimes, though, you just hit bottom and come up empty-handed. In that case, the choice is simple, if not easy: Leave it as it always was, perpetuating a step that, as far as you can determine, has no value; or stop the step, and hope that if it does break something, it's at least obvious. Generally it's worth taking the risk, especially if you've done your homework and are confident nothing critical will be affected. Still, there is always a risk of finding yourself in a different detective role: the one where an old case has come back to haunt him.
No comments:
Post a Comment