Bookmark and Share

Friday, 29 January 2010

Ambitions to Perform

I attended an excellent event delivered by Sabio, one of our strategic partners, last week. Focused around the Sabio Best in Class benchmarking framework called Insight, the agenda covered individual areas of focus for Contact Centres each illustrated perfectly by a case study. Targeted at Operations Directors, IT and Senior Contact Centre Management, the event covered Demand Management, Automation, Accessibility, Optimisation and Efficiency in the Contact Centre from a strategic and underlying technology perspective. The balance between prescriptive advice, practical reality and input from the attendees was refreshing. As were the case study presentations, for once not all about how great things are but illustrating real examples of the progress and real performance improvements that each company had made, with the recognition that there were still many things that need to be addressed and that much of the time they were fire fighting.

HomeServe talked enthusiastically about how they had improved resource optimisation through forecasting and identifying the key factors that influence call volumes. However they accepted that their forecasts would never be 100% accurate because of factors that they couldn’t predict such as the more recent freak weather conditions. They talked about the progress they had made in multi-skilling through simplifying the desktop, making it easier to train agents and to broaden their remits. The result of this was their ability to successfully blend work between teams to address forecast anomalies better but recognised that there was still progress to be made here to make it seamless.

Egg spoke about managing demand and driving greater automation, their desire to move customers to self service wherever possible whilst admitting that in some cases automation was not possible and that the customer would have to call and speak to someone. Egg uses extensive measurement and monitoring processes to identify contact trends that can be addressed by the business. On the whole their move to self service continues to be successful for the majority of transactions but they explained that it was important that if the customer did have to resort to calling that the integration between the channels was seamless and the customer service levels were consistent.

In a very energetic presentation from Lego, the senior customer services director described in detail how Lego were working towards achieving better customer accessibility. Lego were unique in their desire to increase direct customer engagement to ensure that they continue to grow and meet customer needs. The recognition that their customers were multi-lingual, spanned generations and that the majority of Lego is sold during what they called Main Season or to the rest of us – Christmas has massively impacted their contact centre strategy. They needed to achieve improved customer contact across multiple segments whilst recognising and developing Lego as an emotional brand that their customers felt part of and involved with. Something that they realised they lost sight of in the early part of last decade, but had since 2007 been striving to put right with some excellent success rates.

Finally a presentation from Telefonica O2 Ireland that talked about delivering operational efficiency through measuring in call performance, aligning the agent with the customer needs and the work that they have been doing to segment the customers and align service requirements to those segments but doing this within the unique challenges of the local market.

These sessions in addition to some interesting conversations with many attendees led me to believe that the priorities of senior contact centre directors both in operations and IT are many and varied but that the underlying principle they are looking to achieve is the right level of customer service.

There are many areas on which they can focus their attentions in order to achieve their business strategy, technology being one of them. This led me to think that the key defining factor in any technology implementation within the contact centre has to be its impact on the customer. There are so many technology options that will deliver clear business benefits but where should they focus to improve performance – it was made clear that they should begin with the customer journey looking at the major pain points. Ultimately much of that customer journey is controlled by what is going on at the agents desktop. There are some technologies that will have a more wide reaching impact than others, Enterprise Mashups being one where quick wins can be made and strategic value delivered. One thing that was clear is that companies with extensive sector and technology expertise as demonstrated by Sabio can clearly help to bring together the strategy and technology elements to address these pain points, reduce the fire fighting and help contact centres to meet their ambitions to perform.

Labels: , , , , ,


Friday, 22 January 2010

“Obvious Mashups?”

I have been reading Jack Trout's "In Search of the Obvious, the antidote for today's marketing mess". Trout's view is that to succeed in differentiating your offering, you need to look for 'obvious solutions' that will set your products apart from your competitors in a way that is equally obvious to your customers. To help in 'identifying the obvious (sic)', he devised 5 tests, the tests of Obviousness of your marketing strategy or new product concept:
1. The problem when solved will be simple - the obvious is nearly always simple, so simple that generations of people looked at it without seeing it
2. Is the time ripe?
3. Does it check with human nature? i.e. would everyone understand it, without requiring any specialized knowledge?
4. Does it explode in people's mind? i.e. "why didn't I think of that?"
5. Put it on paper - does it still make sense when put on paper?

Trout's focus is mainly on consumer products for both differentiation within a category and for new product development. I thought it would be interesting to check enterprise mashups against the principles highlighted by Trout (ignoring the last one!):

1. Enterprise mashups turn integration on its head. They take the often abused but appealing “lego brick” analogy of SOA at face value and make it work. Pieces of IT are really laid out like bricks – simple, visual and tangible - and are then simply combined to create useful new solutions. And it turns out that a lot of very valuable integration can be done by using these building blocks in a straightforward fashion, without the usual paraphernalia and complexity of integration. Simple – it just took the courage to do it the obvious way (and to figure out what the right sort of lego bricks are)!

2. Is the time ripe?
Is integrating applications to make people more efficient a major issue? One only needs to look at the mess on most contact centre desktops (and the associated inefficiencies and costs) to agree. Do customers need a way to achieve this without major investment? Of course, especially in today’s economic climate. Do companies need to combine internal legacy applications with new generations of web-based services? Definitely, whether it’s to capitalize on social web trends or to benefit from cloud computing.

3. Does it check with human nature?
People understand the problems, associate with them, and see the value - everyone has experienced the issue of working with multiple applications to complete a task. Everyone has been on the receiving end of the same issue when dealing with contact centres. We intuitively understand the idea of combining the different and relevant bits of applications – a bit like creating a collage of the desktop - to make a job easier.

4. Does it explode in people's mind? When you show people what mashups do, the light switches on. The issue is almost the opposite: if this is so obvious, why has this not been done before? Together with the history of failure in integrating effectively applications for people, customers initially tend to think this is too obvious and too easy - there must be a catch.

I think Enterprise Mashups pass the tests. Obviously I would, being at Corizon. Let me know whether you agree.

Wednesday, 20 January 2010

The Impact of Data Ubiquity

Part 2

This blog post is co-written with Lee Provoost from the social business consulting firm Headshift and started over a bowl of porridge

The end-user of your product doesn't care what kind of data silos are laying underneath your IT system. They just want the information they need to do their work, but very importantly: taking in account the context of the work! Put yourself in the consumer’s shoes, your customer doesn’t talk to you in silos and certainly doesn’t want to be treated in silos. Have you ever called your bank, only to be passed to several different departments? We know already that Interactions aren’t Connected and ultimately we are still running processes as if we are in the industrial age – an assembly line of handoff after handoff.

This is the same as going to a McDonalds and asking for a ‘Happy Meal’ but being told to get a drink from one counter, a sandwich from another, fries from a third and the toy will be sent directly from Mattel – oh and you want a straw, napkins and sauce – there’s self service for that. More of a Meal than Happy! Not quite so fast or convenient food. What happens when the meal then changes, there's a new toy, you add something else to the box - how is the existing process able to cope with changes easily?

We have now identified the impact of data ubiquity:
  1. the corporate IT department being challenged by huge data silos (lock-in) and disparate solutions with complex processes that rely on humans to be the integration layer
  2. the business end-user dealing with too many different and complex applications and not being able to make sense of all the data (filter failure), subsequently not being able to deliver the process
In many businesses the delivery of an end to end business process relies on users accessing multiple software applications that combine to deliver the complete process. The result of this can be disjointed processes, mistakes, slow access to required information, no single customer view and ultimately a dysfunctional customer experience that the business users can’t impact.

So, the goal we're trying to achieve is to provide business end-users Enterprise 2.0 systems with meaningful contextual information in a simple and elegant way – we like to call this fit for purpose!

Mashing it together

As a technologist, the first reaction would be to try to solve this data silo problem. (Let's ignore for a second the old approach to create a monolithic repository, called the black hole, where we dump everything in.) How can we make it more accessible, can we wrap a web services around it, can we apply on a large scale the principles of Service-Oriented Architecture and Model-View-Controller, can we add an open data API interface to it, etc. That will most likely keep us busy for the next coming years. Wake up call: your customers are not going to wait two years till you have your internal issues solved. This approach also often instigates new shadow projects that proclaim to deliver tactical, quick win solutions whilst waiting for the 'nirvana'.

As a business end-user, you're faced with a proliferation of applications. A lot of time and money have been invested in building these, so... why not starting by reusing the useful bits of the existing apps to get immediate value?

This is the approach pioneered by Corizon. An user-centered focus approach, starting with the end users and working down - understanding the process in which they go through to complete a task, be it solve a customer enquiry in the front office or manage work in the back office - referred to as the user process. All too often, technology's answer to a problem is upgrade to the latest version as it has all these new features. The problem with this is that this doesn't necessarily resolve the original problems, complex process, too many applications.

Once the user process is clearly defined, we then (or can in parallel) look at working up - understanding what data & applications we need access to to effectively and efficiently complete the defined user processes. We will now understand the pattern, what gets the most use, by who, how. This firmly puts the cross hairs on which applications to enable for reuse. Unlike traditional data re-use approaches, this approach enables the useful & required bits of applications, but also defines reusable UI and stores these in a library of reusable services.

Now we have two key elements defined, a clear user process and a set of reusable UI services. Corizon's solution then allows you to mashup these to create the optimal interface, be it a standalone UI or consumed as a widget in your Enterprise 2.0 application. Adding new, or removing legacy applications becomes a much less complex task - the UI Services approach allows you to interchange these without affecting the interface.

Good is good enough

At first sight, this approach might sound a bit unconventional, but we'd like to invite you to an excellent post by Peter Evans-Greenwood (@pevansgreenwood) that talks about "The Price of Regret".


Building the big, scalable perfect solution in the first place might be more efficient from an engineering point of view. However, if we make the delivery effort so large that we miss the window of opportunity, then we’ve just killed any chance of helping the business to capitalise on the opportunity. ... Size the solution to match the business opportunity, and accept that there may need to be some rework in the future. Make the potential need for rework clear to the business so that there are no surprises. Don’t use potential rework in the future as a reason to do nothing. Or to force approval of a strategic infrastructure project which will deliver sometime in the distant future, a future which may never come.

One thing we've learned in this consulting business is that most of the times, good is good enough since perfection takes an eternity.

Labels: , , , , ,


Thursday, 14 January 2010

Data Ubiquity Threatening Usefulness of Enterprise 2.0

This blog post is co-written with Lee Provoost from the social business consulting firm Headshift and started over a bowl of porridge
Part 1....


"Content and data are everywhere. People are creating and curating content like never before. As data storage becomes cheaper, businesses are storing,archiving, and mining more data than previously possible. The increasing openness of APIs and data portability make more enterprise data available for both consumers and employees to consume. Free flow of data also allows businesspartner relationships to be readily analyzed and optimized." (Emerging Opportunities in Social Business Design)
Filter Failure
With large corporations storing more and more data (be it for compliance, regulatory or internal mining purposes) in their Enterprise 2.0 (and overall IT) systems, we have the danger of getting big data silos or disparate solutions. To make matters worse, they are often stored locally in systems that are owned by different business units with different purposes. So, imagine that you have invested a lot of money and effort in a knowledge management system, just to realize after 3 years that it does not suit your needs anymore and you need something else? If you have a couple of thousands of files, it's still quite manageable. However, if you work in a very knowledge-intensive organisation, three years of data might have accumulated into several hundreds of gigabytes of data. Good luck with that migration.

Then go through a merger with your competitor or launch a whole load of new products or services and try to gain consensus and consistency across these disparate solutions.
With the increasing importance (and increasing amount) of data floating around your organisation, it becomes more and more important to think about open standards for data interoperability. Accept the reality of the day that a lot of your data is stored in silos. What we need to think of now is how we are going to make this data step-by-step accessible so that we don't need to do tedious and error-prone data migrations when the system doesn't cope with our demands anymore.

Perhaps to your surprise, I'd argue that the data silo lock-in is not your biggest problem. No, the inability to intelligently manage and reuse this volume of content in a meaningful way is a much bigger danger that has a direct impact on your business. Filter failure arises when individuals are unable to synthesize and understand the vast amounts of information being generated by an organisation.

Where the problem used to be getting enough information, now it's being able to make sense of it all. So in addition to filtering the underlying plethora of data and subsequent applications, you also have to be an inline translator. For anyone dealing with end users directly eg a front line customer agent dealing with lots of applications, they will always speak in their own language and never that of your systems, applications or processes. More importantly, they have no reason to.

The interface is the product
But what exactly are we trying to solve here? Why would we even care about this problem? Just a Bunch of Stuff That Happens perfectly coined it in the following cartoon:


Even this is being kind – the average knowledge worker will use between 6 and 15 of these apps, we have experienced people using upwards of 30 because of these data silos. The typical enterprise application looks much like "Your company's app" as shown in the cartoon. There is such a vast amount of data flowing around your company that you often end up with these kind of user interfaces. Instead of achieving the goal of bringing powerful information to the fingertips of the business end-user, it just confuses people. It just makes people unhappy and unproductive. For every new channel, (email, web, social channels, ...) and for every new product, the quick answer is often to bring in a new additional application. This all adds to the complexity and mess on the knowledge workers desktop.

And just in case you would forget, an IBM Design tweet nailed it:










Part 2 of this blog which will be published next week will go on to describe how the issues of data silos and increasingly numbers of application interfaces can be addressed.


Labels: , , , , ,