When I was at Deloitte in the late ‘90s/early 2000s, the joke among the junior consultants was that once clients and the general population started to use our industry buzzwords, it was time to change them. “Re-engineering” became “process optimization”, which then became “business process transformation”.
It’s not that these terms have no meaning. These terms became buzzwords that people threw around without a deeper understanding of their value. “Best Practice”, a process or procedure that is the most efficient and effective method of getting something done, has become one of those terms.
“Best practices” can be applied to almost any business process in any industry. I recently had a client who was being merged into a new organization and had to convert to the new company’s payroll system as part of the integration. When faced with redefining and mapping their pay codes, the question asked was “well, what’s best practice?”
The pay codes are simply 4 digit codes that define the different ways of paying people within the system – regular, overtime, shift pay, etc. To get to a best practice, we could have re-defined all of the inputs (time records, benefit enrollments, tax definition, etc) and outputs (how liabilities /expenses and payables hit G/L and A/P, vendor integrations, etc) that yield employee earnings.
The goal of this project was integrating multiple organizations to one payroll resulting in an accurate pay check, and not about current inputs (created by pay and benefit policies and practices). The mandate was expediency, not efficiency. Would this organization have benefited from a best practice review? Absolutely! Was it built into the project or supported by management? No way. There was no room for a “Best Practice” discussion, but I was asked at almost every decision point whether we were going to follow best practices.
On another project where I was implementing a new benefits system and configuring with best practices, I was faced with the issue “well, that method doesn’t work for us” and was asked the question “if we change it to suit our needs, is it still best practice?” Not really, but sort of… And therein lies the myth.
Like all of the buzzwords that preceded it, a singular best practice method isn’t going to work for everyone. More to the point, it isn’t going to work the same for everyone. Organizations are complex organisms with lots of moving parts. Departments are made up of people that are used to doing things in certain ways. There are touchpoints and integrations, technologically and process-oriented, that need to be evaluated and updated in order to truly reach “best practice.”
Instead of trying to force your way into best practice, assuming that it will immediately make things better, try to understand how the “best” in the recommended course of action fits into your model and tweak it as necessary.
Improvement requires analysis to support specific goals that align with business needs. That analysis includes a review of process, data (or how it flows) and sometimes the people that are performing the jobs. If you take the time and engage fully in this analysis, you’ll know how to reach a better outcome.
They say that you can’t know what road to take if you don’t know the destination. That’s true, but you also can’t know how to reach your destination if you don’t even know what road you are currently traveling.
I’m not suggesting that implementing technologies can’t improve process. They almost always can, assuming that those implementing them are willing to be flexible and fungible.
So, before you suggest “best practice”, ask what works best for your organization, sometimes just for your slice of the organization, and go from there. For now, you may only get “better practice”, but that may be the best practice for your organization. Process and technological improvement is incremental, as it is in people, and requires constant and consistent attention.
Photo Courtesy of Stock Photo Secrets