Is Vendor Selection Really The First Step in ERP Implementation?

A free guide that you can download from ERP Focus makes vendor selection the first of an 11-step implementation process, while defining success is the last.  In other words, they have you choose who you buy from before having a clear idea of what you are trying to accomplish.

It reminds me of a meeting at a client site where ERP implementation was about to begin. “This train has left the station,” I was told. The purpose of the meeting was to draw a “Value Stream Map” for the whole plant, in preparation for ERP, and the participants included managers from Manufacturing, Quality, Production Control, Maintenance, Purchasing, Sales, and Engineering.

Even though this was a facility with a few hundred people, the process of asking who needs what information from whom quickly made it obvious that none of the managers knew what their peers were doing. They also realized that they could make the whole organization work more smoothly by sharing what they needed from each other, and that it was a prerequisite for a new ERP system. A few weeks later, I received a call from the company telling me that they had cancelled the ERP implementation and would revisit the issue when ready.

More generally, before considering vendors, you might want answer the questions discussed in this post:

Questions 1 and 2 are not addressed in the ERP Focus process, and Question 3 is about defining success. If you wait until you are done implementing to define success, you will do it in terms of what you have done. You should instead do it at the start, in terms of what you intend to do, so that, at the end, you can notice any gap.

What Do We Expect From ERP?

According to Tom Wallace ERP is the business process of Enterprise Resource Planning; according to just about everybody else, it is a category of software products with total sales of $25.48B in 2013, for which the following benefits are touted:

1. Efficient data collection.
2. An integrated database.
3. A report generator.
4. Online customer service.
5. Data security.

It should be noted that “improved planning” is not on the list, even though the “P” in ERP definitely stands for “Planning.” In fact this set of benefits could be claimed for any generic business database management system, as used in banking, insurance, aviation or car rental as well as in manufacturing.

ERP is the fourth generation of systems that were originally intended for manufacturing and have been marketed to successive generations of managers, from Orlicky’s  Materials Requirements Planning (MRP) in 1964, to Closed-Loop MRP in 1969, Wight’s Manufacturing Resource Planning (MRP-II) in 1983, and ERP in the 1990s. Each successive generation involved an expansion in function, and a dilution of the focus on planning.

Planning is strictly about the future, and does not include activities like order entry or the issuance of shipping notices, which software products called “ERP” routinely do, but you need data to plan, and the task of acquiring and maintaining this data is so great that it becomes the focus of the system, which then becomes an information infrastructure rather than a planning solution. ERP systems, of course, still have modules for Capacity Planning, Sales & Operations Planning, Master Scheduling, etc., but they are buried in feature lists below the ability to use the software as a service (SaaS), “24/7 customer support,” multi-currency accounting, or CAD automation.

If an organization exists in manufacturing today, it already has some sort of information system, typically combining one or more computer systems of various vintages, electronic spreadsheets on various members’ personal equipment, printouts of work instructions, travelers, or schedules, handwriting on shop signs, communications boards, and post-its, and voice — collectively known as “legacy systems.”

The promise of a centralized system integrating all this information has been attractive enough for ERP to command the lion’s share of the manufacturing industry’s IT budget.  In companies that have implemented ERP, however, enthusiastic users are hard to find. Most often, you hear about the time, effort and money needed to set up, operate and support integrated systems that don’t do as good a job in every specific function as the previous, dedicated systems did. Warehouse Management Systems (WMS), for example, often get rave reviews from warehouse managers; ERP systems don’t, but then, infrastructure rarely does.

What’s Wrong With The Current Systems?

The problems with legacy systems are different in each company. Common issues include the following:

• Space Cowboys. The systems are so old that no support is available, and are chugging along on mainframe computers with less processing power and memory than your iPhone, based on structures and logic set up decades ago by systems engineers who are long gone.
• Isolated island. The systems used inside the company don’t play well with suppliers’ and customers’. For example, they may not support Electronic Data Interchange (EDI) with customers, which some customers demand.
• Inconsistencies. As the result of multiple mergers and acquisitions, divisions and subsidiaries run different systems, with different nomenclatures and different functions. Even without mergers and acquisitions, you may still have inconsistencies between the systems used by Engineering, Manufacturing, Accounting, Maintenance, etc.
• Transaction processing only. The systems don’t support analytics. All analytical work is done on extracts to Excel, which is initially easy but deteriorates as the number of people involved and the complexity of the analyses increase, errors creep in, data quality and security are lost. Sometimes this leads to disastrous consequences.
• Obsolete business focus. The company used to live primarily from full-custom jobs, and the system focus was on planning and costing such jobs, but the business has migrated towards repetitive manufacturing of standard products, with an aggregate volume 10 times higher. But it is still using the same ERP system that was developed to support custom jobs.
• …

Whatever the motivation is, management should be able to articulate it in a concise statement.

What Are The Requirements For A New System?

Requirements Analysis

Defining the functional requirements for a new system requires skills that are often not available in house. Software suppliers will be happy to provide analysts to do this for you, and may even do it free of charge, but all they will tell you is how their software can be used to solve your problems. You may achieve some measure of objectivity  by asking multiple vendors, but you will always be getting input from people whose primary motivation is selling.

The requirements analysis should be technology-neutral and focused on business processes. It should describe what you need done, regardless of whether you do it with clay tablets or the latest IT. If you use consultants, they should be working for you, not a software supplier.

More that a laundry list of features, the requirements analysis should produce a model of how information should be managed to support the company’s business, including the following:

• Metadata — timeless. This includes product and process definitions, bills or materials, routings, equipment, facilities, job descriptions, etc. It is definition data that is timeless in the sense that it remains valid and effective until management decides to change it.
• Planning data — about the future. This is data about the future, including yearly capacity plans, monthly sales and operations plans, daily production plans, down to the schedule of what each resource on the shop floor should do next. It changes with the passage of time.
• Status — the present. This is data about the current state of production and resources. Which machines are processing what, and are they on schedule, ahead or behind? Which ones have alarms or are down? Who is at work and where? This is real time data.
• History — the past. As events occur, like shipments to customers, receipts from suppliers, operation completions, quality problem reports, machine failures, etc. the data about these events is kept in history for traceability and analysis.

Requirements Validation

From direct observation of users at work with the legacy systems, review of the outputs they produce, and stakeholder interviews, a well-trained software engineer can produce a model of what a new system should do that is logically consistent, but it is still, at best, a picture of what management thinks it needs today, and may contain misconceptions of how the use of such a system would actually play out.

In his January 2016 newsletter, Bodo Wiegand gives the following example:

“Let’s remember that the company is fully networked. The boss can monitor all machines on screen, and yet performance does not improve. Productivity does not increase, the output remains the same.

[…] What do we do with the employees who now know that their performance is visible to everyone and immediately testable?

Greetings from George Orwell!

During my conversation with the manager,  he was at first unfocused. He kept looking at the screen and wanting to pick up the phone. Equipment that was apparently important for him plant had been stopped for 4 hours. Luckily, I was able to talk him out of calling right away.

Had he called, the employee at the other end would have rightly felt completely totally controlled, thinking “The boss just wants me to fulfill my quota. If that is in question, I am to blame. And I can’t help it that this machine breaks down so often.” The employee feels controlled and made personally responsible for the failures. Motivation sinks to the bottom.

This employee will do the job and keep as much as possible in reserve so that the line still meets monthly targets and the bonus keeps coming.”

In principle, every manager, from the CEO to the line supervisor, has the right to know the state of every resource he or she is responsible for. In a top-down approach the analyst responds to the explicit desires of top management, and this kind of total information access may find its way into the requirements. In actual use, however, the social dynamics of the plant organization may make it counterproductive.

In a bottom-up approach to information about a machine, the analyst would instead focus on the needs of the people who work directly with it, as operators, maintenance technicians, or manufacturing engineers. The challenge here is to extract generic requirements from the profusion of specific situations. This is where continuous improvement on the legacy systems has a critical role to play.

Continuous Improvement On Legacy Systems

Once you have an information model, the next step may still not be turning it into a laundry list of feature to send suppliers in a Request For Proposal (RFP). For all their flaws, the legacy systems are in daily use with trained users, and completely replacing them is as easy as a nervous system transplant.

When you bring up the shortcomings with the IT staff, the most common response is to refuse to work on immediate solutions, because a whole new system is scheduled for implementation two years from now, and it will solve all the problems. And the ERP vendors will tell you that trying to improve the legacy systems is a waste of time and money, and that you will be better off implementing their clean solutions right away. What could possibly go wrong?

Instead of waiting for a technology silver bullet, a continuous improvement approach has the following advantages:

1. It provides solutions now rather than two years from now, with immediate benefits at a low cost.
2. It is a learning experience. It validates your requirements and makes you a better buyer when you actually replace the systems.

Continuous improvement is also not readily embraced by the IT departments of manufacturing companies, because it entails a loss of control. They are keen to restrict the use of IT within the company to a set of standard tools that they vet, implement, control, and support, often with the result that users have more advanced technology at home than at work.

Short of replacing all the legacy systems, the following can make them more useful:

1. Upgrade the processing hardware. One thing the IT department can do is replace the 30-year-old  mainframe with a 5- or 10-year-old machine that can run the same software. You don’t want to run your old systems on the latest hardware, which is expensive and may not be technically feasible, but on the latest compatible hardware, that you buy used, for an order of magnitude less money.
2. Upgrade output usability. The antique dot-matrix printers on the shop floor crank out barely readable pick lists with fading ribbons on colored paper. Replace them with color inkjet or laser printers that can put out barcodes and QR-codes as well as high-contrast text.
3. Improve data entry. Even if entered manually, commercial transaction data is usually accurate. This data is the work product of Purchasing, Sales, or Receiving, and affects multiple parties, with the consequence that errors are promptly corrected. The completion time of one operation in  a machine, on the other hand, is not the work product itself but data about the work. The work product is the workpiece itself, and it can proceed to the next operation with a wrong timestamp. Because manual data collection in production adds work for the operators, it is usually deferred to the end of the shift and delegated to a clerk. This is a source of errors that are often not detected and would be impossible to correct if they later were. Improvement in this area lends itself to a two-pronged approach:
   • Eliminating unnecessary data collection. There is, for example, no need to collect production control data at each operation within an assembly line. From this perspective, the entire assembly line can be treated as a single operation.
   • Automate data acquisition, by collecting both timestamps and measurements directly from equipment controllers, and using auto-ID/Internet-of-Things technology on workpieces or fixtures.
4. Retrofit integration technology. Some inconsistencies in the metadata can be resolved without replacing the legacy systems, by an additional layer of software. Historical data from multiple systems can be periodically extracted, transferred and loaded (ETL) into a data warehouse, structured according to the desired overall data model, with cross-reference tables to recognize the same items under different names. A real-time, in-memory database can serve the same purpose for status data.
5. Enhance analytics. Most managers’ idea of analytics is limited to pie charts and stacked bar charts. Once you have a data warehouse or an in-memory database, you can do more based on queries against these databases, using a variety of analytical tools. In most organizations, it means using Excel, with its pivot tables, charts, and data analysis add-on. It is a good tool, but, as indicated above, often misused. Learning to use it better to find data-based answers to questions about the business is an appropriate topic for improvement activities. So is learning what other, more powerful tools can do. After Excel, due to the influence of Six Sigma, Minitab is probably the most commonly found in manufacturing organizations. There are many others, like SAS or Statistica, and even languages for analytics, like MATLAB or R.
6. Experiment with new technology. Small-scale experiments in innovative uses of IT are necessary to validate and enrich requirements specs. They may reveal that certain functions are not as useful as was anticipated, and identify new ones that had not been considered. Using iPads, QR scans, Sharepoint and Infopath to implement TWI  was an example of such an experiment, conducted not by the IT department but by the management and technical staff of a production unit. Many IT departments frown on IT users thus straying off the reservation and using tools that are not part of the standard kit they provide and support. But these experiments are no different than the ones conducted on hardware in the production engineering sandbox, where teams prototype work stations or jury-rig their own pick-to-light systems. They are about learning. The knowledge gained may be used to build systems for actual use in-house, or to be informed, savvy buyers when working with suppliers.

Just as continuous improvement in the use of milling machines or grinders prepares the organization to make better investments in new machines, so does continuous improvement in the use of legacy systems prepare it to choose new systems wisely and implement them effectively. Another perspective is that continuous improvement on legacy systems is the way you earn the right to choose, acquire, and implement their replacement.

A continuous improvement culture is rarely found in the IT departments of manufacturing companies. Firefighting is more common, but the emphasis on ERP is a contributing factor. There is more to IT in manufacturing than ERP. From embedded equipment controllers to supervisory control systems, local schedulers, warehouse management systems, technical data analysis systems, training systems,… IT is pervasive and much of its use is driven from the bottom up.