Contact Centres, Process and Six Sigma

Last week was a very busy week and one where for the first time since the blog started that I've been so busy on customer sites I haven't had a chance to blog. It's hard to do this subject justice in one post but a big area I'm thinking about at the moment is business process in the contact centre and how it relates to IT. Part of this is that any SOA thinking about contact centre design (and I'm doing a lot at the moment) requires a good view of processes. This is more than just CRM it is the whole process of each customer interaction from the organisations viewpoint.

I find that many call centres do not have a good or accessible view of their processes. By this, I mean that processes exist as MS Word documents, or hard copy flow diagrams but version control, management and maintenance of these processes is very difficult. If you were to try to assess the impact of changing processes, then one (large) MS Word document is very difficult to relate to another. This is especially true when trying to understand how these business processes may impact one another.

It's in this context that I was asked what I thought of John Seddon (of Vanguard Consulting). Their big idea is that you can adopt Toyota's ideas about manufacturing for service organisations. I'm inherently dubious about this. As a Judo player I have acquired a little knowledge of Japanese culture and how subtle concepts can be. I'm very dubious that a concept as subtle and cultural as kaizen can be applied quickly to resolve service issues. It's not just that kaizen is about processes changes (though it is), but it is also cultural, management and risk changes - things organisations find very hard to do. That said, I'm not as dubious that kaizen could not be applied in some form, it's certainly a more useful idea than that of 'black belt' in six sigma.

John Seddon does have some interesting things to say about approaching customer service from a systems point of view. I do agree with him that six sigma is not a very meaningful methodology for customer service and that viewing the process and outcome as inherently connected to each other is very sensible. Similarly a highly iterative approach to change is the way I have tended to approach projects (especially around SOA) as way of driving incremental evolution. Still, being highly iterative and get workforce buy-in does not equal kaizen (or anything close to it) and could in fact just be a RAD type of development model.

I do feel though that much of this debate is missing the point. In many call centres, it's not that the processes are broken, but their complexity and lack of visibility makes them very difficult to mange. This perhaps is also why SOA has lagged in the contact centre, without clear processes, organising units of functionality if very difficult. My thoughts are that whether a systems approach or something else is used for customer service , clear, well managed processes are probably the pre-requisite for success.