Given proper motivation and guidance, people will amaze you with their resourcefulness. They will find ways to solve problems that no architect or business analyst could ever envision, reusing the tools at their disposal and creating new sources of information, processes etc. The question is how to empower the employees without totally losing control.
Well, you need to closely monitor the things they do, how efficiently and correctly they do them and determine if there's something you can do to help them do it more efficiently. That's the missing step in all the projects I've
worked in. Managers rarely know how exactly things are done, or how IT could help them do it better. But if you get a technical person to sit next to a call center agent the problems and the answers become immediately apparent.
Email, unstructured task assignment, document libraries and ad-hoc questions to more experienced agents are some of the tools you'll see them use. Blogs, twits and whatever else may be useful will gladly be used as well, as
long as it helps them do their job. No one needs to tell them to do it. If they know it exists and are given time to learn how to use it, they'll find ways to use it. But it is OUR job to see what they do and determine if a
particular activity is worth automating/integrating/replacing.
Well, you need to closely monitor the things they do, how efficiently and correctly they do them and determine if there's something you can do to help them do it more efficiently. That's the missing step in all the projects I've
worked in. Managers rarely know how exactly things are done, or how IT could help them do it better. But if you get a technical person to sit next to a call center agent the problems and the answers become immediately apparent.
Email, unstructured task assignment, document libraries and ad-hoc questions to more experienced agents are some of the tools you'll see them use. Blogs, twits and whatever else may be useful will gladly be used as well, as
long as it helps them do their job. No one needs to tell them to do it. If they know it exists and are given time to learn how to use it, they'll find ways to use it. But it is OUR job to see what they do and determine if a
particular activity is worth automating/integrating/replacing.
I totally disagree that complex, predictable processes provide the solution. Just try dealing with Oracle's technical support and you'll realize that even the best processes can not replace a knowledgeable agent, empowered
with the proper tools. In my experience, the cost of a 'perfect' process far outweighs the benefits.
I used to make the mistake of considering chaos a bad thing, the opposite of order. In fact, it is chaos that creates order. Complex systems in nature were not designed, but emerged. As humans, we have an inherent need to plan and organize, to make sense of the world we live in. But the world is far from deterministic and the larger the project, the more likely you are to feel the consequences. As more and more projects fail, as the drive to reduce costs and increase efficiency constantly intensifies, I expect that you will see experiments in carefully controlled 'chaotic' processes.
The first large system I ever designed was a 'ticketing' system. It was supposed to simply log agent-customer interactions in the telco I worked for. A key feature was the ability to assign the ticket to another person or 'group' within the company. Well, within a year, the tool was used to control an inconceivable number of processes, many of which did not directly involve customers. The users created virtual groups to categorize tickets (misusing the already available ticket type, which was always left to its default value). Some very interesting things happened in the company. People suddenly had a means of proving that they were doing their job and that the bottleneck was a different department. Tickets were 'hot potatoes' that nobody wanted in their inbox. If an issue took too long to resolve, the ticket of history would tell you what went wrong. In essence, the ticketing system had become a replacement for emails and helped identify several processes that were later implemented on our legacy system.
Our system gave agents an unthinkable level of freedom. They could essentially compose and provision products that did not exist and that our billing system did not know how to bill. Insane, right? Well, with a team of two developers, that was the best CRM we could provide. But guess what? The company has since introduced Siebel CRM, keeping much of the original ticketing system's functionality and orders for corporate products (VPNs etc.) are still being entered in our legacy CRM. Why? Because they are so complex, that it is very time consuming to configure them in Siebel.
Were the processes that emerged the most efficient ones? Probably not. Did we get errors? Certainly. Did we get the job done with the minimum resources? Definitely.
I anticipate that this drive to replace smart people with smart processes will soon reach its limit. Dummy agents can not deal with unexpected circumstances and no matter how smart the processes get, it is simply impossible to predict all possibilities. Maybe it is time to start thinking about providing smart tools that handle business events, one at a time. Maybe there are only so many processes that are repetitive and predictable enough to be fully automated. Maybe we should plan for ad-hoc, manual intervention, instead of considering it necessary only for exceptions. What if exceptions end up being the rule and the 'happy path' is in fact an exception?
Δεν υπάρχουν σχόλια:
Δημοσίευση σχολίου