Follow me on Twitter

Friday, 16 April 2010

Designing for value and outcomes - dealing with variety

I've been hearing this a lot nowadays... engineers, computer scientists, designers, organisation science... all telling the world we must design for value. So you then go in and check how they actually do it and in almost all cases, you hear them start with 'understand what the customer needs'. or 'find out what the customer wants'. In engineering, it's about specifying the customer requirements.

In a world where the product is a tangible one, it would probably be ok. But in the case where the 'product' is a combination of physical asset and intangible human activities, this has to be a major challenge. I'll give an example. Checking in at an airport. Our 'needs' in checking in may be quite consistent if we travel frequently. so there may be some pattern to this. Yet, if tomorrow i decide to travel with the family (perhaps with my baby nephew in tow), those 'needs' change. the value of the airport service is now perceived differently and experienced differently. The context has change and the value of some of the airport services to me has changed. Bear in mind this isn't the same as the market segmentation problem because market segmentation typically talks about buyer types and buyer profiles. in this case, its use-types and use-profiles which are usually not a description of an individual i.e. one individual could have several use profiles. In the extreme, an individual could have infinite use profiles.

So... when you design an airport or a complex system, how do you design for context variety? how should variety be designed in terms of processes and a system architecture to better 'serve the customer'. Which customer is this? the customer that has the baby or the same customer that is the frequent flyer?

In my previous post, I discussed endstates. When a firm wants to deliver endstates or outcomes, it immediately inherits customer variety. You have no choice. How can you claim to deliver me outcomes if you don't also immediately promised me these outcomes at any of my experiential state? How can you claim to deliver me value-in-use if you don't immediately inherit all the various contexts of my 'use'? Do you even know the various context of my use? I get annoyed when firms think 'outcome-based' contracts or performance is a marketing spiel. The reality is that designing and delivering outcomes is a lot more challenging than firms realise.

Traditionally, when designing goods or equipment, the context of use by the customer does not change the delivery system quite immediately e.g. how a customer uses a TV, a car or a cup does not immediately change the design and manufacture of the TV or car (although may serve as inputs and feedback for future design). In service activities, customer ‘use’ of an activity in a context has a direct impact on the design and delivery of the activity, which makes it a challenge for the firm to decide how much variety to tolerate in its initial design and resource inputs.

I'll give you an example. Say I want to withdraw £250 from an ATM machine. On that day, I would like to have 10 £10 notes (instead of 5). That's a contextual use variety that the machine cannot tolerate. I know that, so I attenuate my own variety (Ashby's law says only variety can absorb variety) by living with it. I don't get what I want but I know an ATM can’t deliver it anyway so I'm not necessarily unhappy. Let's say, on that same day I decide to withdraw the £250 from a bank teller and request for 10 £10 notes. Will I get it? Well, it depends on the design of the service isn't it? If the teller absorbs my variety, that's 3 minutes additional time to serve me. Efficient process designers don't really like that. In aggregate this would have an impact on resources. Alternatively, the teller can tell me politely that this is not possible so my variety is attenuated. Interestingly, I get the same outcome as the ATM machine but in this instance, I am not happy. You now get a feel of the depth of the problem.

So how much variety should a firm tolerate? how should a service be designed for variety?

(Phil Godsiff, our PhD student at the institute and who has decided to dedicate his research life to variety, has written a nice paper on variety in the latest issue of service science here)

Contextual value is therefore a moving goal post. it doesn't mean it can't be designed, it just means you can't design with the assumption that value is static. Because if you do, you are making a whole load of assumptions around the context that you probably didn't realise. what we need is intelligent design. that means a redefinition of 'service excellence' to mean the ability of an organization to deliver to moving contextual value goal posts. that's a tough one. see next post.

Actually, I believe the problem is more than merely variety because we need to understand where customer experience sits in all that. As a lead in to my next post (and a reminder to self), I will blog next about variety, emergence and customer experience in a system.