.

IDII White Paper Section

"Research & Time Saving Content"
Free Newsletter -- Tell-A-Friend!

Enter name or keywords.

Software Selection
"Software Selection and Implementation Tips."


IDII Note: A valuable article on selecting the RIGHT software!! Realize that any WMS, SCE, or ERP project is a "large software implementation". Due diligence on selection and implementation issues are critical.


Here are some valuable tips from InventoryOps.com on software selection and implementation tips.

Software Selection and Implementation Tips.

By Dave Piasecki

Software selection and implementation services have become big business for consulting firms as well as the software vendors themselves.  Selecting the right software for your operation and having a successful implementation can be an extremely difficult undertaking, even with outside assistance.  Horror stories about failed ERP system implementations are unfortunately very common.  Anyone that reads the business and financial sections of the newspaper will regularly see stories where large corporations posting smaller than forecasted profits (or losses) site problems associated with the implementation of a new software system as one of the primary causes. 

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, scaleable are just a sampling of the language used to describe software products.  My first tip is that if after listening to a software vendor representative describe the software for 5 minutes you still don’t understand what the software does you probably can’t afford it anyway.  Enterprise software ranges in price from a few thousand dollars to millions.  In fact if you’re a manufacturer with annual revenues of less than 200 million, most of the top enterprise software vendors don’t even consider you a potential customer.  You can also expect implementation costs to match or exceed the cost of the software.

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 (of which I am not).  They can not only help to narrow down the list of potential vendors but can also help to prepare you in initial assessments of implementation costs and time frames.

The most important part of the software selection process is to define the processes within your organization and to determine functionality that is key 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.  Don’t buy an accounting package with a manufacturing module tacked on.  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.  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 for.

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 don’t have and would like and neglecting core businesses processes that their current system handles well.  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:

Multi-plant demand planning

Outsourcing specific operations

Configure-to-order functionality

Back-order processing

Lot tracking

Forward pick location replenishment

Backflushing inventory

Coproduct processing

Multiple stocking units of measure

Product substitutions

Blanket orders

Shipment consolidation

First-in first-out processing

It’s 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.

Implementation

As with the software selection, the implementation will likely also need 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.  It’s very important to listen to the 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.

  1. The consultants warn of the consequences of not dedicating adequate resources.
  2. Management publicly agrees but privately thinks the consultant is crying wolf.
  3. Implementation fails or goes poorly.
  4. Management claims “how could we have known?”

Don’t 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 things the success of a software implementation will be based upon the skill of the people involved, training, 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.  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, and it will fail.  The goal here is to make it fail prior to implementation as apposed to after.

Even with extensive testing there will still be some issues that won’t 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 the process of employee training.  I don’t think I’ve ever heard of a company over training employees prior to implementation.  In fact the opposite is usually true.  Remember you are going to have to deal with the unexpected issues that pop up, you don’t 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 the best way to make sure you have covered the variety of transactions the employee is likely to encounter.

 

 

 

Dave Piasecki is owner/operator of Inventory Operations Consulting LLC, a consulting firm providing services related to inventory management, material handling, and warehouse operations to manufacturers and distributors in Southeast Wisconsin. He has over 15 years experience in warehousing and inventory management and can be reached through his website (http://www.inventoryops.com), where he maintains additional relevant information and links

 

Copyright © 2001   Inventory Operations Consulting L.L.C.


IDII thanks Inventory Operations Consulting L.L.C. for permission to use their white paper. To contact them:



Inventory Operations Consulting L.L.C.

7505 Sheridan Rd. Suite A
Kenosha, WI 53143

Ph: (262) 564-0491
Email: email@inventoryops.com

www.inventoryops.com


 

Recommend a New White Paper - Frequently Asked Questions

Tell A Friend Now!  Tell them about this webpaage and IDII's educational resources.
Free Newsletter on Software

Resources white papers, book catalog, resources, reports, RFP's, & more!

If you have comments, questions, or suggestions - E-mail us at info@idii.com

Industrial Data & Information, Inc.
Route 1, Box 580
Webbers Falls, OK 74470
(918) 464-2222 - Fax (918) 464-2221

© 2001, 2002, 2003 Industrial Data & Information, Inc.
www.idii.com