Working on the SAP SuccessFactors Change Requests (CRs)
The purpose of having a support model is to ensure that the client always have their implementation partner/technology partner available to help and guide them for anything that comes up in the product opted.
Here, Change Requests (CRs) play a major role in any Support Project. For a fact, CRs help the client to maintain themselves in the league of having best practices working on their instance and this of course is also for an extensive use of the product with better user experience.
Looking at SuccessFactors, I have felt that we are always progressing towards the better HR management, as we see new functionalities popping up with new releases. This empowers our clients to achieve their objectives of having a great HR Suite installed for them.
Lets have a look at the potential reasons to the CRs:
- Change in the business process after go-live.
- SAP releases a new functionality to meet the business requirement that was not previously met.
- Launch of any 3rd party system at the client, that needs to be integrated with SuccessFactors.
- Process was parked during implementation and was planned to be implemented during the support after process is finalized.
… and the list goes on depending on the client, timelines, processes, etc.
Points to consider before and after raising a CR
As a SuccessFactors Consultant, below are some series of activities that will help you in seamless implementation of the CRs.
Understand the Requirement
The business owner is the main stakeholder who will have the information and knowledge about the CR your client wants to implement.
The first step on your part should be to understand the Change Request from the client. You can have sessions (face to face, business calls) with the relevant stakeholders and gather as much understanding as you need to proceed with next steps. You can have multiple sessions if you could not understand the requirement well previously, as then only you will be able to do best for your client.
You can also create a template and agree with the client on what all details must be included in order to begin the discussions around the potential CR. For example, you may want to include the Requester, Change Heading, Change Description, Priority, Reason for Change, Issues Currently Faced, etc,. The sessions can also be based on the document prepared, as you will have a written CR from the client to go forward.
Study the Designed Functionality in Client System
You may have been the part of the implementation and are already aware of the configurations/designs or you may have joined the support team specifically for the support project. So in case of the latter, once you have understood the CR, assuming you will have a fair access to the relevant instance, go through the system and have a look at the configurations already running on the client’s system. Try and gain access to the documents created during the implementation – design phase and reach out to the implementation team who configured the system if you cant gather reasons behind the design.
Q/A with the Client
Once you have gathered enough information from the client and also reviewed the existing configurations/functionality in the system, prepare a slide (try to keep the slides minimum) on the CR and conduct a session including the business owners and your team. This will help you and the client to share similar understanding and it can be a good opportunity to clarify certain points which strike your mind while gathering the information on existing system design. You may like to call it a “CR Review Session”. Remember that the business and consultant are working towards one goal as one team, so provide as much support and comfort from your end to the client as and when necessary.
Now is the time to move towards solutions.
Suggest Alternative Options to the Solution
As a consultant, its our prime duty to provide best services to our clients. Hence, while working towards providing the solution to the CRs, try to focus on the below considerations:
- Provide all possible / multiple options and let the client pick the one which makes them comfortable with the change.
- Do provide your recommendation based on the best practices.
- Always keep a standard solution in your list, as it will be compatible with all future releases.
You may add a solutions slide to the CR deck (which we discussed in last point), that can contain information like:
Next Steps for Business
Screenshots or some great Visuals
Raise the CR Formally
The process to raise the CRs vary from company to company. Some company’s use tools like ServiceNow and other may even follow an offline process, so make yourself aware of the process and the protocol to be followed while raising the CR approved by the business owner. Using the CR Document as base, encourage the business to raise the CR formally. It is suggested to now include information like
Deployment Time Frame, etc…
Do not forget to provide a Serial Number to the CR, it will help you to report on the CRs at later stages to monitor the progress, etc.
In terms of Internal team activities, ensure that the technical team understands the CR and is confident & comfortable to work on it. Align some bi-weekly calls or on need basis to know the progress and support the team as and when needed.
Develop the Solution and Provide Demo
It is highly recommended to use the client’s development instance first for the changes related to CR (which of course should be the clone of production in terms of configurations). The change will easily fit into client specific processes designed in their system and when you provide demo to the business owner(s) they will more comfortably understand how the new configurations/process designed works. Do include how the change will impact areas of the system like reporting or if there is any impact on other related modules. I am sure you will see the client pleased with the data available through reporting.
Take the sign-off after the demo and work towards moving the configurations into production instance.
Plan and Move the Configurations to Production
At this stage it is very important to follow the timelines, as a little deviation may result in inappropriate impact on all end users. It is always recommended to revoke the end user’s system access while deploying the new configurations or modifying the existing ones (do look for the right time while revoking the access). This helps to avoid any impact on all end users and makes it all seamless.
Do not forget to be 100% prepared before you implement the change in live environment, for example, the CR may bring in some updates to the data, so encourage the client to prepare the data in the import templates and make them ready for uploads as soon as the configurations are done in the production. The new processes through CRs can be taught to target audience through guides, PPTs, classroom sessions etc. This can also be done using SuccessFactors inbuilt video functionality.
The above examples are some of the Pre-requisites which you would have already included while raising the CR formally.
Hence, every related aspect must be ready for the deployment.
Monitor the Change
Once the change is implemented and all other relevant areas like data, process guide, etc are in place, make sure that the change is monitored and that the users are comfortable to work with new functionalities made available to them. Do prioritize the issues raised against the change, if raised by the users. You could also advice the client to setup a helpline for a couple of weeks for instant support. If the change is major you can also setup weekly meeting with the business and internal team to know the impact of change.
Outline the ways to monitor the success of the change. For example, if the change is major, you could monitor the use of module. If the change will enable data entries, build reports to see the progress on the entries… and so on.
I will conclude by saying that working on CRs is not easy and involves a lot of considerations. It is very important for the consultants to ensure that they provide best support and services to their client.
Do not feel stressed while working in the support projects. It is very challenging and exhausting sometimes but this is how you will thrive through some great things you will explore or learn while looking for the solution.
Good blog on an important topic. My suggestion would be that the main reason i have seen for CRs is not a good shared understanding in the SOW on what the customer is actually purchasing up front. You should spend as much time up front telling them what they are NOT getting as what they are getting. The mantra should be "no surprises".
I agree with your point on the SOW piece, I think technical consultants must be involved in the initial discussions to ensure that both client and implementation partner are on same page. In this case, based on the RFP, it should also sound fair to outline the achievable and non-achievable items well before the project is win and kicked-off. Plus, gaining a high-level understanding of the client's processes initially, will empower the implementation partner, to communicate the clients about their expectations well.
Thanks for sharing your thoughts.
Thoughtfully written Aastha! CRs are critical as we get something to work upon already implemented system. It comes with bigger responsibility because we need to consider the impact on other functionalities. Consultant needs to think of all possible scenarios which have not been encountered earlier. Its a new kind of challenge!
Thank you Rama 🙂
I really hope this piece of information can be of best use for you.
Thank so much for Explanation.