Being on the cloud gives many advantages to companies running SuccessFactors. Faster implementation is one such advantage. However, in their haste to finish implementing SuccessFactors quickly, companies often overlook some essential considerations. Each one of these factors has the potential to derail the implementation cycle and can endanger the fate of whole project. In this article, I look at nine important factors that are commonly ignored in SuccessFactors Employee Central implementations. Many companies wrongly assume that these can be figured out further down in the planning process, only realizing later, when it’s too late, their true importance. Not considering these important tasks, and their outcomes early in the implementation process not only leads to an increased implementation cycle, it also causes friction within the company.

Factor #1: The System Landscape for SuccessFactors

In IT project terminology, the system landscape refers to the strategy for moving the configuration across various phases of the project (for example, development, testing, and production). The greater the number of instances you have in your landscape, the greater the level of effort for:

• Keeping the instances synchronized with production
• Moving the configuration from one instance to another (this is discussed in more detail in Factor #7)

The system landscape strategy helps to streamline efforts for maintaining multiple instances and the movement of configuration across a defined path.

Recommendations

The instance numbers should be kept to a minimum to avoid extra efforts and hassles for moving configuration across instances. Based on my experience, I suggest that there be a maximum of three instances: development, quality, and production (Figure 1). In the case of roll-outs, however, a total of four instances may be used for effective movement of configuration (Figure 2). The solid blue line shows the movement of configuration from development to quality and the dotted-line shows it final movement to the production instance. Managers oftentimes don’t realize what a big job it is to manage these configuration movements while executing the project. At least 50 percent of a resource’s time should be allocated to managing configuration movement during project execution. After going live, this resource’s time may be reduced as the primary task will be overseeing the activities undertaken for configuration movement. In large-scale projects, there is often a dedicated resource for this, called an environment or configuration manager. This kind of dedicated resource, however, is uncommon in small- or mid-sized projects. If one is being used, the configuration manager should be identified during the planning stage so that he or she can start working on a system landscape strategy right from the beginning. The system landscape strategy should also:

• Determine access management within SuccessFactors and Provisioning (back-end) systems. The system landscape strategy should spell out who specifically—which departments and team members—have access to the SuccessFactors system and Provisioning functionalities.
• If needed, include a schedule for copying an instance to another (along with data and configuration). This process is called cloning and can only be accomplished with the help of SuccessFactors support. Cloning is sometimes chargeable and is only needed only when you want to copy configuration along with the data from one instance to another.

Factor #2: Configuration Workbooks

In SAP ERP HCM on-premise terminology, the blueprints for implementations are called simply Business Blueprints. In SuccessFactors, these are called configuration workbooks and they serve the same function. They provide guidelines for most of functionality existing within SuccessFactors (e.g., Employee Central, Recruitment, and so on). Since each project is different in content, the implementation strategies, teams, and the way they are handled are also unique. As a result, the standard configuration workbooks should be modified for each implementation to serve the specific needs of each project. For most of the SuccessFactors projects, configuration workbooks serve as the single source of truth for all downstream processes (for example, conversion, integration, and reporting). Therefore, it is very important to spend time early in the project creating them so that later they prove beneficial and meaningful.

Recommendations

1. Microsoft SharePoint, SAP Jam, or a similar web-based team-collaboration tool should be used to store workbooks. Not only do these kinds of tools provide a single access point; they also are an effective way to maintain versioning. 2. Each prototype (in SuccessFactors terminology the various iterative phases) in the project should have its own workbook. This means that, at the end of every phase, the last version of the configuration workbook should be frozen and made not editable. This ensures that there is no scope creep and gives the project team a clear view of the scope of work that needs to be done in the phase. In addition, each new version of a workbook (for each additional phase) should be created from a copy of the latest version workbook. Finally, each current workbook should be made available to all business and project teams for recording and updating requirements. For each requirement, the workbook should:

• Clearly note on what date or at what phase the requirement was added or modified so that these can be discussed with the company and also communicated to downstream processes, such as conversion and integration.
• Clearly note whether the requirement is being added, deleted, or modified. (This helps the project team update configuration, conversion, and integration scripts for modified requirements. A new column might need to be added to the workbook for this information.)
• Be associated with a requirements traceability matrix. A traceability matrix is a common deliverable used across SAP/SuccessFactors projects for recording client requirements. When recording requirements, each requirement is commonly assigned a specific number (a requirement ID), so that it can be traced during design, build, and test. An appropriate requirement ID should be stamped against each line item in workbook. This also may require a new column to be added to the workbook to serve this purpose.
• Provide a business description and its purpose. (This helps integration and data migration teams to work together more effectively. This also may require a new column to be added to the workbook to serve this purpose.)

3. Segregate requirements according to processes. For big projects, oftentimes separate teams work on different processes within the same module (or functionality). For example, Team A is working on the transfer process in Employee Central and Team B is working on global mobility processes within Employee Central. Since workbooks are commonly module-based (in this example, Employee Central), you should segregate requirements by their processes. This helps teams to focus on process-specific requirements whenever there is a need.

Factor #3: Picklists

Picklists are one of the most important (and sensitive) topics for any SuccessFactors implementation. A picklist is a list of drop-down values attached to any field across the suite (e.g., Employee Central, Recruitment, Performance Management, and so on). Some examples of picklist values include marital status and employee type. Picklists are also used for downstream processes such as data loading and interfaces. Unfortunately, picklists don’t support effective dating and auditing. This means that when you add a new entry or change an existing entry in a picklist, a new record is not created that shows the old and new values. In addition, the picklist doesn’t record or show the name of the user who made the additions or changes. This can create lot of confusion between the various teams, and cause a lot of wasted effort on the part of team members trying to keep the picklist entries consistent and up to date.

Recommendations

1. A place and method for recording current picklist values should be available within all the configuration workbooks (e.g., employee data and foundation objects). This way, users can easily check to see if a picklist attached to a certain field (in the workbook) exists.
2. All the picklist values’ records (within the workbook) should be formatted the same way, ready to be uploaded into the system (for example, in comma separated value [CSV] format). This makes it much easier (and more accurate) for the configuration team to upload the changed values directly into system.
3. All picklist values should have unique external codes attached to them. This is mandatory in order for interfaces to work properly and it prevents users from wasting time having to rework picklists late in the project timeline. In general, I recommend that there be legacy system codes (without spaces) within an external code field for each picklist value.
4. The picklists from workbooks can’t match exactly the picklists within the system (e.g., the workbook can’t have system-generated option IDs for each picklist value entry). This is because the option IDs (the unique identifiers for each picklist value) are generated only when the picklists are uploaded into the system. However, data loading and interfaces should always refer to picklists from the workbook and not from the system in order to prevent confusion between the various teams.
5. To ensure that picklist values in the workbook are always in sync with the system’s picklist values, you may need to put in place a simple manual workflow for each team. Implementing this simple control would restrict anyone who is not authorized to do so from making changes to picklists. For example, on the Employee Central implementation team there is only one person (Mr. A) who has access to configure picklists. In this case, any changes that are to be made to the picklist would first have to be recorded in the workbook by the team member (Mr. B) who received the request. Only once it’s been recorded does Mr. B contact Mr. A and have him change the picklist configuration. Mr. A then validates, configures, and communicates the changes to all the teams using the common email ID created for data loading and interface teams.
6. Don’t forget that the SuccessFactors system does not permit completely deleting or obsoleting a picklist value. (Deleting means that the picklist value doesn’t appear in the employee’s history and is also not available for selection within new records. Obsoleting means that the picklist value appears in the employee’s history, but is not available for selection within new records. Obsoleting is the preferred option, when available.) Only the status of the respective value can be changed to deleted or obsoleted and it remains in the picklist file with this modified status.
7. In case of multi-lingual picklist values, any changes imported to picklists should be done with Unicode-character coding.

Factor #4: Employee Profile

The SuccessFactors Employee Profile is a kind of employee mini-master record that shows employees’ data to other talent management modules (e.g., Recruitment, Performance Management, and so on) that exist within the suite. During implementation, this is a very useful but often-overlooked feature. Project teams usually begin to appreciate the value of the Employee Profile once they start having problems sharing employee data among the different talent management functionalities. It is at this juncture that team members realize they should have spent more time in understanding and meeting requirements from the Employee Profile side earlier on in the implementation. Don’t make this mistake—this can easily be avoided by having a discussion with other talent functionality members to find out (and include) their requirements in the project planning. Once these requirements have been settled on, a resource can be dedicated to work on the Employee Profile side.

Recommendations

1. First, you must have a good understanding of the importance of the Employee Profile in Employee Central—it hosts some of the most essential information about employees: the user ID and user name. The user ID is the primary identification for employee/user. The user name is the login name for employee/user (also used for single-sign on).
2. Keep in mind that the user ID, once created, can’t be updated or deleted without help from SuccessFactors technical consultants.
3. All big implementations need to have a dedicated resource for Employee Profile requirements. This resource can also work on other functionalities (base on their skill set) once the Employee Profile requirements are finalized.
4. You need to fully understand and test the standard Human Resource information system (HRIS) sync functionality to avoid any unpleasant surprises at later stages of the project—ideally, during the initial design phase. HRIS synchronization is the exchange of data between Employee Central and other SuccessFactors modules. It is a background job that periodically looks for data that has been changed in Employee Central and updates the Employee Profile with the new data from Employee Central. The job can be configured to run on a schedule. To update data using a user interface, the synchronization process is automatically triggered at the end of the update for current and past records.
5. There should be a separate workbook for the Employee Profile functionality with at least two sections. The first section contains the one-to-one relationship between the Employee Central and Employee Profile fields. The second section contains the HRIS synchronization configurations.

Factor #5: Translations

Translations are an important part of multi-national global implementations. Employee Central offers a lot of self-service functionality. Therefore it is important to translate data and pages to give them all a unified (and localized) look and feel. The topic of translations is often overlooked and isn’t addressed until the company sees the end product and complains. It’s very important to address this early for implementations with multiple languages in scope. Both gathering requirements and configuration take additional time in the case of translations because:

1. In most cases, the standard translation does not meet company expectations
2. Most of the configuration to update translations must be done manually
3. There is no automated way to download existing standard translations from SuccessFactors

Recommendations

1. Since there is no automated way to download standard translations in a chosen language, in the name of efficiency, I recommend that a resource be assigned to this task as soon as the design starts.

• Translation requirements should be discussed during Iteration 2, but preparation work can be started even earlier so as to avoid any potential delays in the project timeline.
• Configured translations should be tested thoroughly in Iteration 2 testing so that any defects can be removed during Iteration 3 configuration and user acceptance testing (UAT) can happen with all the required translations in place.

2. Some standard translations should be shown to the company in a workshop and any feedback gathered; for example, does the business accept SAP-standard translations?

• The company should be asked to give feedback on almost everything that is language-related, especially translations of self-service pages (along with fields).

3. The company is responsible for connecting and reviewing any third-party vendor translations.

• The implementation team should only be responsible for providing the data-collection format (e.g., the Translation Workbook) and configuring translations into the system—the team is not responsible for engaging and reviewing translations provided by third-party vendors.

4. The Translation Workbook should be simple enough to hold the objects and their translations (e.g., not many columns are required to store translations—simple enough to store objects to be translated and translations in English and other languages).

Factor #6: The Configuration Path Between Instances

Unlike with SAP on-premise systems, SuccessFactors doesn’t have an automated way (e.g., a transport management system) to transport configuration from one instance or system to another. Most of the time, configuration needs to be moved manually across different instances. These instances are part of the system landscape strategy defined for an organization. The total effort required for moving the configuration adds up with each instance in the landscape. It is primarily for this reason that it is recommended by SAP that companies keep their landscape simple. SuccessFactors has developed a tool called Instance Sync for moving configuration from one instance to another in automated way, but it is still in a nascent stage. Instance Sync can’t be used to move all configuration from one instance to another. The configuration that can—or cannot—be moved using this tool depends the type of data and instance-specific configuration. Any configuration that can’t be moved using Instance Sync requires manual intervention for movement. Any tests of this tool should be done in a sandbox schema.

Recommendations

1. Keep instance landscapes to a maximum of three (development, quality, and production). 2. The instance strategy should be defined at the planning stage so that any extra effort for moving the configuration can be factored and effectiveresourceplanningcanbe done up front.

• The instance strategy should be prepared in consensus with all the concerned project teams—for example, the integration, conversion,andEmployeeCentralteams.
• The instance strategy should be a formal document that is reviewed and approved by the company and circulated to all project teams to solicit feedback.
• The instance strategy document should talk about the process to be followed for moving configuration changes in production and non-productioninstances.

3. The movement of configuration for production instances should be supported with the use of a ticketing tool (for example, Microsoft SharePoint) so that approval and versioning of configuration can be maintained.

• The workflow for moving configuration in production instances should be handled in a manner that involves all affected project teams and keeps them informed, even for the smallest changes. This is important because even small changes can have a ripple effect on existing interfaces and conversion routines.

4. Resources who are working on instance strategy should periodically test the Instance Sync tools (after every quarterly release of SuccessFactors, for example) to assess and document configuration objects that can be easily moved using this tool going forward. 5. Provisioning configuration (the back end of SuccessFactors, which is used to enable or disable functionalities within the suite) should be copied by using a copy-settings-from-another-instance utility tool.

Factor #7: Implementing Modules Together

Many big projects span their implementation cycle across multiple phases to give companies a sense of achievement (through early return on investments ([ROI]) and to reduce the impact of change management, which can be huge when all modules go live simultaneously. For example, Employee Central represents core HR and implementations of Employee Central are generally spread across various phases. Oftentimes, each new phase includes a go-live of Employee Central (as an added phase) for additional employees from new countries. The talent management functionality goes live in the first phase (unless it is mutually decided between the client and project team to enable them in subsequent phases). This is because this module takes the least time to implement. This results in quick wins for the company and it can start releasing the benefits of SuccessFactors (early ROI) more quickly. For example, organization ABC has employees in 25 countries and at the end of phase 1 of the implementation, Employee Central is going live with the employees of five of the countries. The rest of the employees in the remaining 20 countries are scheduled to go live in the next two phases. The compensation module is also scheduled to go live at the end of phase, but for the entire population of organization ABC (i.e., for all employees in all 25 countries). Technically, SuccessFactors is capable of handling these kinds of scenarios in which implementation of the compensation module is planned for five countries (existing in Employee Central) along with 20 other countries’ employees (who aren’t in Employee Central, but do exist as users in the employee profiles). These kinds of scenarios are not ideal because they may create many problems that are often overlooked and unanticipated when determining the phased-implementation strategy. These are transitory problems, however, are usually temporary and only exist until all the countries’ employees are live within Employee Central. Some of these problems occur in scenarios like these, where:

• A non-Employee Central employee (technically a user) is the manager of an Employee Central employee.
• Employee Central employees are moved to countries which are not live in Employee Central.
• A user from a non-Employee Central-live country is moving to an Employee Central-live country.
• A user from non-Employee Central live country needs to be hired within Employee Central as part of the go-live for a specific country.

This list of problems is not a comprehensive list, but is enough to show the kinds of challenges that project teams’ face, and that can possibly derail the timeline if not dealt with at the appropriate time.

Recommendations

1. If possible, try to design timelines in such a manner that the compensation module goes live only when Employee Central is fully live with all the existing employees in all the countries. 2. If this is not possible, acknowledge this issue and include the extra work required in the plan to handle these transitory period scenarios, listed above.

• Special consideration should be given for support administrators who are responsible for handling these scenarios in live systems. This is why clear and precise user guides should be created for administrators

3. The design for these transitory period scenarios should be shared, discussed, and agreed upon by teams handling interfaced systems or other SuccessFactors modules. This is because these the scenarios can have an impact on the design of existing conversion and integrations.

Factor #8: Data Conversion and System Integration

Conversion is a process of loading data from a legacy system to SuccessFactors. Data in legacy systems may be in different forms than expected by SuccessFactors systems. This is why an exercise to transform the data should take place before it is uploaded into SuccessFactors. Common data to be loaded may be in the form of employee, HR foundation, or requisition data, just to mention a few types. Conversion is an important process as it makes the system ready to be used after go-live. The conversion process is handled by a large team and it is always given special attention as it is an important milestone for successful implementation. Conversion/integration is a process of connecting SuccessFactors with external systems so that data can be exchanged efficiently and quickly—for example, connecting Employee Central with an SAP on-premise Payroll system or connecting Employee Central and Microsoft Active Directory. These kinds of integrations use middleware such as Boomi or SAP Process Integration (PI) to connect multiple third-party or SAP systems with SuccessFactors. The conversion and integration processes are extremely important and should never be ignored or put off. Oftentimes, however, planning teams overlook the fact that the conversion/integration process originates from the module (in this case, Employee Central) and uses designs configured within the module. This is why conversion and integration teams should engage on a regular basis with the primary point of contact (POC) for design issues on the Employee Central team.

Recommendations

1. Establish a POC on the Employee Central team to address all conversion- and integration- related design issues. The Employee Central team member proposed as the POC should have participated in design workshops.
2. The conversion and integration teams should have at least one or two members with strong knowledge about the module being implemented (e.g., Employee Central).
3. Any changes to the design (field-level changes, for example) or foundation data (picklists) should be communicated to the conversion and integration teams as soon as they are finalized with the company. These changes should only be made in the system after a consensus has been reached with the conversion and integration teams

Factor #9: Last Thoughts and Final Recommendations

Employee Central also has some tasks that can be time consuming. These topics require lot of time to discuss in order reach a consensus between the company and the implementation team. It’s not the complexity of the configuration that makes these discussions time consuming, but rather the complexity of the discussion topics themselves. Some of these kinds of topics include event reason derivation, email notifications, various IDs in Employee Central (user ID and person ID, for example) and the HRIS Instance Sync tool (discussed in more detail earlier in this article in Factor #4). These specific topics are particularly hard to make decisions about and are time consuming for a variety of reasons. Some typical examples include:

• Some topics are complicated and difficult to explain, which makes it difficult to gather requirements (e.g., event reason derivation).
• Some topics are difficult to discuss because of current limitations with the SuccessFactors system itself; for example, email notifications. SuccessFactors has the limitation that only one kind of notification can be used for all processes (i.e., the approval email for transfers, promotions, or resignations all use the same notification).This topic often entails a lot of discussion and takes time to reach consensus.
• The various IDs in Employee Central and HRIS Sync directly affect multiple downstream processes (such as conversion, integration, and talent management), and it is difficult to get all the concerned teams together to agree at the same time.

Recommendations

1. Since these topics require lot of preparation in terms of creating material to present the concepts, I recommend that a live demonstration, with lots of examples, be used to explain these concepts to the business. These live demo sessions should be followed by small exercises where key client process owners explain what they learned and can discuss any doubts. This way, the implementation team can make sure that the company understands the importance of these decisions, and understands the effect these decisions will have on the implementation schedule and outcome.
2. Requirements gathered in workbooks about these topics should be carefully reviewed and approved by the company.
3. Project managers should include extra time in the scope of the project and the budget to handle these time-consuming topics adequately.