Whether you are doing a single instance reimplementation, a system consolidation, or an upgrade rollout, you will to blueprint the differences between your current state and what needs to change for your future state. Depending on your SAP reimplementation approach, you should make 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, and
-
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, data conversion decisions, interfaces, and data reconciliation. I have seen so many meetings and discussions that spin forever because the project lacks a 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, you should have a system where you do financial consolidations or house a central chart of accounts. That system is an ideal 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 a central system where you do financial consolidations or official reporting may not be the best candidate if it was significantly custom developed. One of the “satellite” SAP instances may be a better starting point if it has remained fairly close to standard. As a result, you should carefully evaluate which system works best for your needs. Ideally, this system would be the one that 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, it can create a data maintenance nightmare and still not provide key actionable information. This raises another consideration for a reimplementation: 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). Changes that might have a three- to five-year payback horizon may be justified. In particular, any future upgrades with the more stable organization structure allow for quicker turnaround, lower cost, less regression testing, outside talent that can come up to speed quicker, etc.
