FEDSIM

When the cost of a computer installation reaches some threshold value, a CPE program may be examined as an investment problem. The installation costs include all computer and peripheral equipment; supplies such as cards, tapes and paper; all computer operations personnel; and any systems programmers that are used solely to keep the computer system operating. The value of the system's products must be established. Where no price is already associated with existing products, a break-even price per customer-ordered piece of output must be calculated and assumed as the start-up value. Once a system's cost exceeds its value, or value could be higher if the system could produce more salable products, CPE is needed. When value exceeds cost, but cost is high, CPE aimed at cost reduction is in order. As long as no value is associated with the system's products, there will be no real cost-reduction motivation to attempt to improve a system's performance (except, perhaps, as an academic exercise).

B. PROBLEM DRIVEN DECISION

More typical of the reason most CPE efforts are begun: another set of applications are to be added to an alreadybusy computer system; projected workload growth was an underestimate; the director of operations says he needs another or a larger computer; etc. Someone must look deeply and carefully into the way that existing resources are being applied to meet existing demands. Then the demands and resources must be aligned so that room for growth is available. A simple example may be seen that really made a substantial difference in work performed at no real change in products produced: Α system of 14 batch programs that had been operational on various equipment for nearly 16 years was modelled using a simulation package. This system ran an average of 4 hours and 30 minutes and interfaced with several other systems so that neither in

puts nor outputs could be changed. Several proposed changes were tested on the simulator. Two very simple changes were found that made substantial differences in the system's performance: first, the programs were allowed to run simultaneously (multiprogram) wherever possible; and, second, records stored on disk were blocked to the average track size. The average system run time went down to 2 hours 5 minutes giving better than a 50% reduction each time the system is run. Total CPE project time was about six manweeks; five in the simulation phase and one to alter and test the programs. No magic or profound intellect was involved in this effort, just a thorough examination of the demands and

One of the worst ways to start a CPE effort is to purchase a hardware monitor and assign a person to use it to "do good things". Many starts have been made just like this and few, if any, have succeeded. The monitors are stored away, collecting only dust. It is much more reasonable if specific systems are identified for analysis with modest goals set such as decrease the time that is used by one old program by 5%; or, document the flow of jobs form the input desk to the output window and reduce the total turnaround time for one large job by 5%. No sophisticated tools are needed and any standard time study text will provide guidelines for the test. What these types of projects allow a manager to accomplish are, first, operations personnel become aware of a systematic improvement effort; and, second, recommendations will be made regarding information that is needed, but very difficult to obtain. Setting only one or two simple improvement goals causes unknowns to become visible. These unknowns may then be categorized into application areas for solution by specific CPE tools or techniques. The usual result of these initial efforts is establishment of a systematic analysis of the accounting package information and some physical rearrange

Implementing improvements is often more difficult than identifying improvements. Nearly all significant improvements require either programming skill or a background in systems engineering. Since systems programmers usually evolve from applications programmers, system men are ideal CPE specialists. A systems programmer with a field engineering history is even better. Education in a scientific discipline usually helps a person to examine situations systematically. A scientific education nearly always exposes an individual to fundamentals of mathematics and statistics. These traits--systematic thinking and knowledge of math and statistics--are also necessary for a CPE team. An additional feature that adds immeasurably to a CPE team's effectiveness is an academically diversified background. Reasoning here is like in any other developing field--the broader the investigator's background, the more likely that parallels will be seen in other fields where similar problems have already been solved.

B. TYPES OF PEOPLE

Considerable amounts of nearly original or, at least, innovative thought is a major part of any disciplined investigation. (And the CPE team will indeed appear to be investigators if they are properly placed in the organizational structure.) Picking a person and making him think as a routine part of a task is a nearly impossible approach. It is far better to pick a reaearch type who takes every assignment as a challenge to his thought process. (If no researchers are available, pick a lazy person with the experience and education mentioned earlier.)

Next, and at times most important, is a person who can explain and convince. Perhaps an "evangelist" would come closer to describing this person than "salesman", but "evangelist" would be a misleading outline heading. (That is, no divine guidance is necessary for CPE success--it does help, though.) This person is particularly important at the beginning and end of each CPE project. The idea of performing each project usually needs to be "sold" all the way down to the lowest involved working level. In fact, to be of lasting worth, it is more important that these working level people be convinced that CPE is worthwhile than that higher management be so convinced. Further, a sales type is essential when a project is completed (to make certain that those responsible for authorizing implementation of team recommendations are thoroughly convinced to do so). Unless changes are made, the CPE effort will be wasted.

This

As a CPE team must produce useful work in a timely manner, a worker is a must. is the one individual who should be full time in the CPE field. He need not be particularly well educated or intelligent but he must not be lazy. He will probably be both the easiest one to find and the least expensive to pay. This is the team member who should have the strong system programming background as he will be the one that will sift through reams of output and determine feasible changes in programs.

go into CPE based on return on investment (as opposed to an immediate operational problem) it is certainly more beneficial to develop the CPE capability in-house. If the CPE need is immediate and if you have no capability in-house and can't hire a proven performer as a regular employee, then the only alternative is to use a consultant. There are certainly cases where a return-on-investment decision requires that the CPE investment be less than the cost of an established in-house effort. Such cases could be handled by consultants (although these aren't the jobs consultants try very hard to get...). As a general rule, solve immediate onetime problems with consultants. Solve immediate, but general problems with a consulting contract that requires the consultant to train your in-house CPE team. Solve continuing, non-urgent problems totally in-house. The suggestion here is no different for a CPE team than it would be for any other effort the best way is in-house.

3.

-

ORGANIZATIONAL PLACEMENT OF THE CPE

TEAM

Let's assume here that computer system expenditures are large enough to justify a continuing 1 1/2 - 2 manyear CPE investment per year on an in-house basis. (In the consultant case, the following could be put in terms of "Who should the consultant report to?").

A. LINE VERSUS STAFF

A CPE team performs a staff function: it investigates existing methods, finds and recommends alternative methods, and outlines ways of implementing methods. Although the team must be able to implement any recommendation, it is usually a misallocation of scarce talent for the team to do this. Usually, and particularly in very large data processing environments, the CPE team will periodically be challenged (generally by a middle-manager in applications programming surroundings) to do the implementation job themselves. About every 8 to 12 months, this should be done. In the process of implementing its own recommendations, the team not only gains operational credibility, it also has the opportunity to sharpen and update the team's own programming (or systems design) skills. This keeps the CPE team from becoming a group of former experts. And this is important.

report to the corporate-level controller. This placement insures that recommendations that are accepted will be implemented. Also, it will encourage the team to view their activity in a cost-benefit light. The more cost conscious the CPE team, the more likely that sound recommendations will be made. Unless the data processing center is extremely large, the CPE team should not report to the manager of data processing. (Extremely large: more than three separate and different computer systems and monthly least cost--or equivalent--of more than $100,000.) If there is a good argument for using consultants continuously rather than in-house personnel, it is in this reporting authority region: A CPE team is really a working level activity. It is not customary to have this type activity reporting at such a high level. However, it is customary for consultants and outside auditors to circulate at the working level and report at very high management levels. Except in cases of very small companies (the president acting as data processing manager), company size has little to do with the CPE team's organizational placement. It is more a matter of scaling the CPE effort to match the computer effort, which is generally dependent on company size.

This is the CPE team's license to operate. When duties to identify improvements in computer system operations are assigned to a group outside the direct control of the computer center manager (as recommended earlier), it is mandatory that clear notice of the team's operational arena be given. This notice should be formal (written) and signed by the highest possible corporate officer. Such a notice will be a charter or license to become involved in even the most routine aspects of providing computer support. The charter need not be long or particularly specific. General direction is usually better because it's never known ahead of time exactly which areas will produce the most plentiful savings. The ideas regarding system bottlenecks and workload characteristics that grow in the computer center without benefit of CPE tools, are almost always wrong. (Explain: scientific vs. business mix, printer-bound, etc.) A charter should include, as a minimum, the following statements:

"No new programs or systems of programs and no substantial changes to existing programs are to be implemented without first having the design or change reviewed by the CPE team. If in the CPE team's opinion it is necessary, the design or change must be simulated to predict its impact on the existing workload and to test any reasonable design alternatives before committing resources to programming and implementing the system or change.

"Before ordering new equipment to replace, to add to, or to enhance existing equipment's speed or capacity, the CPE team must be called upon to measure the levels of activity and contentions of the system or portions of the system that would be affected by the new equipment."

This type of charter will allow the team to examine both existing systems and proposed changes before new workloads or equipment acquisitions are committed. Determining the impact of such changes requires a thorough knowledge of existing workloads and systems. The benefit from this initial learning phase for the CPE team will be significant: it is almost always the first time that a review of all facets of the computer center's activity will have been attempted by knowledgeable and impartial persons. This phase is, in itself, sound justification for establishing a CPE team.

D. CONTROLS

Since a good CPE team that is properly placed in the organization will represent a high level of technical competence and have the endorsement of upper management, there will be a tendency to react quickly to the team's suggestions. It is, therefore, important that rather strict controls be established to insure that the team follows a total project plan (more about this later) to its conclusion before discussing possible recommendations with those who will be implementing the changes. Otherwise, there may be changes well underway before all aspects of the changes are examined. And these may turn out to be unacceptable changes when everything is considered. It is quite easy to avoid this situation by adding a statement to the "charter" that establishes a need for written directive by some specified manager (above the CPE team) before any recommendation is to be implemented. Whenever possible, management should insist that the CPE team provide at least two recommended approaches to the solution of any problem. And the approach should be selected by a manager above the CPE team or within the area that will be most affected by the recommended change.

4. PROJECT ADMINISTRATION

A. JOB DESCRIPTIONS

The formal writeups that cover CPE team members must mention the need to (1) work with documentation describing the logical and physical flow of signals through the system and its components; (2) perform measurement analyses and coding changes of applications and control programs; (3) install or connect such CPE

In

A CPE team just as any other group of employees, must be expected to produce results that are worth more than they cost. A detailed listing of responsibilities and procedures will be given in a moment, in classical management terms. At this point, it is enough to say that the team is responsible for "paying its own way." the early start-up phase, it isn't reasonable to demand this of the team. But, by the end of its first year of existence, a CPE team that hasn't documented savings equal to or greater than its costs should be dissolved. By itself, this is a heavy responsibility to meet.

These will be the only real (tangible) product of a properly run CPE team. The changes (except in the rare cases mentioned already) will be made by other programmers and engineers. Only by carefully and completely documenting each project can the CPE team progress in an orderly manner. A format for project reports that has proven useful in several environments is that of the classical "staff study": Purpose, Scope, Procedure, Findings, Conclusions, and Recommendations -- preceded by a short summary of major findings and recommendations. Hopefully, the entire report, but at least the summary and recommendations, should be completely "jargon" free. (The best report is worthless if only the authors can understand it.)

To make certain that the full impact of this project administration section has been made clear, a few minutes will be spent on an exhaustive listing of the responsibilities of a CPE project manager. First, it is pointed out that if the CPE team is large, or if team members have specific skills that not all team members have, each project or study may have a different project manager. Each project manager is responsible for the technical content and conduct of the study. His ultimate responsibility is twofold: to the managers that receive the team's recommendations and to the individual or group who will implement the team's recommendations. For lack of a better term, these two groups are referred to as the "customer". The individual CPE project manager is responsible for:

will be met.

7. Establishing quality control procedures. 8. Thoroughly understanding the kinds of management abilities that will be required in a project.

9. Determining the quantity of management required in a project.

10. Determining what must be provided by all parties involved, e.g., sutomer, other suppliers.

11. Knowing what is needed to

"solve" the problem.

12. Understanding the customer's problem and translating it into a solvable CPE problem.

13. Insuring that a clear, consistent, and appropriate plan for each study is produced.

14.

Knowing how the results of the study will fill the customer's needs.

15. Insuring that the planned approach to the project is logical and realizable.

16. Understanding the details

5.

cost control.

Exercising positive