Wednesday, 14 April 2010

What is Systems Thinking?

I have just finished reading the book “Systems Thinking in the Public Sector; the failure of the reform regime and a manifesto for a better way” (2008) by John Seddon, Triarchy Press, Axminster, UK. This book has received good reviews from politicians, seniors civil servants and specialised journalists. And, indeed, Seddon's understanding of systems thinking is compelling; it makes apparent through many examples in the public sector the always present tendency to fragment policy implementation. In particular his focus is on the current tendency to fragment services between the front end work and the back room support. He illustrates abundantly how front end civil servants take off their sight from customers’ request by passing them to back end workers. No one person or team deals from the beginning to the end with the particular customer, fragmenting the service and leaving in no one’s land responsibility for its performance. The voids in between the end-to-end time for the service grow and grow, transforming a service that could have taken days in one that takes months. This kind of performance is a consequence of the targets imposed to local providers by central government (the regime in his words); these targets are focused on performing activities rather than on the purposes of the service. An activity can be the number of customer calls that are discharged within a certain time, regardless of whether this discharging meant satisfying the client’s needs or not. Following Deming's work Seddon argues for a statistical measurement of the system's capabilities to work out what the current configuration of resources permits the system to do for its customers rather than for the civil servants in central government.

He makes the very useful distinction between failure and value demand. The statistics he gives are frightening; most of the activity of civil servants is responding to failure and not adding value to the client's needs. Seddon's argument, following Toyota's experience, is that a focus on the value adding flow of the service is the essence of systemic thinking. For this he argues it is necessary to understand the customer's needs. For public services, perhaps differently to manufacturing activities, the variety of these needs is very large indeed and it is necessary to design a service that absorbs this variety rather than trying to constrain it through predefined processes. People suffer as a consequence of this predetermination; the service delivery takes too long, costs are too high and the available resources are squandered to the detriment of better services. The purpose should be offering services that match the customers' variety. It is essential to understand in depth these needs and organize the activities' flow in such a way that they match these requirements. And, in his view, the use of IT for these purposes has been counterproductive in recent time. Usually this technology has reinforced the operation of badly designed processes.

He is aware that changing the regime is almost impossible; the only option is dismantling it. The rules and legislation in place make it very difficult to alter the service delivery procedures in place. Service providers are torn between satisfying counterproductive targets and being assessed poorly by contrived inspections. The whole machinery for service provision is inadequate and squanders a huge amount of resources. In spite of these views he ends up the book offering a list of situations where the use of systemic thinking has produced significant improvements.

Though my overall assessment of the book is positive I think that it offers a superficial view of systems thinking and little methodological guidance to use it. This is paradoxical since throughout the book Seddon insists that the problem with the regime is that for policy implementation offers no methods beyond the dogmatic delusion of what he calls deliverology. For those being initiated in this way of thinking the book is useful but there are some issues that need further reflection:

-Centralisation-decentralisation; which structures make beneficial the sharing of resources? No doubt fragmentation is a risk when a service process is divided between front end and back end activities, but the issue is how to overcome this fragmentation at the same time of making possible the sharing of scarce and expert resources.

-How to absorb front end variety? Accepting variety face value is likely to overwhelm service providers. Service providers must find ways of limiting this variety without hindering the main purpose of the service. In the end there must be a trade off between accepting customers' unconstrained variety and restricting it with ingenuity to avoid being overwhelmed by its proliferation. Variety engineering is a key issue in service provision that should take into account purpose, resources and acceptable performance.

-relevance of IT in service delivery; no doubt there are multiple examples of a counterproductive use of ITs. However Seddon's advice to turn off IT changes to understand and design work as a system and to 'pull' the necessary IT when the new design is stable, makes apparent a lack of appreciation of the co-evolution of service processes and technology. Ingenuity in the design of services is deeply related to technological changes and new processes should take into account these new technologies. Politicians, experts and civil servant need this ingenuity badly in their own spaces of action.

2 comments:

HC said...

I enjoyed your analysis of John Seddon's book although I argue that the method John proposes absorbs variety in demand neatly.

Not only that. The method provides mechanisms through which changes in demand variety (in particular predictable demand) are detected quickly and then designed into the system.

Raul Espejo said...

Thank you for your comment. Most likely there is much that John and colleagues must do with clients that is not apparent in the book, however, can you be more explicit about the methods for variety engineering that you use?