From: John Conover <john@email.johncon.com>
Subject: IT uses
Date: Thu, 12 Aug 1993 02:41:46 -0700 (PDT)
Let me explain what I am doing with the archive/retrieve/info programs that are being developed. I am attempting to automate a lot of project administration/execution. Let me tell you why. I will cite the failure of IT at General Motors, (IBM is a similar failure,) as a reason to not do it the way they did. In the mid 80's, GM decided that IT was the way to go. It purchased EDS from R. Perot, made Perot a bigshot manager, and put a terminal on all of the middle managers desks (all 18 levels of them.) After an outlay for direct expenses totaling billions of dollars, and untold fortunes in indirect costs (training, lost data because some pressed the wrong button learning to use the system, etc.) nothing really changed. The org. was still a clumsy, bumbling giant that could not get out of its own way. This is a classic example of how not to automate admin. If you stand back and look at why the GM implementation was a failure, you can see that the problem was that although they automated memos (and did away with paper) the decision process that determined the organization's agenda was really the issue-and they did nothing to enhance the efficiency of that. (A key failure.) Let me elaborate. Consider that the IT system at GM reduced the time of a memo to be routed from 2 days to seconds. But the action required to address the issues in the memo still required months ... well you get the picture. The GM admin. was/is a marvel of efficiency. Look at it this way. (The numbers quoted above are real numbers, BTW.) 60 days divided by 18 levels of management, means that each level responded to the issues addressed in a memo in a little over 3 days, including week ends and holidays-very impressive (GM was proud of these numbers.) The question is, how do you speed up things, and still maintain order and control of agenda in a large organization. Obviously, the number of levels of management must be reduced. But if you eliminate some of the levels of management, who is going to control/administer things? Who is going to enforce the discipline of a consistent and continuous agenda? Won't important things fall into cracks? The answer is yes. (BTW, this number of levels of organization is justified at GM, they actually, really do, need this many levels to coordinate things.) Note that the flow of information in management was not the issue (GM's failure proved that.) GM addressed the wrong issue, and obviously, other organizations, irregardless of their size, have the same issues to address. IT must address the issues of agenda/project execution, and the decision making process (as opposed to being an information provider.) This is an important concept. Let me elaborate on this. The traditional reason for memos is the formal documentation of the decision making process-who decided what and for what reasons.(Memos have nothing to do with communication-they are inferior to the telephone-in all respects-except documentation.) The reasons that we document the process is for accountability, so we can hold the decision makers responsible for their decisions-and make sure that the decisions are executed appropriately. Or to put it in other words, really what we are doing is preserving a paper posterity, or history, that we can do a literature search on in the future, to put into perspective, the organization's agenda. But this can be done electronically (which is a key point.) It is the organizational agenda that is the issue, and NOT the information that flowed in the execution of the agenda. It is a subtle difference. The way that you put into perspective what is going on in an organization, is to search the communication flow for context (ie., agenda,) and not for content (ie., information.) This is a key point. If we make a corporate archive (perhaps distributed throughout the organization,) that contains pertinate information on all the decisions that are addressed (ie., an email database archive) in the organization (ie., we store the information,) AND, we permit realtime automated literature searches of the database, (ie., we can put the information into context,) then we can do the same thing-just with incredible efficiency. (BTW, by context literature search, I mean a full text retrieval system-one that can be cross-indexed, and collated on demand.) The archive/retrieve system that is being developed is such a system. In point of fact, if you use the archive/retrieve system on machine "john" you can see the thinking that lead to me writing this. (As a simple example send an email to retrieve@john.smos.com, with a Subject: retrieve lapyun.) Kind of neat when you think about it. -- John Conover, john@email.johncon.com, http://www.johncon.com/