Creating a Specification Document

The WFA data must be extracted and pulled into the WFA analytics database. This process is referred to as the SAP SuccessFactors data transformation. It identifies:

• The location of the data in the client source data.

• Any client specific business logic that effects the data.

• Code values and their descriptions to drive analysis dimensions.

The Specification Document defines the process of the SAP SuccessFactors data transformation for the client.

As a Functional Consultant, a primary tasks is creating, updating, and maintaining and collaborating the specification document.

The Data Questionnaire (DQ) is used to build the Specification Document, it asks the customer a series of questions about their HRIS and its setup. The answers to these questions, in combination with the specification template document, create a customer specific technical blueprint for the portal build.

The DQ is straightforward and well documented, so minimal guidance is usually required by customers to complete the questionnaire.

Data Questionnaire is broken into relevant sections; associated with the specification document.

1. Measures Section

2. Reporting Hierarchies Section

3. Analysis Options Section

4. Additional Information (Security, Data Delivery, Customization) Section

1. Codes

2. Custom Tables

System and Version: System is important to know what the database source will be for mapping. In some cases, the version can affect the data mapping so noting the version is important also.

Years of History: Determines the number of years in the system, and how much the customer would like to report on. The default history in a WFA implementation is 4 years, current year plus the last 3 years. Customers may want more or fewer years in their history.

Reporting Periods: WFA supports calendar and fiscal year. If the customer wants to use fiscal years, we must capture when the fiscal year starts.

Headcount: Approximation of headcount so consultants can quickly determine if all data is available in items like extracts.

Subsidiary Companies: Some customers may prefer not to report on all employees/parts of the organization. SAP SuccessFactors recommends extracting all data and providing the filtering during the data transform, but some clients still prefer to only supply a subset of employees.

International data: Similar to subsidiary, capture if the client wants to report on all countries or a subset.

Personally Identifying Information (PII): Determine if the customer would like to include the Employee Names in Drill-to-Detail output.

The data questionnaire will only include questions for determining base input measures.

The goal is to determine the source and logic for the different measures.

SAP SuccessFactors WFA requires headcounts and FTE counts for benchmarking. The count of people in a headcount and your FTE are going to be the same number. But we determine them in different ways. A headcount is always a value of 1. An FTE can be a fraction because the FTE value is based on the full-time or part-time condition as an employee.

If you capture all the logic around this FTE value, then you also know how to determine the headcount. The first question is if they currently report on FTE. Most customers use FTE, but not all in reporting solutions.

For clients that already have the FTE value used in reporting, we can use their data as the source. However, for clients that do not the FTE must be calculated.

SAP SuccessFactors WFA uses average FTE, (or the expected FTE), based on what an employee is expected to work, not on the actual hours worked. For example, a full-time person might be expected to work 40 hours a week. If a part-time person is expected to be 20 hours a week, the calculated FTE is 0.5. Note that:

• For a full-time person, the FTE is always 1.

• For a part-time person, the FTE is the expected hours divided by the normal full time hours (20/40 = 0.5 FTE).

In some cases, the full-time expected hours varies by companies or countries. If this is the case, it needs to be captured in the Data Questionnaire.

You will also need to determine who to include or not include in the FTE and headcount values. This is normally based upon an employee status. This will be described more in the Specification Document section.

You need to determine if the client counts determine these values in the same way as the SAP SuccessFactors data standard.

Hires and Rehires: WFA needs to identify when a person has been hired. Typically the HRIS system will use actions/action reasons. The customer can record the appropriate codes or logic for determining hires and rehires.

Uploads and Acquisitions: It is common for clients to have uploaded data from HRIS conversions or upgrades. With an upload, often the full history is not included. You need to identify upload records to include in counts, but often they do not have a hire record.

If the system has uploads, determine the way to identify those uploads and the appropriate hire date for the uploaded employees.

Often acquisitions will also lack a hire record and you must employ the same logic to capture the employee in headcounts and determine the hire date.

WFA uses the concept of movements-in and movements-out. This refers to movements that take an employee into a different job. Employees can get into a job (movement-in) because they have been hired externally, either as a first time hire or a rehire, or because they have moved from another part of the organization, either through a promotion, demotion, or a transfer. Movements-out also include promotions, demotions, or transfers, as well as terminations.

Internal Movements: Internal movements are the promotions, demotions, and transfers. You need to determine how to locate each movement. Typically, this is also done by actions/action reasons.

Often it is not that simple for a client to determine the difference in a transfer of promotion via action reasons alone. Sometimes multiple criteria must be checked, for example, an action reason, but additionally by looking for a pay grade change. You need to confirm the internal movement logic with the customer.

It’s important to note that reorganizations should not be considered transfers.

Terminations: Most organizations are very interested in terminations. They want to know how many people leave and he reasons why they leave. Many measures are based on terminations. You need to identify them accurately

Typically, a status change will identify a termination. When an employee terminates, they tend to be put into a terminated status regardless of HRIS System.

It is useful to do this in conjunction with action reasons to understand the reason for termination. Once identified, WFA can classify those into voluntary, involuntary, and other. That allows WFA to generate richer status measures around the terminations instead of simply identifying one type of termination.

Finally, capture what date the termination occurs versus the status change. More information in the Data Standards section.

As a standard, the SAP SuccessFactors WFA implementation includes two hierarchies of the member’s choice. The most common type represents the organizational structure. Hierarchical dimensions (also called structural dimensions) are customer specific so capturing and validating the structure is the way the customer prefers to display them will be important during the implementation.  

Organization Structure: You must determine the Organization structure the customer wants to use and how the tree structure is determined. Additionally, the several questions around changes and inactive nodes can trigger discussions around different hierarchy options available in the WFA design. This will be discussed in more depth in the section on filling out the specification.

Locations (Geography): The second most common is geography. You also must determine the tree structure the customer desires for the geographical breakdown.

Additional Hierarchies: The customer may wish to filter reports in another structural dimension, such as a financial cost center structure.

Names, Age and Gender: Simply identify the data source for these fields

Disability and Ethnicity: The ethnic group of a person allows for the identification of employees as minorities and non-minorities. This information is not captured in all parts of the world. For example, this is uncommon in Europe, so for multinational organizations, it is important to determine how to capture this data. If you use this dimension, make sure to properly identify areas where the information is not obtained and classify it as not recorded.

Disability, like ethnicity, is not recorded in all cases. Capture where it is used and how it is identified.

Employment Status: provides a dimension to identify the current status of employees. Note that it is also typically used to identify which employees are included in headcounts and FTE. Statuses that are not included in headcounts will not be part of the dimension structure.

Employment Type: employment types are broken into two classifications- duration and attendance. Duration is for regular, temporary or casual classification. Attendance classifies employees as full-time or part-time.

Employment Level and EEO1: Applicable to US based employees only.

Grade/Bands: Not all customers will use grades or bands. For multinational companies, you might need to capture potential differences per location and how to translate them into a global classification that is shared across the entire organization. Additionally, sometimes this source needs to be used to determine the type of movements for a base measure.

Job Families/Functions: Not all customers will use job families or job functions. If they do, capture the source.

Managerial/Non-Managerial: Determine employees that have direct reports. The logic to determine if an employee is a manager can be quite complex. Emphasize to the customer that this is for managers with direct reports, not individuals that simply have manager in their job title. That distinction is important since the dimension is benchmarked.

Organizational Tenure: Customers need to identify how to determine the length of tenure, typically a hire or service date. However, confirm how to handle the values for rehires.

Position Tenure: Even if the client does not report or capture this data themselves, typically it can be built based upon status changes (hires, promotions, demotions, transfers).

Salary Range and Currencies: If the customer needs to analyze data by salary, then you need to capture the employees’ salaries. For multinational companies, be sure to consider what currency to report in and how the values will be converted. Also, consider part-time employees and how their salary is stored in the HR system. Finally, does the customer want to include incentive pay in the salary and now is that captured.

Role Based Security: Capture preliminary information of how to restrict data access. The primary concern here is if they want to restrict the views of portions (parts of the hierarchy) of the data by a dimension, that dimension needs to be a structural dimension. Analysis dimensions can only be restricted to the entire hierarchy.

Data Transfer and Data Encryption: It is important to understand and capture the preferred mechanism for transferring the customer’s data to the SAP SuccessFactors data warehouse when applicable. All data should be encrypted, so determine any requirements by the organization's own encryption standards.

Appendix A: Most HRIS systems use codes to represent values for a variety of fields. The appendix contains a list of common fields that use codes. This appendix provides an area for the customer to document those codes and values. This greatly simplifies the process of completing the specification document when the codes and values are obtained ahead of time.

Appendix B: If the customer has customized tables used to determine measures or dimensions, then they can document the custom table structure here.

Customer Measures/Dimensions: If the customer has recognized a customization they need for the WFA portal, they can document them as part of the data questionnaire. The customer should be aware of the standard configuration from the metric pack documentation. Determining customizations at the beginning of the project streamlines the inclusion of these customizations as part of the normal implementation project.

The WFA Data Specification (DS or specification document) contains all of the business logic and extract data required for the population of the SAP SuccessFactors portal.

During the creation of the Specification, take the answers provided in the data questionnaire (DQ) and update the Template file with the appropriate data. The end result is the Specification Document.

Details for creating the first version of the DS is covered later in this unit.

After creating the preliminary specification document (the very first version of it) usually there are quite a few holes and questions and items for discussion with the customer. You need to go through a review session with the client and, for the foundational metric pack, it should be handled as part of the Kickoff meeting. Other metric packs might be reviewed by some other means. Onsite, face to face review is always the preferred method for the initial review of any specification when possible.

The purpose is to review the document in detail. During the session make sure that the people stay focused and on topic of the project goal, because often the review session is not just to review the specification document, but it is also another avenue for the project manager to start talking about what is going to happen, understanding who are going to be the users, and what measures are going to be used as key performance indicators. Additionally, the functional consultant should look to gain an understanding of the data that the customer has, the idiosyncrasies that there might be within the data, the cleanliness of the data.

You should go through each section of the specification, explaining to the customer what each section is and what it means. This is important because they will be using this document later and reviewing it periodically, so they need to understand what everything is. During the review you will explain to them how to read the document and how it’s used later on.

From the review, any pending information you cannot resolve while you are in that session has to be flagged for the information to be provided later on. It is usual to through a number of iterations until you have a completed document.

The specification documents is version controlled. There is no hard rule on how to version the document. A recommended method is that the very first version will be 1.0 and then if anything is changed it will be 1.1, 1.2, etc.

Only when there is a major change such as adding a new source system or some major change on the version, then take it to version 2, version 2.1, etc. Every time you make a change you must update the version. Based on experience, it is recommended that in each version you identify changes made by changing colors on the font and only identifying the changes from the prior version to the new one rather than trying to keep track of all the changes that have happened since the original version.

Another recommendation is when you send a specification to do a little summary on the email that identifies areas that are changed. You don’t have to be very specific. It helps the recipients quickly locate all of those areas that need to be reviewed. If they have already viewed and accepted all the other areas, this streamlines the process.

Ideally, sign-off acceptance should be achieved within the first 3-4 iterations of the specification document but there are no hard and fast rules. Much depends on the efficiency and commitment of the client’s project team and their knowledge of their systems and data practices.

Clients are often worried about the sign-off process thinking that they will be charged for any change that occurs afterwards and this fear can delay the acceptance point. You should stress to the client that the specification is not set in concrete and that the reason for getting sign-off is to get to the point where the initial implementation can commence. The specification is a living document and in general will change as a result of the verification processes before getting into a production status.

Once the point is reached where the client is ready to accept the initial specification, an official acceptance via email is requested in order to document the milestone reached.

Data Standards are the foundation for which important and useful information about the calculation of measures and metrics can be made and understood.

Establishing standards is the first step towards implementing an individual measure within an organization’s measurement capability. Any measurement capability must be founded on agreed-upon measurement standards. With the established platform of measurement standards, organizations can build solid reporting, analysis, and decision-making competencies. Without an understanding of the standards, HR faces significant data credibility risks both from internal business partners and as an organization.

Data Standards address these two root problems: Measure Inconsistency and Lack of Understanding Results. To counteract these, organizations can adopt measurement standards that establish agreed-upon calculations and shared understanding of measure meaning and relevance.

The headcount is the total of all people employed during the reporting period. You include/exclude the following in Headcounts.

• All full-time, part-time, and temporary employees paid through the payroll.

• Part-time employees, counted individually.

• Fixed term contract employees.

• Employees in both ongoing and non-ongoing positions.

• Employment Status of Active, Paid Leave and Leave of Absence <3 months

• Interns

• Workers paid by a third party.

• Staff on unpaid leave for more than 3 months.

• Supplementary workers for example contractors, agency staff and/or consultants not on the payroll system.

• Employment Status codes of Suspended, Terminated, Terminated with Pay, Deceased, Retired with Pay, Retired, Terminated Pension Pay Out, Short Work Break or Retired-Pension Administration.

Employees who are included in FTE measures follow the same inclusion/exclusion rules as headcount.

Many result measures use average headcount in the calculation: therefore it is important to understand how average headcount for a period is calculated.

The average headcount value of people that are present for only part of the reporting period, for example their hire date is after the period start date, is pro-rated based on the number of days present during the reporting period. For SAP SuccessFactors members this will be calculated on a daily basis.

For example, consider the following:

Day 1 = 12 employees

Day 2 = 10 employees

Day 3 = 8 employees

Day 4 = 8 employees

Day 5 = 12 employees.

The measures of headcount for this example will be:

• SOP Headcount = 12

• EOP Headcount = 12

• (EOP Headcount + SOP Headcount)/2 = 12

• Average Headcount = (12+10+8+8+12)/5 = 50/5 = 10

People that are present at the end of the reporting period, hire date is before or equal to start date or termination date is after the period end date, have an EOP headcount of 1.

People that terminate on the last day of the reporting period have an EOP headcount value of 0.

For example, an employee that is terminated on March 31, 2017, does NOT count for EOP of March 2017 or EOP for Q1 2017.

People that are present at the start of the reporting period, their hire date is before the period start date or their termination is after the end date, have an SOP headcount of 1.

People that commence work on the first day of the reporting period have an SOP headcount value of 0.

For example, an employee that is terminated on January 1, 2017 does NOT count for SOP of January 2017 or SOP for the year 2017.

The FTE value is the sum of all people employed during the reporting period weighted by their FTE factor. You include/exclude the following in FTE.

• All employees paid through the payroll.

• Part-time and temporary employees who are on the payroll (converted to FTE based on actual hours worked).

• Fixed term contract employees paid through payroll.

• Employees in both ongoing and non-ongoing positions.

• Employment Status of Active, Paid Leave and Leave of Absence <3 months

• Interns

• Overtime.

• Staff on unpaid leave for more than 3 months.

• Workers paid by a third party.

• Supplementary workers for example contractors, agency staff and/or consultants not on the payroll system.

• Employment Status codes of Suspended, Terminated, Terminated with Pay, Deceased, Retired with Pay, Retired, Terminated Pension Pay Out, Short Work Break or Retired-Pension Administration.

The FTE value is the sum of all people employed during the reporting period weighted by their FTE factor. The FTE factor is calculated by the following method:

• Full-time employee = 1 FTE.

• Part-time or temporary employee = Employee Standard Hours/Company Standard Hours.

• In some cases, the FTE Percentage is available in the source data and does not require further calculation (preferred).

To calculate FTE, it is necessary to know the standard number of working hours per employee for the specified period. In some organizations employees may be subject to different agreed standards for working hours varying from 35 hours to 40 hours for an employee pending job classification.

If there are substantial numbers of employees operating under different agreed standard work hours, it may be necessary to pro-rata the number of hours for each group.

The Expected FTE value of people that are present for only part of the reporting period (Hire Date > Period Start Date and/or Termination Date < Period End Date) is pro-rated based on the number of days present during the reporting period.

• Any External or Internal movement for which a requisition has been filled.

• Temporary staff who are already on the payroll system and have been recruited into a full-time position.

• Organizational restructures.

• Acquisitions.

• Supplementary workers, for example, contractors, agency staff and consultants not on payroll system.

• Workers paid by a third party.

• Employees whose contract is automatically renewed.

• Temporary job rotations or assignments.

• Reclassification of job role.

The definition of External Hire is a person that does not work for the organization already. Therefore, employees that are considered conversions, acquisitions, or hires from an affiliate will not be counted as external hires, they will be treated as either internal or other movement instead.

• Hire.

• Rehire.

• University graduate recruitment.

• Internal movements.

• Supplementary workers, for example, contractors, agency staff and consultants not on payroll system.

• Workers paid by a third party.

• Employees whose contract is automatically renewed.

• Acquisitions.

• Reclassification of job role.

• Organizational restructures.

The total number of ex-employees rehired during the period. These employees must have been terminated from the system before being rehired.

Recruits who commenced their second or subsequent period of paid employment with the organization (temporary or permanent).

• Internal movements.

• Temporary staff who are already on the payroll system and have been recruited into a full-time position.

• Supplementary workers, for example, contractors, agency staff and consultants not on the payroll system.

• Workers paid by a third party.

• Employees whose contract is automatically renewed.

• Acquisitions.

Where a promotion and transfer are identified to occur on the same date, the movement is counted as a promotion and not double counted.

Internal Movements are then broken down into the following:

• Promotions: Where an employee position changes within the organization and the change involves a move to a position at a higher level or grade.

• Transfers: Where an employee changes position within the organization and the new position is at the same grade or level.

• Demotions: Where an employee changes position within the organization and the new position is at a lower grade or level.

• Promotions.

• Transfers.

• Demotions.

• Temporary staff who are already on the payroll system and have been recruited into a full-time position.

• Intern conversion

• External Hires.

• Supplementary workers, for example, contractors, agency staff and consultants not on the payroll system.

• Workers paid by a third party.

• Employees whose contract is automatically renewed.

• Temporary job rotations or assignments.

• Reclassification of job role.

• Organizational restructures.

• System reclassifications.

This is usually reserved for organization initiatives that result in a significant business change. This can be either growth of the organization that is not linked to specific hiring or a reorganization of the business structure.

• Organizational restructures.

• Acquisitions.

• Hire from affiliate.

• Any External or Internal movement for which a requisition has been filled.

• Supplementary workers, for example, contractors, agency staff and consultants not on the payroll system.

• Workers paid by a third party.

• Employees whose contract is automatically renewed.

• Temporary job rotations or assignments.

• Reclassification of job role.

Termination reflects the total employee turnover within the organization, for any reasons during the reporting period. Terminations as a total are split into three specific separation reasons:

Terminations = Voluntary Terminations + Involuntary Terminations + Other Terminations.

These are the terminations represented as the number of employees who terminated employment at their own initiative during the employment period.

• Resignations.

• Retirements.

• Relocation/Transfer.

• Fixed-term contract staff who resign prior to the end of their contract.

• Dismissal.

• Redundancy.

• Early retirement packages offered by the organization to the employee.

• Divestitures.

• End of a fixed-term contract or temporary assignment.

• Death.

The number of employees who had their employment terminated at the organization’s discretion during the period.

• Dismissals.

• Redundancy (both voluntary and involuntary separation packages).

• Early retirement packages offered by the organization to the employee.

• Organization initiated termination of a contract before its expiration.

• Resignations.

• Retirements.

• Relocation/Transfer.

• Fixed-term contract staff who resign prior to the end of their contract.

• Divestitures.

• End of a fixed-term contract or temporary assignment.

• Death.

The number of employees who separated from the reporting organization for other reasons.

• End of a fixed-term contract or temporary assignment.

• Divestitures.

• Death.

• Contract expirations where the contract was renewed immediately, and the employee did not leave the organization, such as, on a rolling contract.

• Any other reason noted as an inclusion for either Voluntary or Involuntary separation.

The Employment Status refers to the employee as defined in the HRIS as being either Active for payroll or Inactive.

An Employment Status will have at least three states in the HRIS. Other states may be used to report a transition from being an employee to others for ex-employees. Only those considered Active (for payroll) as defined by the inclusions for headcount measures are used as standard.

• Active

• Leave

• Paid Leave

• Deceased

• Retired with Pay

• Retired

• Suspended

• Terminated

• Terminated with Pay

• Terminated Pension Pay Out

• Short Work Break

• Retired-Pension Administration

Allows analysis of measures across different employment types and identifies the proportion of the workforce that is full-time or part-time.

Part-Time: This represents employees in either regular or temporary employment for a regular number of hours that are fewer than a full-time organizational commitment on the part of the employee. According to the Bureau of Labor Statistics, working part-time is defined as working less than 35 hours per week. To reflect the diversity of the workplace, BLS disaggregates the data about people who work fewer than 35 hours into three subgroups: (1) those who voluntarily work part-time, (2) those who work part-time for economic reasons, and (3) those who usually work full-time but worked fewer than 35 hours during the reference week because of holiday, illness, vacation, or similar reasons.

Typically, part-time employees do not receive the same leave, health insurance, retirement, and other benefits as full-time employees receive. The decision for granting part-time employee benefits is at the discretion of the organization.

Full-Time: This represents employees in either regular or temporary employment involving full number of hours defined by the organization as the standard work week.

Full-time employment often comes with benefits that are not typically offered to part-time, temporary, or flexible workers, such as leave, health insurance, retirement, and other benefits.

Allows analysis of measures across different employment types and identifies the proportion of the workforce that is regular/temporary in employment nature.

Regular Employees: This is the number of employees, paid through your payroll system as salaried workers with associated benefits, regardless of whether they work full or part-time hours.

Temporary Employees: This is the number of employees, paid through the payroll system, who are employed on an hourly basis at an hourly rate of pay that normally includes loading in place of leave and other entitlements. Temporary employees can work either part-time or full-time hours. A temporary assignment can end at any time depending on the employer’s needs.

Temporary employees reported here are hired directly by the organization are included on the HRIS. An employee working on a temporary assignment from a staffing agency is considered a Contractor. These employees remain employees of the agency, not of the company where they are placed.

The groups that make up each of these are as follows:

Minority: Black or African American, American Indian and Alaska Native, Asian, Native Hawaiian and other Pacific Islander, Two or more races as well as Other.

Non-Minority: White

The first version of the data specification (DS)is based on the customer’s questionnaire.

The specification document templates are an Excel document that has a number of worksheets or tabs. Each tab has a different type of information. This training looks at the different tabs or sections.

The notes section is used to record supporting information that can be of assistance to the technical consultant team, the onsite partner team, and the customer. It can contain notes about decisions made during the data discovery process. Typically, it includes information provided in the Introduction section of the data questionnaire.

It documents items like the history, the reporting calendar, the number of headcount, scope, exclusions of subsidiaries, use of employee names, conversion/acquisition, and general exclusions.

1. System: <include details of the member's HRIS and database>

2. History: <include details of number of years of data history available and how many years will be included on site>

3. Reporting Calendar: <Calendar Year or Fiscal Year - if fiscal year, include the date the year starts from>

4. Headcount: <Approximate headcount numbers at time of implementation>

5. Data Scope: Data does not include employees in countries other than USA

6. Employee Names: <Indicate if employee names will be included in the data>

7. Data Conversion/Acquisitions: <Include relevant comments if applicable or indicate if not applicable>

8. General Exclusions: <Include any exclusion logic that applies to all measures>

9. International Expatriates: <If applicable>

10. Data Standard: refer to the Data Standard section for details.

The next section of the Specification Document is dedicated to the base input measures. In this section, you start translating the information from the questions asked about the measures.  

The measure name should not be changed in this column of the specification document. The measure override tool can be used to change these names by partners or clients during the beta site review phase.

The Rollup Type tells how the measure is calculated. There are three types of rollups:

Average: average the value across whatever period of time. For example the average headcount over a month

Point in time: like a snapshot at a period of time. For example the headcount at the end of a period

Aggregate count: occurrences over a period of time. For example the number terminations within a month.

Distinct count: an aggregate count that removes duplicates.

Adding additional metrics to this list constitutes customization that could expand timelines and incur additional costs.

Similar to measure names, any changes to description should be done in the measure override section in the web application. Making changes here does not actually change any business logic. Therefore, it is important that this text accurately describes what is being calculated.

This section is important in conjunction with the source column. While changes can be made to this section, we highly advise not making any changes. Descriptions follow of common areas of discussion in regards to this column.

In the specification template, there are separate columns for the different common sources for the Core Workforce and Mobility Metric pack (i.e. different HRIS). There are sources for SAP SuccessFactors Employee Central, SAP, Oracle, and PeopleSoft. The is additionally a ‘generic’ column for other HR systems as a source. Data sources not applicable to the project should be removed.

There are rows for the different base input measures. Some detail about some of the base measures follows:

In this metric, it is critical to identify how to source an employee’s full time equivalent value. Many clients have this pre-calculated in decimal form on an employee’s data record. This is the ideal source however, SAP SuccessFactors can also make the calculation by dividing an employees’ standard work hours by the company’s work hours. This method becomes problematic for global companies where each country or region may have a different work week.

While SAP SuccessFactors can have separate calculations for separate populations, it adds hours to the project quite quickly. Please ensure that dynamic and holistic business logic is identified so as to avoid custom coding for multiple different populations.

The FTE metric source is also used to identify the entirety of the population that will be analyzed in WFA. It is important to identify what populations should be included and excluded in this section of the specification. If an employee does not meet the conditions to be included in this metric, they should not be expected to be reported in any other measure. Subsequent metrics refer back to this measure to identify the applicable WFA population. For example, an employee with a termination record cannot be counted as a termination unless they were previously in the FTE count.

Refer to the data standards section for determining who should be included in FTE/headcounts.

Movements In: This metric is simply the sum of the measures identified in the calculation field.

Pay particular attention to the prioritization logic in case a single record ever fall into two of the metrics identified in this section.

It is not advised to alter any of the prioritization logic or notes here. Changes to this will affect subsequent metric packs such as Talent Flow.

This metric does not necessarily define the final External Hire Rate metric.

Its use here in the specification is to begin an employee's engagement with the company. Every employee must begin an engagement with the organization if they want to be counted in any other metric or analysis. The actions identified here do not necessarily have to be part of the final Hire metric; this this defined in the code mapping section.

For example, acquisition codes have to be identified here to begin the employee’s engagement the day they were acquired. However, these acquisitions codes do not have to count toward the Hire Rate metric, but rather mapped to "Other Movements In" per the code mapping section. Further, Organizational Tenure for an acquired employee does not have to begin on the acquisition date, but typically from a dedicated tenure date field elsewhere in the HRIS.

This metric is used to end an employee’s engagement. Terminations must identify any exit from the organization. They can be counted in the termination metric or not, depending on the code mapping section. Be sure to confirm on what day a termination should be counted. Most systems identify the first day an employee is no longer working. Therefore, the day prior to the effective date is the day the employee actually left the organization.

Movements are often identified by the HRIS event or action codes. In cases where utilizing the codes is enough to completely identify a movement, you simply need to identify the location and applicable codes for that movement. Additionally, you want to make sure you can identify the date when the movement occurred.

For the standard HRIS systems, the table and fields for the codes and date are well known. However each implementation can have unique usage of the action/event codes, so it is critical to correctly identify the codes per movement.

It is also important to verify that the code is the only information that is required and that other logic does not need to be applied. For example, it is sufficient to tell the difference in a promotion and transfer simply because they use different codes, or must you check to see if there is a change in pay grade as well. The requirements can vary for each project.

In this example of the Data Questionnaire (DQ), Promotions have been identified by the standard SAP action and reason codes; Action 50 Reason 1 and Action 53 Reason 7.

For SAP, the job actions are stored in the PA0000 table (also referred to as infotype 00000), with the field MASSN for the action and the MASSG for the reason. Additionally, the date of the action is stored in the BEGDA field of the same table. The specification template contains the default locations for these fields, therefore to update the template you add the appropriate codes for the customer’s data specification (DS).

Example: FTE for population analyzed by WFA and FTE Value

As described earlier, the FTE base input measure defines both the employee's FTE value as well as the employees that are analyzed by WFA.

The template will address both requirements. The template first contains a section for the FTE value. It will either be stored in the system and used directly, or it must be calculated. In the example for SAP, the FTE value is normally stored in the BSGRD of PA0008. If the customer is not populating that field, then the value must be calculated by determining the hours normally worked by the individual versus the standard working hours for the company in that location. In can additionally be beneficial to check the employee for part-time or full-time as the system may not include hourly data for FTE for a full-time employee.

The data questionnaire prompts the customer for the information required to locate or calculate the FTE. The example is a simple calculation, as the FTE value is not stored. The company is utilizing a 40 hour work week for all employees and storing the standard hours in WOSTD of the PA0007 table. The DQ also identifies the part-time employees.

To configure the DS in this example, you would first remove the text associated with locating the FTE value, as it is not stored in the HRIS. You would then configure the calculation logic text. The standard hours for SAP are typically in one of two fields, therefore the incorrect location would be removed in this example (DIVGC). The value of the company standard hours would be updated to 40. Finally, you could include the logic to determine part-time or full-time. This will help to verify FTE calculations, or can populate the FTE of full-time employees to 1 in case the WOSTD does not have accurate values for a full-time employee.

The bottom section of the FTE metric in the specification template contains the logic for the population analyzed by WFA. For a SAP system, it is common to use status codes to identify the included employees. This code is typically stored in STAT1 OR STAT2 of the job action table (PA0000).

In the DQ, the customer can identify how they determine the target population. Typically you should discuss how the customer's method aligns with the SAP SuccessFactors data standard for FTE. In this example, the customer is utilizing status codes in STAT2, with values of 1 and 3 to be included.

The DS can then be updated to include the appropriate status and fields. Some configurations have more complex requirements to determine headcounts beyond just status codes. It is important to document the process of determining the population accurately.

The final output of updates to the template should be as clear as possible. Any text that appears in the template that is not accurate or applicable to the customer needs to be removed from the customer's DS. Formatting the layout so that it is readable is also helpful, as this document will be viewed by the customer, as well as the functional and technical consultants on the project. As changes are made, you should use colored fonts to identify changes for that version. As you continue to update the document in later stages of the project, color coding just the changes helps to quickly identify the areas that might need to be reviewed.

Through the filtering of base input measure by dimension categories, a rich set of derived input measures can be calculated.

Any client-requested, custom derived measure (pre-filtered base measure) should be documented in this section. The list of all the derived input measures and result measures is in the metric pack documentation.

Base Input Measures and Derived Input Measures are combined in formulas to calculate result measures. Through the specification of formulas combining both base and derived input measures a rich set of result measures can be calculated.

Capture any custom result measure and its formula in this section

The next 3 sections will provide mapping on dimensions. The first section of dimensions is Structural Dimensions, also called Hierarchical Dimensions.

Structural dimensions provide for the breakdown of measure values across administrative and geographic structures.

For the specification you need to configure 3 columns:

• Hierarchy Type: should contain both the original name and the alias name if the customer desires to use an alias.

• Structure Type: specify the structure type; Point in time, Span of time, historical period

• Source: sourcing and the logic. You must capture the table(s) required to determine the effective dates and parent/child relationships of the nodes and how to determine what node an employee is in.

Point in Time: The most recommended one is the Point in Time, which means the structure is based on the very latest information. Every time you get a refresh of data from a customer, the structure should be generated based on what is the most current structure at that point.

The resulting structure will be the most current 'state of the organization' as at the end of period.

• The further the period of time is away from the most current period: the more people will fall in the unallocated category.

• This structure is not suitable for trending purposes.

Span of Time: This includes all the nodes that have been active through a period of time, for example the last four years. If a node was active in a structure any point in that time, it will appear in the structure. If it is inactive in the latest period, it will flag it as inactive but it will still appear in the hierarchy. It will appear under the parent it had at the time. Span of time is a very comprehensive structure but it can be difficult for users to interpret

• The number of employees falling into the 'Unallocated' category would be significantly reduced or totally eliminated.

• This structure is more suitable for trending, especially at the higher levels in the tree.

Organizational units that are not active will still appear in the structure. This may be confusing for some users.

Historical Structure: The Historical Structure is a previous point in time to determine which organizational units to include. They are useful when an organization has gone through a major re-organization and the structure has changed considerably from one period of time to another.

Data from a previous period of time can be viewed in relation to the reporting relationships applicable at that time.

• Historical structures are only applicable to view data for specific periods of time.

• Historical structures are not suitable for trending purposes.

Any employee records that do not find a link in the structure are included in the Unallocated category for the period of time that the record represents.

For example, consider a structural dimension build from a hierarchy of organizational units for the customer. There are different reasons why an employee will fall in the Unallocated category depending on the method used to generate the structure. Examples of common reasons include:

• The employee’s organizational unit is not active (the last effective date is prior to the last date of the period covered by the data)

• The employee’s organizational unit has not been linked to an active parent in the structure

• The employee’s organizational unit is not found in the customers source table(s)

• There is no organizational unit identified for the employee

Example dataset of 6 employees across two months:

An organization's structural hierarchies are the central point of most WFA analysis.

The most commonly requested structures are Organizational Unit (departmental structure, functional areas) and Location (physical location of employees). Cost center/Finance (cost-based allocations within the organization) structure is also somewhat common.

SAP SuccessFactors does not recommend Supervisor reporting structure (each employee links to a supervisor employee), as it tends to change often which can make it difficult to maintain and interpret historically. Additionally, it can be difficult to verify the data is accurate historically from the customer system.

By default, a WFA contract allows for two structures.

It is also important to remember that only the structures identified here can be used in Tree Security. Analysis dimensions cannot be used for tree security.

Each organization can have different requirements for the way to view the breakdown of the data. The structural dimensions are unique to each client. Often, where the data is stored for the dimension is the standard for a HRIS, but the nodes of the hierarchy for every customer’s dimension will be different.

To fill the Hierarchy Options tab of the specifications template, you need to identify two pieces of information for each dimension:

• The employee assignment to a node of the hierarchy

• How the hierarchy is built (how nodes are related to each other)

You can see the data questionnaire (DQ) requests both pieces of information from the customer. In this example, the customer is using the Organizational Units of SAP as one of their structural dimensions.

When updating the template, you need to update both types of information. In this example, the customer is using the standard OU structure, therefore the node the employee is assigned to is located in the ORGEH field of the PA0001 table. The OU label is located in the MC_STEXT of the HRP1000 table. Both are standard locations in SAP for this data, but it should be verified with the customer since it was not directly specified in the DQ.

The relationship between OU nodes is defined in the HRP1001 table (Object Relationships). The OTYPE (object type) of O identifies it as an organization unit. The RELAT of 002 refers to the relationships between OUs. Finally, the RSIGN of B is the record that identifies the child OU. With this information, the technical consultant can build the OU structure from the HRP1001 table extract.

The template has 3 or more structural dimensions by default (OU, locations, reports to). Remove any sections that are not applicable to the customer.

The analysis options and code mappings tabs work together.

For the analysis options, the functional consultant will need to configure any alias for the dimensions and how to appropriately source the data. The dimension category and analysis type do not need to be adjusted.

The first column identifies the name(s). It is possible to have a single source of data for more than one analysis option. For example, the date of birth is used to generate an age dimension and a generation dimension.

The dimension category is similar to the measure category. It identifies where it will appear on the site menus, for example the personal details or job details. The analysis type does not really appear anywhere, it helps the technical consultant understand what the data relates to. There are some analysis options that do not apply to all measures. For example, the termination reasons. The termination reasons only apply to the movement-out measure the same way that recruitment sources analysis would only apply to the movement-in measure. When you start building other metric packs, you would find some of the analyses are very specific to certain measures.

The last column is sourcing any logic that applies. If the analysis is not applicable for the customer, for example, where disabilities are not captured, you would indicate that it is not applicable and gray it out in the specification document.

Complimentary to the analysis options is the code mappings tab. This section specifies how analysis options will be displayed on the site. It is also important where mapping needs to be created. For example, mapping the ethnic group to the minority/non-minority category.

There should be a code mapping for every analysis option on the previous worksheet. Configure each code mapping section that is applicable to the client.

First, include alias names identified for the analysis options, which should match the analysis options tab, then configure the code mappings:

Simple options, such as gender, you can just include the code that is returned from the data source and then it would include any mappings. The mappings are what the client wants to see displayed on the site.

Some analysis options have more than one level. If there’s more than one level, you have to identify each one of the mappings for every one of the levels. For example, the age dimension will actually apply three levels of mapping. The first level shows us the ten-year intervals, so we have people in the 20, 20-29, 30-39, etc. If you expand any of those ten-year spans, you’ll see there are five-year interval groupings. Finally, if you go down one more level you will see the actual age in years. If a customer doesn’t want to display one of these levels, then the default mapping can be adjusted.

Additionally, you need to consider benchmarking, because the benchmark categories are standard. If the customer wants to have different categories than those used in benchmarking, you can provide two different analysis dimensions; one that is compliant with the benchmarking, and one that does not comply.

The specification document use the (β) symbol to identify where deviation from the standard mappings will not be in line with benchmarks and will result in the loss of derived measures.

Separation Reason is a good example because the first two levels must conform to the benchmark standard, otherwise your Voluntary Termination Rate metric may not be published if it cannot find this mapping on level 1.

Level 3 and 4 are open to custom groupings and descriptions.

Be careful to clearly articulate in the Analysis Options tab whether or not the code and/or descriptions from the data system should be displayed.

Job related analysis options are a good example here. Let’s say a client has 100 job codes that group into 10 different job functions. If level 1 displays the 10 job functions, should level 2 display the job codes? Or should it display the job title? Or should it display both?

All of the above options are possible, but make sure to explicitly identify the design in the analysis options tab and whether or not to follow the code mappings exactly, or as a reference to the dynamic sourcing from the data itself.

Hard coded (also called manually maintained) descriptions follow the descriptions as they appear on the code mappings section. These are typical for the benchmarked analysis dimensions. In this case the way the label is displayed is configured based upon the specification document. You should leave ‘refer to code mappings…’ in your analysis options tab and remove any reference to a label or description. Then completely configure the appropriate table on the code mappings tab.

Dynamic sourcing of descriptions allows you to use descriptions as they are stored in the customer HRIS system. As labels change in the HRIS, they dynamically change in WFA. This is not appropriate for benchmarked data. To configure, make sure the description source is accurate in the analysis options tab. Then remove the reference to ‘refer to code mapping…’ and reference the dynamic nature of the description on the code mapping tab.

The Minority and Ethnic background dimension is a good example for analysis options and code mappings example, even though it is only applicable to US implementations, because a single source populates both dimensions. It is also interesting because the minority dimension is benchmarked while ethnic background is not.

The data questionnaire (DQ) requests the location for the stored ethnicity of the employee. The DQ appendix also has a location for the code mappings, but in the example above the customer included the mappings with the answer. In this case, the data is stored in the RACKY field of the PA0077 table, standard for SAP.

First, we need to configure the analysis options tab. Analysis options captures the location of the data in the HRIS, as well as the descriptions if necessary. In the template for ethnic background, they include options for both dynamic sourcing and manually maintained labels. You do NOT add code descriptions to the analysis options tab. You can see the ‘sourced’ line already has the correct location for the data.

If the customer determines they want the descriptions to be dynamically sourced from the HRIS for the ethnic background, then add ‘descriptions’ line in the template, and remove the ‘refer’ line from the specification.

If the customer maps the code values to ethnic background labels manually, then you would remove the ‘descriptions’ line while leaving the ‘refer’ line in the specification. You will then update the code mappings tab at a later time with the static labels.

Minority must use static labels, as it is a benchmarked dimension.

On the code mapping tab, you will configure the code mapping for the dimension. In the case of ethnic background and minority, the two dimensions share a single table. The first column will contain the codes identified in the appendix. The second column will contain the ethnic background descriptions, and the third column will contain the minority description. You can see the minority is a benchmarked dimension because it contains the (β) symbol.

For the Ethnic Background, if the customer utilizes dynamic sourcing, then the descriptions are removed and comment below the table will indicate the data is dynamic.

If the customer wants manually maintained descriptions, then configure the table with the codes contained in the DQ and the agreed upon descriptions with the customer. Static mappings allow for:

• Multiple codes to map to the same description

• Descriptions that are more report viewer friendly if the HRIS has descriptions that require HR knowledge

• Multiple levels in the dimension

Since ethnic background is not benchmarked, the customer can configure the code to label mapping as they prefer. In this example, the codes are similar to the descriptions clearly defined.

For the minority, the dimension must use static mappings because the dimension is benchmarked. Therefore, you must align each code with the appropriate mapping/label for the dimension. You would use the list of values available in the code mapping table in the template or view the metric pack documentation for the appropriate values. In this example, each code will be mapped to minority, non-minority, not provided, or not reported.

The final view of the table will be dependent on the selection for the display of the ethnic background, but both dimension can be defined in the same code mapping table.

Drill to Detail enables power users to quickly isolate individual pieces of data and to verify which employee data records are included within a particular measure. It is also a valuable tool for project teams who routinely conduct verification tasks via the portal or who are required to handle requests from casual portal users for transactional information.

The Drill to Detail functionality (if applicable to a measure) is represented in documentation using the following symbol ▼.

To configure drill to detail in the specification:

1. Make sure any custom measures needed to support drill to detail have been added to the appropriate tab.

2. Verify if names should be included, and, if so, how to source the names.

3. Update and/or remove any other data elements or dimensions that the customer would like displayed for drill to detail.

   This might include changing the level of a dimensions the client wants displayed.

4. Add any additional standard or custom elements to appear in the appropriate section of the drill to detail tab.

Every metric pack will have the measures and dimensions that are standard in that particular metric pack. The example has a map of Core Workforce.

• Additional Excel Data Source.
• Payroll System Data.
• Learning Data.

• Custom Headcount Measures.
• Vacancy Data.

• Days to Fill Position (Recruitment).

• Contractor Headcount.

• Historical Structures.
• Any more than 2 Structures.

• Security Clearance Level.
• 401K Plan.
• Second Pay Grade Structure.

One type of customization is when you need to get data from an additional system.

Another type of customization is the data that still comes from a standard system, but the customer might want additional headcount measures, for example, the headcount of contractors. Contractors are not normally kept in a headcount and in FTE, but many organizations have a large number of contractors and they want to know how many they have and where they are in the organization. This data would require a specific headcount measure that just includes contractors. While the data is from the same place, it is an additional measure.

Hierarchies are considered custom if it’s not part of the statement of work (2 by default) or historical structures.

Any analysis that is not listed in the metric pack documentation are customizations. For example, people that may have a 401k plan or a certain security clearance level. Customization of the analysis options is common, as customers often have certain values that are specific to them that they want to use for reporting.

The Specification Document has to be very explicit about which tables and columns need to be extracted:

• Any tables or columns that deviate from the standard as listed in the specification template need to be identified and described so as to enable the development of the extract scripts

• The Extract Tables section should include the full list of tables that will be expected to be delivered from the client. Tables or files outside of the standard list need to be highlighted as custom.

• The Table Descriptions section should reflect custom columns identified in standard tables and include the list of columns for any custom tables or files identified.

The specification document provides a standard list of tables extracted for a data source.

The standard list of tables should be updated to include customer specific configuration. Custom tables that are part of the extraction should be added to the table and background shaded.

Tables normally included but not needed for the customer’s extraction should be shaded with a gray background and not deleted.

The choices made and agreed upon during the creation and sign-off of the specification document ultimately drive the custom design of the WFA portal.