Posts Tagged ‘public services’

The Non-Absorption Of Variety

January 23, 2014 6 comments

Update: Thanks to input from “fatjacques“, the quotes below can be attributed to Jon Seddon

A few days ago, I clipped a bunch of text from an article I read on computer-provided public services and put the words into a visio scratchpad page. However, I forgot to copy & paste the link to the article. Thus, I can’t give proper attribution to whomever wrote the words and ideas that I’m about to reuse in this post. I’m bummed, but I’m gonna proceed forward anyway.

Consider the computer client/server model below. In the simplest case, a client issues a request to fulfill a need to the server. The server subsequently provides a single response back to the client that fulfills the need. The client walks away happy as a clam. Nothing to it, right?


Next, let’s assume that the client needs to issue “k” requests and receive k responses in order for her need to be fulfilled:

multiple transactions

From the bottom of the above multi-transaction graphic, you can infer that the service provider can be “implemented” as a person or a software program running on a computer (or a hybrid combo of both).

With the current obsession in government about “reducing costs” (instead of focusing on the real goal of providing services more effectively), more and more public service people are being replaced by computers and the buggy, inflexible software that runs on those cold-hearted, mechanistic beasts.

Since computers obey rules to the letter and, thus, can’t absorb variety in real-time, service costs are rising instead of declining. That’s because each person requiring a public service likely has some individual-specific needs. And since the likelihood of a pre-programmed rule set covering the infinitely subtle variety of needs from the citizenry is zero, employing a computer-based service system guarantees that the number of transactions required to consummate a service will be much larger than the number of transactions provided via a thinking, reacting service person. What may normally take a single transaction with a flexible, thinking, service person representative could take 20+ interactions with a rigid, dumbass computer.

But it’s even worse than that. In addition to requiring many more transactions, a rule-based computer service interface may totally fail to complete the service at all. Frustrated clients may simply give up and walk away without having received any value at all. Miserably poor service at a high cost. Bummer.

Good services are local, not industrial, delivered by people, not computers, who give people what they need. – Jon Seddon

<span>%d</span> bloggers like this: