For any number of reasons many companies who run SAP end up with fragmented and piecemeal landscapes. It happens for lots of 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 scattering pieces everywhere.
More and more I am seeing companies looking to consolidate onto either a single platform or at least a few regional platforms. This makes sense for a lot of reasons. It is easier and more cost effective to manage user licenses, engines, solutions, and create centrally supported business processes.
Getting the SAP application space all together makes it simpler to manage and helps to control overall costs–, both from a solution cost perspective as well as internal maintenance. Done properly a consolidated SAP landscape can help to reduce TCO and improve your ROI.
SAP Total Cost of Ownership is reduced by more than just any hardware or architecture savings, there are also real savings in the ability to centralize support and maintenance. Your overall consulting costs will be reduced as well because in a fragmented environment any consulting efforts that are needed in the broader enterprise tend to be duplicated as well as fractional. On top of that there is also the cost of bringing each of those fragmented consulting resources “up to speed” on that particular business unit. Then there is the cost of short-term spot consulting. I’m sure I’m not alone here but on shorter engagements I charge a higher rate than on longer term engagements. And those are just a few examples of the impact on SAP TCO.
If you are considering an SAP application consolidation all of the previous posts and information on re-implementation are very 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 like SAP ERP, CRM, BW / Business Objects, and HR, there are many engines SAP also licenses and 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 across the enterprise. And the list goes on.
There are also struggles even after a successful consolidation. One of the better components which likely led to some of the fragmentation was the autonomy and freedom to set up the system to run it the way the business thought was best. In a consolidated environment that freedom becomes more difficult because it must be coordinated with all of the other players.
Even though there are benefits there are still a few drawbacks. But many of these drawbacks were the same things you likely considered when each SAP instance was used to replace some 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 there is the issue of defining global standards around data, authorizations, user provisioning, development, processes, etc. How you will segregate legitimate needs for differences between the various businesses? What are your processes for this? There are also political realities. It is tough to get some very profitable or flagship business units on board with these types of initiatives.
Then there is the issue with how do you start such an initiative? 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 with a location that is in need of an upgrade. 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 “central” instance as time goes on. This way each phase can take lessons learned, refine project standards, improve on delivery processes, enhance deliverable templates, etc.
And then there will be the issue of negotiating agreements with SAP that allows 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 help with determining what a new contract or license agreement should look like. For example I work with a company called “NPI Financial” from time to time. There are others out there but this is also an important component of your landscape consolidation.
Good luck on the journey and if you need architecture, solution, spend management, or other consolidation help please feel free to reach out and contact me.