For any number of reasons, many companies that run SAP end up with fragmented and piecemeal landscapes. This problem happens for many reasons: roll-outs, independent Business Units, mergers and acquisitions, immature software procurement processes, lack of a Software Asset Management program, etc. The results can leave your SAP application and business solution looking like someone set off an explosion with scattered pieces everywhere.
More and more, I am seeing companies work to consolidate onto either a single platform or at least a few specialized platforms. This makes sense for many reasons. A single platform is easier and more cost effective to manage user licenses, engines, and solutions, creating centrally-supported business processes.
Getting the SAP application space all together allows for simpler management and controls overall costs– both from a solution cost perspective as well as internal maintenance. Done properly, a consolidated SAP landscape can reduce TCO and improve your ROI.
Hardware or architecture savings are not the only things that reduce SAP Total Cost of Ownership– centralizing support and maintenance does as well. Centralization reduces overall consulting costs as well, because in a fragmented environment, any necessary consulting efforts for the broader enterprise tend to be duplicated as well as fractional. Additionally, you have to also address the cost of bringing each of those fragmented consulting resources “up to speed” on the unique and segregated system along with its integrations. Then, you must deal with the cost of short-term spot consulting. On shorter engagements, I charge a higher rate than on longer-term engagements– and I’m sure that I’m not alone.
If you are considering an SAP application consolidation, all of the previous posts and information I have written on re-implementation are similar to what you deal with on a consolidation.
Consolidating Fragmented SAP Solutions
Because of SAP’s focus on business application solutions, their application footprint tends to expand into many areas of the business. Aside from more traditional application offerings such as the ERP application, CRM, Data warehousing and reporting, and HR, SAP also licenses many engines (or instances in the Cloud). You can quickly end up with a jigsaw puzzle of SAP solutions spread around your enterprise.
Done properly, a consolidated SAP landscape can help to reduce TCO and improve your ROI.
Over time, this jigsaw puzzle leads to licensing headaches where you can be over-licensed or under-licensed, even on the same SAP solution across instances. You can end up with a huge architecture headache where the hardware, interfaces, infrastructure, security, and usefulness of the systems are impacted. Remote use of the systems creates duplicated access and duplicated security problems. Reporting across the various solutions becomes little more than critical compliance rather than business insight. The list goes on.
Even after a successful consolidation, you will face struggles. One benefit the business had before (which likely led to some of the fragmentation) was the autonomy and freedom to set up the system how they thought was best. In a consolidated environment, that freedom becomes more difficult because they must coordinate the set up with all of the other players. This tension, while difficult to manage, allows you to corral your solutions so they stay somewhat closer to standard.
Even consolidation has benefits, you will still experience a few drawbacks. However, many of these drawbacks are the same issues you likely considered when you used each SAP instance to replace a legacy application.
Where Do You Begin SAP Landscape Consolidation?
Just like with an SAP reimplementation, one of the first decisions to make will be whether to use an existing system as your starting point or whether you should do a “clean” start with part of the application landscape? My personal preference is to start clean and challenge any custom development as to how necessary it really is. That is one issue.
Then you face the issue of defining global standards around data, authorizations, user provisioning, development, processes, etc. How should you segregate legitimate needs for differences among the various businesses? What are your processes for this? You also have to deal with political realities. You will struggle to get profitable or flagship business units on board with these types of initiatives.
Additionally, you have to consider the number of production systems. While everyone touts the desire to get to one, single, centralized system, that is not always practical. Some companies with business units are so disparate, and some vertically integrated businesses are so different, that maybe two or three production instances makes sense. That is far better than many far flung enterprises I have seen with fifteen, twenty– or in some very large corporations, even more than a hundred production instances. If you do more than one production instance, how do you differentiate which divisions, businesses, or operation types go into each one? Maybe one is completely vanilla; maybe another needs a fair amount of customizing for legitimate business reasons. Maybe you have FDA or ITAR regulations, so segregating those systems and processing makes sense.
Then, you must address how to start such an initiative to consolidate and move back to standard. Once again, I suggest you begin where it makes sense, and where it has the least financial impact. Begin with either a rollout location or a location that is in need of an upgrade or legacy ERP system replacement. While the effort and impacts are different, the project work and some budgeting around these areas is already being planned for. It is just a matter of systematically rolling any upgrade or rollout efforts into the newly determined instance(s) as time goes on. This way, each phase can take lessons learned, refine project standards, improve on delivery processes, enhance deliverable templates, promote knowledge transfer, etc.
Finally, you need to deal with the issue of negotiating agreements with SAP that allow for the changes in the application footprint and user licensing. Do not underestimate this effort. At this point, I would suggest you hire an outside IT spend management firm to determine what a new contract or license agreement should look like.
Good luck on the journey! If you need architecture, solution, spend management, or other consolidation help, please feel free to reach out and contact me.
