Basic Principles/Planning during a Brownfield Implementation to enhance Employee Central Solution

[manubhutani]

This blog is basically to share some experiences which can come handy during a Brownfield SuccessFactors Employee Central (EC) implementation or while enhancing Employee Central solution to support Vendor Integration globally/for some countries for ex. ADP for Payroll.

In this blog we can assume that we are enhancing our EC solution to support the transition of Payroll from Vendor A to ADP for some countries while some countries are already live on ADP. Since Employee master data resides in EC so we need an Integration from EC to ADP so that Payroll can be run in ADP.

In such situation customer is already live on SuccessFactors Employee Central and the solution needs to be enhanced with new configuration and data loads to meet the requirements. The success of your implementation depends on how well you understand your already live environment. Such implementations become tricky and complex due to following reasons.

1. As you know that throughout the lifecycle of the implementation there are various mocks to practice the Configuration/Data Loads and in this case it's not a fresh system but already an up and running system. So for every mock when you copy from Production EC instance you will get something new because of various change requests, enhancements, data changes in live system. So it becomes really difficult to practice a mock cut over which will mimic the production cut over.


2. In continuation to above point make sure you are aware of all planned CRs which will move to production EC instance during/after your Production cut over to make sure your solutions (as part of Brownfield Implementation) don't break anything in the system.


3. As I said you are going live on already live environment so it is suggested to hold on all the CRs during the production cut over to mitigate the risks.


4. There may be SAP SuccessFactors upgrades planned during your production cut over so be prepared for that as well. Even a small change in any functionality can create hurdles in your already tested solution.


5. There can be some mandatory upgrade where all customers have to migrate to enhanced version. For ex. Legacy Picklist Migration to MDF Picklist. This changes the whole game because for ex. MDF picklist doesn't allow multiple parent child relationships. So take such migrations into consideration during Production cut over.


6. The Black out during production cut over will be only for countries going live but not globally so take care of those tasks which affect all countries because you will be performing cut over in an up and running LIVE system.


7. It is better to turn off the inbound and outbound Integrations for countries going live during the black out period to make sure you are working on a static environment (at least for those countries that are going live).


8. It is difficult to have a long black out period in such implementations so you don't need a high level roadmap but a detailed plan.

From Configuration standpoint below points should be considered.

1. Before enabling any new custom field for any portlet for a country check whether this field is already enabled for any other country. If yes then it is advisable to use the same custom field for your country to make the solution is generic. This way you can use existing picklist id and add records as per the requirement. Ex. Country A and B are already live on ADP and now Country C will go live on ADP so same custom field which is enabled for A and B should be enabled for C and picklist values can be added for C.


2. In continuation to above point make sure not to change any property of this field. For example if this field is not editable for Country A and Country B and you make it editable for Country C then it will become editable for all countries. So take decision as per the requirement to avoid getting surprises after Go-live.


3. If you create new pay components then make sure to dissociate the old pay components so that HR/Business users don't end up using old pay components after go-live.


4. If you have to change a global field then make sure communication is sent out to global teams to analyze the affect.


5. Before configuring a new business rules check the existing ones to make sure you don't end up creating a duplicate.

From Conversion/Data Loads standpoint below points should be considered.

1. Work out the effective date to load records into existing Foundation objects/MDFs in such a way that doesn't create an issue if user wants to make retro changes. For ex. if you added new mandatory fields in the position object which get sync to Job info (where also the fields are mandatory) then decide an earliest date to load data into Positions where no changes are expected if there is a record where the field will not be populated.


2. If you insert a FTSD/split/Migration/Conversion record in Employee portlets then no retro changes should be done before this split date because those changes will not replicate to ADP /other third party systems. Usually the split date will be the Pay period start date for Payroll. Most probably you will create a split on FTSD because this FTSD record marks the beginning of your Implementation.


3. Decide whether you want to convert terminated employees. This is required to make sure Rehire scenarios work properly. For ex. if you have created new pay components and deactivated the old ones/dissociated the old pay components with Country MDF then Inbound Integrations may fail because via APIs we need explicit logic to delete old pay component while creating a new record in Compensation portlet. (When you create a new record in Compensation portlet old record is copied)


4. Decide what all portlets need a split record as per your requirements.


5. If you load data into existing fields then better to do that only during black out because it's a running/moving system. If you do any data load before black out period then you have to do a delta during black out again.

From EC External (ex. Vendor) Integrations standpoint below points should be considered.

1. All new fields configured should be added into existing Integrations as per requirement. For ex. If employees are hired in third party system and then come into Employee Central then such Integrations should be modified to make sure new Mandatory/Optional fields configured in EC are added into third party Integrations (such fields should either come from third party system or defaulted in Integration). Inbound Integrations will fail if mandatory Integrations don't update mandatory fields in EC.


2. In continuation to above point in case of Inbound Integrations if you have mapping stored in a MDF table then this MDF table should have updated values in every EC environment. For ex. A field in EC which has a picklist attached to it and if you have stored the mapping of this field in MDF table in terms of option id (Middleware use the option id of picklist to update the picklist field) of picklist values for Interface to read then make sure this MDF table has updated mappings because option id is different in different EC environments.


3. The FTSD records will have a custom Event Reason which Integrations should identify after go-live and logic should be added accordingly.


4. The new business rules configured to default newly added fields may not get triggered via APIs so logic should be added in the Integrations and tested thoroughly.

From EC Reporting standpoint the Ad-hoc reports, Integration Center Reports, Advanced Reporting etc. should all be updated to accommodate new fields and changes done to existing fields.

From RBP standpoint it is pretty straightforward. Make sure the RBP workbook is updated with newly added fields and roles are defined and updated and updated roles are assigned to all users. From Integrations standpoint the user used in the Integrations for API is updated accordingly as Integrations would fail to update new fields.