SAP Implementation

From Wikipedia, the free encyclopedia

Jump to: navigation, search
SAP Implementation is the whole of processes that defines a complete method to implement the Enterprise
Resource Planning SAP ERP software in an organization. The SAP implementation method described in this
entry is a generic method and not a specific implementation method as such. It is based on best practices and
case studies from various literature sources and presents a collection of processes and products that make up
a complete implementation method to allow any organization to plan and execute the implementation of SAP
software.

Contents
[hide]

1 Introduction
2 Overview
3 Table of concepts
4 Activity table
5 Implementation processes
o 5.1 Project preparation
o 5.2 Sizing and blueprinting
o 5.3 Functional development
o 5.4 Final preparation
o 5.5 Go Live
6 Critical success factors
7 See also

8 References

[edit] Introduction
The implementation of SAP software, such as SAP R/3 is almost always a massive operation that brings a lot
of changes in the organization. The whole process can take up to several years. Virtually every person in the
organization is involved, whether they are part of the SAP technical support organization (TSO) or the actual
end-users of the SAP software. The resulting changes that the implementation of SAP generates are intended
to reach high level goals, such as improved communication and increased return on information (as people
will work with the same information). It is therefore very important that the implementation process is
planned and executed with the usage of a solid method. There are various SAP implementation methods. An
example of how one company, Robert Bosch GmbH, implemented SAP R/3 over 10 years is available [1].
This study shows that designing IT architecture is very critical in SAP implementation practices.

[edit] Overview

Figure 1: SAP Implementation process-data diagram

The SAP implementation process is made up out of four main phases, i.e. the project preparation where a
vision of the future-state of the SAP solution is being created, a sizing and blueprinting phase where the
solution stack is created and training is being performed, a functional development phase and finally a final
preparation phase, when the last tests are being performed before the system goes live. For each phase, the
vital activities are addressed and the deliverables/products are explained.
The process-data diagram that is depicted at the right, gives an overview of all of these activities/processes
and deliverables. The four gray boxes depict the four main implementation phases, which each contain
several processes that are in this case all sequential. The boxes at the right show all the deliverables/concepts
that result from the processes. Boxes without a shadow have no further sub-concepts. Boxes with a black
shadow depict complex closed concepts, so concepts that have sub-concepts, which however will not be
described in any more detail. Boxes with a white shadow (a box behind it) depict open closed concepts,
where the sub-concepts are expanded in greater detail. The lines with diamonds show a has-a relationship
between concepts.
Many of implementations are also done with ASAP (Accelerated SAP) methodolgy evolved from best
practises in SAP.

[edit] Table of concepts

The data table below provides a summary of all the concepts addressed in the process-data diagram.
Concept
CHANGE
MANAGEMENT

CHANGE
MANAGEMENT
DOCUMENTATION.
COST OF OWNERSHIP
ANALYSIS
CUTOVER
CUTOVER PLAN

Definition
***Activities involved in (1) defining and installing new values, attitudes,
norms, and behaviors within an organization that support new ways of doing
work and overcome resistance to change; (2) building consensus among
customers and stakeholders on specific changes designed to better meet their
needs; and (3) planning, testing, and implementing all aspects of the transition
from one organizational structure or business process to another. (www.gao.gov)
All documentation that is required and being delivered whilst performing change
management, e.g. the functional test cases and all the other documents a new
end-user of SAP requires and the various tools and approaches used to manage
change by the TSO. (Anderson, 2003)
Determination of where and when the costs are inquired within the context of the
SAP solution stack and ongoing operations. The analysis addresses all internal
and external costs, both one-time as well as recurring (Anderson, 2003)
The process of transitioning from one system to a new one (Anderson, 2003)
All documentation related to planning, preparing and executing cutover,

describing how to lock down the system from a technical change management
perspective, preparing the TSO for its new role and rolling out the SAP graphical
user interface to all future end users. (Anderson, 2003)
A data center is a facility used for housing a large amount of electronic
DATA CENTER
equipment, typically computers and communications equipment.
(www.wikipedia.org)
A requirement for the SAP data center, i.e. a physical requirement like power
DATA CENTER
requirements, a rack requirement, a network infrastructure requirement or a
REQUIREMENT
requirement to the network server. (Anderson, 2003)
DISASTER RECOVERY Requirement that focuses on downtime that lasts many hours to days or even
(DR) REQUIREMENT
weeks (Anderson, 2003)
FUNCTIONAL TEST
A set of conditions or variables under which a tester will determine if a certain
CASE
business process works (www.wikipedia.org)
HIGH AVAILABILITY
Requirements that describes the amount of time that the system needs to be
(HA) REQUIREMENT
available to satisfy the needs of the users. (Anderson, 2003)
INSTALLATION
All documentation related to the installation of an end-to-end SAP solution
DOCUMENTATION
(Anderson, 2003)
The collection of current state system documentation, day-to-day and other
OPERATIONS MANUAL regularly scheduled operations tasks, various installation and operations
checklists and how-to process documents. (Anderson, 2003)
SAP AG is the name of the biggest European software company. The head office
is in Walldorf, Germany. SAP was founded in 1972 as Systemanalyse und
SAP
Programmentwicklung ("Systems Analysis and Product") by five former IBM
employees in Mannheim, Germany. (www.wikipedia.org)
SAP IMPLEMENTATION A comprehensive project plan that contains all products that are delivered whilst
PROJECT PLAN
performing an SAP implementation project (Anderson, 2003)
Set of software subsystems or components needed to deliver a fully functional
SOLUTION STACK
solution, e.g. a product or service. (www.wikipedia.org)
SOLUTION STACK
A list of all vendors that deliver the products that make up the SAP solution
PARTNERS LIST
stack (Anderson, 2003)
SOLUTION VISION
A vision of the future-state of the SAP solution (Anderson, 2003)
A test plan that is focused at determining the stability of a given system or entity.
STRESS TEST PLAN
It involves testing beyond normal operational capacity, often to a breaking point,
in order to observe the results. (www.wikipedia.org
A detail of how the test will proceed, who will do the testing, what will be tested,
TEST PLAN
in how much time the test will take place, and to what quality level the test will
be performed. (IEEE 829)
The acquisition of knowledge, skills, and attitudes as a result of the teaching of
TRAINING
vocational or practical skills and knowledge that relates to specific useful skills
(www.wikipedia.org)
Consisting of training units, a training plan is the result of hierarchical
decompositions of a training goal, tailored according to the learning preferences
TRAINING PLAN
and prior knowledge of the trainee. A plan is the means by which the trainee
satisfies the goal. (www.ece.eps.hw.ac.uk/)
Technical Support Organization. The people that are committed to
TSO
implementation and management of SAP. (Anderson, 2003)
TSO CHART
A chart that depicts the structure of the TSO. (Anderson, 2003)

[edit] Activity table

The following table provides a summary of all of the activities that form the SAP implementation process.
These activities will be described with more detail and elaborated with examples in the rest of this entry.
Activity

Sub-Activity

Description
Refine and communicate a SOLUTION VISION of the future-state of
the SAP solution, to sketch a design that meets both business and
financial requirements. The focus should be on the companys core
business and how the SAP solution will better enable that core business
Craft solution vision
to be successful. Some of the guidance and key requirements for how to
Project
put together an ERP and SAP business case for ROI, business benefit,
preparation
and successincludes focusing on competitive pressures, value
propositions, and how the solution enables success.
Design and staff the key positions of the SAP Technical Support
Design and initially
Organization (TSO), the organization that is charged with addressing,
staff the SAP TSO
designing, implementing and supporting the SAP solution.
Perform a COST OF OWNERSHIP ANALYSIS to determine how to get
Perform cost of
the best business solution for the least money i.e. to determine where
ownership analysis and when the costs are incurred within the context of the SAP solution
stack.
Identify high
Determine all HIGH AVAILABILITY and DISASTER RECOVERY
availability and
REQUIREMENTS, to plan what to do with later downtime of the SAP
disaster recovery
system
requirements
Engage SAP
Select the best SAP hardware and software technology partners for all
solution stack
layers and components of the SAP SOLUTION STACK, based on a
vendors
side-by-side sizing comparison
Staff the bulk of the TSO, i.e. fill the positions that directly support the
Sizing and
Staff TSO
near-term objectives of the implementation, which are to develop and
blueprinting
begin installation/implementation of the SAP data center.
Train the various members of the SAP TSO, like data center specialists,
Execute training
high availability specialist and network specialists and train the endusers to give all the required SAP knowledge and skills
Build a new SAP DATA CENTER facility or transform the current data
Setup SAP DATA
center into a foundation capable of supporting the SAP SOLUTION
CENTER
STACK
Perform
Install the (My)SAP components and technological foundations like a
installations
web application server or enterprise portal.
Round out support Identify and staff the remaining TSO roles, e.g. roles that relate to help
for SAP
desk work and other such support providing work.
Develop a planned approach to the changes in the organization. The
Address Change
objective is to maximize the collective efforts of all people involved in
Management
the change and minimize the risk of failure of implementing the changes
related to the SAP implementation.
Address SAP
Create a foundation for the SAP systems management and SAP
systems and
SAP functional
computer operations, by creating a SAP OPERATIONS MANUAL and
operations
development
by evaluating SAP management applications.
management
Test the SAP business processes, by executing functional tests to ensure
Perform functional, that business processes work, integration tests to ensure that the
integration and
organizations business processes work together with other business
regression tests
processes and regression tests to prove that a specific set of data and
processes yield consistent and repeatable results.

Final
Preparation

Go Live

Plan, script, execute and monitor SAP STRESS TESTS, to see if the
expectations of the end users, defined in service level agreements, will
be met.
Plan, prepare and execute the CUTOVER, by creating a CUTOVER
Prepare for cutover PLAN that describes all cutover tasks that have to be performed before
the actual go-live
Turn on the SAP system for the end-users
Perform systems
and stress tests

[edit] Implementation processes

[edit] Project preparation
The project preparation phase, depicted below, focuses at two main activities, i.e. to make a setup for the
TSO and to define a solution vision. These activities allow an organization to put in on the right track
towards implementation.

Figure 2: Project preparation phase

Design and initially staff the SAP TSO

Figure 3: TSO chart example

The first major step of the project preparation phase is to design and initially staff an SAP technical support
organization (TSO), which is the organization that is charged with addressing, designing, implementing and
supporting the SAP solution. This can be programmers, project management, database administrators, test
teams, etc. At this point, the focus should be at staffing the key positions of the TSO, e.g. the high-level
project team and SAP professionals like the senior database administrator and the solution architect. Next to
that, this is the time to make decisions about choosing for internal staff members or external consultants.
The image at the right shows a typical TSO chart.
Craft solution vision
The second project preparation job is to define a so-called solution vision, i.e. a vision of the future-state of
the SAP solution, where it is important to address both business and financial requirements (budgets). The

main focus within the vision should be on the companys core business and how the SAP solution will better
enable that core business to be successful. Next to that, the shortcomings of the current systems should be
described and short but clear requirements should be provided regarding availability (uptime), security,
manageability and scalability of the SAP system.

[edit] Sizing and blueprinting

The next phase is often referred to as the sizing and blueprinting phase and forms the main chunk of the
implementation process. The phase is illustrated below.

Figure 4: Sizing and blueprinting phase

Perform cost of ownership analysis

Figure 5: Solution stack delta analysis

This phase starts with performing a total cost of ownership analysis (TCO analysis) to determine how to get
the best business solution at the lowest costs. This means to compare SAP solution stack options and
alternatives and then determine what costs each part of the stack will bring and when these costs will be
incurred. Parts of the stack are for example the hardware, operating system and database, which form the
acquisition costs. Next to that, there should be taken a look at recurring costs like maintenance costs and
downtime costs. Instead of performing a complete TCO analysis for various solution stack alternatives that
would like to compare, it can be wise just to do a so-called delta analysis, where only the differences
between solutions (stacks) are identified and analyzed. The image at the right depicts the essence of a delta
analysis.

Identify high availability and disaster recovery requirements

The next step is identifying the high availability requirements and the more serious disaster recovery
requirements. This is to plan what to do with later downtime of the SAP system, caused by e.g. hardware
failures, application failures or power outages. It should be noted that it is very important to calculate the
cost of downtime, so that an organization has a good idea of its actual availability requirements.
Engage SAP solution stack vendors

Figure 6: Simplified SAP solution stack

A true sizing process is to engage the SAP solution stack vendors, which is the next step. This means
selecting the best SAP hardware and software technology partners for all layers and components of the
solution stack, based on a side-by-side sizing comparison. The most important factors that are of influence
here are the estimated numbers of (concurrent) users and batch sizes. A wise thing to do is to involve SAP
AG itself to let them create a sizing proposal stating the advised solution stack, before moving to SAPs
technology partners/SAP vendors, like HP, Sun Microsystems and IBM. A simplified solution stack is
depicted at the right, showing the many layers for which software and hardware has to be acquired. Note the
overlap with the OSI model.
Staff TSO
The TSO is the most important resource for an organization that is implementing SAP, so staffing the TSO is
a vital job which can consume a lot of time. In a previous phase, the organization should already have staffed
the most vital positions. At this point the organization should staff the bulk of the TSO, i.e. fill the positions
that directly support the near-term objectives of the implementation, which are to develop and begin the
installation/implementation of the SAP data center. Examples are: data center experts, network infrastructure
experts, security specialists and database administration experts.
There are many ways to find the right people within or outside the organization for all of the TSO positions
and it depends on the organization how much time it wants to spend on staffing.
Training
One of the most vital stages of the implementation process is training. Very few people within an
organization are SAP experts or even have worked with SAP software. It is therefore very important to train
the end users but especially the SAP TSO: the people who design and implement the solution. Many people
within the TSO need all kinds of training. Some examples of these positions:

SAP Network Specialists

SAP Database Administrators
SAP Security specialists
Documentation specialists
Et cetera

All of these people need to acquire the required SAP knowledge and skills or even SAP certifications
through training. Moreover, people need to learn to do business in a totally new way. To define how much
SAP training every person needs, a company can make use of a skillset matrix. With this matrix, a manager
can identify who possesses what knowledge, to manage and plan training, by defining the height of expertise
with a number between e.g. 1 and 4 for each skill for each employee.
Setup SAP data center
The next step is to set up the SAP data center. This means either building a new data center facility or
transforming the current data center into a foundation capable of supporting the SAP solution stack, i.e. all of
the technology layers and components (SAP software products) in a productive SAP installation. The most
important factor when designing the data center is availability. The high availability and disaster recovery
requirements which should have been defined earlier, give a good idea of the required data center
requirements to host the SAP software. Data center requirements can be a:

Physical requirement like power requirements

Rack requirement
Network infrastructure requirement or
Requirement to the network server.

Perform installations
The following step is to install the required SAP software parts which are called components and
technological foundations like a web application server or enterprise portals, to a state ready for business
process configuration. The most vital sub steps are to prepare your OS, prepare the database server and then
start installing SAP software. Here it is very important to use installation guides, which are published for
each SAP component or technology solution by SAP AG. Examples of SAP components are:

R/3 Enterprise Transaction Processing

mySAP BI Business Information Warehouse
mySAP CRM Customer Relationship Management
mySAP KW Knowledge Warehouse
mySAP PLM Product Lifecycle Management
mySAP SCM Supply Chain Management
mySAP SEM Strategic Enterprise Management
mySAP SRM Supplier Relationship Management
mySAP HCM Human Capital Management

Round out support for SAP

Before moving into the functional development phase, the organization should identify and staff the
remaining TSO roles, e.g. roles that relate to helpdesk work and other such support providing work.

[edit] Functional development

The next phase is the functional development phase, where it is all about change management and testing.
This phase is depicted below.

Figure 7: Functional development phase

Address change management
The next challenge for an organization is all about change management / change control, which means to
develop a planned approach to the changes the organization faces. The objective here is to maximize the
collective efforts of all people involved in the change and to minimize the risk of failure of implementing the
changes related to the SAP implementation.
The implementation of SAP software will most surely come with many changes and an organization can
expect many natural reactions, i.e. denial, to these changes. To fight this, it is most important to create a solid
project team dedicated to change management and to communicate the solution vision and goals of this team.
This team should be prepared to handle the many change issues that come from various sources like:

End-user requests
Operations
Data center team
DBA group
Systems management

SAP systems and operations management

Next thing is to create a foundation for the SAP systems management and SAP computer operations, by
creating a SAP operations manual and by evaluating SAP management applications. The manual is a
collection of current state system documentation, day-to-day and other regularly scheduled operations tasks,
various installation and operations checklists and how-to process documents.
Functional, integration and regression testing
Testing is very important before going live with any system. Before going live with a SAP system, it is vital
to do many different kinds of testing, since there is often a large, complex infrastructure of hardware and
software involved. Both requirements as well as quality parameters are to be tested. Important types of
testing are:

Functional testing: to test using functional use cases, i.e. a set of conditions or variables under which
a tester will determine if a certain business process works
Integration testing
Regression testing

All tests should be preceded by creating solid test plans.

[edit] Final preparation

The last phase before going live can be referred to as the final preparation phase and is depicted below.

Figure 8: Final preparation phase

Systems and stress testing
Another vital preparation activity before going live with SAP is systems and stress testing. This means
planning, scripting, executing and monitoring system and stress tests, to see if the expectations of the end
users, defined in service level agreements, will be met. This can be done with SAPs standard application
benchmarks, to benchmark the organizations configurations against configurations that have been tested by
SAPs hardware technology partners. Again, a test plan should be created at first.
Prepare for cutover
The final phase before going live with SAP is often referred to as the cutover phase, which is the process of
transitioning from one system to a new one. The organization needs to plan, prepare and execute the cutover,
by creating a cutover plan that describes all cutover tasks that have to be performed before the actual go-live.
Examples of cutover tasks are:

Review and update all systems-related operations procedures like backup policies and system
monitoring
Assign ownership of SAPs functional processes to individuals
Let SAP AG do a GoingLive check, to get their blessing to go live with the system
Lock down the system, i.e. do not make any more changes to the SAP system

[edit] Go Live
All of the previously described phases all lead towards this final moment: the go-live. Go-live means to turn
on the SAP system for the end-users and to obtain feedback on the solution and to monitor the solution. It is
also the moment where product software adoption comes into play. More information on this topic:

Product Software Adoption: Big Bang Adoption

Product Software Adoption: Parallel Adoption
Product Software Adoption: Phased Adoption

[edit] Critical success factors

In order to successfully implement SAP in an organization, there are several things that are of great
importance:

1) Choose the correct SAP Consultants to have the correct blueprint. An SAP Consultant is a
professional who has the skills to speak to the managers of a company and help them creating the blueprint.
For this the SAP Consultant has the business skills of the business area he/she is working with, and also
masters this area on SAP. For example, if this is SAP FI (accountancy) Consultant, this person is an expert on
accountancy and payments, gained through experience or by the corresponding studies at the University.
Also this person knows SAP FI because has gained by the corresponding training, or the course on the SAP
Partner Academy or similar. Benefits: As this person knows about Accountancy he or she will understand the
needs of the business and will bring it into reality. Screening Methods to Find the Right SAP Consultant
2) SAP R/3 implementation is not an IT project, in fact is an Organization Project impacting all levels of a
company. So it is very important to get the support from all the people that are involved in implementing
SAP, but more important the participation and commitment of all levels, specially managers, of the company.
3) The Blueprint is the keystone used as the lighthouse who must guide the whole project. A blueprint
should never be a merely mapping of IT systems. In fact a blueprint is bringing the strategy of a company
into execution through defining its processes across all business areas. Many projects have failed because the
focus was on having people with SAP knowledge, but with no business skills and so defining something that
works...wrongly. Just remember, processes must change across time, and a manual error automated could be
repeated infinitely.
4) Always consider changing the way things have been done before implementing SAP. "This has always
been done like this and the Consultant should replicate it on SAP" is the start of a big problem. SAP many
times could save you time and money as it allows your organization to automate many processes.
5) Test the SAP hardware and software rigorously by testing your business processes, and to ensure that
the end-users are ready to use SAP before going live, because there are many known projects that failed
because of a lack of support and SAP knowledge.
6) Design and execute a Change Management Program by communicating as early as needed all the
information that end users should have to accept the new technology and designing and executing a training
plan in order to reassure a knowledge base within the organization.

Planning For a Smooth Go-Live: Part 1

Posted on October 27, 2008 Bill Wood
No Comment
BOOKMARK

After youve done all the research, and gone to all the trouble to make your project a success, there are still
four key areas that consistently cause trouble at go-live:

1. Security and Authorizations.

2. Master Data.
3. Process changes, process gaps (missed processes and exceptions).
4. Custom Development.
While each of these areas consistently cause trouble at go-live, resolving the first item, Security and
Authorizations, and the third item, Process issues, should be a standard part of every project no matter who
does it. There is just no real reason for these two issues to be a problem on any project.
The Master Data and Custom Development are a bit more difficult to resolve. Even companies that believe
they have a good handle on master data often discover that it is not as pristine as they might believe.
Custom development can also be another source of headaches. Often it is some gee wiz gotta have it
improvement, automation, or rearranging a printed form 20 times to get it right where development can
come back to bite you if youre not careful. This is especially true with inexperienced developers who read
some ABAP programming book, or take some back room fly-by-night certification course and then get a
fake resume presented.
1. Security and Authorizations
To reduce go-live headaches, security and user authorizations must be carefully tested. By testing I am
*not* referring to consultant testing, core team testing, or even extended user (power user) testing, I mean
actual end users logging in under their own user IDs and verifying they have what they need to get their job
done.
The most effective method Ive seen over the years to do this is to incorporate authorization testing into the
end-user training. Usually end-user training has dummy training logon IDs created that are used during
classroom training. However, the best solution I have seen is to have users also have their own User IDs
available at the time of training, have the users log in under their own IDs, and then verify that they have
access to all of the transactions they will need at go-live.
On one client in particular, the users had a form that matched their training classes and they had to initial a
sheet next to each transaction they tested, sign the sheet, and then turn it in at the end of the course. If there
were problems they were noted on the form and sent in to security to be resolved. The users then make use
of their training IDs for the classroom training. While this is a little disruptive to the classroom training
process, it is the most effective method I have ever seen. The idea is that the end user must somehow log in
and test their User ID long before you go live. However you decide to do that is up to you, but doing so will
reduce many headaches after go-live when everyone is focused on trying to resolve fires, gaps, process
changes, and user learning of a new system.
Suggestions and ideas for handling security:
1)
Integrate the security and training efforts. Those identified for training should also have the tasks and
transactions they will be trained on identified. This is a good starting point for security access as well.
2)
Be sure to test security with every end user before you actually go-live. This will help to reduce the
production headaches with security and authorizations; unfortunately it will not eliminate them.
3) Take the time and effort to carefully structure your security and authorizations. Done properly
authorizations should not be a maintenance nightmare.

Other than the obvious reasons, security maintenance after go-live can not be overemphasized; after the
consultants leave this is one of the routine, regular, and ongoing maintenance areas and if there is not enough
attention paid to it from a long term maintenance perspective you may have to live with a nightmare.
Aside from the normal security concerns an improperly designed security strategy will cause you ongoing
maintenance nightmares because each person will eventually end up with completely unique one off
security objects. That translates into significant maintenance overhead that is not necessary with a properly
designed security strategy.

Planning For a Smooth Go-Live: Part 2

Posted on October 25, 2008 Bill Wood
No Comment
BOOKMARK

2. Master Data.
Ideally your master data processing should begin early in the process. Identification of legacy data sources,
and even raw legacy data extracts should begin during the Blueprint phase. Experienced implementation
consultants should be able to ensure that the key data requirements or data settings are also captured. It
wont be perfect, but initial scope should have already been determined and experienced developers should
be able to point you to the type of raw data records they will need to begin working with.
By the end of Blueprint master data requirements (extracts and layouts) wont be complete but should be
well underway. Even though you may have to add a little more time to your initial project plan, it is optimal
to plan for Integration Testing to be done with converted data, even if the data is not perfect and not
completely ready for prime time. By doing integration testing with converted data you will discover data
gaps, process gaps, and other problems that can be addressed then rather than in a live production system.
Live testing of converted data in a production system is the worst time to find out if the system will work.
Data Transformation Methods
There are four primary methods for data transformation into SAP:
1)
Do the data transformations outside of SAP and legacy systems then feed pre-formatted data files into
the system using standard input programs;
2)
Extract raw legacy data and do all of the transformations in custom programs or conversion tools inside
of SAP;

3) A hybrid that does some conversion outside of SAP and legacy and some at the time of conversion
inside SAP;
4)

Or do transformations in legacy extract programs.

I personally prefer methods 1) or 3), if there is one method that I dislike the most it is probably 4). There are
mountains of data transformation tools available. USE THEM! I personally prefer MS Access, but that is
for one time data conversion and one time throwaway transformation rules. Over the years I have seen
that the more cleanup and transformation on the data that is performed outside of SAP and legacy, in an
automated and repeatable process, the shorter the development time. Using that approach my experience is
that is easier / less risky it is to resolve and mitigate data conversion problems. The other side benefit of that
approach is that it begins to press legacy employees to move away from the legacy app and begin learning
more about the new system.
My personal method is to take unmodified, raw legacy file extracts, use MS Access to do as much data
conversion, data cleanup, and data transformation as possible, and then use SAP Legacy System Migration
Workbench (LSMW) tools to load the data. Over the years Ive learned that I do NOT want any legacy data
changes made at extract time. It causes too many problems, and frequently it then leads to managing
multiple, sometimes conflicting, transformation rules. Often times a single change in an extract data set,
before an intermediate or final transformation into SAP can completely compromise a data load. And sadly,
those extract changes rarely get reported so they are discovered by trial and error at load time.
A good MS Access power user can do huge amounts of data transformation and file layouts to match SAP
input requirements. Done correctly, this then becomes an easily and quickly repeatable process. MS Access
is a quite capable data transformation tool, on a decent workstation it can manipulate hundreds of thousands,
or even a couple million records relatively quickly for the lightweight desktop tool it is. From there,
SAPs LSMW tool is quite powerful and has the ability to directly code individual field level transformation
rules right into the program for any final detailed requirements.
As a few final notes on data conversion I will offer these suggestions:
1) Never leave off doing a mock conversion of data and capturing the necessary steps and times to do the
real data conversion into your production client.
2) If you are doing a rollout of a new facility into an existing SAP instance, make sure you do some type of
regression testing before you go into production.
3) Plan for and be ready to support the master data maintenance efforts after go-live.
4) Test and check every interface and batch job, both before the go-live and then within 24 hours of the first
time they are run at go-live.
5) Make sure to correct and clean up any master data issues immediately at go-live. Each time that master
data is referenced by a transaction without being corrected compounds the cleanup effort and the problem
needing to be corrected.

Planning For a Smooth Go-Live: Part 3

Posted on October 24, 2008 Bill Wood
No Comment
BOOKMARK

3.

Process issues

Let me start with a caveat to this section. No matter how good, thorough, experienced, or conscientious a
consultant or a core team member is, there will always end up being a few process gaps, and an occasional
completely missing process discovered at go-live. Now that the caveat is out of the way, there are many
reasons for the process problems: inexperienced consultants, company employees who miss some of the
process exceptions, inadequate training, insufficient integration testing, lack of user acceptance testing, and
other reasons.
The bulk of the items causing process problems generally fit into three core areas, 1) design or blueprinting,
2) change management, and 3) testing.
Design and Blueprinting
Your business probably developed numerous processes and exceptions over many, many years. Some of
those processes were also developed as the need arose, and in an ad hoc manner and may have many inherent
inefficiencies. SAP projects are generally tasked with replacing all of those years of collective knowledge
and processes, as well as any broken processes in six months to a year, and on very large projects in maybe
a couple years. That is no small task and to be successful it truly takes an experienced consultant. As Ive
previously written about, this is one of those areas that all of the fakes end up costing your SAP project and
your company big money. And I mean big money over and above what you pay them.
A good blueprint should translate your scope into all of the key business processes that your company does,
and then the key process components needed to support those processes. I generally prefer a blueprint that
has inputs (or some type of process trigger), the process itself, and then the outputs. It should also contain
the key master data requirements, any necessary FRICE (Forms, Reports, Interfaces, Conversions, and
Enhancements) development objects, and the key business areas affected. If there is sufficient time in the
Blueprint phase, the Blueprint itself should also begin to capture some of the key change management issues.
Poor blueprints (missing processes, too generic, too high level, etc.) cause serious project delays and flared
tensions by constantly dragging your project back into Design mode when you should be in full project
execution. It takes up the time and effort of other integrated teams, and generally causes a drag on the
overall project. Obviously this burns up budgets too. Worse still, a poorly designed Blueprint is often
blamed on the company, the department, or the key resource on the project who is responsible for that area.
Unfortunately those smokescreens are often used by consultants who are not that skilled at extracting the
necessary information needed for a good blueprint. Its always easy to blame the client through the
backdoor by putting the responsibility on a core team member, or some other portion of the company / client
team.
If there is a genuine issue with a team member, an experienced consultant should raise this issue during the

process when it is encountered. Frankly, if it suddenly comes up AFTER the blueprint is due, it should be
seen as nothing but an excuse by the consultant.
Testing
Another area to begin addressing processes is during testing. Any integrated application like SAP should
include at least 4 primary types of testing. No matter what name is used, they are generally individual
transaction tests (sometimes called unit tests), transaction strings or processes within the same module like
Sales and Distribution (module tests) and then full-blown cross module tests that test entire process chains
from start to finish (true integration tests), and then finally tests that involve the wider user community
often called user acceptance tests or day in the life scripts, etc.
During testing, while it is important to follow the scripts to be sure that all of the proper boxes are checked
off, it is equally important to test more. Integration tests and user acceptance tests serve as the last
opportunity to find and address process gaps. Sadly some consultants (and some consulting firms) see this as
an opportunity to absolve themselves of responsibility for potential problems or shortcomings. As a result,
they will often strictly enforce that the script must be followed to the letter and no deviation is allowed and
no exception processing is allowed. There is a legitimate need to control the process to ensure that the work
is done and that the known processes work sufficiently as designed, however there should also be some
mechanism to address gaps or exceptions. One simple method to accommodate this is to create a space on
the signoff sheet that directly solicits comments about any process gaps and any exception processing that
might be needed. Final signoff of the testing should not be signed off until this commentary is converted into
additional testing scripts or some manual process defined to address the processes.
For final integration testing you may wish to pick random documents from your current business operations
to run those through the system with the converted data. This will give you the best test to ensure things are
working correctly. For example, you may wish to choose 10 or more each of the sales orders, purchase
orders, production orders, reports, etc. The key is to use something that is meaningful and can be verified
back against your current system.
Change Management
Unless you completely re-design and re-write SAP to do all of your processes exactly the way they were
done before, there will be change management issues to deal with. And unless you also re-write the user
interface, there will still be training and user acceptance to accommodate. If youre going to re-write
everything, why bother with a packaged system application at all? On the other hand, if you are putting in a
package application such as SAP, Oracle Apps, or others, there are change management issues to deal with.
Change management generally encompasses a few key areas: Training, communication, organizational
change, process / job changes, and post production support. Some change management is necessary on every
project and if your company handles change reasonably well it may not be a struggle. However, if your
company has many employees who have done the same job for a long time, without much change taking
place within the organization it will take a tremendous amount of hand holding to get them through even
small adjustments.
You will need to assess your own organization and its ability to absorb change for whether change
management resources should be budgeted. From a project perspective however, one of the key things to be
wary of are consultants who want to add new functionality without understanding the impact on the
organization.
Business Change Management analysis case in point: I was at a client where SAPs Handling Unit
Management functionality was the best fit I had ever seen. They had high dollar custom made steel
transportation racks that needed to be inventoried and returned, the packing was consistent and uniform, their

production volume was not intense as a sheer number, and they already had wireless bar codes with some
warehouse automation. From a functionality standpoint it was almost a no brainer and a great ROI on the
automated tracking, inventory, and return of the units. However, a more careful look at the organization
showed a very different picture. The staff responsible for maintaining the data and processing the
transactions had not been reliable with data maintenance or with processing in the past. Also, because of the
organization there was virtually no chance that would change in the future.
A less experienced consultant with limited project or change management experience would have seen this as
a great opportunity to throw some gee whiz wow new functionality at a company. They keep billing for
the new work (a scope change), they would be needed almost indefinitely for production support, and
theyve got a great candidate to blame for why you have to keep paying them. Sadly Ive seen this scenario
played out over and over again. On a recent project I saw this with the implementation of SAPs Customer
Service and Solution Database functionality. The company had an ugly but mature and working solution,
they were downsizing the customer service area, the SD scope for the project was already pretty significant,
sales were beginning to slow, portions of the business were being spun off, and employee morale was already
low. The consultant convinced them to replace their solution database and customer service functions
from a CRM application that they did not even retire. So there werent even any software license savings.
The consultant got to stay on, support an unnecessary process (the legacy app was not going away and
worked fine), and was needed for post production support.
The process related issues will quickly separate experience from inexperience. There are lots of good
consultants out there, and then there are lots of less than satisfactory fakes in the market as well.
Unfortunately it is it the good consultants who are often penalized for smooth and successful go-lives by
early roll offs. Meanwhile fakes and less skilled consultants are rewarded by extensions to support poorly
designed processes and inadequately prepared user communities at go-live. The old adage rings true here
that you get what you pay for as long as you have a way to separate the genuine articles from the fakes. In
the end, there are many hidden ways you end up paying as much or more for inexperienced consultants, not
the least of which are the many hidden ways their SAP implementation approach impacts your business. A
truly seasoned consultant may cost a little more up front, but at go-live with the quality of delivery and the
overall satisfaction of the solution it can pay dividends for many years.
In essence, the need for careful process understanding can not be underestimated. The amount of change
your company can absorb, the impact of processes being brought into a package application like SAP, and
the cost to your implementation budget should all be considerations.

Planning For a Smooth Go-Live: Part 4

Posted on October 12, 2008 Bill Wood
No Comment
BOOKMARK

4.

Custom Development

Every project ultimately has some development work needed. And by development work I mean custom
coded programs to address FRICE or RICEF objects (Forms, Reports, Interfaces, Conversions, and
Enhancements). Getting the right developers to do the work can make a huge difference in your project
being delivered on time and on budget. Often times inexperienced developers bring significant hidden costs
to a project that can cause slipped timelines, blown budgets, and go-live production nightmares.
Some suggestions to ensure a smooth go-live are:
1)

The Blueprint should deliver at least a first pass list of needed development objects.

2)
Prioritize development items by when they will be needed in the project, for example, reports can
sometimes wait until right at the end of the project, and a few can even be done after the system is live.
However, interfaces and conversions will be needed much sooner.
3) Add a second level of priority to the development items but what is truly critical and what could
potentially have some kind of temporary manual workaround or some other method to mitigate it.
4)
Be sure to break the development work up into deliverables that can be monitored and tracked, for
example you might require a functional specification (verbiage of what must be developed), a separate
technical specification (the detailed inputs, process, and outputs of the development including table, field,
and pseudo-code requirements), first pass coding, a code review by a trusted senior coder, testing, etc.
5)
Make sure your implementation partner provides you with a list, and samples, of the deliverables and
the tracking tools they use to monitor development progress. These should be requested during the initial
proposal process.
In the end, many projects have taught me that if you get the right folks doing the job, you can have a very
successful implementation. The key is to make the transition to SAP a relatively smooth and relatively painfree process.
Interfaces and Batch Jobs
If your project requires interfaces or batch processing jobs it is absolutely critical to test them thoroughly
during integration testing. And then at go-live it is important to verify their operation after the first time they
are run.
After the first run of any interface in the live production system the data records should be checked on both
sides of the interface. The input side and after the data is brought into SAP. The first few times the interface
or batch jobs run, EVERY error record must be cleared immediately. Otherwise you can end up in a
cascading situation where similar errors are repeated each time the interface or batch job runs. Each of those
individual errors must be corrected even if they are duplicates that occur from the same master data (like bad
customer master, vendor master, material master, or other data). Immediately working to resolve this will
significantly reduce ongoing headaches and processing problems.
Month-end
Month-end close processes must be carefully tested and scripted during your integration testing. From that
testing a checklist and all of the necessary steps need to be produced. And then coming up to the first
month-end close it will be very important to resolve as many master data and posting errors as possible
throughout the month. If you wait until your first month-end youve waited too long and will get bitten
pretty badly by processing issues.

Be proactive in testing and planning for all of your go-live processes and issues and you will have a much
smoother go-live. Neglect them and you will pay the price.
An SAP go-live can be both successful and relatively smooth with the right preparation. However no
amount of planning, testing, or preparation can address every issue so there will always be a few small things
that crop up. You can minimize the impact with good planning and testing.
Costs and Consequences of Inexperienced Developers
Inexperienced developers bring another of those hidden costs to a project. The hidden cost of them
consuming a highly paid implementation consultants time to constantly test and pseudo code the
developers work. What customers never see with these fakes are the hidden costs their inexperience adds.
Their lower hourly rate needs to be added to the hourly rate of the implementation consultants time they
waste from having to be baby sat, in the end their inexperience costs you far more than their lower rate
may initially lead you to believe. Along with that you have to add the drag their inexperience brings to a
projects pace adding additional hidden costs.
If developers do not have enough experience to start identifying key legacy data based on the project scope,
get new developers. Also, keep a close eye on developers who claim they have experience but need step
by step detailed specs for every bit of coding they have to do, or who have a difficult time testing their own
data conversions and programs. A good developer should have enough exposure and experiences with the
key transactions to be able to do most of their own testing, and even make suggestions on how master data
might need to be changed or set up in the new environment. Watch for the ones that are constantly on the
phone during work hours speaking to someone else