Systems Thinking creating Business Value

We were very fortunate to have Professor John Seddon, lead consultant and owner of Vanguard, visit us last week here in Melbourne.

John is a leader in Systems Thinking for Services Organisations.  Under John’s leadership, Vanguard has developed a methodology (known as the ‘Vanguard Method’) that adapts the teachings of W. Edwards Demings and Taiichi Ohno for the service industry. The wisdom of Demings and Ohno has had great positive impact on the manufacturing industry over the past 40-50 years, and Vanguard have been able to emulate this success with many service organisations over the past 25 years.

In our discussions last week, we hit upon a topic that causes much frustration amongst IT professionals these days: as a profession, we have made great strides over the past 10 years in bringing quality software into production in a much shorter timeframe and with significantly less resources.  Agile principles, in particular, have helped organisations to get a much better return on their IT investment (in comparison to using a waterfall approach to software development).

Despite these gains, there is much frustration in the IT community regarding true Business Value.  John made what I felt was a pertinent comment: “Agile is doing the wrong thing faster”.  While I would argue that the iterative process that Agile engenders actually surfaces the wrong things faster (and therefore permits us to change track to building the right things instead), I agree with John that we need to be starting from a point that is much closer to perfect that we currently do.

Under the Vanguard Method, we are called upon to define the purpose of the system from the customer’s point of view, and then design the system against customer demand.  While these concepts are plainly common sense, it is remarkable how often we are asked to build applications that clearly do not meet these criteria.

In particular, there are two key areas that contribute to the failure of IT systems to deliver the gains that they are theoretically capable of producing:

  • Ignoring (and even automating) failure demand.  John defines failure demand as “demand caused by a failure to do something or do something right for the customer”.  A good example can be found with call centres, where “cost to serve” and “time to serve” are often (in fact, almost pervasively) key performance indicators.  These are false metrics, as unless the customer need has been met* during the call, the call actually failed to deliver value.  Under a scenario where the customer needs to call 5 times before the problem is solved (e.g. missed appointments, didn’t fix the problem first time, etc.), there are clearly 4 calls that represent failure demand in that scenario.
  • Sub-optimising end-to-end value delivery, by independently optimising steps in the process.  This is a conundrum we encounter consistently in software development.  For instance, we may optimise the way payments are handled for an online transaction, but at the cost of asking the buyer to once-again (possibly for the third time!) enter their personal details, etc. – even for existing customers.
The challenge for those of us working in the IT community is how to design and build the right software the first time (not just building it right).

Systems Thinking brings an approach to the table that can certainly help in this regard.  By focusing on demand, value & flow (rather than functional specialisation), and designing software to deliver on customer demand in particular, we have the opportunity to drive much greater value from (and avoid considerable waste in) our investment in IT.

* Obviously the service to be provided may need to be scheduled during the call, for later delivery of the service.  In that case, as long as the service is indeed delivered and completed to the customer’s satisfaction at the agreed date and time, the original call can safely be classed as being successful.

Advertisements