|BACK | Key Success Factors | IT for Business | people issues in IT | other articles on IT | My IT Strategy | Download articles|
People and Process Issues in ERP Implementation
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.
took over the PeopleSoft implementation as Head of
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
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
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".
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 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.
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.
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.
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.
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).
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.
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).
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
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
project, and the skills of Change Management Expert are rarely engaged.
That probably explains why there are
70-80% failures in ERP projects!
HomeFrom Bench to COE