Hello randyluddy-ga,
I have compiled information on the considerations that need to be made
from an organizational perspective when implementing enterprise
software. This answer will be structured more as a set of
recommendations that are meant to mitigate the occurance of
foreseeable issues.
When readying for a new enterprise solution, it is very important to
keep in mind that the smallest decision (or non-decision) could
possibly result in unexpected consequences. Unfortunately, replacing
an old system with a new one is nothing like Lego, where individual
pieces are easy interchangeable. It's more like a muscle transplant,
where successful replacement would require properly applied anesthetic
and correct treatment of blood vessels and nerves. Consider yourself
the surgeon - you are required to ensure the correct tools are in
place and you have the right people supporting the decisions that are
made.
Based on the information you have provided, I have highlighted several
issues that may arise, and suggestions for the best ways to mitigate
the risk of each issue. These particular issues have been chosen
specifically for your scenario.
OBTAINING ENTERPRISE-WIDE STAKEHOLDER ACCEPTANCE
Your organization is a classic medium-size operation, however it is
spread considerably thin geographically. Although your number of
employees per location averages out to 10-15, I suspect there are a
few locations with considerably more. In this type of structure, it is
important to ensure that decisions don't become a power struggle
between locations/regions. Instead, decisions should ideally be made
by concensus and through an objective process.
This type of "fair decision making" is typically done through the
establishment of two committees:
1. Project Steering Committee
This group has the mandate of jointly making decisions that impact the
start, continuation, and completion of the project. Some of the major
decisions this group would make are:
a) Budgetary
b) Vendor Selections
c) Organizational Restructuring
The group should be composed of upper management (typcically VP level)
that represent the various functional areas of the company that would
be impacted by the decisions that are made here. For this type of
system, I would not exclude any groups. The size of this group
shouldn't exceed 8-10 people for a company your size.
2. Change Control Committee
When a project starts, many assumptions are typically put in place
that will inevitably need to be adjusted as the project runs it's
course. The way this happens is usually along the lines of a sequence
of events like this one:
a) Steering Committee gives project go-ahead
b) Key personnel identified (including a project manager to oversee entire project)
c) Initial project plan is established
d) Project starts
e) Project not going according to plan
f) Project manager submits item for change control
g) Committee approves/denies request
h) Plan adjusted accordingly and project proceeds
What usually happens here is that there are numerous requests being
generated; if the PM sees them as valid they will create a formal
change control item for review by this committee. Outstanding items
(unless they are urgent) will be review in bulk periodically - once a
week for example.
Overall, stakeholder acceptance is obrtained by keeping them involved
throughout the process. A functional area is much less likely to
contest decisions if they've had the chance to participate all along.
JUSTIFYING PROJECT COSTS
So how do you determine what is a good value for your company's money?
Well there are a few approaches, and each should be investigated
during the due dilligence stage of product selection (once the vendors
have been narrowed down to the finalists).
a) Relative cost/benefit analysis between vendors: By looking closely
at a product's cost relative to what it provides YOUR company with,
you can weed out products with costly features that your company may
not fully leverage. Vendors who are not aware of exactly what you need
may just give you a laundry list of features, hoping to have most or
all of the things you are looking for. Needless to say, if 50% of the
product functionality will never be used, your project dollar is not
being very efficiently utilized.
b) Return on Investment calculation: The most pragmatic way of
justifying costs - determining the ongoing dollar value of cost
reduction and revenue generating opportunities that would arise by
making the investment. This has nothing to do with a specific product,
but with what the initial vision is for a new system (what you think
it should do). Such an analysis is most valuable when proposing the
project in the first place (perhaps as part of a business case).
c) Calculate Estimated Break-even date: At what point in time will the
increased efficiencies promised by the system pay for itself? This
often puts decisions in perspective; perhaps something that sounds
like a good idea and would make life easier is simply not worth it.
This type of analysis is also helpful at a more granular level, and
can be used when deciding which modules to implement (and in what
order).
At the very least, these measures will help you explain how you came
to the decision to proceed, and even how you determined which vendor
came out on top of the selection.
SUPPLIER COOPERATION
One thing you mentioned in the clarification is that you would like to
integrate communication with suppliers so that PO's can be
autogenerated based on inventory. When the supplier/customer dynamic
is good, this can work out very well. However, there are a few things
worth considering before telling your supplier about this.
1. Who is the "big fish" in this relationship?
If you are Wal-Mart, for example, you can pretty much dictate what
adjustments you want you suppliers to make to their systems and
processes to accomodate your supply chain. However, some suppliers do
business with a large number of customers, of which your company make
only make up a small portion. If this is the case, you may want to
think twice before imposing this type of arrangement on them. If the
impact to their business is too great, they may just decide to forego
the revenue opportunities you offer.
2. What does your supplier network look like?
Are you working with just one or two suppliers, or do you have
hundreds? Do you have redundencies in place if you your primary
supplier runs out of stock or something enexpected happens? These
questions bring up interesting problems with integrated supply chains
because, of course, there is a cost to rolling out integration with
each supplier. What many companies with a large number of suppliers
end up doing is just intergrating ordering with the few suppliers they
buy the bulk of their raw materials from. Although not an elegant
solution it is often far more cost effective.
3. How stable is the current group of suppliers?
If you have high turnover in your suppliers, investing to get them
integrated may not be such a great idea. I would recommend doing this
only for suppliers who have been reliable and long-standing sourcers
for your company.
RESTRUCTURING IT ORGANIZATION
The area that will ultimately feel the heaviest impact from
implementing a new enterprise solution is the group keeping the
current system running and developing new functionality. While this
group of people may know little about the system you are bringing in,
they are still very valuable. They hold the key to one of your
company's most important assets - it's data. For this reason alone it
is important that they play a central role and not be pushed aside.
Here are some thing you can do to ensure smoother relations with your
IT staff:
1. Give them more than proportional representation in the committees
(this is the only exception to the rule of proportionate
representation).
2. Make clear the organizational objectives of this intiative, and how
this will impact them. Often IT workers are left in the dark when
decisions like this are made - this would be a big mistake. Provide
members of this group with the opportunity to grow their skillsets in
an adjacent manner so that they can leverage the skills they have to
the greatest degree. It is not a good idea to completely remove
someone from the type of work they are doing and transplant them into
something different.
3. Create enthusiasm in the group by selling the ultimate benefits of
this change. This may prove most difficult with the developers, as
this type of work is actually minimized with an off-the-shelf
solution. Explore alternative interests of these resources, and
attempt to move them to roles on this basis.
4. Provide ample training specific to the new roles and technologies
that the IT staff will be transitioned to. Do this in a manner that is
well-paced and progressive. If appropriate training on implementing
package XYZ is successfully delivered performance of these employees
could be surprisingly good.
5. Bring on external technical consultants who can keep the project
moving at the beginning of implementation while assisting your staff
with their duties on the job. Some companies even go as far as using a
mentorship scheme, pairing up a staff member with a consultant.
MINIMIZING OPERATIONAL DOWNTIME
When you are replacing your entire enterprise software package, it is
critical to ensure that the progress of that replacement doesn't come
at the expense of remaining operational. While there will need to be
scheduled periods of time where certain operations may be hindered,
minimizing impact is a balancing act. Here are some techniques you can
employ:
1. Use maintenance windows whenever you can - these are times when the
enterprise has very little load and systems can be upgraded or taken
down with minimal impact. While this is typically nights or weekends,
I don't know whether off-hours work is done at your company. There
could be scenarios when performing changes during business hours makes
sense (ie. accounting systems after monthend processing is complete).
2. Utilize shifts of workers to pick up slack when their counterparts
are offline. If you have sales operations in different regions, you
can minimize impact by redirecting calls emails to regions that are
running, rather than exposing downtime to customers.
3. Time zones should be taken advantage of - having multiple locations
is a good thing here. If you have to take down a production system,
consider how functional areas are concentrated in a given time zone.
Look for opportunities such as lunch hours or end of day to do
maintenance, rather than ad-hoc outages.
4. Overlap service - if you are working on swapping out a certain
module (such as inventory management), consider running both systems
at the same time if it makes sense. For mission critical operations,
end users would rather have some combination of the old and new system
than now system at all.
DEPLOYMENT STRATEGY
This concern relates to scheduling of the project. Most enterprise
software is set up as modules, allowing customers to pick and choose
which functionality they want, and when they want it. It is definitely
worth taking advantage of by following a process that includes:
1. Identifying the modules within your selected product you want to implement
2. Prioritizing those modules based upon a relevant factor. This could
be any combination of cost, impact on operations, time to implement,
or risk. You should typically start projects with modules that have
the smallest impact/cost/risk/duration in order to mitigate the cost
of potential failure.
3. Start small and build on those small successes - this will inspire
the project team and build a positive aura around the project in the
company. Putting completion of major milestones in the company
newsletter doesn't hurt either!
END USER SKILLSETS
It is well known that people will be happy working with tools they
know how to use. One of the worst fates of a project like this is when
users reject the system (this can happen for a multitude of reasons).
It is certainly in the best interests of the company to make sure that
users are appropriately trained and happy about the system. After all,
it is being implemented for their benefit.
The extent to which you want to get into this area is a function of
the level of sophistication of your staff and the complexities (read
differences from old system) introduced by the new system. You will
know you have done this right if you don't constantly hear "but our
old system let us do XYZ task this way".
Since all users are not going to be using all parts of the system,
they cannot be given the same course. An effective way of measuring
just what type of training should be delivered to people who fulfill
various roles can be achieved by:
1. Selecting a moderate cross-section of end users (maybe 10% of all
users) across various functional groups - these people will be members
of your focus group.
2. Classify each member as having a certain role or job function.
3. Identify which modules are needed for each job role or function.
Make sure you haven't left out any major roles!
4. Provide training to each member on this basis (the vendor will be
able to suggest the ways this can be done).
5. Put the member in a 'dry run' situation in a test lab. Have an
observer look at how they interact with the system. Did they learn
what they were supposed to? Are there any patterns of confusion or
frustration that are common to many users?
6. Collect observations, refine training appropriately.
7. Roll out training to the full user group - ensure this is done a
short amount of time before that given module is to be deployed to
production. This will minimize the chance they will forget what has
been learned.
I hope the content above has given you an appreciate for the number of
"moving parts" that are likely to be present in a package
implementation of this scale. If you have any comments or are unsure
of the above, please post a clarification and I will attempt to
respond promptly.
Thank you for using Google Answers :)
Cheers,
answerguru-ga |
