We're Live! Now How Do We manage This Thing?

OVERVIEW

Installing a new SAP system, including the HR component, is a major undertaking. Companies often spend millions of dollars and dedicate dozens of employees to a project that can take a year or more to complete. Once the system cutover passes and the consultants go away, companies are faced with a new, different, and sometimes unexpected challenge - managing the productive system.

WHAT ARE THE CHALLENGES OF MAINTAINING A PRODUCTIVE SAP HR SYSTEM?

From the second you perform your first SAP transaction, whether it is hiring a person or producing your first SAP paycheck, you are producing historical data that will be used in future reporting, calculations, and transactions. Now you have real, live work processes and historical data to consider whenever you think about changing work processes or system configuration. And you will make changes - regardless of what HR system you use, there will be changes driven by organization restructuring, regulatory compliance, and so on. For each and every change you make to work processes and system configuration you must ask the question - How does this change impact my existing data and work processes?

This is a different paradigm from the implementation project that you may have just completed. During implementation there is no historical data created, so if the process change doesn't fit with the data it's OK - just delete the data and start building it again. And if a process change affects another process, you can probably take your time making these adjustments. But in a production environment, you can not ignore historical data and you can not postpone or ignore affected work processes.

WHAT ARE SOME OF THE SYSTEM CHANGES THAT ARE TYPICALLY SEEN?

There are many types of changes that can occur once your SAP system is productive. Here we are focusing on the HR module, and these are some of the more common changes that have to be managed:

Configuration bugs not resolved before cutover: System testing, integration testing, even full scale parallel testing will not catch every bug in the system and in your configuration. Once you find these problems you must remember the work processes and historical data: Do I have to change some work processes to resolve this problem? Do I have some historical data that is incorrect due to this problem, and if so how should I correct it?

Legal Change Patches (LCP's): Since HR regulations vary by state and even by locality (there are an estimated 4,000 tax authorities taxing paychecks in the US), there are often regulatory updates that SAP must deliver for the HR module. These updates can be as often as every two weeks; sometimes they may change the way existing transaction and programs perform, or they may introduce new functionality that is required. All of the changes introduced by the LCP must be evaluated against the existing system configuration to determine if any changes need to be made to work processes and if changes to system configuration are required. Some people call LCP's 'mini-upgrades'.

Upgrades: Full, version-specific upgrades can require significant effort. Business specialists need to evaluate new functionality against the current environment to determine if processes need to be changed. IT specialists need to determine how to change system configuration in areas where SAP offers increased functionality and determine if custom reports or interfaces need to be changed. And thorough testing must be done to ensure the new version delivers comparable results to the current version. These are just a few of the points to address. Upgrades have the potential to become mini-implementation projects.

Addition of functionality left out of initial scope: Some companies reduce their implementation scope so they can go live on budget or on time, and they often push these items into a 'Phase 2' effort. Once the system and work environment is live, adding additional functionality can be tricky. For example, maybe Time Management is a 'Phase 2' item - it may drive changes in how you manage the existing work schedules, the current payroll process, and system security profiles. Maybe you find that a few new work schedules are required and that you need to change the way you produce system defaults for basic pay - these are all changes that can be made, but you must consider the impact to historical data and existing work processes.

Phased implementations: Larger companies may implement one division, location, or subsidiary at a time. In the initial implementation you will try to determine requirements for all the divisions, but you will not discover each one of them. As you bring in divisions you will have to integrate these additional requirements into your productive system

HOW DO YOU MAINTAIN SYSTEM STABILITY WHILE INCORPORATING SYSTEM CHANGES?

There are several actions you can take to minimize system disruptions. There is no single solution that will work for everyone; rather, you should practice all of these actions as part of an overall change management process:

Involve user groups in testing and change management: While system specialists may be making configuration changes or corrections to custom reports, the system's users should have the final authority on whether or not the change gets migrated into the production environment. Users have the ultimate vested interest in ensuring the system correctly performs its duties, and by testing system changes they have more control over their environment.

Establish an effective Quality Assurance system environment: Final testing of system changes happen in a Quality Assurance environment - typically a separate SAP instance between development and production. This environment should contain a client that has a recent copy of the production employee data - all the HR data, payroll results, etc. In this environment the system changes can be tested against real data, which is much more likely to identify problems than manufactured test cases.

Document all system changes: Whatever method is used for system documentation, it is vitally important to document changes. A change made today may make sense to the person doing it, but a year from now when that person may have moved to another department will anyone remember why the change was made? If that piece of customization has to be revisited, how will you know the details about why it was done and what its dependencies may be?

Setup system config to be date-dependent: This is particularly important in the Payroll and Time Management areas since they use rules and schemas. Changes to rules and schemas are not time-dependent, but change to wagetypes are. If you ever have to change the characteristics of how a wagetype is processed, you will most likely want that change to occur at a point in time, not retroactively. The best way to do this is by using date dependent customizing, not by changing existing rules.

Develop and follow regression testing procedures: A good test environment, good testing procedures, and date dependent configuration does not matter if you have incomplete testing procedures, or if you do not follow your testing procedures. It is almost always easier to perform thorough testing than it is to fix a production problem due to a faulty system change.

Establish a separate Crash & Burn environment: Most SAP HR customers have Development, Quality Assurance, and Production environments. A fourth, separate environment can be extremely useful for testing upgrades, LCP's, and for troubleshooting production problems. A Crash & Burn environment is a copy of the Production environment, periodically refreshed, in which customizing is allowed. It enables you to test the effect of system changes in the productive environment without first making the changes in your development environment. The Crash & Burn environment is like a 'sandbox' environment used in many implementation project.