Software selection and implementation services have become big business for consulting firms as well as the software vendors themselves.  Even with outside assistance, selecting the right software for your operation and having a successful implementation can be an extremely difficult undertaking. Horror stories of failed ERP system implementations are unfortunately very common.  Anyone that frequently reads business publications has likely read stories where large corporations, posting smaller than forecasted profits (or losses), cite problems associated with the implementation of a new software system as one of the causes.  Whether these claims are legitimate or not is up to debate. What is true, is businesses are highly dependent on information systems, and failures in the selection and implementations of systems can result in anything from a minor nuisance to a complete operational shutdown.

Software Selection

If you are unfamiliar with business software, be prepared to be bombarded with acronyms and buzz words.  MRP, MRPII, ERP, APS, MES, CRM, SCM, WMS, TMS, E-business, web-enabled, E-procurement, E-fulfillment, E-manufacturing, collaborative, modular, and scaleable are just a sampling of the terms used to describe (sell) software products.  My first tip is that if after listening to a software vendor representative describe the software for five minutes you still dont understand what the software does, walk away, you probably cant afford it anyway. Or you can to stop ask them "Okay, but what does it actually do?" Not that youll get a real answer, but its worth a shot.

Enterprise software ranges in price from a few thousand dollars to millions.  In fact, up until recently, if you were a business with annual revenues of less than 200 million, many of the top enterprise software vendors didnt even consider you a potential customer.  Fortunately, this arrogance has been tempered recently due to economic conditions (primarily the software vendors cash flow). So unlike five years ago when the software vendors felt like they held all the cards, today, it is truly a buyers market. No matter how big or small your company, there is a multitude of vendors vying for your software dollars. Thats the good news. The bad news is that you must now find a way to sift through all these products to find the one that best meets your business needs.

Unless you are shopping for a very simplistic low-end package it is highly advisable to seek the services of an independent software selection firm. Not only can they help to narrow down the list of potential vendors but can also help to prepare initial assessments of implementation costs (which can easily exceed the initial cost of the software), and educate you on software and the process in general.

The most important part of the software selection process is defining the processes within your organization and determining functionality that is critical to your operation.  Many times customers get lost in the bells and whistles and forget about their core business functions.  If you are a manufacturer, manufacturing is your core business function and you should be looking at packages that have been designed specifically for manufacturers.  Dont expect an accounting package with a little manufacturing module tacked on to be very functional.  In addition, you should be focusing on the specific type of manufacturing you are conducting.  Software designed for make-to-stock manufacturers may not work well for a make-to-order manufacturer.  Software designed for electronics manufacturing may not work well in a machine shop.  Software designed for discrete manufacturing may not work well for process manufacturing.  If you are in the distribution or fulfillment business, youll want to focus on functionality related to order processing, warehouse management, and transportation management. Be wary of the software vendor that claims their package works equally well in all of these environments.  Most software packages are initially designed with specific customers in mind; asking the vendor about their biggest customers will often give you an idea as to the type of operation the software was designed to work in.

When you look at the detailed functionality of a product it will be important to have listed detailed functionality requirements of your operation.  This is where companies often make mistakes by emphasizing functionality that they currently dont have and would like, and overlook core businesses processes that their current system handles well. For example, if you become awestruck with functionality that allows you to access your system remotely from a browser on your PDA, and as a result, overlook critical functionality related to demand planning, you may end up with a system that provides great visibility to the fact that your business is failing. Never assume a software package must be capable of handling something you consider a standard business function.  Some examples of detailed functional requirements are as follows:

E-commerce capabilities

Multi-plant demand planning

Postponement and configure-to-order functionality

Forecasting and demand planning

Back-order processing

Lot or serial number tracking

Forward pick location replenishment

Batch or wave order picking

Returns processing

Backflushing inventory

Coproduct processing

Outsourcing specific operations

Multiple stocking units of measure

Product substitutions

Blanket orders

Shipment consolidation

Multi-carrier rate shopping and manifesting

First-in first-out processing

Don't settle for "yes, we can do that" responses from the software vendor. It's your responsibility to verify that not only can they do it, but also that they can do it to the level you require. Ask detailed questions as to exactly how it works in their system. Look at the specific programs used to achieve the task and verify the data elements required to achieve the task are present. Don't allow the software vendor to not answer your question. They sometimes do this by answering your question with technical jargon they know (or hope) you won't understand. Don't be afraid to stop them and make them restate their answer in different ways until you understand it (I do this all the time). John Bielecki of CompassLead Consulting once told me he tells his clients to "Ask questions YOU understand the answers to."  Keep that quote in mind as you discuss functionality with software vendors.

Its unlikely that the software package will do everything you wanted it to do, so be prepared to compromise on some of the functionality.  Shortcomings in functionality will need to be addressed through process changes, software modification, or in some cases, off-line workarounds.

When addressing the issue of modifications, I have become convinced that the question to ask is not "will we modify?" but rather "how much will we modify?" Packaged software will not do everything you want it to do, the way you want it to do it. Sometimes these deficiencies result in minor annoyances and other times they result in costly business inefficiencies. It's important to treat software as you would any other process, system, or piece of equipment. Evaluate the costs and benefits of the modifications and make sound decisions that are in keeping with the business objectives of your organization.

In addition to functionality, you also need to consider usability. Functionality answers the question can it do something? while usability answers how does a user get it done? You especially want to look at any high volume tasks that occur in your organization. Look at the information provided in critical programs and count the number of mouse clicks and key strokes required to perform a task. Can you complete the task in one or two screens or do you have to cycle through four or five? Is all the information you need readily available and presented in a logical manner? Are mouse clicks required or are shortcut keys available? As much as we all love the mouse for surfing the Internet or working in graphics programs, it is not an efficient tool for high-volume transactions.

Are the bigger, more expensive packages better? That depends. There is no doubt that there is a relationship between functionality and cost. But with this greater functionality also comes greater complexity. Greater complexity gobbles up resources, extends implementation times, and drives up implementation costs. For large complex organizations, highly functional software is indispensable. However, for a small company, even if the supplier were to give you the software for free, you probably wont have the resources to implement and maintain it.

Implementation

As with the selection process, the implementation may also require outside assistance.  Whether you use consultants from the software vendor, a business partner, or an independent firm, the implementation plan will likely be the same.  Its very important to listen to your consultants and be prepared to dedicate the resources outlined in the implementation plan.  A common mistake made by companies going through their first major implementation is to underestimate the complexity of their operations, the extent of system setup and testing, and the impact the implementation will have on their operation.  Let me outline a common scenario in ERP implementations.

The consultants warn of the consequences of not dedicating adequate resources.

Management publicly agrees but privately thinks the consultants are crying wolf.

Implementation fails or goes poorly.

Management claims how could we have known?

Dont let this be you.  The only things you can assume about the implementation is that it that it will be much more difficult than you expected, it will take longer than you expected, and it will cost more than you expected.

Like most other projects, the success of a software implementation will be based upon the skill of the people involved, training, planning, and the effort put forth.  You should plan to have your most knowledgeable employees heavily involved in the system setup and testing.  Note that the most knowledgeable employees are not necessarily the department heads (trust me on this one). 

Adequate time should be dedicated to make sure every aspect of every process is thoroughly tested.  An example of detailed testing of a receiving program is listed below:

Does the PO receipt screen have all the information I need to perform the receipt such as vendor item number, item description, unit of measure?

What happens when I receive more than the PO quantity?

What happens when I receive less than the PO quantity?

What happens when I enter multiple receipts against the same line?

What happens if someone tries to change the PO quantity after I have entered a receipt?

What happens if someone tries to change the PO quantity at the same time I am entering a receipt?

What happens when I reverse a receipt?

What happens when I reverse a receipt after it has been paid?

What happens if the ordered unit of measure is different from the stocking unit of measure?

What happens when I receive an early shipment?

What happens when I try to receive against a cancelled PO?

What happens when I change the receipt location?

Now when I say what happens?  I mean; How were the PO quantities affected? How were the on-hand quantities affected? How were the inventory and payables accounts affected? How were allocations affected? How were inbound quantities affected?

You get the Idea. You need to essentially try every combination possible to see if you can make the system fail (not do what you wanted it to do), and it will fail.  The goal here is to make it fail prior to implementation rather than after. And you need to do this with every key process in every key program.

Even with extensive testing there will still be some issues that wont be identified until after the system is up and running.  While small issues and minor bugs are to be expected in any implementation there is no excuse for not identifying major issues prior to implementation.

After the system has been thoroughly tested you need to begin (if you have not already begun) the process of employee training.  I dont think Ive ever heard of a company over training employees prior to implementation. Remember, you are going to have to deal with the unexpected issues that pop up; you dont also need to be training employees after the system is turned on.

The training should consist of written procedures for the tasks they must perform and hands-on training.  For most positions you will want to make sure that each employee has entered the equivalent of at least a full-days transactions during the training.  Using an actual days transactions is a good way to make sure you have covered the variety of transactions the employee is likely to encounter. The most common mistake made in training end-users is a lack of adequate repetition. Just because someone was able to perform the task once during a training session on a Saturday three weeks prior to go-live does not mean they will be able to perform the task when you start up the system. If they have repeated the task many times over a series of training sessions, they are much more likely to remember how to do it. 

Watch the data. During and immediately after the implementation it is incredibly important to watch the data and make sure everything is working as planned. Monitor the statuses of sales orders, purchase orders, and manufacturing orders paying specific attention to "stuck orders" or other exceptions. Conduct some aggressive cycle counting of your fast moving items to make sure transactions are working correctly. Run financial reports daily to validate accounting processes.

Post-Implementation

Don't let it end with the initial implementation. Your new system likely has additional functionality that can improve your business processes. Once you become comfortable with your system, you should go back to the system documentation and start reviewing detailed functionality. You should also review all business processes to determine opportunities for improvement. This should be a continuous process. It is very unlikely that your initial implementation truly optimized the system for your business.

In the end, the success or failure of a software selection/implementation project is directly related to the efforts put into it. Information systems are critical part of managing operations, so don't shortchange the process.