Академический Документы
Профессиональный Документы
Культура Документы
If one can manage small decisions now, the large ones will gradually disappear or might never appear in the first place. Anonymous
PAGE 1
!HRISTIAN
ERGERON
" cvcby@yahoo.com
PAGE #
A O$T THIS DO!$MENT Thi% do&'(ent i% free) Yo' &an '%e it and di%tri*'te it freely+ a% long a% yo' do not &hange any of it% &ontent or %ell it)
Goal of thi% do&'(ent This document provides you with a procedure to assist you organizing and performing the data transfer from the legacy system. It describes a methodology for data migration I used successfully in different implementations. It is base upon my previous e periences. There is no warranty on its content or on the results. This guide gives you suggestions. It is up to you to ta!e the hints and ma!e up your own methodology. All the templates are derived from models I used in specific implementations and may come from older version of "A# $%. It most probably will not be &''( accurate or ade)uate for your use. There may be omissions and the templates can be for different "A# versions. It is a base to help you build your own template. *ou can start from them, but do not ta!e for granted that everything is there.
,ho( i% thi% g'ide for & "ection & is for every one involves in the data conversion process. + "ection + is for the pro,ect manager and the data conversion manager % "ection % is for the data conversion manager and the members of your team responsible of converting -usiness .b,ects, both technical and functional.
PAGE .
ig Fi/e 0 2hen referring to the -ig 3ive, it means 4aterial 4aster, 5ustomer 4aster, 6endor 4aster, -ill .f 4aterials 7-.48 and $outings. '%ine%% O*1e&t% 0 To help in the analysis and transfer process, the data are not treated as tables or field contents but rather as ob,ects in term of business operational. These are called -usiness .b,ects. '%ine%% O*1e&t D! re%2on%i*le 0 $esponsible of the conversion process 79egacy data source and integrity, mapping, conversion rules, etc.8 and for the respect of the planned schedule for his -usiness .b,ect. '%ine%% O*1e&t O3ner 0 The one that owns the information in the every day business. This is the person that will ma!e the strategic choices on functional re)uirements for the business ob,ect and that will do the final validation of the converted data. 5an be identified by finding The highest hierarchical person who will be directly and mostly affected if the business ob,ect does not wor! Data !on/er%ion 4 Data Migration 0 The data conversion process. :ata conversion and :ata 4igration terms are used interchangeably in the document. D! 0 Abbreviation for the data conversion process. Do(ain0 3unctional domain within the pro,ect, li!e 3inance, "ales, #roduction, etc. Flat File 0 A file format used to import data into "A#. The flat file is a plain te t file with a tab separator between fields. It can be easily generated from ; cel or Access. Inter(ediate file 0 An ; cel, Access or other type of file, which is manually manipulated in a process between the 9" e traction and the flat file generation. LS 0 Abbreviation for 9egacy "ystem LSM or LSM, 0 9egacy "ystem 4igration 2or!bench. It is a "A# tool for conversion that permits data loading using flat files e tracted from the 9egacy "ystem. Tran%&odifi&ation Ta*le+ !ro%% referen&e ta*le or 5"Ref ta*le 0 A table that shows the relation between fields when one value is related to a parent field. 3or e ample, the <"ales .rganization< will be set accordingly to the material type. , S 0 2or! -rea!down "tructure.
PAGE 6
TA LE OF !ONTENTS
SE!TION 1 " INTROD$!TION TO DATA !ON7ERSION)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))8 &.& I/T$.:=5TI./..................................................................................................................................................> .verview..................................................................................................................................................> -ases from which this methodology was made.......................................................................................> #hilosophy 6" techni)ues.......................................................................................................................? A few facts...............................................................................................................................................? 5onversion rules and business ob,ect ownership ....................................................................................? 4ain steps of the conversion methodology.............................................................................................@ 2here you will, for sure, have a timing problem....................................................................................@ There is no such thing as a free lunch....................................................................................................&' The computer will have the last word....................................................................................................&'
&.+ :ATA 5./6;$"I./ A=I:;9I/;"................................................................................................................&& Thin! "A#..............................................................................................................................................&& #repare the 9egacy :atabase.................................................................................................................&& -efore the last test run, ta!e into account the customizations of your new system...............................&& $educe the amount of historical data to be transferred..........................................................................&& =se controls edition in "A# ..................................................................................................................&& "mall is beautiful...................................................................................................................................&& -e wise...................................................................................................................................................&& #lay it safe..............................................................................................................................................&&
&.% "=AA;"T;: A::ITI./A9 $;A:I/A" .......................................................................................................&+ SE!TION # " ORGANI9E THE DATA !ON7ERSION))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))1. +.& .6;$6I;2.........................................................................................................................................................&B +.+ :ATA 5./6;$"I./ #9A/.............................................................................................................................&B -usiness .b,ects....................................................................................................................................&B :ata type ...............................................................................................................................................&B Information to complete in the conversion plan....................................................................................&C 4ain -usiness .b,ects se)uence of conversion....................................................................................&>
+.% 2-" 7 2.$D -$;AD:.2/ "T$=5T=$;8..............................................................................................................&? 2hy a 2-" E.........................................................................................................................................&? Fow to....................................................................................................................................................&? "uggested 2-" content for data conversion.........................................................................................&@ Are you sure E........................................................................................................................................&@ $e)uest to reGevaluate your 2-"..........................................................................................................&@ "ome pointers to figure out numbers.....................................................................................................+' -allpar! figures......................................................................................................................................+& A formula to help H. Fandle with care.................................................................................................+&
+.I 5A9;/:A$ #9A//I/A...................................................................................................................................+% .verview................................................................................................................................................+% 4"G#ro,ect or not...................................................................................................................................+I "e)uencing the tas!s..............................................................................................................................+I Dey users and consultant availability to wor! on 4aster :ata..............................................................+I ;nd Jat bestJ 6" Jmost probableJ.............................................................................................................+I
PAGE :
SE!TION . " !ON7ERTING A $SINESS O ;E!T)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))#8 %.& .6;$6I;2.........................................................................................................................................................+? -efore you begin....................................................................................................................................+? :ocumentation of your wor! 7conversion spec. and mapping sheet8....................................................+?
%.+ :ATA #=$AI/A A/: 59;A/"I/A...............................................................................................................+? %.% 4A##I/A A/: 5./6;$"I./ $=9;"..........................................................................................................+? About the rules.......................................................................................................................................+@ A special case for 4aterial 4aster........................................................................................................%' All other business ob,ects......................................................................................................................%I :irectory organization...........................................................................................................................%> 6ersion management of conversion rules..............................................................................................%> 4urphyJs protection 0 "ave it often H and get good bac!ups...............................................................%?
%.I ;KT$A5T A/: 9.A: #$.A$A4"..........................................................................................................................%? %.B :ATA A/: $=9;" A:A#TATI./............................................................................................................................%@ %.C 9.A: =/IT T;"TI/A.............................................................................................................................................I' %.> ;KT$A5T L 9.A: M 3=99 "IN; T;"TI/A A/: :ATA 6A9I:ATI./.....................................................................I' %.?A55;#TA/5; "*"T;4 3=99 9.A:........................................................................................................................I' %.@#$; #$.:=5TI./ A/: #$.:=5TI./ 9.A:...........................................................................................................I& %.&'"=AA;"TI./" ./ TF; :ATA 5./6;$"I./ 9A/:"5A#;.....................................................................................I& !ON!L$SION)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))6# APPENDI5 < 7ARIO$S TEMPLATES)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))6. A G 5onversion plan template................................................................................................................II - G 2-" template..................................................................................................................................II 5 M 4aterial 4aster G 3ields selection sheet..........................................................................................II : G :ata conversion specification G Aeneric template...........................................................................II ; G :ata conversion specification M -.4 L $outing Template "amples.............................................II 3 G 4aterials 5lasses and 5haracteristics structure...............................................................................II
PAGE 8
PAGE =
1.1 INTRODUCTION
O/er/ie3
Implementing "A# is an important challenge, both in terms of resources 7people, money, time8 and in business process. A lot is at sta!e and, for most of you, failure is not an option you can afford. To put all odds on your side, you need a good methodology. .ne that will provide you with a realistic planning, a solid organization, a way to manage the process and control tools to detect and correct slippage before it becomes a problem. An important part of this challenge will be the data conversion. #revious implementations of "A# have shown that data migration can amount up to about I'( of the entire pro,ect. #oor data conversion will ma!e your Ao 9ive 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 implantation.
At Ao 9ive 4aster data deadlines where constantly busted and production load is done in JJrush modeJ at the last minute. "ome !ey parts of the data cannot be loaded in production. #atches are applied to the master data in order to forceGload. "ome data ,ust will not get in at all, they will have to be entered after A. 9ive.
After Ao 9ive "ome :ata need to be corrected L entered after Ao 9ive. -ecause the production system is now living, data are moving targets. This ma!es the process difficult and time consuming H. This translates into a costly operation.
After discussing with people who lived these situation 7manager, functional and technical8, we identified the following points 0 #lanning and resources load estimates where way out 7when they e isted8. 4ost of the problems encountered are actually functional issues. Information does not travel well between functional and technical team. As we get near the Ao 9ive, this becomes much worst.
PAGE >
Philo%o2hy 7S te&hni?'e%
The approach I ta!e to the data conversion is as much a state of mind as a techni)ue. -oth aspect of it must be applied for results to show up. This is actually true of any concept. 4ost of concept failures are due to application of the techni)ue while neglecting the philosophical aspect of it. The mindset re)uired in our case is that we must do things right from the start and solve issues as they occur. Ta!e the time that it re)uires to do thing properly and thoroughly. /o e pediting, no bypassing of step, no piling of unsolved issue to !eep going. $esults will initially be slower to come. Fowever, because you will get things right on the fist time, you will eventually pic!Gup an impressive speed. As in car racing, it is not the speed at which you enter a turn that is most important, it is the one at which you get out of it.
A fe3 fa&t%
The data conversion is not some technical stuff to give to the programmers and wait until it comes bac!. 4ost, if not all, of the issues and problems you will encounter in the conversion process will be functional. Although the e tract 1 load process itself will not be effortless, it is the part between the e tract and the load that is the most difficult. Aetting the right data at the right place with the values re)uired for your business process is always a functional problem. "A# is a processGoriented system and master data is an integral part of this process. /ice, but what does it meansE The answer is that everything is tied together. 4aster 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 behavior of the process. If you change customizing, your master data may become incomplete or incorrect. 2hichever phases you are in the pro,ect, data conversion always seem to be the one step that can be pushed a little bit forward in time when you run behind in the overall schedule. :oing this will put the conversion process too close to the end of the pro,ect. In that situation, you will end up shoveling a ton of data into "A# at full speed with little control, if any, on data )uality and coherence. $emember the old saying <garbage in, garbage out<. There is no Jeasy does itJ way to do the data conversion and it ta!es time. :ata conversion is made with lot of brain stuff mi ed with hard wor! and some programming. /o technological gadget or guru will ma!e this otherwise.
PAGE @
The mapping document and conversion rules will become the technical staff road map. If it is not in the rules, it does not e ist. "o any discussion, decision or answer must be documented in the rules. *ou will be surprised to see how things change between verbal decision, sometime made in the hallway between meetings, and written decision which re)uired thin!ing about it and assuming responsibility for it. Again, ta!e the time that it gets to have clear and unambiguous :5 rules. 2hen the spec has no ambiguity and has been cross read and validated by all domains and the technical team, and only then, can you start the development of the e tract and load programs. That will be the point where will start pic!ing up speed, lots of it.
PAGE 1A
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 bac! to the basic rule, this !ind of pro,ect ta!es time and the best way to minimize it is to plan for it correctly. *ou will have no other choice than spreading the load throughout the entire pro,ect. 5omplaisance planning will ,ust ma!e a long pro,ect longer, sometimes much longer and always a lot more e pensive. Trying to go too fast with insufficient resources is usually the basic recipe of most horror story you hear about "A# implementations.
PAGE 11
efore the la%t te%t r'n+ taBe into a&&o'nt the &'%to(iCation% of yo'r ne3 %y%te(
-ecause both the organizational structure and the actual customizing influence the data you transfer for business ob,ects, finalize all customizations before the last test run. 5ustomizing changes after the final transfer may result in additional re)uired fields, this re)uires preparing and transferring more data. It can also invalidate the loaded data, which leaves you with an incoherent data set that will be very costly to correct after Ao 9ive.
S(all i% *ea'tif'l
"tart small. The first time you transfer data, begin with a few records of a business ob,ect. This way, you learn how the program wor!s. After transferring some records successfully, try transferring a larger amount of data. 4a!e sure that you transfer each different type of data before you transfer on a larger scale.
e 3i%e
The full data integration in your production system is the end of the process and should mostly be a technical operation where we push some buttons to get some results. To reach this goal, it implies that all functional and technical issues where dealt with before starting the full size transfer from the 9egacy "ystem. The hard wor! is in the mapping and establishment of conversion rules from the old to the new system. That is where you will ma!e or miss your conversion. :onJt even thin! about loading large volumes into production if you are not completely ready.
Play it %afe
I strongly suggest that you perform a system bac!up 7or client copy8 after transferring a significant amount of data. The bac!up 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, and you do not have to begin the process all over again.
PAGE 1#
PAGE 1.
PAGE 16
2-"
5alendar planning
PAGE 1:
2.1 OVERVIEW
This section describes the organization of the conversion. This is the first building bloc! of your conversion process and must be completed right at the beginning of the pro,ect. This part of the process is to be done by the pro,ect manager and the data conversion coordinator.
Data ty2e
There are three types of data involved in a "A# system0 master data, transactional data, and historical data. Ma%ter Data) Application master data tends to be more static once defined. 4ost master data can be driven by the legacy applications. ; amples include vendors, customers, charts of accounts, assets, bills of materials, material masters, info records, and so on. Tran%a&tional Data) Transactional data is current and outstanding transaction data that needs to be captured from the legacy system and defined to the "A# $1% applications for business process completion. ; amples include accounting documents, open purchase orders, open sales orders, bac! orders, and so on. Hi%tori&al Data) Fistorical data needs to be brought over from the legacy system to the "A# $1% "ystem for reference purposes. ; amples include closed purchase orders, closed sales orders, summary general ledger information, and so on.
PAGE 18
Ho3 ('&h ;stimate the number of records to be ultimately loaded into "A#. Ho3 There are two aspects to be considered 0 The way data is e tracted from the 9egacy "ystem Automatically e tracted from the 9egacy system without manual intervention. 4anually filled spreadsheet 5ombination of an automatic 9egacy "ystem e traction R 4anual ;ntry into a spreadsheet
The way data is in,ected into "A# 0 Automatic data transfer from a flat file into "A# 4anually entering data with online transactions into "A# 5ombination of both
The data transfer method you choose will determine the types of resources you need. 3or e ample, you may need temporary employees for the manual data entry and programmers for writing your own e traction programs. *ou need to !now both what data is in your legacy system and which "A# applications correspond to the business ob,ects that will be transferred. .ne person does not have to !now all of this, but the people who !now this information should wor! closely together. ,ho 2ho is involve on each -usiness .b,ect 0 Dey user 73unctional responsible of -. conversion 0 $ules, manual data corrections, test, validations 8 5onsultant $esponsible of data cleaning and purging in the 9egacy "ystem $esponsible of the e traction $esponsible of loading data in "A# -usiness .b,ect 4anager 7Fierarchic owner who is responsible of day to day use and integrity of information and the one which will be signing off for data acceptance 8
This part seems easy enough. Fowever, you will )uic!ly see that getting a clear answer to these )uestions is no easy tas!. Ta!e the time and energy it needs to answer these )uestions meticulously. It will avoid a lot of turning in circle and save you lot of time throughout the pro,ect. Fa yes, I forgot one thing, 4AD; "=$; that all whose name is on the document are aware of it, understand what it mean and approve it.
Data Migration Methodology for SAP Main '%ine%% O*1e&t% %e?'en&e of &on/er%ion
PAGE 1=
#reG$e)uired
G A9 account 4aster 7Include primary cost L revenue elements8 G #rofit centers hierarchy G #rofit centers G 5ost centers hierarchy G 5ost 5enters G Activity types .ptional Internal orders 2-" elements if #" module.
G 5haracteristics G 5lasses
4aterial 4aster
5ustomer 4aster
-.4
6endor 4aster
$outing Te t
"ource lists
"torage -ins .pen A1# .pen A1$ .pening -alances "toc!s 7648 "toc!s 7I48 .pen "ales .rders .pen #roduction .rders 5ontracts .pen #urchase .rders
PAGE 1>
, S Sa(2le
Ho3 to
The idea is to brea! the pro,ect in chun!s and then brea! each of these in tas!s. *ou then proceed to evaluate the wor!load re)uired for each of these elements. It will be much easier to get accurate and ob,ectives numbers on small specific tas!s than on a large chun!. Fow to brea! it and at which level is more an art L e perience mi than it is a science. The more 2-" you do, the better you will get at it. If your 2-" 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 followGup, it will be less accurate, since any detected slippage will involve higher number because the element is itself too big. If the 2-" is too granular, you will get lost in a forest of details and numbers. The followGup will also be much more difficult and it will be difficult to get the whole team to use it 7too comple 8. In this methodology, the 2-" I suggest is a middle ground between these two limits. I got to this one by trials L errors on different pro,ects. I thin! it is granular enough to be precise and usable for efficient followGup. *et, simple enough, for the whole team to easily contribute in evaluating the numbers.
PAGE 1@
In order to get a successful evaluation, follow these guidelines 0 ;valuate each and every element of the 2-" while ma!ing abstraction of the other tas!s. This gets you an ob,ective evaluation of each tas! independently of each other. It is important at this point to ma!e complete abstraction of calendar planning or any target date. 3orget when this should be finish or how long should it last. Tust try to figure out the real wor!load needed to complete each element of the :5 process. After that, we will see how we can meet deadline by acting on the organization of the pro,ect rather than <fi ing up< the estimate. "tarting a 2-" while ta!ing into consideration a goal to meet, li!e a specific date or target total of #erson1:ays, will only lead to complaisance planning which will be false and get you in trouble.
A&&e2tan&e load and /alidation 3ull data loading into A55;#TA/5; "*"T;4 3ull data loading into #$; #$.:=5TI./ "*"T;4 6alidation of converted data and Dey =ser R -usiness .b,ects .wner "ignoff 3ull conversion into #$.:=5TI./ "*"T;4 and final "ignoff
Total Total G at best 7total in #erson1:ays of each business ob,ect8 Total G most probable 7total at best R +' to +B( buffer8
Are yo' %'re <That much, are you sure E< This is probably the first thing you will hear when showing your 2-". In many pro,ects, the notion of estimating wor!load in #erson1:ays e ists in theory only. 2hen you actually get the numbers, it seams a lot of time and a lot of money ,ust for converting data. 2ell <,ust converting data< is an understatement, as stated earlier this is an important part of the pro,ect. A value of &'' #erson1:ays on a +' people team is not a lot of time. It adds up very )uic!ly. Tust have a + hours meeting once a wee! with seven people and it will consume two #erson1:ays each wee! throughout the pro,ect. "tretch the meeting ,ust a little hour more than e pected 7sounds familiarQ8 and the e)uivalent of a whole day of wor!, for one person, ,ust went by. Add to this the little informal meetings between !ey users, consultants and :5 team members for each business ob,ect to convert. This )uic!ly adds up to a nonGnegligible amount, and that is ,ust for meetings, no tangible deliverable is produce yet.
PAGE #A
2hen getting the numbers for the original 2-", you average each element. .verall, you under estimate some and over estimate others, but the average law will ma!e it a globally reasonable measure. Fowever, if you start concentrating on some numbers while forgetting others, the average law is out the window. This is why you must consider, both the large and small values, when reGevaluating a 2-". Fere are some suggestions I give to those concerned when reGevaluating a 2-" 0 ; plain clearly what a #erson1:ay is0 <letJs say you have only this to one tas! to do and you have to do alone, how many days will it ta!eE<. ; plain the wor! to evaluate. 3or e ample, ma!ing the conversion rules mean U tal!ing about it with the consultants and 9egacy "ystem e pertsU writing the first version U having meetings to answer gray areas U doing some tests for uncertain fields U cross reading the documents and finally, some reflection time. Therefore, as you see, it is lot more than ,ust figuring how long it would ta!e to write some lines of rules. 5ount everyoneJs time. In the above e ample, you must count time for you, the consultants, the 9" ; perts, those present at the meetings, those doing tests, etc. It adds up very )uic!ly. ; plain the average law I mentioned above and ma!e sure they do reGestimate all the elements with the same scrutiny. 2hile some high wor!load tas!s may be overestimated, some smaller one are probably underestimated as well. Avoid tal!ing about deadline or total wor!load. They have to evaluate all elements independently from each other.
I personally went through that process a few times. Interestingly in all cases, the reGevaluation turned out with a slightly higher global number. 4ainly because they realize there is more, small but still time consuming, tas!s than originally thought so.
PAGE #1
4aster. This will create collisions and conflicts, which will need meetings, discussions and testing before the issues are solved. The conversion rules are different for each 4aterial Type and it is not always the same !ey users who have the info for the different types.
.ther than the -ig 3ive, wor!load estimates are rarely lin!ed to the number of fields. The !ey is then the )uality of the 9egacy "ystem data. Fere are some factors on that will ma!e the process much longer0 Fistorical data that was never purge Inconstant data 7well, no one have these in their systems, rightQ8 #art of the data e isting aside in ; cel, Access or other non formal system Information spread into different systems /o clear owner or manager of a business ob,ect in the 9egacy "ystem 7then it is probably messy8
-e conservative, in doubt, over estimate rather than under estimate. /ever mind how much you investigate or !now the 9". There is always one business ob,ect where you will discover, at the last minute, that it ,ust will not fit into "A# without ma,or unplanned efforts. It is not bad luc!, it ,ust happens every time. -ad luc! is when you did not consider it in your planning. If the data is not e tracted from the 9" but generated manually, it will ta!e longer. The time is however more predictable as manual data is rarely bugged. 2hen you e tract data automatically from the 9", it should be faster. Fowever ta!e into account that programming means possible bugs. It also needs modifications when the rules change 7and change they will8, which again may bring bugs If you have part automatic and part manual, li!e <yes we can e tract most of it, but need to do some ad,ustments in ; cel<, add e tra time 7B' to &''( more8. At first glance, this seems li!e the easiest way to go. 2ell, itPs notQ Trust me, these will be real headaches. Although almost impossible to avoid them, try having as little as possible of these. In all cases, prefer ma imum usage of conversion rules.
all2arB fig're%
Fere are some figures to give you a ballpar! of the pro,ects I wor!ed on. These are not absolute figures, as they vary from one pro,ect to another. In pro,ects involving the modules 3I, 5., 44, ## and ":, having from +' ''' to I' ''' material master items with all related -.4 and $outings, about + ''' vendors1customers, &' ''' inventory records and all other basic :5 stuff, it gave me something between I'' to C'' #erson1:ays per legacy system. I say per legacy system and this is something important to consider. If you have different legacy systems, you tend to thin! the second one will go faster than the first. There is absolutely no gain. ;ach system must be evaluated as if it was a different pro,ect. If one ta!e B'' #erson1:ays, than two 9" will ta!e &''' #erson1:ays. This will probably be a ma,or disagreement point among the team when you will show your numbers. Deep in mind that for all the pro,ects I wor!ed on, it proved to be true. 4apping is different, conversion rules are different and issues with 9" data will not be the same. "ince these three items represent the bul! of the :5 process, you can see why two 9" will be twice the energy.
PAGE ##
-ase on the volume data from your 2-", you can calculate as follow 0 3or mapping 0 5ount &' min per field 7'.'+ day per field8 and add & day to the total for set up and e planations 5onversion rules 0 5ount &' rules per day 7'.& day per field8 :ata and $ules Adaptation 0 5ount &+ seconds 7V'.'''I&C day8 per record and by field 7number of fields records '.'''I&C8. There is more, later on, e plaining what is O:ata and rules adaptationP. number of
As you see, you need to establish how many fields need :ata and $ules Adaptation. I use a percentage in the 2-" so that I can recalculate all the wor!load easily as I learn more about the 9". -ase this on the number of fields you will populate in "A#. I usually count that about ?'( of the fields are solved by conversion rules and +'( will need data and rules adaptation. If the data are in bad shape in the 9", go toward >'(G%'(. This formula is most pertinent for 4aterial, 5ustomer and 6endor masters. 3or -.4 and $outing, the time is less dependent on the number of fields than on the comple ity of the data to e tract. 3or those two, you can use the formula and then add between B'( to &''(, depending on the legacy data comple ity. As stated earlier, if -.4 and $outing are merged in a single structure in your 9" 7i.e. multilevel8, count that -.4 will ta!e double the time you originally estimated and $outing will most probably have to be done manually from scratch. .ther than the -ig 3ive, the number of fields has little to do. It is the comple ity of the process, which needs to be ta!en into consideration. If you really count all the time spent on one business ob,ect, none will ta!e less than &' #erson1:ays. =se you ,udgment and apply between &' to %' #erson1:ays per business ob,ect according to e pected comple ity. ;ach time someone tells you <this is a one day thing<, ma!e a note of it and follow the time it really too! from start up to a loaded and validated data set H you will see, nothing ta!es less than &' days. Another business ob,ect, which is also special, is inventory. At first it loo! simple enough, but getting &''( of the data in "A# will prove to be a challenge... if you plan to shoot less than &''(, go bac! to page & of this document. If you use 24 in "A#, it will be even more challenging. If you have a good wor!ing 24 in your 9", it will be a challenge. If you use 24 in your 9" and it is not wor!ing perfectly, it will be a great challenge. If you do not have 24 in your 9" and want to use 24 in "A#, than you are in for a hec! of a ride. In this situation, consider converting without 24 and implementing it later, once you system has been stable for a while in production.
3or Inventory, count %' days for I4 R up to &'' days for 24 according to the three possible scenarios I ,ust mentioned. If you have a doubt, try finding someone who went through it before. :one right the inventory load ta!es lots of wor! but the process will go well. -adly managed it will !eep you up +Ihrs1day for a few days before A. 9ive H and after.
PAGE #.
This will not only give you a calendar date planning based on an ob,ective wor!load estimate, but it will also permit a )uic! identification of resource overGallocation, overlapping of dependant tas!s, and delay due to non wor!ing time and bottlenec!s. .n most conversion, the overload on !ey user is always a ma,or problem. *our !ey users will be strongly solicited right from the beginning of the pro,ect. Deep in mind that the more you go on with your pro,ects, the more they will be solicited to troubleshoot problems, and this will be on top of their normal conversion wor!. The result is that their availability will only get lower as the pro,ect is going on. :o not under estimate this fact in your planning. .nce you will be done with the :5 calendar planning, you must integrate it in the overall pro,ect planning and do a resources load analyses. This tas! is most difficult, time consuming and very frustrating 7especially if you do not master 4"G#ro,ect8.
PAGE #6
4ost probably, the only planning tool youJll have available will be 4"G#ro,ect. Although it is a nice tool, it also has great talent in Jauto messingGupJ your schedules 7ma!e bac!up copies H and ma!e them often8. 4y first advice is that you should learn the basics of 4"G#ro,ect before you get into it. It will be a much less frustrating e perience. "ome )uic! learning boo!s can be found and are useful 2hichever tool you use must be able to give you a resources load analysis. This will be a !ey element of you planning.
-elieve me, it is very difficult to do better than the most probable date.
Are yo' %'re <That long, are you sure E< Fere we go again, the same phenomena as in the 2-" will occur. 4any peoples will challenge your calendar planning. They would whish all could be done )uic!er, faster, easier and all in parallel. As in 2-", they will focus only on some big tas!s, generate great theories and totally ignore the overall picture and possible side effects on the overall planning caused by any change on some tas!s. $emember the part in the first section of this document, which stated <It ta!es the time that is needed.< Fere is the part where this statement ta!es most of its sense.
PAGE #:
G :o not parallel the tas! hoping to save time. There are only +Ihrs in a day and people need sleep. G :o not forget the +'G+B( margin G :o not change the #erson1:ays established in the 2-", it is the most ob,ective values you can get. G If you need to finish a tas! faster, never change an end date or the wor!load. 5hanges the resources allocations to obtain the timeframe you want H then reGvalidate the resources wor!load.
,orBload analy%i%
Fere you are, now you have to identify the resources overload and play with the tas! se)uencing until all resources are in normal wor!load. This is a very difficult and frustrating step. In addition, since 4"G#ro,ect will regularly mess things for you, 4AD; -A5D=# copies before ma!ing changes in the calendar planning. .nce the planning is done and resources wor!load is realistic, you are ready to go. At this point youJll only have to identify slippage as the pro,ect go and ta!e corrective action before it has an impact on the pro,ect duration.
PAGE #8
PAGE #=
#ro,ect !ic!Goff
Acceptance "ystem full load #re #roduction "ystem full load #re #roduction "ystem "ignoff #roduction 9oad L "ignoff
PAGE #>
3.1 OVERVIEW
This section gives you information on the ma,or steps involve for each -usiness .b,ects. ;ach person who is responsible of a -usiness .b,ect should read this. In the previous section we saw one of the methodology main ingredients. It involved mainly planning and is actually a basic management concept, which is applicable to any !ind of pro,ect, computing or other. The second main ingredient of the methodology, which will ma!e it so efficient, is the way we deal with the conversion process itself.
PAGE #@
*ouJll have to !eep in mind that these will be made by !ey users who may not be familiar with writing computing rules. Therefore, it is necessary to give some e ample and to e plain some basic !ey element in rules writing. -asic properties of a rule 0 Aeneral rules 6" 3ield $ules Aeneral rules are the one that does not yield directly to a field value. 3or e ample the way in which we differentiate the material types in the 9egacy "ystem is such a rule. 3ield rules are those that give a value for a specific field. 3ields names This is a crucial one. 2hen discussing or writing notes, A92A*" refer to a field in the form TA-9;G3I;9:. *ou will )uic!ly realize that as the pro,ect go, different people will start using different names for the same field. As well they may start using the same name for different fields. .n top of this, some fields e ist in different views in "A# master data. "ometime it is the same field that is shown at two places while other times it is really two different fields. The best way to !now which case apply is to have the TA-9; R 3I;9: information. ; ample0 In 4aterial 4aster, the field WAvailability chec!X e ists in the <4$#+< and the <"ales Aen< views. If you loo! at the TA-9;G3I;9: of each view you get 0 4$#+ 0 4A$5G4T63# "ales Aen 0 4A$5G4T63# In both cases the TA-9;G3I;9: name is the same, so it is the same field. In 5ustomer 4aster, the field < Terms of #aymentJ e ist in <#ayment Transactions< and <-illing< views. If you loo! at the TA-9;G3I;9: of each view you get 0 #ayment Transactions -illing 6iews 0 D/66G NT;$4 0 D/-&G NT;$4
It is not the same field. In the payment view, the field is lin!ed to the 5ompany 5ode while for the -illing view it is lin!ed to the "ales .rganization 7you find this by loo!ing at the tables !eys8. "o both of these fields can have different values. "hort and clear $ules should be short, using I31;9";1;/: structure as much as possible. 4a!e certain that the use of A/:, .$ and 7 8 is clear. A long sentence embedding many A/: L .$ will most probably be wrongly interpreted. :o not hesitate to spread the rule on many lines, ma!ing it easy to read. 5hun! of te t is difficult to read.
PAGE .A
This is not clear enough, Fow do we !now which product are <sold semiGfinished<. This must be clearly stated in the rule or be part of a general rule. =sage of discrete values in au iliary file In some case, it is impossible to group items or to get values by rules. 6alues must be entered manually. In this situation you must enter these values in a separate file 7usually ; cel8 using a search !ey 7li!e the item number8 and specify in the rule to use the au iliary file. In the rules document, all tables must be specified li!e the following 0
PAGE .1
Aet each domain with their consultants to go through the mapping file and loo! at the fields for each material type. The goal here is to see all the fields that are important and as! )uestions to understand them. 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 will we get them. T="T A;T TF; 4A##I/A :./; and wor! on understanding what material master is. ;ach time a domain select a field for a specific material type, they must enter their domain type in the list. Fere are some 7theoretical8 e amples of mapping from 44, ## and ":
,hat to do 3hen the %a(e field i% fo'nd in different /ie3% In 4aterial 4aster, some fields can be entered 1 modified in different views. 3or e ample, the field Aoods receipt processing time in days 74A$5G2;-AN8 e ists in views #urchasing, 4$#+, Suality management. 2hen doing the rules and the load program, the same field canPt be in different views. To solve this, proceed as follow0 "ee with all implicated domains who is the lead for the field and decide in which view the field should be included.
PAGE .#
Ta!ing the e ample of the field Aoods receipt processing time in days 74A$5G2;-AN8, it can be decided among the domains to put it in the #urchasing view 7and nowhere else8. This means that #urchasing is the lead on this, but do not stop other domains to use it of have specific rules for it. It is however #urchasing role to ma!e sure this field is used correctly. -e careful, ma!e sure it is really the same field. 3or e ample0 In 5ustomer 4aster, the field < Terms of #aymentJ e ist in <#ayment Transactions< and <-illing< views. If you loo! at the TA-9;G3I;9: of each view you get 0 #ayment Transactions -illing 6iews 0 D/66G NT;$4 0 D/-&G NT;$4
It is not the same field. In the payment view, the field is lin!ed to the 5ompany 5ode while for the -illing view it is lin!ed to the "ales .rganization 7you find this by loo!ing at the tables !eys8. "o both of these fields can have different values. SPE!IAL M$LTI 7IE,S In can however happen that no specific domain can be identified as the lead or main user of a field. 9etPs ta!e for e ample, 44 1 ## status 74A$5G44"TA8 which is in views 0 purchasing, 4$#&, wor!scheduling, costing &, )uality management. If no one can be clearly identified as the lead for that field, then we put it in a dummy view called "#;5IA9 multi views. This is used to put all the fields that e ist in different views and for which we canPt assign a lead functional. +nd step 0 $egroup selection of all domains .nce this is done for each domain, than you 7the :5 manager 8 have to put together all the results. This would yield something that loo!s li!e this 0
%rd step 0 -uild the data conversion rules template with all the selected fields. "pecify for each field, which domain selected it. If more than one domain selected the same one, put the name of all the domains who selected the field.
PAGE ..
Ith step 0 Aet the rules from each domain, independently As! 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 ne t step. Bth step 0 4erge the rules from all domains. 4a!e a single document that contains all the functional domainJs rules and note, for each one, which domain wrote it. Cth step 0 Analyses of the results and creation of the Issue list. At this point, I usually create what I call the S=;"TI./" 9I"T. It is a simple 2ord document where I put all the )uestions, the name of who is responsible for the solution, creation date, target date 7with history if the target is changed8. #repare yourself for a very long list at first. I usually endGup with an average of + )uestions per field. Therefore, if you have %'' fields, that is C'' )uestions. And if you happen to merge % 9egacy "ystems into one "A#, you will have C'' )uestions per 9egacy "ystem. H That is &?'' )uestions. 4ost of these will be )uic!ly dealt with, they are unclear rules or obvious problems that get solved within the first wee!. .ne interesting thing that usually happens here is rules conflict. This happens when more than one domain use the same field and they come up with contradictory or incompatible rules. 3inding this at the beginning of the process will be a great time saver, as you ,ust identified important issues between domains before you developed anything. .ne of the main challenges of implementing "A# is integration of the different functional domains into a single product. 3ailure to understand this is will get you into trouble, and this is true for all the "A# implementation process, not ,ust the :ata 4igration part of it. As the pro,ect goes, the S=;"TI./" 9I"T becomes the data conversion T.:. 9I"T. Anything that is promised, due, scheduled or to be given must be noted there.
PAGE .6
*ou now have 4aterial 4aster conversion rules documented and a T.:. 9I"T to follow up on the issues to be solved before you can load the data.
PAGE .:
PAGE .8
R$LE
/ote that "A# term "ecurity deposit e)ual $etention in #$4" Type of transaction T*#; field in #$4" 0 #artial #4T0 #ay. 5redit 4emo0 5r 4. :ebit 4emo0 :r 4. Invoice 0 Inv. /on A1$ cash0 /on A$ Ad,ustments0 Ad, Any other type is an error. 6alidation to apply both at e traction and load. #artial #4THHH. must be negative in #$4", if not ;$$.$ 5redit 4emoHHHmust be negative in #$4", if not ;$$.$ :ebit 4emoHHH.must be positive in #$4", if not ;$$.$ InvoiceHHHHH..must be positive in #$4", if not ;$$.$ Any other type is an ;$$.$. 9"4 9oad parameters DT.#9 G 5hart of account 0 5A'' -=D$" M 5ompany code0 ''>' A"-;$ G -usiness Area 0 ''I' -=:AT M #osting :ate 0 'BG%&G'+ or last day of last closed period. .33";T M Account 7+8 0 $;#$I";59 "D#;$$ M "!ip err 0 K
A''+
A''%
PAGE .=
Dire&tory organiCation
As you go, you will end up with lots of documents and versions. To store the different files on your local server, use a specific directory structure. I suggest having a structure with a directory for each -usiness .b,ect to store all the files relevant to the data conversion. Fere is an e ample. 50Y. Z[ :ata 5onversion \ \ \ Z[[[ '' G .rganization \ \ \ :5 #9A/ \ \ \ :5 2-" \ \ \ :5 "5F;:=9; \ \ \ \ \ ][[[[[ .ld \ \ ^ "tore here previous versions of above mentioned documents _ \ \ \ Z[[[ '& G 4aterial 4aster \ \ \ 4aterial 4aster G 3ield "election "heet. ls \ \ \ 4aterial 4aster G :ata 5onversion "pec.doc \ \ \ ^ Deep here only the latest version of each document _ \ \ \ \ \ Z[[[[[ .ld \ \ \ ^ "tore here previous versions of above mentioned documents _ \ \ \ \ \ ][[[[[ 2or!ing 3iles \ \ ^ #ut here various wor!ing files _ \ \ \ Z[[[ G-. name \ \ \ -. G :ata 5onversion "pec.doc \ \ \ ^ Deep here only the latest version of each document _ \ \ \ \ \ Z[[[[[ .ld \ \ \ ^ "tore here previous versions of above mentioned documents _ \ \ \ \ \ ][[[[[ 2or!ing 3iles \ \ ^ #ut here various wor!ing files _
PAGE .>
If you are not familiar with 4"G2ord change trac!ing I strongly suggest that you get ac)uainted with this functionality.
This all happens because of a certain 4urphyJs and there is no way around it.
PAGE .@
4ost of the time, when you do not begin any programming until all e tract and load rules are &''( clear 7and I mean &''(8, there is a tendency to thin! that you ,ust ma!e everyone loose time. /ot so. If you found issues at this point, it means that there will be errors in the process and you will have to address these issues anyway. It ,ust will be more difficult and time consuming to do it after the programming is done than now.
+.
%. I. B.
C.
PAGE 6A
If you start running in all directions and canPt !eep you head out the water, "T.#, and go bac! to step &.
3.3 Lo!" U#2% T $%2#Fere 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. 2e are more concerned about going through the load cycle without "A# stopping us, rather than validating the correctness of the values. 3or this we use a very small volume of data, usually creating data manually from scratch rather than using real e tracted data. The !ind of issues you usually encounters at this point loo!s li!e the following 0 "ome mandatory fields are missing "ome dependency between + fields in one view where not considered and you canPt load as e pected Invalid values where given to you in the rules ;rrors in the load programs =sing a load program, "A# did not behave as you e pected 7it sometimes behave very differently with a load tool than it does with manual data entry8 As mentioned earlier, the conversion process is iterative. 3ollowing the issues youPll find here, you will have to go bac! to the functional !ey user, find solutions and document them in the specs 7this is the responsibility of the !ey user8.
After each load, the functional that is responsible for the business ob,ect must validate the data. This is time consuming and must be done as soon as possible. $emember the bottlenec! with !ey user I mentioned earlier in the planning section, the farther you are in the pro,ect, the less availability youPll get from the !ey user responsible of the -.. 3inally, of course, following the issues you will find here, you will have to go bac! to the functional !ey user, find solutions and document them in the specs 7this is the responsibility of the !ey user8.
3.9
-efore going into preGproduction, you must be able to start from an empty "A# client, e tract, load &''( of the data, and have full data validation from the -.Ps !ey users and the -.Ps .wners. 3rom this point on, if you change something, you must redo a full e tractGloadGvalidation cycle for the -. affected. 3ailure to do so 7i.e. ma!ing last minute changes and not validating them full size8 will @@( of the time creates bugs in the load process at production time. Again, to achieve this you will need lots of discipline. 2hile you can correct bugs in dev, it is difficult to correct them in pre prod 7and suicidal8. If at the end you load in production and create data inconsistencies, it can ta!e up to a year to correct this. -ecause the production system is living its own life and canPt be controlled as in dev, correcting 4aster :ata errors is li!e shooting a moving target H the more you try to fi it, the more you seems to brea! everything around it. I
PAGE 61
have seen teams cheating on this step and still have corrupted -.4 after a year. "ince -.4 affect #urchasing, 5osting, 4anufacturing, Inventory, etc. you can imagine in which condition their "A# got after a while.
3.;
"ince you went through all the steps and followed all the methodology guidelines, this is ,ust a formality. *ou do a full load in preGprod, starting from a copy of prod and doing everything e actly as you will do in prod *ou get the whole thing validated by the -.Ps !ey users and the -.Ps .wners Then you get written signoff from the -.Ps .wners that all is AG.D 7insist to have it written, not verbal8 After, you do the final production load and get final signoff 3inally you have nothing else to do, as by following this methodology, you managed to load &''( accurate 4aster :ata and no rewor! is needed 7yes, this happened to me for real8
Fere are the guidelines to follow here. Again simple but re)uiring a lot of discipline 0 :o not change any e tract1load programs to correct errors found in reGprod. It is better to ma!e manual corrections or create programs the correct the data after loading them. This way you do not induce regression into the e tract1load process. 2hen it is time to load in prod, do e actly as you did in pre prod, and then apply the manual changes or run the data correcting programs e actly as you did in pre prod. If you must change the anything in the load1e tract process or programs, you must again do a full preG prod load test1validation of everything.
PAGE 6#
CONCLUSION
/ow you !now how I did different 4aster :ata migrations faster and better than others did. I successfully used this methodology in different industries, in different countries and with starting pro,ects as well as with pro,ects already running which needed to be turned around. The methodology itself is mainly a mi of good old common sense and management &'&. ;ach step is the foundation needed for the ne t step. 5omplete each step at &''( and the ne t one will be easier. This will have a snowball effect, permitting you to gain more speed from step to step. /ot following this rule will also have a snowball effect, but in the other direction, reaching a point where the conversion process becomes totally out of control. The difficulty is not in understanding the methodology. #ressure to show rapid results 7any results8, tendencies to push forward issues so we can !eep progressing, and resistance to slow down when the process starting to get out of hands. These are the most difficult challenges you will have to overcome in order to complete each step at &''( Although it may sometimes loo!s to others that you are ta!ing the long route to get there, remember that the ob,ective is not to finish a specific step A"A#. The goal it is to complete the whole process in the best time possible and to deliver a complete set of 4aster :ata that will not need rewor! once in production. This is how I managed to !eep my head above the water and continuously see where we are going, even when everyone else seems to be in crises.
PAGE 6.
PAGE 66
" , S te(2late
WBS Template.xls