Product Lifecycle Management Blogs by Members
Get insider knowledge about product lifecycle management software from SAP. Tap into insights and real-world experiences with community member blog posts.
Showing results for 
Search instead for 
Did you mean: 
Active Contributor

Ever wondered how to manage a change program comprising of SAP projects with unique dynamics?

Well, here’s one you may like to read about as it’s a firsthand account of transitions I was part of until recently.

What made my Change Management experience exciting was the program’s diversity in terms of types of changes, scope, complexity and perception. Here’s a brief explanation of the aspects.

Change Type Description
Procedure Change in the steps which were followed to finish work.
Process Change of the framework in which work was done.
Solution Change of the tool through which activities were performed.
Practice Change in the way used to complete activities.

The distinctive characteristics of the projects in SAP context were

  • Transition within SAP Application,

  • Automation through SAP Solution,

  • Migration to SAP Tool,

  • User Experience within SAP Environment,

Each of the projects had two major dimensions i.e.

  • Complexity: The complications throughout the projects from start to end, and

  • Perception: The ways projects were regarded even before their start.

From SAP components perspective, the projects were mainly about

  • Modifying Recruitment procedures within SAP Success Factors,

  • Implementing SAP Funds Management to automate budgeting processes,

  • Switching CRM function from Microsoft tool to SAP CRM Software,

  • Enhancing User Experience for some of HR Applications through SAP FIORI.

My Findings – Lessons Learned

Since each of these projects were different, the associated requirements (to ensure changes were accepted across the relevant departments) varied. Except the Change Control Procedure, which remained constant in all of above-mentioned projects, adapting to and effecting the changes were bit challenging aspects of the overall delivery. I concluded

  • Change in Procedure, especially if its slight, is accepted easily,

  • Change in Process, requires thorough effort to ensure its embraced,

  • Change in Solution, is often perceived difficult,

  • Change in Practice, generally requires ease.

Change Control Procedure: It’s a well-defined procedure across the organization. Hence, anyone requiring / requesting change goes through similar process i.e. documenting, assessing, planning & implementing the change. For the projects in question, the relevant stakeholders were taken through the process of

  • Documentation to ensure changes were recorded correctly and were well described in business terms.

  • Assessment to review justifications and to make sure that the alternatives were investigated well before calling for system changes.

  • Planning to keep the project status transparent & known to people involved in the project activities.

  • Implementing, as and when required, to make different groups part of the change.

Adapting to Change: To ensure all of the user groups adapt to changes, different strategies were followed for creating common orientation & conviction and ensuring ability & uniform perception. In addition to making sure that results were felt throughout the enterprise, few additional measures were taken to ensure lastingness of changes including

  • Communication to create awareness & understanding of the value each project was supposed to generate.

  • Publishing of reports and newsletters (in different frequencies) to keep relevant people informed of the overall situation.

  • Meetings with business users (on ad-hoc basis) to let them know of what the technical team had done for them, was working on and had planned in next few weeks.

  • Managing full spectrum of training, from analyzing learning needs to updating content & delivering instructions to ensure impacted users were capable of handling the change.

  • Running surveys across user groups, across business functions, to get feedback on the changes and taking necessary actions accordingly.

Effecting Change: Each of the change initiative, described above, had buy-in of the executive leadership for knowing the benefits of deploying the components, hence, the changes did occur (even though there were some delays). Here’s a quick summary of the benefits which were visible, to the management and their teams in each of the projects:

  • The maintenance cost of on-premise system is high, in-cloud systems are better choice (use of SAP SuccessFactors for Talent Management Process).

  • The automation of processes could reduce human errors, thus, could minimize costs (deployment of SAP Funds Management for Budgeting Process).

  • An integrated solution in an existing landscape has better return on technology investments (use of SAP CRM for Sales Function).

  • Flexible user interface is a key acceptance criteria of any solution (enhancement of SAP User Experience).

In short, I could say my one year experience of managing change was great and I’m hoping for the next release of changes (planned for the year) at my organization to be even more exciting.