future shock: impact of hrms implementation on · pdf filefuture shock: impact of hrms...

Future Shock: Impact of HRMS

Implementation on Existing Non-HR

Modules

Mohan DuttBinita Wagle

Hyperion Solutions CorporationGopal Krishna Anant

L&T InfoTech

Copyright © 2007, Dutt-Wagle-Anant. All rights reserved. 2

“Future Shock: A personal perception of too Future Shock: A personal perception of too much change in too short a period of timemuch change in too short a period of time.”

Alvin Toffler“Future Shock”


Presentation AgendaHRMS Implementation – Project Objectives & Scope

HCM Global Framework

Oracle Applications Environment – Existing & Proposed

Changes implemented in Oracle HRMS

Impact of changes on existing non-HR modules

Data Migration and Testing Strategy

Production cutover tasks

SOX Implications

Post Go-Live Issues & Resolution

Lessons Learned - Ways to avoid Future Shock


Project ObjectivesImplement Oracle HR GloballyEliminate many paper-based processes & transactions— Operational & process efficiencies

Provide direct access and updates to employee data— Manager and Employee Self Service

Improve data reliability and reporting capability— Improved HCM

24 x 7 global system accessBetter support of future growthIntegrated technology platform


HCM Global Framework

Planning Acquisition Performance Continuity

• Environmental Scanning• Forecasting• Job Design• Organization Design

• Strategic Direction• Goal Setting • Coaching• Feedback/Evaluation

• Data Management• Systems Development• Query and Reporting

• Compensation• Recognition• Benefits

• Policies/Practices• Diversity• Corp Social Responsibility • Employee Communications

Analytics Learning Rewards Culture

• Succession Planning • Career Development• Engagement/Retention• Separation

Enter

• Recruitment/Staffing• Orientation/Assimilation• Integration• Branding

HCM Information Systems

Oracle HRMS Success Factors Learning System Hodes Payroll IntranetKey Transactional Processes and Applications

• Employee/Manager Training• Leadership Development• Organization Effectiveness

Entering Organization

Exiting Organization


Project ScopeRollout of new technology systems & solutions in support of the HCM Global FrameworkImplement HCM Benefits – Project Olympus: BHQ DirectImplement HCM Performance Management – Project Alison: Success FactorsImplement HCM Phase I – Project Phoenix: Oracle HRMSProject Olympus went live in July, 2006Project Alison went live in August, 2006Project Phoenix went live on November 14, 2006Phase II scope – Oracle Self-Service HR: Manager & Employee


Oracle Applications Environment

Before HRMS Implementation— Single Business Group— Single Segment Job Flexfield— 55 HR Organizations— 71 Jobs— 124 Locations

Post HRMS Implementation— Single Business Group— Multiple Segment Job Flexfied— 600+ HR Organizations— 720+ Jobs— 149 Locations


Changes Implemented in Oracle HRMS I

One year history migrated for all active employees and employees within 1 year. Any other termed employees left untouched as they maybe attached to non-HR transactions

History Data

Change from single segment to multi-segment job codesJobs

Identification of persons as Employees and Contingent Workers (CWK). Previously, all persons were entered with person type: Employee.

Person Type

Naming convention changed to include country as prefixLocations

Name changed to include cost center as prefix before organization name. Organizations

ChangesEntity


Illustration of Typical Key Changes

Chapel Hill, NC USA - Chapel Hill, NCLocationLocation

US South Central Region

9999 - Central Region Consulting - South Central

OrganizationOrganization

Principal Technical Architect

JobJob US SVC 8899

Principal Technical Architect


Changes Implemented in Oracle HRMS II

Date Track Enabled for HR in Full installed modeDate Tracking

Any looping in the supervisor hierarchy identified to be eliminated, e.g. Chairman’s supervisor. Looping hierarchy not supported by SSHR (AME). One of the candidates for change for Phase II

Supervisor Hierarchy

Employee numbering changed from manual to automatic numberingNumbering Scheme

Contingent Worker Numbers stored in NPW_Number field instead of Employee Number. Custom reports modified to incorporate number change and person_type_id change (from 6 to 13)

Person Numbers

ChangesEntity


Impact of Changes in non-HR modules

Org Hierarchy modify to include new organizations setupPA: Org Hierarchy

Approval Assignments redefined for the new job codes setupPO: Approvals Assignments

Bill Rate overrides redefined for the new job codes setupPA: Job Bill Rate Overrides

New HR job codes mapped to the PJRM job codesPJRM: Job Mapping

Cost Rates redefined for the new job codes setupPA: Cost Rates

Bill Rates redefined for the new job codes setupPA: Bill Rates

ChangesEntity



Extra Information for all new Billable Jobs setup for PJRM Delivery Assignments

PA: Jobs Extra Information

Labor cost clearing account for CWK setupPA: Labor Cost Clearing Accounts

Contingent Worker person information updated with Supplier, Supplier site information to enable expense entry

OIE: Contingent Worker Setups for Expense Reports

Rules and SQL modified for new cost center codes and org description

PA: Auto Accounting Rules and SQL

Look up set modified to account for new org descriptions

PA: Auto Accounting Look up sets

Profile Option set to Assignment for viewing current assignment only

PJR: Supervisor hierarchy profile option

ChangesEntity



CWK would only be eligible to enter expense report if Supplier and Supplier site information is defined for their person records.

CWK: Supplier information

Multiple records for active CWK no longer allowed. Previously, there were multiple CWK records for the same person setup with different person numbers.

CWK: Active Records

Only completed transactions entered before cutover can be processed with a ‘History Supervisor’. In process transactions to be re-entered.

Retro Transactions

Ensure that resources are linked to the correct person id and no duplication in resources de-normalized table

CRM: Resources

ChangesEntity



Custom concurrent program to create or end-date user was rewritten to account for CWK hire, final processing date etc

FND: User Creation

Multiple assignments for same person number configured instead of creating multiple CWK number for same person with different assignments.

PER: Multiple Records

Corporate Data warehouse extract programs that referenced organizations, jobs and locations were updated to comply with the changed HR data.

Data warehouse Extract Programs

Value Sets referencing country specific custom PO: Approver List updated to reflect new values.FND: Value Sets

ChangesEntity


Data Migration Strategy I

Freeze creation of new job codes in old HR system 1 month before cutoverNew purchase requisitions not entered 2 weeks before cutoverIn-process requisitions approved 1 week before cutover or re-entered again post cutover.Change in key flexfields require re-implementation of the apps. An unique toolkit was used by our implementation partner who preserved all the referential integrity and the IDs while converting existing person information to the new flexfield structure.One had very few fallout due to code combinations being invalid,supervisor information not converted etc. However, after seven test cycles the conversion was perfect and the production cutover was smooth.


Data Migration Strategy II

New PO: Approval Assignments were uploaded using Data Loader. Validation scripts ensured correctness of the data and any missing job-approval assignment combination.PA: Job Bill Rate overrides for each project was migrated using custom program.Data Loader was used extensively for other master data uploads or updates, e.g. Organization creation or Location updates. The rationale was that these were one-time setups and no conversion or migration scripts were scope.Only 1 year of historical person data was converted for active employees. There were issues related to processing retro transactions (i.e. transactions before cutover date). It was decided to introduce a ‘History Supervisor’ for all such records to prevent any non-HR transaction processing failure.


Testing StrategyTesting Oracle HRMS Module— New Hire to Termination Process for Employees and Contingent

Workers (CWK) and all transaction in between the events— Processing with Active employees simulating data conversion

cutover— Processing with Contingent Workers simulating cutover

Testing non-HR Modules— Test all employee-facing modules – iExpense, OTL, iProcurement— Additionally test employee, job, org impacted modules – Payables,

Purchasing, Project Billing, Project Resource Management, CRM Foundation, Inventory, Assets, Order Management

— Test new transactions and retro transactions (retro = transactions before simulated cutover date)

— Test self-service modules functionality to be used by CWK— Test Contingent worker transactions (simulated pre-cutover and

post-cutover) in non-HR modules


Production Cutover Tasks - I200+ Cutover tasks were classified in four phases as follows:— Pre-migration tasks— System migration tasks— Data migration tasks— Post-migration tasks

Pre-migration tasks included setup and configuration that did not impact the erstwhile production system. Some of the setups completed during this phase were:— Set Key Flexfield Value Sets and Segments— Define DFF segments for Person, Assignment, Job, Org ,

Salary,Termination forms— Define and register Special Information Types (SIT)— Define Lookup types and values— Define Elements, Salary Basis and Link elements and costing— Define Task Flow nodes, task flows, functions, menus, responsibilities— Freeze new employee data creation— Extract all data files needed for migration


Production Cutover Tasks - IISystem migration tasks included the following among others:— Send shutdown communication and disable end user access — Put all scheduled concurrent programs/interfaces ‘On Hold’— Disable all inbound/outbound interfaces in legacy HR system— Create and validate backup— Lock power user database accounts— Bring back application online— Run Key Reports for all countries

Some of the Data Migration tasks comprised of the following:— Define Key HR Flexfields: Job and People Group— Enable DFF: Person, Assignment, Job, Org ,Salary, Termination— Load Jobs and Organizations— Update Extra Job Information— Define / Update Locations


Production Cutover Tasks - IIIThe data conversion tasks included the following:— Full Name change — Changing CWK for expanded role— Remove person information from Oracle PER tables— Load person, assignment, address, phone, contacts, salaries, SIT— Update PERSON_ID to the same ID pre-migration

The post-migration phases involved tasks related mostly to non-HR modules:— Load Bill / Cost Rates for all countries— Create PJRM Job Mapping— Modify PA: AutoAccounting Rules and Lookup set changes— Configure setups Contingent Worker— Org Hierarchy changes— PA: Labor Cost Clearing Account setup— Load PA: Job Bill Rate Overrides— Turn on Automatic Numbering for Employees


SOX ImplicationsSystem and HRMS application security strengthened to conform to SOX controls.Custom HR responsibilities created as per country specific regulations and security requirements.Tools > Examine functionality using FND: Utility Diagnostics profile options disabled.Mercury ITG Change Management tool implemented to maintain and migrate the complete life-cycle of any application changes.Third-party software implementation planned to address Segregation of Duties (SOD) access policiesDatabase access to key HR tables removed. Access limited to custom views where all sensitive fields were masked.All sensitive HR data masked in cloned instances using custom obfuscation program.


Post Go-Live Issues & Resolution - I

The existing PO: Approval Hierarchy had several positions like “IT Equipment Purchase Approver” and “EMEA Buyer” that were setup as persons. Since the HR information for these were not converted, approvals failed. A value set was created to link a position to an employee and the approval code referenced the value set.Min-Max Requisition Creation process was failing since the requester was a person not defined in the system post-conversion. Min-Max Planning process was rescheduled by Purchasing team.Expense Report Import not working for Employees with Final Processing Date greater than termination date. Oracle has released a patch. Patch is only compatible with ATG.RUP4 and further patching followed by regression testing required to resolve this issue.


Post Go-Live Issues & Resolution - IIWorkflow Background Processes were put on hold during cutover. Inadvertently, they were not started post-cutover. All scheduled concurrent programs had holds removed.Individual database account didn’t have read access to custom tables. Access were granted after review of all custom objects were conducted.CWK cannot approve requisitions. Enhancement request created.Employee record was created in HR but Oracle user record not created. Existing custom program rewritten to incorporate HR changes like date tracking, final processing date, person type etcLabor cost exception due to incomplete auto accounting setup. HR team had changed the organization description post go-live to match cost center value set description assuming org_id remains unchanged and hence no impact. Autoaccounting was updated to match changed description value.


Lessons Learned IThe impact of HR implementation on non-HR modules was underestimated. The scope of data conversion for non-HR modules increased manifold with the configurations decided for HR. Instead of APIs, Data Loader was used for some conversions. This required ‘freeze’ of HR data weeks before cutover as well as a longer production cutover time. Please review APIs that can beleveraged as much as possible. Not all inbound and outbound interfaces were identified early enough to gauge the implementation impact. Interface testing thus arrived on the critical path of the implementation when it should have been a parallel activity.The regression testing required for non-HR modules was far greater than the initial estimates.The HR data conversion itself went through several iterations before it was perfect. Most of the fallouts were only noticed when doing non-HR module testing.


Lessons Learned IIHR: Data Security is of primary importance due to sensitive databeing entered in the system. Greater focus on this area is recommended.In-depth non-HR testing by business users did not go through as many cycles as the HR testing. On hindsight, these cycles needed to be synched for quicker issue resolution.The core-HR implementation team had no bandwidth to address the non-HR impacts. Hence, a separate non-HR testing team is crucial.The “Future Shock” shock handled admirably by the HRIS & ITS team who performed admirably to overcome the monumental hurdles and still go-live on time. Avoid “Future Shock” by planning and estimating impacts on non-HR modules as this suddenly arrives on the project critical path


Additional ReadingChallenges Implementing Oracle HR/Payroll after Financials – Ken Conway and Bill Straton, OAUG Conference 2000Harmoniously implementing HRMS on top of existing Fin, CRM, SCM modules – Basavraj Loni, OAUG Connection Point 2005Challenges of Implementing HRMS after Financials – A whitepaper by Satyaprakash H.A.Oracle 11i HR/Benefits/Payroll Strategies after Financials – Ken Conway, SCOUAG Conference, 2003Future Shock: Impact of HRMS implementation on non-HR Modules (White Paper) – Dutt-Wagle-Anant-Rogers, Connection Point 2007 (forthcoming)

We hope this presentation intrigued, provoked and encouraged you to ask us

some questions!Please take a minute to respond to the Session Survey at the following URL:

http://http://www.zoomerang.com/survey.zgi?pwww.zoomerang.com/survey.zgi?p=WEB2262HTP7DG2=WEB2262HTP7DG2

future shock: impact of hrms implementation on · pdf filefuture shock: impact of hrms...

Documents