Business Solutions with SAP

SAP Landscape Consolidation

February 13th, 2012 by
SAP Landscape Consolidation Direction

SAP direction

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.

Related Posts:

Key Design Considerations for SAP Reimplementation

February 6th, 2012 by
SAP RE-implementation

SAP RE-implementation

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: 

  1. rationalize your landscape,
  2. consolidate your functionality scope,
  3. evaluate data differences and consolidate custom field requirements,
  4. inventory and eliminate as much custom code as you can,
  5. 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.

Popular Searches:

  • SAP Reimplementation
  • https://usngerip datamanagement it/

Related Posts:

SAP Reimplementation Method Key Considerations

January 30th, 2012 by
SAP REimplementation

SAP Reimplementation

Among three variations for SAP software re-implementations there are two key approaches.  You either make the changes to your existing production system (or a cloned copy of it) or you make the changes in a pristine, newly designed environment. 

SAP Cloned Production System “Re”-Implementations

Making changes in your existing production system (more likely in a cloned instance of it) helps ensure data consistency and ease of adjustment, however there are several difficulties involved.  If you have a significant number of custom-coded solutions you will have to fight them every step of the way.  You will have to work around them, deal with them throughout the process, adjust any out of date coding, and most likely will end up keeping many of them.  As you can tell, I’m not a big fan of an SAP reimplementation in a production system with lots of custom coding.

You either make the changes in your existing production system or in a newly installed instance with no data.

For example if you decided to consolidate organization structures from a multi-system environment you might quickly discover lots of hard coded values in custom programs.  These hard-coded values in the programs themselves, rather than using table driven values and parameters, can cause system consolidation nightmares.  This is just one type of problem from many of the custom-coded solutions so often provided.

Another problem occurs with any of the existing system configuration.  If you make changes to existing objects that are already in production you have the challenge of timing and coordinating your cutover to prevent disruption to existing processes.  Depending on your circumstances if you decide to do a transition in your own production system with the eventual goal of moving away from it and into  cleaner environment then it may be best to create all new custom configuration objects.  You have to make that determination.

Clean SAP Re-Implementation with Old Legacy SAP for History

The other approach to SAP re-implementation is to do a re-implementation in a clean, non-modified system.  That approach assumes that after conversion to the newly designed environment you will leave your old “legacy” SAP system in place for reference and historical data only.  Using a new system for a re-implementation means that you do not have to work around any of the bad setup or design decisions that were made previously.  You avoid all of the headaches with the custom programs and only bring in those custom programs that are really business critical.

If necessary, and if you already have a BI / BW / or other reporting system it will require some additional work to integrate old data structures with new.  However even that will be easier with standard functionality.  The SAP BI / BW / BObj reporting options already contain a number of standard extractors that can be used more easily and with less expense.

The Optimum Solution is a Phased SAP Global Instance Harmonization

The most cost effective way I have found over the years to do a reimplementation is to bring in an operation that is moving to SAP in a “clean” environment.  It is not particularly complicated to integrate two SAP systems using ALE (Application Link Enabling).  In this way you create a new environment, with more up to date and more standard functionality that you can eventually migrate other business units into.

As upgrade projects occur it is only incrementally more expensive to migrate the upgraded companies into the less customized environment.  With an upgrade you still have to do the custom ABAP program reviews, code validations, etc.  With a cleaner environment that does not have all of the custom coded artifacts it is much easier to pick and choose what is really of value and what can be replaced by new, or better understood functionality.

For additional rollout locations there is virtually no additional cost over the rollout project for bringing those companies or organizations onto the more standard SAP environment.  In fact, the reduced custom coding would tend to be less expensive because the amount of time spent regression testing custom functionality, or fixing any organization specific settings, as well as training people how to deal with some of the custom functionality would be lower.  Consulting time, and therefore consulting cost, would be lower as well because the closer you stay to standard the larger pool of resources there is available to make or adjust system settings rather than work with custom programs.

SAP Organization Structure and Master Data Harmonization

One other possible project approach is to do the SAP Org Structure harmonization in all of the separate SAP global instances and then agree on the common master data types.  At “go-live” you extend all of the existing data in each production instance to begin executing with the new structure and master data types in each production instance.  By doing this, the “legacy” data and “legacy” org structures stay in place so that little or no business disruption occurs.  A transition period of approximately a year is needed to complete at least one full annual financial close under the new structures and data in the existing production system.

By using this approach you are actually making the transition in two-steps.  First you build out the new state in your existing system,  then after flushing out and adjusting most of the issues you do a conversion or cutover to a clean system after a financial close.  This approach allows for an orderly transition from the old to the new with relatively little business disruption.  While the old SAP org structure elements and master data types are being made “obsolete” they are still available for all processing and reference purposes.

Some of the key considerations for this approach involve what to do with custom coding and how to transition the master data.  It is impossible to know what custom coding is in place that might be replaced with standard functionality.  However some new data types may help resolve the issue of moving off the custom coding in the same system.  Eventually the goal would be to upgrade away from the custom coding and into more standard functionality unless there is some clear business justification preventing this.

Popular Searches:

  • https://usngerip datamanagement it

Related Posts: