ERP (MRPII) and MES Selection Process

Knowledge and Planning

The successful selection and integration of a new manufacturing software requires Knowledge, Experience and Selection Methodology. Without proper knowledge, experience, and methodology, half of the manufacturing software projects are terminated somewhere along the process. Of those that are implemented and reach the operational mode, 75% are subsequently rated poor by the users. The reason for these disappointing numbers are too often based on a lack of either knowledge, experience, or methodology.

Knowledge and Experience

Knowledge is knowing how things are supposed to work, if everything goes right. Experience is an understanding of the reality that the job must get done in spite of the fact that things can and do go wrong. Knowledge without experience can result in devising a seemingly perfect plan that proves impossible to implement. Experience without knowledge too often leads one to repeat the mistakes of others. Balancing the two assures proper selection of the system and successful implementation.

Methodology

Organized structured process for selecting a manufacturing software to meet the requirements of your company. Methodology doesn’t have to be complex to be effective. Get organized, focused, and keep it simple. The aim is to provide a framework within which many diverse yet interdependent activities relate in an orderly sequence.

Understanding Types of Manufacturing Software

There are three types of manufacturing software available for implementation and they are: MRPII (now called ERP), MES (Manufacturing Execution System), and Process Control software. MRPII is designed to manage: a. sales and customer service issues, b. material planning, purchase control, inventory control management, and c. accounting management. MES is designed to control production management ie: production planning, production engineering, scheduling and shop floor tracking, monitor quality process, and manage ISO process. Process Control software is used to control manufacturing machinery.

As a rule, MRPII suppliers do not get involved with MES and MES suppliers do not get involved with Process Control software. Most of the companies purchase MRPII software package and MES package and run them independently or integrate through custom programming to interface between the two.

As part of the manufacturing software search criteria, make sure to define whether you want MRPII, MES or both and define them accordingly.

Avoiding Failure

The concept of Manufacturing Resource Planning (MRPII) has been around for more than 35 years, and its most recent manifestation is Enterprise Resource Planning (ERP). Its technologies and approaches are nothing new.

More bells and whistles, more attention to user-friendliness, ever-widening availability of industry-specific functionality, and great leaps in the number of ERP/MRPII-experienced people have, created a mature technology.

A significant percentage of ERP (MRPII) & MES installations still fail either partially or totally. The key component in success or failure is the human factor; and unlike with machines, you can’t get people with technology built in. The lack of methodology and training is the major cause of implementation failures:

· Users are unprepared for the size of the task;

· System information flow is not defined;

· Upper management’s commitment wavers;

· System users are not committed to the implementation;

· Initial pains of implementation create resistance;

· Operational ignorance is unchecked;

· There is a lack of system data integrity;

· Saboteurs and general inertia take over.

To lessen the chance of failure, you must ensure that everyone involved recognizes that change is needed and act as willing participants in moving to the new world of manufacturing software.

Methodology for avoiding failure

· Management commitment through project justification, such as a detailed cost-benefit analysis that sets realistic goals with a realistic schedule;

· Management and user commitment in establishing project specifications. Both groups must agree on requirements. Users define how key business processes should flow, and what changes must be made in their departments to make them work;

· Both management and user recognize the positive effects of the new system. The first few months of operation will create some frustration. Be prepared for a temporary negative impact associated with implementing a new system.

Companies too often skip steps in the preparation and qualification process to save time and money. The one thread that ties together more than half of all implementation failures, is the lack of preparation and commitment to the process. Going through each step prepares your company for the change.

Management Role

It is important to understand what the proper role of management is in systems selection and implementation. Management must establish objectives and must stand behind the implementation team. Any more involvement is often inefficient. Management should do what they do the best – provide the backbone of the project, not the brains and muscle.

Management defines the business environment so the implementation team can select a software application that fits. Environmental issues include organization, structure, industry, policy, scope, and function.

The act of defining the environment need not be time consuming nor entail many details. It is more or less the answering of pertinent questions about business practices.

Management must look to the future, but not succumb to the temptation of opening themselves up to a much more complex installation. Systems should not be more complex than the business they are serving.

Selection Committee

The project committee will decide, within the bounds of the business environment, what the system must do and how they will do it. They will also evaluate what each software supplier can do.

The project committee should be composed of the following department managers: master scheduling and production control manager, materials manager, production manager, sales manager, accounting manager, and others. Members are those responsible for deciding how business is conducted – they define and enforce policies and procedures.

Justification

Cost justification is the first hurdle that a business system implementation project must clear. If this step is skipped or done haphazardly, negative results will continue to be felt throughout the course of the project. A good justification will be key step to garnering the management and user support to a successful installation. Support or justification won through realistic identification of the true costs and benefits of new systems will assure the proper management attention and involvement.

The best justifications match the project goals to the company’s business objectives. Following are some of the major elements of a justification model:

Benefits – There are two types of financial benefits: day-to-day savings that eventually aid the bottom line, and increased working capital (cash availability) resulting from reduced assets such as inventory and receivables. Also new systems usually cost less to operate than legacy systems.

Revenue and Profits – Revenues increase as a result of more responsive customer service; accurate forecasting and manufacturing scheduling; increased sales volumes; the competitive edge engendered by on-time deliveries made possible by better manufacturing performance; lower costs through increased quality and productivity; and having the right material at the right place and the right time.

Inventory Management – Inventory is the repository of many of the company’s past mistakes, and a vast resource of potential working capital. Better scheduling reduces inventory by taking delivery of the right material at the right time and preventing buildup of obsolete materials.

Purchasing control and more reliable scheduling reduces purchase prices and lead times. Fewer shortages improve manufacturing performance.

Costs – Capital expenditures, on-time project expenses, and ongoing support activities include:

· Application software and hardware, which – for the entire company – can cost from $50,000 to $500,000 (for small to medium size companies), even without modifications (if the application software is not developed for a specific industry);

· Modification of applications software, which potentially increases the risk and length of the project, in addition to having future cost implications such as custom code maintenance;

· Software and hardware maintenance;

· Communications equipment and installation;

· Education and training – including management, train-the-trainer, and hands-on as well as personnel costs (only incremental payroll expenses should be allocated to the project);

· Conversion of initial operating expenses, including the cost of parallel operations (not recommended), part-timers, consultants, and programmers (if modification is necessary); and

· Consultant and temporary staff expenses, until the new operating environment settles down.

Remember, a sound justification is a first important step to successful implementation. If you find your project is not demonstrably justifiable, consider not doing it. You may have overriding control needs, or a strong management drive for change, or customers require it, or the project will be done anyway. But if it is justified, management support will be a natural follow-on, not the missing factor.

Specification and Software Supplier Selection

Identifying detailed functional requirements is the most intricate task of the management and project committee. The specification commits users to the selection process. If they contribute in the specification process they have good chance of getting what they need. If they do not, they must realize that they have to live with what they get. Subsequently, they will judge systems based on their own requirements.

Preparing a detailed specification goes far beyond a list of requirements to present to a software supplier. It is the definitive statement of the system required to run the business. We all work in a box defined by our education, knowledge and experience. If you don’t want to just automate what you are doing today, you must look outside the box to find out what you don’t know. This is one of the major reasons for keeping an open mind during the software demonstration to see if there is a better or more efficient way of running the business.

The first step in defining specification is to break the job down into manageable pieces by business function. Specifications for each function can be defined with the help of experts in that functional area.

Perhaps the most difficult aspect of defining detailed functional requirements is determining how much detail is enough and how much is too much.

After gathering all the functional requirements, weigh them for importance. Throughout the specification process, the committee must stay focused on the important issues. It is easy to get sidetracked by pet projects of a vocal minority. With each issue, ask: Is it really necessary to run the business? If the answer is NO, spend time somewhere else.

In the case of inventory management or tracking material in production process, for example, there may be many systems that perform each detailed function, but there may only be one or two that perform it the way needed for your business (unless you are prepared to modify the software). These functions should be described by a detailed information flow and analysis and possibly used to disqualify suppliers in the phone, fax, written specification survey process, or during the software demonstration.

Request for Proposal

The Request for Proposal (RFP) must do the following: a) describe your company to the supplier; b) provide understanding of the needed software capabilities as it relates to functional requirements; c) solicit bids (price estimate based on system requirements).

RFP should contain the following information:

· Introduction of the company, the industry it serves, and the scope of the planned systems. Describe only what the supplier needs to ensure they understand the framework in which their system will run.

· A summary reason for changing the current system.

· Criteria that will be used to make the selection ie: the rules of decision making.

· Detailed functional requirements (survey form), to which you want the supplier’s capability response including all the functions you must have.

The detailed functional requirements (survey form) above should be a subset of those requirements developed as part of your specification process. The specification and RFP processes have different goals. The specification process allows users to define everything they want the systems to do, irrespective of availability from any vendor. The RFP should ask questions necessary to understand the software product’s capabilities and allow you to select three or four suppliers for software demonstration from a large list of suppliers.

You will find the suppliers often suggest workarounds for some requirements different than originally envisioned. These are usually worthy of consideration. Decide on a case-by-case basis whether or not your need will be satisfied. The goal is to find a software package with the least amount of workarounds but realize that some may be needed. Suppliers deal with many variations of the manufacturing process more often and more widely than do their customers. They’ve seen it all, so don’t be afraid to consider workarounds as good or better than the approach you had in mind. Use their expertise.

The average supplier will spend 2 to 6 hours answering the document, so make it something that can effectively be dealt with in that time frame. Don’t ask the supplier to prepare more detail than you are willing to review when it comes back. If you want a quality effort, keep it concise and focused and you will save time for all involved in the selection process.

Software Demonstration

The first consideration in software demonstration is how many supplier demonstrations to conduct. Remember, the value of the software demonstration process often works in inverse proportion to the number of suppliers included. Experience of most of the customers has shown that optimal results are gained when three to four suppliers participate.

Prepare a demonstration agenda, a list of system functions to be exhibited. The agenda should contain from 50 to 100 requirements depending you are looking at MRPII or MRPII and MES together. Although you can set the sequence for demonstrating these functions, it is usually better to submit an agenda at least a week ahead of time and let the demonstrator set his or her own sequence.

The agenda is also the demo scorecard, listing the capabilities stated by the supplier. Evaluate both truthfulness and their understanding of the requirements. Record any changes to the supplier’s score throughout the demo and review these observations as a group afterwards.

Ask questions as the demo progresses, don’t hesitate to bring up all potential critical issues of specific functionality. How is the system designed, what industry did the designer had in mind when designing the software or is it a general purpose? Why is this software more likely to solve my issues? "What is the background to the designers and technical support personnel." The motto for all participants should be the adage, "the only stupid question is one not asked."

Throughout the process of selection, you must remember you are making a major decision for the company. If you get it wrong, your company will not realize the benefits for which it is spending significant money and resources.

Supplier Ranking

The selection of the right software supplier is a combination of objective scoring (the hard facts) and subjective impressions (the soft issues). The objective scores focus on detailed requirements and how well each vendor’s software meets your needs. The subjective issues, on the other hand, focus on opinions and feelings: Which software feels more user-friendly? Which supplier would make the best business partner? Who has the best support? Should I take flexibility over functionality?

Decide what factors are most critical to the success of your business. This should be done early in the process, before you’ve sent out the RFP’s.

From the minute you make the first supplier contact, note the facts about each software package and the soft issues involving each supplier. Learn as much as you can about both culminating to a better decision.

Reference checking, once you are down to your final supplier it will help you to determine whether others users of the system agrees with your selection and gain how to succeed with implementation of the system.