SuccessFactors Release Management: It’s Not as Difficult as You Think

Does your organization have a defined process for implementing SAP SuccessFactors’ bi-annual releases? Even though there are only two releases each year, it can still be overwhelming to plan for, test, and roll out new features.  

You may ask, why does a formal release management process matter? Isn’t it enough to just know what’s coming in the release? Creating a defined release management process helps ensures you are never caught by surprise and that your HR business partners have the opportunity to take full advantage of new features and constant innovations offered by SAP; and in the event something isn’t working as expected you know in advance and are able to report that to SAP Support.  

Now that we know why we need to create a release management strategy, let’s cover some tips to help you create a process and strategy for your organization. 

1. Who should be involved in the release process? 

This is the first step in putting together your strategy! Each organization is different, but consider who needs to know about new features, deprecations, and changes to the product and what level of detail they need. Create your internal release management “team” which may include some or all of the following: 

• System Administrators 
• HRIS 
• Key Line of Business Stakeholders 
• Executive Sponsors 
• Communications Team (or person responsible for communicating user-experience changes to the organization) 

Not everyone will need to be in the weeds but at some level, they should know what’s happening and be able to speak to it at a high level.  

2. What is the meeting cadence and what do you cover during the meetings? 

Since SuccessFactors has two release cycles per year, your team should meet at least twice per year, and potentially more depending on your business processes.  

Considering the preview environment is updated five weeks prior to the production environment, we would recommend meeting one to two weeks after the preview release; this should allow your team to familiarize themselves with what will be in the release and start testing (which we will discuss in the next tip).  Also, if the release significantly impacts your organization or processes, we would recommend an additional touch-point in the weeks immediately following the release to production to cover any major roadblocks or issues stemming directly from the updates.  

The agenda for your team should include the following: 

• What is coming out for each module and does it affect any of the other modules, are business processes affected? 
• Are there any key features or deprecations that would significantly change the user experience and how should those changes be communicated? 

• Of the new features, which are opt-in at your own pace, and which are universal (meaning they are required and automatically pushed to your environment)? 
• Who is responsible for testing? 
• Re-visit items from previous releases and determine if it’s the right time to enable past features. 

3. Testing 

TEST, TEST, TEST! This is one of the most important parts of a good release strategy. Approximately five weeks prior to the production release, your Preview instance is updated. This gives your organization time to review the new features or deprecations, verify universal features are working as expected and business processes are not impacted. During this window, you also have the opportunity to enable new opt-in features and present those to the various lines of business as needed. 

What does testing look like for your organization? Is it solely the system administrators that do the testing? Is HRIS involved? What about the business process owners? 

These are all key things to consider and to build into your testing process. 

4. Features in beta phase 

How does your organization approach features released in the “beta” phase? Is this something you determine as a rule not to turn on until they are permanently added to the product or does it depend on what the feature is?  

Know in advance how you intend to handle those features. Sometimes, during the beta phase organizations have an opportunity to provide feedback to SAP Product Management regarding that specific feature; know if that’s something you want to take advantage of and weigh the risks. As a team, determine where the value exists and build that into your plan. 

5. What about features we choose not to enable? 

It doesn’t always make sense to enable every new feature as soon as it is released. Maybe as an organization your processes aren’t aligned to be able to utilize that feature, or maybe you need to wait until there aren’t other competing priorities. Even if you choose not to enable a feature simply because you want to see it become more developed before rolling it out to your teams, keep track of those features and why you have chosen not to enable them and revisit them frequently, including times your release team meets.  

Here’s an example of how you may want to track these features. It can be helpful to include a link to the documentation about that specific feature as it provides quick access to details if needed.

We all know technology changes frequently but so do our processes; something that didn’t make sense last year may be just what you need this year. The key takeaway here, is don’t get left behind when it comes to your technology. Stay up to date and know what functionality is possible. 

Release cycles don’t have to be painful and stressful. By creating your own release management process, you can strategically and successfully manage your ever-changing technology. If you don’t have a release strategy in place today, begin taking the necessary steps to implement one. It doesn’t have to be perfect and may take some time to refine, but it will be well worth your effort.

Still need help? Connect with one of our certified solution consultants to discuss drafting a release management plan specific to your business processes and needs. Contact us to schedule a complimentary call!