|
February 1998 Volume 8 Number 2 What Software Should I Buy
By George Johnson and Louis Malucci Among the questions most frequently asked of the APICS Industrial Inquiry Service are those relating to the acquisition of new software. Inquirers are apt to ask for "the top 10 MRP packages" or "what software," for example, MRP, "do the most successful companies use?" or variations thereof. They also may request software "evaluations." The APICS Inquiry Service can neither endorse nor recommend software products, nor consultants. It does not perform evaluations of software packages. What we can do is provide relevant sources of information which describe software packages. One of these is APICSThe Performance Advantage, which publishes software reviews. Another thing we can do is offer a few sample descriptions drawn from a CD-ROM-based directory made available to us by ICP Inc. There are firms which publish functional requirements (lists and descriptions of features which may be desirable in a system). These range from "standard systems" in book or loose-leaf form to diskette or CD-ROM form. Some of the computer-based versions are designed as semi-expert systems, where users respond to questions to define their own functional specifications. The functional specs then are used as a filter to screen the features of available packages, selecting a subset of the packages for detailed review by the client. What about published evaluations? Are they accurate and fair? Take for example, the writings of 15th Century monks that reside in a repository at the Melke Abbey outside Salzburg, Austria. Their theories have not changed substantially over time. By contrast, software evaluations can be obsolete within hours of their publication. Software is in a continual state of change. That which is described as a weakness or a flaw may already have been corrected in an update. It probably is disappointing for software developers to read a review of their software design describing weaknesses that have already been corrected. On the other side, potential customers desire accurate, up-to-date assessments of the packages they may integrate into their businesses. In lieu of an evaluation you could perform on your own, a suggested methodology follows. However, before getting into that, it should be said emphatically that, if you are pursuing an MRP or other software package because your factory is out of control, i.e., undisciplined, you may be making a grave mistake. Computerized systems such as MRP require (I should say demand) discipline. [A good overall discussion of this issue is "Manufacturing's Crisis: New Technologies, Obsolete Organizations," by Hayes and Jaikumar in the Sept.-Oct. 1988 issue of Harvard Business Review.] Inadequately maintained data, such as inventory records, open orders, bills of material, etc., can be fatal to efficient plant operation, more so than in a manual system. And if you don't have the time to react to the "exception" messages or recommendations, why bother running the system? A methodology you might consider for doing your own evaluation involves defining your requirements. Purchasing? Shop floor control? Financial interfaces? Multi-plant? Repetitive? Want to run on a micro, mainframe or midrange? This monthly magazine, in its annual MRP software review, lists more than 40 factors to be considered. Other references, such as "MRP II Standard System" by Landvater and Gray (1989), discuss such things as architectural issues, integration with other functions, how various modules function, etc. Decide which of these features are important to you. Some packages come with options you don't need now, but they can remain inactive without impacting your system negatively. Narrow your search to a meaningful few packages, perhaps 10 to 20. Have someone on your staff contact the package manufacturer or distributor and request a customer list. Indicate that you wish to evaluate the compatibility of this package to your operating environment. Ask for firms in businesses similar to yours, job shop, electronics, automotive, etc. If the software firm won't provide a list, consider this the first clue in your elimination process. For those who respond, call each of the listed customers on the telephone to ask their opinions, i.e., the strengths and weaknesses of the system. In many cases, they will respond favorably. First of all, misery likes company. Secondly, if the packages have flaws, here is one more potential user to lobby for those changes by a recalcitrant designer. (Can you tell there is scar tissue, here?) Based on the results of the interviews, select an even smaller sample, and request a personal visit to their plant to talk to the hands-on users, not MIS managers. Have them walk you through a typical day using the planning and execution systems. At this point you will get honest answers. For example, at lunch they may describe how they feel about the accounting interface. "The guy who wrote that module never saw a general ledger in his life. We had to rewrite 10,000 lines of code to make it work." Even here you need to be judicious in evaluating their comments. They may want to see the system as an exact replica of what they were used to in the old system. Another vital question to ask during your interview of the users of the software is: What changes have they (the users) made to the original package? (How have they customized the system?) This question is important because it relates to ongoing support for the system. Vendors typically support only their own packages not those which have been customized. Who owns the customized package in terms of support? Even if the vendor has made the changes for you, you may still have corrupted the basic design the vendor has successfully tested and which is used by other companies. Modifications made within a module may work successfully. But the interfaces between modules become the tricky part. Will data processed successfully sustain reversing, if necessary; for example, reversing a purchase order which interfaces with the accounts payable module and the general ledger? These are important elements to consider when evaluating vendors' software packages. By doing the above, you can make your own, well-informed judgments of the potential effectiveness of the system in addressing your own plant's requirements. We have discovered in our research several useful sources of information about MRP II and other application software packages. They are as follows:
Dear APICS: What is remanufacturing? Nabil Nasr, director of the highly regarded Center for Remanufacturing and Resource Recovery at RIT, characterizes the umbrella concept as recycling. Within this broad context he says there are three major types of activity: material recycling, remanufacturing and reuse. He agrees with the first sentence of the APICS definition as that of remanufacturing. The other two concepts he includes under the umbrella of recycling are distinguished as follows: Dr. Nasr indicates that some companies heavily involved in the recycling field may make further distinctions. For example, in managing its office equipment life cycles, one firm recognizes three levels of remanufacturing: Some references related to remanufacturing are cited below:
Copyright © 2020 by APICS The Educational Society for Resource Management. All rights reserved. All rights reserved. Lionheart Publishing, Inc. 2555 Cumberland Parkway, Suite 299, Atlanta, GA 30339 USA Phone: +44 23 8110 3411 | E-mail: Web: www.lionheartpub.com Web Design by Premier Web Designs E-mail: [email protected] |