Organizations using or implementing SAP ERP Human Capital Management (SAP ERP HCM) demand measurable business benefits, such as reducing costs as a result of restructuring HR functions. This presents an opportunity to review, redesign, and document HR processes. The documentation of these processes is often treated as a low-priority activity. However, well-designed process documentation can generate significant additional benefits, particularly by:

• Reducing cost during the testing cycle
• Facilitating change management and organizational design
• Strengthening process controls
• Supporting the development of flexible, modular training materials
• Improving accuracy through better understanding of end-to-end processes
• Enabling ongoing process improvement
• Assisting future training of new HR staff or those providing emergency coverage

The key to unlocking these benefits lies in the structure and format of the process documentation. Before presenting detailed recommendations, I will review how you can use the documentation during an implementation and after a go-live. The aim is to maximize the business benefits and minimize the effort required to create and maintain the documentation.

My advice is based on experience with both commercial and public sector organizations. The structure and design principles featured in this article were used successfully in a recent SAP ERP HCM implementation for a global manufacturing organization in which significant organizational change occurred in parallel with the SAP ERP HCM implementation.

Generating Business Benefits During an Implementation

To maximize the benefits of process documentation you need to invest time at an early stage of the project. Because a number of factors affect process design (such as organization structures, SAP functionality requirements, and third-party integration points), you cannot finalize the processes until you fully define each of these areas. These areas are usually known at the end of the blueprinting phase of the project, which allows the documentation to take place in parallel with the system build during the realization phase.

The fact that SAP ERP HCM is an integrated system facilitates the design of efficient business processes. Historically, organizations may have used several different systems to manage HR processes, such as payroll, organizational information, employment history data, training administration, recruitment management, and personnel development. This approach would often necessitate the duplication of data entry and other activities in multiple systems. However, SAP ERP HCM removes this duplication and enables the design of far more streamlined processes. SAP system installations that don’t take the time to perform good process documentation may be missing the opportunity to capture some of the advantages of having an integrated system.

Process diagrams provide a clear way to present processes to workflow experts who may be unfamiliar with the functional business processes. In addition, it is vital that the workflow process definition be based around well-designed business processes, rather than simply automated from poorly designed processes that may exist outside of SAP ERP HCM.

Beware of one potential pitfall you may encounter during the process design phase: you may find yourself dwelling on the details of obscure processes. I would recommend that you do not document processes for handling infrequent errors in the format described in this article. The low volume of obscure error processes, together with the often complex correction procedures required, means that there is little business benefit to be gained from time spent documenting those. It is usually more appropriate that users be directed to the SAP ERP HCM support functions in cases where errors occur, so that these can be handled on a case-by-case basis.

The goal should be to complete the documentation in time for it to be used during user training and user acceptance testing. Figure 1 is a summary timeline showing process documentation activities. Items in dark blue represent tasks associated with the production of the documents, and items in light blue indicate areas where the documentation can be used.

Figure 1

Example timeline with process documentation activities

The time invested in documenting processes, when invested early in the project, produces benefits in the following areas:

• Training: Training often focuses solely on SAP transactions. However, the documentation design provides tools to deliver more comprehensive and focused training. Rather than having the trainees learn the SAP transactions in isolation, the process maps help them understand where their activity sits in the end-to-end process, and what prerequisites and dependencies exist. This is particularly useful in areas with fairly complex process dependencies, such as payroll processing, in which SAP ERP HCM processes are likely to differ somewhat from legacy payroll systems. In addition, the detailed user procedures can form part of the training materials. Finally, the responsibility matrix, showing which teams will carry out which task, can be used to ensure that the training courses can be designed in a modular way that focuses on individual teams’ responsibilities.
• Testing: The process documentation is a ready-made foundation for user acceptance testing. The list of processes can become the test scope, and the detailed user procedures can be given to testers to ensure that the testing is carried out in a way that mirrors the real-world processes. It is likely that testing will cover multiple scenarios of a particular process, and it is very easy to create test scripts that include the data entry combinations with references to the appropriate user procedures. This removes the need for test scripts to repeatedly detail how to perform the test. In addition, using the process maps and user procedures during testing is a very useful way to validate the documentation itself. It will highlight any issues around the design or level of detail, and therefore you can make changes to the documentation before go-live.
• Organizational design: An implementation of SAP ERP HCM often goes hand in hand with significant restructuring of the HR and payroll functions. A number of different drivers affect the design of the new organizational structure. However, you can use the process documentation (or, more specifically, the responsibility matrix) to inform the organizational design process. It summarizes clearly where responsibilities for different tasks lie, and if used in conjunction with estimated data volumes, it can help identify headcount requirements within particular teams. In reality, process design and organizational design rarely happen sequentially, and there is likely to be an element of remodeling during the cycle. However, the modular documentation structure minimizes the effort of remodeling, should it be necessary to redesign a process as a result of a decision made during organizational design.
• Controls design: One of the main areas of risk in HR processes relates to hand-off points between different teams. This is the point at which information can be lost or misinterpreted. Single-page process maps, which I describe in the “Designing the Documentation” section, provide a good basis for designing controls by clearly showing where hand-off points between different teams exist. In addition, error information identified by controls can be fed back into the process design so that an improved process can be put in place.

Process documentation can generate significant business benefits during the implementation project. However, this is not the limit of their usefulness. Additional benefits are available post-go-live, as shown below.

Generating Business Benefits After Go-Live

One of the most frequent issues with process documentation generated during an SAP implementation is that it is not used post-go-live. Reasons include:

• Time pressures on users that cause document maintenance to be seen as a low-priority activity
• Reliance on key individuals who are seen as experts and who become the source of guidance, at the expense of documented procedures
• Complacency by users who become comfortable with the SAP ERP HCM system after go-live
• Sometimes the blueprint documentation focuses heavily on the as-is process rather than the to-be process, making it obsolete upon go-live

With a small amount of effort, the process champion can maintain documentation long after go-live. To realize these benefits, the documentation must be updated and easily accessible.

To keep the documentation up to date, a company should appoint a process champion within each functional team. These people are responsible for:

• Recommending changes to processes or to the documentation
• Communicating process changes to their team
• Acting as a first line of support for colleagues who are unclear about a process

I recommend appointing someone to manage process change (coordinating the activities of the process champions), review feedback from process champions and auditors, and analyze and manage any processes that need to be changed, in order to ensure that the impacts of the change are properly understood. These roles do not require a great deal of time, but the structure enables your organization to take on process improvement and documentation maintenance in a controlled and efficient way.

SAP Solution Manager is an excellent tool to store process documentation. It enables all users who have the SAP GUI to access electronic versions of the documentation, while maintaining control of document changes by restricting user authorizations. Often users have a tendency to print hard copies to retain locally, but you should discourage this to ensure all users recognize and use the most current processes. If SAP Solution Manager is not available, a secure, shared location on the corporate network is an alternative. However, one benefit of using SAP Solution Manager is that you can manage user administration and document access along with SAP ERP Central Component (SAP ECC) access, which will minimize duplication of administrative tasks.

Maintaining documentation post-implementation can benefit your organization in a number of ways:

• Training: The responsibility matrix facilitates the creation of work instructions for new starters into the HR or Payroll teams. In addition, it can support the transfer of staff between different teams either on a permanent basis or in short-term cases such as emergency cover for absence. The relevant process maps and user procedures can be quickly collated and used as the basis for training a new member of the team.
• Regression testing: When organizations make SAP configuration changes (either on the basis of business requests or statutory changes), it is good practice to carry out regression testing of key activities to ensure that there has been no adverse impact. Process documentation can form a framework for performing regression testing and reduce the workload involved in creating test scripts each time. The test scripts can simply reference the appropriate process or procedure documentation. In addition, if the people carrying out a configuration change do not have a detailed understanding of the business process, they can read the relevant process documentation to ensure that the change is performed in a way that meets the requirements of the relevant business processes. This reduces test failures and rework time.

• Inter-team understanding: In some organizations, a team may have little understanding of the process steps performed by other teams. This can result in misunderstandings during data processing and can also mean that problems take longer to correct while the staff tries to understand what went wrong. However, by structuring the process documentation in a way that shows the end-to-end process on a single page, any team can easily see the high-level steps that other teams perform in the process. This understanding of other teams’ responsibilities promotes teamwork across the organization, and results in fewer data processing errors and more efficient error resolution.

Designing the Documentation

The single most important consideration in the documentation design is that the results are relevant and useful to the end users. To this end, it is essential to involve key stakeholders in the decision-making process from the start. A group of stakeholders from HR, Payroll, and any other teams that play a part in HR processes should assemble and amicably answer the following questions:

• What is the list of HR processes that need to be documented? For example, should the re-hire process be considered part of the new hire process, or does it make more sense to list it as a separate item? This list will form the scope of the deliverables. Although there may need to be some movement as processes are documented, stakeholders should agree on the final list. This ensures that users understand its scope and terminology.
• Who will have the final say in any disputes about best practices for each process? Determining this at the start of the exercise limits wasteful discussion during the process design stage.
• Are the templates and terminology suitable for the end users? Once the teams draft the templates, users should review them so they can provide feedback regarding the level of detail and format. This helps ensure that the final documentation is meaningful to the users.

I have also seen that adopting a “modular structure” in the design can maximize benefits. In a modular structure, documentation is split so that each document corresponds to an individual task rather than a full string of tasks being contained within a single document. Although this creates a large number of separate documents, each document is clearly focused, allowing users to quickly find the specific information they require. A modular structure enables efficient user access to information, can be integrated easily into training and testing cycles, and is easily maintained.

In addition to adopting a modular structure, producing a two-tier structure to the documentation is recommended. At the top level, a process map shows which teams perform particular tasks in the end-to-end process (Figure 2). At the second level, a set of detailed user procedures explains at a key-stroke level how to perform a single stand-alone task (Figure 3).

In addition, you should compile a directory matrix. The matrix should clearly show which teams are responsible for which tasks in each process. It is a much easier way to perform a high-level review of responsibilities than by working through each process map in turn.

Figure 2

Example of top-level process map

Figure 3

Example of detailed user procedure document

The key stakeholders should agree on the layout and format of the two sets of documentation. However, I have a number of recommendations based on past experiences:

• Each process map should be limited to a single page so that users can easily see which teams and which tasks are included.
• The process map should use a standard swim-lane layout—one lane per team—even if a particular team has no involvement in a process. The advantages are twofold: First, it makes the documentation easier for users to understand at a quick glance. Secondly, it facilitates the creation and maintenance of the matrix of responsibility.
• The instructions for a user procedure should be sufficient and clear enough for a user who has not carried out the transaction to follow. It is also helpful to include screen shots.
• Each task on the process map should have a one-for-one mapping with a detailed user procedure. The user procedure document should have a unique reference that is included on the process map at the appropriate point.
• Although detailed user procedures are usually only created for tasks performed on SAP systems, it is worth considering documenting off-system tasks (such as reconciliation or control activities) in the same format. This ensures information is available for other people, as well as key users, to reference if necessary.

To put these recommendations into context, here is an example. A New Hire process map includes a flow chart showing each step in the process, which would usually include tasks for HR, Payroll, and facilities teams. One task should be for HR to perform a New Hire Personnel Action transaction. This would be represented on the process map as a single task, with a reference to the user procedure 01 New Hire Personnel Action. A later step in the process may be for Payroll to perform a New Hire Follow-Up Personnel Action to enter relevant payroll data. This would also be detailed as a single step in the process map, with a reference to a separate user procedure, 02 New Hire Follow-Up Personnel Action.

This structure allows Payroll users to quickly see that they only need to reference user procedure 02 in this case, and they don’t need to read through the instructions contained in user procedure 01, an HR function.

There are instances in which a transaction may be required in a number of different HR processes—for example, amending a recurring payment. The structure defined above can enable a single user procedure to be created for transaction code PA30 and infotype 0014 (maintaining a recurring payment or deduction for an employee). For processes such as promotions and transfers, users can reference this single user procedure at the appropriate point in the process maps.