Approach framework for SRM Upgrade

[Former Member]

Applies to:

All SAP’s Supplier Relationship Management version (technical) upgrade

Summary

This paper outline the basic aspects of an SRM upgrade any organization should know when considering or evaluating such projects. This will help facilitate a better overall approach to upgrade, reduce the hurdles, significantly plan well ahead to mitigate any risk and incorporate contingency.

Author(s):    Sachin Rao

Created on:  March 1^st, 2013

Author Bio

Sachin a Mechanical Engineer by education has been in the field of SAP consulting for over 8 years, having core expertise in the modules of SRM, MM and WM. He has worked on several projects in SAP comprising implementation, roll-outs and support engagements. He has a good understanding of the business and its drivers especially in Automobile, Chemicals and Petroleum and Banking Domain. He is also the author of the whitepaper ‘Need of Post Implementation Audits for ERP Implementation’ & ‘Due Diligence & ERP’

Introduction

From the stakeholder perspective there is a basic requirement for understanding the various aspects of an SRM upgrade. The purpose of this document is to provide this understanding and also outline the approach an organization has to / can take when considering upgrade to their existing versions of SAP SRM system. This also provides some insight on the impact from the technical and business process perspective. Although majority of the points covered will be part of any / many SRM upgrade project, however this may vary to the extent of emphasis each aspects may have based on the business, the client is involved in and how integrated the procurement function of indirect procurement is embedded within the organization.

Evolution SAP SRM since inception

The companies having SRM are on various versions ranging from BBP to EBP to SRM as listed below, the latest version being SRM 7.0 = SRM2008

SAP BBP 2.0B = SAP EBP 1.0 Basis 4.6C                 

SAP BBP 2.0C = SAP EBP 2.0 Basis 4.6D                    

SAP EBP 3.0 = SRM 1.0   Basis 610 (BBPCRM 3.0)          

SAP EBP 3.5 = SRM 2.0   Basis 620 (BBPCRM 3.5)                      

SAP EBP 4.0 = SRM 3.0   Basis 620 (BBPCRM 4.0)          

SAP EBP 5.0 = SRM_SERVER 5.0= SRM 4.0                   

SRM_SERVER 550= SRM 5.0                                 

SRM_SERVER 600= SRM 6.0 = SRM2007

All the SRM versions up till EBP 4.0 (SRM3.0) if upgraded then it has to be a 2 step process, one to upgrade it to SRM5.0 and then to SRM7.0. For all latter version a single step upgrade to SRM7.0 is possible.              

Context for Upgrade

To understand why an organization think of investing time and money in upgrading an existing system when an equal if not less cost has been invested in implementing the system.

There are some important factors which drives an organization to consider the upgrade of their existing system. The below are the list of factors majorly considered but not confined to these

• The support for the existing version of the system is running out in the near future, in which case the premium support will/may cost more than upgrading the existing system
• The existing system has been customized to such an extent that it had become difficult to support , add new standard updates to the system and due to this the cost of maintaining this system is high
• The existing version is not compatible with some of the latest interfaces of the business application

If any one of the above points fits into the consideration of any organization then there is a need to take the next steps in the direction of approach to upgrade.

Myth about Upgrade

Any SRM technical upgrade will not be a purely technical upgrade, this will come along with some functional changes which will impact the process to a certain extent like

• User Interface change because of the change from ITS to Webdynpro
• Change in the authorization objects impacting the roles defined in the previous version
• Migration of custom objects from the previous version to the new version may need some workaround in the new version to be embedded

Thus it will be worthwhile to start engaging with the business or process owners as early in the project as possible, this will reduce any noise coming from business and also help build a more efficient version of SRM with early collaboration.

Approach to Upgrade

• Before you get into making a plan for an upgrade, the first step to be taken is understanding if the upgraded version provides enough capabilities to support the existing business functionality
  • For doing this it will be worthwhile to have a workshop with Business and IT along with the expertise of the application/service providers to demonstrate the capabilities of the upgraded system
  • The outcome will give an indication if the techno-functional upgrade of the existing system will satisfy the existing business process with minor customization  or a new implementation of the latest version will be suitable
• Based on the decision that comes out of the above exercise then the vendor should be asked to do a technical assessment to get an overview of the Order of Magnitude (OoM), to get a ballpark estimate how much budget should be set aside for the upgrade project
• After the organization has the understanding of the OoM and agree on the budget then the relevant project can be initiated incorporating all aspects of the project at high level
• Once the project is initiated there has to be a Quick Upgrade Evaluation (QUE) done to understand the scope, pre-requisites, technical objects, dependencies, assumptions & effort estimate. In this stage a detail analysis of all
  • Scope – clearly demarking what entails in the technical upgrade like for ex- whether data migration is a part of the upgrade
  • Pre-requisites required for the upgrade is listed out like the database version, Operating system, etc
  • Technical objects – the details of the technical objects which will have to be migrated to the new version as part of the upgrade XXX
  • Dependencies for the upgraded version in terms of any new infrastructure ex – SRM MDM should be in place for catalogues
  • Assumption which will have an impact of not clearly mentioned has to come out in the scope
  • Project Estimate – this should give a clear breakdown of the activity list and the efforts for each of the activities
• At this point there may be some open questions which may still need to be probed into like the existing hardware is sufficient enough for the upgrade or additional sizing needs to be done to accommodate the requirements of the new version
• Once we have complete the above activities and have answered some or all of the open questions then the next step will be to come up with a detailed project plan
• When developing a detailed project plan the following additional points has to be considered and listed in the plan
  • Number of infrastructure components requirement and the elapsed time to procure them
  • Time and effort for building a temporary BAU landscape as the upgrade will be done in the existing Business- As- Usual landscape
  • Time and effort for building the training material for the new version and catalogue management tool SRM-MDM in this case
  • Training of the users in the new version and catalogue management tool SRM MDM
• After the detailed project plan is developed assigning roles against each of the activities the relevant resources must be mobilised to work in the direction of the plan
• Effective and elaborate Change Management Framework should be developed in order to manage the change of the upgrade on the business
• Extensive Training Strategy should be developed keeping in mind the extent of the changes in terms of localization and how it will be managed in training the users communities
• In some cases the change management framework can be embedded within a Training strategy if the upgrade is not impacting any of the core business processes

Points for Consideration

Any SRM technical upgrade will bring with it additional features and pre-requisites to be incorporated in order to leverage the benefit that comes with any improvement in versions. Some are mandated by the technological improvement and some with the vendors product strategy  in this case SAP.

The following points are to be considered and integrated with the project plan which will require additional resource and expertise as well as participation from Business/Process owners

Technology Consideration

• Migration from application controlled workflow to process controlled workflow

This is a technical component to implement and maintain workflow where the move in the new version is more towards functional maintenance rather than technical one.

Product Strategy

• Implementation of SRM-MDM as the catalogue management tool

As all future releases of the new version will only be aligned with SRM-MDM for all its catalogue management, it becomes mandatory sooner or later to adopt this tool. Having said that SRM 7.0 can still be integrated with the current catalogue management tool like Requisite as long as it is OCI compliant.

Conclusion

The success or failure of any upgrade project depends on how thoroughly the upgraded system has been unit, integration, regression and user tested and how effective has been the communication and training strategy adopted and implemented. The more effort goes into the testing and training of the system the less are the chances of the project getting into red. It should also be noted that the involvement from the top management in driving this at all levels also matter in the success of the project. The upgrade project also should derive potential improvements in terms of the procurement cost of indirect material from business perspective and/or the reduction in the TCO from the technical perspective of the on-going cost.

Glossary

BBP     -           Buyer Business Procurement

EBP     -           Enterprise Buyer Professional

SRM     -           Supplier Relationship Management

ITS       -           Internet Transaction Server

BAU     -           Business As Usual

MDM    -           Master Data Management

OoM     -           Order of Magnitude

OCI      -           Open Catalogue Interface

TCO     -           Total Cost of Ownership