DATA MIGRATION METHODOLOGY FOR SAP VERSION 2.0 Data Migration Methodology for SAP version 2.0 By Christian Bergeron (cvcby@yahoo.com) This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License Data Migration Methodology for SAP PAGE 2 NO TIME TO READ! … THE METHODOLOGY ONE-PAGER The origin of the methodology I started by analysing previous migrations, looking at what worked and what did not. After, I followed an ongoing migration, working in real time with the team and, as issues occurred, we used the “5 Whys” approach to find the root cause of each issue and see how to avoid it next time. The result was a set of ground rules, permitting to avoid issues by working on their causes. The ground rules These are the ground rules around which the methodology was built: 1. Start by understanding SAP … Than see what is to be taken from the legacy system 2. The migration must be integrated with the functional analysis … As most migration issues are linked to functional choices 3. Key Users may not be familiar, or comfortable, at writing conversion rules or specifications … The format used to write rules is kept simple, clear and easy 4. Each Business Object must be owned by a Key User (supported by a business analyst) … Who is responsible for writing the conversion rules and accountable for their accuracy 5. Define which fields you need in SAP before going into any conversion rules ... As Key Users must first understand the fields purpose and impacts on the SAP process 6. Conversion rules must be written … So everyone involved in the project can read them and agree on it 7. Do not start any programming for a Business Object before you have a complete set of clear rules for all fields … A clear understanding between the functional and the technical teams will avoid many time consuming issues. The rules in action In order to clearly document the conversion rules, the functional team must question and understand the purpose of each SAP field, thus requiring them to better understand the SAP process itself. Since most of the conversion issues are linked to customizing and functional choices (or omissions), some questions raised while digging to document the conversion rules will reveal these pitfalls, which might otherwise come up only toward the end of the project. This synergy of conversion rules and functional analysis, permitting to identify and resolve potential issues before they occur, will yield a much faster and stable conversion AND functional/customizing process for the following steps. The “AND” is key here, conversion will boost functional/customizing and vice-versa, this is where we get added value. How to make it work? The whole process of this methodology is designed as building blocks, were each step if the foundation on which the next one is built. I also used the “Lean” approach, so everything that is not necessary is removed, everything that is left is necessary. What makes it work is the systematic application, of each step of the methodology, for all Business Objects. No silver bullet There are no technological gadget or revolutionary methodology to make it effortless, but some paths are easier than others. This methodology has proven to be the shortest path, to achieve a 100% accuracy, in data migration of many ERP implementations. Data Migration Methodology for SAP PAGE 3 ABOUT THIS DOCUMENT Goal of this document This document describes a methodology for data migration I used successfully, in different implementations of SAP in a manufacturing environment. It is base upon my previous experiences. All the templates are derived from models I used in specific implementations in the manufacturing industry and may come from older version of SAP R3. It most probably will not be 100% adequate for your use. It is a base to help you build your own template. You can start from them, but do not take for granted everything is there. Although this methodology was done for specific SAP implementations, the same approach can be used in other ERP implementations, as the challenges and issues of data migration will be similar. Version 2 Version 1 was published in 2003. Version 2 consists of texts corrections and revisions. The methodology itself is the same. The templates found in “APPENDIX A” are the same as in version 1. Whom is this guide for? 1 Section 1 is for every one involves in the data migration process. 2 Section 2 is for the project manager and the data migration manager 3 Section 3 is for the data migration manager and the members of your team responsible of converting Business Objects, both technical and functional. Data Migration Methodology for SAP PAGE 4 TERMINOLOGY AND ABBREVIATIONS Note: The terms SAP and R/3 are both use interchangeably to refer to SAP R/3 system. Big Five: When referring to the Big Five, it means Material Master, Customer Master, Vendor Master, Bill Of Materials (BOM) and Routings. Business Objects: To help in the analysis and transfer process, the data are not treated as tables or field contents but rather as objects in term of business operational. These are called Business Objects (Ex: Material Master, Customer Vendor …) Business Object Owner: A Key User responsible of the conversion process for a specific Business Object (Legacy data source and integrity, mapping, conversion rules, etc.). Business Object Stakeholder: The one owning the information in the every day business. This person will make the strategic choices on functional requirements for the Business Object and the final validation of the converted data. The Business Object Stakeholder can be identify by finding “the highest hierarchical person who will be directly and mostly affected if the Business Object does not work” Conversion table, Cross reference table, Transcodification table, or X-Ref table: A table that shows the relation between fields when one value is related to a parent field. For example, the "Sales Organization" will be set accordingly to the material type. Data Conversion & Data Migration: The data conversion process. “Data conversion” and “Data Migration” terms are used interchangeably in the document. DC: Abbreviation for the Data Conversion process. Domain: Functional domain within the project, like Finance, Sales, Production, etc. Flat File: A common file format used to import data into SAP. Functional team: A Key User owning the Business Object and one (or more) business analyst. LS: Abbreviation for Legacy System LSM or LSMW: Legacy System Migration Workbench. It is a SAP tool to convert and load the data extracted from the Legacy System. WBS: Work Breakdown Structure. Data Migration Methodology for SAP PAGE 5 TABLE OF CONTENTS NO TIME TO READ! … THE METHODOLOGY ONE-PAGER ................................................................................... 2 ABOUT THIS DOCUMENT................................................................................................................................................. 3 TERMINOLOGY AND ABBREVIATIONS ....................................................................................................................... 4 SECTION 1 - INTRODUCTION TO DATA CONVERSION ........................................................................................... 7 1.1 INTRODUCTION ..........................................................................................................................................8 1.2 DATA CONVERSION GUIDELINES ........................................................................................................12 1.3 Overview ..................................................................................................................................................8 Bases from which this methodology was made ........................................................................................8 Concept VS techniques .............................................................................................................................9 A few facts ................................................................................................................................................9 Conversion rules and Business Object ownership ....................................................................................9 Main steps of the conversion methodology ............................................................................................ 10 Where you will, for sure, have a timing problem ...................................................................................10 There is no such thing as a free lunch .....................................................................................................11 Think SAP ..............................................................................................................................................12 Prepare the Legacy data .......................................................................................................................... 12 Before the last test run, take into account the customizations of your new system ................................ 12 Reduce the amount of historical data to be transferred ...........................................................................12 Prefer the use of control reports..............................................................................................................12 Small is beautiful ....................................................................................................................................12 Play it safe ..............................................................................................................................................12 SUGGESTED ADDITIONAL READINGS.................................................................................................13 SECTION 2 - ORGANIZE THE DATA CONVERSION ................................................................................................ 14 2.1 OVERVIEW .................................................................................................................................................15 2.2 DATA CONVERSION PLAN ..................................................................................................................... 16 2.3 WBS ( WORK BREAKDOWN STRUCTURE) .......................................................................................................19 2.4 Business Objects .....................................................................................................................................16 Data type.................................................................................................................................................16 Required information to complete the conversion plan ..........................................................................17 Main Business Objects sequence of conversion ..................................................................................... 18 Why a WBS? ..........................................................................................................................................19 How to ....................................................................................................................................................19 Suggested WBS content for data conversion .......................................................................................... 20 Are you sure? ..........................................................................................................................................20 Request to re-evaluate your WBS...........................................................................................................21 Facts to consider in you work estimate ...................................................................................................21 Ballpark figures ......................................................................................................................................22 A formula to help …. Handle with care..................................................................................................22 CALENDAR PLANNING ........................................................................................................................... 24 Overview ................................................................................................................................................24 MS-Project or not. ..................................................................................................................................25 Sequencing the tasks ...............................................................................................................................25 Data Migration Methodology for SAP PAGE 6 Key Users and consultant availability to work on Master Data .............................................................. 25 End 'at best' VS 'most probable' ..............................................................................................................25 Are you sure? ..........................................................................................................................................26 Workload analysis ..................................................................................................................................26 SECTION 3 - CONVERTING A BUSINESS OBJECT ................................................................................................... 27 3.1 OVERVIEW .................................................................................................................................................28 Before you begin. ...................................................................................................................................29 Documentation of your work (mapping sheet and conversion rules) .....................................................29 3.2 DATA PURGING AND CLEANSING ........................................................................................................29 3.3 MAPPING AND CONVERSION RULES ...................................................................................................29 About the rules .......................................................................................................................................30 The Material Master challenge ...............................................................................................................31 All other Business Objects ..................................................................................................................... 35 Business Objects conversion rules examples .......................................................................................... 36 Directory organization ............................................................................................................................ 38 Change management: working in batch mode ........................................................................................ 38 Version management of conversion rules ............................................................................................... 39 Murphy's protection: Save it often and do rolling backups. ...................................................................39 3.4 EXTRACT AND LOAD PROGRAMS .......................................................................................................40 3.5 TRANSFORMATION BETWEEN THE EXTRACTION AND LOAD ..................................................... 40 3.6 DATA AND RULES ADAPTATION .........................................................................................................40 3.7 LOAD UNIT TESTING ............................................................................................................................... 41 3.8 EXTRACT & LOAD – FULL SIZE TESTING AND DATA VALIDATION ............................................41 3.9 ACCEPTANCE SYSTEM FULL LOAD ....................................................................................................41 3.10 PRE-PRODUCTION AND PRODUCTION LOAD & SIGNOFF .............................................................. 41 3.11 SUGGESTIONS ON THE DATA CONVERSION LANDSCAPE............................................................. 42 CONCLUSION ..................................................................................................................................................................... 43 APPENDIX A – VARIOUS TEMPLATES ........................................................................................................................ 44 1 - Conversion plan template.doc ...........................................................................................................44 2 - WBS template.xls .............................................................................................................................. 44 3 - Material Master - Fields selection sheet template.xls ........................................................................44 4 - Data conversion specification - Generic template.doc ......................................................................44 5 - Data conversion specification – BOM template.doc .........................................................................44 6 - Data conversion specification – ROUTING template.doc ................................................................ 44 7 - Materials Classes and Characteristics structure.ppt ..........................................................................44 APPENDIX B –LICENSE ................................................................................................................................................... 45 Creative Commons Attribution-ShareAlike 4.0 International Public License ........................................45 Data Migration Methodology for SAP SECTION 1 - INTRODUCTION TO DATA CONVERSION PAGE 7 Data Migration Methodology for SAP 1.1 PAGE 8 INTRODUCTION Overview Implementing SAP is an important challenge, both in terms of resources as on business process impacts. A lot is at stake and failure is costly. To put all odds on your side, you need a good methodology, providing realistic planning, solid organization and a way to control the migration process so you can detect and correct slippage before it becomes a problem. An important part of this challenge will be the data conversion. Previous implementations of SAP have shown that data migration can amount up to about 40% of the entire project. Poor data conversion will make your “Go Live” very difficult, if not impossible. This guide is aimed at helping you organize the data conversion process, which in turn, will lead to a successful implementation. Bases from which this methodology was made When I was originally asked to come up with a data migration methodology, I started by analyzing passed experiences, where I found the following recurring problems: While the project is going on: There are many things being worked on at the same time. Yet, most of them are not progressing. There are documents all over the place and, somehow, they always seem to be outdated. Data loaded is regularly incomplete and inconsistent. Functional changes are not impacted on the conversion rules. Data previously loaded with success are suddenly rejected by SAP. There is a lot of misunderstanding, friction and frustration between the functional and technical teams. At Go Live Master Data deadlines where constantly busted and production load is done in ''rush mode' at the last minute. Some key parts of the data cannot be loaded in production. Patches are applied to the Master Data in order to force-load. Some data will not get in at all, they will have to be entered after Go Live. After Go Live Some Data need to be corrected and entered after Go Live. Because the production system is living, data are constantly changing, making the “catching up” on data integrity a moving target. This makes the process difficult and time consuming, which translates into costly operations and possible business errors. After discussing with people who lived these situation (manager, functional and technical), we identified the following causes: Planning and resources load estimates where way out. Most problems encountered are functional issues, which where overlooked or classified as conversion stuff “to look at later on”. Information does not travel well between functional and technical teams. As we get near the Go Live, this becomes even worst. This methodology was made to solve these issues. Data Migration Methodology for SAP PAGE 9 Concept VS techniques The approach I take to the data conversion is as much a concept as a technique. Both aspects must be applied for results to show up. This is actually true of any concept, where failures are often due to application of the technique while neglecting the conceptual aspect of it. The mindset required in our case is that we must do things right from the start and solve issues as they occur. Take the time it requires to do thing properly and thoroughly. No expediting, no bypassing of step, no piling of unsolved issue to keep going. Results will initially be slower to come. However, because you will get things right the fist time, there will be no need to go back. Changes always create regressions, costing you precious time and money. By eliminating the need to do rework, thus eliminating the regressions, you will eventually pick-up an impressive speed. As in car racing, it is not the speed at which you enter a turn which is most important, it is the one at which you get out of it. A few facts The data conversion is not some technical stuff to give to the programmers and wait until it comes back. Most, if not all, of the issues and problems you will encounter in the conversion process will be functional. Although the extract / load process itself will not be effortless, it is the part between the extract and the load, which is the most difficult. Getting rules, permitting to have the right data at the right place, is always a functional problem. SAP is a process-oriented system and Master Data is an integral part of this process. Nice, but what does it means? The answer is that everything is tied together. Master Data is dependent of the customizing, the customizing is made accordingly to the way you do your process, and Master Data is needed to run your process. If you change Master Data, it will most probably change the behaviour of the process. If you change customizing, your Master Data and conversion rules may become incomplete or incorrect. Whichever phase you are in the project, data conversion always seems to be the step that can be pushed a little bit forward in time. Doing this will put the conversion process too close to the end of the project. In this situation, you will end up shovelling a ton of data into SAP at full speed with little control, if any, on data quality and coherence. Remember the old saying "garbage in, garbage out". Conversion rules and Business Object ownership Ok, we now know DC is a functional thing, data must not be shovelled-in, it is hard work and it takes time. How do we manage his? The solution is to make the DC process part of the functional process, both in term of timing and deliverable. Key Users must do a thorough analysis of the Master Data and link their usage to the process as they are customizing. They must understand which data does what, which are needed, how it relates to the customizing & process flow and figure out where it will come from. This knowledge will get things to fit progressively one into the other like a set of blocks. For Key Users to get this knowledge, I give them the responsibility and ownership of the mapping and conversion rules. It is ‘their’ Master Data and they will do mapping & rules documents. At first, this process will not simplify the technological aspect of the conversion, nor will it make it shorter or easier … say what! As I already mentioned speed will come, eventually. The goal of the mapping and rules writing is to get Key Users to sweat it out and understand SAP way of doing things. This will also help the knowledge transfer between consultants and Key Users. When they are done with this, they will play that “Master Data - business process - customizing -” game without even thinking about it. The mapping document and conversion rules will become the common ground for discussions between the different domains. Cross reading of DC rules is essential as, for example, some action taken by PP may affect SD and FI. Do not underestimate this, a small change in PP can block all expeditions. I saw this kind of issues in all the projects I worked on. The DC rules will also serve as the common language between the functional team and the technical team. The mapping document and conversion rules will become the technical staff road map. If it is not in the rules, it does not exist. So any discussion, decision or answer must be documented in the rules. You will be surprised to see how things change between verbal decision and written decision, which requires thinking about it and assuming responsibility for it. Again, take the time needed to have clear and unambiguous sets of DC rules. For a specific Business Object, when the rules have no ambiguity and where cross read and validated by all affected domains and the technical team, and only then, can you start the development of the extract and load programs. This is the point where you start picking up speed, lots of it. Data Migration Methodology for SAP PAGE 10 Main steps of the conversion methodology Before you even start to work on specs, you must first get organized. Getting a good planning and organizational structure take about two weeks for the first draft, which will leave you with some questions on project organization. Getting a complete and final planning will take at least one more week. Any unsolved issues on the conversion organization will haunt you throughout the project, so finish this completely before starting any other step. The data conversion requires Key Users, business analysts and technical resources from most departments. These same resources will most probably be involved in other parts of the project. For this reason, the risk of conflicting task is high and can quickly lead to a bottleneck, where key peoples are overloaded. For this reason, you should consider the data conversion as a project within the project. This translates into the preparation of a complete conversion plan that will help you go through the process and will permit to foresee and solve the conflicting resources usage before the bottleneck ever occurs. The methodology is based on a top down process, which permits to plan, organize, execute and follow-up your conversion. As the project is going, you will control the evolution of the data conversion process. Each step has its own use. You may sometimes feel like you are not going to the end by the shortest route, but remember, the goal is not to get first results faster, it is to finish the ‘whole’ process faster. This methodology, based on the experience of many projects, will help you avoid the data conversion pitfalls. The main steps of the data conversion are: Organization of the data conversion Data conversion plan The WBS with workload estimates The calendar planning with resources loading Going on with the Business Objects data conversion Data purging and cleansing Mapping and conversion rules Extract and load programs from rules Data and rules adaptation Load unit testing Extract and load full size testing Full data loading and validation into ACCEPTANCE SYSTEM Full data loading and validation into PRE-PRODUCTION SYSTEM Full conversion and signoff into PRODUCTION SYSTEM Where you will, for sure, have a timing problem The business process analysis is done by the Key Users, business issues are dealt with by Key Users, tests are done by Key Users, functional issues are solved by Key Users, training is prepared by Key Users, data conversion rules are done by Key Users, data validation is done by Key Users, Master Data issues are solved by Key Users …. In addition, when you start validating Master Data, it is usually at the same time as Key Users are out giving training. If you try to identify where there will most probably be a bottleneck, do not look any further. The intersection of Master Data validation, integration testing and training will be 'it'. You will need a very realistic workload estimate and resources workload planning to avoid Key Users being schedule 24 hours of work per day. There are not many solutions to this. Assuming your team is sized correctly, doubling the resources will double the cost, double problems but probably not double the output. Therefore, we are back to the basic rule, this kind of project takes time, and the best way to minimize it, is to plan for it correctly from the start. You will have no other choice than spreading the data migration workload throughout the entire project. Complaisance planning will just make a long project longer, sometimes much longer and always a lot more expensive. Trying to go too fast, with insufficient resources and unrealistic planning, is the basic recipe of most horror story you hear about SAP implementations. Data Migration Methodology for SAP PAGE 11 There is no such thing as a free lunch This is a simple methodology, but simple does not mean easy. Doing things right the first time is an investment, and like any investment, it has a cost (money, people, time) to be paid before you get profits. No free lunch here. You will need discipline, lots of it. Do no pile up or delay solving of conversion issues. Better to slow down, cut your loss and figure out how to resolve problems, than trying to keep going the wrong way. To reach the point where the result is be bigger than the sum of the parts, you must finish each step at 100% before starting the next one. Expediting, bypassing or neglecting a task will have a negative effect further down the road, which will eventually create important delays. Data migration takes time and no technological gadget or guru will make this otherwise. There is no 'easy does it' way to do the data migration… but some paths are easier path than others. Data Migration Methodology for SAP 1.2 PAGE 12 DATA CONVERSION GUIDELINES Think SAP Forget your actual system and understand SAP. First, get familiar with the SAP business process you will be implementing. Then, according to the SAP process needs, establish the Master Data requirements. Finally, see what can be salvage from your legacy system. Think SAP, do not try to fit in your old system into it. Prepare the Legacy data Clean the data on your legacy system. It is easier to start from a sound legacy system than trying to fix inconsistencies during the conversion. Delete obsolete data and fix data discrepancy. These two steps are called data purging and data cleansing. This can be done without specific knowledge of SAP and can begin way before the project Kick Off. Before the last test run, take into account the customizations of your new system Because both the organizational structure and the actual customizing influence the data you transfer for Business Objects, finalize all customizations before the last test run. Customizing changes after the final transfer may result in additional required fields. It can also invalidate the loaded data, which leaves you with an incoherent data set that will be difficult to correct after Go Live. If there is a last minute change in SAP customizing, no matter how small it is, you must retest the loading of all business objects… been there done that, and without a re-testing following a last minute customizing change (2 days before go live), we would have failed to proceed with the data migration on go live day. Reduce the amount of historical data to be transferred If your system has lot of historic data, think about archiving data. There is no need to spend large amount of money to keep live data that are otherwise used sporadically and could very well be stored in an archive database. Large set of historical data will add a strain on your SAP implementation and will make the data conversion more difficult. Also, because data tend to be less accurate when they where created a long time ago, it increases the risk of having inconsistent data when extracting from the LS. Prefer the use of control reports Data entered in SAP should be checked using control reports instead of looking directly in the database. This will make it easier for the Key Users and stakeholders. Small is beautiful Start small. The first time you transfer data, begin with a few records of a Business Object. This way, you learn how the program works. After transferring some records successfully, try transferring a larger amount of data. Make sure that you transfer each different type of data before you transfer on a larger scale. Play it safe Do a system backup (or client copy) after transferring a significant amount of data. The backup allows you to secure a specific level you have reached during the data conversion process. If you have any problems, you can return to this level, avoiding to start from the beginning of the process. Data Migration Methodology for SAP 1.3 SUGGESTED ADDITIONAL READINGS SAP “Data Transfer Made Easy guidebook”. It can be found on the “SAP Simplification Group” web site System Landscape (Landscape-II.pdf) fount on SapLabs website SAP Legacy System Migration Workbench (LSMW) on https://help.sap.com PAGE 13 Data Migration Methodology for SAP SECTION 2 - ORGANIZE THE DATA CONVERSION PAGE 14 Data Migration Methodology for SAP Data Conversion Plan WBS Calendar planning PAGE 15 Data Migration Methodology for SAP 2.1 PAGE 16 OVERVIEW This section describes the organization of the conversion. This is the first building block of your conversion process and must be completed right at the beginning of the project. This part of the process is to be done by the project manager and the data conversion coordinator. 2.2 DATA CONVERSION PLAN Business Objects A Business Object is a general category for data that defines something like material master, vendor master, stocks, orders, purchase requisitions, organizational units, etc. The first step is identifying which Business Objects are required for your SAP implementation. Data type There are three types of data involved in the migration: Master Data, transactional data, and historical data. Master Data. Application Master Data tends to be static. Most Master Data can be driven by the legacy applications. Examples: vendors, customers, charts of accounts, assets, bills of materials, material masters, info records. Transactional Data. Transactional data is current and outstanding transaction data that needs to be captured from the legacy system and defined to the SAP R/3 applications for business process completion. Examples: accounting documents, open purchase orders, open sales orders, back orders. Historical Data. Historical data needs to be brought over from the legacy system to the SAP R/3 System for reference purposes. Examples: closed purchase orders, closed sales orders, summary general ledger information, etc. Data conversion plan sample Data Migration Methodology for SAP PAGE 17 Required information to complete the conversion plan What Where How much How Which Business Objects will be converted from the legacy system into SAP. Where are the data, which Legacy System's are involved for the extraction. Estimate the number of records to be ultimately loaded into SAP. There are two aspects to be considered: The way data is extracted from the Legacy System Automatically extracted from the Legacy system without manual intervention. Manually filled spreadsheet Combination of an automatic Legacy System extraction + manual entry into a spreadsheet The way data is injected into SAP: Automatic data transfer from a flat file into SAP Manually entering data with online transactions into SAP Combination of both The data transfer method you choose will determine the types of resources you need. For example, you may need temporary employees for the manual data entry and programmers for writing the extraction programs. Who Who is involve on each Business Object: Key User (Functional responsible of BO conversion: Rules, manual data corrections, test, validations) Legacy system technical staff Functional consultants Resources for of data cleansing and purging in the Legacy System Programmer for the extraction Programmer for loading data in SAP Business Object Stakeholder Knowing where the data is in the Legacy System, and which is accurate, requires the implication of different resources from your organisation. They will need work closely together and you have to plan and secure their availability. This part seems easy enough. However, you will quickly see that getting a clear answer to all these questions, for all Business Objects, is no easy task. Take the time and energy it needs to answer these questions meticulously. It will avoid a lot of turning in circle and save you lot of time throughout the project. Ha yes, I forgot one thing, make sure that all whose name is on the document are aware of it, understand what it mean and approve it. PAGE 18 Data Migration Methodology for SAP Main Business Objects sequence of conversion Pre-Required - GL account Master (Include primary cost & revenue elements) - Profit centers hierarchy - Profit centers - Cost centers hierarchy - Cost Centers - Characteristics - Classes - Activity types Optional Internal orders WBS elements if PS module. Material Master Work Centers Banks Doc Mast Customer Master Vendor Master BOM Condition record - Discount - Pricing Purchase info records Sales info records Routing Text Source lists Routing / Task list Storage Bins Open A/P Open A/R Opening Balances Stocks (VM) Stocks (IM) Open Sales Orders Open Production Orders Contracts Open Purchase Orders Data Migration Methodology for SAP 2.3 PAGE 19 WBS ( work breakdown structure) Why a WBS? Estimates for a project planning must be deducted and justified from a logical process. They represent the real workload required for the different tasks of the project. The WBS is a great tool to figure out these numbers. The goal is to get a workload estimate for each task, without any duration or calendar consideration. Ignoring the date factor help in getting as objective as possible. The workload is calculated in Person/Days. Whether there is one or five persons assigned to a task, the total workload is the same. Using Person/Days will help for the next step, where you will build a calendar planning. WBS Sample How to The idea is to break the project in Business Objects and then break each of these in tasks. You then proceed to evaluate the workload required for each of these tasks. It will be much easier to get accurate and objectives numbers on small specific tasks than on a large chunk. If your WBS is not granular enough, your estimate is more difficult to get and will be less accurate. An error on one element will also have a greater impact. As for progress follow-up, it will be less accurate, since any detected slippage will involve higher number because the element is itself too big. If the WBS is too granular, you will get lost in a forest of details and numbers. The follow-up will also be much more difficult and it will be difficult to get the whole team to use it (too complex). In this methodology, the WBS I suggest is middle ground between these two limits. I got the resulting WBS by trials & errors on different projects. I think it is granular enough to be precise for efficient follow-up. Yet, simple enough for the whole team to easily contribute in evaluating the numbers. Data Migration Methodology for SAP PAGE 20 These guidelines will help you: Evaluate each task of the WBS independently, making abstraction of the other tasks. It will results in a more objective evaluation of each task. It is important at this point to make complete abstraction of calendar planning or any target date. Forget when this should be finish or how long it is expected to last. Just try to figure out the real workload needed to complete each element of the DC process. After that, we will see how we can meet deadlines, by acting on the organization of the project rather than "fixing up" the estimate. Starting a WBS while taking into consideration a goal to meet, as a specific date or target total of Person/Days, will only lead to complaisance planning and get you in trouble. Suggested WBS content for data conversion Business Objects (BO) BO name Functional domain responsible for the BO (conversion rules, manual data corrections, test, validations) Extract : Method use for data extraction from legacy Load: Method use to load data in SAP Legacy System : Identified where the data is coming from Volumes Qty of Records Qty of fields % of Data & Rules Adaptations Business Objects Mapping & Conversion ( For detailed information on these items, refer to section 3 ) Purging & Cleansing Mapping & conversion rules LS Data Extraction Programs LSM & Load programs Data & Rules adaptations Load Unit Testing Extract & Load Full size Acceptance loads and validations ACCEPTANCE system Full Load & validation PRE PROD Full loading PRE PROD validation by Stakeholders PROD Full loading PROD Validation & Signoff by Stakeholders Total Total - at best (total in Person/Days of each Business Object) Total - most probable (total at best + 20 to 25% contingency buffer) Are you sure? "That much, are you sure?" This is probably the first thing you will hear when showing your WBS. In many projects, when you get the numbers, at first glance it seams a lot of time and money just for converting data. Well, "just converting data" is an understatement, as stated earlier this is an important part of the project. When considering all tasks, it adds up very quickly. Just have a 2 hours meeting once a week with seven people and it will consume two Person/Days each week throughout the project. Stretch the meeting just a little hour more than expected (sounds familiar!) Data Migration Methodology for SAP PAGE 21 and the equivalent of a whole day of work just went by. Add to this the little informal meetings between Key Users, consultants and DC team members, for each Business Object to convert, and it quickly adds up to a non-negligible amount. And this is just for meetings, no tangible deliverable is produce yet. Request to re-evaluate your WBS Sometimes, after the "are you sure?", comes the "please re-evaluate with the Key Users & consultants". This is a very justified request … But be careful, a WBS revision often results in trying to reduce the largest numbers by hammering them down with various theories, while totally ignoring the smaller values. When getting the numbers for the original WBS, you average each element. Overall, you under estimate some and over estimate others, but the average law will make it a globally reasonable measure. However, if you start concentrating on some numbers while forgetting others, the average law is out the window. This is why, when re-evaluating a WBS, you must consider both the large and small values. Here are some suggestions I give to those concerned when re-evaluating a WBS: Explain clearly what a Person/Day is: "let's say you have only this one task to do and you have to it do alone, how many days will it take?". Explain the work to evaluate. For example, making the conversion rules means: talking about it with the consultants and Legacy System experts, writing the first version, having meetings to answer gray areas, doing some tests for uncertain fields, cross reading the documents and finally, some reflection time. Therefore, as you see, it is lot more than just figuring how long it would take to write some lines of rules. Count everyone's time. In the above example, you must count time for you, the consultants, the LS Experts, those present at the meetings, those doing tests, etc. Explain the average law I mentioned above and make sure they do re-estimate all the elements with the same scrutiny. While some high workload tasks may be overestimated, many smaller one are probably underestimated as well. Avoid consideration for deadline or total workload Estimate each task independently from each other. I personally went through that process. In all cases, the re-evaluation turned out with a slightly higher total effort. Mainly because they realized there is more, small but still time-consuming tasks, which they originally forgot to take into account. Facts to consider in you work estimate These are pointers to help you come up with the first draft. If Information is spread into different Legacy Systems, it will take more time than if it all came from one system. Also expect to have referential integrity issues between legacy systems, which must be solved before migrating to SAP. It is very difficult to find someone who knows all, but there is always someone who can help you on a specific task. This is where the WBS will help, as the splitting of Business Objects in tasks, permits each one to be evaluated by someone knowledgeable without the need of understanding the whole project. Take into account the number of fields you need for each Business Object. If you have no clue, take 200 for Material Master, 100 for Customers, 100 for Vendors, 40 for BOM, 40 for Routings. These figures are what I got in average for implementations with the modules FI, CO, MM, PP and SD. For BOM and Routings, if they are merged in a single structure in your LS (i.e. multilevel), count that BOM will take double the time you originally estimated and Routing will most probably have to be done manually from scratch. SAP is Single Level (unless it changed in newer versions), which mean that materials hierarchy is in the BOM and the operations sequence is in the Routings. Material Master is huge. It requires time and energy, lots of it. On top of being a difficult one, it is the first one you will have to do. It involves many of people from different domains. There is much to learn while doing Material Master, and this learning will bring Key Users to question the process, which they though where well understood. Data Migration Methodology for SAP PAGE 22 Different domains come up with their own set of rules, which need to be put together in a single Material Master. This will create collisions and conflicts, requiring meetings, discussions and testing before the issues are solved. The conversion rules are different for each Material Type and it is not always the same Key Users who have the info for each type. Other than the Big Five, workload estimates are rarely linked to the number of fields. The following situations in the Legacy System will increase the efforts: Historical data that was never purge Inconstant data (well, no one have these in their systems, right!) Part of the data existing aside in Excel, Access or other non formal system No clear owner or manager of a Business Object in the Legacy System (then it is probably messy) Be conservative, in doubt, over estimate rather than under estimate. Never mind how much you investigate or know the LS. There is always one Business Object where you will discover, at the last minute, that it just will not fit into SAP without major, and unplanned, efforts. It is not bad luck, it just happens every time. It is bad luck only if you did not consider it in your planning. If the data is not extracted from the LS, but generated manually, it will take longer. The time required is however more predictable as manual data entry do not need programs testing and debugging. When you extract data automatically from the LS, it should be faster. However take into account that programming means possible bugs. If you have part automatic and part manual, like "yes we can extract most of it, but need to do some adjustments in Excel", add extra time (50 to 100% more). At first glance, this seems like the easiest way to go. It’s not, trust me, these will be real headaches. Although it is almost impossible to avoid them, try having as little as possible of these. In all cases, prefer maximum usage of conversion rules. Ballpark figures Here are some figures to give you a ballpark of the projects I worked on. These are not absolute figures, as they vary from one project to another. In projects involving the modules FI, CO, MM, PP and SD, where we have from 20 000 to 40 000 material master items, with related BOM and Routings, about 2 000 vendors/customers, 10 000 inventory records and all other basic DC stuff, it gave me something between 500 to 800 Person/Days (if there is only one LS to get data from). A formula to help …. Handle with care Here is a formula for the Big Five. I came up with it when I started doing data conversion. I established it by looking back on previous projects. I asked how many Person/Days it took in average to do each of the Big Five. This was the total time including meetings, writing rules, programming extract/load tools, testing and updating rules, etc. Then, with the precious help of people who had first hand experiences doing DC, we came up with a formula to calculate a first estimate. As I went on different projects, I realized it was good enough to give me a first estimate in all cases. However, handle this with care. This really needs to be used as a tool that will help on a first draft. You need to challenge these numbers with your data conversion team for functional and technical tasks. To use the formula, you will need to establish how many fields can be solved only by rules and how many need “data and rules adaptation”. For the first draft, consider that about 80% of the fields are solved by conversion rules and 20% will need data and rules adaptation. If the data are in bad shape in the LS, go toward 70%-30%. As you learn more about the LS further on, these percentages get adjusted. You can calculate as follow in the WBS: Mapping Count 10 min per field (0.02 day per field) and add 1 day to the total for set up and explanations Conversion Rules Count 10 rules per day (0.1 day per field) Data Migration Methodology for SAP PAGE 23 Data and Rules Adaptation Count 12 seconds (~0.000416 day) per record and by field. We estimate around 20% of fields will need Data and Rules Adaptation. The resulting formula is (number of fields x number of records x 0.000416 x 20%). You will fin more explanations about ‘Data and rules adaptation’ in Section 3. This formula is most pertinent for Material, Customer and Vendor masters. For BOM and Routing, the time is less dependent on the number of fields than on the complexity of the data to extract. For those two, you can use the formula and then add between 50% to 100%, depending on the legacy data complexity. As stated earlier, if BOM and Routing are merged in a single structure in your LS (i.e. multilevel), count that BOM will take double the time you originally estimated and Routing will most probably have to be done manually from scratch. Load Unit Testing and Extract & Load – Full Size Testing Here we count only the time of the technical team to test and debug the extract & load tools. This also includes investigating the error messages sources, which will be communicated to the Key Users so they can analyse and correct the rules or customizing accordingly. The functional team efforts to solve issues is included in “Data and Rules Adaptation” Load Unit Testing Count 14 days for Material Master and between 2 to 7 days for other Master Data. For transactional data, count 2 to 5 days. Extract & Load – Full Size Testing Count 30 days for Material Master and between 5 to 15 days for other Master Data. For transactional data, count 2 to 10 days. For the other WBS items, it depends on the complexity of each project: Cleansing and Purging can be best estimated by the Key Users who knows in which condition are the data (if they don’t know, conclude they are in bad shape). Making the extract and load programs are estimated by the technical team according to the expected complexity. For extracting and loading data at the different steps, the technical team is the most informed to get estimates based on the expected complexity of the programs, the data volumes and the systems performances. For the validations and signoff, the Key Users are the one who, according to the volume of data to validate, can best estimates the efforts required. For Business Objects other than the Big Five, the number of fields has little to do. It is the complexity of the process, which needs to be taken into consideration. For those, none will take less than 10 Person/Days. Use your judgment and apply between 10 to 30 Person/Days per Business Object according to the expected complexity. Another Business Object, which is also more challenging, is inventory. At first, it looks simple enough, but getting 100% of the data in SAP will prove to be a challenge... if you plan to shoot less than 100%, go back to page 1 of this document. For Inventory, count 30 Person/Days for Inventory Management (MM-IM) + up to 100 Person/Days for Warehouse Management (WM) according the complexity of your WM system and the quality of the LS data. If you do not have WM in your LS and want to use WM in SAP, than you are in for a ride. In this situation, consider converting without WM and implement it later, once your system has been stable for a while in production. If you use WM in your LS and it is not working perfectly, you cannot expect to load it correctly in SAP. You must correct it before going into SAP. Data Migration Methodology for SAP 2.4 PAGE 24 CALENDAR PLANNING Overview At this point, you have assigned resources in the Data Conversion Plan and estimated the charge for each of the WBS elements in Person/Days. You must now transform this information in duration for each task, this is the calendar planning. To do the calendar planning, using MS-Project or other planning tool, you will enter the tasks and complete it with the following information: Tasks efforts in Person/Days Tasks dependency Names of the resources assigned to each task and the percentage of their availability on it Non working days and Holiday. This will give you a calendar planning based on an objective workload estimate and will also permit a quick identification of resource over-allocation, delay due to non-working time or tasks conflicts and bottlenecks. On most conversions, the overload on Key User is always a major problem. Your Key Users will be strongly solicited right from the beginning of the project. Keep in mind that the more you go on with your projects, the more they will be solicited to troubleshoot problems. Their availability for data conversion will only get more difficult to secure as the project is going on. Do not under estimate this fact in your planning. Once you will be done with the DC calendar planning, you must integrate it in the overall project planning and do a resources load analysis. This task is most difficult, time consuming and very frustrating (especially if you do not master MS-Project). Calendar planning sample Data Migration Methodology for SAP PAGE 25 MS-Project or not. Most probably, the only planning tool you will have available will be MS-Project. Although it is a nice tool, it also has great talent in 'auto messing-up' your schedules (make backup copies … and make them often). My first advice is to learn the basics of MS-Project before you get into it. It will be a much less frustrating experience. Some quick learning books can be found and are useful Whichever tool you use must be able to give you a resources load analysis. This will be a key element of you planning. Sequencing the tasks Since the process between test, writing rules and extracting/loading is iterative, we should be able to do them in parallel. However to do this realistically you would need to consider the percentage of effort on each task to be non-linear. If you get into this, your planning will be complex and difficult to build. The solution is to avoid parallel tasks, within a Business Object, when they share resources. Just put them one after the other so that each resource is working on only one thing at the time for the data conversion. The exception is for Materiel Master, where each material type can be considered as a Business object. Experience proved that the best way to get an accurate calendar planning for the DC process, while keeping it simple enough, is to avoid putting tasks in parallel within a Business Object. Key Users and consultant availability to work on Master Data When assigning Key Users and functional consultants to the Data Conversion tasks, count only 20% of their time available. This gives you an average of the time they will be able to give you throughout the entire project. Sometime it will be less, sometime it will be more, but overall it will be 20%. "20%, that is only one day a week!". Yes, remember that bottleneck mentioned before. You'll see that getting this much attention from Key Users will be quite a challenge when you get towards testing. Since you take 20% of the Key User’s time for DC, make sure whoever is planning other work on the project, takes into account that the Key Users are available at only 80% for them. End 'at best' VS 'most probable' In the WBS, you estimated all the tasks as objectively as possible, which gives you the required workload “at best”. To this, you must add 20 to 25% buffer, which gives you the “most probable” total effort and duration. In the calendar planning, all tasks are entered with the WBS value “at best”. The end date will than be the "at best". To get the most probable end, you need to add a single task at the very end of that planning which is equal to the WBS buffer. For buffer, and only there, the resources allocation is 100%. Assign all Key Users to the buffer task. Do not assign support consultants or technical team. In reality, they will all work on the buffer, but not at 100% and there is no way to know ahead of time who will do what. Therefore, the easiest ways to get a realistic “most probable” end date is to consider only Key Users at 100%. For example, My calendar planning end on April 30th I had 200 days buffer in my WBS I have 10 Key Users At the very end of the calendar planning, I will add a 200 days task with 10 resources at 100%. This will translate as a 20 days duration buffer for the Key Users. Now I have the most probable end date. Throughout the project, the “official” planning will only show the “at best” end date. The buffer is for unforeseen events when you are doing everything to meet the “at best” end date. However, believe me, it is difficult to do better than the most probable date. This is why the possibility of ending on “most probable date” should be communicated to higher management right from the start. Data Migration Methodology for SAP PAGE 26 Are you sure? "That long, are you sure?" Here we go again, the same phenomena as in the WBS will occur. Many peoples will challenge your calendar planning. As in WBS, they will focus only on some long tasks, and ignore the big picture and possible side effects on the overall planning caused by any change on some tasks. Then will come the silver bullet: Fast Track planning. In short, fast tracking consist of doing in parallel tasks which where originally schedule at different time. In IT projects, this usually translates in doing design and development in parallel. Therefore, your programmers start the programming before the functional team figure out what is needed. Each time I saw Fast-Track on an IT project, the result was a project taking longer than original planning, costing much more and delivering a faulty product. I am not saying it is impossible to gain by fast tracking on an IT project, but I am still waiting to see it work in real life. Remember the part in the first section of this document, which stated "It takes the time that is needed." Here is the part where this statement takes most of its sense. Good practice - Do not parallel the task hoping to save time. There are only 24hrs in a day and people need sleep. Do not forget the 20-25% margin Do not change the Person/Days established in the WBS, it is the most objective values you can get. If you need to finish a task faster, never change an end date or the workload. Changes the resources allocations to obtain the timeframe you want … then re-validate the resources workload. Workload analysis Here you are, now you have to identify the resources overload and play with tasks assignation and sequencing until all resources reach normal workload. Once the planning is done and resources workload is realistic, you are ready to go. At this point, you will only have to identify slippage as the project go and take corrective action before it has an impact on the project duration. Data Migration Methodology for SAP SECTION 3 - CONVERTING A BUSINESS OBJECT PAGE 27 Data Migration Methodology for SAP Data Purging & Cleansing Project kick-off Mapping & Conversion Rules Extract and Load Programs Load Unit Testing Data and Rules adaptation Extract & Load – Full Size Testing and Data Validation Acceptance System Full Load Pre-Production Load & Validation Production Load & Signoff PAGE 28 Data Migration Methodology for SAP 3.1 PAGE 29 OVERVIEW This section gives you information on the steps required for a Business Object conversion. Each person who is responsible of a Business Object should read this. Before you begin. When working on the conversion, do not try to fit your Legacy System into SAP. Think SAP and understand it. Then you can see what can be taken from your Legacy System. Converting to SAP, while having in mind your Legacy System process, will lead you in the wrong path. Get familiar with your SAP Business Object. Create objects, read the on line documentation, understand the requirements, go through your complete process. This will make the conversion easier. Documentation of your work (mapping sheet and conversion rules) SAP is an integrated system where Master Data has direct and indirect impacts on all process. Those impacts are not always obvious. For this reason, all fields mapping and rules must be clearly documented, permitting cross reading and validation among the whole functional team. Better circulation of information across all domains increase awareness of each other reality, reducing the risk of conflicting rules and side effects between domains. The mapping and conversion rules also provide a common language between the functional and technical teams. Although a structured documentation process might take a bit longer at first, it will create a synergy which will eventually make the whole bigger than the sum of the parts. 3.2 DATA PURGING AND CLEANSING The purging and cleansing of the Legacy System will save you time and efforts. Start as soon as possible and do as much as possible. This can be done without specific knowledge of SAP. Data Purging Before transferring data from your legacy system, delete old and obsolete data. For example, you may delete all onetime customers or those for which there where no transaction in the last two years. You can also delete unused materials. Data Cleansing This process correct data inconsistencies and ensures the integrity of the existing data in the Legacy System. For example, there are often lots of inconsistencies in Customer and Vendor address fields. You will quickly find that SAP will not let you load address fields unless you cleaned them. 3.3 MAPPING AND CONVERSION RULES The documentation of each Business Object will contain the data conversion rules, which include: Legacy sources From which Legacy system(s) are we extracting the data. Extraction procedures Document the specific steps required to extract data from the LS. Purging and cleansing rules What are the cleansing steps to be taken and extraction filters to be used. General Conversion rules Guidelines and generic rules. Fields Specific rules Conversion rules for each SAP fields. Data Migration Methodology for SAP PAGE 30 About the rules Getting the conversion rules to be written by Key Users is essential to this methodology. Key Users must understand SAP fields usage. Key Users must question their Legacy System values and integrity. Documented rules permit a clear statement of what a Key User think. Thus permitting to identify conflicts and misunderstandings between domains. Rules documents must be versioned, making change management easier. The rules will provide a common language between functional and technical teams. Key Users may not be familiar with writing conversion rules. Therefore, it is necessary to give some examples and explain the basic key elements of rules writing. Basic properties of a rule: General rules vs field rules General rules are guidelines not related to the final values of a specific field. For example, the way in which we differentiate the material types in the Legacy System is such a rule. Field rules are specific and will be used to get the field final values. General rules can be used as part of a field rule algorithm. Fields names When discussing or writing rules, always refer to a field in the form TABLE-FIELD, which is the only way to identify a specific field. There are fields, which exists in different views. Sometime it is exactly the same field, which is shown at two places. Other times, it is really two different fields, which happens to have the same name. The only way to differentiate them is to know from which table they come from. If they do not come from the same table, it is not the same field. The field name shown in a SAP views is often different from the field name in the database, which can lead to misunderstanding between the functional and technical teams. Different people will use different names for the same field. As well, they may start using the same name for different fields. Using the form TABLE-FIELD in all documentation will avoid these issues. Example: In Material Master, the field «Availability check» exist in the "MRP2" and the "Sales Gen" views. If you look at the TABLE-FIELD of each view, you get: MRP2 : MARC-MTVFP Sales Gen : MARC-MTVFP In both cases, the TABLE-FIELD name is the same, so it is the same field. In Customer Master, the field " Terms of Payment' exist in "Payment Transactions" and "Billing" views. If you look at the TABLE-FIELD of each view, you get: Payment Transactions : KNVV- ZTERM Billing Views : KNB1- ZTERM It is not the same field as they come from different tables. In the Payment view, the field is link to the Company Code, while for the Billing view it is link to the Sales Organization (you find this by looking at the table’s keys). So both of these fields can have different values. Short and clear Rules should be short, using IF/ELSE/END structure as much as possible. Make certain that the use of AND, OR and ( ) is clear. A long sentence embedding many AND & OR, if not clearly written, will lead to confusion. Do not hesitate to spread the rule on many lines, making it easy to read. A long of text is more difficult to read and understand than a series of short lines. Data Migration Methodology for SAP PAGE 31 Must be clear and without ambiguities For example: If product is a sold semi-finished …. End This is not clear enough, How do we know which product are "sold semi-finished". This must be clearly stated in the rule or be part of a general rule. Conversion tables In some case, it is impossible or too complex to get some values by rules. In this situation, we use conversion tables (usually Excel) and specify in the rule how to use the conversion tables. In the conversion rules document, a section identifies the conversion tables and explains how to use them: Conversion tables Here is an example of a field rule referring to a conversion table: IF BUYER-CODE on legacy is blank THEN Purchasing Group is Blank ELSE Locate BUYER-CODE in “Purchasing group” table to find Purchasing group END The Material Master challenge Material Master involves all the domains and may require anywhere from 20 fields to a few hundreds, depending on the complexity of your implementation. Some fields will be used by different domains while others will be used by only one domain, but its value will have an impact on functionality used by another domain. This is the most complex Business Object to document and, at the same time, it is the one you must start with in your conversion process. Material Master is key to all domains and many fields must be discovered and understood. To get that understanding from Key Users we proceed as follow: Data Migration Methodology for SAP PAGE 32 1st step: Selection of the fields by each domain Get each domain with their consultants to go through the mapping file and look at the fields for each material type. The goal here is to find which fields will be needed, requiring from the Key Users to ask questions and understand their purpose. This is done separately by each domain and documented in different mapping files. At this point, we are not interested about where the values will come from and how to convert them. Each time a domain select a field for a specific material type, they must enter their domain under the type in the list. Here are some examples of mapping from MM, PP and SD Example of fields selection by each domain What to do when the same field is found in different views In Material Master, some fields can be entered and modified in different views. For example, the field “Goods receipt processing time in days (MARC-WEBAZ)” exists in views Purchasing, MRP2 and Quality management. When doing the rules and the load program, the same field can’t be in different views. To solve this, proceed as follow: See with all implicated domains and decide who will be the owner of the field. Data Migration Methodology for SAP PAGE 33 Taking the example of the field “Goods receipt processing time in days (MARC-WEBAZ)”, it can be decided among the domains to put it in the Purchasing view (and nowhere else). This means the Purchasing Key User is the field owner. Other domains still can use it and have their own specific rules for it. However, it is the Purchasing Key User role to make sure this field is used correctly and validate if there are conflicts among the different domains rules. Be careful, make sure it is really the same field. In Customer Master, the field " Terms of Payment' exist in "Payment Transactions" and "Billing" views. If you look at the TABLE-FIELD of each view, you get: Payment Transactions : KNVV- ZTERM Billing Views : KNB1- ZTERM They come from different tables, it is not the same field. In the payment view, the field is linked to the Company Code while in the Billing view, it is linked to the Sales Organization (you find this by looking at the tables keys). So both of these fields can have different values and different owners. SPECIAL MULTI VIEWS In can however happen that no specific domain can be identified as the lead or main user of a field. Let’s take for example, “MM/PP status (MARC-MMSTA)” which is in views: Purchasing, MRP1, Work scheduling, Costing 1, Quality Management. If no one can be clearly identify as the lead for that field, then we put it in a dummy view called “SPECIAL multi views”. This is used to put all the fields which exists in different views and for which we can’t assign a specific owner. 2nd step: Regroup selection of all domains in a single document Once this is done for each domain, the DC manager put all domains mappings in a single document. It will show all the fields/domain dependencies and identify fields which will have conversion rules from different domains (put the field owner first). Example of fields selection grouped for all domains Data Migration Methodology for SAP PAGE 34 3rd step: Build the data conversion rules template with all the selected fields. In the previous step, we established which fields of the Material Master will be use in SAP. Now we build the data conversion rules template, which we will use to write the conversion rules. There is one line for each field/type combination. Specify, for each field/type, which domain selected it. If more than one domain selected the same field/type, put the name of all concerned domains (put the owner first). Data conversion rules template sample 4th step: Get the rules from each domain, independently Ask each domain to specify the conversion rules for all the fields they are concerned with. This is purposely done independently for each domain, so that misunderstanding or conflicting rules between domains may be put in evidence in the next step. 5th step: Merge the rules from all domains. Make a single document containing all the functional domain's rules and specify, for each rule, which domain wrote it. 6th step: Analyse the results and start building the Issues list. At this point, I create what I call the QUESTIONS LIST. It is a simple MS-Word document where I put all the questions I have after reading the rules. I document the question, name of who is responsible for the solution, creation date and target solution date. Prepare yourself for a very long list at first. I usually end-up with an average of two questions per field. Therefore, if you have 300 fields, that is 600 questions. Most of these are unclear rules or obvious problems, which are easily solved within the first week. What usually happens at this stage is rules conflict. It happens when more than one domain use the same field and they come up with contradictory or incompatible rules. Finding this at the beginning of the process will be a great time saver, as you just identified important issues between domains, before you developed anything. One of the main challenges of implementing SAP is integration of the different functional domains into a single product. Failure to understand this is will get you into trouble. This is true for the whole SAP implementation project, not just the Data Migration. Data Migration Methodology for SAP PAGE 35 After one or two weeks, once most questions are solved, the QUESTIONS LIST becomes the data conversion ISSUES LIST, logging all unanswered questions. From now on, any questions, decisions and actions assignments are documented in the ISSUES LIST. You now have the Material Master conversion rules documented, plus an ISSUES LIST, to follow up on the issues to be solved before you start programming. Material Master conversion rules sample All other Business Objects For the other Business Objects, because they are simpler than Material Master, we do not need a specific field selection template. The field selection step is still done before writing the rules, but we do it with the conversion rules template. Data Migration Methodology for SAP Business Objects conversion rules examples BOM conversion rules sample Open Account Receivable conversion rules sample (NOTE: In this example, PRMS is the name of the Legacy System) PAGE 36 Data Migration Methodology for SAP Vendor Master conversion rules sample (NOTE: In this example, PRMS is the name of the Legacy System) Example of general rules (NOTE: In this example, PRMS is the name of the Legacy System) ID RULE G000 G001 Note that SAP term “Security deposit” equal “Retention” in PRMS Type of transaction TYPE field in PRMS: Partial PMT: “Pay.” Credit Memo: “Cr M.” Debit Memo: “Dr M.” Invoice: “Inv.” Non A/R cash: “Non AR” Adjustments: “Adj” Any other type is an error. Validation to apply both at extraction and load. Partial PMT………. must be negative in PRMS, if not ERROR Credit Memo………must be negative in PRMS, if not ERROR Debit Memo……….must be positive in PRMS, if not ERROR Invoice……………..must be positive in PRMS, if not ERROR Any other type is an ERROR. LSM Load parameters KTOPL - Chart of account: CA00 BUKRS – Company code: 0070 GSBER - Business Area: 0040 BUDAT – Posting Date: “05-31-02” or last day of last closed period. OFFSET – Account (2): REPRISECL SKPERR – Skip err: X G002 G003 PAGE 37 Data Migration Methodology for SAP PAGE 38 Directory organization As you go, you will end up with lots of documents and versions. To store the different files on your server, use a specific directory structure. I suggest having a structure with a directory for each Business Object to store all the files relevant to the data conversion. Here is an example. C:\. ├─ Data Conversion │ │ │ ├─── 00 - Organization │ │ │ DC PLAN │ │ │ DC WBS │ │ │ DC SCHEDULE │ │ │ < Here, keep only the latest version of each document > │ │ │ │ │ └───── Old │ │ < Store here previous versions of above mentioned documents > │ │ │ ├─── 01 - Material Master │ │ │ Material Master - Field Selection Sheet.xls │ │ │ Material Master - Data Conversion Spec.doc │ │ │ < Here, keep only the latest version of each document > │ │ │ │ │ ├───── Old │ │ │ < Store here previous versions of above mentioned documents > │ │ │ │ │ └───── Working Files │ │ < Put here various working files > │ │ │ ├─── xx -BO name │ │ │ BO - Data Conversion Spec.doc │ │ │ < Here, keep only the latest version of each document > │ │ │ │ │ ├───── Old │ │ │ < Store here previous versions of above mentioned documents > │ │ │ │ │ └───── Working Files │ │ < Put here various working files > Change management: working in batch mode As the project goes, rules will change. This is certitude. As you get closer to Go Live, changes occur faster and will require a quicker reaction time. When programming and testing the rules for a BO, we work in batch. This means we will do V01 of the rules, validate them, close the version, program it and test it. If changes are required at any point after we close the version, they will be documented in V02 and we finished programming and complete testing of V01 (V01 Batch). If there are bugs on the V01 load, they will be analysed and correction will be documented and applied to the V02. Considering the stress on the whole project team and the overall load on all members near Go Live, there is a real danger to loose control here. One way to stay on top of things, while keeping a quick reaction time, is good change management. Although it may sometime feel frustrating for Key Users and the technical team to go through versioning & batch mode, it will ultimately be the best way to go fast without breaking something else, which already works (regression). Data Migration Methodology for SAP PAGE 39 Version management of conversion rules Here how it goes: Creation of the first version V01 Freezing version V01 Once everyone agree that V01 is OK (functional and technical staff), freeze the version. Password protect V01, so no one changes it afterwards Make a copy of V01 as V02 In V02, activate MS-Word change tracking Put V01 in the "Old" directory Unprotect V02 (This is where we start the new version) From now on, any change to the rules must be done in V02, do not change V01 Development and testing of V01 Ask the technical team to work on V01 and only on V01. Once V01 is programmed, load it and ask the functional team to validate. If there is a bug requiring rules changes, all corrections must be entered in V02. Freezing of V02 Once everyone agree that V02 is OK (functional and technical staff), freeze the version. Password protect V02, so no one changes it afterwards Make a copy of the document as V03 In V03, accept all changes so that there is no visible change. In V03, activate MS-Word change tracking (should already be on) Put V02 in the "Old" directory Unprotect V03 From now on, any change to the rules must be done in V03. Development and testing of V02 Ask the technical team to work on V02 and only on V02 All changes between V01 and V02 are visible through MS-Word change tracking. Once V02 is programmed, load it and ask the functional team to validate. If there is a bug requiring rules changes, all corrections must be entered in V03. And so on … If you are not familiar with MS-Word change tracking, I suggest you get acquainted with this functionality. Murphy's protection: Save it often and do rolling backups. You will be working with Excel and MS-Word (using change tracking). These are nice tools but they can go wild and scrap your documents. This is mostly true with large documents. So save often and make backups of all your Data Conversion documents. I usually keep a 7 days rolling backup of all my files somewhere on a local PC to protect me from MS-Office bad behaviour as well as network failure … and human error. Be certain of two things: If you have many large MS-Office documents, at least one of them will get corrupted during the project. It always happens. It also always happens that someone mess-up a document, usually the most critical one. If you are in doubt, please refer to Murphy's Law. Data Migration Methodology for SAP 3.4 PAGE 40 EXTRACT AND LOAD PROGRAMS The rules document has sections for “Legacy sources and extraction procedures” and “Purging and cleansing rules”. This should explain what to clean/purge, what to extract and how to proceed. If there is ambiguity or incomplete information in the specs, solve them before you do any programming. This will prove to be a time saver later on. 3.5 TRANSFORMATION BETWEEN THE EXTRACTION AND LOAD Most data need transformation between the extraction from the Legacy System and the load in SAP. These can be done at extraction time, as an intermediary step or at load time. There is no good or wrong here and any combination is valid. What you must avoid is to spread the transformation in too many places, which makes debugging and finding the sources of issues more difficult. My preference is as follow: 3.6 Cleansing and filters are applied at extraction Data transformations are made at load time. Exceptionally, for very complex transformations, it is done as an intermediary step between the extraction and the load. However, I do try to avoid this as much as possible. DATA AND RULES ADAPTATION This is the most time consuming part of the conversion process. It is also the most difficult and can be very frustrating for the whole SAP implementation team. The path you took, in the preceding steps of the methodology, is design to deal with the issues and difficulties you will face at this point. At this stage, the team start programming the rules and test them. The first tests will reveal programming bugs and obvious rules issues. As the process go, the tests will be done with full data sets and many rules issues will come up. The high number of issues may be a bit discouraging at first. However, a lot of them are inter-related, and solving the root issues will solve many linked issue. Most will be solved quickly. The remaining issues will be the most difficult to solve. To find solutions, the functional team will need to review their process and possibly change customizing. This, in turn, may affect other Business Objects process and customizing, sometimes on process and conversions which where already tested successfully. Having many simultaneous changes to customizing and conversion rules, combined with the interrelations between the Business Objects, create a “pool break effect”, where you have balls going in all directions at the same time. This is where having clear rules, a solid change management process, a team working in batches and the discipline to stick to the methodology, will yield the biggest results. Although all the ingredients for chaos are present, you will stay in control. This is where the whole gets bigger than the sum of the parts. Here are some useful guidelines: 1. The Business Object Key User is the one writing and updating the rules as well as been accountable for the conversion result. 2. When something needs a change, it must be clearly documented and validated in the specs. 3. The technical team will develop programs according to the rule. If it is not in the rules, it does not exist. So if you do not see what you need, get it documented. 4. Have the discipline to manage change by versioning the documents and stick with working in batches. 5. It is better to take your time to do it correctly the first time rather than rushing it. Results will initially be slower to come, but you will eventually progress faster and faster. Problems accumulate in a snowball effect, so does success. 6. The most common error I saw on projects that failed, is trying to save time by working on new solutions without taking time to document, cross read and validate the conversion rules. They sure are getting output quickly this way… but are they going in the right direction? Data Migration Methodology for SAP 3.7 PAGE 41 LOAD UNIT TESTING Here we want to test the load programs at a unitary level. The goal is to see if we can load all the fields for all the data types without error. We are more concerned about going through the load cycle without SAP stopping us, rather than validating the correctness of the values. We use a small volume of data, usually creating them manually from scratch, rather than using real extracted data. The kind of issues you usually encounters at this point are: Programming errors in the load programs Some mandatory fields are missing Some dependency between two fields where not considered and you can’t load as expected There are invalid rules Using a load program, SAP did not behave as you expected (it sometimes behave differently with a load tool than it does with manual data entry) As mentioned earlier, the conversion process is iterative. Following the issues you’ll find here, you will have to go back to the functional Key User, find solutions and document them in the specs. 3.8 EXTRACT & LOAD – FULL SIZE TESTING AND DATA VALIDATION Once the unit testing of the load programs is done, we start testing the extract from LS and load in SAP with data volume. You can start by partial data set, like only one Material Type, and progress toward the full data conversion for each Business Object. Here we want to know if we can load the real data for a Business Object, as well as validating the results once loaded in SAP. The issues found are addressed by the Key Users and solutions are documented. We are still working in batch mode with rules versioning. It is important to validate results in SAP. The values, validated at an intermediate level of the extract/load cycle, may become incorrect once loaded in SAP. As for the challenges you will encounter here, they where described earlier in the “DATA AND RULES ADAPTATION” section. 3.9 ACCEPTANCE SYSTEM FULL LOAD In the previous step, we successfully loaded all Business Objects and had them validated with the real data extracted from the Legacy. However, depending on the landscape you used, different BO may have been validated in different clients and the customizing for the testing environment may not be clean. We do the acceptance full load once we are done with testing and solving issues for all Business Objects. Here, we want to start from a clean client (as close to production as possible), apply all transports, do the extract load cycles of all Business Objects and get a validation signoff from the functional team. At the end of this step, you must have successfully loaded data in SAP, for all Business Objects, and have them fully validated. For ACCEPTANCE SYSTEM, Key Users drive the validation of each Business Objects, with the implication of the Stakeholders. The key Users must sign the acceptation for each Business Objects 3.10 PRE-PRODUCTION AND PRODUCTION LOAD & SIGNOFF Pre-production load is a dressed rehearsal of the production load and is done with an exact copy of the production environment. What is done in pre-production must be exactly what will be done in production. At this point, customizing is finished for the entire project, everything was validated in ACCEPTANCE and we are ready to go in production. It is essential you did the full load and validation of all Business Objects in the previous step. While you can easily correct bugs in dev, it is difficult to correct them in pre-prod and almost impossible in production after Go Live. Because the production system is living its own life and can’t be controlled as in dev, correcting Master Data errors in production is like shooting a moving target … the more you try to fix it, the more you seems to break everything around it. I have seen projects with corrupted BOM data in PROD, even after a year of trying to fix it. Since BOM affect Costing, Manufacturing, Inventory, Purchasing, etc. you can imagine in which condition their SAP got after a while. Data Migration Methodology for SAP PAGE 42 Since you went through all the steps and followed all the methodology guidelines, the rest is just formality. You do a full load in pre-prod, in an exact copy of prod and do everything exactly as you will do in prod You get the whole thing validated by the BO’s Key Users and the BO’s Stakeholders Get written signoff from the BO’s Stakeholders (insist to have it written, not verbal) Do the final production load and get final signoff (insist to have it written, not verbal) Finally you have nothing else to do, as by following this methodology, you managed to accurately load 100% of the Master Data and no rework is needed (yes, this happens for real) Here are some useful guidelines: Unless there are major errors, do not change any extract/load programs to correct minors errors found in Pre-prod test cycle. It is better to do the correction immediately after loading in production (manually or by programming). This way you do not induce regression into the extract/load process, which may corrupt data loaded in the production system. If there are major errors found in Pre-prod test, you must step back to “Extract & Load – Full Size Testing and Data Validation”. When it is time to load in prod, do exactly as you did in pre-prod. For PRE-PRODUCTION, Stakeholders drive the validation of each Business Objects, with the implication of the Key Users. The Stakeholders must sign the acceptation for each Business Objects For PRODUCTION, Stakeholders are making final validation and signoff for each Business Objects. 3.11 SUGGESTIONS ON THE DATA CONVERSION LANDSCAPE When you start the loading and validating cycles, each Business Objects will be at different levels and they will progress at different speed. This will create an issue when it is time to refresh an environment to start a new “extract, load and validate” cycle. Here are the most common conflicts: PP will be making corrections to BOM and Routing, so they need to reload them. FI-CO will be doing costing runs and are directly affected by BOM and Routing, so they need to freeze them. The rest of the team will be making corrections to the other Business Objects and are not ready for a refresh. A solution is to use three SAP clients organized like this: 1. A Client for PP working on BOM and Routing 2. A Client for FI-CO working on costing 3. A Client for all the other BO’s been worked on Data Migration Methodology for SAP PAGE 43 CONCLUSION Now you know how I did different Master Data migrations faster and better than others did. I successfully used this methodology in different industries and countries. The methodology itself is mainly a mix of good old common sense and management 101. Each step is the foundation of the next one. Complete each step at 100% and the next one will be easier. The result is a snowball effect, permitting you to gain more speed from step to step. Not following this rule will also have a snowball effect, but in the opposite direction, reaching a point where the conversion process becomes out of control. Although it may sometimes look to others like you are taking the long route to get there, remember that the objective is not to finish a specific step ASAP. The goal it is to complete the whole process in the best time possible and to deliver a complete set of Master Data, which will not need rework once in production. The main challenge you will face it is to overcome: Pressure to show rapid results (any results) Tendencies to push forward issues so we can keep progressing Resistance to follow the versioning process and associated work in batch mode Refusal to slow down when the process begin to get out of hands. This is how I managed to keep my head above the water, even when everyone else seems to be in a crisis. Data Migration Methodology for SAP PAGE 44 APPENDIX A – VARIOUS TEMPLATES The following documents are attached to this PDF file: 1 - Conversion plan template.doc 2 - WBS template.xls 3 - Material Master - Fields selection sheet template.xls 4 - Data conversion specification - Generic template.doc 5 - Data conversion specification – BOM template.doc 6 - Data conversion specification – ROUTING template.doc 7 - Materials Classes and Characteristics structure.ppt I included this, as it may be useful to understand, and explain, the structure of the Materials Classes and Characteristics. The documents are included as comments, click on the paperclip to open the files. You can also see them as attachment : In the horizontal menu, click on “View”, “Show/Hide”, “Navigation Panes”, “Attachments”. Data Migration Methodology for SAP PAGE 45 APPENDIX B –License Creative Commons Attribution-ShareAlike 4.0 International Public License By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions. Section 1 – Definitions. a. Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image. b. Adapter's License means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License. c. BY-SA Compatible License means a license listed at creativecommons.org/compatiblelicenses, approved by Creative Commons as essentially the equivalent of this Public License. d. Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. e. Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements. f. Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material. g. License Elements means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike. h. Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License. i. Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license. j. Licensor means the individual(s) or entity(ies) granting rights under this Public License. k. Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them. l. Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world. m. You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning. Data Migration Methodology for SAP PAGE 46 Section 2 – Scope. a. License grant. 1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to: A. reproduce and Share the Licensed Material, in whole or in part; and B. produce, reproduce, and Share Adapted Material. 2. Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions. 3. Term. The term of this Public License is specified in Section 6(a). 4. Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material. 5. Downstream recipients. A. Offer from the Licensor – Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License. B. Additional offer from the Licensor – Adapted Material. Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter’s License You apply. C. No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material. 6. b. No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i). Other rights. 1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise. 2. Patent and trademark rights are not licensed under this Public License. 3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties. Section 3 – License Conditions. Your exercise of the Licensed Rights is expressly made subject to the following conditions. Data Migration Methodology for SAP a. PAGE 47 Attribution. 1. If You Share the Licensed Material (including in modified form), You must: A. retain the following if it is supplied by the Licensor with the Licensed Material: i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated); ii. a copyright notice; iii. a notice that refers to this Public License; iv. a notice that refers to the disclaimer of warranties; v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable; B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License. b. 2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information. 3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable. ShareAlike. In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply. 1. The Adapter’s License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License. 2. You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material. 3. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply. Section 4 – Sui Generis Database Rights. Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material: a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database; b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database. For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights. Data Migration Methodology for SAP PAGE 48 Section 5 – Disclaimer of Warranties and Limitation of Liability. a. Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You. b. To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You. c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability. Section 6 – Term and Termination. a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically. b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates: 1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or 2. upon express reinstatement by the Licensor. For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License. c. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License. d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License. Section 7 – Other Terms and Conditions. a. The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed. b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License. Section 8 – Interpretation. a. For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License. b. To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions. c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor. d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority.