Entidad Relacion

GOAL
To place the acquisition of hardware and software in perspective and to proceed rationally in evalu-ating and financing acquisitions and in negotiating contracts.
HIGHLIGHTS
General Considerations Basic guidelines and precautions establish a foundation for the acquisition procedures.
Obtaining Proposals Comprehensive statements of user inten-tions and requirements permii vendors torespond with realistic proposals.
Evaluating Proposals justitiabl, frorn attention to the worth of many factors, with judgement assisted by quantitative methods, not by "seat of the pants" guesses and mistakes.
Financing the Acquisition Techniques are available to make the rent-lease-purchase decision on a sound financial basis.
Negotiating the Contract Sincere buyer-seller efforts to obtaina "fair" contract minimize later conflict and frustra-tion, lessening the likelihood of litigation.
Software Acquisition This procedure is similar to that used for hardware acquisition, but it has its own spe-cial guidelines and precautions, personnel. When users make their own choices, all sorts of incompatibilities and inefficiencies are likely to result Further, when users actually acquiretheir own hardware and software, many price discounts are unavailable to them; they also lose the negotiating power to eliminate such undesirable features as copy protection. Two factors make rational acquisition even more difficult: one is rapid technological change and the other is political, the pressure to "keep up with the j o neses ." In the early history of computer use, major changes inequipment and operating systems occurred every two or three years. Minor corrections and enhancements were necessary durint, this time. But present equipment and operating systems usually require several major modifications a year. When changes are made this frequently, adequate evaluation of the latest inno-vation is practically impossible. But is it really necessary? No doubt advantages are gained:how-ever, can they be delayed a month, a year, maybe two years? If so, who keeps pressuring for changes? It becomes apparent that the problem of frequent technological changes is to a large extent actually part cf the second p1obli, iig up wiLli the J oneses. The attitude that what is ordered today and received tomorrow was already obsolete yesterday must be killedgiven a quick and permanentdeath. This attitude makes adherence to a rational acqui-sition process impossible. It also creates its own particular problems. It results in acquiring un-proven, errorprone equipment and software. Those who have used equipment released too soon do not have to be cautioned about hurried ac-quisitions. Personnel in data centers blessed with hurriedly acquired equipment have observed tech-nicianseyeing the innards of the equipment, hold-ing a soldering iron in one hand and a wiring diagram in the other. It is also common for the • programmers in user organizations that have re-ceived newly- released vendor software to daily notify vendors of software deficiencies. The lesson to be learned from these experiences is that equip-ment and software must be allowed to mature, and at the vendor'sexpense. Two of the culprits fostering the quick ac-quisition attitude have already been identified. The vendor salesman wants to make sales. Just as a car salesman does not want to know that your present, one year old car is running well, and wants to sell the latest available, caring little if it actually functions better or poorer, thc computer salesman also wants to make a sale. 1 he secondculprit is the technician who wants to use the latest hardware available after all, how would it look on a resume to be associated with "obsolete" equipment. There is a third culprit: the user department manager who knows little about data processing, but knows enough to affect acquisition decisions, to pressure the acquisition of the latest, talked-about piece of equipment. An editorial in the...