Learn More 

#SUPPORTWOMAN: first, watch the go-live


So, why are you reading this?
You have either implemented or are in the process of implementing your new, awesome, responsive, interactive HR system; you are looking forward to the expected accelerations that will be delivered by the new technologies you have selected to implement. The new processes are going to make life easier for everybody and provide plenty of insightful data; its modern UI will entice your employees to use the system and adopt the new methods. You have planned a launch, and a change management plan has been put in place to communicate, train, teach and share. So what now?

As much as you would like to put all project times behind you, they are simply not going away. Much in the same way as after the implementation of any large system, even with cloud systems you will need to plan the next steps.

In your new SuccessFactors system (but it is worth noting here that other SaaS systems will carry similar obligations), you will not need to know ABAP or other coding languages to stay ahead and keep up with the system. You have learned that

  • It is all about configuration, and not about customizing; so in other words, no coding needed
  • There are no regular upgrades to plan, and consequently less need for technical support services
  • All administrative tasks should be undertaken by HR, and there will be no further need for IT involvement.

While this is all true (or mostly so), it is important to understand that there are still areas that require an expert eye, and whether IT or HR will be doing it should not be the most important question. It is a shift of work skills and priorities, but not a disappearing act! The headcount need to be budgeted somewhere, with the correct expertise and training - in HR, in IT or as a support contract from a vendor.

HR representatives often don’t have the skills to manage an application and its governance, or simply have no interest in doing it – it is frequently not considered an attractive career development for the HR team.
There is also a critical share of change management as well as system and process governance on both HR and IT sides, to ensure system stability and performance. Considering that at the time of go-live, the HR administration is only at the start of the road, the learning process is beginning and HR users are often overloaded, picking up on the system responsibilities can a challenge, and should be planned and built in the daily work.

What tasks should be expected? Here is a simplified list.

  • Overall system admin, including user administration and routine regular tasks required for the regular HR processes run; depending on the size of your company and on the system footprint (one or more modules), you may need one (even part-time), or several appointed power-users.
  • Quarterly releases reviews, management and tests if required
  • Governance and IT responsibility
  • Specific after go-live (usually one or more months)
  • Role-based permissions management
  • End-to-end system change management (or governance), to ensure that all consequences of a proposed change in the system can be spotted in time
  • Integrations to other systems
  • Training, knowledge transfer and documentation updates as required

In the next weeks, I'll examine all these aspects in more details, including information on what to expect and hints on how to proceed.

Note: implementation of new functionalities, new modules, new processes and requirements are not included in the scope of the present document, and should be considered as additional project phases.

The first important thing in the process is to support the go-live to ensure it is as smooth as possible. With a new system to play with – and a system that provides every employee with a visibility on her records, the new tools and processes will enjoy an exceptional visibility. You can then expect questions!

What questions?
Just about anything. A good preparation and change management program will address most of them ahead of time, but it is key to remember that it is not because it has been said that it has been heard

Examples would be:

  • Why a new system?
  • Are we still using the old system as well?
  • How come it has been done this way?
  • How will this new system impact my daily work?
  • Who made these decisions?
  • Who should be contacted if something is not right?
  • Why and how the old process was changed?
  • Where can I find more information?
  • and many more....



  • Data cleanup should certainly be part of the data migration approach. The new system and new reporting will highlight “dirty data” and give users the impression that it is a “broken” system, where analytics cannot be run and normal business operations cannot be conducted. In most situations, it is not the system at fault, but the data that has been imported.
  • Ensure not only that there is a reporting strategy, but that it is communicated and shared. Data in the system is only useful if it can be easily turned into information to meet any number of requirements, and many will be identified after go-live, when users start accessing the system. People tasked with capturing and pulling data typically have no underlying knowledge about using the right tools to maximize reporting capabilities, but in this case a little training can go a long way.
  • As the go live approach, create a backlog of requirements. It is often simply not possible to keep including new or changing requirements and ideas without scope creep and/or endangering the date of go-live. Communicate this approach and the way the backlog will be revised and approached so that a temporary workaround can be found if needed.
  • Teams are built, team disband at the end of the project, resulting in a loss of knowledge, experience, resources and continuity. Plan for it, and communicate to ensure all the relevant information is captured on an on-going basis, and that there is an onboarding plan for new resources.
  • Plan the transition to the Support Model (blog upcoming in the next weeks); clarify the respective roles of external and internal support; define acceptable turn-around times for questions and issue resolution, and be ready to monitor.
  • Keep records of support logs to verify type of queries and check efficiency of knowledge repositories. Sometimes a quick revision or a new video can save many frustrating hours while drastically reducing the support requests submitted.
  • Review what day-to-day business processes will be most impacted, and plan to have back-up if needed.
  • Plan for scalability: it is not only important for large corporations and projects (where it must be part of the project planning), but also in smaller initiatives – so that people and resources can be managed, the amount of work is regular, and knowledge transfer needs can be met.
  • Quantifying Return on Investment – hopefully, ROI has been defined at the time of the establishment of the business case. Running measures and analytics before go live and immediately after is the way to establish the baseline.

In the next chapters, I will cover the following topics:

So come back to our blogs to learn more!

For more information or to request the full whitepaper on this topic and more, contact me at cbersano@lsiconsulting.com, and visit my Linkedin profile for more blogs and details.