2.

5 ENTERPRISE RESOURCE PLANNING

1. How will you execute the Gap Analysis phase of ERP
implementation for a very large manufacturing industry?
Discuss the steps involved in this scenario.

All companies have objectives identifying where they would like

to be, potential projects, and long-term strategies, but this will do
them little good unless there is an effective way to measure
progress.

One effective way of determining where you are against where

you would like to be, whether you are a company or an individual,
is to perform a gap analysis. A gap analysis compares actual
performance (or status) with the desired performance (or status).
A gap analysis takes into account where the company is and
where it wants to be. Any review of a company and its goals
should include a thorough gap analysis – especially when wanting
to improve productivity, processes and products.

The first step to performing a gap analysis is formulating clear

objectives and goals. These objectives may cover any of the
following areas when concerning a company:
 The organization of the company

 The direction of the company

 The products of the company

 The processes of the company

 The IT associated with the company

 The bottom line of the company

At this point, it may be helpful to suggest that you keep separate
documents for each of your company’s objectives. This helps you
keep the following steps straight.

After formulating clear goals, and choosing a goal to focus upon,

the next step is listing all the features of the present situation that
relate to the goal you are analyzing. This will cover the “Where are
you?” part of the gap analysis. To do this, you may need to gather
extensive data about your situation. Complete this step for each
goal or objective you would like to analyze.

Next, you will need to list anything associated with the goal or
objective you or your company would like to achieve. In other
words, you will need to break down this goal into the component
parts that will need to be completed in order to achieve the goal.
Repeat this step for each goal or objective.

Now, look at where you are compared with where you need to be.
Are there any attributes in common between the two lists? If so,
great–those don’t need to be filled. But where are your biggest
gaps? How can you fill these gaps? What steps need to be taken?
Look at each attribute and carefully and honestly analyze what
needs to be done in order to ensure that attributes and factors
are completed. Sometimes, this will require multiple steps. Keep
track of each step involved.

Steps of Gap Analysis:

how to do a gap analysis, follow these three simple steps. Regardless
of your industry, you’ll be able to apply these tips across any discipline
and meet your business goals.

1. Analyze your current state

For those wondering how to do a gap analysis, you first need to

discover what we’re calling “the once and future you”—where your
organization currently is and where you would like to be.

Start with your current state. Your analysis can include qualitative
information, such as team processes/methodologies, and quantitative
information, such as the number of sales calls made each week. In fact,
your gap analysis process should evaluate everything you currently do
so you get the “big picture.”

2. Identify the ideal future state

Once you have a big picture figured out and understand how your
team or organization currently functions, you need to become
strategically idealistic. Where would you like to be? What’s not
happening that should be? What could be happening that hasn’t
before—or maybe was but changed? But most importantly, what
needs to happen to get there?

Maybe you have an exceptional marketing team that outsources all its
content; maybe your goal is bringing that creative process back in
house to meet your brand guidelines. Perhaps you realize you want to
create a cultural shift to better match your product or services. The
sky’s the limit, and you should dream big!

3. Bridge that gap

This is the harder part: getting from here to there. You have to
determine what gaps exist and how they’re preventing you from
reaching your goal. The better part is figuring out how to transcend
the difficulties. Establish clear objectives that will help you actualize
your transition. You can use the tools described below during this gap
analysis process.

Gap analysis process tools

Many tools exist to help you bridge the gap. Whichever tool you
choose, you can create any of the visuals you need in Lucidchart for
free.

SWOT analysis

SWOT analysis is, perhaps, one of the oldest textbook marketing

assets. SWOT is an acronym that stands for strengths, weaknesses,
opportunities, and threats. You can perform a SWOT analysis both
quantitatively and qualitatively. This process will help you determine
internal and external threats to your organization and see where how
you stand out against the competition.

Lucidchart acts as the ideal SWOT analysis tool. Get started with this
template!
McKinsey 7S Framework
The McKinsey framework was developed by its eponymous consulting
firm. It ultimately helps determine whether a company is meeting
expectations and actualizes the shared values of an organization. It
works through the 7 S’s of an organization to see what values cross
over. Additionally, this framework bridges the gap between the
company’s present and desired states.
Nadler-Tushman Model

Perhaps the most dynamic of the models, the Nadler-Tushman model

examines how each business process affects another and identifies
which gaps affect efficiency. It creates a holistic view of your
organization’s operational processes from beginning (input) to end
(output).

The model finds gaps by comprising your organization's processes

into three groups:

 Input: Entire company culture and workforce; all resources used

to create product/service, and operational environment
 Transformation: The systems, teams, and processes that take
the input value(s) and turn them into the output product
 Output: The final product or service
The gap analysis process is essential for any business to streamline
their operations for efficiency and cost-effectiveness. If you’re
considering process improvement, take a look at how using
Lucidchart can help with your endeavors!

2. Explain the Planning and Execution Model based on

integrated process for a service industry.

There are many ways an Enterprise Resource Planning(ERP)

implementation process can be troublesome, costly and frustrating, but
by trying to adhere to some ground rules the whole process can be
pushed in the general direction of success.

The following steps have been the product of years of learning by

different customer approaches and implementation methodologies and
should be considered before, during and after any ERP implementation.
These steps do not purport to be a definitive list or the exact recipe for
success, but by reading and acting on only a few of the suggestions here
will ensure your implementation goes smoother than it otherwise would
have done.
1. Understand your incumbent system
The decision to purchase a new ERP system has been made, but why?
There are many reasons a new ERP system will be sourced, but it is
important to understand that the implementation of a new ERP system
will not simply create a return on investment or solve the issues of the
business. These come from the process improvements; the ERP system
is a tool and improving the way a business uses the tool can reap
benefits.
The process of implementation does not start with the initial inviting of
suppliers to fill invitations to tender, it is when the company define the
goals that the new ERP system will set out to achieve. It is the goals that
are critical, and should be referred back to during and after the
implementation process to ensure focus is retained. If there is no clear
goal, the process of selecting a product and vendor will be a futile
process, whilst the overall situation may have improved this will bear no
resemblance to the investment of time and money made, and in many
cases the business would have been better off not changing.
Setting and defining these goals can be driven by the current system.
The business may have outgrown the system, or the system may be
non-compliant or non-supported, but whatever the reasons the system
and the processes inside and outside of the system must be understood.
Many businesses want to see X% improvement in Production efficiency,
Y% reduction in stock holding or a Z% customer service level, but
without understanding the processes behind the current figures there is
little benefit in moving forward with these targets because the new
system will be implemented using the old processes and produce the
same end results.
“The focus of this Magic Quadrant is on ERP systems that support a
single-instance strategy for multientity midmarket and upper midmarket
companies. User-centric improvements focused on usability and deeper
integration of analytical capabilities is at the core of leading systems.”

Without understanding what is causing the current figures,

improvements cannot be made. Additionally these figures need to be
recorded over a period of time in the old system and then compared to a
similar timescale in the new system after a period of stabilisation to try
and prove any improvements; many businesses never record these
figures and can never go back and justify an actual improvement even if
one exists.
The success of your future implementation lies in the process and data
of your current system. Study your current system at length and learn
from it to take forward the elements you do well, change the ones you do
not do well and enable you to statistically prove the success of the new
system compared to the old one.
2. Homework & Collaboration
Once a business has come up with clear defined goals that the new ERP
system must achieve and defined some tangible metrics to judge
success then the next step is to find the right product and the right
vendor.
There may be industry verticals supplying specific software to meet the
needs of your business, or a tailorable ERP system may meet the needs
of the business, but the key is to investigate, find out what your
competitors, vendors and customers are using. Many businesses send
out invitation to tenders listing hundreds of questions filled in by potential
vendors based upon an assumed set of answers to open questions.
Whilst these may assist in narrowing the choice down, the choice of
software alone cannot be based upon these.
It maybe that the software choice can be narrowed down, if it cannot get
businesses in to present the benefits of the software they supply. Once
you can decide on the software to meet the needs of the business you
need to choose the correct vendor, not simply the vendor who helped
you define the software choice.
Does the vendor have the ability to transform the business to help
achieve the set goals? If they cannot the likelihood is they are not the
correct vendor. However there are other methods that can be employed
to judge the suitability of the vendor. References must be taken,
preferably with site visits and face to face contact. Can the customers
acting on behalf of the vendor stand in front of you and tell you why you
should choose the product and the vendor?
This endorsement will show how the vendor and customer act in a
relationship, and this is a key concept to understand if you wish to
purchase from the vendor, because if you do you will soon be in the
same position as the reference extolling the virtues of the supplier. Ask
about the implementation methodologies; what standards are used and
are these industry recognised, proven and successful in the field
delivering tangible results?
Any vendor seeking to develop a long standing successful relationship
with you as a customer must be able to assist you in reaching your aims,
and will be able to prove they have done this in the past and have the
tools and resources in place to deliver a successful project.
If you cannot trust or work with the vendor then the project is very
unlikely to be successful. Therefore choose the vendor very carefully.

3. Budget Control
To be able to control a budget you need as a business to identify the real
costs of ERP. These costs can include hardware, training, organisational
change management, developments, staff cover for project members
and the software. The identification of a clearly defined budget scope is
critical and difficult. The ERP supplier can provide a scope of services
and a software and hardware budget, but this is not the entire budget.
The first question to clarify is what is “not” included in the budget. This
can traditionally be data migration, modification work and attendance
contingency. These elements will be unknown at the start of the project,
but should be estimated because they are critical to avoid significant
budget creep.
The non-budgeted elements are difficult to define because the breath of
these areas vary greatly project to project and business to business.
However it can be said that almost all projects involve data migration
and every project requires modification even if it is to the output
documentation.
Additionally there can be third party software costs, or non-related ERP
software costs, or freelance consultant costs. All of these need to be
estimated and entered into the control Budget Document.
The Budget Document is an evolving document as the project
progresses and the estimates are known in greater detail. Once the
business has a budget, it needs to control it.
This requires constant monitoring and change control where additional
work is required. It is critical to establish Project milestones, key sign off
points and compare the budget at each stage and more frequently if
possible, to control the budget. Active management of the budget is the
only way to manage and control overruns and alterations to the project.
This will include the auditing of budget expenditure from the software
vendor to verify vendor invoices to consultants’ timesheets – one of the
more costly elements of the project.
There are many methods to constructing a budget, but it is only as good
as the information the business inputs into it, and the subsequent
management and tracking of the budget. Ensuring tight control of the
budget can be the difference between a successful implementation and
one that whilst goes live successfully, does so at a massive overrun in
costs.
4. Resources and Team
Implementing an ERP project requires an internal project manager and
team. Whilst the majority of businesses try to achieve this by assigning
these roles to key members of the business and making them continue
to do the day-to-day work that has made them key, it is ultimately a
struggle and causes issues with the project and the business.
The most successful implementation projects have at least a 100%
dedicated internal project manager to ensure the project is kept on track,
on budget and moving in the right direction.
The key members of the team need to take ownership for the project and
to cascade this responsibility down through departments. The ownership
is achieved through involvement and ensuring all areas of the business
contribute to, and feel a part of the project.
The key members are critical. They have to adopt a positive attitude
towards the ERP change, resistance is amplified further down the
responsibility chain, and if the ERP “Champions” do not believe it will
work, why should anyone else?
The key members must be influential, be able to win over resistance and
promote the project within the business. To enable this they must be
respected or in areas of responsibility. Whilst having the knowledge to
understand the daily issues and processes they must also be considered
enough to make decisions that are based upon the overall good of the
business now and in the future.
The key members and the peripheral members of the team form the
departmental spearheads for the ERP project and will drive the success
of the project. Without the commitment of this team the project has a
much higher failure rate.
All staff involved in the ERP project are a resource the business has
direct control over. Priorities can be set and goals and milestones
achieved. However without the backing at management and board level
the project will drift and the team will concentrate on the daily workload
and general work responsibilities rather than the requirements of the
project.
The software partner will also provide consultants to guide the business
through the implementation. This is one of the largest costs of the project
and these also should be considered resources and part of the team.
The consultants can be limited to a single project, but this is expensive,
and if instead there are consultants planned to be part of the project it is
likely that they are assigned to multiple projects, and it cannot be
assumed that they will be available at short notice, these requirements
must be planned and controlled.
The consultant is also the initial knowledge holder and making them a
part of the team to deliver a successful implementation is critical. The
consultants should not be treated as an external isolated resource, they
should be considered part of the deliverable team and if the buy-in of the
consultants to the success of the project can be established along with
the buy-in of the staff then the success of the project as a whole is more
likely.
Related:ERP, WMS & TMS Data Collection Value Proposition

5. Training and Understanding – User Acceptance

There are many philosophies on how best to train staff, but the simple
rule to follow is to actually train the staff.
During implementations there are many methods of training, but before
any of this can really commence the software must be understood by the
business, and the business must be understood by the ERP partner.
This is not simply how the incumbent software is used, but the business
processes, requirements and the reasons behind why transactions and
processes are undertaken. This understanding will lead to further
questioning and mapping of processes to the new software to see how
the software can be leveraged to full potential to meet the needs of the
business.
Redundant system based processes adopted for historical or system
restrictive reasons should be questioned, clarified and where possible
integrated into a new method, or if possible dropped altogether.
With the harmonising of business and software understanding the
processes can be mapped into the software and a training plan
developed. This may include initial training sessions with the key
members of the project team, in a train the trainer format. It may also
include scheduled classroom sessions for departmental members, or
entire departments. It is critical when training end-users that the
processes are agreed with the key team members beforehand to ensure
the sessions delivered meet the needs of the business.
The training itself can take many forms, but generally the most
productive form is hands on sessions where the users have individual
access to a test system and are given scenarios to create or follow.
The training of the users however is not the end of this process.
Once trained the users need to process train. Training in isolation may
help the user gain an initial understanding of how the software works,
but undertaking this in process loops is an essential step. By undertaking
this the business gets to see how each department impacts on the other
and how the decisions made upstream affect what the downstream
departments “have” to do. Additional to this, and perhaps more critically,
holes between the departments begin to appear from a software
perspective. If discovered and understood at this stage provision can be
made, but if this is not undertaken these issues can only be uncovered
at go-live.
The acceptance of the users in totality is critical. Once the business
understands how the business process flows through the software the
business can assess the suitability of the processes, and whether they
are really needed, or with the implementation of the new software
whether other alternatives are now present from the software itself.
The entire processing cycle must be undertaken, and not simply once,
different scenarios, different issues and different users should be used.
All users generally bring a different perspective and a different set of
questions and issues to the table. By collating all of these requirements
the business has the best possible chance of going live smoothly.
Undertaking this will mean all of the processes are understood, and the
users understand how to use the software to meet the needs of the
business.
If a business chooses to be trained and then go live without letting the
users undertake static and process testing then all of the process gaps
and issues will be discovered at go-live. The incumbent system will have
been bent and abused to hide and conceal these gaps. The current
system is as yet unaware of these issues and needs to be warned. It
should not be expected that the new system will solve all of the issues of
the old system, primarily because these are generally not software
issues, they are process issues, but secondly because no one in the
process of training has discovered they exist.
6. Data Migration
The common response to the question “What data from your current
system do you want migrating to your new system?” is “Everything”.
Whilst this is possible, it would probably cost more and take more time
than the current ERP project being undertaken.
There are many pitfalls in the sub-project of data migration, but the
underlying starting point is to be realistic. It should also be noted from
the budgeting section that this area is not generally in the budget at the
outset and therefore the business needs to consider what adding a
multitude of days development would do to the budget at this stage.
The first question regards the areas of the business requiring data
migration. This can generally be assessed on a volume basis. If there
are 100,000 item records then they will be migrated, if there are 10 they
will be keyed. Between these levels of volume assessments there is a
grey line where a decision is made; and this line moves in volume
depending upon the area of the records being migrated and the
complexity. Another possible solution is the manual keying of data. This
in itself acts as further training, and if the volumes permit can be used on
open purchase and sales orders to dismiss the complexity of dynamic
data migration.
Once the automated areas have been decided the next issue is the data
itself. There are generally several issues with the data; the structure of
the tables will be different, concepts in one system not being present in
another, the data itself will be of poor quality, a common example of this
is address records stored in completely separate text fields with different
county references and no way of mapping these to the new and different
address format, and the new system can be used in a manner that the
existing data is not set up to handle.
One common requirement or request is for sales history to be migrated.
To migrate into posted ledger tables and mark transactions as fully paid,
with all of the reporting requirements of the new system catered for is a
very lengthy and costly process that generally would never make a
return on investment. Far more productive is to push the legacy data into
a separate referenced SQL database or cube for cross analysis with the
new system, or to simply leave the data where it is for user reference.
Converting any form of historical data should be considered carefully
with regards to benefit, timescales with the impact on the project, and
cost.
Where the new system requires different settings and categorisations
that do not exist in the current system the first issue is the
transformation. The best method of this is to create these settings during
the export routine of the legacy data if possible. The last option is to key
these into the exported data ready for import – human errors will cause
issues.
This project can run parallel to the ERP implementation project, and if
possible the user acceptance training can be undertaken on the initial
passes of migrated data.
The methods and processes for extracting, transforming and importing
the data vary between systems, but one common factor is that the
internal IT staff will be part of the process. It should be remembered that
the IT staff are focused generally on the migration of data, that is to say
the focus is on getting data from one field into another, and not that the
end result meets processing requirements.
The final data routines should be finalised months in advance of a go
live. Whilst initially testing will be undertaken on subsets of data it is
imperative prior to live that at least one full import run is undertaken to
ensure all of the possible issues from a full import are understood and
potentially resolved in advance of the live date.
Once data exists and is present in a test system the end users
responsible for the data must test this thoroughly. Responsibility for the
acceptance of the resulting data in the end system resides with the end
users and not the IT staff responsible for the transformation. This means
to ensure the best possible results from the data migration project the
routines must be run in full in advance of the live date and the end users
must test, test and then test again.
Related:Are Enterprise Resource Planning Systems the Right Tool for
Today’s Trading Networks?

7. Go Live perpetually
At the end of months and months, or even years and years, the business
and the team will finally manage to drag themselves across the finish
line. The business has made it, at last! That is it, the project is
completed, there is relief all around as people can now concentrate on
their day jobs. Simply put the answer to this is “NO”.
Going live is simply the start of the next phase of the project. There will
have been requirements, issues, modifications and suggestions that
were not on the business critical path, or were even purposely moved off
the business critical path, and now these must be addressed. The
original goals set out during the purchasing process should be reviewed
for relevancy and achievement.
Whilst there is a period of settling in to the new system to gain the full
leverage of the software and the change, the original reasons for change
and the strengths of the new software and possibilities must be brought
to the fore. Implementing a whole new system and getting back to where
the business started with a new front end and a new way of processing
the business through software is not success, it is a costly way of
standing still.
Even if the business has implemented a system and there was very little
in the second phase and they have made massive leaps forward
throughout the business this is still not the time to do nothing. The go live
process is perpetual. Standing still after go live will see the business
begin to slip backwards from an ERP perspective.
The system needs to be constantly reviewed, processes and
applications should be assessed for suitability and purpose, and where
gain can be extracted from a change it should be made.
If at this stage the business stops the process of going live on the new
software it is a distinct possibility that in the next five to ten years they
will be undertaking a new implementation project to install a new system
because the incumbent system does not meet the needs of the
business. It does not meet the needs of the business because the
business does not understand one of the costliest most powerful tools
they possess and they never developed it to its full potential. This in turn
brings us full circle, knowing your incumbent system – without it the
business will not be going live perpetually, they will be implementing
ERP perpetually.
There is generally no quick and easy solution to implementing an ERP
system in a business of any size. This is gauged on the size of the
business, you can implement an accounts system in a small business
relatively quickly and cost effectively – but would you want the same
timescales implementing in a multi-site, multi-million pound, 1000
employee business?
As a business the need to be realistic at the outset is paramount. The
process, if done correctly, takes time, costs money and requires great
internal resource commitment. All of these can be compromised to some
extent, but there is always a balance in the end, and this will come in the
system that the business ends up going live with. Compromise on the
project and you are compromising the end solution, and potentially the
growth and future of the business.
Implementing an ERP system is not straightforward, but remembering
some of these simple suggestions will help the project have a greater
chance of success than ignoring them.