Evaluation and Selection of ERP

Packages
Evaluation and selection of ERP package is an essential criterion for successful ERP implementation.
Quality of selection will have a long term impact on the processes of the organization. It is also not
easy to switch to another product with concomitant scale of investment and complexities. This
evaluation and selection process should be properly directed and normally comprises of following
activities:

Formation of an evaluation committee: An ERP implementation is not an IT project but a

business oriented development. Therefore, in addition to Chief Information Officer, this committee
should comprise of all functional heads and driven by a top management representative. Since all
business functions are represented in selection process, the chosen package would have wide
acceptance subsequently.

Requirement Analysis: This analysis should outline functional expectations of various business
divisions, such as warehouse, finance, procurement, from potential ERP package. Vital requirements
specific to the company should be highlighted e.g.

 Must have Distribution Requirement Planning (DRP) functionality.

 In transit inventory and pallet tracking, as a part of shipping requirement.
 Multiple purchase orders linked to one bill of lading.
 Multi currency and multi locations functionality.

Requirement analysis forms a base for preparing a Request for Proposal (RFP), where important
technical and commercial perquisites are incorporated. Common examples of technical perquisites:
flexibility, Upgradability, User friendliness, field level security, Operating system and database
compatibility. Common examples of commercial perquisites: cost, reference sites, high level project
plan, resumes of consultants, post implementation support, financial health of the company, local
presence, number of installation and upgrade.

Selection Criteria: A pre-determined selection Criteria should be ready before actual selection
process commences. Selection criteria are normally in the form of questionnaire and point system,
where each question represents a business or technical need. Weightage for each point or a group of
points are predetermined which varies according to criticality of the issue. These processes help in
making the selection process objective and transparent.

Selection Process: Selection process constitutes various stages as mentioned below:

1. Short listing of vendors: Hundreds of ERP packages are available in the market, which
have different concept, architecture and sets of functionalities. Analyzing all the packages is
not feasible. Organization need to identify a few best suited packages by looking at product
literatures of vendor, finding out which product is being used by their peer organizations and
getting help from external consultants. Once a few packages are short listed, respective
vendors should be asked to respond to the RFP, as per its format.
2. Demo and Presentation: Responses from shortlisted vendors are evaluated by the
selection committee after collating scores obtained by them and a consensus is reached
about their final ranking. Anyone not fulfilling a predetermined vital requirement is eliminated
at this stage. Top two or three vendors, are then invited for demo and presentation. Mode of
presentation should be carefully scripted and send to the vendors in advance. They should be
asked to walkthrough a particular business cycle through their vanilla software. They should
be specifically asked to clarify any area of concern about their proposal, which may expose
weak/ problem area of their offer.
 3. Site visit and contract negotiations: After the committee has reached a decision on best
suited package, visits to reference sites are imperative. The vendor should provide reference
sites of similar size and industry, identical version and belonging to same geographical
location. Team members should have look and feel of the systems operating at reference
sites and ask pertinent questions covering overall satisfaction, functionality, cost/ time over
run, support concerns etc. After site visit, if the committee members feel that their selection
is right, they proceed with final negotiation and procurement. Negotiations are normally held
on license and annual maintenance cost, payment plan including a leasing option, support
issues and other commercial and legal terms.

Conclusion

The most important point of selection process is that it should be based on a consensus and have
maximum buy in as an ERP system belongs to all functions and departments. Another important issue
is that over expression of requirement during requirement planning should be avoided as this will lead
to incurring unnecessary expenditure.

ERP Systems Integration is not without risk. Projects can go over time and
budget, fail to create optimal business processes or even fail when risk
factors are not mitigated and adjustments are not made. Several factors
should be considered when developing an approach to risk mitigation in
your ERP Systems Integration Project:

1. Number of integration points. Projects that attempt to integrate

everything at once, sometimes called “the big bang approach,” are prone to
adverse results due to the extreme complexity and large number of
interdependencies. Scale down the scope of your first few projects and
focus on quick, easy wins while your team increases its capabilities.
2. Changing Requirements. When the use case has been poorly thought
through, requirements can change frequently and create chaos in an ERP
integration project. Make sure you spend enough time in the requirements
gathering and process planning phases to gather the best possible set of
requirements for your project.There is nothing wrong with using agile
methodology, but it still helps to have a clear vision before you begin.
3. Inadequate integration infrastructure. Undertaking an ERP
integration project with the wrong infrastructure to support your team can
lead to serious issues and excessive costs. Avoid solutions that rely on
manual programming or overly complex, heavy middleware software sets.
Focus on single stack, single studio solutions with an integration platform
for enterprise class integration projects.
4. Impossible Schedules. Aggressive schedules are fine but impossible
schedules must be avoided. Set realistic expectations by establishing an
accurate estimate of the integration efforts required for your project. If
 necessary, bring in an outside firm to provide an estimate of the effort
required.
5. Staff Turnover. Changes in project management, business analysts,
developers, and stakeholders can complicate completion of a project. Try
to avoid turnover by gaining commitments from participants that they are
available for the expected duration of the project.
6. Inadequate Change Management Procedures. Some organizations
lack the formal methodology to handle change orders. In addition, changes
to the ERP and other systems being integrated may not be locked down
during the integration project. The result can be chaotic from a
requirements, implementation and testing perspective.
7. Lack of Staff and Management Experience. ERP integration may be
new territory for your IT staff and management. Try supplementing your
experience with proven consultants or consulting firms that can leverage
experience across a wide array of ERP integration projects.
8. New Business Processes. Introducing change to an organization
always carries with it the risk of institutional or market resistance. Make
sure the processes have been vetted by stakeholders and customers and
that they are introduced properly so as to gain maximum adoption and
adherence.
9. New integration infrastructure. New or unproven integration
infrastructure represents a risk factor. Make certain vendor experts are
available to back up your team not only with technical bugs but with
implementation experience and best practice advice and or services.

10. Inadequate testing plans. Test plans should introduce testing early
and often. Test scripts and automated testing may be able to help ensure
accelerated and more complete discovery of problems early in the ERP
integration project.

INTRODUCTION TO DATA MIGRATION

Data migration is a systematic and phased approach for transferring data between (multiple) systems
based on a specific migration methodology. The driver for data migration is often based on the
business decision to modify the ERP landscape.
Data migration is a value adding activity for the organization. Moreover, an end to end data migration
exposes the full data landscape of an organization in an unique way. Going through the migration
process as such can reveal many unknowns in organizational data and data relationships and enables
mapping of the full organizational data landscape. In addition, data migration supports the
identification of data owners and can be an improvement or a solid start for setting up data
governance within your organization.
It is worth mentioning that data migrations are always complex in their nature. It is of critical
importance to design internal controls that provide assurance regarding completeness and accuracy
of the data selected for migration. A solid and extensive data reconciliation framework including
checks and balances is of crucial importance in order to verify the completeness and accuracy of the
migrated data. Based on our experience, data migration consumes on average 15-25% of the project
implementation budget.
With regard to the ERP data migration we have identified two approaches based on our industry
experience. These two approaches will be explained in detail within this article. Both approaches have
their own specific complexity and challenges.
The transaction driven approach is the most common approach for an ERP migration. In this
approach data is extracted from the legacy system and converted into a load file which in turn can be
loaded with the use of standard load programs provided by the ERP system. Often the scope of data
migration is limited to active data and is therefore more cost effective when compared with the table
driven approach.
The table driven approach is less commonly used as this entails the full transfer of tables without any
selection criteria. Based on our experience for a multinational client, we have an interesting real-time
case where the table driven approach is implemented successfully in an SAP ERP environment.
Respectively, the transaction and table driven approach will be described in the following paragraphs
by explaining the two approaches and their inherent benefits and challenges.

ERP Data Migration Strategies

for Successful Implementation
To make an ERP implementation successful data migration is the key
factor. When a data can migrate effectively that proves that the ERP
system is just appropriate for them. And this projection builds their
confidence in the system and which in n turn becomes the key factor of the
success of ERP implementation. Though while implementing an ERP the
main focus is on the modules attached with it and how popular it is, but
what they lack is the focus in the operation of the system, that is real time
data migration, which cannot be determined till the ERP is started working
full fledged with all real time data, and when some one find out that the
data is not migrating efficiently and effectively then the ERP implementation
is becomes a failure. The real problem lies in the fact that data migration is
the last activity we do, because real time data can only migrate when the
system is about to working live, so the real problem area starts after that.
Strategy of Data migration There are few strategies that need to be
followed while migration of data - 1. Data identification for migration. 2.
Determine the time for data migration. 3. Generation of the data templates.
4. Data migration tools need to free zed. The data Identification for
migration The Identification of the need to be migrated to any applications
consists of four groups of data. A particular order need to be followed while
entering the data as, all data is interdependent. The order is like A.
Configuration Data - These data are for one time feeding into system that's
required for set up. B. Sub master Data - These data are mainly related to
any transaction procedures. C. Master Data - These are the data which are
being regular updated. It relates from sales module to purchase modules to
stocks and inventory. D: Transaction Data - These are the data which are
entered at the end of all these above data entry order. It consists of
balance sheets, reports, and other end results. Data load timing 1. As we
discussed above the timing should starts from set up data and it will end at
transaction data. But as set up data can be entered just one time so
exception caution should be taken while entering it. 2. And same rule goes
for the case of sub master's data entry. 3. And for Master data and
transaction data, both are continuous process so loads on tools need to be
taken care. Templates These are sharable components mostly for various
users, between different countries or continents so it should be created and
modified keeping the exact purpose of sharing. Tools to be used There are
four different tools can be used to load data into the database. 1. Desktop
Integration - This tool is used for one window based process. 2. SQL
Loader - These tools accept data from databases. 3. Oracle Standard APIs
- This tool is meant for oracle database. 4. Custom Built Interfaces - These
are custom's verified data for loading into database. Conclusion Data
migration is very important activity in establishing the success of an ERP
implementation. An accurately migrated data is a reflection to the
stakeholders that the ERP system is perfect and gives clear indication of
their current organization. This increases their level of confidence in the
system and in turn is a key factor in the ultimate success of ERP
implementation..