Their name, which is short for "Systems,
Applications and Products in Data Processing, may not be catchy--but if
you work in the field of enterprise resource planning (ERP) software,
you know who SAP is. SAP is the world leader in ERP software,
holding a 33% market share according to a recent survey.

What
makes SAP different from other ERP systems is its wide bandwidth of
functionality. While PeopleSoft might have the best
human-resources package, for example, or Manugistics the best
forecasting package, many people feel that SAP does the best job of
offering the broadest range of excellent products and services, across
more industries, than any other company in its field.

This same versatility, though, makes giving advice
about working with SAP a challenge. With so many options,
where do you begin? Whose perspective do you use?
What area needs the most concentration? In
this article, I will describe some aspects of SAP from an independent
consultant’s perspective. I'll attempt to provide
some insights to important elements for success on a project--and
propose ideas for enhancing your experience and improving the results
of your work.

The essence of any SAP project is configuring the
system to facilitate the transactions needed to run the
business. Your understanding of the functional and
technical aspects of SAP, therefore, has to be connected with your
users’ knowledge of the company’s business
processes: the mountain range of details about how the system will
support customers, vendors, products, services, partners, employees,
materials, planning, reporting, and more.This, obviously, requires a massive and time-consuming
effort.You'll
need to perform extensive testing and quality checks before "going
live" to ensure that the system is designed properly, convert master
and dynamic document data, turn on interfaces, and more.

But what principles will help you get tothe point where the system
is ready to run the daily transactions needed to support the business?Here are some important
questions to ask that will help you apply your knowledge successfully
when working on an SAP project (in fact, many apply to any consulting
situation):

·How
do I fit in to the project?
·What are the business processes? ·Who are the business owners? ·What is the project methodology and
documentation?
·What is the testing strategy? ·How is communication managed? ·How is training and change management
delivered?
·How can I maximize your effort?

How
Do I Fit In?

The
size and complexity of SAP itself is often mirrored by the number of
people involved in the project.SAP
projects are usually run by large consulting companies, in conjunction
with representatives from the client company.Add up the people involved with initial implementations,
upgrades to new releases, adding special functionality or new modules,
interfacing with vendor or customer systems, interfacing with other
divisions within the same company, and so on, and you often end up with
an unwieldy project team.

This
situation poses two tasks, one of which is fitting in personally with
the team environment.You'll
need to get a sense of not only where you fit within the team, but
where your team fits within the total project (since your team's work
will almost always affect that of other teams, and vice versa).As a newcomer thrust into
the mix, your immediate challenge will be getting up to speed as
quickly as possible, proving yourself as a valuable team member even as
you're still deciphering the state of affairs.Your success will depend on how well you demonstrate not
only your skills to accomplish tasks, but also your understanding of
the politics of the client and other consulting companies on the
project.When
you're struggling to get on someone’s calendar for a meeting,
balance your desire to keep things moving forward with the recognition
that most project members are strapped for time--and the awareness that
when you’re in someone else's house, you need to go by their
rules.

The
second task is figuring out how to make your project fit with the
client company's way of doing things.Since each company is unique, you can expect to design
plenty of non-standard business processes, from interfaces to reports,
labels and outputs, web applications and EDI, and master data
conversions.These
special requirements are usually managed by creating functional and
technical specifications that (1) describe the work needed to
accomplish the need, (2) design the solution, (3) program the solution,
(4) test it, and (5) implement it.

What
Are the
Business Processes and Project Methodology?

Most
projects use the Accelerated SAP (ASAP) implementation methodology--or
at least portions of it--for gathering requirements, defining the scope
of what functionality will be used, defining the business processes to
be used, translating these into the needed transactions and
functionality, developing test scripts and training documents, and
documenting decisions made along the way.This is an effective way of leveraging SAP’s
years of knowledge and experience from past implementations.With many templates
designed to save time and effort in building the system, ASAP is a
valuable tool to communicate to all team members, and it is especially
important to new people on the project.But it's important to remember that although ASAP is used
in conjunction with project management, it is not a substitute
for project management.

ASAP methodology may suggest, for example, that
team members who are familiar with the company’s business
processes set up the system by defining key values in configuration
tables, then assigning them to the respective business processes in
other tables (e.g., a special order type can be defined for full
truck-load orders, then assigned to a specific sales organization that
needs to use this type of order).But skillful project management is necessary to ensure
that they achieve the goal ofconfiguring
the system so the users can quickly execute their daily transactions
with a minimum amount of manual entry, and a maximum amount of
automatic processing.

Who
Are the Real Business Owners?

Another
key element of project management is defining the real business
requirement within each specification if custom programming is required.Bad specifications result
in work that has to be redone, lost time, and unhappy customers.Many times, however,
specifications are faulty because someone only defined part of the
requirement, or did not define it clearly.

Be
aware of the possibility that the customer may have a vested interest
in the design of some functionality, and this may affect your
requirements.For
example, the customer may be using your outputs or reports to help with
some aspect of their business process.On one project I worked on, a major customer compared and
reconciled invoices with packing slips before paying each invoice; as a
result, we had to re-design and add more data to the invoice to satisfy
this business need.When
you are working with processes that affect the end customer,
it’s a good idea to get their feedback on how they are using
reports and outputs and other data that you are giving them--you'd much
rather make changes to accommodate these uses during development than
do it afterward.

Here
are some ideas to avoid thenightmare
of "going live," only to find out that the specifications writer
didn’t really understand the full business process and
requirement:

·Have
key business owners review and approve the specification before the
developers start working on it.In
addition, try to get approval from the actual users who perform the
legacy transactions (who may not be the formal
business owners).

·Make
the key business owners test the specification, after it is complete,
to verify that it works as they want it to.Someone from within the client company should be
responsible for verifying that the functionality meets the business
requirement.

·Ask
questions, based on your experience, to stimulate project team members
to do a better job gathering requirements and translating them in the
system.If you feel
that you don’t have a good requirements definition, keep
asking questions until you’re satisfied, or until you are
told to stop asking.

Testing

ASAP
provides many templates to facilitate the testing process.Someone close to the
business process, though, should identify the most common scenarios or
combinations to be tested.Expand
your testing to include feedback from your key customers, so you can be
sure that nothing is missed.

Similarly,
you should test for the real environment where the programs and
functionality will be used.In
a typical remote testing environment, you might only have one label
printer, but the factory floor actually has one printer per pack
station, so you should test the process to ensure that the label can
print at each respective printer.These details are sometimes overlooked; don’t
wait until the last minute to test for the real scenario.Use actual legacy business
documents to verify test script results.

When
working on problematic outputs, develop a test matrix.For example, the invoice is one of those documents that
seems to have perennial changes to it, even after going live.In SAP, however, there are
several transactions that allow you to reprint documents easily.If you have a matrix of
baseline invoice numbers that are correct, along with the actual
invoices, you can reprint these documents after each code change and
review them to ensure that the change did not break any functionality.

Some
other important testing considerations are as follows:

Close the loop on it.Test for the "yes" path as
well as the "no" path.

Be creative in
trying to"break the system."Do the transactions the way they should be done--then do
them in wrong and incomplete ways, like a new user might do.

Where interfaces are
involved, make sure all error messages can be displayed (and make
sense) to the actual user, especially when testing web applications.

Many times, testing will
not reveal an error situation until a certain combination of master
data is used (for example, customer number, material number, and
quantity).It’s
impossible to test for every combination, so use the 80/20 rule and try
to find the tests that will cover the most common user situations.

Communications

Given
the number of people involved in developing such a highly integrated
system, weekly or periodic team meetings are essential to a successful
SAP project, especially after going live.A quick discussion of what everyone is working on, what
problems they are having, what new things they have learned or noticed,
and so on can be invaluable in identifying when team members' efforts
or discoveries impact other areas.

Similarly,
sending e-mails to the team before moving new functionality into
production can prevent members from stepping on each other’s
work, and help them trace the cause more quickly if something does
break in production.

Talking
to key users can help you get to the root cause of problems.On one project, we had a
sporadic problem with availability checking for certain materials.After checking with the
planners, we found that they were running Material Requirements
Planning (MRP) at random times during the day, rather than just at
night as we had assumed.Once
we knew their procedure, we were able to make an adjustment to fix the
allocation problem.

Besides
the current release level, it is very important to keep track of what
level of"hot
pack" (bug fix) has been installed.During testing, it's easy to forget that on most projects,
the client fails to keep up with applying the hot packs, resulting in
unnecessary problems.In
every project I’ve been on, we encountered an apparently
unexplainable situation that was finally solved by applying an existing
fix.

SAP
has a very nice online support system for identifying known problems
and solutions.It
also includes many notes that explain complex functionality for
consultants, and you can submit questions to them as well.

Training and Change Management

Knowledge
transfer and change management are a big part of our job as consultants.Clients do not want us to
stay forever; instead, they want us to share our knowledge with the
users, so those users can run their processes effectively.This can be a critical
factor for smooth and successful execution after we leave, and that in
turn will influence the clients' decision to call us back for future
work.

Training
is an essential part of our knowledge-transfer responsibilities.Untrained users will do
transactions incorrectly, in an incomplete way, or not at all--and this
can prevent downstream transactions from taking place.For example, a missing warehouse management transaction
could prevent a shipment transaction from taking place.Moreover, users need to know not just how to do the
transactions, but how to identify and react to omissions and exceptions.SAP is filled with many
excellent tools to manage exceptions, but these tools are useless
unless users know when and how to use them.

Change
management is a key facet related to training.When you make a change or add a new feature, is this being
communicated to everyone who needs to know?Has the training documentation been updated?You may not be directly
responsible for training (since many companies have their own
departments for this purpose), but you should know if any changes are
significant to the users, so that you can communicate these changes to
the appropriate people.

It
is often difficult to get users to take ownership of their own system,
but we have a responsibility to encourage them to do so.As consultants, it is
sometimes also our duty to train other, less experienced consultants.These tasks may feel like
burdens sometimes, but remember that very few people (perhaps including
yourself) know it all.Not
only that, but the success of the project requires knowledge
transfer--and that success should always be our ultimate goal.

Conclusion

There
are obviously many factors and topics to consider when working on a SAP
project, and what I have provided here are just a few observations from
my experience.We
have all heard about problem projects, and listened to dozens of
reasons to explain the bad results.My experience with SAP has been that all of the problems
were eventually fixed--and the underlying problem was not the software,
but rather the incorrect use of it.

We
may not always be empowered to make the key decisions that determine
the outcome of our project, but we can certainly communicate our ideas
to those who can influence change.Some of the key factors that need to be considered to
minimize project problems are the following:

A strong commitment
from management, who allow adequate time to make a good project plan
and supply enough full-time skilled people to the project

Good project management
and team building, including excellent communications and support
systems

Empowering
people to make decisions--and, conversely, getting users to commit to
owning and taking responsibility for their processes

Proper use of ASAP or
business process methodology, including (1) keeping the project
oriented toward the business processes that are in scope, (2) getting
good requirements definitions, (3) thorough testing and quality checks
by the business owners and users, and (4) effective training and
training documentation for all processes

Fostering an environment
of learning and knowledge transfer, accomplishing goals, and having fun
along the way.If
that is not happening, it’s time to look for the next project.

You
can review SAP products and services by visiting their website, which
contains several good white papers, along with a great deal of other
content worth reading.Here
is the URL for their site, along with a few other sites that you can
use to look up information and to seek assistance with your questions:

Tony
is an independent consultant, and president of Beyer Business Solutions.He is APICS and
SAP certified, and has many years of experience in industry, software
development, and consulting.Beyer
Business Solutions works in conjunction with other consultants to
assist customers with SAP projects and other projects in the
supply-chain area.