Newsletter October 2006

Improve usability and quality within your SAP HR application

Part III: From Error detection to an Internal Control System (ICS)

Under the pressure of tight schedules and budgets many SAP HR implementation projects end up with a system that works somehow and in most cases produces the correct payroll results … for the moment. However, most projects fail to provide an application that supports its users in the best possible way to ensure high quality of everyday processes, let alone procedures to support quality management for future changes, such as support packages, upgrades or new functional requirements.
In this article we want to give you some ideas to include into your own quality initiative. Similar measures have been implemented by the experts of AdManus in various projects and have proved to be highly beneficial.

1 Testing procedures and test automation

Testing is a very time consuming and often ill-defined task, which tends to be passed to and fro between HR and IT departments. To reach higher levels of security and efficiency

systematisation
automation
and a proper test environment

are necessary.

Who’s got to do it?
To achieve a clear task sharing between HR and IT is already a large step forward. In most cases, both departments will play some role in testing. How exactly tasks are distributed depends on the distribution of other SAP-related tasks (e.g.: who does the customizing?) and knowledge. A common definition is this one:

The IT-department checks, whether the process can be performed at all without error messages.
HR tests for the correctness of the outcome – such as payroll results.
When necessary, acceptance tests may have to be added, ensuring user friendliness. This may be done by the HR department or outsourced to an ergonomics testing lab.

When to test what?
This question is more difficult to answer – and often testing is performed more or less randomly depending on the time available. There is certainly no such thing as a 100% waterproof test. However, the level of security you want to achieve and the effort you want to invest to achieve it should be decided upon by the management. This decision then leads to appropriate testing procedures which must be documented once and serve as the guideline for the future:

Which events trigger testing activities?
e.g.: support packages, changes in customizing, periodically,…
What has to be tested at each of these events?
e.g.: check payroll results, perform user-interactive processes such as personnel actions, check authorisations
How to document test results?
Auditors may demand that all or certain tests are documented with the signature of the person who performed the test.

How can you make your life easier?
For payroll and time evaluation in particular, automating tests is easily possible. After having defined a reference result, a test tool can compare new results with this reference after any change in the system in a batch run. This allows you to check the whole test data every time you make even a small change in the configuration with only little effort. This leads to a much higher level of security than just picking individual cases to test manually. It particularly avoids the effect that correcting one error leads to a problem in a different case you don’t even think of.
Tools for automating tests are available from several providers at different packages and prices. The AdManus company iProCon offers a template based custom solution which generally can be implemented and explained in one day.
Interactive processes are much more difficult to test automatically. In some cases, the SAP CATT tool can help – but only to a limited extend.

Test environment
The availability of a proper test environment is crucial for any test. This may be a copy from the life system done in regular intervals or a targeted approach to set up an anonymous and documented test population to cover all relevant cases. Both cases have there pros and cons, depending on the technical and organisational requirements of your organisation.

Here are some criteria for a good test environment:

Cover all relevant cases
Data for all processes – not just payroll and time management
The system should be identical to the life system as far as possible (except for the changes yet to be tested)
An appropriate amount of data to test reports
Availability of all relevant variants, queries and infosets
Availability of all relevant forms (e.g. for correspondence in recruitment)
Possibility to test processes with the same roles they are performed in the life system
Possibility to test the interfaces – particularly ALE

2 Integrating procedures beyond SAP

Up to now, this little series on quality management has only dealt with elements within SAP HR. After all, this is our main focus.
However, be aware that an IT-system can never be the single answer to questions about process quality. A clear definition and documentation of processes, no matter whether performed manually or IT-based, is an indispensable prerequisite for high-quality processes.

We want to mention only a few not SAP-related elements that have to be included into a quality system:

Designing simple and lean processes
Clear definition and communication of these processes
Check lists
Well defined leeway to deal with exceptions
Responsibilities
Tools outside SAP HR
Traceability, particularly for auditing purposes

3 Bringing it all together: the ICS

This series covered the better part of the elements necessary to build an Internal Control System (ICS). Before setting up your ICS, you should be crystal clear about its objectives. The term “ICS” is used very often with very different concepts in mind. So you should ask yourself some questions before you start:

Is the whole system just a response to an auditors’ report?
Does it aim at reducing errors in payroll?
Do you want to target real business risks evolving from HR processes? In this case, payroll may not be a big issue at all but other processes such as recruiting and succession planning become much more important.

Based on these objectives, a central document should be created to capture the important elements of your ICS:

Which processes are included in the ICS?
With which methodology and tools and to which level of detail must the processes be described?
What are the rules for exception handling?
How do IT systems help to ensure the quality of the processes?
What are the procedures for system changes?
How do we describe testing procedures?
How must tests and other events with relevance for auditing be documented?
Which checks and monitoring tasks have to be performed regularly?
Where is all the detailed documentation to be found?

It is recommended to keep this central document as lean as possible and refer to more detailed documentation elsewhere. This allows for a better structure and better maintainability and enhancement. If the system is not constantly adapted to changing requirements, employees will start working around the rules and the whole system collapses.

There are two principles you should always have in mind:

It must be feasible to follow the procedures within the time available. If you use IT, checklists and documentation intelligently, then it should make daily work more efficient in the long run – not more complicated.
The system must be maintainable. Are the rules fixed on a too detailed level, than you have to change it much too often.

If you want our experts to help you with any issues concerning quality and usability or internal control system, contact us via e-mail: kontakt@iprocon.com

Back to Newsletter 10/2006