The term "best practices" is widely used in IT software sales brochures, but does anybody really know what best practices means?
Beware of 'best-speak'
I've learned plenty of lessons in my business process re-engineering career. One of the most important is to think beyond the misuse of "best practices" by IT infrastructure management software vendors and the misconception of best practices by customers.
Look closely at software vendors' marketing, and you'll see that they frequently hijack best practices as a "me-too" statement -- trying to keep up with the Jones, so to speak. The unfortunate downside is that companies looking for IT operations software thought leadership are lured into a best practices trap. All to often these companies learn (to their cost) that best practices are not the panacea advertised.
To get to the technology promised land, one must take a larger, more strategic approach. That approach should focus on "best processes" and the automation of the processes and procedures, not just the procedures.
Best practices and best processes -- and how to tell the difference
A practice can be defined as a specific set of procedures followed by an organization. For example, the telephone handling or call logging routine followed when an IT call center or help desk receives a trouble call is a practice. The analyst works through a standard series of screening questions to identify the nature and severity of a user issue.
In this case, a best practice would be a telephone handling or call logging routine that has been proven to work at the highest efficiency and satisfaction or is accepted by the help desk industry as the best method.
In contrast, a process involves a number of procedures or practices that comprise the operational method of doing something. If you take apart a process routine, you'll see a series of work procedures plus the delivery steps that connect the practices. A best process maximizes the efficiencies of the work procedures and the linkages between them.
Here's another critical distinction between practices and processes. Practices are bound by organizations. A given work procedure happens within a department or a group within a department. Processes, on the other hand, span organizations. They are the totality of how a task moves through a set of departments for fulfillment or resolution.
To illustrate, if a repair request hand-off to field services is fumbled due to bad process in our example above, it won't matter how "best" the practice is that was used to gather the problem information. The end user will be unhappy.
Closer to the technology promised land
The question you must ask yourself is how a given practice -- whether "best" or not -- relates to the overall operational process that it fits in. Without considering the key relationship of the way underlying practices fit into operational processes, a project is headed for disappointment, failure or both.
Remember, successful change requires that all elements be aligned. Automation should overlay and enable processes and procedures based on how the organizations involved actually process inputs and outputs.
My advice? If you want to impact the bigger picture, design a scope of work that includes processes, procedures and automation.
Greg Lenox is president and CEO of Norcross, Ga.-based Entuition Inc., a maker of business process management software.