Hello randyluddy-ga,
I have compiled information on the considerations that need to be made
from a technical perspective when implementing enterprise software.
This answer will be structured as a set of technical considerations
that are intended to provide a checklist of areas to consider or
address. The end goal is a document describing the transition between
the current environment (?AS-IS?) and the completed implementation
(?TO-BE?).
Implementing a new enterprise solution is, by its very nature, a
technical exercise. Once the business-related decisions and issues
have been addressed, time will come to get down into the details solve
the technical challenges that will arise.
Based on the information you have provided, I have highlighted several
areas that will require significant attention. I have also attempted
to address many of these by providing generic best practice
approaches. These particular issues have been chosen specifically for
your scenario.
TECHNICAL ROLES
It is a good rule of thumb that for every 20-25 employees in a medium
to large size company, there be one employee whose main role is to
provide or support IT in some aspect. The following conditions apply
to this rule of thumb:
a) This ratio is relevant to organizations that have a stable and
slowly improving set of systems and demands on their staff. Varying
situations require varying resources.
b) This ratio also considers only employees who will be using the
technology during their daily tasks. In your case this is roughly 300
(as previously stated).
c) It is assumed that all IT is provided in house ? if certain
services are outsourced, then the demand on the internal IT group is
accordingly lowered.
d) This ratio can become inaccurate depending on the intensity of use
of IT across the user group.
While I don?t know how your IT services are broken down in terms of
outsourced vs. internally provided, your IT organization seems to be
stretched thin already, with one IT resource per 50 IT users.
While I?m not questioning the capability of that IT group, perhaps the
biggest pitfall of this sort of project is that it is assumed that
daily operations can be maintain while the implementation is ongoing.
In fact, the logical approach is to come to terms with the following facts:
The current team is not experienced with enterprise software
The current team may not have the appropriate skill set needed when
implementation is complete. Either that or they won?t be happy doing
the type of work that may be asked of them.
Hiring new staff to bear the majority of the effort of the
implementation will allow your current group to continue supporting
daily operations. It will also build up the skills of resources who
don?t have internally defined boundaries on what their role is within
the company.
Once you?ve digested this, the following approaches are fairly sensible:
a) Rely on existing IT staff for work that requires knowledge of the
current systems and keeping operations running.
b) Hire new staff (preferably with experience in whichever solution
you choose) to act as your key resources long term.
c) Bring in consulting expertise, either from the vendor or an
external firm with significant experience in the product you are
implementing.
d) Once implementation is complete, work with each member of the
original IT staff to determine possible role transitions. There may be
mismatches in skills that are difficult to overcome. If an employee in
this position is still committed to continuing with the organization,
they would be a key candidate for training.
DATA CONVERSION
This topic is often looked upon as a detail that can be addressed as
necessary. For this reason, data conversion is one of the reasons why
plans to implement new systems are shelved or altogether cancelled.
Your existing software, a blend of Foxpro and .NET applications, are
essentially just tools for manipulating various subsets of data in SQL
Server databases. Each of these databases has what is known as a data
model, which is essentially a set of tables and relationships between
those tables. Although this is a simplified view of what is actually
in a database, it will do for the purpose of this discussion. Now the
data model for these systems defines the real world things (ie.
entities) that you are keeping track of, along with how they relate to
other things within the context of the business.
The often complex task of data conversion involves taking your current
data model and determining the best way to map it to the data model
provided by the enterprise package. The best case scenario is that the
package contains all of the critical entities of your business, and
some work will be required to match field names and data types. This
is rarely how it plays out. There is often customization required on
the enterprise package, or existing data needs to be creatively
?reshaped? to match what is defined by the new data model.
It is important to realize that enterprise software may not match your
business exactly. Most enterprise software is designed to be inclusive
of as much as can be conceived of within the vertical market that is
being targeted. The idea is that most companies that purchase the
software would much rather ignore entities and concepts than have to
come up with customizations that address specifics to their business
that don?t seem to exist within the enterprise package.
Although this approach often improves the situation, it is an educated
guess based on some level of market research. Until the vendor or a
consultant sees your data model, they will have a difficult time
determining how closely the two match up. Since you should be focused
on ensuring that your existing data maintains its integrity during
conversion, your database resources will be vital through this
process. Don?t be surprised if the ?jargon? of your business changes
slightly at the end ? terminology is one of the major confusions of
data transformation.
SYSTEM ARCHITECTURE
You indicated that your current environment is a mix of client/server
and server-driven environments. You should expect a unified
architecture at the end of your enterprise implementation. Each of the
modules within an enterprise application are designed over a common
architecture and connective group of data models. This increases
efficiencies when these modules need to interact with one another or
share common data.
From an overall architecture standpoint, moving to an enterprise
solution has major benefits for future growth and maintenance. This is
especially the case when you are moving away from a hybrid
architecture.
DEPLOYMENT
Although you may want a quick transition to the new system, this is
not suggested and probably not possible anyways. There are several
micro-strategies when deploying a new enterprise solution which is
meant to replace a legacy system:
a) Set up a separate hardware environments in advance ? you want to
make sure your existing systems are isolated from the new software
that will be coming online. This goes for both the application and
data layers.
b) Implement common (baseline) components or modules first ? this will
provide you with the groundwork for subsequent functional areas.
c) Aim to deploy the modules that are the simplest and of least impact
first. Mistakes are most likely to occur at the beginning, so it is
best to be in a situation where you can more easily reverse to an
earlier configuration.
d) Run your current and new systems in parallel ? this does not mean
that users should have a choice in which system they use. It is more
of a contingency to ensure that there is a quick workaround if
necessary.
e) The current system should progressively be taken offline piece by
piece, but only as its replacement is confirmed fully functional and
stable. Conversely, modules of the new system should be fully tested
prior to being put online for end users.
CONTINUING DAILY OPERATIONS
The problem that is likely to occur here is a conflict of priorities.
The group focused on rolling out the new system may not always think
about the impact of their actions on the line staff or keeping the
business running.
On the other side, business users may be focused on getting their own
jobs done rather than being willing to slow productivity for the
benefit of the new system.
There is no broad sweeping solution for this problem, but from the
technical side, here is what you can do to place checks and balances
on these two groups:
a) Scheduling windows for upgrades ? get approval from operations
management prior to setting these. They should ideally be at a point
where no users will be impacted (off-hours or weekends work best).
b) Script and schedule tasks or jobs to the greatest degree possible ?
this is much faster than having a technical resource performing the
same tasks manually during precious windows of availability of time.
The other benefit of this is that scripts can be run in test
environments beforehand to ensure they result in the correct outcomes.
c) Rearrange business operations if impact is minimal ? this is on a
case by case basis, but if it makes sense to have end users change
their schedules and doesn?t impact the bottom line, it should be
considered.
PHASING OUT EXISTING SOFTWARE
Overall, both the old system and new system should be running at all
times until a consensus has been reached that all functionality is
correct, complete, and stable in the new environment.
Again, this does not imply that either system can be used; it is
simply a failsafe. The IT group have the ability to essentially route
system usage in whichever direction makes sense as the implementation
progresses. This is done by modifying security settings for user
groups (if they exist) or blocking access to systems that shouldn?t be
available at a given point in time.
Client machines should also be updated so that previously installed
software is removed. This will reduce impact on support from users who
do not pay attention to notifications from IT.
MAINTENANCE PROCEDURES
From an enterprise point of view, maintenance includes
post-implementation activities that resolve an identified problem or
deficiency with the new system. Depending on what the problem is here
are some suggestions to deal with them:
a) Contact the vendor with the issue ? it is possible they have seen
the same thing before with other clients and may have a simple
solution.
b) Existing module customization ? a new business need may result in
the need to change/add functionality in the package application. It is
case-by-case on whether external involvement is needed here. Warranty
issues may set the course of direction here.
c) New module implementation ? this is likely rare unless this is a
previously identified area that was postponed and has now become
urgent. This is a mini-implementation that potentially has all of the
concerns associated with a full transition. Getting vendor input is
important, but if technical roles were correctly managed, an internal
resource should now be able to drive this change from within.
SUPPORT PROCEDURES
Support in this type of environment could be rather light if end user
training is done in a targeted and effective manner. Support staff
should be familiar with all modules that have been implemented so as
to provide guidance to business staff.
Mistakes made by users resulting in incorrect data in the system would
simply require an administrative-level user (supervisor or IT staff)
to go in and make the appropriate correction. Most enterprise software
is designed with this in mind and most have fairly comprehensive
management consoles built in to deal with these types of issues.
Although rare, extreme situations could require involvement from the
vendor. If a support package was purchased during the package
procurement, it should suffice. The process requires:
a) End users raises issue with IT
b) If IT cannot resolve, designate (sometimes specified in support
contract) will contact vendor support team
c) Issue is opened
d) Resolution or workaround, when found, is relayed back to internal designate
e) Designate relays solution to end user(s)
I hope the content above has given you an appreciate for the technical
considerations required during 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 |
