Software Selection and Implementation Tips.
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, walk away,
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.
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 in your organization. Evaluate the
costs and benefits of the modifications and make sound decisions
that are in keeping with the business objectives of your organization.
Link to relevant site
|
 |
|
Emerging Technologies
Articles on ERP
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.
The consultants warn of the consequences of not dedicating
adequate resources.
Management publicly agrees but privately thinks the consultant
is crying wolf.
Implementation fails or goes poorly.
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.
|
|