Change Management in Implementation of SAP Projects
The guide “How to implement SAP SuccessFactors with Hicron?” includes descriptions of proven work methodologies, a clear breakdown of project phases and deliverables, and the responsibilities and roles of individual project team members. It also includes expert commentary, and it just so happens that my two guests today are among those experts. In the studio today are Tomek Zubrzycki, Solution Architect HXM at SAP, and Michał Sarna, Head of PMO and Change Manager at HICRON.
At Hi!Talks, we expand the topic of the guide and talk not only about how to implement, but also how to prepare for an implementation.
At Hi!Talks, we expand the topic of the guide and talk not only about how to implement, but also how to prepare for an implementation.
SAP Knowledge Base at hand!
This article is only a small portion of knowledge on how to use SAP software in your daily tasks. Hicron SAP AMS Clients are granted full access to similar guidelines… accompanied by professional SAP Application Support Services. Ask for an offer!
Transcription: Summary
Read the entire conversation or click on the selected topic and go to the issue you are interested in.
When to introduce change management?
Hanna Dziubińska: Michał, you are a change manager, so you put a lot of emphasis on introducing changes in organizations and the readiness of these organizations for these changes. Please tell me, can we really say that Change Management is a pre-phase before an implementation project?
Michał Sarna: That is a very interesting question. The term “pre-phase” you used was also nice. I think definitely, yes, we should say that change management starts before the project, yes, this is the moment. We can also say that change management, for it to work, starts before the project, but it is not a one-time activity, it is the beginning of a whole process that will run parallel to the ongoing project or implementation and even continue after the implementation is completed. If you want to implement a solution from the SAP family of products, such as the SuccessFactors you mentioned, you need to think about it before you start the project. You have to prepare for it. This can help the organization ensure that the implemented solution is introduced as successfully as possible.
Awareness regarding change management
Hanna Dziubińska: So this change management takes place at the beginning, before the implementation, but also continues during the implementation.
Michał Sarna:Exactly. I think that if we look at the last 10 years in the SAP project industry, my personal observation is that this awareness of change management in Poland is definitely growing. Demand for this type of competence is beginning to emerge in the market, both on the part of partner companies and also on the part of clients. And when we look back at that time, we have to say that we have seen both successful and unsuccessful projects – projects that were put on hold, frozen, and never resumed. And I think that in such a negative scenario, the best result that these clients received after the implementation was a reduction in the work efficiency and motivation of their employees. It was the least negative aspect.
However, clients and the market are more aware today. You can see that the demand for these competences, as I said, is beginning to emerge. It is evident that companies are beginning to focus their attention on acquiring such people, whether through consulting firms or by hiring them internally.
Change management competences and the role of the implementation partner
Hanna Dziubińska: And how does it look from your perspective, Tomek? Is this awareness really improving in Poland, are these organizations really thinking more and more about Change Management?
Tomasz Zubrzycki: Organizations are definitely aware of this need, and this awareness is growing. However, it is one thing to be aware of the need for appropriate competences and a method for managing change as part of an implementation project, but it is another thing to prepare the organization for that change, particularly from the perspective of the competences of the people who would be implementing that change. And that’s where things don’t look so great, because clients rarely have people on board who are adequately prepared to manage such projects. But this is not surprising, because these projects – if we’re talking about projects implementing HR solutions, including SuccessFactors – happen in organizations every few years, maybe once a decade. Keeping this type of competences on board... Change management in particular has different aspects in the context of an HR project, it has its own peculiarities. It would be unreasonable, to say the least, to keep that competence on board to carry out a project that will take place several years from now. And these competences are often missing in organizations. However, the fact that they are missing is not unusual in my opinion. It is only natural. And I think this is where the implementation partner has a big responsibility. First of all, to make the client aware of what competencies they need, to suggest whether within the organization – even at the stage of earlier meetings, pre-project meetings, or sales processes – whether such people have been noticed who have the right characteristics and, one might say, also some kind of background that will help here, so that such a person could be responsible or participate in this change management process. In fact, I believe that the responsibility for this change management, at least at the beginning of the project, lies with the partner, and the partner should be the client’s advisor on how to approach this issue.
Challenges of change management: lack of knowledge of the goal
Hanna Dziubińska: I wanted to ask about the consequences of such a lack of preparation, but you’ve already talked about it a bit, Michał. You mentioned this decrease in efficiency. Can you list any other challenges we face when preparing for such an implementation?
Michał Sarna: Yes, of course. These challenges can be really numerous. Tomek rightly pointed out that clients need this guidance, this insight, to show them these perspectives within their organization and this level of preparation. When it comes to the challenges, we can certainly come across different situations. One that I can mention is when the employees of an organization that is planning to implement a solution from the SAP family are not familiar with the purpose, importance, and primary direction that this implementation or project is supposed to support. This, of course, has to do with communication. It is this communication that is the key here, so that when a decision is made about a project, an implementation – a fairly major organizational change – the people are well informed about how they can prepare for it and how they should work together to achieve these common goals of the organization. We can support these things in two ways. Of course, as Tomek said, by advising – whether before the sales process or right at its beginning. At this stage, you can already talk about this communication and talk to clients about it and also suggest how to build a communication strategy so that this information actually reaches the people in the organization who are going to personally use this system or the solutions that we are going to implement.
Who is affected by change management?
Hanna Dziubińska: Well, that’s right, because Change Management is not a higher level. Change Management goes across all levels of an organization, right?
Michał Sarna: Yes, of course. Definitely. Here we can refer to what was mentioned in your question, namely the combination of a project and a change. And to go a little bit more into the theory and rely, for example, on the PMBOK definition, which says that project management is the use of skills, knowledge, tools, and various techniques to deliver value to people by implementing some solutions, launching systems, in our case systems from the SAP family. Change management, on the other hand, is a little bit on the side. It guides users through the entire process of change to ultimately change their behaviors and habits. So exactly what you said, that it has to go through the entire structure of the organization and reach the people who are going to be the users of that system on a daily basis, so that they know how to use it and how to prepare for it.
Challenges of change management: lack of commitment
Hanna Dziubińska: But let’s go back to the challenges, because we said that people need to know why something is being introduced. Are there any other issues worth mentioning?
Michał Sarna: We can also talk about a situation that unfortunately affects us very often – the involvement of the so-called middle management. In the case of this kind of changes – which, as Tomek mentioned, can happen once in a few years or a decade in an organization, when a large system, a large solution is implemented – it is especially important to work not only with, for example, a representative of the management board, who will be the sponsor of the project from the client’s side, but also with those people in the operational management of the organization who have a direct influence on their subordinates. Because the lack of involvement, the lack of understanding of the purpose of the whole project, the whole change in these people will translate into members of their team. And that is not a situation that will support the implementation.
Change management challenges: time buffer
Hanna Dziubińska: And you, Tomek, what challenges have you faced in the companies you have worked with?
Tomasz Zubrzycki: To what Michał said, I would add two more points that are directly related to change management and change in the organization. The first problem is that it still happens that people from HR departments or people who are involved in projects on the client’s side, I do not mean a PM from the client’s side, but simply people from the departments where this solution is implemented... These employees often have the tasks that are part of the project assigned to them as additional tasks, so to speak. And the preparation for the project does not take into account the fact that this involvement will be very significant at certain stages and will require adequate time. This results in working overtime. This can lead to frustration, and it can also mean that certain tasks that these people should carefully think through and get used to are not done as effectively as they could be if they had sufficient time to prepare and participate in the project. And that can have all kinds of consequences for the whole project.
Challenges of change management: old habits
Tomasz Zubrzycki: And the second thing I would like to mention in the context of change management is that it still happens, maybe not as often, but it does happen, that clients who are implementing a new solution want to run their old processes in the new tool that they chose. Sometimes, of course, they additionally automate, extend, or improve something – because there is some reason why they are changing the tool – but overall their approach to the project is basically that things should be the same as before, just in this new tool.
Hanna Dziubińska: A semi-change.
Tomasz Zubrzycki:Exactly, a semi-change. And this is a cardinal error when it comes to the very assumption of what a new project is, because this type of project, especially when we are talking about HR, will always be associated with a transformation. Bigger, smaller, but it will be a transformation. Transformation, change, and also the need to prepare well for that change, and to make clients aware that the intention should be to change something – improve, streamline, make things easier. This is also a huge task for the implementation partner, for the solution provider, so I don’t want to shy away from our responsibility to make sure that there’s awareness in the organization that this project is going to bring change and it’s not going to be like it was before. It has to be better.
Change Manager and Project Manager – differences
Hanna Dziubińska: Although it will probably be a little harder at first, right? Because you have to prepare for that. Okay, we talked about how a lot of the responsibility lies with the implementation partner. We’ve talked about how the company implementing certain solutions can’t avoid changes within the organization, but there should be a person managing it all. And that’s where the change manager comes in, but it turns out that’s not always the case, right? Why is that? Is it that in some projects, some of the change manager’s tasks are performed by the project manager? How are these two roles different?
Michał Sarna: This is also a very nice question. Well, do we always need this change manager? Based on my experience, I would say not always. Not always. It all depends on the size and complexity of the project. Of course, when we are talking about large, far-reaching transformations like we are today, this role should be carefully considered. However, this will also depend on the culture of the client’s organization. How it has functioned in the past, how open it has been to change, what previous implementations have been like, how it has handled such projects organizationally in the past.
However, going back to what you asked, whether the Project Manager also performs these functions. Well, we will definitely find places in projects where this fine line between Project Manager and Change Manager is blurred, and we will definitely find moments where Project Managers have stepped into the Change Manager’s shoes in the past, not knowing that this whole trend is coming in a big ship. But from my point of view, I think these roles should be treated separately. First, because they are very time-consuming, and to be effective, they should be done by two people.
And you asked about the difference, so we can go back to the definitions that I mentioned earlier and summarize it from the Change Manager’s perspective and say that the Change Manager’s job is to guide these people – to prepare the organization, prepare the people who are leading this organization, so that they can prepare their own people for the change of habits that I mentioned earlier – and act at the operational level, because that is the crux of the whole change. So we can talk about this human aspect. If we turn to the Project Manager, then the Project Manager is responsible for delivering the solution that was ordered – here and now, within the budget, time, and scope – something that will be used in the client’s organization. And this is the more technical side of the project.
Change Manager and Project Manager – cooperation
Hanna Dziubińska: Do these people work closely together in any way, or are they rather unconnected areas?
Michał Sarna: There are certainly many intersections. What would this look like in an ideal world? I think we should look at the structure of a large project, where the Project Management unit works in parallel with the Organizational Change Management unit, because that is how SAP defines this unit in its methodologies. And we separate the Project Manager, who works on the project together with PMO support, and we have the Change Manager, who works in parallel, but can also be supported with additional competences. It all depends on the scope and approach, which depend directly on the project’s steering committee.
SAP Activate methodology / Cloud Mindset / retrospective analysis
Hanna Dziubińska: And how exactly does the Change Manager work? What methodologies do they use? How do they manage change?
Michał Sarna: There are many methods that have been developed over the years. We can focus on a few of them today. Certainly they can be divided into those that support the organization more broadly in preparing for change and those that are very focused on the individual, supporting them through that change. I think we can start with what we actually get from the SAP system provider together with the SAP Activate methodology. It includes activities related to Organizational Change Management in what is called the Solution Adoption stream. It contains different activities, and anyone who is interested can refer to this material by browsing the SAP project roadmaps that are available online. This is one piece of information. And as we look at what’s actually in there, there are a number of activities that – I’ve said this before, I’ll say it again, just as Tom pointed out – can be done right at the beginning of this journey when thinking about a new system. When we talk about cloud solutions, we start by getting the client to think about whether they are ready to move to cloud solutions. In the methodology, this is called the Cloud Mindset, which is thinking about how our organization responds to the transition to cloud solutions and what this entails. Going forward, you need to think about identifying the stakeholders in the project, the purpose, the business benefits behind it, and the approach to what we discussed earlier, the seeds of a communication strategy. How to communicate this to the organization so that the sense of importance of this project is high enough in the organization.
I would also add what we might call a retrospective analysis, i.e. I would encourage the people who run the client’s organization to sit down and think about how the organization has responded to such projects in the past. Were they successful, did they achieve the intended effect? If not, what did they do, what was done, how did the people react to it, how was the organization as a whole prepared for it. Because looking at what has already happened in a given organization gives us a nice starting point for further projects. So you can start thinking about what didn’t work, what did work, what can be continued, and what should be changed. We can refer to Albert Einstein’s quote that doing the same thing over and over again and expecting different results is insanity. So that’s a nice turning point to say at the very beginning – OK, we already know this, we want it to work this time, so let’s not do that.
Three goals of the SAP Activate methodology
Hanna Dziubińska: : Tomek, this is actually very interesting, because you yourself mentioned SAP as a solution provider, a product provider, and here we have SAP Activate, which is supposed to make these products and solutions work. Tell us more about how such a product appeared in your portfolio.
Tomasz Zubrzycki: Exactly. Michał has already nicely characterized these, one could say, elements of this SAP Activate methodology. But if I were to tell you why this methodology was created, I would generally point to three goals. The first goal is to make efficient use of client-side resources during project implementation. Why? To shorten the time of project implementation and optimize its costs. The third goal, of course, is to achieve the business objectives set at the beginning of the project in the most effective way.
Change management at every stage of implementation according to SAP Activate
Tomasz Zubrzycki: Speaking of the SAP Activate methodology, it is worth noting that it is designed to be applicable to any project. Any project, be it HR or any other area. But also when it comes to the size of the project. Whether it is a small, local implementation of one module or area, such as training, or a large, transformational project across the entire global organization. We can use this methodology. It is built in such a way as to make this possible.
Michał mentioned change management earlier and that this change management happens in parallel with the project. I would even go one step further and say that change management in modern projects, especially projects that involve implementing solutions in the cloud model, is a necessary element. This change will always take place there, and the methodology we propose takes this into account. For example, if we look at the different stages of this methodology, in the first stage, which is the planning of the project, where we define, among other things, the goals of this project, so that everyone can see where we are going, what we want to achieve, where – of course, based on different types of tools, templates, procedures that this methodology brings – a framework is prepared for the functioning of the project, communication, documentation, how everything is going to take place. This stage also involves familiarizing the client’s people with the solution, so that the business process discussion is already based on knowledge of the tool that will be implemented in the organization. And even in this first phase, the issue of change management arises. Although this is only at the level of strategic assumptions regarding change management, but this methodology proposes this topic even at this first stage.
The next stage, which is called the exploration stage, which is sort of a classic element of an implementation project, where we map the organization’s processes onto the tool, verify if there are any functional gaps, think about what to do with those gaps, whether to configure any additional functionalities that will close them or to change the process, and then again think about what impact that will have on that change in the organization, how to approach it. And, of course, as part of this phase, it is necessary to determine the scope of data to be migrated, the approach to migration, integration with the entire ecosystem of solutions, because – as you know – today these systems no longer function as islands, but are part of a certain ecosystem that functions in the organization.
. In the third stage of this project, which is simply called realization, where on the one hand we configure the system in this stage there is more emphasis on the implementation partner, i.e. configuring processes, preparing various types of mechanisms to import data from the source systems, but the client also has a huge responsibility, which is also worth mentioning here, since you asked about these project difficulties – the responsibility for thorough testing of the processes. What often causes problems later is that the processes were not properly tested. Both in terms of data migration and what was delivered as part of the system configuration. If something is not tested well, it will still come out, just later and cause some sort of disruption.
As far as change management itself is concerned, it is at this stage of the project’ s implementation that a plan is developed – and this is what the methodology includes – a plan of how this change will be introduced into the organization.
And, of course, the final stage of the project, i.e. the deployment of the solution, where we have to communicate within the organization, inform employees about what awaits them, what will change, what will look different, what will be better – because, of course, here you have to emphasize the benefits that will be achieved by managers, employees, and all people in the organization. And issues like cutting off the old system, getting a new production system up and running, well, those are obvious things.
But as you can see here, at every stage of this methodology, there is an emphasis on including change management aspects because it is essential.
Embedded Launch Activities – what is it?
Hanna Dziubińska: Tomek, in the guide you mentioned a tool called Embedded Launch Activities. What is it?
Tomasz Zubrzycki: Yes. Embedded Launch Activities is actually a proposal that we prepared for our clients to help them implement projects according to the methodology that we propose. In simple terms, this EMLA, as we sometimes abbreviate it, consists of three elements. The first element is training materials in the form of videos that showcase the business processes that run on SuccessFactors, the strengths of those processes, and the benefits to the organization from choosing one path over another. In this element there is also the possibility of consulting experts. In the form of question and answer sessions. This fits in perfectly with the first phase of the project, where the Client should get to know the tool and its capabilities in a much more detailed dimension than in the solution selection phase.
The second element of this offering is access to a system, an additional project environment, that is configured according to the leading practices that come with the system, because this is also a very important element and the idea behind the way solutions are delivered in the cloud service model. The system suggests or this solution suggests a certain way of implementing processes, and the tool will be used most effectively if the organization adopts these processes. To the extent that makes sense, of course, but still, adopting the processes that the solution provides is a starting point for modeling how those processes should work. So, the client gets an additional environment that’s fully configured with sample data, including scripts with scenarios on how to navigate that environment. And that fits perfectly into the second phase of the project where we have this mapping of our existing processes to the solution. Well, if there was no such environment, it would be impossible to see and touch these processes, find out what they will actually look like, how they will function. It is much harder to imagine than when the client simply has an environment where they can see it, test it, and be sure – it is indeed a good direction, we can use what this solution offers.
And the third element of this offer is the ability to measure the effects of this project. How is this done? On the one hand, as part of this offer, appropriate surveys are provided that can be conducted in the organization to measure the level of adoption of the solution. But the other aspect of this results analysis, that I find very interesting, is that there are all kinds of business KPIs proposed, that are usually measured at the beginning of the project and at the end, when the system is already warmed up, colloquially speaking, when the processes are already working as planned. Again, we measure the relevant KPIs, and by comparing the values at the beginning and at the end, we are able to arrive at the measurable effects of such a project. We can easily convert these indicators into money and see what the organization has saved, what strictly financial, hard, measurable effects have been achieved by implementing this project.
Importantly, this EMLA option comes at no additional cost to our clients. As simple as that. All new clients who choose SuccessFactors, or existing clients who decide to expand the project with new modules, will have access to such an environment. What is more, this environment covers a wide range of modules we have in SuccessFactors. So even if the client chooses one module, they get an environment that shows a broader context of these processes, what they might look like if they decide to expand the project, perhaps adding more elements in the future. So there is also an educational function to this program.
Summary. Communication + building a change team
Hanna Dziubińska: Awareness seems to be growing, we have the methodology, we have the tools. It seems that organizations should be embracing change management by now, and yet we still seem to face many challenges. Maybe we’ll sum it all up and list what companies most often forget when implementing projects.
Michał Sarna: Well, I will mention three things, I think. The first is communication, which I would emphasize very strongly, so that this communication is coherent and well thought out, so that the clients define well the group of recipients of this communication, and so that it goes through all levels of the organization to the people who are going to consume the effects of this change or work on the new system. This is one thing.
The second thing comes from John Kotter’s methodology, his eight steps. I would encourage building a change team, that is, even before the project, dive deeper into these waters of change management, build a team to support the change. This team should have people with different qualities, different talents, different abilities. Here we can point to the internal change sponsor mentioned earlier, who should have a formal influence on the entire organization. We should have a person who has influence, but a more informal one. Someone who has been in the organization a long time and has a wide range of influence over people. We should have people with technical expertise. We should have people who will support communication. And it is also worth paying attention to the inclusion of the “naysayers”, i.e. people who, for various reasons, will not actively support the implementation. There are such people in every organization. And the methodology that John Kotter proposes talks about that – listen, don’t make this mistake, don’t skip this group, try to include someone who is opposed to the change. As this person travels through the change on this team, you benefit in at least two ways. One is that there is a chance that this person will absorb this change by being a co-creator of what is happening and getting involved. Second, you will have an impact on how they affect other parts of the organization.
And the third thing, in connection with what you also summarized, that this awareness is growing, theoretically we have everything, everything is happening. Let us also remember that the change manager who eventually appears in the organization or the project, whether on the side of the provider or as an employee – because we did not discuss that – they will not be able to do everything alone. This is not a man who is going to wave a magic wand and make all of our problems, that Tomek and I have listed, magically disappear from the organization. It is certain that a person in this role, by engaging and supporting the subject of the change, will make this adoption, this change in the organization more effective, more efficient, and ultimately bring the expected results.
Readiness for modern HR / decision-making of the HR department
Hanna Dziubińska:Let’s come full circle back to SAP SuccessFactors, because HXM solutions from the SAP portfolio support modern HR. Based on your SAP experience, are organizations ready for this modern HR?
Tomasz Zubrzycki: To say they are ready is to say nothing, in my opinion. They really need and want these changes. I can see that there is a great need on the HR side to implement such projects. HRs are ready, they are open, they are very willing to do these kinds of projects. There is also a very high level of awareness on the part of organizations about what they want to improve, what results they want to achieve. What we need to do to support organizations – this is only natural – is to show them the tools or ways to achieve the planned or expected effects. However, in terms of both readiness and willingness, I think it looks almost exemplary, especially when you look at the Polish market. We talked a lot about different difficulties, so I will mention one more difficulty at the end, not to make things too sweet.
If you look at Poland in comparison with other countries, Western countries, it is unfortunately still quite common that HR is not empowered in organizational structures at a level that would give it sufficient decision-making power when it comes to implementing projects and pushing through strategies and ideas that HR has. In the Western world, it is increasingly common for the head of HR, the HR director, to also play the role of a board member. There is a similar trend in our country – fortunately, I see such situations more and more often. However, it still happens that this HR does not have such power within the organization. Well, and this, of course, later complicates and affects the possibility of carrying out, implementing such a project. Because what is also a challenge in an HR project is selling the impact of the solution to the board and decision makers. So in terms of a hard calculation, what are we going to gain, where are the savings, how is this project going to help us in our organization from a purely economic point of view.
This is where we as SAP come in, and as part of our broad offering to clients, we can help them build a business case and prepare a justification that is very specific, based on hard calculations, indicators, different types of impact measurements, and the expected and possible effects of implementing a particular project. So it is still a bit of a challenge for HR to be able to speak the language of finance and defend their projects. We are trying to help with that, but there is still some work to be done.
Hanna Dziubińska: Of course, I do not want to end on a sour note, so I would like to wish modern HR both to the organizations and to the people who will work in these organizations.
Tomasz Zubrzycki: Not to end on a sour note, I would like to mention one more thing, because I have complained a bit about how it sometimes looks in our country when it comes to the role of HR, but I would like to end by mentioning one more thing that also strikes me. More and more often I see that Polish branches, even of large international groups, are more and more dynamic when it comes to promoting and realizing solution implementation projects in the field of HR, where I see more and more often that even pilot programs within entire groups include Poland, where these Polish organizations want to participate in such projects and submit such projects themselves. So there is no shortage of courage and willingness in our companies. That’s for sure.
Hanna Dziubińska: Fingers crossed for further development. Thank you very much for the interview.