I have been working with SAP for over 15 years.  This was my first SAP Retail project and once again SAP has proved to me that it can be successfully leveraged and become a competitive advantage for those companies that implement it.  Each time I start a new project in a new industry I think about the vast differences in how the new company will need to leverage SAP and the challenges that unique business will create for the SAP application.  Time and time again a reasonable solution path is achieved and SAP becomes a solid foundation from which the business operates.  The diversity of my own personal experience working with successful SAP customers demonstrates this point.  There are not a lot of similarities in how A Flooring Retailer, Rocket Manufacturer, Pharmaceutical Manufacturer operate, yet they are all very successful at leveraging SAP.

Project Background

A little bit about my background in SAP Retail.  I have played quite a few roles over the last 2 years.  I have been an Infrastructure Architect (Design Of Virtual SAP Landscape), Development Lead (Initial Implementation), Stabilization Lead (Post Go-live), and SAP Program Manager (2 Physical Inventory Projects, Implementation Of Canadian Operations, POS (Point of Sale) Redesign, and Store Receiving Redesign).  Through these various roles within this project I have learned some very important new lessons as well as proved out ones I already new.

Lessons Learned – Too many to fit in one post

I would like to break down my lessons into the various phases of the project, from start to finish I think there are valuable lessons to be learned.  I will start with a lesson learned that applies to all aspects of the project and you will most likely think “thanks captain obvious for pointing this out”.  Rule #1 – Apply Common Sense in all decisions you make and look to see that other decision makers are doing the same.  Yes this is obvious but more often then not common sense is not applied.  I will reference this theme as I point out specific lessons learned.  Many of my lessons learned apply to all SAP projects or any project in general.  I will try and highlight lessons that I feel are specific to a retail.

In order to keep this post manageable I am going to break the lessons learned up into a series of posts.  I will add a new post each week until I have covered all the areas that I think are important to cover.  So lets start with project resources.

Consulting Resources

• Eliminate Under-Performers Quickly – I personally am not very good at this.  It is in my nature to look to try and help develop an individual to be successful.  However when it comes to consulting resources, career development does not apply on a project team.  We had several resources (not on my team) that did not have the skills and/or could not keep up with the pace.  We worked around them instead of eliminating them.  DataXstream did have a contract resource we brought on to my team and within a couple weeks we could see that he had interviewed better than he executed.  It is never easy to say we made a mistake to the client but we did and we replaced him.
• Cheap Resources Are Not Always Cheap – You could also reference the lesson above because it usually applies here.  However decision makers managing budgets tend to try and make the numbers work instead of ensuring they have the right people or are doing the right thing.  If a resource does not have the skills, drive, attitude or lacks all of these then it does not matter if the numbers look good in Excel.  This is a common thread to all SAP projects.
• With Free Resources You Get What You Pay For – There are many free resources that consulting firms provide that add real value.  However it is important to recognize that not all do and some provide negative value.  Free + Negative Value = Expensive.
• A Good (Non-Retail Experienced SAP Resource) is Better Than A Bad (SAP Retail Experienced Resource) – An SAP Retail System is 95% the same as any other SAP system.  Yes, there are differences. A good resource will have worked in a divers set of industries in the past.  They will pick up retail differences.  A weak resource with Retail experience will continue to be a weak resource.

Here is an outline of my future lessons learned post topics:

• Week 2
• Client Resources - There Are Never Enough Client Resources
• Planning - Establish Planning Rules That All Decision Makers Agree To And Then Follow Them

• Week 3
• Design - If It Is Hard or Complex You Most Likely Are Taking The Wrong Approach

• Week 4
• Execution
• Basis - Size Does Matter
• Configuration - Prototype And Prove Out Approach Before You Commit To Process
• Development - RICEFW Can Not Be Developed In Silo’s

•  Week 5
• Testing - Testing Design Is More Important Than Solution Design
• Go-live Planning & Execution - Have An Implementation Methodology That Tests Your Go-live Plan As You Go
• Go-live - Big Bang Not A Good Idea For  An SAP Retail Implementation (Without A Pilot)

• Week 6
• Post Production Support - Figure This Out Prior To Go-live

Hope you have enjoyed this post and I will see you next week.

Church & Dwight – SAP Upgrade Customizations Church & Dwight needed to update their documentation standards, their ABAP programming standards and their SAP monitoring procedures. In preparation for an upgrade from 4.7 to ECC 6.0, Church & Dwight needed to identify the extent of and need for their customizations. Eliminating unneeded customizations would reduce the effort, cost and complexity of the upgrade project.

View More Case Studies

Intradeco Apparel – SAP WMS Integration For Intradeco Apparel, the integration of their third-party Catalyst Warehouse Management software was paramount to the go-live of their SAP system. Intradeco had tried twice before to go live with SAP, each time ending in failure as the integration to their legacy system was not done well enough to limit business risk.

View More Case Studies

Other companies may have consultants that match ours in talent, but no one matches our skill. Talent is natural. Skill is only developed through tremendous work ethic and endless hours dedicated to honing one’s craft. Our craft is SAP: from the program level down to the specific functional, technical, and administrative details. Our depth of understanding and experience in SAP allows us to clearly see the big picture, and our detailed SAP expertise is used to build solutions that match your vision.

Because Experience Matters

DataXstream offers senior level consultants covering many types of SAP consulting services. Our deep domain expertise, particularly in technical activities, enable customers to tackle complex, challenging projects where time is of the essence. Averaging over 10 years SAP experience per consultant, we can fill most roles from analyst to project lead, to solution manager. When hiring DataXstream, you gain the commitment to success that is reflected in our 100% project success rating.

DataXstream’s range of services include:

Infrastructure Assessment and Systems Architecture

Whether you are looking to implement SAP for the first time, perform an upgrade, merge several legacy systems together, or virtualize your landscape (SAP or otherwise), it is critical that you take the proper steps in preparation for your work.  DataXstream can work with you to design a system landscape that is able to meet your business goals and adapt to business growth in the short, medium, and long- term.  We will review your existing hardware, software, systems architecture solutions (SAP and non-SAP) and make recommendations regarding the design of your system and the applications you need.  We will determine the sizing requirements for your new landscape (including the amount of hardware, storage, servers, etc. that is needed), identify gaps in hardware and software between your present system and the one proposed, and obtain all required licenses.  At this stage, we will also make recommendations as to whether to engage in a virtualization process or not.  If you decide it is in your company’s business interests, we will use our technical expertise to virtualize your landscape.

 Project Management

Once you have architected the optimized and efficient IT infrastructure needed to support your SAP system, DataXstream can assist you in the management of your SAP projects.  We work collaboratively with customers to develop and deliver strategies and engagement plans for projects in all phases of the SAP lifecycle; including implementations, development, integration, upgrades, data management, and support. We provide realistic project forecasts, deliverable timelines, estimated costs, and resource needs.  Whether it is during the stage of pre-implementation, execution, or post-implementation of your project, DataXstream remains highly involved in the process and can work with you on strategy, tactics, and execution.

SAP Technical Development and Functional Configuration

Once you have your infrastructure and the specifics of your envisioned SAP solution in place, DataXstream’s SAP experts can do the nitty-gritty work to make your plan into a reality. Our team of senior developers dive into the programming world of ABAP, BAPI, RFC, XI, PI, IDOCS, ALE, .Net, Java Connectors, as well as a number of middleware integration platforms, working to meet all the functional and technical specifications of your SAP system.  Our consultants have the necessary mix of  project leadership, thorough understanding of  business processes and goals, and SAP technical expertise to deliver solutions that are both technically-sound and business-process optimized. This work involves configuring all critical components of the SAP system, developing custom applications to enhance the capabilities of standard SAP solutions to meet your unique needs, and testing each of the SAP components to ensure your system performs as desired.  We integrate all critical process,  data sources, and third party software with SAP; cleanse and migrate data as necessary into your SAP system; leverage SolMan’s rich tool set to better manage and support your system throughout the application lifecyle; and provide the Basis administration to KTLO and support your SAP system’s day-to-day activities.

Support

As you are engaging in your SAP project, DataXstream can assist with every phase of an SAP lifecycle.  Our consultants have been through countless SAP lifecycles and have experienced the details of every stage. We know when certain support activities need to be done and can plan pro-actively to resolve them to eliminate unnecessary issues. DataXstream also understands the need for process discipline, along with clear communication during an SAP lifecycle, and can assist you with putting such critical processes in place. When it comes to your support needs, DataXstream can assist in planning and vision, full post-production support, and adaptation of the support model as you respond to internal and external changes.

Upgrades

At some point in time, it may become necessary to upgrade your SAP landscape.  When that day comes, DataXstream can assist you.   DataXstream has been helping companies with SAP upgrades since 1998.  Consequently, we understand upgrades and the need to execute upgrades quickly and effectively to minimize disruption and ensure business continuity.   Our upgrade process involves understanding your technical and business environment in order to establish an approach that meets your business goals; assessing your existing infrastructure and doing a gaps analysis between what exists now and what is needed for the upgrade; and executing on the upgrade plan.  If it is in your company’s best interest, DataXstream can also virtualize your landscape before executing the SAP upgrade.

Initially the project team had the expected you-can’t-do-that reaction when the idea of a mid-month go-live was suggested.  We took three main steps to determine whether or not we were crazy or had a viable go-live option:

1. We asked SAP.  As one of the main participants on the project we got them to do an internal review with some platinum consultants with the objective of telling us why we could not go-live mid-month.
2. We asked our project team, both client and consulting resources.  Again, the goal was to tell us why we couldn’t do it.
3. We Googled like maniacs to find something to support and justify the conventional wisdom.  We failed to find anything substantial that would deter us.

Armed with the conviction that there was no reason we couldn’t go-live mid-month we set about defining the details of how we would pull it off.

Conventional Wisdom: Why You Don’t Go-live Mid-Month

My big disclaimer is that each SAP project has unique characteristics and what worked for us may not work for you, nonetheless I encourage you to keep an open mind and push until you find your insurmountable barrier, if it exists.  I would even contend that one of the biggest barriers may be your most experienced project team members and their gut reaction.  I admit my first reaction to the suggestion was “NO,” but as we drilled into the specifics of our project my inchoate objections crumbled.  The conventional wisdom is typically grounded in truth and experience, but conventional wisdom only applies to conventional situations.  To use a consulting cliché: challenge your assumptions.

In our research we found a consensus that there are three main areas that make a mid-month cut-over a bad idea.

Assets: I’m no expert on assets but the general word was that depreciation gets “messed up” if you cut over mid-month.  Owing to my limited experience in this area I’ll take that on faith, but this was not considered an issue as assets was out of scope for our project and asset postings will be done by journal entries.

Payroll: Again, I’m not an expert on payroll, but this was another situation where payroll was out of scope as the process is outsourced to a third party provider and journal entries are posted instead.  It was not considered a show stopping concern.

Year-to-Year Period comparisons: by cutting over mid-month some folks on the interwebs expressed concern that the month-over-month comparison for the go-live year would be no use until the third year.  Let’s say you go-live in the middle of June 2010 with partial balances in SAP (the remainder being in the legacy system), when June 2011 comes around you can’t compare the two Junes because one month is partial and one is complete.  You have to wait until June 2012 for a meaningful comparison.  This was not an issue for us because we converted three prior fiscal years of account balances with the go-live month balances being the balances as of the go-live date along with the transactional activity for the rest of the month.

Factors Leading to an SAP Mid-Month Go-Live

The ugly truth is that we went live mid-month out of necessity, not by choice.  Our original plan was to go-live on the first of the month, but we weren’t ready and a focused re-planning exercise identified that we could go live three weeks later.  Changing the go-live date to the first of the next month was not acceptable for a variety of reasons, including political considerations – it’s never a purely technical decision, so no surprise there.

Adapting the SAP Go-Live Strategy for Mid-Month Cut-Over

Once we knew we were going live mid-month we had to work out how to handle key areas of functionality: particular areas of interest were open A/P items, inventory balances, customer deposits, and the GR/IR account.  On top of this historical account balances needed to be loaded and we needed to ensure that FI conversions reconciled with logistics conversions.

Finance and Logistics Reconciliation

We came up with an approach that allowed us to readily identify differences between account balances converted by FI compared to the conversion by MM.  Consider the example of inventory conversion.

Standard SAP postings for the initial inventory balance with movement type 561 post to a pair of accounts similar to these:

• DR Inventory (135010)
• CR Conversion account (399175)

Instead of making this posting we changed the account determination for MM conversion to post as follows:

• DR Inventory (135010)
• CR Inventory conversion (135011)

Now when we converted historical balances into FI the inventory posting was:

• DR Inventory conversion (135011)
• CR Conversion account (399999)

The benefit of this approach was that any balance on the 135011 account meant there was a difference between what was converted via MM and via FI.  This became the basis of the work list that had to be reconciled.  The actual operational G/L account for inventory (135010) could be used immediately after the go-live without worrying about it becoming part of the ongoing reconciliation process.

Also, standard SAP does not allow direct posting to the inventory account (135010) and this approach allowed us to leave it as delivered.

We used a similar process, i.e. a conversion account instead of operational account, to support the cut over for accounts payable, customer deposits and the GR/IR account.

GR/IR Conversion

In our environment we are fortunate to have a situation where invoices are not received before the goods.  Consequently at the time of conversion there were purchase orders where goods have been received and not invoiced.  The typical GR/IR process is as follows:

Goods Receipt:

• DR Inventory (135010)
• CR GR/IR (211200)

Invoice Receipt:

• DR GR/IR (211200)
• CR Accounts Payable

At the time of conversion the good receipt has already happened and we did not want to reconstruct the PO processing so that we could use MIRO processing when the invoice is received.  Instead we converted historical balances for the GR/IR account by posting to a new account, 211201 as follows:

• DR Conversion account (399999)
• CR GR/IR conversion (211201)

Now when the invoices are received they will be posted with an FB60 transaction as follows:

• DR GR/IR conversion (211201)
• CR Accounts Payable

We know we are giving up some integrated capability for a period of time until these purchase orders and invoices wash through the system, but it means that once the GR/IR conversion account gets to zero we are done.  The typical life cycle for PO is 6-8 weeks so this is a temporary situation.  The true GR/IR account, 211200, will be used as intended and the benefits of MIGO and MIRO processing will be realized.

Month End Processing in the Old System

Going live mid-month also meant that the prior period was closed in the old legacy system and the month end balances were converted over in the same way as any other period.  It was a straightforward extension of our process to pull the mid-month account balances from the legacy system during go-live weekend and load them into SAP, too.

Financial Statement Impacts

The approach that we took meant we introduced several accounts to the chart of accounts for conversion only.  Consequently we had to update our financial statement versions to include these accounts and assign them to the correct positions in the report structure.  Clearly this is not a difficult task, but one that is needed.

SAP Mid-Month Go-Live Conclusions

I am skipping over some of the detailed considerations of how we made a mid-month go-live work for our project.  The details of how to make it work, the nuts and bolts of reconciliation, how we tested it (iteratively!), how we worked the differences identified between FI and MM/SD conversions, etc. aren’t here.  It wasn’t always easy and we had to do it in a short amount of time, but my key message is that we found a way to do it: the conventional wisdom wasn’t and isn’t necessarily wrong, just we found another path.

Is Your Project a Hotbed of SAP Consulting Clichés?

I felt compelled to come up with a 2-by-2 matrix to help you decide whether your project is cliché generator or a cliché consumer.

Here’s a chart to gauge your progress

This is your guide to see if your project vernacular has made it to cliché status or is too localized for such weighty titles.  The matrix should be self-explanatory, and if it isn’t, then it isn’t much of matrix.  But let’s cover the bases and check we’re all working off the same playbook:

• If the phrase is only used by a few people on your project you’ve got yourself a clique but you haven’t got a cliché
• If the phrase is in widespread use across your organization but strangers check for their keys and wallets when you say it in public you’ve got tribal knowledge and a clear boundary between understanding and bafflement
• If the phrase is used in lots of projects but only by a select group – perhaps those geeky developers who speak something that sounds like a cross between Fortran and Klingon – you’ve got the beginnings of a cult going on (I appreciate you geeks, but I’m not sure my mother wants to meet all of you)
• If you hear the phrase everywhere and everyone knows what it means you have achieved nirvana: cliché status is yours to behold!  Jolly well done, splendid, attaboy!

What Does That Mean?

Here is a handful clichés submitted to me recently along with a short explanation of what I think they really mean.  If these aren’t familiar please do you best to over use them so that they do become clichés.

9 women can’t make a baby in a month

Translation: You have critical path issue on your project.  Assigning additional resources to the task isn’t going to help.  Better resources, perhaps.

This is an aggressive timeline

Translation: Get ready to develop a new plan.  An aggressive timeline usually assumes perfect execution, code is good, configuration is good, users are trained, security and authorizations are good, interfaces are good, master data conversion is good, transactional conversion is good, backup and restore is good, and everything works together flawlessly, without a hitch.  Or at least it will once we get through this exercise with no, well maybe minimal errors and rework.

This doesn’t work the way the old system does

Translation: I agree, it doesn’t work the same way as the old system.  It’s SAP and it works differently.  If it was supposed to work the same way as the old system it wouldn’t be SAP.  Now tell me again, why did your company choose to implement SAP?

That’s not what I wanted

Translation: But it is what you asked for.  In defense of the speaker I think it is very difficult to describe what you want in a clear and complete manner and very few people are good at distinguishing between what they want and how they think it should be delivered and operate.  Nonetheless on ERP projects there is always a tendency to want to make that Buick into a Bentley despite the fact that both vehicles can get you to your destination.

This is working as designed

Translation: The design is broken.  A fork is a good implement for eating some foods, but not all foods.  Is a spork the result you were looking for?

Let me get back to you on that

Translation: a) I have no clue, b) let me look on http://help.sap.com, c) I don’t understand what you’re asking, d) that makes no sense to me, e) why would you want to do that?  But seriously, this is consultant speak for I have no idea how to answer that question.  The good consultants figure it out and get back to you whereas the bad ones just hope you are too buried to remember to ask that question again.  You know pretty quickly whether you have good or bad consultants.

The End of a Humorous Interlude

I hope I managed to bring a smile to your day as you read this and the previous post – perhaps your assistant printed it so you can read it on the plane as you fly home from another week of project execution optimization driven by paradigms harnessed by unconventional quantum leaps into new challenges that seek to maximize ROI.  That won’t be a cliché any time soon, but the individual components are probably already active on a project near you.

Thanks for indulging me.

One area in which businesses can make improvements to reduce waste is in Virtualization.  Eddie White, Sr. VP with Sentilla, noted that data centers account for 2% of the power usage in the United States.  In addition to actual hardware costs, the cost of power to the data center, power drawn by the servers and power used in cooling, can be reduced by 25% through efficient use of hardware and through virtualization.

In addition, virtualization allows a business to “sweat the assets it already has instead of adding new ones.”  Through smart virtualization a CIO can delay the need for a new data center, which can cost in the area of 10 million dollars.  White noted that IBM’s data center accounts for 6% of the company but utilizes 30% of the company’s power usage.

Stezler stated it simply.  “Virtualization has a huge impact.”  SAP was 60% virtualized servers in 2009 and the goal for 2010 is 80% virtualization.   In more detail Stezler notes that Energy Management is a new challenge for IT.  In recent studies 50% of clients and investors state energy efficiency and carbon footprint are among deciding factors when making consumer or investor decisions.   The data center is typically 30% to 40% of energy cost associated with any business.

With this in mind DataXstream offers virtualization services as part of our SAP integration focus.  DataXstream is a certified partner with Dell and has also partnered with VMware the global leader in Business Infrastructure Virtualization.  These partnerships allow DataXstream to streamline the virtualization process as well as allow excellent pricing options.

In each session Timo Stezler advocated, “Become a strategic Sustainability advisor to your business.”  Work to streamline efforts within your business.

For more information on Virtualization:

SAP Virtualization Solutions:  http://www.dataxstream.com/products-services/sap-virtualization-solutions/

SAP AIO Virtual Infrastructure: http://www.dataxstream.com/sap-aio-virtual-infrastructure/

For more information on Green IT within SAP:

Green IT blogs on SDN https://go.sap.corp?Green-IT-blogs

SAP Green IT Community: https://go.sap.corp/GIC

SAP Sustainability Report: http://www.sapsustainabilityreport.com

Why the data will not load correctly.

There is a litany of reasons why some data records will load correctly while others will not.  Here is a list of some common root causes:

1. Poor quality legacy data.
   Legacy systems which are not as tightly integrated as SAP, and are not under master data control allow the end user a bit of freedom when entering data.  A zip code may contain too little or too many characters; the email address is not properly formatted; numeric fields have transposed digits; various forms of abbreviations (especially in the city field), a quantity of zero (0) permitted by the legacy system and uploaded into a field where SAP will not accept a quantity of 0 and even simple misspellings  all can cause stringent validation checks to trigger an error and prevent the record from loading at all.  A more sinister type of error occurs when the data is functionally incorrect, but good enough to pass all of the SAP validity checks.  In this case, the data record will technically load into SAP, but will not be functionally correct.  Duplicate customers, duplicate vendors, and the data entry error for a quantity of 1000 instead of 100, and the wrong pricing condition applied to a sales order line are examples of this scenario.

1. Functional configuration and supporting data effects.
   Many times I have watched the load statistics for a data object plummet from near 100% in the cycle two test load to near 0% in the cycle three test load.  This is very unnerving to the client because the cycle three test load is getting rather close to the go-live date, and “by the way, shouldn’t the statistics be getting better rather than worse?”  Functional configuration changes can wreak havoc on any data load.  Flipping the switch on a data field from optional to required; turning on batch management or serialization for materials for the first time; changes in the handling of tax, tax codes, and tax jurisdiction codes; that account determination entry that is missing or not set up correctly; a missing unit of measure or unit or measure conversion factor; the storage location in the upload file which does not exist in SAP – any of these can cause a load to drop mostly or completely onto the floor.While change is inevitable on any project, it is important to control and communicate the change so that the downstream impact can be recognized and understood.   Controlled change and communication always works better than total surprise.  Perhaps if we all know ahead of time about that data field that is now required, we can impose a requirement on the data extract side to make sure that the data field is populated before it enters the upload file. 
2. Additional data in the upload file.
   Inserting a new field in the middle of the upload file data structure might be necessary for the business to close a gap, but if that change is not communicated to the technical team so that appropriate adjustments can be made to the load object’s input structures and processing logic, the new data will surely never load, and may cause misalignment of the data fields which follow it in the upload structure.

The Finger Pointing Game

It’s the load program!  No, it’s the data!  No, it’s the configuration!  No, it’s … (fill in your favorite finger pointing game excuse explaining why data will not load).

If you ever find yourself in the midst of this type of finger-pointing game, immediately stop the madness.  For this and similar situations, I apply a simple litmus test which has never failed me yet – manually enter the EXACT upload data into SAP for the transaction which has failed.  If one can be entered manually, then the program will be able to automatically load thousands with similar upload data and functional configuration.

I have lead many a functional analyst – kicking, screaming, and ranting about how terrible the load program is – to the terminal to play “let’s enter one manually”.  Typically, the result is that one cannot be entered manually due to configuration issues or the lack of supporting values data.  Once these issues are cleaned up, the load program “magically” begins to process thousands of records with no trouble at all.

Sometimes, the load object appears to be the cause, but is not the root cause.  The important data item not being handled by the load object (which was not called out in the functional specification document), the data item which turns blue (because the functional specification document explicitly stated “put this data item into the blue category”), the formula which is not calculating the desired result (but is indeed the exact formula found in the functional specification document) – all are examples of the load object adhering accurately to an incorrect functional specification document.  The root cause, then, is the functional specification document which must first be revised and checked into the controlled document repository before making any code modifications.

It’s the Program

Well, OK, sometimes the load object is at fault.  But it is extremely rare.

Collecting and Reporting the Technical Load Statistics

Load statistics are an important technical metric, indicating what percentage of the upload file has successfully posted a transaction into SAP.  This is a basic and simple record count check.  How many records were presented in the upload file, how many records posted successfully to SAP, and how many records failed to post.  Also, does the number of successful transaction plus the number of failed transactions equal the total number of records presented in the upload file.

Here is how I communicate this technical metric:

This technical metric indicates only that all of the SAP validation rules for posting the transaction have passed.  It does not indicate that the master or transactional data posted to SAP is actually correct in functional terms.

The Functional Review

It is very possible for an entire upload file to technically load at 100%; while at the same time, functionally fail at 100%.  The customer may be missing a partner, the material or article may be categorized incorrectly, the pricing conditions on a sales order may not have the desired validity date range, the GL posting may be to the wrong accounts.  Hence, the need a functional review and validation of the data transacted into SAP.  The data type – master or transactional – determines the type of functional review and metrics to be employed here.

For master data, such as of materials, customers, vendors, etc., it is impossible to individually validate the many thousands of entries in your SAP system.  But statistical methods can be employed which will guide you through a random sampling of the data, while at the same time assuring accuracy at a high degree of confidence levels.

For transactional data, such as inventory, open sales orders, open AR, etc., direct mathematical comparisons can be employed.  On a grand scale, if an inventory value of $15,246,321.44 is being moved from your legacy system to SAP, then that exact amount must arrive in SAP when the migration task is complete.  It may be a bit more difficult to do this mathematical comparison at a more granular level.   If, in the move to SAP you are also redesigning your material/storage location combinations, a direct comparison between the legacy system and SAP may not be possible without a translation factor.  The same scenario exists if you redesign your GL chart of accounts, where one legacy GL account now maps to several SAP GL accounts, or vice versa.

Reporting the Fallout

If an automated data load was not technically 100% successful, a clear set of error messages complete with a link back to the legacy data must be mined, formatted, and presented to the business for analysis.  Such a report really helps to facilitate the fallout cleanup.  The link back to the legacy data must be carefully designed into the load process to make sure that, for example, the legacy customer number, legacy vendor number, legacy sales order number, legacy purchase order number, etc. is included as part of the data being handled.  Without the link back to the legacy data, it becomes very difficult to identify which data record needs to be fixed.

The error message mining technique that I use depends on the load method.  I will describe two here – one for a BDC load method and one for an IDOC load method.

Mining Meaningful Error Messages from a BDC Session Log

At the completion of a batch input session, the batch input session overview screen (SM35) displays the technical load statistics.  In this example, out of a total of 229 transactions, 13 failed and 216 succeeded.

The session log shows the status of all 229 transactions.  This screen snapshot is a fragment of the complete session log for the batch input session.  It shows many successful transactions (Type = S) and one failed transaction (Type = E).  The error message here is clear – the article does not exist or is not activated.

But as you can imagine, the 13 failed transactions with error type = E are sprinkled throughout the many pages of this log file.  With only 229 transactions, this log file is quite easy to pick through to find the 13 errors.  But imagine if the number of transactions were in the thousands or tens of thousands.  How do we extract only the failed transactions and present a concise report of the failed transactions?

To do this, I use SAP transaction SM35P – Batch Input Log Overview.  This transaction has the ability to set a filter on any field in the batch input log file, display the filtered results, and then to export the results to a local file.

To enter the mode where this is possible, first press the PRINT icon.

Next, set the filter.  The appropriate filter field here is SESS. TYPE.

We only want the errors, so set the filter for field SESS. TYPE = E.

The display now shows only the 13 rows containing the error messages.  This can be exported directly to a local spreadsheet for further analysis.

Mining Meaningful Error Messages from IDOCs

Depending on the IDOC and the processing module, mining the error status messages from IDOCs can be very easy or somewhat challenging.  For the more difficult scenarios, you probably will need to hone your EXCEL skills to properly join several extracts together into one complete picture.

When creating IDOCs with a load object, I always note the date, time, and IDOC basic type.  I will use this information as the selection criteria for transaction WE05, which is going to locate the IDOCs and display the results information I need after the IDOCs are processed.  The results that I usually collect are the error status messages, and some data content from a segment or two to illustrate exactly where the problem is in the legacy data.

While the background job is busy processing the IDOCs, I usually take a peek, using transaction WE05, to see how the load is progressing.  If I see that most of the IDOCs are falling onto the floor (IDOC status 51) rather than moving into the database (IDOC status 53), I usually stop the background job and begin an immediate analysis of the fallout.  If the fallout solution does not require a change to the IDOC data content (e.g. a configuration change), then I can replay the fallout using SAP transaction BD87.  If the fallout solution does require a change to the IDOC data content, then the complete set of IDOCs must be regenerated again.

Let’s see what WE05 can tell us about a completed Article Master load.

On the WE05 screen below, we can see that of the total of 14,005 IDOCs, 11,412 have processed successfully and 2,593 have failed to process.  By double clicking the Status 51 folder, the display will show only the Status 51 IDOCs – the fallout.

By pressing the “status list” icon (shown above), the display will show the status messages for the fallout.    Once these messages are displayed, pressing the “export” icon allows me to save the screen contents to a spreadsheet.

Now it would be really nice if I could have the article number in the spreadsheet right next to the error message.  The article number in the ARTMAS IDOC is stored in segment E1BPE1MATHEAD.  The segment content for each IDOC can be displayed by pressing the “list specific segment” icon and entering the segment name in the box.

The segment display will show all fields in the segment, so I usually hide all of the columns that I don’t want to see.  Here is the E1BPE1MATHEAD segment display showing only the article number.  I can use the export icon to save the list of article numbers to another spreadsheet.

Here is a portion of the complete spreadsheet showing the error messages and the article numbers side by side.

A filter applied to the spreadsheet shows that the 2,593 errors are all grouped into one of three error status categories.  By selecting a single category, Excel will also show me the number of records within that failure category.

Sometimes it is easier to mine the status messages directly from the IDOC status table EDIDS.  This is especially true where the processing module is a BAPI which returns an error table rather than a single error message.  In this case, when you press the “status list” icon in WE05, only the first error status message of several is displayed for each IDOC.  I find that the first message is not very helpful (as shown below).  I also find that typically the second or third message in the return status table is usually the important one.  You won’t see it displayed on the WE05 screen, but you can mine it from the EDIDS table.

SAP transactions SE11 or SE16 both support this activity.  For the selection criteria I use the IDOC number range, status 51, and status type E.  On the display screen, choose only the relevant fields for display – the IDOC number (DOCNUM), IDOC status (STATUS), status message (STATXT), the four substitution parameters for the status message (STAPA1, STAPA2, STAPA3, STAPA4) and the message type (STATYP).  All of this can be exported into a spreadsheet.  If you really want to test your Excel skills, you can write code that will move the substitution parameters into their placeholders in the status text.

Preparing for the next data migration cycle – Let the fallout analysis and cleanup begin.

Presenting the fallout report to the business with a set of clear error reasons and links back to the legacy data is key to enabling the legacy data cleanup process to proceed.  In the iterative process of data migration cycles, cleansing the legacy data is a step in the right direction towards an improved next conversion cycle.

I hope you enjoyed this blog series on data migration.  Please feel free to send comments or questions.

Service Desk functionality is delivered to you for use as a ticketing system.  One of the features of it is that it can be used as a ticketing system for both SAP and non-SAP systems as well as in conjunction with other ticketing systems that may be in place already.  In this blog post I’ll briefly touch on some of the scenarios I have encountered and show that there are several ways to deploy Service Desk.

Using Service Desk is beneficial because it can automatically capture a wealth of information about what a user was doing when a problem occurred if the ticket is created directly from SAP.  Also, Service Desk can communicate directly with the SAP mother ship to log issues and manage OSS notes which obviously reduces the risk of transcription errors.  And Service Desk can be extended to include functional components from non-SAP systems which in turn leads to the possibility of one-stop-shopping for ticket management.

Here are some SAP Service Desk scenarios I’ve come across.

New SAP Installation

If you are a new SAP installation and have no ticketing in place Service Desk is a great place to start.  As mentioned the functionality available allows end users to create tickets directly from SAP and have workflow set up to manage ownership and eventual resolution.  Alternatively, a URL can be made available to allow trouble tickets to be logged via the SAP Service Desk web front end.

In this case end users and technical support personnel learn a new tool as part of their go-live experience.

Migrating Non-SAP System Support to SAP Service Desk

Rather than SAP being your sole IT application it is much more likely that you have an existing portfolio of systems and an associated ticketing tool and procedures for ticket management, escalation and resolution.  A conservative approach when bringing up Service Desk is to use it initially only for SAP related tickets and deploy a limited set of functionality.  This allows you to go through the growing pains and adjustments as you learn how to best make Service Desk work for you.

In the longer term migrating ticketing for non-SAP systems to Service Desk brings it all into one system.  Using the Service Desk capability to create custom components and to build an organization structure that fully supports your users and systems facilitates consolidated reporting and the ability to monitor Service Level Agreements (SLA).

This approach works best if you have a fairly simple environment where the level of disruption is limited when decommissioning an existing ticketing.  The impact on people, process and technology is carefully managed and the working environment has some tolerance for the time if and when things aren’t quite as expected at first.

SAP Service Desk Integration with an Existing Ticketing System

In situations where there is a well established ticketing system it is unlikely that that system will be easily displaced by SAP Service Desk and it may not make sense to do so.  In this situation you can choose to not use Service Desk and forgo the system capabilities and instead use the existing ticketing tool to manage SAP issues.  This gives up a lot of delivered SAP Service Desk capability.

Alternatively you can integrate the existing ticketing system and Service Desk and reap the benefits of both worlds.  In this case you need to decide which system is the primary ticketing system and which is the secondary.  DataXstream has worked with CA (formerly known as Computer Associates) to integrate the CA Service Desk offering with SAP Service Desk and now CA delivers a packaged solution for this integration.

SAP Service Desk is the Ticket Initiator

In the scenario where the SAP Service Desk (SAP SD) is primary tickets are initiated in SAP SD and categorized either as SAP related or as non-SAP related.

SAP related tickets are managed to resolution in SAP SD, including any communication with the SAP mother ship, and the secondary ticketing system, e.g. CASD, receives only informational updates on ticket progress, if required.  The complete ticket lifecycle is managed and closed in SAP SD.

Non-SAP related tickets are transferred to the secondary ticketing system, e.g. CASD, where they are worked to their resolution.  In this case ticket status changes and informational updates all occur in CASD and these updates are relayed to SAP SD.

In either case SAP SD and CASD can have a full picture of the ticket status throughout its lifecycle, the main difference being which system “owns” the ticket and has responsibility for working it and closing it out.

Overall the established ticketing system continues its original function and ticket resolution process, the key change being where a ticket is initially created.

SAP Service Desk is NOT the Ticket Initiator

In the scenario where SAP SD is the secondary ticketing system SAP-related incidents originate in the primary ticketing system, e.g. CASD, and are relayed to SAP SD.  Now the SAP related incidents are worked in SAP SD where ticket information can be supplemented with all the SAP unique information that would be useful for analysis and investigation.  Similar to the earlier scenario any significant status or informational updates in SAP SD are relayed to CASD and the ticket is ultimately closed out in SAP SD.

Any non-SAP related tickets are not sent from CASD, for example, to SAP SD.

A Natural Progression: from Island to Integration

SAP Service Desk can be deployed in a variety of ways in an organization: it can be a standalone ticketing and support system; it can be fully integrated with existing support applications.  The role played and the pace of adoption is very flexible and is driven by an organization’s ability to manage the change and adopt new tools and procedures.

The general progression I have seen is to bring up SAP Service Desk as a standalone tool and then after a settling in period one of two things happens:

• Existing ticketing tools and functionality are migrated into Service Desk
• SAP Service Desk is integrated with another ticket management tool

In either case the outcome usually allows SAP related tickets to be created directly from SAP in order to capture as much detail as possible at the time of the incident.

Before you embark on your project’s first data migration test cycle, your data migration plan will probably start out as a simple list of preparation steps, data load dependencies, and cleanup steps.  As you progress through your several data migration test cycles, your plan should evolve into a rather complex list containing load methods, responsible persons, historical data volumes, historical execution times, steps that need to be modified and additional steps that need to be added.

I always find it rather interesting to compare the very first plan to the plan that is actually used in the cutover process.  Many project factors will cause you to amend your data migration plan.  Newly-discovered gaps, changes in the business requirements, the decision to load all of the legacy customers instead of only those customers which have been active for the past two years, and toggling back and forth between “should this one be a manual or an automated load” are only a few.   Always keep in mind that the goal in amending the plan is to keep it compatible with the changing requirements of the project.

The Data Migration Preparation Phase

Before you actually start the data migration main course, you will probably want to execute a series of preparation steps.  Some of these preparation steps may have a significant lead time; while others may require a system reboot to take effect.  Make sure that you carefully plan accordingly.  Here are some data migration preparation steps that I have found useful:

• Obtain a Data Migration Login
  Obtain a special data migration login, with all of the authorizations needed to execute all of the required tasks.  This login is only to be used during the data migration process, and is to be deleted upon the completion of the data migration process. Using the data migration login makes identification of migrated data very easy both now and several years down the road.  It also facilitates implementing a general user lockout while the data migration user is performing data migration activities.
• Technical client preparation
  The BASIS team may want to configure the data migration target client to have less dialog processes and more background and update processes.  This configuration can significantly improve data migration performance, especially if you have the opportunity to parallel process IDOCs.  In a Virtual Machine environment, the infrastructure team can even provision additional processors and memory.  You may also need additional disk space to handle large upload files, and any intermediate files that a load program might need to create.
• Configuration for IDOC processing
  If a data migration process involves creating and processing IDOCs, you may need to configure the ports, partner profiles, message types, and processing modules.  My preference for IDOC triggering is by using the ABAP program RBDAPP01 rather than immediate triggering.  This allows me to exercise the most scheduling control over the background processing options.
• Change Pointers
  During a data migration turn off change pointers.  Creating what could potentially be hundreds of thousands of change pointer records that are never going to be processed is an overhead burden on system performance and disk space that you do not need.  If the migrated data needs to be sent to external systems, manually send the data after the data migration is complete.
• Set the Correct Open Posting Period
  Some of the transactional data will want to post into an open financial or manufacturing posting period.  You will want someone from the business to make sure that the correct posting periods are open for business.
• Configuration Settings
  Sometimes, special temporary functional configuration settings are made to facilitate the data migration process.  Several functional analysts may be responsible identifying and setting these prior to the start of data migration.  As these are temporary configuration settings, it is expected that they will be set to their production values after the data migration is complete.
• Basic Setup Data
  Some data migration objects are dependent on reference data – a template from which new data migration objects can obtain some of their default values.  You will want to make sure that those who are responsible for setting up this reference data have completed their task before you start the actual data migration.  Sometimes this data is moved from the Golden Client into the target client via ALE, so you may need to set up RFC destinations, ports, distribution models, etc.
• General user lockout
  All users except for the data migration user should be locked out of the data migration client during the actual data migration activity.  It is impossible to verify that we moved exactly $15,386,254.23 in inventory from the source system to the target system if users are performing material movements in either system during the conversion.
• Connections to External Systems
  Depending on what connections to external systems are doing, you may want to make sure that they are disconnected prior to the start of data migration.  This will ensure that inbound interfaces, which may either modify existing migrated data or add new data, are disabled.

The Data Migration Phase

When all of the preparation steps are complete, it is time to start the actual data migration.  Data must be loaded into the target system in a certain sequence that is dictated by their data dependencies.  Customers must exist before sales orders can be migrated, vendors must exist before purchase orders, materials must exist before either sales orders or purchase orders, etc.  This dependency exercise varies a bit from project to project, and should have already been determined well before you start loading the data.

Automated data migration tasks for a single object (e.g. customer master data) usually include some or all of the following:

1. Creation of an upload file from the source system
2. Technical validation of the upload file
3. Functional validation of the upload file
4. Execution of a technical object to load the data into the target system
5. Technical validation of the migrated data
6. Functional validation of the migrated data
7. Collection and reporting of load statistics
8. Analyzing the fallout
9. Correcting the fallout
10. Reprocessing  the fallout

Checkpoints

At a higher level, the data migration plan will string together an end to end list of all of data migration objects.  I strongly suggest that you study the list and judiciously intersperse several checkpoints at appropriate places in the plan.  A checkpoint is an activity where all interested parties meet to review status and metrics, and to determine whether or not to proceed forward.  Keep in mind that what fails to load early in the plan will geometrically cascade into larger fallout later in the plan.  That single vendor which failed to load may cause several hundred open purchase orders to also fail.  And while the business owner of the vendor master data may think the fallout of a single vendor to be quite insignificant, the business owner of open purchase orders may have an entirely different perspective.  It is important here to make sure that all of the right stakeholders are participating, and that all are in agreement about whether or not to proceed.

Backup or Restore Points

Another activity that you should judiciously sprinkle into the plan is several backup or restore points.  It is very painful to have successfully navigated seventy-five percent of the data migration plan, only to have the next load create a huge and unrecoverable mess in the target system.  Without a backup or restore point available, you may have to wipe the slate clean and restart the entire data migration process again.

Depending on the target system and the facilities available, the backup or restore point could be a full system backup, a client copy, or a virtual machine snapshot.  Whatever the means, make sure it is a part of your plan.  It’s really great if you don’t need it.  It’s also really great to have if you do need it!

The Data Migration Cleanup Phase

When the data migration loads are finally complete, it’s time to exercise a series of cleanup steps.  This is where we:

1. Undo the special temporary settings and configurations that were done prior to the start of the data migration activity.
2. Adjust the technical configuration of the system to a more user-oriented system with the right amount of dialog, background, and update processes.
3. Turn change pointers back on.
4. Allow the general user population to access the system.
5. Connect the system to its inbound and outbound communication partners.
6. Disable the data migration user.
7. Archive those massive upload files.
8. Delete any intermediate processing data files.
9. Clean up the IDOC tables if needed.  But first make sure that you do not need to keep the IDOCs  for legal reasons.

An Example Data Migration Plan

Click on the link below to access an example data migration plan.  This plan is not a complete data migration plan, but is intended to demonstrate format and content.
Sample Data Migration Plan

Stay tuned!

In part 3 of this series on Data Migration, I will be discussing how to deal with fallout from automated data loads.