VPEC-T is based on a profoundly radical philosophy of plurality. Instead of a single centralized value system (as found in top-down command-and-control organizations), we expect to find a range of different (overlapping, conflicting) value systems. Instead of a single coherent set of policies, we expect to find complex interaction between different kinds of policies (commercial, security, safety, corporate responsibility, and so on). Instead of a simple set of routine events, the post-modern organization is faced with a dynamic set of emerging events. Instead of a rigid set of database records, systems content is rich and evolving. And finally, the whole human activity system is underpinned by a complex set of trust relationships between people and organizations.
If you’ve spent any time working and thinking in business and systems, these statements will probably seem like common sense. However, many twentieth century systems methodologies were based on simplistic assumptions – for example, that there should be a single ordered set of goals and objectives, completely and consistently driving all system activity; that there should be a single ordered set of policies, rationally decided by management according to best-practice strategic principles, and so on.
And in our working lives and elsewhere we are surrounded by systems that have been designed according to these simplifying assumptions – systems that are inflexible, that serve a narrow set of stakeholders and to hell with everyone else. Not just software systems (for example, badly designed websites) but all sorts of human activity systems. Think of the hours of passenger time that are wasted because airline and airport procedures are designed for the convenience of their own operations rather than for the passengers. Think of the huge inefficiency of healthcare and other public services. Think of organizations whose attention is almost exclusively focused on internal squabbling rather than building external relationships, and which only survive because their competitors are no better. Think of counter-productive targets and expensive white elephants and all the other trappings of bureaucracy. These are the products of a certain way of thinking about business organizations and systems, which VPEC-T regards as obsolete and obscene.
So VPEC-T starts from the opposite assumption and expects trouble – there will be tension, there will be contradictions, and so on. Some people might think this is a pessimistic position. After all, wouldn’t it be wonderful if the world was as consistent and orderly and predictable as the 20th century methodologies assumed?
Actually I don’t think so – I think that kind of mechanical uniformity takes us towards the utopian nightmare described by countless science fiction writers. The plurality and richness which I find in VPEC-T is not only more realistic but also more human.
VPEC-T is not just a tool for making sense of complex human activity systems, but also a tool for communicating and telling stories about these systems. This is important for three reasons
- Firstly, because any single view of a complex system is necessarily unreliable and incomplete. We need multiple lenses and multiple voices to give us greater coverage of the issues, and greater confidence in the analysis.
- Secondly, because the philosophy of plurality makes it necessary for us to work collaboratively with other people, not only with different perspectives but with different value systems. So we need a language for collaboration.
- And thirdly, because of the reflexive nature of trust, which requires transparency of the models and assumptions on which the system is based. Ultimately, VPEC-T cannot be a private matter for a closed elite group of system designers without compromising trust principles.
See also POSIWID should be plural
Richard,
ReplyDeleteAs usual this is ver succinctly put. So thanks for that.
The observation that there is no single consistent view of a sufficiently complex system (and no I am not talking about the CUEC work that Roger Sessions is leading) is spot on. There are always ambiguities. There are always inconsistencies. Time and temporal considerations have a way of insinuating themselves into the discourse. Many pieces of data only have value at a moment. (Aside, I find web pages that aren't time stamped infuriating because I don't know when the information was valid, or when it was superseded).So, if we could even agree on a centralized definition of something, unless the value is time stamped we can't agree on its value.
Oh, and another thing time as continuum is rather important too. In unreliable systems, the order of transaction processing on 2 different sides of a system could be (and I suggest should be) different. The sequence that I write cheques and the sequence in which the bank processes them must be different because there is a series of inherently unreliable paths from my cheque book to the bank.
The balance I see when looking at cheque book stubs and the balance the bank sees as a result of processing transactions is very different.
So the question is what constitutes "the system" and where should we apply our lenses?
In my trivial banking example, the Value systems of the various participants are quite at odds. The banks view is "make as much out of fees/nterest/float from Chris as possible." Chris's view is, "Don't let the bank pocket any of MY MONEY." Completely conflicting Values in the same system. As each party changes the rules o suit itself, the other party has to respond in order to keep its values intact (up to and including severing the relationship). This is getting too long to be a comment, so I will develop further in a post elsewhere.
Thanks Chris
ReplyDeleteI would distinguish between unreliable and underdetermined. The fact that cheque-writing and cheque processing are not tightly coupled doesn't necessarily mean that the system is unreliable. It does however mean that you have to be careful to allow for the possible latency in your bank balance, which may add a complicating step (and extra transaction costs) to the management of your finances.
Sometimes the latency is in your favour, sometimes in the bank's favour, and you are right to observe that the bank's policies are more often aligned with the bank's values than with the customer's. (Not always perfectly aligned because policy design is an inexact craft, especially for organizations that are not intelligent enough to cope with evidence-based policy.)
Many people make a fetish out of speed, and persuade themselves that "If this latency were only cleared away ... it would be grand!" But the latency isn't itself the root cause of the problem; if the underlying value difference is not addressed, then (the chances are) it will merely emerge in some other way.