SAP Implementation & BlueprintsSAP 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.