You Need More Than Functions and Features to Implement an ERP Package Part Two: More Tools and Summary

  • Written By:
  • Published:


It stands to reason that, when selecting an enterprise resource planning (ERP) package, you must be sure that the software has the functions and features to support your organization. Unless you turn those functions and features into reality with a successful implementation, the benefits and savings that you think are there for the taking, won't materialize. Sure, if you don't select the most appropriate software in the first place, a truly successful implementation may never be an option. The majority of the hard work, however, still remains ahead of you and the project team. Icebergs are not the only objects whose danger is 75 percent below the surface.

This article looks at four classes of implementation tools that can make the ERP implementation process go smoother, put the "friendly" back in user-friendly, and put a smile on faces in the IT department. For sake of simplicity we will refer to these tools as

  • Administrator (see Part One)
  • "Customizer" (see Part One)
  • Configurator
  • Integrator

In the following sections we will discuss the key attributes of each tool so that you will understand their benefits and potential usage.

This is Part Two of a two-part note.

Part One discussed the administrator and customizer Tools.


Most ERP solutions come with best practices, which users are encouraged to follow to achieve efficient use of the software and an optimal level of control and management of the processes. However, for a variety of reasons, a prescribed best practice may not be applicable to your organization. In fact, some of your existing practices may be what gives your company an advantage over the competition or makes it easier for your customers to do business with your company. The configurator tool allows you to modify vendor-supplied workflows or create new ones to ensure that an organization maintains its competitiveness in the marketplace.

Essentially, with configurator you are presented with a palette of transactions or existing workflows from which to choose. By dragging and dropping transactions from the palette onto the drawing board, you start designing new transaction flows. The flow of information is visually depicted through connecting lines and directional arrows. Hence, you are able to create workflows that better satisfy your company's objectives.

This is the easy part. Behind the scenes, transactions are defined with expected inputs and outputs. This prevents you from designing illogical or impractical workflows. As a result, you would be prevented from mapping the order taking transaction directly into a shipment transaction. Where is the picklist generation? Where is the pick confirmation? Likewise you would be prevented from mapping a purchase order workflow into a billing process. Configurator must have the built in intelligence to ensure that basic transactional relationships are upheld and enforced.

Again, a simple example will illustrate how configurator could be used. Let's say the vendor-supplied workflow for purchasing is shown in figure 1:

Figure 1

This is clearly a suggested flow to ensure that purchases are authorized, approved, and received before payment is made. However, this may not be the flow when dealing with purchases under a certain dollar amount or purchases that are governed by a contract or blanket purchase order. For these types of purchases a more simplistic flow may be appropriate as illustrated in figure 2.

Figure 2

Both workflows would be available. Configurator should enable you to copy an existing flow (figure 1), modify it, and create a new flow (figure 2). However, the tool should prevent you from creating the flow depicted in figure 3 since it is contrary to good controls and practices. Moreover, a purchase order is not an expected input for the vendor payment transaction.

Figure 3

While an organization does not typically purchase and implement software to mimic what they already have, unique requirements may demand it. Configurator provides the flexibility to realistically and intelligently evaluate this alternative. The tool also permits an organization to make process changes on a gradual basis. When starting to use the ERP software, an organization may not be able to absorb controls like approval and credit verification. As the software and users settle in, configurator enables you to gradually insert these controls and other changes. As such, change management is now squarely in the hands of the users and not the software vendor.


Unless you are migrating from an abacus and manual ledger sheets, all implementations must come to grips with a common dilemma: How do you get the data from your current systems into the ERP software and all of the related problems? Users don't want to go through the drudgery of manually entering the data. And, if by some miracle you can convince them of the merits of this exercise, there will be a period of time—two, three months or more, when both the legacy and ERP data will have to be maintained. You can hear the cries of excitement about doing double maintenance from the other side of the production floor.

Then, there is some data that, because of its need to be absolutely current, must be converted electronically. Inventory on-hand balance is a good example. It is not a case of your programming department not wanting to spare users of this manual drudgery but a conversion program is essentially throw away code. Once the data is converted for the implementation, the program is no longer needed. So, if the choice is a program to increase sales versus a conversion program, which would you rather have the programming group work on?

The programming effort may not be trivial. Typically, you will be migrating data from a flat structure to a relational database hierarchy. This would be like assuming that, if you did the electrical wiring for a one-room apartment, you are ready to tackle a twenty-story, high-rise office building. Again, remember that the program may not be needed at the implementation project.

This is where an integrator tool can save the day for an implementation project. Integrator is a mapping tool that can transform your legacy data into a format and structure require by the ERP software. Simply, the theory is that, if you can export your existing data to an external file, this tool can pull it into the ERP software.

The integrator should come with out-of-the-box templates such as Excel spreadsheets, which define the sequence and format for the legacy data elements. Extraction of data from an existing system is a fairly common and routine function. Moreover, it probably is already being done. Typically, this data can exported to a delimited or text file that can then be imported or opened within Excel. The spreadsheet is then processed by integrator to upload the exported fields into a relational database.

If you cannot change the sequence or format of the extract data, not to worry. A decent integrator tool will allow you to develop a custom map to designate how exported data elements from your legacy system is related to and formatted for your ERP software. While a little bit more time consuming, it certainly beats coding and debugging a program. Just ask your IT manager.

There are additional features that you should look for in integrator. You should be able to designate a begin procedure (delete table first, housekeeping, etc.) before the data is processed as well as an end procedure (clean-up activities) after processing is completed. Within the tool, it would be helpful to filter the extracted data (dates within a certain range, sales greater than a specified amount, etc.). When performing incremental uploads, a filter could prevent doubling up data without changing the extraction logic. Data sources should not be restricted to a local server but be accessible via the Internet or FTP. Either when using the vendor-supplied templates or developing a custom map, designating default values should be available. Typically, when migrating to ERP software, new fields will be offered that were not used in your legacy systems and, hence, do not have a mapped value. The assignment of a default can permit the use of these fields from day one and then modify as you grow into the software. Likewise, the tool should allow you to perform simple reformatting of your legacy data without additional code. For example, if your dates are in a European day/month/year format, change them to a month/day/year American format.

It also would be nice to schedule the running of integrator on a daily, weekly, monthly, day of the month basis to run at specific time of the day or every five, ten, or fifteen minutes. You are probably saying to yourself, "Now you're getting greedy." Integrator need not be viewed only as an implementation tool. Let's say you have a custom production subsystem that just cannot be replaced and affects or adjusts your on-hand finished goods inventory. With an integrator scheduling option, you can routinely, seamlessly, and automatically pull this data into your ERP database.

While not a function of scheduling but more a function of its routine operability, refreshing pilot databases and uploading current production data just before "go live" is now a simple procedure and not a orchestrated affair tantamount to planning a mission to the moon. Okay, this may be a slight exaggeration but those of us that have lived in the trenches understand the point.

Finally, integrator should not be viewed only as an importing tool. As we have described, as long as you can describe the data, any database can be input for integrator, even the ERP database. This means that you can use the tool to format ERP-based data for third party software such as EDI or bank reconciliations, which typically require custom coding. Not anymore!


As has already been said, there may no shortcuts to selecting the right ERP software, but, if you do your homework ahead of time and do some due diligence, there are definitely tools that can make the implementation, while not a pleasure, at least an easier adventure. And this due diligence is not just a technical exercise. Menu organization and screen customization should be considered by the day-to-day users. Workflow modifications should be evaluated by operations, shop floor personnel. Data migration activities should attract the interest of the IT staff.

Implementation tools of this caliber can help companies to be more adaptive and proactive in growing their competitive position in ever changing markets without having to replace existing solutions or pay for expensive customizations. Finally, without being redundant, you make users, who possess the business knowledge, more productive in facilitating a workable and successful solution.

While this article is not suggesting that implementation tools carry the same weight as how orders are processed, production is scheduled, and other bottom line activities are managed, they clearly should be considered essential tie-breaking criteria. If these tools are provided free with the software then that's great! If not, perhaps you should sharpen your pencil before signing the contract.

About the Author

Joseph J. Strub has extensive experience as a senior project manager for the planning and executing ERP projects for manufacturing and distribution systems for large to medium-size companies in the retail, food and beverage, chemical, and CPG process industries. Additionally, Strub was a consultant and information systems auditor with PricewaterhouseCoopers and an applications development and support manager for Fortune 100 companies. Currently, Strub is a senior consultant for 3i Infotech.

He can be reached at

comments powered by Disqus