You don't replace a system, you build it together How a major Korean energy company achieved company-wide HR system adoption

What were the biggest pain points with your previous system?

There were three main issues. First, since it had no mobile access, employee accessibility was a real problem. Second, the manual workload on HR practitioners: payroll and compensation involved so many exceptions that whenever the system couldn't process a case, we had to handle it manually through hard-coding or Excel uploads, and notices such as severance payment guidance or salary-peak announcements all had to be written and sent out one by one by the person in charge. Third, there were limits to providing meaningful data to management. The system was built in 2001, so it was over 20 years old, and during that time the company's size and policies changed a great deal, but the system couldn't keep up.

We heard you also considered a subscription-based solution. Why did you decide to build a system instead?

At first we seriously looked at global subscription-based solutions. But it turned out that customizing them to fit a large Korean enterprise's HR policies was practically impossible. The solution's representative even said, "If it can't be done, adapt your policies to the solution." Our HR policies simply aren't at a level where they can be bent to fit a solution, so we judged that direction wasn't right for us. We decided to build, and sent an RFI to five vendors to begin our review.

You compared several vendors. What was the decisive reason you chose hunel(휴넬)?

We had three evaluation criteria: whether the functional coverage was sufficient, whether the UX · UI was intuitive, and whether the build timeline and cost were realistic. When we actually compared them, the differences were bigger than expected. Many vendors had moved to subscription models specialized for small and mid-sized companies, and only one or two met both the coverage and the UX · UI requirements at an enterprise scale. hunel met those standards, and what set it apart was that it carries out consulting and implementation together. Since our requirements weren't simple, we needed a partner we could work alongside and adapt with. In the final bidding, they flexibly adjusted the cost, timeline, and maintenance terms, and our HR director, team leads, and practitioners all took part in the decision, and the opinions all pointed in the same direction.

What changed most in HR work after the implementation?

We didn't eliminate manual Excel work 100%, but the overall frequency of manual HR work dropped to about half of what it used to be, and notices like severance payment guidance and various alerts are now processed automatically from data within the system, greatly reducing the effort of writing each email by hand. We used to work late often during the payroll closing season in particular, but now being able to leave on time itself shows how much easier it has become.

You pushed for integration with the payment system. What inconvenience did you have before?

It wasn't part of the plan from the start. Honestly, it was just so tedious for me as the person in charge that I felt I had to do it. (laughs) Previously, whenever we needed to pay employees something, we had to go through at least seven steps: create a list in EHR → download it to Excel and verify → manually enter the amounts → convert it into the payment system's format and upload → get approval and move on to firm banking. The data was simply going back and forth, so I couldn't understand why the systems weren't connected. On top of that, there was actually a time when a wrong filter led to an incorrect amount being paid out. I felt something fundamentally had to change.

It must not have been easy to actually achieve that integration.

The payment system itself was outdated, and even its administrators had a hard time fully grasping the entire process. There were many stakeholders across tasks, so persuading one person meant having to meet yet another. We repeated the process of checking and persuading, reason by reason, for nearly three months. Once the integration finally went through, a chain of further integrations using that process opened up afterward. Now it's actually the team upgrading the payment system that asks us first what kind of system our HR system is. I'm glad we pushed it through to the end without giving up.

We're curious about employees' reactions after the mobile app launched.

There was a strong reason employees wanted mobile. For field technical staff, checking pay or requesting leave meant having to access the legacy system directly via a shared laptop. Now they can handle it right on their phones, so the convenience has changed dramatically. I also took three months of parental leave myself, and being able to apply to return to work from my phone even during leave was a relief. Team leaders are satisfied too, because they can immediately check an employee's HR information on mobile whenever they suddenly need it.

Before the full launch, you ran a company-wide "bug-finding event." How did you plan it?

During the soft-launch phase, we loaded virtual data and ran a "bug-finding event" in which people who found errors received a gift. The response was really great. They found all kinds of things, from minor typos to UI color mismatches, to a permission error in which executive information was visible to staff in other divisions. When the permission error was found, it was genuinely a close call. (laughs) Through that process, a perception spread among employees that "the team running this project has an open mindset," and the post-launch satisfaction survey came out quite well.

Was there anything else you paid special attention to while preparing for launch?

Honestly, I think a system that isn't intuitive enough, to the point where you have to distribute a manual to employees, is a failed system. So we didn't run separate training for general employees. Instead, we focused on building a structure where the menus matching each person's permissions are right there, and things just work when you click them. We also decided to push the launch back by a month, and I think having that buffer ultimately led to a stable rollout.

We'd love to hear how the system settled in internally after launch.

After stabilization there are almost no complaints, and I've heard a lot of positive feedback from our CEO and employees. But the most rewarding part is something else. Right now, several systems within the company are being developed even mimicking our HR system's UX and naming conventions. The payment system, and the internal ERP system as well, are being aligned to the same naming scheme and developed with the direction that "this is the level of experience we should provide." In a sense, the HR system has become the benchmark for the company's digital experience.

Based on this experience, what advice would you give to someone facing a similar HR system transition?

Composing the project team matters. If you split it into someone handling management reporting and communication and someone digging deep on the practical side, each gets an area to focus on and the whole project's pace changes. And someone who has actually handled a wide range of HR work must be on the task force. You need someone who can judge whether what a frontline manager says is a real pain point, and that's what changes the completeness of the build. Finally, the key to company-wide adoption is turning members from passive recipients into active participants. Just as we ran the bug-finding event, if you create opportunities for employees to experience the system directly and contribute to improvements, the post-launch atmosphere will be completely different.