Micros in manufacturing; personal computers in engineering and manufacturing.
Nowhere is the rush to the PC more evident than in manufacturing and engineering. The costs of microcomputing are falling rapidly and acceptance of the advantages of the machines is rising. In order to keep you up to speed, we are launching ongoing coverage of the new hardware and software being offered, the emerging applications in metalworking manufacturing, and the thorny issues such as people and organizational problems.
In this first installment, Professor Miles Kennedy, head of management information/decision systems at a Case Western Reserve University, and Ian Sutton, VP of COADE, an engineering-software publishing house specializing in microcomputer applications, vent their views on ... Personal computers in engineering and manufacturing by Dr Miles Kennedy Associate Professor Weatherhead School of Management Case Western Reserve University Cleveland, OH Personal computers are powerful intelligence amplifiers that can significantly increase the efficiency of knowledge workers and raise their effectiveness. PCs can be used to facilitate retrieval of information, processing of that information, or its communication among groups who need to coordinate their activities.
Gains from computer use, in other words, can be reflected not only in greater individual performance, but also through synergistic improvements at the level of groups of workers where aggregate benefits exceed the sum of individual improvements. This last consideration is often overlooked by managers with a rather narrow and conventional view that stresses only the computational capabilities of computers and forgets their important role in the retrieval and dissemination of information. What do they really cost?
The adoption of personal computing isn't cost-free, however. First, there's the cost of acquiring hardware, software, and communication facilities. Second, there is the explicit cost of training users and the implicit opportunity cost of the learning curve effect. More important, in many cases, are some of the more subtle opportunity costs.
For example, any power that can be used for good will always have potential for abuse. An engineer who goes off the track with computer support can wreck far greater havoc than if he was unsupported. Better access to data can also be abused as an opportunity to compromise the legitimate technical secrets of the employer. Fundamentally, the best policy is to address the problem rather than the symptom.
In the first place, secrets should be made accessible only to those with a genuine need to know. Secondly, accountability should accompany responsibility--access to confidential information should be logged. Since this won't guarantee the safety of confidential information, a balance must be struck between the loss that could be incurred through disclosure and the loss in productivity caused by denying or impeding access.
An active security policy, nevertheless, is always superior to a passive one. Denial of access can be more risky than monitored access.
Another subtle cost is uncontrolled development. PC technology is in a period of dynamic change. Ill-considered actions and decisions today can preempt important future options. Policies for evaluating both acquisitions and procedures need to benchmark proposals not against the status quo, but against future alternatives that may be foreclosed by the planned decision.
This can be a fairly important consideration when selecting hardware. It's of greatest concern in selecting programming languages, data conventions, communication protocols and standards for programming, documentation, and operating procedures. Too many PC users are making all over again the same horrible mistakes made by data-processing departments one or two decades ago. Centralized policy should at least provide guidelines to help PC users within an organization to avoid such pitfalls.
These remarks suggest that asking the question, "Should engineers use personal computers?" isn't very sensible. The real issue is how they use them. Several choices are at issue here: Hardware selection, software selection, purpose of use, and mode of use. Each can be addressed by centralized and rigid rules or by a situation of total local autonomy. Neither extreme is sensible. The correct approach is to formulate policies that generate rules appropriate to varying circumstances.
A degree of uniformity in selection of hardware and sysems software reduces capital and maintenance costs, while facilitating communication and increasing shareability and portability of software and data bases developed by the engineer. Total uniformity, though, only will be economical in cases where the situations of all users are uncommonly uniform. Good policies, therefore, mandate a range of options. Policy is central, but its implementation should be distributed locally.
Likewise there should be guidelines on the purpose and mode of use. The responsibility for working within those guidelines should rest with the professional concerned.
Many MIS directors are deeply worried by the unplanned proliferation of personal computing within their organizations. The approach I recommend is based on a recognition and balancing of the costs and benefits just mentioned rather than the imposition of cookbook-type rules. Microcomputers and the engineer by Ian Sutton Vice President COADE Houston, TX Many engineers, their managers, and their data-processing groups are trying to determine what effect PCs are going to have on their business. One question that's raised often is can microcomputers tackle full-size engineering problems? The answer is an
almost unqualified yes.
We have, for example, full-size programs in areas such as finite-element analysis, process flowsheet simulation, and even civil engineering coordinate geometry. There are limits to what can be done with a micro, of course. Unfortunately, though, engineers generally underrate their speed and power.
Will micros save money? Again the answer is yes. For many large applications, such as design of frames or development of flowsheets, each run on a mainframe can cost a user up to $500; even short runs are usually in excess of $100. Given that most problems involve a series of case studies, it's easy to generate costs of many thousands of dollars for just one project.
In contrast, microcomputer software is almost always stand-alone with a single one-time price. Prices for engineering software range from $300 to $15,000; however, there are not many packages in excess of $3000 and so payback can often be in ridiculously short time spans, e.g., one month. Program reliability
Most general applications for a microcomputer (such as spreadsheets or word processors) were written from the ground up. In the case of engineering software, this isn't so. Almost all engineering PC products are a downloaded version of a mainframe product, which means such software is generally reliable since it has been proven on mainframes in commercial applications. Although downloading to a micro may change the appearance of a program, the technical algorithms won't be changed.
The fact that most microcomputer software has a mainframe big brother also means that it is quite simple to check. All an engineer has to do is take a problem and answer from the mainframe and repeat it on the mciro. Are micros enough?
If there's a soft spot with micros it's their run time. Subjectively, we've found most users find a run longer than about 20 min unacceptable. If a program routinely takes longer, then it should be left on a mainframe until micro hardware improves.
Most of the problems that engineering software for microcomputers generate are related to the com pany organization. The benefits of using this new technology are clear. However, the role of engineering management, third-party software vendors, data-processing groups and the engineers themselves will have to be redefined over the next 10 yers or so. Company standards
Until now, high-level engineering software has only been available on the mainframe (either time-sharing or in-house). This means that only software that has been authorized by the engineering managers and by the data-processing department can be used. These two groups ensure that company standards are maintained.
It's now possible for an engineer to completely bypass these authorities. He or she can buy stand-alone software for a PC, and there's no guarantee that anyone else in the company will know what is going on. If the software is inadequate, consequences obviously could be severe.
No company can allow unauthorized software to be used. If, however, the engineers are indeed bypassing the system, it may be a sign to management that there is some dissatisfaction with the existing software or that there are problems with obtaining computer line. Software exchange
In my opinion, this problem (and other problems as well) will be resolved by the MIS group setting up a system that is much closer to a book library than a centralized computer center. Engineers will check programs in and out using a "library card." One of our customers, a university, has set up an effective system of this sort. Also a major electronics company has developed a very sophisticated library. Before a program is purchased it's validated and checked by the MIS group.
This library will be similar to a book library in another sense. Now that software is relatively cheap and certainly much easier to carry around, the library will contain many books on the same subject. So the engineer will have a choice of programs depending on what he is doing. His manager coudl authorize certain programs for certain engineering applications and then the engineer will be free to use a "book" of his or her choice.
With microcomputer software, an engineering manager can't be sure that his staff is using the most up-to-date versions of each program. With a mainframe this problem should never occur. The latest authorized version will be the only one that can be accessed.
The MIS library makes sure only update programs are available and all older versions are withdrawn. Data and program security
Although it's difficult to quantify the problem, unauthorized copying of microcomputer programs poses another management dilemma. Once private programs and data are put on floppy disks they become easy to duplicate. It could be quite simple for a terminating employee, for example, to take programs or data to his next employer.
Many companies draw much of their business from some specialized calculation method or store of knowledge. The danger of losing that information to the competition is very real.
One approach is to say that sensitive software or data won't be downloaded to floppy disks. But, as the technology of doing it becomes easier and easier, this will be difficult to enforce. Simple, yet effective, policies such as keeping disks locked up must be rigidly enforced. The conversion effort
If a company decides to use micros for most of its engineering applications, it has two choices: Either downloading its private software to the PC, or purchasing the equivalent software.
Before attempting the former, the following problems should be considered:
* Microcomputers are still slow compared with mainframes; therefore, lots of "tricks" are needed to make mainframe software run on them. Ironically many o the best methods of doing this were developed about 20 years ago when mainframes were much more limited. For example, finite element methods require efficient use of memory on a micro. These were developed for the early mainframes and are now coming back into favor.
* Software needed for a conversion often isn't fully developed. For example, at our company most of our programs are in Fortran. We haven't found any of the Fortran compilers that we use with our micros to be completely satisfactory. As a result, we've had to change or modify them to meet our needs.
* It's difficult for a company to devote the resources needed to keep up with hardware developments. Within the last year alone, hard disks, mice, and color graphics have all become commercially widespread. More important for engineers, there have been significant developments with 32-bit processors and with larger compilers. Don't expect the rate of innovation to slow in the near future.
|Printer friendly Cite/link Email Feedback|
|Publication:||Tooling & Production|
|Date:||Jun 1, 1984|
|Previous Article:||Tips on saving deviant workpieces.|
|Next Article:||Machine vision to serve flexible systems.|
|Micros in manufacturing; personal computers and production control.|
|On PCs and LANs: tying the factory together.|
|PC-based CAD-CAM is on the move.|
|Computer chips take a leap forward.|
|IMP/RAYCHEM TO DEVELOP CIRCUIT PROTECTION IC'S.|