Scale and its problems in the contact centre

This week and last week I've been on site at the contact centres of some of the UK's biggest banks. These are also some of the UK's biggest contact centres, so it's been very interesting to see the challenge scale presents.

These organisations tend to have at least 10 million customers, which is a decent number if they all decide to phone you! What makes it even more challenging is that these 10 million customers have they data spread across thirty or more years of legacy systems.

It's interesting for me that the challenge of scale that this presents has been well addressed by telephony but the IT industry still lags behind to a certain extent. This might sound controversial, but if I explain that this is viewed from the perspective of customer service, it should become clearer. Contact Centre telephony (whether Cisco, Avaya, or Genesys) pretty much scales to run a very large customer service operation. It's taken twenty years of ACD development to get here (and the evolution of TDM technology to IP), but the telephony side of things works in terms of getting a call to anywhere that the organisation wants it to go.

By comparison, the availability of data and customer information (especially in real time) is still a real challenge. All the organisations I've been working with run 3270 sessions, or other terminal emulation, as so much of their data is still mainframe based. Processes similarly can be embedded in applications and present real challenges scaling to the wider enterprise. There is recognition that the process and application layer is now one of the choke points for customer service and IT System Integrators are starting to address it (see posts like "System Integrators write interesting things about contact centre for the downturn!"). The problem is that while mainframe was previously a very good answer to many of the scaling problems that organisations experienced, integrating yesterdays good solution into today's customer service requirements is still a struggle.

It's an interesting set of challenges and one I'll blog on further.

Software archaeology, financial services and the contact centre

There's an interesting (and brief) post on Grady Booch's IBM blog that got me thinking. Grady Booch, for those unfamiliar with him, is an IBM's Chief Scientist for Software Research but perhaps more importantly developed UML (Unified Modelling Language) and was very influential in the development of Object Orientated programming. I've seen him through my time at IBM and through the BCS (British Computer Society) and I find he always has something interesting to say on IT.

His particular post this week was on the first signs that 'software archaeology' is emerging as a discipline. I think this is long overdue as alongside Enterprise Architecture, management of legacy software is one of the biggest challenges in modern IT.

I've met this challenge regularly when working with financial services customers and it's been well documented (see Silicon.com on the subject last year). The financial services industry was (and is) a sector that understands how IT can bring efficiency and so adopted automation early on. The problem is that today this can mean an environment of very mixed and some quite elderly systems. What makes this challenging is that as business requirements change, an elderly system than ran quietly on its own in a corner might now need to make it's data available to other systems. Even more challengingly, in an SOA type of architecture it may not be easy to predict which combinations of systems they might be.

It's at this point that the project team usually discover that the documentation for the legacy system is incomplete and that most of those in the organisation who could have helped fill in the gaps have taken early retirement. This means that ripping it out and replacing it is not possible. One option is to bring back these retirees as consultants but this expensive and often not practical. The other emerging option is to do some software archaeology to understand what processes and dependencies are actually in the legacy code.

This has been one of the major challenges I've found in the financial services contact centre. The agents, often young or from a non-IT background, expect either a Microsoft Windows type desktop or a shiny, new Facebook style web 2.0 interface. Instead, they find themselves learning from scratch how to deal with OS2 or 3270 terminals and green screens. This has big impacts on agent productivity and training costs. It's also a long way from the type of technology I was blogging on in: "The future of contact centre - Google, Salesforce, Skype & Microsoft".

Unfortunately, though, if the business logic for something like a life insurance policy is embedded in legacy code, and there is no documentation, then that system has to be kept running. As long as there are customers who could make claims (and that's potentially a 30+ year horizon for life insurance), then the organisation has to be able to manage them under the Ts&Cs of the policy and that means keeping the system as it is as there is no other truly reliable source of the information.

It may not be an expected outcome of software archaeology, but one of the big benefits it could bring is for the call centre agent in financial services. A more easily integrated desktop and presentation layer would help agents find the information they need far more easily. I've seen agents in one bank running three monitors each (and having to type out each piece of information the customer gave them three times to get it into into each system) because they couldn't integrate the various system interfaces.

Software archaeology may initially be focused on the back-end and legacy, but could become very important for the contact centre.