Role of IT - information technolgy - in next-gen companies

Judging from Toyota and "lean" processes, what is the appropriate role of information technology ("computers and networks") in the next-generation company?

If we assume that what we're building is, essentially, a massively-parallel connnectionist computing engine (consciousness) out of people and technology, we get the suggestion that the key roles are:
transparent communication at successively larger scales
coherence-building at successively larger scales, and
transparent interactions - ("phase-lock loops") across the components of the system.

Yes, computers will still be required for tracking the trillions of details needed to run a large company today, but that is, in Peter Senge's words "detail complexity." There's a huge amount of it, but it is, relatively, simplistic in nature aside from the amount of it. Enterprise computing knows how to do that, at least in theory.

What we are looking for in the next-gen company is the thing that ties it all together, that supports the feedback loops that maintain coherence and build integrity, the same way the circulating thoughts in the brain slowly emerge an "image" out of billions of "nerve impulses" from the retina.

This is "Technology-mediated collaboration" and more, so I'll call it "technology-mediated coherence." It is what allows "aperture synthesis" in large radio telescope arrays to act as if they are a single huge individual and the gaps "don't exist."

This is pretty much what the Institute of Medicine was recommending when it urged a focus on "microsystems" recently (see prior posts on "microsystems"). The point is that a small team (5-25 people) is capable of being "self-managing" if they can simply be given the power to do so by having access to information about what their own outcomes are. This information does not need to be packaged and interpreted at successively higher levels of management and then repackaged and distributed back to them a month later as "feedback." In fact, that doesn't help much. What really helps is speed. What helps is if they can see, today at 2 PM, how they have been doing collectively, up through, say noon. They can learn to make sense of the details, and don't need "management" to try to do that for them.

In fact, given the fractal density of reality, and the successive over-simplifications required to get data into a "management report", it is a certainty that we have something far worse than the game "telephone". What will come back down the line from upper management will bear little resemblance to what went up, breeding distrust and anger on both sides.

So the role of next-gen IT is to grab hold of the 'WEB 2" technology, that allows bidirectional websites to be both read and written by people, and that includes weblogs, wikis, and "social software" that encourages interaction and cooperation, including, gasp, "gossip."

This is the stuff that, in the right climate and context, can be converted into "social capital" and converging understanding by each employee as to what everyone else is doing and why.

Where there can be dashboards, they should best be very close, in both space and time, to the decision-making actors. Lag times are incredibly dangerous, and are the source of instability in feedback systems. (Imagine trying to drive a car with a high-resolution TV screen instead of a windshield, with a fantastically clear picture of what was outside the car 15 minutes ago. )

A relevant quote from Liker's "The Toyota Way" is this (page 94) where he is talking about the problems with large batches and the delays that go with such batches:

"...there are probably weeks of work in process between operations and it
can take weeks or even months from the time a defect is caused until the time it
is discovered. By then the trail of cause and effect is cold, making it nearly
impossible to track down and identify why the defect occurred.

The hugely complex computation of making sense of such data is what human brains and visual systems are built for, and tuned for, and that machines costing a billion dollars cannot replace yet. Just give people a VIEW into what is happening as a result of what they are doing, and they will, by a miracle of connectionist distributed neural-networks, figure out what's affecting what faster than a room full of analysts with supercomputers - in most cases.

That's the role that computation needs to look at - is close-to-real-time feedback in a highly visual form to the workers of the outcome of the work currently being done. (This is a step-up from Lean manufacturing visual signal system which is a signal to management that something is amiss.)

The "swarm" is capable, like any good sports team, of making sense of "the play" long before the pundits have had a chance to replay the video 8 times and "analyze" it. Yes, there is a role for longer-term, more distant view that adds value.

But what there is NOT is a way to replace real-time feedback and visibility with ANY kind of delayed information summary. All the bases must be covered, and long-term impacts and global impacts will not be instantly visible to local workers -- but they have to be able to see what their own hands are doing or they'll be operating blind. "Dashboards" with 1-month delays on them cannot cover that gap. Too much of the information is stale by the time it arrives. Both are needed. Local feedback for local news, and successively more digested, more global feedback for successively larger and more slowly varying views.

Another gentle introduction to control loops

So, my favorite reader tells me the diagram of the loop with 432 boxes or whatever "left her cold."

So, here's a little more gentle ramp up to that diagram I did yesterday. The classic model of "causality" is that one thing causes another thing. The "causality" goes only one way. B has no impact on A.

But, sometimes there is "feedback" and B does affect A.
Often, "feedback" is mistakenly described as "positive" or "negative". In control theory, feedback is just information. But since those terms are pretty common, let's review what the users mean by them.
P
Positive feedback (above). Things reinforce each other and we get an upwards spiral of whatever it is. Both sides chase each other upwards. A "virtuous spiral".


B keeps raining on A's parade, and after a while A gives up and stops trying. But, actually, feedback loops have many more different behaviors than those two. Here's a third possible outcome - an oscillating condition that keeps going in "cycles", like the economy or the number of birds in a given region.

Actually, again, in "control theory" the thing called "feedback" is just information. By itself it has no "positive" or "negative" content. All that meaning is actually supplied by some active entity, maybe a person, who has to interpret what that news means.

Take a new driver trying to keep the car on the road. He has a "goal", to stay in the right hand lane (in the US at least). He sees what's going on and responds by turning the steering wheel one way or another. (This is much more dramatic if he is learning how to drive in reverse and steer going backwards for the first time.)




OK, now to get from THERE to the picture I used or the format used in "control theory" textbooks, we need to identify a few more familiar parts and rearrange the pieces a little. Here goes. Let me add a "command" box with"turn left!", and a line called 'visual feedback'.

OK, so keep on unfolding, and add an explicit eyeball. (That's what that is supposed to be in the lower right). In general this is not always a visual feedback, and could be sound or tactile or whatever, so we break out a "sensor" of some kind (in this case, an eyeball).

And, finally we make the step to removing all my effort at drawing cars and people and roads, and get a very dry, abstract looking diagram that looks something like the one below. The"loop" is the part in green. The"controller" is a general term, and in this case, it's the driver of the car. Sticking off the loop, like some kind of side radical group in chemistry, are two boxes - the "goal" of the loop, and some external conditions that make life harder (usually), such as the fact that the road bends sharply to the left ahead.
In real life, there are some additional feedback paths if we look over a longer time window. For example, by picking the right controls of the steering wheel, the driver can pick one road instead of another, which indirectly changes the "road" box.

And, the thing that is following the loop around over and over is a very abstract thing - it's "control". "Control" flows, and like electricity, it can move through solid objects like current flows through solid copper wire. Control can happily leap from one medium to another, now being in a steering wheel position, now in a car position, now in light travelling to the driver's eyeballs, now in neural impulses going to the arm, etc. Control doesn't care who it hitches a ride from.

As I've said in earlier posts on this same subject, this makes it hard to find all the parts of a control loop sometimes. I trace out the parts in a person getting a glass of water out of a faucet in this prior post. (See "controlled by the Blue Gozinta")

OK, but why go to all this effort, you may well ask. The answer is that this can "solve" many problems for us. If we can rotate and stretch the problem around until we can see it as a control loop, then there are software programs that can tell us what could or will happen next, if we push here versus there. We can tweak and tune them. We can design them and redesign them. We can draw on a 100 year deep literature on "what goes wrong and why" so we know a classic problem when we see it. We can realize "Oh this is because we have a lag time between when we turn the boat's helm and when the boat gets around to responding" so we know what needs to be fixed or accounted for.

Or, it can help us design feedback-based interventions, as the IOM has suggested in "Crossing the Quality Chasm" for "microsystems" -- small teams of health care providers. I used a feedback model in my "Capstone" to inform the suggestion of what factors the diabetes team should be considering routinely and to be sure it forms some kind of coherent and complete set of topics while being as compact as possible.
Also, from control systems textbooks we can see quickly why "dashboards" have a very dangerous downside, if the data being used to steer an organization with is 2 months old -- and why that can tend to produce wild oscillations if it's used to steer by.

And, we can design "regulatory processes" and "regulations" that have a snowball's chance in a hot place of actually working, because we did our homework and computed the necessary numbers in the underlying feedback control process we're trying to tweak. Or we can realize there's no point in pressing there, because that point won't budge, and we need to save our pennies and find a better intervention point. We can model "what if" behavior.

That's what this is all good for. It connects a huge problem domain of public health to a huge solution set already found and in place in 'control system engineering" on the other side of campus. It makes the powerful analysis tools Engineers already use daily to design jet planes suddenly useful to redesign health care reimbursement policies. Etc.

As I've said before, to public health and control system engineers - you guys REALLY need to meet each other and form an alliance.