How not to use IT in services

Several people picked up on this one after Gerold Kathan sent out a note about it, but perhaps David Sprott said it the best:

  • davidsprott: RT @gkathan: John Seddon – a master class in how NOT to use IT in services. Optimize value, not cost. Brilliant. http://tinyurl.com/dygdcpg

It’s a 40-minute video (split into three parts) of a keynote by John Seddon at an IT-conference somewhen last year. And it’s magic – absolutely brilliant.

If you’re into enterprise-architecture, business-architecture, organisational-architecture, service-design, or any related field such as service-management of any kind, you need to watch this video – there’s no other way to say it.

Some of the insights I picked up on my first pass through include:

  • “standard times are for dummies”
  • “manage for value, not cost; if you manage to costs, your costs go up”
  • “it’s failure-demand, not value-demand”
  • “specialise – it increases the costs”
  • “people who study systems focus on demand”
  • “[you get better results because] you’re trained to identify the things you’re not capable of doing”
  • “we get rid of all the activity-measures, because they’re of no value whatsoever”
  • “whenever we create a back-office, we see an increase in activity: it should be a signal… but what do they do, no, they specialise the activity, they outsource it, they lean on people to do more faster, and that just creates more work.”
  • [vid3, 05:00-07:30 “it’s just wrong”]
  • [on ‘Lean’] “never give it a name: if you give it a name, the managers will expect if to come in a box”
  • “the problems you’ve really got are not the problems you think you have, when you study”
  • “[Taiichi] Ohno’s favourite word was ‘understanding'”
  • “[managers think] if you’re a service organisation, and you standardise the work, the costs will go down – wrong!”
  • “when you standardise and specialise in service design, you stop your system absorbing variety, and your costs go up: economy comes from flow, not scale”
  • [important summary in vid3: 13:00 – 14:30]

I’m going back to watch it again… very strong recommend.

Tagged with: , , , , , , , , , , , ,
8 comments on “How not to use IT in services
  1. Adam Johnson says:

    Really good stuff and in my opinion relates to a lot of the work you have put into your sense making analysis and the like. Trying to push everything out of Chaotic so a system of sorts can be put in place to automate before truly understanding what is unique and should perhaps remain chaotic and people driven. e.g. principle based decision making in practice… allowing the housing repair specialists to assess and set a total repair time based on their knowledge and expertise vs. setting standard repair times prior to getting on the job. Granted there was perhaps some complex and simple work involved by aligning specialists by geography based on common repair analysis data…which supported the ability for the specialists to provide a principle based decision at the time of the repair. As the principle based design proves its worth then a move towards complicated, complex, simple made sense (mapping their non-unique work to technology or other enablers). I wonder how technology related some of the models are? or how related the influence of technology is to dampening the chaotic space? Similar to your post that described your upbringing ….parents didn’t rely on technology much or the concrete in making decisions…they relied on their principles and design thinking. Just my take anyway

    [TG: post edited at Adam’s request – removed unintended “not” before “dampening”]

    • Tom G says:

      Adam – yep, much like my own take on John Seddon’s talk. Absolutely brilliant work.

      Also I agree with your interpretation of what I’m aiming for in ‘business-speed’ sensemaking, about the role of principles – which is why principles are so fundamental to an enterprise-architecture.

      Perhaps the other point about a rules/control-based system is that in a human context it indicates lack of trust, whereas principle-based systems depend on trust – including trust in the flow. (Another essential read is Csikszentmihalyi’s ‘Flow’ – see Wikipedia at http://en.wikipedia.org/wiki/Flow_(psychology) – note that it applies to ‘flow’ in this services sense as much as it does to human psychology.)

      (As per above, I edited your comment to remove the extraneous ‘not’ – worry not, such things happen to us all! 🙂 )

  2. Bala says:

    Very insightful post Tom!. Thanks for sharing!.

    As we see today, many industry developments are large in scale – be it cloud or grid – assuring economies of scale, resulting in reduced cost. Am trying to evaluate is there a true merit in it…

    • Tom G says:

      Hi Bala – thanks for the comments!

      “Am trying to evaluate is there a true merit in [standardisation and economies of scale]” – obviously, yes, there’s some. Look at Ryanair, for example, who’ve standardised on a single aircraft-type: that means that spares-management is much simpler, training is much simpler, and so on. It greatly constrains their versatility, but their business-model doesn’t require that kind of versatility.

      The situation John Seddon is describing is one where by the nature of the work there is a high degree of variation – and it’s there that standardisation and (over)-specialisation doesn’t work. The real point is that the methods to resolve variation must at least match the level of variation in the system: if they’re simplified beyond that, to a level where they’re significantly less than the natural of the variation of the system, then you’re definitely set up for failure.

      At a relatively quick glance, seems to me that the only way that standardisation and specialisation will work is at the front-end of the business-model, where we tell everyone that this is all we do. But even there there’ll be a fair few options: for example, if you compare Apple’s product-line – limited model-range, limited variation – with Dell’s – mass-customisation – you’ll see very different business-models that use standardisation in very different ways.

      “Even in Toyota, I hear they had specialisation” – very likely, not least because of themes such as aptitude and experience. There’s a segment in Pirsig’s Zen and the Art of Motorcycle Maintenance where he talks about different types of welders: the production-welder who hates doing anything new, and wants to achieve perfection on the one task; and the maintenance-welder, who loves tricky challenges and hates doing anything twice. The point Pirsig was making was not to use the one type of welder for the other’s work: same principle would apply to all other types of skills and contexts, really.

      “Are they specialised or generalised or both?” – the usual phrase is ‘T-shaped’: depth-specialism in one area, but good linkage to all other areas. Think of an Army cook or bandsman: they each specialise in an area that’s not military as such, and they’re not usually engaged in front-line war-craft, but they know how use a rifle and they can switch over to second-line military tasks at a moment’s notice.

      The challenge for a service-manager (to use Seddon’s example) is to know what specialisms are available, to know where those people are, and how to deploy them. As Seddon says, sometimes they’ll be sitting on the bench back at base – and that’s fine, if we’ve costed for it. The other half of the balance is to make it ‘safe’ for less-specialist people to know when to call for specialist backup – and wherever possible to treat any such call-out as a learning-exercise for all involved. Given my family background, one example I know well is the relationship between the general medical practitioner (‘family doctor’) out in the field, and the specialist consultants and equipment back at the hospital – but every service-discipline will have its equivalent balance between generalist and specialist.

      A good topic for another discussion somewhen, anyway.

  3. Bala says:

    Tom – Also wanted to ask you..

    The standardisation also has an impact on workforce skill planning. In economies of scale, standardisation leads to specialisation. Even in Toyota, I hear they had specialisation.

    How do the workforce supposed to work in economies of flow?. Are they specialized or generalized or both?..Your views?

  4. Stephen says:

    I agree about the need to focus on flow, delivering value and limiting failure that creates churn.
    I have just ordered some plumbing parts online and so far I have experienced three major failures in the process that have generated significant churn (across what seems to be a complex supply chain). Unfortunately this churn was created by humans not doing their job properly, e.g. failing to manage expectations as promised on stock control, and just putting the right parts in a box.
    Taking people out of the equation all together, shortening the value chain and reducing variability can be a good thing, in terms of achieving quality and reducing human error.
    I like systems where – as a customer I can do as much as possible, as easy as possible without having to speak to anybody or god forbid have to ring a call centre. Amazon seems to be very good at providing high volume efficient services, excellent service and with low human engagement.

    • Tom G says:

      Stephen – good points, and great first-hand description.

      Your note about “low human engagement” is probably the key here – in both senses of ‘low human engagement’. An over-standardised system with poor match between contextual variability and the variability are allowed to address results in people becoming almost completely detached and demotivated from the work. In an all too literal sense, they lose ‘response-ability’. As Seddon says, the management-myth response to that is to crank up the automation – yet there’s always going to be some key part of the variability of the system that can only be resolved by real-people (such as, in your example, actually putting plumbing-parts in packing-boxes). And the more the automation is ramped up, but doesn’t address the variability, the more demotivated the people are going to become, which leads to more resorting to automation: a classic vicious-spiral.

      Note that you said that “I like systems where as a customer I can do as much as possible” – in other words, where you have direct ‘response-ability’, and not need to rely on others. Which in a way is good, but that also means that you need specialist-knowledge in order to know what plumbing-parts (in this case) are required. That’s another risk in the overall system that could cause further failure-demand – and your cost this time! 🙂 – perhaps not such a good design or outcome, then?

      There’s a lot we could discuss here… 🙂 – but something to play with for now, I’d hope?

  5. Stephen says:

    In the end I came to the conclusion that every system needs to have a feedback loop to support improvement. Those systems (IT, Human or otherwise) that don’t are the worst to deal with, as one knows in a system without an active feedback loop – problems will continue. Feedback and even perhaps co-creation could enable proactive elimination of churn and bad customer experience. Like John says I have also worked with organisations who complain about call volumes, yet they have no idea why people actually ring them up, so some very fundamental things can be forgotton.

1 Pings/Trackbacks for "How not to use IT in services"
  1. […] Re-thinking IT  on loistava John Seddonin keynote-esitys vuodelta 2010. Olen katsonut sen kaksi kertaa vaikka en juuri jaksa katsella videoituja esityksiä. Löysin linkin siihen tästä How not to use IT in service. […]

Leave a Reply to Tom G Cancel reply

Your email address will not be published. Required fields are marked *

*