Data Migration

Implementing CRM is an important challenge, both in terms of resources (people, money, time) and in business process. A lot is at stake and failure is not an option one can afford. To offset all potential failures, we need a good methodology which provides 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.

Download

An important part of CRM challenge is process of putting legacy data into new SAP CRM System. This process consists of Data conversion and Data transfer to CRM Application .Previous implementations of SAP have shown that data migration can amount up to about 40% of the entire project. Poor data conversion could make “Go Live” very difficult, if not impossible.
Precaution

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 one 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 that is the most difficult. Getting the right data at the right place with the values required for particular business process is generally a functional problem.

SAP is a process-oriented system and master data is an integral part of this process. Nice, but what does it mean? The answer is that everything is tied together. Master data is dependent on the customizing, the customizing is made accordingly to the way you do your process, and master data is needed to run your process. If one changes master data, it will most probably change the behavior of the process. If customizing gets changed, master data may become incomplete or incorrect.

Core team must do a thorough analysis of the master data and link their usage to the process customization. We 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.

Core team should be driving the Mapping and conversion rules building exercise. They should do mapping & rules documents. The mapping document and conversion rules will become the common ground for discussions between the different domains. Dependency of data 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. 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. Again, take the time that it gets to have clear and unambiguous conversion rules. When 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 extract and load programs.