SAP & ERP Consulting from the Customer Point of View

synchronizing success

Most ERP software packages are designed around industry accepted business practices, operating philosophies and techniques that have evolved over many years. Today the issue is not whether there is a body of knowledge with supporting software tools, the question is… are clients educated enough to see the value or understand the proper use of the tools. The short answer is no.

Education versus ERP software training

First, many have lost site of the fact there is a difference between education and software training. End user software training is very important but it is mainly about how to do transactions in the software and how these transactions related to your business processes. However, this can be very different from understanding the original design intent and industry application of the tools.

For example, the issue of education vs. software training is analogous to training someone to fly a 767 but not educating them on the concepts of jet propulsion or flight; or how to start-up a chainsaw but not the best way to cut down the big tree. Both of these are scary propositions, but in terms of ERP projects it is about failure to achieve the business benefits. At the root of the problem is senior managers and end-users never changed their behaviors to take advantage of the tools; and a big part of this is lack of education.

Independent Sources of ERP education

Keep in mind, education is more than just a seminar of “best practices” put on by a software vendor (with a hidden agenda) in room full of 300 other clients. It is about getting some real independent education, not focused on any specific package. In addition to understanding key concepts, one must also delve into the mechanics in order to implement.

Baked into the ERP implementation methodology

There once was a time when management and user education were part of the standard implementation methodologies. Interesting enough the project success rates was much higher.

For example, it is worth noting the great Joseph Orlicky wrote the first groundbreaking book on the topic of MRP (forerunner to ERP) back in 1975 (updated and still a good read). It focused on concepts and techniques on how to plan and control materials in a manufacturing plant. However, the most interesting thing is Mr. Orlicky (an employee of IBM) never glorified the role of the computer. He believed if one did not understand the underlying principles of MRP, the computer was not much help anyway.

However, the late Ollie Wight (the godfather of MRPII) said it best “MRPII is not a computer system, it is a people system made possible by the computer”. Orlickly and Wight went on to build and grow the “religion” called APICS (The American Production and Inventory Control Society). The best thing that ever happened to manufacturing practitioners.

Back to ERP Basics

Today there is a disconnect between industry best practices and what clients attempt to do with their systems. It might be time to get back to the basics of blocking and tackling or at least try to understand the intent of the package you just purchased.

Instead, we focus on the gee-whiz aspects of software, technology, implementation tools, and turnkey solutions (which usually exist only in the marketing literature). Cheaper, faster and the slam-dunk mentality is the name of the game, even when we do not accomplish anything worth the effort. We naively assume the mere existence of better tools automatically results in a change in employee behavior (if we build it, they will come). We fail to educate senior management and then wonder why they are not committed to the project. We set higher expectations of our employees, yet as leaders, we fail to provide them with the knowledge they need to succeed. When our projects go down the tube, we blame software vendors, consultants, the entire senior management staff, all employees, our spouse, and everyone else except ourselves.

No, education is not glamorous so proposing it will not make you a hero. Nevertheless, it is the stuff successful IT projects are made of. If Ollie knew what was going on today he would roll over in his grave.

=====================

Contributed by Steve Phillips of the Street Smart ERP Blog – Visit his site for more great project insight.

Related Posts:

• The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors
• SAP Success Factors for Vendor Selection – Responsibility Matrix 1
• ERP Project Plan: Getting Real Part 3
• Reduce SAP Project Stress Part 3
• Achieve Breakthrough ERP, SAP, or IT Project Success: 1 of 4

This is the final post in the series on SAP project shared success criteria.  Doing this entire topic justice has been more of a challenge than I had originally anticipated and at some point I will put it all together in a PDF e-book. 

This series leaves you with a lot to digest but over the years these items generally make up the foundations for a very successful project that is able to transform your business.  This series has been challenging but interesting and I am glad it is complete. 

In a few more weeks I will be coming back around to try to wrap up my series on SAP reimplementation for little more cost than a technical upgrade.  That one turned out to be more challenging than I had originally expected.  Until then, here is the final installment in this series on project success criteria.

Legend

A = Primary Responsibility for the success factor
z = Shared but secondary responsibility for success

21.  SAP Data Analysis and Conversion

One of the major activities of an SAP project is the data analysis and conversion. On many projects there are too many new data requirements or data changes needed after the system goes live.  One way to avoid so many of the data correction in a live production system is to ensure that you have sufficient integration and cutover testing.  We will look at testing in a moment.

The primary responsibility for data conversion is generally on the customer.  Customer primary responsibilities include:

• Identifying legacy and other data sources
• Cleaning or scrubbing the data
• Ensuring the converted data meets business processing requirements
• Defining sufficient test plans to validate data is properly converted
• Provide sufficiently skilled employees to work the data
• Make as many data corrections as possible in legacy systems before conversion
• Ensure there are sufficient hardware resources available for meaningful data conversion tests

I’ve developed a short list of the common data conversion risks as adapted from the SAP ASAP 7.0 Data Migration and Risk Assessment Template.  That template, provided by SAP, contains a sample issue and risk log, and includes some suggestions on how to manage the following common data conversion risks:

SAP Data Conversion Project Management Risks

• Improper estimates of data migration effort and activities
• Client side skills gaps on data migration
• Deferring data corrections until after go-live
• Knowledge of and access to data sources
• Insufficient or incorrect change control processes
• Insufficient participation from key functional project team members (client and consulting)
• Improper management of dependencies between functional areas or modules. 

SAP Data Technical Conversion Risks

• Lack of agreement on system of record, data definitions, standards, transformations, conversion methods, etc.
• Data migration tool(s) not well defined or settled
• Hardware sizing and data volume are inconsistent
• Requiring historical data conversion (rather than using legacy systems for historical purposes)
• Multiple legacy sources of data for single master record loads in SAP.
• Data gaps – no corresponding data record for SAP conversion
• Different data structures between legacy systems and SAP.  For example SAP may have structured hierarchies and the source data may not.
• Poor data quality – errors, duplicates, inconsistent use of fields

Preparing conversion programs, or more specifically, using SAP’s variety of conversion tools and resources is a vendor responsibility.  Together with that the vendor, who has set up the system with the master data requirements is also responsible for providing data load templates as well.  Further the vendor’s functional consultants must participate in the data conversion design and development activities because they are the ones that set up the system and know the master data requirements better than anyone.  The only exception to this is if you decide to bring in consultants who do knowledge transfer to your implementation team and your own internal team does all of the system setup.

For an overview of the various data transformation methods in an SAP project please see the following post:

Planning For a Smooth SAP Go-Live: Part 2
http://www.r3now.com/planning-for-a-smooth-go-live-part-2

SAP Blueprint Master Data Requirements

As a final note, a system integrator should be able to provide a first pass at basic master data requirements by the end of the Blueprint phase.  In fact your SAP Blueprint should contain a technical blueprint section with significant amounts of detail. 

• It should include each master data type (Material Master, Vendor, Customer, Routing, Sales or Production BOM, Work Center, Chart of Accounts, Profit Centers, Cost Centers, etc., etc., etc.)
• And it should include each master data SUB type, using just the Customer Master as an example it should contain the requirements of sub-data types, for example you may need Ship-To Customers, Sold-To Customers, Bill-To Customers, Payers, Agents, Freight Forwarders, Carriers, one-time customers, web shop or online customers, etc.  This type of breakdown and segmentation should be done for every data type so that you know what data conversions are necessary.  And this level of detail MUST be contained in a sufficient blueprint.
• At the end of the blueprint, to ensure that you have all of the master data requirements covered as well, your system integrator SAP blueprint document should contain the specific details of every transaction data type.  That transactional data requirement will be a key part of the data conversion.  For example using the Material Master and inventory movements SAP provides the blueprint document should contain the specific types of inventory movement transactions you perform.  Simple goods receipts, goods issues to production, goods receipt from consignment stocks, issues to consignment stocks, scrapping, shipping / distribution goods issues, receipt into restricted / quality hold, move into unrestricted from quality hold, transfer from plant to plant, transfer from storage location to storage location, etc., etc., etc.

 If your SAP system integrator Blueprint does NOT have this level of detail then it is not sufficient to set up the system and perform the necessary master data conversion.  Further, if it lacks this level of detail you may want to fire your system integrator and demand a refund of at least part of what they bill.

By having this level of detail at the end of SAP blueprinting (process details, master data details, interface requirements, forms, reports, etc.) you can immediately move into setting up the system. If you lack this level of detail you may find yourself forever in design mode (revisiting normal blueprint requirements) and blowing both the budget and the timeline.

I suggest you add this summary of the type of detail you want by the end of the blueprint phase to your contract.

22.  SAP Test Planning

You will have to determine who needs to perform what testing, when, and where.  Together with that you will also want to use this as an opportunity to get both “power users” and non power users involved in the testing.  This becomes the early part of knowledge transfer as well as user acceptance testing.  Inevitably the additional resources from outside of the project team will discover gaps or items that might need to be addressed. 

The Test Planning responsibility is primarily on you as the SAP customer.  Your primary goal here is to ensure that every process you put in scope is represented in some type of testing script. For example, in your order to cash process you might want test scenarios that include credit processing with and without product returns; third party drop shipping to the customer direct from the vendor; pro-forma invoice processing and then follow-up commercial invoice processing; interfaces to and from various external systems; online order entry processing with and without manual intervention; backorder processing and sourcing from other facilities, etc.  At a high level you will be responsible for ensuring that you cover all of the key processes that need to be tested.

SAP Test Strategy and Testing Approach

• SAP Test Management
  • Test planning, scheduling, and logistics / coordination
    • Identify users to perform testing
    • Identify who will coordinate testing activities
    • Location and equipment logistics for testing
    • Method for communicating test schedule to participants
    • Test data – common master “data sets” to use for testing.  This is different than the converted data testing.
• Types of SAP Testing and Methods for Testing (whether manual or automated)
  • Unit testing (single transaction)
  • Business Process testing (unit test strings within the same functional module like SD, MM, PP, FI, CO, etc.)
  • Integration testing (Business Process testing including the integration points with other functional modules)
  • Interface testing
  • Data conversion testing (test the data load programs)
  • Converted data testing (test the converted data at performing various functions)
  • User Acceptance Testing
  • Regression Test
  • Batch Job testing (test batch programs, timing, and sequence)
  • Security Test
  • Performance / volume testing
  • Any positive and negative testing requirements for security or transactions
  • Ad hoc testing of unplanned variations and variants
• Testing Toolset (various spreadsheets, or automation tools for building and managing the testing process).
• SAP Test Reporting and Analysis
  • Test Metrics
  • Defect Management

Change Control Process (for an overview and details of the SAP change control process see SAP System Integrator Shared Success Criteria Evaluation 4 which focuses critical success factor on #20 on this list of “System Change Control Process”). 

As for a test script, I have included an example one which is a modified version of the standard options SAP provides as part of the older ASAP methodology.

EXAMPLE SAP TEST SCRIPT with Ad Hoc or Variant Section information.

23.  SAP Test Development

As for test development this is clearly a vendor primary responsibility.  Unless you use SAP’s integrated Solution Manager resources for testing this is probably one of the areas where you will have to rely heavily on your SAP partner. The reason this is primarily a vendor responsibility is that as an SAP customer “you don’t know what you don’t know.” 

Unless you have adopted an approach where you require the implementation vendor to act as pure consultants, where your own project team does all of the system setup, you will not know the detailed testing requirements.  As a result a vendor must be able to walk you through the transaction strings and dependencies.  They must be able to take the entire process-related solution they blueprinted from master data creation through cash processing and any interfaces or manual steps in between. 

Because of time, budget, and limitless possibilities there is only so much testing in a project.  These limitations create a requirement that only a “limited universe” of testing can be accomplished and SAP system integrators will usually require someone to sign off on those limited tests. 

There are a few things to beware of here:

1) When the tests have been “gamed” to support only a successful outcome and not to actually test the solution.

2) When a system integrator pushes back on testing variations that they may not have documented in the “formal” test scripts.

3)  Any vendors who engage in hard push back against additional ad hoc, variant, or converted data testing.  Unfortunately I have seen a couple of the major SAP system integrators KNOWINGLY push trash on their customers.

For a thorough testing program you should always ensure your tests include any of the custom development objects as well as manual processing steps.  For example, a thorough test process must include testing of any outputs (forms), interfaces, enhancements, and reports.  Data conversions should also be tested but may be done separately.  However, one strong word of caution here, once converted data is available, even if you do not do formal testing, be absolutely certain to do as much process testing as possible with the converted data.  Testing with converted data will reveal a number of potential problems that can be corrected or resolved before you go live.

Related Posts:

• Overcome SAP-ERP System Integrator Sales Tactics 7
• SAP ERP Project Failures Lessons Learned and Mini Case Studies 2
• SAP Implementation is an Investment NOT an Event
• SAP ERP Project Failures Lessons Learned and Mini Case Studies 3
• SAP Implementation Projects: Still Crazy After All These Years

I had intended to wrap this series up with this post but because I haven’t done much review of the SAP System Change Control Process this post will address that topic in detail.  The last few SAP critical success factors will have to wait for the next post.

Many of the steps, insight, techniques, and other suggestions I have made were gleaned from the SAP ASAP methodology and my experience with the various toolsets SAP provides to their customers and vendors. 

This post will address this SAP or ERP critical success factor about the SAP System Change Control Process from my experiences on SAP projects since 1994. 

Legend

A = Primary Responsibility for the success factor
z = Shared but secondary responsibility for success

20.  SAP System Change Control Process

When it comes to SAP system changes the software is pretty mature.  Between the SAP Correction and Transport System (CTS) and more recently the Solution Manager options, SAP change control options are very robust.  Because the landscape approach is mature, and because SAP provides most of the change tools for success I have placed this item 100% under SAP system integrator responsibility. 

For the actual management of the system changes themselves, including gateway approval processes for moving changes an SAP system integrator should have proven tools and methods for managing this entire process.  What is critical for you as an SAP customer, or prospective customer, is to ask SAP system integrators for samples of their change control processes and their spreadsheets, approval templates, or other resources for managing SAP system changes.

Some Steps and Considerations to Defining an SAP System Change Control Process

• Determine the team members who have the authority and ability to create and then release SAP change requests.
• Define the details of how SAP change requests are created, the naming conventions used, and how they are released.
• Define the system change documentation requirements.
• Develop tracking tools and status monitoring resources for change control or ensure that your SAP system integrator has useful templates.
• Determine how to manage the transport sequence of system changes.
• Define the change control requirements for each part of the system landscape, what is the requirement for SAP Development changes, and then for moving them to SAP QA for testing, and then finally the requirements to go to SAP Production.
• Develop change control “levels” or requirements for the different parts of the project.  For example, depending on your industry regulatory requirements, you may have less strict approval and gateway requirements for early phases of the project but as you get closer to going live and during the testing processes they will become more strict.  And then finally once the system is live for a short period (generally 1 – 3 months) you may establish very rigid change control requirements.

Poor SAP Change Control Processes Can Create Major Problems

In spite of the normal three (3) tier system landscape SAP has proposed for years (Development – QA / Test / Training – Production) I’m still amazed by how many times production systems are opened up for direct changes.  With very few exceptions (and there are a few, like number range changes) any developer or consultant who insists on a need to open the production system may need to be removed from the project.  This is very high risk and can cause the system landscape to be out of sync.  Any supposedly “experienced” consultant who does not understand the need to follow a properly defined change control and verification process should not be on an SAP project or near any business technology system. 

An SAP system integrator should have proven tools and methods for managing the entire SAP System Change Control process

Making direct production system changes creates inconsistencies in the SAP system landscape which:

• damages testing results,
• creates system maintenance issues,
• and creates general instability in the overall landscape. 

For example you may test something in your QA system and then when you move the change to a production system that has been changed independently your production system may fail. And that is just one example.  Once the damage is done it may be difficult to make the landscape consistent.  Sometimes it may not be possible to make the SAP landscape consistent at all depending on the types and quantities of changes.

The first step to a good change management program is the system landscape itself.  This diagram shows a typical “best practice” SAP system landscape with transport paths.  Or how the SAP CTS (Correction and Transport System) should be set up to move changes. 

SAP Landscape Configuration Assumptions / Decisions

An SAP system landscape has a ‘Configuration Master’ client on the Development box. This SAP Development Master Client contains only system changes and custom programs.  There will generally not be any master data there except the few items that are needed to directly support the system setup.

The SAP Development landscape change process has an SAP Development Sandbox for prototyping, concept checking, or testing various methods on setting up transaction processing. The initial prototyping and concept checking in the SAP Sandbox will not be directly transported.

Once SAP configuration is (1) set up in the Sandbox and appears to meet the requirement it is (2) set up again in the SAP Development Test System to ensure that it works as expected (the Dev Test system is generally a much “cleaner” system than the Sandbox).  After satisfactory results in the SAP Development Test System the changes are recorded in the test system and then (2) copied to the data conversion and ABAP programming client.  This is a parallel activity to the SAP configuration activities taking place in the Dev Test environment.  ABAP programming is generally considered “client independent” which means that any code that is created is automatically generated in all of the associated clients.  This is why it is generally a separate client that has a separate transport path.  As ABAP coding or data conversions are completed enough to test, the underlying code is used to generate a transport request that is then (3) copied into the SAP Development Master Client.  When this code is copied into the Master Client it is automatically generated in the other clients in that landscape as well.  From there the coding can be tested and verified in the Dev Test client even though that transport was not copied into there.

As the SAP configuration and SAP ABAP development-conversion activities are completed and then copied into the SAP Development Master Client, they are then (4) moved into the SAP QA (Quality Assurance) Test system.  At a pre-defined point in your SAP project, a Training client is created from the SAP QA Test System.  Once that Training Client is created and the training data and training documentation is created you will not generally move any new configuration or coding changes into that system unless they are critically needed.  The reason you stop SAP Training Client changes is that even if the training environment is not 100% perfect (generally +90% is sufficient), you need a stable environment to create your training data and documentation from.  As necessary you will create additional training clients as part of your overall training strategy. 

For more information on the various types of training throughout your SAP project lifecycle please see Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project 1 and the second part at Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project 2 .

Once the SAP QA testing is successfully completed you will manually (5) move each of the QA CTS (Correction and Transport System) objects into the SAP Production System and into the SAP Pre-Production client [FN1]. You begin the process from the beginning if there are any adjustments, changes, or corrections needed during the SAP QA testing process.  Once you are satisfied with the testing results, and the changes or corrections have been moved into the production system, you perform your mock go-live or mock conversions in the live production system or in the pre-production system (depending on your landscape design).

Conclusion on SAP Configuration, Correction, and Change Management Processes

Over the years I’ve seen some well done, carefully controlled, and well managed system landscapes.  The one thing that set them apart was how they managed the system change process.  SAP itself provides a significant number of tools and resources, including BC Sets (Business Configuration Sets) which we don’t have time to address today.  However the important thing to understand is that a properly constructed system landscape and change process is critical to a successful SAP implementation. 

On the other hand I have come onto other SAP sites at customers where their system integrator should have been sued into non-existence.  SAP is not some new and unproven software application with weird new ways people are experimenting on implementing it.  But like my friend and previous co-worker Michael Doane says (paraphrased) it is still shocking at the number of SAP implementations that are done as if the application just came out yesterday and people are trying to figure out how to implement it.

Do not underestimate the importance of a well thought out and carefully controlled SAP system landscape and change control process.  In the end it can mean the difference between a smooth go-live with relatively few bumps (when taken in context with all of the other critical success criteria) and a complete disaster

 ======================

[FN1]  My personal experience as a “best practice” is that you are better to have a separate pre-production client available to do your Mock Go-Live testing in.  There are several reasons an SAP pre-production client is useful:  you can quickly simulate live production processing; if significant data changes are discovered at the last minute that can be remedied in the pre-production system with some of the mass change tools or other correction methods you can easily ALE (Application Link Enabling) the master data from one client directly into the live production client.  This provides another risk mitigation point for the live conversion.

Related Posts:

• SAP System Vendor Project Success Criteria 1
• SAP System Vendor Project Success Criteria & Factors 3
• SAP System Vendor Project Success Criteria & Factors 2
• SAP Success Factors for Vendor Selection – Responsibility Matrix 1
• Removing SAP Project Barriers to Realize ROI and Business Benefit