Archive for April, 2009

How Should I Structure an ERP Migration Team?

Saturday, April 4th, 2009

 Firstly, if the team is of any size you will need both a manager and a deputy(s). Major DM management requires one executive manager setting the team’s direction and talking strategy, plans and requirements to the rest of the implementation programme and at least a second team lead dealing with issues that are impacting the team day to day, progress to plan etc. while acting as an analyst themselves.

Then look at the ERP facing or To-Be facing analysts: Plot out the target data objects that are likely to be required: material master, vendor master, open orders etc., and separate them into groups that would face off with the process teams. Process teams often arrange along lines suggested by the ERP vendor. For SAP this would be one for Finance and Controlling (FI and CO) one for Sales and Distribution (SD)… Pairing the To-Be migration analysts with the process teams who need the data allows them to bond as a cohesive design and upload unit. These To-Be facing analysts should be hired early an initially donated to the process team as ‘extra hands’. You can retrieve them into migration proper and they will already know all the people in the business and process teams, what’s going on with the design and how to get design updates. What do these analysts do? Together with the process team they come up with the target side of the mapping sheet and understand what it means in detail. They then obtain legacy data to match, from the ‘As-Is’ facing analysts (below) or by data creation ensuring there is a good bond between the legacy data, created data and ERP requirement. They also write and execute the the upload scripts so typically they need to know how to do that (typically LSMW and ABAP for SAP).

Your legacy ‘As-Is’ analysts need to start early enough to gain a thorough understanding of the data in your systems. Typically they will be a mix of people who already worked with the old systems and specialists who have been involved in SAP migration before, bring life-cycle experience and special techniques such as data profiling. Some ERP systems can be more fussy than legacy for example SAP on addresses, so the old data that used to be OK may now not be. You need to know what’s really in the old system, not what people and designs say there is. When planning the legacy side of the team you need to allocate analysts to groups of connected existing systems, not to the target as per the ‘To Be’ analysts. The job of your own experts is to thoroughly understand the reality of legacy, write or specify the extract routines and talk to the To Be analysts. The external experts will usually move towards arranging the necessary data cleanse in conjunction with the programme change managers.

Finally you need a small group of transformation analysts in the middle. Typically they execute rather than understand and are directed by the As-Is and To-Be analysts as to which extracts go to which targets. Expertise depends on method. You may need Datastage, Informatica, SQL Server or MS Access expertise depending on choice of transformation tool. The above is for large migrations. For smaller, scale it down and have people double up on a few compatible roles, but maintain the ethos/pattern.Well that’s the method. If you would like me or one of my associates to help you plan and implement it my blog is at , our website at and the telephone number 0794 109 5082

First posted on www.datamigrationpro ‘Ask an Expert’ 

(c) John Platten and DataMigrationPro