Whether you are doing a single instance reimplementation, a system consolidation, or an upgrade rollout you will need to blueprint the differences between your current state and what needs to change for your future state. Depending on your SAP reimplementation approach there are several key considerations in the SAP reimplementation blueprint.
All three approaches require a few key steps:
- rationalize your landscape,
- consolidate your functionality scope,
- evaluate data differences and consolidate custom field requirements,
- inventory and eliminate as much custom code as you can,
- design for usability
SAP System of Record
Probably the first decision will be the SAP system of record. This simple concept seems to escape many consultants, clients, and project managers. Deciding which system will be the “source of truth” for any particular processing stream is critical. That decision determines landscape architecture, how data conversion decisions are made, interfaces, and how to reconcile data. I’ve seen so many meetings and discussions which spin forever because there is no clearly defined “system of record” for a particular processing stream.
If you have a single instance of SAP and are looking to undo some of the prior custom coding then this decision is easy. If you have a diverse SAP landscape it would be hard to imagine that you do not have one of them that you do financial consolidations or house a central chart of accounts. That system would most likely be the candidate for the “system of record”.
Depending on how fragmented your SAP landscape is with multiple SAP instances in various locations the decision may not be so easy. Even with a central system where you do financial consolidations or official reporting it may not be the best candidate if there has been a lot of custom development work. One of the “satellite” SAP instances may be a better starting point if it has remained fairly close to standard. You will have to carefully evaluate which system works best for your needs. Ideally this system would be the one which has the least amount of custom coded requirements.
SAP Organization Structure
You will want to take a hard look at reconciling and adjusting your SAP organization structure. Whether it is a system consolidation, a rollout, or a single system reimplementation the organization structure is the base you build the system on. The organization structure becomes the foundation for your master data requirements, reporting requirements, and key functionality decisions.
A properly done organization structure can enhance reporting functionality without dramatically increasing the amount of master data maintenance. However when it is poorly designed, as you may have discovered, it can create a data maintenance nightmare and still not provide key actionable information. This raises another consideration for a re-implementation –, if you have a significant investment in custom developed reports they will need to be revisited.
In some cases, even the extra expense of the additional reporting requirements may be justified if the new organization structure provides you with enhanced reporting capabilities or simplifies some of your processes. The key to remember here is to look past the short term to the TCO (Total Cost of Ownership). If the changes might have a 3 – 5 year payback horizon it may be justified. Especially when you consider any future upgrades with the more “stable” organization structure, quicker turnaround, lower cost, less regression testing, outside talent which can come up to speed quicker, etc.
- SAP Reimplementation
- https//usngerip datamanagement it
- usngerip datamanagement it
- https/:usngerip datamanagement it
- https://usngerip datamanagement