Application of Change Management Techniques at different projects – lessons learned
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.
In addition to the above account of practical experience within Change Management work stream, I have described an overview of the subject at following link which could be referred for a brief understanding of the topic.
Changing the way they work: A short introduction of Organizational Change Management
Should you like to see a case study of managing change in context of SAP ERP HCM, you may find following discussion, I had at forum, useful.
OCM by SAP HCM implementation – are there well known areas?
To have a clear understanding of what it is and what it is not, I'd recommend you to read following thread where the Change Management Professionals (including myself) have shared their thoughts:
SAP - Organisational Change Management History
Faisal, Kudos for an excellent article. Bringing about a change in perception is not only difficult but mostly impossible. But thankfully, that does not keep a change, from happening. As long as the change is well managed and brought about with least numbers of whiners, its a success. My own experience in a petrochemical manufacturing company's adoption of SAP ERP, 10+ years ago, as power/user for PP, SD, LE, PS, MM (etc.) modules, comes to mind. We, as process and project engineers, grudgingly attended large number of training sessions by SAP implementing team members, but never convinced that millions of dollars spend could really payback within promised timeline and lofty claims of "business transformation" will ever be realised. But I only hope that company finally started reaping benefits from that "change".
Hi Jay, Thanks for your nice words and for describing your past experience. I see your points clearly and can relate these to my experience a decade ago when I - as part of project team - was delivering SAP training to number of people. I remember quite well how attendees often asked if their work would 'really' become easy after replacing the existing systems with new solutions. I was convinced and they were not exactly (at that time) of reaping the benefits later.
In fact with the global change in economy, the successful solutions & services providers have redefined their approaches to stay ahead of competition. What was acceptable a decade ago, is not now. SAP has responded well to its customers' needs in these years and have brought big changes in the way it was dealing in software market, such as rapid deployment solutions to ensure faster time to value, shifting to cloud to let customers benefit with lower TCO of SAP Solutions, enhancing user experience and much more...
Now convincing customers has become lot easier than it was ever before. So for the new transformations, such as the one I experienced lately, its amazing to see how the end-users are embracing the solutions. I was lucky for having a good team on both sides; at one side where I had wonderful support from Consultants in adhering to the Change Management plan, the people on other side (business) were also quite cooperative in trying their best to welcome the change.
Great information! I am trying to map out a new learning path. I am interested in SAP, Change Management and Training. I am in the process of figuring out how to bundle them.
Starting from Training could be an easier route to develop yourself in areas of your interest i.e. SAP, Change Management and Training.
Generally at SAP Implementation Projects, training part is handed over to people with skills in content writing & instruction delivery. While Consultants configure processes, the training developer captures the steps for end-users and prepare user guides (which are later reviewed by Consultants) to ensure the correctness of processes. For training person, its also good chance to learn specific processes and to develop an understanding of how the whole thing fits together.
And anyone who has developed the training material and is good at carrying-out the training, could know further the end-users' needs which qualify them to be level 1 support provider as soon as SAP goes live. By handling common issues and trying to resolve them by self could help you in developing your technical skills as well.
After spending sometime in such roles, training and support, you could opt some trainings to develop yourself on consulting, project / change management roles.
Since I had the above as my career path, I could clearly see its effectiveness and would advise the same.
This was GREAT information!!! I really enjoy training and helping people learn, I enjoy learning as well. I have been doing my own class content and documentation for sometime now so that is a good area as well. I do believe I WILL try to use this as an "in" while doing the free classes as well.
THANK YOU SO MUCH!!! 😀