HRIS Case Study – Strategic Leadership India -LLC

HRIS Case Study – Strategic Leadership India - LLC 1

Index: 1. Abstract / Executive Summary – Pg.1 2. Industry Background - Pg.2 3. Description of Business - Pg.2 4. The HRIS- Planning Stage - Pg.2 5. Leave Management -Offline Process - Pg.3

a. LMS - An Effective Transaction - Pg.4 Processing System b. Data Cleansing and Validation - Pg.4 c. Test Environment - Pg.4 d. Data Security - Pg.5 e. Application Level Triggers - Pg.5

f. Testing Roadblocks and Challenges - Pg.6 g. Post Implementation Functionalities - Pg.6 6. Performance Management

– Offline Process - Pg.8

a. The Challenges with Offline Process - Pg.9

b. Performance Management – Entity Relationship Diagram - Pg.9

c. Online PCMS Advantages - Pg.9 d. User Friendly Interface - Pg.9 e. Enhanced Functionalities - Pg.10 f. Schedule Adherence - Pg.10 7. Conclusion - Pg.11

Abstract / Executive Summary: The objective of this case study is to present to prospective clients - our knowledge, skills and abilities to "synthesize" the clients need and deliver a integrated HRIS solution. Acronyms used – PCMS – Performance and Competency Management System LMS – Leave Management System Pre Implementation - Existing / rudimentary / offline – Performance Management & Leave Tracking processes. Post Implementation – Overview of the Online – PCMS & LMS – Related IT and Information Infrastructure.

Industry Background: Client Name was established in late 2005 as a fully owned IT Infrastructure subsidy of the CLIENT NAME Group, the organization grew from 20 to 100 in a span of @ 6 months. As factors in the external and internal environment were conducive to growth the organization is rapidly scaling up, employee strength is increasing (100 Employees as of March 2012, year end target 300+) so is the geographical spread. CLIENT NAME already has its employees at two locations within Bangalore and at Gurgaon.

Description of Business: The CLIENT NAME Group is a worldwide leader in Financial Protection. CLIENT NAME's operations are diverse geographically, with major operations in Europe, North America and the Asia/Pacific area. For 1H09, IFRS revenues amounted to Euro 48.4 billion and IFRS underlying earnings to Euro 2.1 billion. CLIENT NAME had Euro 967 billion in assets under management as of June 30, 2009.

Case Study – Actual Work Product IMPLEMENTATION OF A - HRIS FRAMEWORK Strategic-Leadership-LLC-India


The HRIS- Planning Stage:

The IT Strategy of the organization was Primarily driven from Germany (the Corp HQ of the MNC) , this strategy was clearly aligned towards implementation of a scalable company wide integrated - Human Resource Information System / Management Information System / Enterprise Resource Planning Platform - SAP.

1. Currently all international entities like – Belgium,

Germany, France, England and Australia were in transition mode from locally / internally built HRIS to SAP. India as an entity was to decide how to transition from offline manually driven processes to SAP over the span of next 2 years, by when the size of the Indian entity could justify a SAP implementation.

--------------------------------------------------------------------- The resources allocable to such a transitional project were limited. We have not shared the details of budget allocated to this project as it’s confidential to CLIENT NAME .

2. CLIENT NAME had to decide which HR Applications

had the most Business Critical data. This decision was required to zero in on the quick-wins for the Transition Project. It helped them identify applications with the most critical data – data which was required over a period of time, data which could not be inaccurate, as its inaccuracy would impact the business.

3. It was decided that the very first automation of

processes would be for Leave Management and Performance Management. a. Functional interoperability was critical for these

applications as they were to be the base upon which the SAP Structure was to be built at a latter date.

b. These and the systems which were to follow were not to expect changes in process, but were to rather aid the existing process by making it agile and online.

c. The processes as such were not faulty they had been tweaked with the in house Six Sigma methodology.

d. Thus this project was to be a vanilla automation of a healthy existing offline process.

4. The resources assigned to carry out these and other similar projects constituted of –

a. The Information Technology Team Lead and two

team members ( additional resources were at the discretion of the Project Manager subject to availability)

b. The Information Systems Manager and three team members ( additional resources were at the discretion of the Project Manager subject to availability)

c. The HR Assistant Manager ( additional HR resources were not available )

5. Strategic-Leadership-India was consulted as most of

the functional know how was not present internally. 6. The Project Planning was the joint responsibility of

the Information Systems Manager and Rohit . The Information Technology Team Lead provided access to the IT Infrastructure – Test Servers, Testing Environment, Development Environment, the Build and Release Environment.

7. The Project Manager was given discretion to take decisions (within budget and other agreed limits) and was given access to additional resources of the IT and IS team as and when required, rider being that there should not be unnecessary interruption to normal BAU activities. All affected departments IS, IT and HR were consulted by the Project Manager during the planning of the project on all matters that affected their people and resources. This was done by means of weekly progress review meetings.

Pre Implementation – Leave Management Offline Process: In this section we describe the AS IS process for Leave Management and share challenges in the offline leave management process. Most of these challenges were overcome by automation of the process. The Data consistency, accuracy and authenticity were ensured as a result of the automation. This data was available in real time and thus was ready to be ported onto the SAP system - this being the primary objective of the project – a smooth transition to SAP from offline processes.


1. Employee joins the organization; HR creates the

EMP ID by increasing the counter in a Worksheet.

2. Employee is authorized X numbers of days of Earned Leave ( EL ) , Y number of days of Casual Leave ( CL ) along with Sick Leave , all these are entered into the Worksheet as starting balances on DOJ or as accrued balance from the date of confirmation.

3. Every time an employee applies for leave the Leave Application form duly signed by the Employee, Manager and HR needs to be filed in the personal file.

4. In case this leave application form is misplaced there is no documented proof of leave availed. This used to create problems during compliance AUDITS – ISO etc.

5. The HR team needs to enter leave data manually for all employees and debit the Worksheet of the leave balance once the Leave form had been submitted. Sometimes managers shall be tied up and will not sign the leave form. There shall always be issues around the accuracy of data in this worksheet and also about the storage and safe keeping of the pages of leave application.

6. An employee’s real time leave balance shall only be available with the HR business partner or the Manager if he also maintains a worksheet.

7. If the manager maintains a worksheet then there shall be synchronization issues between the two worksheets.

8. The leave data is critical for employees on client projects as they cannot be billed on the dates they take either CL or SL , the EL’s are usually planned for in advance and are thus flagged in the project management & planning tools of the client also.

9. It was sometimes warranted to integrate the Attendance tracking system – swipe in system - data with the leave data. Especially so for invoicing T&M projects. The clients required Leave and Attendance data as part of these invoices. This was a challenge as data was maintained offline and client did not believe the authenticity of the data.

10. There was substantial time wasted by the HR resources on these transactional activities and still the data was never to be found accurate when required. The worksheet used for maintaining this data offline was akin to the worksheet seen - Figure 1.1 below :

( Figure 1.1 )

The Leave Management System – An Effective Transaction Processing System:

The Leave Management System was envisioned as an ideal Transaction processing System, which would provide real-time data, the essence being that leave data is managed in such a manner that after each transaction with the system the data is left in a consistent state. Transaction processing as a model for development was also implemented for the entire HRIS (LMS, PCMS and the subsequent modules). Transactions made by employees and managers in real-time were to be viewed as stand-alone transactions both at the request stage and end result / out put stage. These were inputs for many a internal and external stakeholder processes – client invoicing,

Let’s understand this advantage with an example – Ram is allocated to work in a team whose Client

Resource Manager is stationed in Australia (employee of CLIENT NAME Australia). The project is being executed for CLIENT NAME’s Australia office. Ram is based in Pune his Operational Reporting is mapped to the IT Manager stationed at Bangalore (there is no manager level employee stationed at Australia). Ram can not be mapped to the Australian employee as this shall lead to Employee Relation issues. If Ram applies for leave being in Gurgaon, his manager approves the same being stationed at Bangalore this transaction is over.

Figure ( 1.1 ) Leave data maintained offline.


The system immediately needs to provide the relevant out put from this transaction as an input to the Client Resource Manager. This was not possible from the offline system. There the Manager at Bangalore or Ram at Gurgaon would be required to email the manager in Australia. The LMS was built keeping these Real-time Transactional benefits in mind.

Data Cleansing and Validation: As the LMS was a highly data dependant application the very first step taken was the validation of the Leave Data available with the HR team , the different functional teams and the client resource managers ( being the case for two teams working on Payroll of CLIENT NAME but under direct Operational Control of Client Managers ). Manually updated worksheets were emailed to al concerned Resource Managers and their inputs consolidated in a master sheet. This data was then signed off by the respective Business Unit Heads. This was to be an ongoing process till the Leave Management System went live as this data was changing almost daily.

Test Environment: With the live data ported into the leave Master Database a test environment was created for the application – a. The test environment was to have a pilot

application running with all the functionalities of the actual LMS.

b. The front end forms which were created were – A

Dash Board / Landing Page for the Employee which showed his current EL, CL & SL Balances. This form gave the employee option to apply for these leaves and also for the SL and Maternity Leave (for female employees). The moment the employee applied for a leave an auto email intimation was sent from the Email Server to the mapped Resource Manager and the HR Business Partner.

c. An EMP_INFO table within the LMS database was created , its various record types were –

1. Emp ID of Employee 2. Name of Employee 3. Emp ID of Resource Manager 4. Name of Resource Manager 5. Email ID of Employee 6. Email ID of Resource Manager

d. Forms were also created for the Resource Manager

and the HR Business partner. The Manager could view a listing of his entire team along with their various leave balances. He could also view the Applications Pending for approval. Within this form itself he had a URL that took him to another form where he could conduct individual leave transactions. Approvals / Rejections reflected in real-time to the employee and the HR Business Partner.

e. The Leave_MASTER , table within the LMS database

was created , its various record types were –

1. EL_Opening Balance 2. EL_Closing Balance 3. EL_Applied Date 4. EL_Approved Date 5. CL_Opening Balance 6. CL_Closing Balance 7. CL_Applied Date 8. CL_Approved Date etc. These records were updated for every transaction through SQL queries and the Leave Master database was kept updated in real-time.

f. Various Reports were catered for and tested in the

Test Environment – 1. Resource Managers Team Report 2. Finances Billing / Invoicing Report 3. Attendance Report 4. Payroll Report

The need was felt for varied reports as all stakeholders did not require all the data that was stored in the Leave master database. All these reports exported in the form of worksheets.


Data Security: Data security was catered for at two levels one at the individual user level and the application level. This pattern of data security was also replicated for the PCMS and the subsequent HR Modules developed within the HRIS. Individual User Level - Employees (with no direct reports) could access only personal data, of which they could modify only limited data i.e. – Office Extension, IP Phone etc, for most other data the approval from the Resource Manger was mandatory in some cases a secondary approval was required from the HR Business Partner. None could view the data of other employees / access data of other employee’s direct reports. Application Level – The LMS, PCMS and the modules created subsequently as part of the HRIS had mandatory secondary logins. The Passwords had 28bit encryption and were similar to the Windows Login. This ensured that no other employee could login and alter the information of any other employee. Also included in application level security were the concerns for Employee Privacy or data secrecy. For example the training team could only view the Training Requirements posted as part of the PCMS by Resource Managers and could under no circumstances see / generate reports on employee leave and employee salary etc.

Application Level Triggers: The LMS had certain application level triggers which were mandatory to remind the stakeholders of certain timelines etc , these were –

1. The first reminder to managers for leave approvals, an auto generated email sent to the manager if leave not approved / rejected within 12hrs of application.

2. The second reminder to managers for leave approvals, an auto generated email sent to the

Resource Manager and his/ her Manager if leave not approved / rejected within 24hrs of application. This was deemed necessitated as the Resource Manager could be on leave themselves.

3. Trigger to HR and Resource Manager in case employee is absent – has not swiped in nor has logged into designated workstation. This was possible as the LMS was integrated with the Swipe In Attendance tracking system.

4. The reminder to managers for Confirmation of

Employees post the 6 months probation period. This trigger was similar and parallel to a trigger in the PCMS.

Testing Roadblocks and Challenges: It is never easy to replicate a test environment exactly in the manner that we would desire a live application environment, even after the very best efforts of the IT team a majority of bugs were trapped at the actual execution level after the Go Live / Implementation. During the test phase certain challenges were faced which were – 1. Inconsistent Leave data, the HR team had to go

through almost 15 iterations before data could be frozen. Kurt Lewin’s Change model recommends – Unfreeze - Change – Refreeze, sometimes the data would change before the refreeze, and this was by far the most prominent functional challenge.

2. It was easy to train employees on the functionalities of the Leave Management System but it was a daunting task to make them change their attitudes and lax behavioral patterns. Everyone was used to the offline Leave Process, the offline process was Batch processing transactions. There was always scope, time and bandwidth for timely corrections. Real-time processing capabilities of the Leave Management System warranted accuracy and authentic transactions.

a. Changing data once entered for leave applied required a cancellation which would again trigger


an alert and require the manager’s approval for cancellation. b. This was considered as an overhead by most employees but imbibed a sense of discipline and accuracy into the daily functioning.

Few challenges warranted a re-look at organizational policy and structure an example is as seen below - 3. A challenge that led to policy change and partial

Org. restructuring was - email ID’s of the Employees and Resource managers were frequently required to be updated in the database. This was so that they reflected the current reporting. Reporting had become dynamic and flexible due to frequent project allocations and resources sharing for batch projects.

It was thus warranted that the concept of the Resource-manager or Pool-manager being distinct from the Functional Manager be introduced. The Resource Manager was to handle the Operational reporting for employees within a Batch project. The Functional Manager was to handle the functional reporting for employees with related, similar or aligned competencies i.e. Network Engineers, Java Developers, .Net engineers, Technical Helpdesk Associates etc. Employees operationally became pool resources. Their Leaves were sanctioned by the Resource manager, billing was invoiced by the resource managers and the Performance was appraised by the Functional managers.

Post Implementation Functionalities: The LMS became a success post implementation the most outstanding features and functionalities were:–

Generic Advantages - a. Software Development costs were minimal as

the Software Development Kit (SDK) was available for other applications too. The Testing, Development and Maintenance were handled totally in-house.

b. The HRIS as also the PCMS had a client server / thin client architecture, thus keeping the IT infrastructure cost minimal. The desktops required no changes of hardware of configuration etc.

c. There were no additional networking requirements or costs.

d. Web interfaces were not planned as the data was sensitive & business critical. There was thus no external web hosting costs.

e. Hardware costs were minimal as internal servers were used to co host these applications with other internal applications.

Application Specific Advantages –

1. No need for creation of employee iD’s manually, the employee master process increments the EMP_ID counter.

2. All employees have similar leave

authorization thus on creation of new employee database populated with authorized number of EL’s, PL’s & CL’s. The SL and Maternity Leave are transaction dependent; these are debited on need basis from the Employee leave Master table.

3. An employee leave transaction is complete

when it goes through the following six steps:-

i. Employee validates available leave balance – done within the employee form, as real-time balances are available.

ii. Employee triggers leave application by choosing – “from” and “to” date, choosing leave type and resource manager name (in certain cases employees were mapped to 2 resource managers). Employee fills in the address, contact details while on leave if the leave period is beyond 3 days.

iii. Email is triggered to Resource manager, HR Business Partner giving all details as mentioned at point (ii) above.


iv. Resource Manger Approves / Rejects (providing reasons for rejection) leave application. Email is triggered back for Employee and HR Business Partner.

v. Employee decides not to proceed on leave even after approval, withdraws the leave application. Email is triggered for Resource Manager and HR Business Partner.

vi. The leave database is accordingly debited for leave availed. Calculations are made for Saturday, Sundays and National Holidays. The Leave credits happen at fixed intervals in accordance with leave policy.

4. The LMS also provided reports for the Resource manager the, HR Business Partner, the Finance and Payroll. The data at any given time was real-time, consistent and authentic. The reports were generated through SQL queries targeted towards specific tables of the LMS database. 5. The LMS database was interlinked with the Employee Master, from where it populated the basic employee structure info such as, EMP_ID, EMP_Name, Resource manager EMP_ID, EMP_Name, Email Id’s etc. It populated its own Leave table by debiting and crediting Leaves on specific triggers.

The Leave Report (as exported to .xls) for a particular project team looked as seen in Figure (1.2) below:

The Offline Performance Management Process :-

Confirmation, Half Yearly and Annual Appraisals were done offline by Assesee (Employee), Assessor (Functional Manager) & Reviewer (Functional Managers Manager) sharing worksheets at each step of the process. These worksheets (Screen capture seen below as Figure – 1.3 ) were emailed from Assesee to Assessor to Reviewer and finally to the HR Business Partner.

The Challenges with Offline Process: –

1. The offline Process was inherently cumbersome. It had no inbuilt data integrity, security or consistency of data.

2. Employee Performance Data could be accidentally accessible to prying eyes.

3. It was extremely difficult to maintain records / versions of earlier appraisals.

4. Appraisal discussions were recorded in email body or in separate attachments. Keeping track and validation of genuine documents (at a latter date) was an ethical issue.

5. The Offline process had a number of iterations as seen below in – Figure (1.5), it required many a back and forth of emails and worksheets.

Figure – ( 1.2) Employee Leave Data as seen in worksheet a result of the SQL query for - EMP ID , PL , CL , SL & Opening , Closing Balance .

Figure – 1.3 – Offline Appraisal Form - Worksheet


6. Keeping track of process and ensuring closure within timelines was a challenge.

7. Employees found it difficult to update the Goal Settings data for various appraisal cycles.

8. Managers could not refer to previous appraisals online and had to either store worksheets from previous cycles or seek these from the HR.

9. In case the earlier Functional Manager had moved out from the organization it was difficult to track this data.

Data Captured In Worksheets –

1. Data generated at each step stored in worksheets.

2. Accuracy of data an issue as there are numerous and varied data points.

3. This is sample depicting limited data points / data items required to be maintained for 1 Employees, 1 Cycle of Appraisals. ( Figure – 1.4 )

4. Similar data maintained for 300+ employees, data integrity was a challenge.

Performance Management – Entity Relationship Diagram:

Online PCMS Advantages: Post implementation the PCMS had many advantages the main intangible advantage being employees felt proud that the organization considered Performance management o employees so highly that they specially commission a Software Application for Performance management. The following functionalities were catered for –

1. Confirmation Appraisals 2. Half Yearly Appraisals 3. Annual Appraisals 4. Online Performance Feedback 5. Forced Ranking

Figure – 1.4 – Offline Appraisal Data Points

Figure – 1.5 – Offline Appraisal Data Points

S No.

Data Type

Name EMP ID

Email ID Reporting Duration

Assessment Duration

Appraisal Type

Assesse Rating

Assessor Rating

Reviewer Rating

1 Assesse Data

Assesse Name

123 NA 12 Half Yearly

3 NA NA

2 Assessor Data

Assessor Name

103 [email protected] 6 NA Half Yearly

NA 2 NA

3 Reviewer Data

Reviewer Name

93 [email protected] 6 NA Half Yearly

NA NA 2

mailto:[email protected]





6. Critical Incidents Tracking

7. Assessor and Reviewer Feedback Discussions 8. Separate Incidents of Appraisals

9. Automated closure in case of delays 10.Online Normalization – Bell Curve. The Post Implementation PCMS Infrastructure is dealt with in the PPT accompanying this Case Study , we still list the following -

1. SQL Server , Oracle 9i – Back End . 2. ASP .Net based GUI - Front End. 3. OS - MS Windows XP Professional. 4. Client Server Architecture - Thin Client. 5. Single ID and Password Login for all Sub Modules 6. Accessible across WAN of CLIENT NAME 7. System generated alerts

User Friendly Interface: The PCMS had an

extremely user friendly interface, from a single Login the user was directed to the customized user interface. As seen in Figure – 1.6 below the PCMS landing page for an employee with role Assesse looked like this. From this very page the Assesse could navigate to various forms as listed below.

Various Assesse Level forms –

a. Goal Setting b. Self Appraisal c. Development Plan d. Previous Appraisal Data e. Assessor Ratings & Discussion f. Critical Incident Log g. Final Ratings

Enhanced Functionalities:

The PCMS catered for different instances for different roles of the employee. Take for instance a Manager level employee he would be required to fill in his own Self Goal Setting, Self Appraisal, Self rating and Development plan etc. The system would also cater for this Manager to carry out all these activities from the same Login under a different tab. Figure 1.7 below displays the Assesse Goal Setting Form this form catered for the assesse to set self goals also it catered for –

a. Drill down objectives to be set for each Goal defined.

b. Defining of Specific KPI’s – Key performance indicators for each specific performance Objective chosen.

c. The weightages were allocated to each specific Objective from 10% to 90 %, these could be chosen forma drop down list, and these would add upto 100% signifying each objectives contribution to the overall performance of the employee.

d. Specific timelines were assigned for completion of Objectives, the Performance management framework mirrored the Project Planning Timelines.

Figure – ( 1.6 ) PCMS ASP enabled GUI - Front End – Assesse Landing Page


Schedule Adherence:

With the Online PCMS it was easier to adhere to schedules for closures of various Appraisal Cycles. Especially in the case of the Annual appraisal it was difficult to explain to the majority of the organization if the Normalization or declaration of ratings was being delayed due to a specific team. The online PCMS gave each Functional Head access to reports that provided Real-time data of Schedule Adherence to process timelines. As is seen in the Figure – 1.8 below, such reports were available which showed for an Individual Employee –

1. Goals Setting Status 2. Self Appraisal Status 3. Assessor Rating and Feedback Status 4. Reviewer Rating and Feedback Status

Similar in content drill down reports were also available for a Team of employees who could be directly reporting to the Assessor or indirectly to the Reviewer. All these status reports for the entire Organization were accessible to the HR Business Partners. Thus the HR Business partners along with the Assessors and Reviewers drove the PCMS Appraisals and ensured Schedule Adherence for this Business Critical Process.

Conclusion: The PCMS and the LMS both added value to the Internal HR Efficiency at CLIENT NAME . The LMS impacted directly and positively both the Employee Relations and Client Invoicing. The PCMS clearly positively impacted Employee Development, Compensation Administration and Employee Relations. These processes were rightly chosen as Business Critical they were the stepping stones for the completion of the Transformational project the implementation of an in-house HRIS at CLIENT NAME. This in-house HRIS further paved the way for the successful implementation of SAP. Figure 1.9 gives us an overview of the PCMS online process.

Figure – (1.7) – Goals, Objectives, KPI’s and their weightage as seen in the Assesse Goal Setting Form.

Figure – (1.8) – Appraisal Status Report for Annual Appraisal completion and Schedule Adherence.

Figure – (1.9) – Appraisal Process as defined within the PCMS.

HRIS Case Study – Strategic Leadership India -LLC

Documents