Business Solutions with SAP

Planning For a Smooth SAP Go-Live Part 1

October 27th, 2008 by
SAP smooth go-live requires a lot of coordination

SAP go-live issues

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

1.  SAP Security and Authorizations.

2.  Master Data.

3.  Business process changes, process gaps (missed processes and exceptions).

4.  SAP ABAP Custom Development.

While each of these areas consistently cause trouble at go-live, resolving the first item, Security and Authorizations, and the third item, Process issues, should be a standard part of every project no matter who does it.  There is just no real reason for authorizations or business process issues to be a problem on any project.

The Master Data and Custom Development are a bit more difficult to resolve.  Even companies that believe they have a good handle on master data often discover that it is not as “pristine” as they might believe.  Custom development can also be another source of headaches.  Often it is some “gee wiz gotta have it” improvement, automation, or rearranging a printed form 20 times to get it “right” where development can come back to bite you if you’re not careful.  This is especially true with inexperienced developers who read some ABAP programming book, or take some back room fly-by-night “certification” course and then get a fake resume presented.

1.  SAP Security and Authorizations…

To reduce SAP go-live headaches, security and user authorizations must be carefully tested.  By testing I am *not* referring to consultant testing, core team testing, or even extended user (power user) testing–, I mean actual end users logging in under their own SAP user ID’s and verifying they have what they need to get their job done.

The most effective method I’ve seen over the years is to incorporate authorization testing into the end-user training.  Usually end-user training has “dummy” training user ID’s created that are used during classroom training.  However, the best solution I have seen is for SAP end-users to use their own ID’s during training.  They log in under their own ID’s and then verify that they have access to all of the transactions they will need at go-live.

At one client the users had a form that matched their training classes and users had to initial a sheet next to each transaction they tested, sign the sheet, and then turn it in at the end of the course.  If there were problems they were noted on the form and sent in to security to be resolved.  The users then make use of their training ID’s for the classroom training.  While this is a little disruptive to the classroom training process, it is the most effective method I have ever seen.  The idea is that the end user must somehow log in and test their logon ID long before your SAP go live.  However you decide to do that is up to you, but doing so will reduce many headaches after go-live when everyone is focused on trying to resolve fires, gaps, process changes, and the users learning a new system.

Suggestions and ideas for handling SAP security

1)      Integrate the SAP security and training efforts.  Those identified for training should also have the tasks and transactions they will be trained on identified.  This is a good starting point for security access as well.

2)      Be sure to test security with every end user before you actually go-live.  This will help to reduce the production headaches with security and authorizations; unfortunately it will not eliminate them.

3)      Take the time and effort to carefully structure your security and authorizations.  Done properly authorizations should not be a maintenance nightmare.

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

Four Part Series on SAP Project Planning for a Smooth Go-Live:

Planning For a Smooth SAP Go-Live: Part 1
(introduction, security and authorizations)

Planning For a Smooth SAP Go-Live: Part 2
(master data, data transformation methods)

Planning For a Smooth SAP Go-Live: Part 3
(process issues, blueprinting, testing, and change management)

Planning For a Smooth SAP Go-Live: Part 4
(custom development, costs and consequences of inexperienced developers)

Popular Searches:

  • sap security for go live

Related Posts:

Planning For a Smooth SAP Go-Live: Part 2

October 25th, 2008 by

SAP go-live steps and processes

2.  SAP Master Data. 

Ideally your master data processing should begin early in the process.  Identification of legacy data sources, and even raw legacy data extracts should begin during the Blueprint phase.  Experienced implementation consultants should be able to ensure that the key data requirements or data settings are also captured during the blueprint process. 

It won’t be perfect, but initial scope should have already been determined and experienced developers should be able to point you to the type of raw data records they will need to begin working with.  When you begin your SAP project you should immediately ask for SAP master data maps, layouts, and conversion information.  If the developers responsible for data conversion seem to “talk around” the issue but can not demonstrate very clear understanding of the details of the SAP master data requirement then you should be very suspicious. By the end of Blueprint legacy system master data requirements (extracts and layouts) won’t be complete but should be well underway. 

It is optimal to plan for Integration Testing to be done with converted data, even if the data is not perfect and not completely ready for prime time

Even though you may have to add a little more time to your initial project plan, it is optimal to plan for Integration Testing to be done with converted data, even if the data is not perfect and not completely ready for prime time.  By doing integration testing with converted data you will discover data gaps, process gaps, and other problems that can be addressed before you convert to a live SAP production system.  “Live testing” of converted data in a production system is the worst time to find out if the system will work.  Not only that, data corrections in SAP can be very involved and difficult because of the integrated nature of the system.

SAP Data Transformation or Data Conversion Methods 

There are four primary methods for data transformation into SAP: 

1)      Do the data transformations outside of SAP and legacy systems then feed pre-formatted data files into the system using standard input programs;

2)      Extract raw legacy data and do all of the transformations in custom programs or conversion tools inside of SAP;

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

4)      Or do transformations in legacy extract programs.
I personally prefer methods 1) or 3), if there is one method that I dislike the most it is probably 4).  There are mountains of data transformation tools available.  USE THEM!  I personally prefer MS Access, but that is for one time data conversion and one time “throwaway” transformation rules.  Over the years I have seen that the more cleanup and transformation on the data that is performed outside of SAP and legacy, in an automated and repeatable process, the shorter the development time.  Using that approach my experience is that is easier / less risky it is to resolve and mitigate data conversion problems.  The other side benefit of that approach is that it begins to press legacy employees to move away from the legacy app and begin learning more about the new system.
My personal method is to take unmodified, raw legacy file extracts, use MS Access to do as much data conversion, data cleanup, and data transformation as possible, and then use SAP Legacy System Migration Workbench (LSMW) tools to load the data. Over the years I’ve learned that I do NOT want any legacy data changes made at extract time.  It causes too many problems, and frequently it then leads to managing multiple, sometimes conflicting, transformation rules.  Often times a single change in an extract data set, before an intermediate or final transformation into SAP can completely compromise a data load.  And sadly, those “extract changes” rarely get reported so they are discovered by trial and error at load time.  
A good MS Access power user can do huge amounts of data transformation and file layouts to match SAP input requirements.  Done correctly, this then becomes an easily and quickly repeatable process.  MS Access is a quite capable data transformation tool, on a decent workstation it can manipulate hundreds of thousands, or even a couple million records “relatively” quickly for the lightweight desktop tool it is.  From there, SAP’s LSMW tool is quite powerful and has the ability to directly code individual field level transformation rules right into the program for any final “detailed” requirements. 

Suggestions for SAP data conversion:  

1)  Never leave off doing a “mock conversion” of data and capturing the necessary steps and times to do the real data conversion into your production client. 

2)  If you are doing a rollout of a new facility into an existing SAP instance, make sure you do some type of regression testing before you go into production.

3)  Plan for and be ready to support the master data maintenance efforts after go-live.

4)  Test and check every interface and batch job, both before the go-live and then within 24 hours of the first time they are run at go-live.

5)  Make sure to correct and clean up any master data issues immediately at go-live.  Each time that master data is referenced by a transaction without being corrected compounds the cleanup effort and the problem needing to be corrected.

Four Part Series on SAP Project Planning for a Smooth SAP Go-Live:

Planning For a Smooth SAP Go-Live: Part 1
(introduction, security and authorizations)

Planning For a Smooth SAP Go-Live: Part 2
(master data, data transformation methods)

Planning For a Smooth SAP Go-Live: Part 3
(process issues, blueprinting, testing, and change management)

Planning For a Smooth SAP Go-Live: Part 4
(custom development, costs and consequences of inexperienced developers)

Related Posts:

Planning For a Smooth Go-Live: Part 3

October 24th, 2008 by

 SAP smooth go-live process issues

3.      ERP or SAP Process issues 

Let me start with a caveat to this section.  No matter how good, thorough, experienced, or conscientious a consultant or a core team member is, there will always end up being a few process gaps, and an occasional completely missing process discovered at go-live.  Now that the caveat is out of the way, there are many reasons for the process problems: inexperienced consultants, company employees who miss some of the process exceptions, inadequate training, insufficient integration testing, lack of user acceptance testing, and other reasons. 

The bulk of the items causing process problems generally fit into three core areas, 1) design or blueprinting, 2) change management, and 3) testing. 

SAP / ERP Design and Blueprinting 

Your business probably developed numerous processes and exceptions over many, many years.  Some of those processes were also developed as the need arose, and in an ad hoc manner and may have many inherent inefficiencies.  SAP projects are generally tasked with replacing all of those years of collective knowledge and processes, as well as any “broken” processes in six months to a year, and on very large projects in maybe a couple years.  That is no small task and to be successful it truly takes an experienced consultant.  As I’ve previously written about, this is one of those areas that all of the fakes end up costing your SAP project and your company big money.  And I mean big money over and above what you pay them.
A good blueprint should translate your scope into all of the key business processes that your company does, and then the key process components needed to support those processes.  I generally prefer a blueprint that has inputs (or some type of process trigger), the process itself, and then the outputs.  It should also contain the key master data requirements, any necessary FRICE (Forms, Reports, Interfaces, Conversions, and Enhancements) development objects, and the key business areas affected.  If there is sufficient time in the Blueprint phase, the Blueprint itself should also begin to capture some of the key change management issues.

Poor blueprints (missing processes, too generic, too high level, etc.) cause serious project delays and flared tensions by constantly dragging your project back into “Design” mode when you should be in full project execution.  It takes up the time and effort of other integrated teams, and generally causes a “drag” on the overall project.  Obviously this burns up budgets too.  Worse still, a poorly designed Blueprint is often blamed on the company, the department, or the key resource on the project who is responsible for that area.  Unfortunately those “smokescreens” are often used by consultants who are not that skilled at extracting the necessary information needed for a good blueprint.  It’s always easy to “blame” the client through the backdoor by putting the responsibility on a core team member, or some other portion of the company / client team.
If there is a genuine issue with a team member, an experienced consultant should raise this issue during the process when it is encountered.  Frankly, if it suddenly comes up AFTER the blueprint is due, it should be seen as nothing but an excuse by the consultant.

ERP Project Testing 

Another area to begin addressing processes is during testing.  Any integrated application like SAP should include at least 4 primary types of testing.  No matter what name is used, they are generally individual transaction tests (sometimes called “unit tests”), transaction strings or processes within the same module like Sales and Distribution (“module tests”) and then full-blown cross module tests that test entire process chains from start to finish (true “integration tests”), and then finally tests that involve the wider user community often called “user acceptance tests” or “day in the life” scripts, etc.
During testing, while it is important to follow the scripts to be sure that all of the proper “boxes” are checked off, it is equally important to test more.  “Integration tests” and “user acceptance tests” serve as the last opportunity to find and address process gaps.  Sadly some consultants (and some consulting firms) see this as an opportunity to absolve themselves of responsibility for potential problems or shortcomings.  As a result, they will often strictly enforce that the script must be followed to the letter and no deviation is allowed and no exception processing is allowed.  There is a legitimate need to control the process to ensure that the work is done and that the known processes work sufficiently as designed, however there should also be some mechanism to address gaps or exceptions.  One simple method to accommodate this is to create a space on the signoff sheet that directly solicits comments about any process gaps and any exception processing that might be needed.  Final signoff of the testing should not be signed off until this commentary is converted into additional testing scripts or some manual process defined to address the processes.

For final integration testing you may wish to pick random documents from your current business operations to run those through the system with the converted data.  This will give you the best test to ensure things are working correctly.  For example, you may wish to choose 10 or more each of the sales orders, purchase orders, production orders, reports, etc.  The key is to use something that is meaningful and can be verified back against your current system.  

ERP Project Change Management 

Unless you completely re-design and re-write SAP to do all of your processes exactly the way they were done before, there will be change management issues to deal with.  And unless you also re-write the user interface, there will still be training and user acceptance to accommodate.  If you’re going to re-write everything, why bother with a packaged system application at all?  On the other hand, if you are putting in a package application such as SAP, Oracle Apps, or others, there are change management issues to deal with.
Change management generally encompasses a few key areas:  Training, communication, organizational change, process / job changes, and post production support.  Some change management is necessary on every project and if your company handles change reasonably well it may not be a struggle.  However, if your company has many employees who have done the same job for a long time, without much change taking place within the organization it will take a tremendous amount of “hand holding” to get them through even small adjustments. 
You will need to assess your own organization and its ability to absorb change for whether change management resources should be budgeted.  From a project perspective however, one of the key things to be wary of are consultants who want to add new functionality without understanding the impact on the organization. 
Business Change Management analysis case in point:  I was at a client where SAP’s Handling Unit Management functionality was the best fit I had ever seen.  They had high dollar custom made steel transportation racks that needed to be inventoried and returned, the packing was consistent and uniform, their production volume was not intense as a sheer number, and they already had wireless bar codes with some warehouse automation.  From a functionality standpoint it was almost a “no brainer” and a great ROI on the automated tracking, inventory, and return of the units.  However, a more careful look at the organization showed a very different picture.  The staff responsible for maintaining the data and processing the transactions had not been reliable with data maintenance or with processing in the past.  Also, because of the organization there was virtually no chance that would change in the future.  

A less experienced consultant with limited project or change management experience would have seen this as a great opportunity to throw some “gee whiz wow” new functionality at a company.  They keep billing for the new work (a scope change), they would be needed almost indefinitely for production support, and they’ve got a great candidate to blame for why you have to keep paying them.  Sadly I’ve seen this scenario played out over and over again.  On a recent project I saw this with the implementation of SAP’s Customer Service and Solution Database functionality.  The company had an “ugly” but mature and working solution, they were downsizing the customer service area, the SD scope for the project was already pretty significant, sales were beginning to slow, portions of the business were being spun off, and employee morale was already low.  The consultant convinced them to “replace” their solution database and customer service functions from a CRM application that they did not even retire.  So there weren’t even any software license savings.  The consultant got to stay on, support an unnecessary process (the legacy app was not going away and worked fine), and was needed for post production support.  

 The process related issues will quickly separate experience from inexperience.  There are lots of good consultants out there, and then there are lots of less than satisfactory fakes in the market as well.  Unfortunately it is it the “good” consultants who are often penalized for smooth and successful go-lives by early roll offs.  Meanwhile fakes and less skilled consultants are rewarded by extensions to support poorly designed processes and inadequately prepared user communities at go-live.  The old adage rings true here that “you get what you pay for” as long as you have a way to separate the genuine articles from the fakes.  In the end, there are many hidden ways you end up paying as much or more for inexperienced consultants, not the least of which are the many hidden ways their SAP implementation approach impacts your business.  A truly seasoned consultant may cost a little more up front, but at go-live with the quality of delivery and the overall satisfaction of the solution it can pay dividends for many years.  

 In essence, the need for careful process understanding can not be underestimated.  The amount of change your company can absorb, the impact of processes being brought into a package application like SAP, and the cost to your implementation budget should all be considerations. 

Four Part Series on SAP Project Planning for a Smooth Go-Live:

Planning For a Smooth SAP Go-Live: Part 1
(introduction, security and authorizations)

Planning For a Smooth SAP Go-Live: Part 2
(master data, data transformation methods)

Planning For a Smooth SAP Go-Live: Part 3
(process issues, blueprinting, testing, and change management)

Planning For a Smooth SAP Go-Live: Part 4
(custom development, costs and consequences of inexperienced developers)

Popular Searches:

  • Go Live Date Communication Example
  • go live communications examples
  • erp go live plan
  • communicate servicenow golive
  • communication messages for ERP post support example
  • go live communication examples

Related Posts: