Contents

The Background
Challenges
Problem Analysis
Plan Execution
Lessons Learnt

Summary:

This is a real life case story of how a failed PeopleSoft HR ERP Implementation which had not delivered the results and was in doldrums was brought back on track. When I took over PeopleSoft ERP, there was widespread dissatisfaction with the software and the consultants who had implemented the software. There was no reliability of data and reports. In spite of having a world renowned HR ERP system, no one was ever sure of the exact head count of the company. Data was extracted to excel sheets and then after due modifications, reports were being prepared for three years. The data on PeopleSoft was not reliable for direct reporting.

The Background

When I took over the PeopleSoft implementation as Head of Global Software department, there was widespread dissatisfaction about the ERP. PeopleSoft Finance and HR modules were implemented about three years back and both had serious issues. The data in Finance was never current so no useful reports were being taken from PeopleSoft. All finance reports were prepared in excel. HR too was in a mess, which was evident from the fact that no one was ever sure of the employee headcount in the company. So, though both modules were supposed to have been implemented and rolled out, no one trusted the data and all reporting was manual and "outside the system".

I will discuss how the derailed PeopleSoft HR implementation was set right in this article. How confidence was gained on the Financial PeopleSoft system is discussed in another case story.

Allegations were being made for the wrong selection and for improper implementation by the renowned international consulting PeopleSoft implementer who had implemented the ERP in the company. PeopleSoft had been implemented in all the global locations of the company. Most significantly, books had not been closed for three years globally on the system. Obviously, when the data on the system was not current or matching the reality, no useful reports were being derived from the system. All reporting and statutory books of accounts were produced using excel after extracting data from PeopleSoft and then manually changing the data.

Comments | Top

Challenges - Status When I Took Over

Soon after I had joined this company to head the Global Software department, the Country Head called me to his office. He had a few reports in front of him and said that the employee headcount data did not match in any of the reports. I came to know that he had three employee reports in front of him: one from PeopleSoft, one from the old HR system and one final report submitted by HR department. He said that the employee headcount data was different in all three of them and wanted an explanation from me.

I started investigating the cause of the discrepancy with the HR Head who was also in the room. After a lot of digging, the truth was revealed. I discovered that there was nothing technically wrong with the ERP system. The problem was with data discipline and process discipline. Here is what was happening:

It was found that, for whatever reasons, there was normally a delay of a few days in entering data into the Peoplesoft HR system. There were delays in entry of records for new employees and for transfers/resignations. So obviously the data on the system did not reflect reality. The HR department was extracting data from the system into excel spreadsheet and then correcting headcount figures to the extent of employee movements which were not yet entered in the system. All this data was in the head of the person who made the report on excel - if he remembered that three people had joined, but their particulars were not yet entered in the system, he would add three to the headcount. If there was one resignation and the data was not captured, he would reduce the headcount by one in the spreadsheet. You can imagine what would be the accuracy of the report submitted to the top management!

The headcount data was never reliable and manual corrections were made on system reports before circulation.

I said this was not the way you use ERP systems. There was something seriously wrong in the manual processes interfacing with the ERP system. I explained that the problem then was not with the ERP software, it was with the data discipline and process discipline.

I gently turned the table on the country manager himself. I asked him why he entertained three different reports from three different sources from HR department. I said that as country head, he should insist that he got one single report from HR department (straight out of the system and not from excel spreadsheeets), and that "it should bloody well be correct".

I said it is in his hands to ensure process discipline. He has to demand it. I said the HR department had to take full responsibility to ensure timely and accurate data entry. Having ensured that, if the output is incorrect, I am ready to take full responsibility for the error.

Comments | Top

Problem Analysis

I subsequently decided to closely examine these manual processes to investigate what led to delays and data inaccuracies.

There were three important people processes which were affecting the company and department headcounts:  New Joinees, Employee resignation, and Inter Department Transfers. Resignation entry was not an issue, but there were serious delays in entering new joinee and transfer data, due to which the system did not reflect reality. Each of the other two problem areas, i.e., delays in new employee entry and employee transfer entry required different approach to address. We will look at each of these processes separately.

New Employees

Most of the new joinees were trainees and they used to report in the training department. Their attendance was marked on the system and they had to log on to the intranet to mark attendance. As they did not have employee code (and hence the intranet user id), they were unable to log-in to the intranet to mark their attendance. I was told that a few months before I joined, it was decided that for 3 days after the employee joined, he need not mark his/her attendance. The attendance would be auto marked as present. Not the best solution, but may be they may have thought that 3 days was a short period to give as grace period. The policy change was incorporated through a software customization.

Soon it was discovered that 3 days were not adequate as new employee codes were still not entered in 3 days, so the auto attendance period was increased from 3 days to 5 days. When I joined, it was 5 days of auto attendance!

To top it all, one day I got a request from Training manager to increase this auto-attendance grace period from 5 days to 8 days. He said that the HR department was not entering the employee data even after 5 days and the new trainees were unable to mark their attendance. The person who was in charge of reporting the attendance figures to HR department complained that he had serious issues with new joinees as their employee codes were not assigned in 5 days. Hence the request to me to increase the grace period from 5 days to 8 days in the system.

I said we should not make a system inefficient because there is an inefficiency in some manual process. It would be wrong to modify a system to incorporate an inefficiency in the system. That way you reinforce the inefficiency and ensure that the inefficiency would never go. I declined to change the system, and instead, insisted that the process inefficiency must be removed.

I found that the Recruitment Department, which was part of the HR Department, was responsible for entering the new employee data and creating employee codes on time. I studied the process to understand why there were inordinate delays. I found that the recruitment department was too busy with the recruitment and also the new employee entry was a long and tedious process.

There were two HR Heads, one for recruitment and one for other HR operations, both located in two different premises. I went to the recruitment office to meet the HR Recruitment head and also called the other HR Head in the meeting.

The recruitment department said it was very difficult to enter all the data for new joinees. Some of the data relating to identity card and security card numbers was not even available for entry as it took time for the cards to be ready.

Recruitment team was too busy to enter all data.

Comments | Top

Plan Execution

New Employees Joining

In order to reduce the work of the Recruitment department, the employee record to be entered was split into two parts - one had the mandatory bare minimum data required to create a new employee record and employee code, and the second had the remaining data. The essential data required to create the Employee code was mandatorily entered in recruitment section on the day the employee joined. It was thus ensured that the employee code and employee record was created in the system on day one so that the new employees could log in to mark their attendance.

The remaining data was sent to main HR department to a different office (which in this case worked as back office operation) and they entered it. The main data had to be entered the same day and the other data now could wait for identity and security card details without affecting work. (Though, the card preparation work was also speeded up to ensure that the cards were ready on day one. However, the entry of the remaining employee data was no longer in the critical path and could be completed comfortably without affecting other essential work).

All manual processes to prepare and issue identity card, security card were also streamlined. Cobwebs in the process were removed to ensure that the primary data could be entered on same day and the cards could be issued to the new employees on day one. The secondary data entry was not so critical and could be completed at its own pace without affecting critical activities.

It was ensured that the loophole on the new employee record entry was plugged. The new employee now got his code, intranet id on the day of joining and could mark attendance online from day one! Moreover, the headcount data on PeopleSoft now reflected reality, at least with respect to new employees.

Transfers.

A proactive system was put in place instead of reactive system. Instead of the action happening first and then data being entered, it was made mandatory that all transfer approvals were done on the system and so when the transfer actually happened, the data was already in the system.

When process discipline was improved, the employee data on the system was now reliable so that the reports could reflect the reality on the ground.

Comments | Top

Lessons Learnt

• Most often, the problem is not in the application. It is not a technical issue but a process and process discipline issue. In this case, most of the issues were process and discipline related, though small modifications were made in the system to suit the modified optimized process (mini re-engineering of processes).
• Several IT professionals make changes to the system immediately based on customer requests without properly analyzing the root cause of the change request. Very often, if the root cause is analyzed, you may not need to make the change and instead you end up improving some processes. In this case, if the user request of extending the auto attendance from 5 days to 8 days was carried out without analyzing the cause, the process inefficiency would not have been discovered and corrected.
• The system should never be changed based on process inefficiencies. If it is changed, the process inefficiency gets reinforced and it is more difficult to remove the inefficiency later.
• Discipline has to be enforced from the top. People try to find ways to break the discipline initially as it looks easier. Only when discipline becomes a way of life, life becomes easier than it was when discipline was not there (which looked easier initially). Entropy is always preferred. In this case, the country manager could have enforced discipline by insisting on a single accurate computer generated report.
• The need for a skilled Change Management Expert should be recognized. You need an expert in IT-Driven Change Management, not just change management. This is a typical mistake most top management teams commit when they embark on ERP implementation project. They believe that any manager can lead a ERP project, and the skills of Change Management Expert are rarely engaged. That probably explains why there are 70-80% failures in ERP projects!

Comments | Top

Also See:

More Articles on Team Development
From Fresh Graduate Trainee to Expert
My Success Stories

Comments | Top | | Home