This recent article in the McKinsey Quarterly on “a better way to automate service operations” nailed it: processes and work practices are best designed and implemented before companies roll out the new IT. Otherwise, the COO will walk into the field operations control center after spending millions on a new automated scheduling and dispatching system (and over a year implementing the software and installing the hardware) only to find that response times have not improved, and the number of jobs each engineer handles in a day has not increased.
This experience is all to common for leaders of service operations organizations that manage large groups of remote or distributed employees, including those that have made multi-million dollar IT investments in areas such as automated dispatching, schedule prioritization, workflow automation, and performance management. This is because these systems require processes and work practices different from those used in non-IT enabled situations.
This means that before a company implements a new service management system, the company not only has to sit down and baseline its current operations, but determine how these processes need to change in order to appropriately utilize the capabilities of an automated system. This is because best practices developed over the years to insure that manual processes don’t break down tend to be over cautious due to the limitations of the average person to manually schedule hundreds, or thousands, of resources across thousands of jobs — limitations that today’s software doesn’t have.
To succeed, a company needs to go back to square one and define the goals of its service operations, the resources it has available, and the equipment at the resources’ disposal. It has to throw away all of the old rules and constraints and be sure to only define true constraints (an engineer is only available 8 hours a day, service for tier 1 contracts must occur within 24 hours, etc), not perceived constraints (an engineer can only handle two calls a day, the repair must be by an engineer at the closest office, etc.). And then it has to trust the system which can optimize across thousands of variables.