SAP Implementation & Blueprints

SAP Implementation Process

What is ASAP Methodology

ASAP: Accelerated Systems Application and Products in Data Processing
All implementation projects have the following phases:
Scoping - What is to be implemented i.e. which sub modules are to be implemented some clients
may not require credit management for example. Look at the project scope document carefully it
will tell you what SAP sub-modules in SAP you should be prepared for. Usually the sales people
along with project manager do it.
As is - Here you understand the existing business processes of the client . Your BPO collect all
the ISO-documentation (if client is ISO certified), reports and forms at this stage and you
analyses how and when the reports/forms are generated, where the data is coming from. You
also do a Level -2 training for your BPO so he is made aware of all the required transactions in
SAP.
Once this is over BPO can start learning with the consultants help more about SAP. This is
crucial because if you miss out any transactions the BPO may forget about some of his Business
processes which may come up later. It is a good practice to ask the BPO to make flow charts to
explain business processes.

To-Be - Parallely you map these processes to SAP. Processes that you are not sure of as to
whether they are present in SAP or not you try to do a configuration of those processes, and
along with the BPO(Business process owner he is the clients employee who knows about the
clients business processes probably a middle management guy, ther can more than one), BPO
involvement is required as he may be able to tell you his requirements better. Once you do the
business modeling you
will also be made aware of the gaps between as-is and to-be , here decisons have to be made as
to whether a ABAP development/system modification is required or not and so on. Involve the
BPO as much as possible and document everything it is good practice do not be lazy about it.

Business blueprint: Here the as-is and to-be and gap analysis is explained. This is the document
that you will be using to do your configuration in the realization phase.
Realization phase: Here you do the configuration in the development server (there are three
clients -development,quality, production). You also decide on the master data format, so that
BPO can go collect the master data. You also gove ABAP specifications for forms, reports etc,
system modifications etc. Unit testing: Your BPOs and a few key users sit down and test your
configuration in your module only. It is good to test the BDCs that you need for uploading data at
this stage so you have more realistic data and your BDCs are tested.
Integration testing:

Once all modules unit testing is over then the configuration is trasported to the Quality server,
where testing for all the modules is done by BPOs and end user, this is to check if any problems
are there in integration between various modules. Once all is okay from the QA server config is
transported to the production server.

Go live preparation

Data uploading: The collected master data is checked and the uploaded into production
server(sever and client I have used interchangeably). Now you are ready for go live i.e. users can
now use the production server.

ASAP methodoligy means nothing but standard process for implementation of SAP, It consists of
5 phases.
1. Project preperation - consists of identifying team members and developing strategy as how to
go.
2. Business Blue print - consists of identifying the client current process, reqeirement and how
SAP provides solution.
Consists of detailed documentaion
3. Realization -The purpose of this phase is to implement all the business and process
requirements based on the
Business Blueprint.
4. Final Preparation - The purpose of this phase is to complete testing, end-user training,
5. Go Live and Support All the functinal consultatns need good rapo with Abapers. right from
uploading of legacy data, devoloping customised reports, BDC's, Forms etc, here functinal
consultatns need to give guidence as to get the requried data for reports and all.. like the table
name, fields etc

What is baseline configuration in sap?

Base line and Final config is the third phase in ASAP methadology. The purpose of this phase is
to implement all the business & process requirements based on business blue print. You
customize the system step by step in 2 work packages: Base Line Configuration & Final
Configuration.
- Base Line Configuration: this phase comprises the priority requirements of the enterprise,
ensuring that they can be implemented quickly. This phase can be completed without
programming or enhancements to SAP systems.
- Final Configuration: in this phase you confirm that all your requirements are met in the R/3
system. Final configuration is a transportation process that expands that base line solution

Documentation which is prepared before and in a project:

1) Templates
3) Fit Gap or Gap Analysis
4) Business Process Design
5) Business Process Model
6) Business Change & Impact
7) Configuration Design, which is just 5 % of Total SAP- have different names -
8) Future Impact & Change Assessment
9) Functional Design (Module Wise)
10) Risk Assessment
11) Process Metrics and Many More-- Which has impact on Business and its work flow

Note * This documents are prepared in Vanilla SAP Standards -- Things differ from one
implementation to another, and it always depends on the type of business which is opting for
SAP.
What Are SAP End User Manual
It is the same for every other modules although here I reference it mainly for SAP HR.
1) You should understand which targeted group for the end-user training is for. Do they have any
computer background or not.
2) In what way they are going to make use of the manuals supplied to them during the course of
training.

How to prepare manuals:

In the client side, End Users are not permanent. If they get any better job outside they will resign
and go out. Even if you train them well, again the end-user team disappears after some time.
That is why implementing company( Client ) expects SAP Consultants to prepare documents
which are self explanatory (even to a layman in SAP) and study themselves and use the sap easy
access very comfortably.
Hence we should prepare a document which explains the following things comfortably:
A) All the buttons and Screens we have in sap and its importance for an end-user.
B) All the transaction codes used by end user.
C) The STEP by STEP usage methodology with screen shots and explanatory foot notes for each
Transaction code.
D) Prepare a book a table and columns which should have the following information:
- Sl.NO.
- Transaction Code
- Navigation path
- Use of the Code
- Expected Result
- Achieved Result
- Remarks/Any Comment
E) Highlight the common troubles during the usage of SAP by an end- user and give the solutions
(ready to use)
These problems you can come across while giving the in house training for the end-users. You
just place them at one place and publish it for their usage in future for any of their new join as an
end-user.
F) Every consultant is aware that the entire Organsiational Management is with end user only.
Means consultant should train the end user in entire OM.
G) We should inform the importance of info types and usage for our purposes at expert mode,
PA30, PA40 etc.,
H) Each field in the international infotypes should be explained very clearly and ensure that they
are comfortable with the fields of infotypes which have been configured for their company.

For example : info type 0001 Org Assignment insists about the three structures of the HR. We
should explain each sub field like Emp Group, Emp Sub Group, Personnel Area and Sub Area
and its importance and relevance to their company so as to understand while processing them
from the end- user point of view .
When an employee is hired into the company , now the end-user in a position to understand
which employee group and subgroup, Personnel Area And Sub Area etc., should allotted..
Like this whatever comes across in SAP Easy Access should be insisted through the training of
end users.
I) Demo, exercises and solutions should be provided in the manuals.
J) Glossary of terms and expansion of Acronyms, Abbreviations should be given. Like this each
consultant should focus on end user training and prepare the documents.
As is document:
How to start doing the project in 'AS IS' ?
Are you working as a technical person or functional person?
This work is of a functional consultant. It involves understanding the complete functionality of the
system.
It involves detailed understanding of how the HR department is functioning because based on
that only you would provide a solution to them. Like suppose you are implementing SAP HR
module for them then in the AS-IS and TO-BE phase, you need to prepare all the documents of
the process flow (you can prepare them in word). Like suppose you are implementing for PA then
you need to identify how many personnel areas you need to make, how many subareas you will
make, employee groups, subgroups, based on what you are classifying them? This all will come
in the master data document which has to be approved from the client whoever he is .
Like if the current system is on mainframe or for some specific applications like for recruitment the
system is on mainframes and the client wants to keep that system as well then interfaces need to
be identified which will be there because you will have to upload the data to sap system using
bdc.
Like this for every process there will be a document. Even for actions like:
- Hiring
- Newly Hire
- Termination
-Transfer
- Layoff etc
You will have to see what all actions your client wants, like if there is an action transfer which is
run for employee what all will be the reasons you will be configuring for that action. This will be
told by the client which can come out after a series of meetings and after discussions you will
have to come out with the document that these will be action types. These will be the action
reasons, these will be the action codes for that. This will be in the TO BE process document.
After this phase is over complete configuration can be done.
Actually AS-IS process in summary involves a :
1) Series of meeting with the client.
2) Gathering complete information about the existing system.
3) Preparation of the blue print documents describing the complete AS-IS process ,i mean the
existing system.
4) Flow charts should be included in the as-is blue print process flow document describing the
complete process.
5) After this is finished u have to give the TO-BE process structure that will be implemented in
SAP.
6) After that there will be some things which cannot be implemented in SAP so the gaps are to be
identified.
7) These gaps are to be documented in white paper for the client.
It is a lengthy process but not so difficult only the thing is that the functionality is to be understood
properly.

SAP BLUEPRINTING
Defining the Business Processes
After you have defined your organizational structure for R/3, the definition of the business process
for your Business Blueprint is the next step. You now map the enterprise requirements onto R/3
business processes, in order to create the conceptual design for your R/3 implementation. For
this, the following activities need to be carried out:
• Conducting business process workshops
• Completing the Business Blueprint, reviewing it and obtaining management signoff
• Setting up an end user training schedule
Besides determining the R/3 functionality to be implemented, the following types of requirements
should be identified in the business process workshops:
• Reporting requirements
• Interface requirements
• Conversion requirements
• Enhancement requirements
• Authorization requirements
Since all the results gathered during the workshops will subsequently create the Business
Blueprint, the importance of this step cannot be underestimated. The main tool used to define the
business processes is the AcceleratedSAP Question & Answer Database in conjunction with the
R/3 Reference Model. In the process, information is gathered using the following tools:
• Business Process Questions (via R/3 Reference Model)
• Customer Input (CI) Template
• Business Process Master List
• Knowledge Corner
A functional spec should theoretically mean that the ABAPer should be able to take the design
document you have prepared, go and sit in a dark corner of the office and build the whole
report..... this rarely if ever happens, but I think that the theory.

When you write a functional spec, you are meant to be turning the clients requirements into a
design document that a techno can then build from.

Some of the things you may want to think about are:

Report logic - What information is the report trying to get, what logical links are required to link the
data together - like master data and payroll data, and org mgt data, and how should this be
linked, an imp

how should this be linked, an important bit to remember here is the time selection, do you want all
the data in the system, or only the data relevant on the day, or over a month etc.

Selection screen - What fields are required as selection options

Authorizations - Should the report check the 'runners' authorizations and tailor the output
accordingly

Output - What fields are required to be output, in what order, in what file type, for example this
could be a text file, or just out to the screen of the runner.

Error handling - What should the report do when it encounters a problem eg what scenarios
would constitute errors - what should happen etc.

Test mode - does the report require running in test mode prior to a file being produced?

What are the roles & responsibilities as a sap hr functional consultant

As a Functional Consultant, one needs to first understand the business process of the client and
then map it in SAP to accommodate those business processes.

In the Business Blueprint stage, you need to prepare AS-IS (which is a detailed list of the current
business practices of the client) and then , you need to prepare a QADB (Questions and Answer
Data Base) questionnaire and send it to the client.

Then, based on client's answers, you need to prepare TO-BE list ( procedure in SAP to match the
client's business process).

You need to map AS-IS process and TO_BE process.

What are the differences between a functional and business consultant?

The difference between Functional consultant and Business consultant are as follows:
1) A funcitonal consultant is able to configure the system unlike business consultant.
2) Functional consultant know more about business process unlike Business consultant.
3) A business consultant will bring business process knowledge and provide it to functional
consultant who in turn used this knowledge to configure the system.
4) Functional consultant has more configuration knolwledge then Business consultant
The responsibilities of a support consultant are:
- Primarily responsible for Handling tickets and application support to the endusers
- When an issue comes diagnose, analyse and solve the issue
- Responsible for any enhancements
- Writing functional specs and interacting with Abapers to develop any user exits
- Training the end users and preparing end user training material
For those who wished to know the role of a functional consultant. Below is one view:
A functional consultant evaluates the demands in talking with the customer\'s representatives,
transforms the essence into an abstract and algorithmic business model. Hence, he identifies the
use cases and transforms them into logical and technical views.
Then the main task starts: customizing the respective business area and making sure the system
reacts in the manner according to the constraints of the requested use case.
The consultant documents the settings and prepares proper guidelines that allow other
consultants to do further changes or repairs with due efforts.
The consultant takes care that proper training is given to the users and that the system is usable,
performing appropriately and the business flow is complete and correct.
During go live he assists the technical staff by testing the behaviour of the system.
After go live he guarantees that the procedures remain usable and consistent in real live situation
and proposes enh

The consultant takes care that proper training is given to the users and that the system is usable,
performing appropriately and the business flow is complete and correct.
During go live he assists the technical staff by testing the behaviour of the system.
After go live he guarantees that the procedures remain usable and consistent in real live situation
and proposes enhancements.
The main duty of a consultant is to transfer external know-how to the client. It is not manpower
that counts but intelligence, understanding of processes, a feeling for defects and general a
common sense.
Role of a Functional Consultant in an End To End Implementation
1. Functional consultant is expected to generate knowledge about the current business process,
design current business flows, study current business processes and its complication, in all we
can say getting through with current business setup. Flow diagrams and DFD are prepared, most
of the time in Vision format, all this forms the part of AS IS document.
2. Everything configured has to be documented as per their categories in the form of predefined
templates, these have to be then approved by the team leads or who ever the consultant is
reporting to.
3. Mapping and GAP analysis is done for each module, I have seen people defining integration
after mapping, gap analysis and configuration is done, but as per my experience in
implementation, it is a simultaneous process.
4. Before starting configuring future business processes in SAP, the DFD/ERD are prepared, this
documentation is called TO BE, which can be also siad as the result of mapping and gap
analysis.
5. Sometimes Functional consultants are also expected to prepare test scripts for testing the
configured scenarios.
6. End user manual and user training is also expected from F.Consultants.
The project normally starts off with a Kick off meeting in which the team size, team members,
reporting system, responsibilities, duties, methodlogy, dates and schedules, working hours which
have been predicided are

working hours which have been predicided are formally defined.

SAP Landscape is like a server system or like a layout of the servers or some may even call it the
architecture of the servers viz. SAP is divided into three different lanscape DEV, QAS and PROD.

- DEV would have multiple clients for ex: 190- Sandbox, 100- Golden, 180- Unit Test.
- QAS may again have mutiple clients for ex: 300- Integration Test, 700 to 710 Training.
- PROD may have something like a 200 Production.
These names and numbers are the implementer's discreet on how they want it or they have been
using in their previous implementations or how is the client's business scenario.
Now whatever you do in the Sandbox doesn't affect the other servers or clients. Whenever you
think you are satisfied with your configuration and you think you can use it moving forward, you
RE-DO it in the golden client (remember, this is a very neat and clean client and you cannot use it
for rough usage). As you re-do everything that you had thought was important and usable, you
get a transport request pop up upon saving everytime. You save it under a transport request and
give your description to it. Thus the configuration is transported to the Unit Test client (180 in this
example).
You don't run any transaction or even use the SAP Easy Access screen on the 100 (golden)
client. This is a configuration only client. Now upon a successful tranport by the Basis guy, you
have all the configuration in the Testing client, just as it is in the Golden client. The configuration
remains in sync between these two clients.
But in the Testing client you can not even access SPRO (Display IMG) screen. It's a transaction
only client where you perform the unit test. Upon a satisfactory unit test, you move the good
configuration to the next SERVER (DEV). The incorrect or unsatisfactory configuration is
corrected in Golden (may again as well be practised in the sandbox prior to Golden) and
accordingly transported back to 180 (Unit Test) until the unit test affected

by that particular config is satisfactory.

The Golden client remains the 'database' (if you wanna call it that) or you may rather call it the
'ultimate' reference client for all the good, complete and final configuration that is being used in
the implementation.

In summary:
Landscape : is the arrangement for the servers
IDES : is purely for education purpose and is NOT INCLUDED in the landscape.
DEVELOPMENT ---> QUALITY ----> PRODUCTION
DEVELOPMENT : is where the the consultants do the customization as per the company's
requirement.
QUALITY : is where the core team members and other members test the customization.
PRODUCTION : is where the live data of the company is recorded.
A request will flow from Dev->Qual->Prod and not backwards.
These three are landscape of any Company. They organised their office in these three way.
Developer develop their program in Development server and then transport it to test server. In
testing server tester check/test the program and then transport it to Production Server. Later it will
deploy to client from production server.
Presentaion Server- Where SAP GUI have.
Application Server - Where SAP Installed.
Database Server - Where Database installed
SAP Testing
SAP Testing is same as manual testing but here the applications are SAP R/3 and Enterprise
portal. Whenever there is change in R/3 and Portal and You need to design test cases according
the change request and test the application.

If you have knowledge in the module (like HR, CRM, SD, SRM), which you are going to test
would be helpful to you.

UAT means USER ACCEPTING TESTING. Suppose end user raised an issues that we solved
and send to end used it is working fine. then we get confirmation from him that it is fine. that is
call UAT.

UNIT TESTING - This is done by developer and anyone who did any customizing or any code to
ensure what they did is working properly

INTEGRATION testing - Done by tester by developing some scenarios which are most unlikely
and get the result to ensure the integration is correct

Apart from that, regression testing, functional testing and other cross functional testing are there
done by testers

In realization phase, unit testing are done by developers

After unit testing, Integration testing and other testing are done by testers/functional depending
upon the object to test.

Testing usually follows two paths. Firstly, System Integration Testing (SIT) which is performed by
the SAP team in the development client, and secondly User Acceptance Testing (UAT) which is
performed in the QA client after transport from the development client. UAT is performed by end
users or the testing team.

Unit Tests are defined and performed by developers. A process consists usually of several
functions. Each of this function usually consists of "sub-functions" corresponding to a single
method or a group of methods (if you are developing OO-based).

Unit Tests could be described as white-box tests whereas a normal tester (which should be not
identical to the developer) will test entire functions (black-box tests).

--- During the entire life cycle of a SAP solution, it is necessary to test the functions and
performance of your solution. With the SAP Test Workbench, SAP provides you with an
environment for all test phases, which you can use for testing in the following cases:

• Implementation of SAP solutions

• Integration of new components and business scenarios
• Customer developments
• Function tests
• Integration tests with other components
• Upgrades, regression tests
• Importing support packages

Integration
Features
Test Preparation
• Creation of manual and automated test cases
• Management of manual and automated test cases
• Creation of test plans
• Definition and management of test series
Test Execution
• Execution of mass tests using Extended Computer-Aided Test Tool and Computer Aided Test
Tool
• Integration of test cases and test scripts of non-SAP providers
• Assignment of work lists (test packages) to individual testers

Test Evaluation
• Permanent overview of test progress and test results
• Complete documentation of test processes in the test plans (test cases, test case descriptions,
test results, test case notes, error messages)
• Detailed tabular and graphical evaluation of all test plans
• Export of test results to Office applications
• Message processing

Testing usually follows two paths. Firstly, System Integration Testing (SIT) which is performed by
the SAP team in the development client, and secondly User Acceptance Testing (UAT) which is
performed in the QA client after transport from the development client. UAT is performed by end
users or the testing team.
SAP Upgrade Skills You'll Need - A
Recent Survey Points the Way
Hello Toolbox readers - my apologies for not blogging recently. I have taken on one too many
blogging commitments and that has resulted in less time posting to this blog than I would like. But
I have a good one for you today on SAP upgrade skills and trends. If you like a meaty blog post
packed with SAP skills tips, this one's for you!

Before I get to that, if you’d like to track some of my recent work, I just posted a two part video
series on SAP career strategies to the SAP Community Network, and I also posted to my site a
podcast on SAP training, SAP certification, and SAP market trends with Andy Klee of
ERPtips.com, who himself publishes a popular blog on SAP training here on SAP Toolbox.

OK, on with the upgrade post. As I noted in my PAC blog piece on SAP consulting trends in 2010,
SAP upgrades will be a significant driver of consulting demand – though not the kinds of
upgrades we have seen in this past. The SAP upgrades of 2010 will be meaner, leaner, and
much more tightly managed.

These new upgrades are what I call “smart SAP upgrades,” and while they will generate some
need for skilled consultants, they will not resemble the huge “roll out the consulting wagon”
projects the systems integrators used to feast on in the past.

To give some teeth to the trends I am talking about, I’d like to point you to a recent SAP upgrades
survey published by Panaya (disclosure: Panaya is a client). Panaya provides a SaaS-based
SAP upgrade solution, but for our focus here is on the free information they have provided in this
19 page report. (You can get a free copy of this 2010 SAP Upgrades Study for yourself with a
short sign up).

The data in Panaya’s 2010 SAP upgrades survey is drawn from the input of 145 SAP customers
and systems integrators who responded to an October 2009 online survey (53% of the
participants were SAP customers; 47% were SAP partners). While this is not a huge sample size,
it does give us enough data to highlight some critical SAP skills trends. I should note that the
respondents represented a wide range of geographic regions, industries, and company sizes.

One sentence in the upgrade summary really jumped out at me:

“Although last year’s survey showed that most SAP upgrade projects were on track
despite the economic downturn, this year’s responses indicate a slowdown in upgrade
activity compared to last year.”

That’s a critically important point that is reinforced by my own market conversations. Companies
are moving ahead with SAP upgrades, but not in a herd. They are moving along selectively -
enough to create skills opportunities for well-positioned SAP professionals, but not
enough to revive the SAP consulting market on a broad basis.

There is some good news, however: of the respondents surveyed, the most commonly cited
reason given for an SAP upgrade was: end of maintenance (54%). This was well ahead of the
second place functional requirements (35%) and third place improving usability (28%).

What we can take from these stats: due to the financial motivation provided by end of
maintenance, many SAP users will be compelled to upgrade. While many of these upgrades will
be narrow in scope, focusing on technical upgrades and saving functional and strategic
enhancements for follow-on phases, the “end of maintenance” upgrades will march on.

Of course, those respondents running on 4.7 or 5.0 were not as likely to cite end of maintenance
as a reason for upgrading. But we know that in the SAP market as a whole, the majority of
customers who haven't upgraded are indeed running on 4.6, so it’s the 4.6 to ERP 6.0 technical
upgrade that will be the focal point of upgrade activity in 2010.

There were some other results in Panaya’s SAP upgrade survey that shed light on SAP skills
trends.

For example, consider these results for SAP modules commonly used (page 10 of the survey):

FI --- 84%
CO --- 80%
MM --- 78%
SD --- 78%
HR --- 60%
PP --- 56%
PM --- 49%
QM --- 40%
PS --- 40%
LE --- 32%

We have to be careful about making absolute statements about module usage given the survey
sample size, but a few observations do come to mind:

- I’m struck that the HR number is so low, given that HR is useable by all SAP customers (unlike,
say, MM and PP, which wouldn’t be used by non-manufacturing companies in most cases). This
implies that best-of-breed HR is still a factor in many SAP shops.

- CO (Controlling), which was once used heavily by maybe half of those SAP customers who
used SAP Financials, is now just about as prevalent as FI itself. This reflects the increased
emphasis on the strategic/costing/planning capabilities of SAP versus simply the transactional
capabilities of Accounts Payable and Accounts Receivable. It is hard to imagine a good SAP FI
consultant these days who is also not well versed in CO.

- PM, QM, and PS – these “fringe modules” seem to have quite a bit of traction. Even if the
numbers are artificially high for some reason in this sample group, it’s clear that as the SAP
market matures, there are fewer “basic module” SAP customers and more who are pushing into
the complete functionality provided by the integration of quality, plant, and project management
systems.

Despite the respectable numbers of these fringe modules, I continue to recommend that unless
you are a bigtime industry guru, it’s best to combine expertise in a “fringe” module with a core
area. So instead of being a PM expert, go for MM/PM. Instead of PS, PS/FI.

Another interesting result from that same page in the survey: almost three quarters (73%) of
the responded use SAP NetWeaver components – a major increase from last year’s
responses (51%). This is a marked contrast to some industry sentiment I have heard from
analysts critical of SAP who claim “NetWeaver” is not heavily used. If we limit NetWeaver to
PI/integration hub only, perhaps. But once we include BW and Portals, clearly NetWeaver is a
factor in most SAP shops.

Here’s the breakdown:

NetWeaver BW/BI: 59%

NetWeaver XI/PI: 33%
NetWeaver Portals: 30%
NetWeaver TRex*: 16%
Other: 18%

*NetWeaver “Search and Classification”

A few interesting things to note here:

- NetWeaver MDM is still not in usage enough to make the “top four” cut. Neither is the
NetWeaver Developer Studio, which includes the Composition Environment. NetWeaver BPM is
not in the top four either. No surprises here. This does not mean that these tools are not
important to master, only that they should be combined with other skills that are more prevalent.

- NetWeaver PI is about where I expected it to be, showing a decent level of acceptance but also
reflecting the stiff competition in the middleware/integration space with best-of-breed tools. Given
this competitive middleware environment, I don’t see SAP boosting that PI number
significantly without the acquisition of a best-of-breed middleware solution.

- NetWeaver Portals is about where I expected also, reflecting a moderate level of usage but also
the diverse UI environments companies are utilizing. With the increased emphasis on mobile
access, I don’t expect this Portals number to increase much by 2011.

- NetWeaver BW/BI is clearly reaching the point of acceptance where it is moving beyond
discrete roles and specializations to a skill that most SAP consultants should add to their tool set.

- It will be interesting to see if NetWeaver Mobile can make an appearance on this list by next
year, and if we consider Solution Manager a NetWeaver component, surely that will be
somewhere on this list by 2011.
A couple final observations on the skills implications of Panaya’s report:

More than 55% of those surveyed said they were including Unicode as part of their SAP upgrade
project. This highlights not only the importance of Unicode to SAP users, but also a potential area
of skills exposure for SAP professionals to seek out. I am running into more consultants who
specialize in SAP Unicode conversions, and this may be another tool to add to the 2010 belt.

Over 47% of the respondents are using SAP’s industry solutions – a 10% increase from last year.
Panaya also found that the use of industry solutions almost doubled the complexity of SAP
upgrades. For SAP consultants, complexity is not always a bad thing, in the sense that
complexity often requires skills mastery and human intervention.

As long as complexity doesn’t hold customers off from pursuing new initiatives, mastering more
complicated functionality can provide a level of skills differentiation. I can also tell you that
increased industry specialization is a common request I hear from companies looking to hire SAP
professionals. Panaya’s survey certainly reinforces this.

My personal 2010 SAP outlook is good news/bad news: the good news is that IT spending will
continue to a modest basis. Companies are not cutting off all IT spending, knowing they must
forge ahead on mission critical projects. SAP professionals who work hard to achieve the
right level of skills mastery and specialization will be in the best position to capitalize on a
tight and not very forgiving market.

Panaya’s data on SAP upgrades provides a window into one of the most important SAP skills
trends of 2010. Just keep in mind that the skills needed to do “smart upgrades” are a little bit
different than the “welcome wagon” upgrades of the past.

As I said in my PAC blog post on 2010 consulting: “SAP’s classic upgrade methodology will be a
reference point, but many customers will look to firms that provide a leaner upgrade model.
Examples will include: fixed cost upgrades with most of the project managed virtually, tools that
cut the upgrade testing cycle and help with specialized SAP upgrade issues like Unicode. With
more companies managing part or all of their SAP upgrade within Solution Manager, we will also
see a continued emphasis on Solution Manager skills.”

I wrote that comment with service firms in mind, but it has skills implications for individuals as
well: know the tools that can smooth an upgrade, understand remote upgrade support, grapple
with Solution Manager and Unicode.

I hope that this blog post helped to shed light on the skills you and your team may want to be
targeting in 2010. Please feel free to post questions or comments – there is a good chance I can
work them into future videos, blogs, or podcasts. Oh, and if you want to track all my blogs and
podcasts, my “Master JonERP Blog and Podcast Feed” pulls in all my content, including the stuff
posted on this blog.
Previous Entry
SAP End User Training: An interview with Shannon Hicks, South
Carolina Enterprise Information System
We kick off our series of blogs on SAP End User Training with Shannon Hicks, a veteran of a
huge project to convert every state agency in South Carolina to SAP. Shannon shares some
great insights as to how end user training projects can succeed and even thrive.

Andy: Shannon, let's start with the project scope. How big is the SCEIS project?
Shannon: It's big, Andy. We are rolling out SAP to every state agency in South Carolina. We
have a legislative mandate to complete the go-live by May 3, 2010. Some agencies were happy
to do this, some not. There are some significant challenges—South Carolina state agencies have
over 70 different legacy systems—all of which are being converted to SAP. 70,000 users will be
on the system. There is a public website, which readers of your blog can visit: www.sceis.sc.gov.

Andy: Shannon, there’s an amazing amount of information on the project website. Any
comments about what people outside the SCEIS project can learn from the website?
Shannon: The publications and newsletters on the website provide a history of our journey. Not
only that, with the FAQs and learning tools, it can be a great resource for other SAP clients.

Andy: What was your SAP and IT background before this project?
Shannon: When I joined the U.S. Air Force in 1995, they were implementing EDI (Electronic
Data Interchange). I was assigned to that project, and when I later joined the Contracting
Squadron at Lackland Air Force Base in San Antonio, Texas, I was tasked with learning EDI and
training others. There was an eclectic mixture of civil servants, enlisted airmen and also junior
officers to train.

I learned very quickly the importance of adapting to different learning styles and personalities.
When an officer threatens to tear the stripes off of your uniform because he does not like the new
automated system you are showing him it makes things quite interesting!

Most of my experience is in Procurement (not training). I have 15 years of Procurement

experience. I was asked to join the SCEIS project in April 2008. I had no previous experience with
SAP. I started work on a Thursday, sat with new users as they went "live" and entered their work.
The following day I was training a new group of users.

Andy: When you joined the SCEIS project, what struck you right away?
Shannon: I had never been involved in an implementation of this magnitude. I was amazed at
how diverse all of the team members needed to be. Our training resources were limited and the
other team members (business analysts) made up the training team. We had multiple project
roles, as we were responsible for writing test scripts and testing, data migration, training, and
production support.

Andy: What did you (or management) do to address the shortfall in training resources?
Shannon: We embraced the limited resources with as much zeal as possible. I work with some
amazing people. Of course, after we realized how much time would need to be spent training, we
had to juggle schedules to ensure that functional team members were in the office to assist end
users from previous phases. Eventually, we used technology to our benefit and created e-
learning courses that allowed individuals to learn transactions on their own time without the aid of
an instructor.

Andy: What is the relationship between end user training and the SAP configuration being done
by others?
Shannon: Each team (MM, FI, HR, BW, etc.) has a team lead—most of the configuration was
already done on MM before I joined the MM project team. Project team members in my position
have the knowledge to recommend configuration changes, and the outside consultants
implement the changes, once they’ve been approved through our formal change control process.

Andy: How much configuration knowledge do end user trainers need?

Shannon: It’s important that they have some, but they really need to know what options are
available. For example: If we were putting in vanilla SAP, and a user says "can we change the
setup to do the process differently?" it's important for the end user trainer to know if it can be
done or try to find out from the consultants if it can be done. It is also important for the trainer to
be able to explain to the individual why their system was configured the way it was. A lot of things
that users vehemently told us they did not like were required customizations due to regulations
and laws.

Andy: So, it sounds like you and the other end user trainers had configuration-level knowledge
and that was helpful, correct?
Shannon: I think our approach makes a lot of sense, since the trainers understand the State's
business processes and why the system is setup the way it is. This gives the end users
confidence that the trainers know much more about how the system should be used as a result.

Andy: Did some end users want to know more about how the system worked, rather than just
know how to use the system to do their daily work?
Shannon: Yes, a big challenge was teaching both types of students in the same classes.
Employees who learn more than the others know that this translates into job security. Students
are sometimes frustrated and scared by all the new software. The current economy contributes to
this feeling.

Andy: Shannon, you mentioned in a previous email to me that "voluntary knowledge transfer
didn't produce as many Subject Matter Experts (SME's) as we had hoped"—can you explain what
you meant by that statement?
Shannon: Because of the weakened economy and subsequent budget cuts, agencies did not
always have the available staff to send to knowledge transfer Sessions. We invested a great deal
of time in this process and lost a lot of potential SMEs because it was not feasible for valuable
resources to be in training.

Andy: How many people did you train?

Shannon: Since I joined the project in April 2008 I have trained hundreds of mostly procurement
professionals. I teach a Procure to Pay and Purchasing course in the classroom. I have had to
travel to remote sites and even take laptops for the participants. Our most recent go-live forced us
to think outside the box. I developed online courses for Requisitioners and Approvers. Thousands
of end users took these courses.

Andy: How about online helps? Did you create online helps that are integrated with SAP?
Shannon: Yes, we used RWD's uPerform to do this. A lot of the transactions we use have online
helps that go directly to the uPerform helps.

Andy: Does the State of South Carolina use a Learning Management System to keep track of all
the students, classes, learning facilities, etc.?
Shannon: Yes, we used a product called Blackboard to keep track of everything. As an
instructor, this allowed me to email students additional learning documents and notices about
process changes and the eLearning modules that covered those changes.

Andy: Did you conduct any virtual instructor led sessions?

Shannon: Yes, using Live Meeting I was able to conduct sessions to handle questions. This was
primarily used as a follow up for the e-learning courses that were not instructor led. I would
answer questions and give live demos of how the system was designed to work.

Andy: Were formal evaluations done after every class?

Shannon: Every class had evaluation forms filled out by the students. I read all the evaluations
for my courses.

Andy: What stands out from reading all the evaluations?

Shannon: The common denominator was how important it was that the instructor understood the
end user's business processes that were being taught. Students also appreciated instructors that
tried to make the training fun.

Andy: Did you notice any differences in learning style between younger and older students?
Shannon: Most of the people who took to the eLearning modules were younger. One of the
younger students was on Facebook (playing Farm Town) during the classroom training—but she
understood everything, and asked good questions. She is now the go-to person for her agency.

Andy: When I was teaching, multi-tasking wasn't such a big issue.

Shannon: Andy, it's a judgment call, but you'd be surprised how easily some of the younger
students can 'pay attention' and still be multi-tasking.

Andy: Shannon, what's next for you and your project?

Shannon: Of course, I can only speak for the MM module. Personally, I would like to focus more
on the end-to-end business process. I’d like to work with end users to create training that covers
the entire procure to pay cycle. The people we train will then have a better understanding of
where their job fits into the entire cycle. Plus, I’m sure that future upgrades and support packs will
keep me busy for a while.

Andy: Shannon, let's review some key points about end user training. I’m interested in your
perspective on these. First, when should end user training development begin?
Shannon: Development should begin as early in the project as possible. The training team
should be researching the client’s business processes early on, becoming familiar with how the
agency (or company) conducts business. If the trainer stands in front of a room of participants
and knows SAP (or any ERP system) but has no idea what their current process is like, how can
they bridge the gap from their current world to their new? Of course, this is my opinion. :)

Andy: When should the end users be trained?

Shannon: No more than two months before going live unless you are training a true SME
(Subject Matter Expert) or using a Train the Trainer concept. (I was surprised how difficult it was
to convince management it is worth the investment to allow us to train "super users" within their
organization.)

Andy: What will be your response when an end user says they don't know how to do something
(after going live) when they were trained on that topic, previously?
Shannon: I direct the individual to our website. If I train users on a new topic, I make sure I have
a RWD uPerform simulation posted on our website as a future learning tool. If I do not have either
a simulation or some sort of "cheat sheet", I better be prepared to tie up service desk resources
to assist with the transaction repeatedly.

Andy: Lessons learned? Would you have done anything differently?

Shannon: At this time we are gearing up for our largest and most complex go-live. We are
implementing SAP at four very large state agencies. Each phase of our implementation has
resulted in significant changes in training methods. This time around I have requested to be
involved in the data gathering process. My plan is to ask questions about current business
processes and gather examples of any paper processes (forms, workflow, etc). Since the
agencies are so large, I plan to tailor my courses to each agency. For example: Although the
Department of Health and Environmental Control follows the same state procurement laws and
regulations, their processes are different from the Department of Transportation.

Making these adjustments to each course will help build a positive relationship with the users.

When I stand in front of a classroom holding an organization's internal form (probably first created
in 1982) and demonstrate how each data field on the form is entered into SAP I build trust with
the users. It is truly amazing! Body language changes, arms uncross, and questions flow.

Andy: Shannon, how did the SCEIS training of end users differ from many other projects where
"trainers" are brought in towards the end of the project?
Shannon: Because our SAP project includes a great deal of custom configuration, my
recommendation is to scrap the idea of bringing in "trainers" solely for developing training
materials and delivering training. The individuals that deliver training should be brought in early in
the project. They could be utilized in information gathering, system configuration, testing, etc. By
the time training begins, the trainer should have a full background knowledge of the system is
configured, why customization was necessary (to meet what business needs, regulatory reasons,
etc.)

Andy: The role you just described sounds like an internal business analyst role. How do you
distinguish (or don't you distinguish) between business analysts and trainers?
Shannon: Perhaps, if you take the definition of a Requirements Analyst (as opposed to a more
technical programmer analyst) and add TRAINING to it. The project doesn't end with the
configuration. If the project does not have end user "buy in" then it is doomed. Because many of
the end users knew I was familiar with their processes and had met with their management
concerning process changes, I gained a level of trust. To me, this was priceless!
Andy: Shannon, it’s been a pleasure talking with you. Thank you for sharing your insights and
good luck with the SCEIS project.
Shannon: Thanks, Andy. I am always happy to help, and I look forward to reading other
interviews you do on this topic.
SAP Support - A Recent Survey
Sheds Light on Customer
Viewpoints (and Skills Trends)
Hey folks -

It's been a while since I blogged here. I plead guilty to taking on too many commitments. The
other problem was logistical - I have blog and podcast feeds in many locations and started to feel
too spread out. I solved that part of the problem by uniting all my feeds into one "Master SAP
Blog and Podcast Feed" on Feedburner, which required a lot of geeky fun with Yahoo pipes, so
feel free to hop onto that feed. With that solved, I'm going to try to blog here at SAP Toolbox more
often also.

There's no better way to get back on track with this blog than on an issue that matters a great
deal to SAP customers right now: the cost of SAP support. A little while ago, I received an email
from IT Toolbox about a new survey on customer attitudes on SAP support. The survey was
conducted by Panaya, a third party software firm in the SAP ecosystem that offers SaaS-based
tools to streamline SAP upgrades and the implementation of SAP support packs. You can get
your hands on a copy of this free SAP support survey in PDF format by filling out a short sign up
form.

Some of the survey results were pretty surprising to me. In this blog post, I'll review some of the
survey highlights. Since this blog is geared towards SAP skills and careers, I'll sprinkle in some
skills tips, and I'll close with a few comments on the skills aspects of SAP support. Before I dive
into the survey, I want to say a word about data. To me, good data is one of the most important
contributions a firm or blogger can make to an SAP debate and I'm always on the lookout for
more of it. When you think of some of the hot button issues in the SAP community, whether it's
SAP certification, SAP support, or SAP versus SaaS, there is a lot of noise out there. The huffing
and puffing doesn't always advance the conversation, but good data does.

There are some voices in the IT Toolbox that have advanced some of these discussions. Eric
Kimberling of Panorama Consulting, one of the best sources of objective data on ERP versus
SaaS and other ERP purchasing factors, posts on these topics frequently in his IT Toolbox blog.
If you want more insight into Eric's data on attitudes towards SAP specifically, I recently issued a
podcast with Eric on JonERP.com that looked at SAP implementation trends and SAP project
success factors.

On the SAP certification front, Andy Klee of ERPtips just posted a great piece on his SAP training
blog here at SAP Toolbox. What made Andy's contribution so worthwhile is that he did the hard
work of primary research and in my view definitely advanced that particular conversation.

Meanwhile, for the hot button issue of SAP support, Panaya has done a good job of gathering
data on customer attitudes. Their survey sample was not huge - 179 responses from customers
and partners - but that's just enough to know that we are getting a useful window into customer
perceptions.

Here's some of the topics addressed in the survey:

What is the average SAP IT support cost per user?

How much of it is incurred as in-house costs and how much is outsourced?
What are the top SAP IT support-related challenges?
What are SAP customers' opinions on SAP's latest Enterprise Support program?

Overall, the survey is 18 pages long with 100+ metrics and 25 charts, so I can't reproduce the
effect of it here in this blog, so I'll focus on a few highlights that surprised me.

First off, Panaya estimates the cost of SAP developed and support across the organizations
surveyed at $5,670 per user, per year. Given the emphasis that both SAP and Oracle place on
support revenues in their quarterly earnings report, this number is not a surprise. Panaya
calculated this by adding the total internal and outsourcing cost of an SAP implementation, and
divided it by the number of users. This kind of number gives a good idea why support costs, and
more importantly the need to justify the value of the support investment, has become an issue for
all ERP users and a major reason why SaaS has established its current level of buzz in the ERP
community.

70 percent of this per user cost still goes to on site users, with 30 percent going to outsourcing (it
would be interesting to see if Panaya does another such survey in a year or two and tracks the
increase or decrease in outsourcing costs). Not surprisingly, overall cost of support was cited
as the top support-related challenge by 70 percent of those surveyed.

Another interesting issue is that of the "SAP support pack installation," which is not necessarily a
routine process for SAP users. Those surveyed cited on average 73 person days per support
package, with 42 days of that associated with testing.

But of course the spiciest information pertains to Enterprise Support, SAP's new support offering
that was rolled out with such a degree of controversy. Not surprisingly, the majority of those
surveyed (68%) did not think that the price increase of SAP support was reasonable (the original
price increase being a maintenance increase from 17 to 22 percent).

Personally, I found that number to be a bit low, because that meant 32% of those surveyed were
either supportive of the price increase or neutral towards it. I would have expected the level of
negativity around the price increases to be higher. What this number tells me is that if SAP does
a better job of communicating the value of Enterprise Support from here on out, and more
importantly, if SAP continues to collaborate with its user group representatives at SUGEN to
carefully measure support value before increasing support fees, SAP just might be able to pull out
of what seemed at one point to be a debacle in pretty good shape.

The full story of how SAP got into hot water with its original Enterprise Support announcement
and how it has started to turn the story around through user group collaboration is beyond the
scope of this blog, but if you want a very recent update on the status of the "SUGEN KPIs," here's
a recent link. The short version is that the first of the KPIs jointly established by SAP and its user
group representatives (SUGEN) is now being measured, and there should be more information
on the progress of measuring this first KPI (for CPU utilization and storage performance) in the
fall. This KPI is the first in a group of 11 that SAP and SUGEN have established that will
eventually be measured. There is quite a lot riding on these KPIs: SAP has agreed not to raise its
maintenance fees to 22% unless it meets the agreed-upon KPI measurements.

So, while we review these Panaya support survey results, we have to keep in mind that the issue
of SAP support is a moving target, and customer attitudes towards Enterprise Support in
particular may change again, for the better or for the worse, based on how SAP follows through
with its SUGEN/KPI collaboration and whether the KPIs developed really show customers the
value they are getting. We would also need a larger survey sample size to make any definitive
statements about Enterprise Support sentiment.

From an SAP skills perspective, the Panaya support study is also useful: there is data
indicating the degree of usage of various SAP modules and solutions. For example, of those
surveyed, 81% are now running NetWeaver components, with BW/BI being the most commonly
used (83%). The first thing we can draw from this data is that any SAP technical person not fully
immersed in SAP NetWeaver is falling out of relevance quickly. But I am often asked which
NetWeaver components are in most demand. This survey has BW/BI out in front with NetWeaver
XI/PI at 47% and NetWeaver Portals at 43%. I was a bit surprised the XI/PI number was so high,
which tells us something about the acceptance of SAP's integration tools amongst those
surveyed.

More interesting skills data: 43% of those surveyed are running SAP's industry solutions. Given
how aggressively SAP pushes these solutions I found this number a bit low, but it wasn't totally
out of range of what I would have predicted. I was not surprised to learn that FI and CO were the
most common modules used (95% for CO and 98% for FI), but SAP's HR usage according to this
survey was at 70%. That's a pretty decent number considering that SAP came to the HR party a
bit late and many shops were already entrenched in other solutions by then. I would have liked to
see some numbers on Business Suite product usage (CRM, SRM, etc) - maybe a topic for a
future survey.

Well, I want to wrap this blog entry soon but there is plenty of data on the implementation of
support packages I haven't had a chance to get into, and also some information on enhancement
packages. The enhancement pack info is useful because there isn't much data yet on how
customers are utilizing ECC 6.0 enhancement packs. The biggest difference between the two?
51% of those installing enhancement packages cited "understanding the new functionality" as
one of their top two challenges. Assessing the impact of the enhancement packs on the existing
solution was a close second (47%). This is where tracking data can really help you from an
SAP career perspective. Does it make sense to be a consultant that has expertise in how
enhancement packs impact the product areas you specialize in, from either an installation or
functionality perspective? The answer from this data is unequivocally yes!

My final thought on Enterprise Support is that there is a definite skills tie in here as well.
Enterprise Support is all about SAP making the case that there is indeed a much greater value to
be derived from the "best practices" SAP has developed for monitoring SAP support issues from
within Solution Manager. However, even SAP would concede that to accomplish this requires
expertise in a new set of Solution Manager tools, as well as the Run SAP methodologies that
provide a framework for post-implementation SAP support. For those who aspire to improve their
skills and marketability, there is a lot to dig into here. And the best thing? You can be confident
that the need for these skills will be there regardless of how the Enterprise Support debate pans
out.