Introducing WFA Implementation Methodology

Project Sponsors: Both SAP and Customers to champion, make critical decisions, and deal with escalations.

Project Management: Both SAP and Customers for their control of activity, resourcing, and risk and issue management.

Functional Consultants on SAP side, and Process Owners/SMEs, Business Stakeholders, Trainers and Technical Resources on Customer side, liaise on configuration design, configuration validation, training design and delivery, architecture, connectivity and migration.

The SAP Activate Methodology for Cloud provides an implementation framework to support subscription-based software where the system installation and management occur outside of the project (SaaS).

SAP Activate Methodology for Cloud is less intensive than a traditional project methodology making it ideal for smaller project teams. You can see a high-level overview of roles of the Activate methodology in the diagram.

For WFA projects customer resources can be loosely defined as Technical Roles, Strategic Roles and Functional Roles.

  The Executive Sponsor (ES) is the primary executive advocate for the human capital measurement capability at the organization. The Executive Sponsor may not be involved in the day-to-day project management over the course of the year, but their engagement and sponsorship will be critical to the successful implementation of the portal and other tools (such as reports) among the user population.  

The Project Manager (PM) is the person within the organization who is responsible for the ongoing progress of the company’s human capital measurement capabilities within the organization. This person will work closely with the SAP SuccessFactors Consultant and SAP SuccessFactors Project Manager assigned to the project to ensure both strategic and operational goals are met.

The Functional/Technical Specialist (FS) ,commonly an HR Analyst role, is the primary resource for workforce data interpretation and will need to be familiar with the Human Resource system, its data structures and business rules. The role will also include other activities such as data verification and user testing.  

The Technical IT Resource (IT) is the primary resource for data extraction and transfer activities.

For SAP or Partner resources, we generally define three roles. Each of these roles are carried out by separate individuals or teams, as the required skills of each role are quite different. The high-level responsibilities of the roles are:

• Managing Project Risks.

• Managing Internal Team.

• Ensuring Quality Gates are met.

• Support of Customer through the process.

• Data Extraction Verification.

• Creation of Data Staging Framework.

• Resolution of application issues.

• Configure data refresh.

• Specification Generation.

• Customer Data Verification/Auditing.

• Application Verification and Knowledge Transfer.

More detail is displayed over the next images.

• Identify customer team and roles.
• Project kick-off/welcome call.
• Organize demo site set up.
• Organize on-site visit.

• Attend configuration workshop.
• Receive verification reports.
• Oversee specification document workflow.
• Oversee resolution of data audit issues.

• Oversee discrepancy reporting process.
• Manage QA and set up beta site review.
• Organize and attend on-site beta site review.
• Manage completion of beta site issues log.

• Manage transition to customer support.
• Schedule implementation of subsequent metric packs.

• Attend project kick-off/welcome call.
• Provide relevant implementation documents.
• Set up demo site.

• Develop and update Specification Document.
• Facilitate Specification Document review.
• Assist with resolution of data audit issues.

• Manage discrepancy resolution process.
• Provide site navigation training.
• Set up initial customer roles.
• Assist in resolving beta site issues.

• Assist in transition to Customer Support team.
• Support implementation of subsequent metric packs.

• Attend project kick-off/welcome call.
• Set up demo site.

• Support develop of Specification Document.
• Perform data extract for SF data.
• Perform data audit.

• Set up data staging framework.
• Publish beta site.
• Deliver discrepancy reports.
• Assist in resolving beta site issues.

• Publish pre-production site.
• Publish production site.

ACTIVATE is the implementation methodology used by consultants to help customers get the most out of their SAP SuccessFactors applications, in the shortest amount of time. First they establish the framework for a successful project and then design the solution and develop a detailed project approach. Then, they proceed to configure the solution to enable each customer to achieve their strategic business objectives. Once the configuration is complete, they perform thorough testing, complete the training, and execute on the rollout strategy.

Workforce Analytics projects are planned to implement each metric pack independently, starting with Core Workforce and Mobility. The following is an overview of the implementation methodology phases, objectives and deliverables.

The approximate timeline for a traditional WFA project is 100 days.

The implementation of WFA on SAP HANA can be shorter due to a couple of reasons:

• WFA on SAP HANA uses only SAP SuccessFactors data replicated into the analytical cube. Therefore, the creation of extraction scripts and testing of those scripts is not required (Data Audit).
• Changes to the SAP HANA analytics cube can be applied iteratively by the consultant and tested individually, instead of the consultant applying all required configurations at once.
• Multiple metrics packs can be initially applied at once. However, each metrics pack must still go through individual configuration, modification, and testing.

Note that just because an implementation is utilizing WFA on SAP HANA, that does not necessarily mean it will be faster than the approximate 100 day for traditional WFA. Often, the bottleneck for completion of the project is the pace at which the customer can complete their required steps. This can be the case for either traditional or WFA on SAP HANA projects.

Project Management Summaries are created from a blank template for each new customer. During the pre-sales process a summary may have already been generated to give sample time frames.

Summaries should be updated on a regular basis, or when a milestone is achieved.

Customers are not expected to manage these summaries, and the summary is often provided as a PDF to remove edit functionality.

Each metrics pack focuses on a logical group of data items that support the generation of a related set of measures and reporting breakdowns. Each metrics pack is based on a highly structured framework that:

• Defines a standard set of core metrics which includes a high percentage of commonly selected key performance indicators (KPIs).

• Defines a standard set of core business dimensions/hierarchies to support further analysis/breakdown of measure values.

• Maps requirements to a source set of core data items.

• Includes templated extract programs and scripts for common computer systems.

• Includes common business logic which can be customized for SAP SuccessFactors Member specific business rules.

• Includes a default gallery of reporting templates.

This modular approach facilitates the sourcing of data and the calculation of measure values by significantly reducing both the time to implement and the cost of providing a comprehensive reporting solution.

Traditional WFA applies the Core Workforce and Mobility metrics pack first, then additional metrics packs can be added individually. Each additional metrics pack is its own implementation project.

WFA on SAP HANA implementation can consist of only Core Workforce and Mobility (CWM) metrics pack, or a collection of metrics packs including CWM initially loaded into the system as a single configuration. The list of supported metrics pack is available on the SAP Help Portal.

For each Metric Pack there is a defined set of source data fields which are extracted from a Customers human resource information system (HRIS) and other business systems. These data items are processed by SAP SuccessFactors Data Transformation, using predefined formulae and the Customers business logic, to generate Base Input Measures and Dimension Hierarchies. These two components form the basic building blocks of any business intelligence solution.

Base Input Measures: The building blocks that enable generation of the WFA content.

They cover basic counts like Headcount, FTE, Hires, Terminations, and Internal Movements.

Derived Input Measures Base Input Measures filtered by Dimension Hierarchies: Base Input Measures filtered by a selected dimension.

Derived Input Measures Base Input Measures filtered by Dimension Hierarchies.

Result Measures Calculated based on two or more Base/Derived Measures: Selected measures are combined in formulas to generate Result Measures (in percentages, ratios etc.) which are commonly used in analysis and reporting, as well as in benchmark comparisons.

• Used to allow breakdowns by the organizational, geographical or similar types of reporting structures.

• They support tree security. Administrators can limit access to only certain areas of the hierarchy for different users.

• Allows slicing and filtering of measures by a number of analysis criteria, for example Demographic, Job-based, Tenure etc.
• They support Dimension Restriction. Administrators can remove access to the dimension for different users. Access is granted to the entire hierarchy of that dimension.

Drill to Detail functionality is provided via the SAP SuccessFactors portal and allows users to build data queries that return the details of the individual employees meeting the criteria of the query. Using these results and the standard portal, analytical users can see how the transactional data feeds they provide to SAP SuccessFactors are transformed into the metrics presented on their WFA portal.

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.

The Core Workforce and Mobility Metric Pack supports the generation of the following dimension hierarchies:

• Time dimensions provide for the breakdown of measure values across consecutive periods of time (years, quarters and months)

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

• Other Dimensions provide a variety of categories of dimensions that apply to certain metric packs (Biographical, Employment, Payment, Tenure, Recruitment, Separation)

Organizations can customize their reporting solution according to their reporting requirements. Additional dimensions, hierarchies, time periods and special time categories are supported through customization.

SAP SuccessFactors Workforce analytics (WFA) on SAP HANA provides a framework for creating and delivering analytics, including new partner enablement and customer tools.

Historically, WFA has been implemented on Microsoft SQL Server, but the move to SAP HANA results in a number of changes to the implementation process.

• Measure Template Pages.

• Query Workspace/Investigate.

• Page Designer with WFA data, excluding Waterfall Chart component.

• Report Distributor.

• Tree Security.

• Drill to Detail.

• Export to Excel.

• Custom Calculations, Members, and Sets.

• Connector to SAP Analytics Cloud.

• SAP SuccessFactors RBP Integration.

Data can only be sourced from the following modules in SAP SuccessFactors:

• Employee Central.

• Employee Profile.

• Performance Management.

• Goals Management.

• Succession Management.

• Recruiting Management.

• Compensation Management.

• Fieldglass Contingent Workforce.

We also support data stored in MDF, including custom MDF objects.

The prepare phase is primarily handled by the project managers. Project planning is the focus of this phase, however, it is beneficial to understand the purpose of the data questionnaire. The following topics will be covered in this section:

1. Implementation Documents.

2. Welcome Call.

3. The Data Questionnaire.

4. Project Summary.

The Welcome Call typically occurs during the first two weeks of the SAP SuccessFactors subscription. The objective of the Welcome Call is to define the customer’s goals and expectations of the customers. Key timeframes, deliverables and communications plans will also be discussed.

The SAP SuccessFactors project team is happy to include any agenda items the customer would like. The following provides an outline of the standard Welcome Call agenda:

• Introductions, discussion of personal background/position/experience.

• General discussion, identifying key decision makers, key project managers, client’s hot HR topic, client’s critical success factors for the SAP SuccessFactors membership.

• Key project outcomes.

• Schedule key events, for example, periodic calls/meetings, existing reports to be supplanted.

• Overview of the Implementation Process and next steps.

At that welcome call, clients meet the people they’ll be working with and start to talk about how to conduct the project. You will start giving the client some documents that they can review in their own time and also fill in any details to be able to help you in the implementation.

1. The first document should be a Project Summary. This is an overview document of the implementation process. It describes the steps from the beginning to the production site. The project summary helps the customer to understand what that process is and the milestones. In some instances, you will run through that document with a little bit of detail during the welcome call.

2. The second document is the Data Questionnaire. The Data Questionnaire has several questions that the client must respond to.

3. The third document is the Metric Pack Document. If they don’t already have a copy, it’s really important that they do have the document at the very beginning so they understand what the standard metrics and dimensions for the metric pack are.

Following the Welcome Call the customer is requested to complete the Data Questionnaire. The purpose of the Data Questionnaire (DQ) document is to gather information to enable the development of a data specification document that will form the framework around which the customer’s site will be built. A separate questionnaire will be provided for each of the metric pack to be implemented on the site. The questions throughout the document will focus on detailed information about data sourcing and specific rules that may be applicable for various topics and data elements, as well as general information about HRIS and reporting requirements. Each data source provided will contribute towards populating different parts of the WFA portal. The information provided will be used to create a customer-specific data specification document.

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

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 template specification document, create a customer specific technical blueprint for the portal build.

If necessary, a follow up Technical Call will be scheduled to discuss the responses provided in the questionnaire and, where needed, request clarification and additional information.

The following provides an outline of the standard Technical Call agenda:

• Team Introductions.

• Overview of the Implementation process (recap if required).

• Detailed review of the Data Questionnaire.

• Next steps, key dates and timeframes.

Early in the project, it is common to configure a WFA site to aid with the visualizations for the customization of a WFA instance for the customer.

For traditional WFA (WFA on SQL server), it is customary for the project team to have a demonstration site so the customer can see examples of how decisions made during the alignment of the specification document affect the outcome of the project. Many consultants already have a demonstration instance that will suffice for the project. If a new demonstration instance is needed, then it can be requested from the SAP SuccessFactors HCM Cloud Operations Portal. The demonstration instance is NOT modified to the customer’s configuration, it only serves to visualize the outcome of certain decisions. Customizations will be applied and tested on a Beta site that is created later in the project.

WFA on SAP HANA takes a different approach. Early in the project the technical consultant can publish an alpha site. As customizations are requested, they can be applied directly to the alpha site and viewed as the changes occur. The initial alpha site can be configured quickly by applying a standard template, then customization can occur throughout the project as part of the realize phase. The alpha site can be setup by following the ‘WFA on SAP HANA Template Implementation Guide’ from the WFA on SAP HANA implementation kit.

At the end of this phase:

• The project manager should have finalized a project plan.

• The onsite Kickoff Meeting/configuration workshop should be scheduled.

• The customer has returned a completed data questionnaire.

The tools and processes used in the discovery phase uses the Data Questionnaire to developing the Specification Document, reviewing the Specification with the client, and getting Specification sign-off.

When you first start the Data Discovery process you want to use the Data Questionnaire as a guide to begin asking the customer some targeted questions to reveal how their data is currently structured.

Then you move to the Specification Document. You take the customer’s answers and create a document called the Specification Document.

That specification document becomes the blueprint for how the customer’s portal is going to look, and holds all the information about all the measures to be included.

The last step in the Data Discovery process is to review and get sign-off from the customer on the format and structure of the Specification Document.

Based on the responses received in the Data Questionnaire, you will create a document called the Specification Document. This specification document becomes the blueprint for the customer implementation containing all of the business logic and source extract data locations. As a partner, you will need to be prepared to walk a customer through what is included and not included in the specification/metric pack, compared to initial requirements. It’s a living document, it will have different versions over the course of the project. The first version you create is based on that questionnaire. It is important to make it as accurate and complete as possible because it is also the document that the technical consultant team will use to develop the staging, the framework, and the publication of the site.

After the initial specification document is created, the questionnaire is no longer needed.

It is important that the customer understands and reviews the specification document carefully. Identification of Customization outside of the Metric Pack offering is critical during specification design. Once signed-off, changes to the specification will result in project delays and additional development days.

The review of the initial Specification document is handled as part of the Kickoff Meeting.

Many partners will create their own custom Kickoff Agenda.

Framework: The specification document matches the metric pack, it controls the configuration of the solution. It contains all the sourcing and the data extracts and any business logic that is specific to customers. It also maintains data standard for the customer base and this is important for benchmarking.

The specification documents are usually in Excel, and they have several worksheets or tabs, and each tab has a different type of information.

Now that the data has been identified, you will develop a plan for extracting the data from the customer’s existing systems for transferring the data to the SAP Technical team (if required), and the initial steps to take for verification of the data.

The tools and processes used in the data extraction phase:

1. Data delivery methods

2. Extraction scripts/processes

3. Expected Results Reports

4. Data audit management and resolution

5. Managing changes in the specification

SAP SuccessFactors supports the following data Transfer Methods: SFTP, FTPS, FTP + Encryption. Once a client is in a Production status, data delivered via one of these methods to a specific SAP SuccessFactors site is automatically downloaded and put through predetermined verification processes and queued up for processing.

Alternatively, SAP SuccessFactors can also download data from the client’s websites. This method is not recommended because it does not take advantage of the automated data retrieval processes which are in place for the other listed methods and can result in delays in processing the regular refreshes.

The data delivered to SAP SuccessFactors should be encrypted. Our recommendation is to use PGP with a public encryption key provided by SAP SuccessFactors.

Discussions should be held early in the project to identify the most appropriate Data Delivery and Encryption method for each client.

SAP SuccessFactors tries to make the process of extracting data as simple as possible for extracting data from external data sources. SAP SuccessFactors has a limited library of extract scripts for some of the more common data sources to help produce a simple text file for each table. Each record in the table corresponds to a row in the file, and the columns are separated by Tabs, for example, Tab delimited. The current scripts provide a simple mechanism for extracting the data for the required database table columns to an ASCII file.

SAP SuccessFactors can provide several different scripting templates for major HRIS systems to aid in the data extraction process. For custom or smaller HRIS systems, we can provide generic table column listings to help customers generate their own scripts. In some cases, these standard scripts will require modification to satisfy specific system requirements. In these instances, the customer’s team is requested to modify the script to suit the need.

• The SAP SuccessFactors standard is to develop one script per table extracted.

• Some clients prefer to develop one single script that targets more than one table but in general we find that it is easier to maintain separate scripts going forward.

• The SAP SuccessFactors standard is to generate one separate file for each table extracted.

• Some clients prefer to generate one single output file with all the extract tables. In this case the extracts need to include the name of the table as the first column in the extract and include leading and trailing header records. This has to be clearly documented in the specification document.

The SAP SuccessFactors standard is to receive TAB, Pipe (|) or comma separated text (.TXT or .CSV) files.

To give a customer confidence in the published figures on the portal, every implementation requires a set of customer expected results reports. These reports are used at a later stage of the project, after the framework has been built.

The expected results report request during implementation relates to the following verification items:

• End of Period Headcount

• Hires

• Terminations

• Internal Movements (Recommended)

  • Transfers

  • Promotions

  • Demotions

• Analysis Options (used for verification support)

It is important that expected results reports are run the same day that the extract scripts are executed.

For adequate sampling, SAP SuccessFactors will compare three separate quarters of data.

A document to aid the customer in completing verification reports is available on PartnerEdge.

Once the following requirements are met, the project can be handed over to the Technical Consultant team:

• The Specification document has been accepted and signed-off.

• The Extract Scripts have been developed and tested (if required).

• The initial data extracts (if required) and the expected results reports are created.

At this point all the documentation that is relevant to the project should be made available to the technical team by an agreed upon mechanism. Management of documentation should include:

• The Completed Questionnaire and any additional supporting documentation for example lists of codes and descriptions, table descriptions.

• The signed-off Specification version and all the prior versions

• Any sample data that may be useful

The technical team will then proceed to start the next phase of the project

Common data audit findings could be:

• Incomplete data extracts, missing fields or tables.
• Inconsistent extract formatting.
• Unallocated or NULL data, incorrect field references.
• Poor data quality, text in place of numbers, out of range values, incorrect date formatting.
• Incomplete business logic, lack of data linkages.

The Data Audit is completed by the SAP technical team for external data sources. The data is audited against the specification document to ensure that the necessary tables, fields, and business logic have been captured and the data received is as expected and contains the values identified. A ‘Data Audit Issues Log’ is created and provided to the functional team for review with a request to provide responses to the issues raised.

Partners need to work with the customer to answer questions logged during audit before the technical build can commence.

It is common that as a result of the Data Audit issues reported, the specification document may need to be updated. The responsibility for these updates should be agreed upon between the Implementation Functional Lead and the SAP technical lead.

Once all the Issues identified have been addressed and any changes to the specification completed, the technical team is ready to start the development of the Staging Framework and the processing of the data.

The staging framework is based on a standard SAP SuccessFactors model where the appropriate tools and steps of this framework will be tailored to capture and interpret the specific logic applicable to the customer as defined in the Data Specification Document.

Now that you have the required data you will need to manage the steps taken from the time the data is accepted for processing until the client achieves a Production status. The tools and processes used in the Realize and Deploy phases:

1. Data staging and discrepancy reporting.

2. Managing resolution of discrepancies.

3. Achieving verification sign-off prior to publication.

4. Assisting with beta site issues resolution.

5. Achieving production status.

Data staging for traditional WFA builds can take up to three weeks.

During this time the technical consultant team will create the staging framework, process the data received and create the Verification Discrepancy Reports and the Structural Hierarchies Pivot Tables.

A verification process is followed to ensure WFA is interpreting the data in the same manner as the customer interprets the same data. Before SAP SuccessFactors can publish a beta site, the customer must be comfortable with the data that will be displayed. The outcome of the discrepancy verification process will be the customer acceptance to publish a site.

Once the data has been staged and processed, the technical team will generate reports and compare the results with the verification reports received from the client. Discrepancies found between these reports will be recorded and reported in a series of Discrepancy Reports that will contain details of the apparent reasons for the discrepancies found. As an example, the technical team can identify the employees that the customer shows as part of headcount but WFA does not, and the employees that WFA identifies in headcount but the customer does not.

The technical implementation lead will deliver these discrepancy reports. The client with the support of the functional lead will be requested to investigate the issues raised and provide feedback.

Discrepancy reports identify differences in the customer generated expected results reports and the SAP SuccessFactors data after the customer extract has been loaded into the WFA framework.

A discrepancy report typically has several sections.

The first one is a summary. It shows how many discrepancies you have, how many people you are counting that the client is not counting or vice versa. It is a very detailed checklist. Ask for the expected results reports from the customer to include the employee identifier, so the discrepancy report can identify individual employees.

For example, they may identify 96 extra employees in SAP SuccessFactors employee data and provide a breakdown of the reason why those discrepancies exist. In this example, 94 employees do not have termination records and they’re still in an active status. Anyone that is in an active status at the end of that period will is counted. If WFA does not find a termination for an employee, they are included in WFA counts, but the identified 94 employees are not included in the customer’s counts. The other two discrepancies are for rehires without terminations.

Along the bottom, there are employees in the customer’s report that are not in WFA report.

Continuing the example, 12 have been identified. Four have termination records and there had not been any rehire since, so the employee should not be counted. The last 7 could not be associated with a record in the job table. For WFA, those individuals are not considered employees.

For each one of the sections, there will be one worksheet where it will give the details for each one of the types of discrepancies. For an example of the detailed worksheet, you can review the type of discrepancies. For each one of those people there is a comment. By having the employee id and a level of detail, it simplifies the process for the customer to go in and investigate each one of these people to determine the issue.

In some cases customers need to recreate expected results reports to facilitate the verification process. One of the reasons commonly found is a timing issue between expected results report creation and data extract. Another common issue is when someone terminates on the last day of the month, as WFA doesn’t include that person in counts whereas a customer might count them. The verification process helps to understand whether you have the correct logic and the correct data or whether you need to adjust something in the extraction, logic, or customer reporting. Needing to change something is common.

The same process is carried out for all the expected results reports we have received.

Additionally, an Organizational Structure Verification report is provided to represent the organizational structure from the logic in the specification. When the technical team process the data, it will generate a tree showing what the reporting structure would look like and provide a pivot table type format showing all the levels. Potentially it could number the head count at the end of a particular period against that structure.

The end of the discrepancy verification process should mean the customer must be comfortable with the data that will be displayed in the WFA environment.

The functional lead will assist the client in the resolution of the discrepancies by acting as a communication channel between the client and the technical team. They also contribute to the discussions based on the knowledge gained during the specification process.

In some cases, the resolution of discrepancies will require changes in logic in the specification document, changes to extract programs and/or a new data delivery for one or more tables affected, as well as a revised set of expected results reports from the client. This is unpredictable and needs to be addressed on a case-by-case basis.

Updates to the specification document as a result of the resolution of discrepancies should be agreed between the functional lead and the technical lead. The Specification document at the end of the verification process needs to reflect accurately any logic changes and changes in data extracts.

The client will be responsible for any changes to data extracts. A copy of the final data extracts implemented should be provided to the technical team for their records.

Once all the discrepancies have been resolved or explained satisfactorily, the client will give an approval to move to the publication of the beta site. The functional lead or the Project Manager will notify the technical team that publication has been approved at which point the technical team will schedule the publication of the Beta Site. The project manager or functional lead should at this point schedule a session with the client to provide navigation training as well as a session to review the Beta Site in detail.

It is recommended the project manager and/or functional lead review the beta site prior to the client has been told that the site is available. They should review the site to see if there are any glaring issues that could be resolved before the client sees it for the first time.

Once the beta site has been published, the client needs to have a site navigation training and review this site in detail. Following that, there is a joint effort between the functional lead and the client to review the site as part of User Acceptance Testing process.

User acceptance testing is conducted to ensure that the site performs the activities agreed between the partner and the customer. During this process the customer must record any issues to a Beta Site Issue Log. It is common to perform testing for a week or more.

Once the initial testing is complete, the project manager and the functional lead should review this issues log and attempt to respond to issues that are not technical in nature. Some issues reported by clients still unfamiliar with the site may just be the result of misunderstandings.

The Beta Site Issues Log should be sent to the technical team so they can provide feedback on issues that may relate to data or site configuration. Any issues that require changes to logic or site configuration should be scheduled to be resolved. If the issues are of a nature that are preventing the client from continuing with the verification process, the technical team will determine if a republication of the Beta Site is recommended. The resolution of the issues may involve an iterative process.

Once all the issues in the Log have been resolved, or responded to in a satisfactory way, then your aim will be to get the sign-off from the client to move to the Deploy phase.

For traditional WFA clients, once written sign-off is received from the customer beta acceptance and completion of verification activities, the technical team will schedule the publication of the data in the beta site to the Production site. A customer may decide to provide a more updated data extract before the first Production site publication. In this case, the new data extract will be processed and published to the beta site and the customer will be requested for approval before the beta site data is moved to the Production site.

For traditional WFA clients, upon the release, the client will have two sites, a pre-production site and a production site. The reason that you will have these two sites is to support the regular refresh cycle, for example a refresh on a monthly basis. When the SAP technical team processes the data they will only publish to the pre-production site. The production site remains as it is, so as not to affect the current function.

Upon the publish to pre-production site, the SAP technical team will communicate to the client that the data is updated and the client can review it and give them the authority to move it to production. Once the update is signed off, the team will replicate what’s on the pre-production site into production.

For WFA on SAP HANA clients, once written sign-off is received from the customer alpha/beta acceptance and completion of verification activities, the technical consultant can copy the configuration and build the initial data cube on the production instance.

Data updates for customers on WFA on SAP HANA are automated updates and do not follow the same refresh cycle. Typically, the data is refreshed daily. The data is replicated directly from the SAP SuccessFactors transactional data, therefore there is not an approval process of the periodic loading of data that is required for WFA on SQL server. Also for WFA on SAP HANA, while a new analytics cube is being updated, the WFA site will continue to function with the previous data. If the cube update/build fails, the WFA site is still accessible to WFA users with the last successful cube build.

After the Realize Phase is complete, the project team needs to discuss with the customer to consider:

• Configure RBP as required to allow users to access the WFA metrics and dimensions.

• Enable Investigate: review Workforce Analytics Investigate (Administration Guide) on the SAP help portal.

The last steps include:

• Update data in Production for traditional WFA clients.

• Provide knowledge transfer for administrators/train the trainers/power users.

• Manage Transition to Customer Support

• Schedule Implementation of Subsequent Metric Packs

• Final sign-off

The project team should spend one to two days onsite with key users from the customer to conduct training on administration and usage of WFA. Knowledge transfer to key users is critical to the success of a WFA project.

During the final stage of a traditional WFA implementation, the technical team will configure the customer’s existing SAP SuccessFactors (BizX) environment to connect to the tested beta site for go live. This configuration is completed in provisioning by configuring Single Sign On (SSO) between the environments. If you need to perform this configuration, for example connecting a demonstration SAP SuccessFactors environment to an existing WFA environment, you should follow the instructions provided in the document SAP SuccessFactors HCM Suite to Analytics Single Sign-On available on the SAP Help Portal. SAP SuccessFactors provides the common configuration for the data center with the WFA URL set.

The WFA refresh is a task to update the WFA instance with the new information supplied by extract file uploaded to the SAP SuccessFactors WFA SFTP.

Traditional WFA is based on extracted files that are provided by the customer from a different HRIS system OR extracted from the customer's SAP SuccessFactors environment by an internal script. The SAP SuccessFactors internal Professional Services Team (PS) imports the WFA data once the files are provided or received on the WFA SFTP site.

Terms used in the flowchart:

• ADR: Automated Data Retrieval

• PS: Professional Services Team. This is the team that process the WFA monthly refresh.

• Variance Report. Report produced by PS to highlight variances in key input measures across multiple time periods, for example, end of period headcount, terminations, hires. This report can indicate potential data issues for the refresh.

• Missing Codes Report. Customers typically update dimension values, for example Job Type, Recruitment Source. These new values may begin to appear in the employee data, however the dimension hierarchy may not have been updated by the customer. This report highlights these 'unallocated' codes to allow the customer to update their HRIS in preparation for the next refresh.

• Preview (now referred to as Pre-Production). Staging instance for data validation by customer.

The WFA Pre-production (preview) site is where customers of WFA on MS SQL Server preview the next monthly cube after the monthly refresh has been completed. Typically, only a handful of expert users access WFA preview site once a month to perform this task.

To login to the pre-production site:

1. Log into SAP SuccessFactors HCM.
2. Once authenticated, open another tab in the browser
3. In the new tab, navigate to the pre-production site. Since the browser has already authenticated their session, they will not be presented with a login screen.

The user will need to use the WFA pre-production link.

WFA pre-production site users must have the permission pre-production Environment Access for Workforce Analytics on SQL to access the environment.

WFA customers with integrated WFA permissions will need to provide pre-production access in SAP SuccessFactors RBP to appropriate users.

WFA customers with non-integrated WFA permissions (legacy permissions) will need to provide pre-production Access in WFA permissions to appropriate users.

The navigation from SAP SuccessFactors HCM suite to the WFA pre-production site can be seamless for your users by adding either a custom navigation link or a custom homepage tile. This allows users to easily navigate to the WFA preview site after they have logged into the SAP SuccessFactors HCM suite. Use SAP Help Documentation to see how to create a custom navigation link. Use your role-based permissions to ensure only users of the WFA preview site see this custom navigation link.