왜 HRIS는 실패한 것으로 보일까?

by 미르

새로운 HR 시스템에 대한 현업 HR 담당자들의 후기를 찾아보면 가장 많이 듣게 되는 말은 "기대한 것만큼 기능이 편하지 않다.", "왜 이렇게 불편한지 모르겠다."이다. 하지만 정말 HRIS 프로젝트 프로젝트들은 대부분 실패한 것일까 아니면 실패한 것처럼 보이는 구조 속에 우리가 놓여있던 것일까?


여러 기업들의 HRIS 프로젝트들은 '성공적'으로 마무리되었다고 경영진에게 보고되거나 외부에 홍보하는 경우가 많다. 실제 시스템은 정상적으로 오픈되었고 데이터도 이관되었으며 직원들의 신규 계정도 문제없이 생성되었다. 하지만 프로젝트가 끝난 이후 HR 조직 내부에는 불만이 쌓이면서 시스템 사용을 회피하기 시작한다. 그리고 어느 순간부터 '이 시스템을 구축한 것은 실패한 사례다.'라는 평가가 자연스럽게 내려진다. 이는 HRIS 시스템에 대한 현업의 기대와 HR의 역할에 대한 오해가 있기 때문이다.





[1] HRIS는 업무 자동화가 아닌 업무 기준을 자동으로 실행해 주는 시스템이다.


HRIS 프로젝트가 시작되면 현업에서 가장 크게 기대하는 것은 '업무의 자동화'이다. 엑셀 작업과 수작업이 감소하고 복잡한 업무나 보고를 시스템이 대신 처리해 줄 것이라는 기대를 매우 자연스럽게 가진다. 하지만 이 기대가 HRIS 프로젝트가 실제로 실패하지 않았음에도 불구하고 마치 실패한 것처럼 현업이 생각하도록 만드는 첫 번째 오해이기도 하다.


HR 시스템은 RPA처럼 단순 업무를 자동화해 주는 도구가 아니다. HRIS의 본질은 업무를 대신 판단해 주는 것이 아니라, HR 업무가 어떤 기준으로 처리되어야 하는지 정의된 기준을 강제해 주는 것에 가깝다. 시스템은 담당자를 대신해서 판단해주지 않는다. 어떤 상황이 예외적이며, 어떤 정보를 Master 정보로 관리하고 저장할지, 그리고 업무의 기준은 언제부터 유효하게 적용되는지를 모두 사람이 결정하고 따르는 것이다. HRIS는 그 판단의 결과를 구조화하여 반복적으로 실행하고 보여줄 뿐이다.


바로 이 지점에서 많은 현업 HR 담당자들은 당황하게 된다.

"이건 시스템이 알아서 처리해 주는 것이 아닌가요?"

"왜 이런 기준까지 우리가 정해야 하나요?"

"예외적인 상황을 반영할 수 있는 우회 경로는 없나요?"


특히 Workday를 포함한 SaaS 기반 HRIS를 사용하면서 더욱 분명하게 드러난다. 이러한 질문은 HRIS가 제공하는 것이 '판단을 대신해 주는 자동화'가 아니라 '합의된 판단을 반복적으로 실행해 주는 자동화'란 사실을 인지하지 못하면 발생한다. 앞서서 언급한 것처럼 과거 온프레미스 환경에서는 HR이 "이렇게 쓰고 싶다"라고 말하면 IT부서나 개발자가 이를 해석해서 시스템에 구현했다. HR은 필요한 요구사항을 전달하면 후속 작업은 모두 IT의 책임이었다. 하지만 SaaS HRIS을 사용할 때는 이러한 역할 분담이 성립하지 않는다.



그러므로 프로젝트 초기에 'HRIS가 제공하는 자동화'에 대한 전제가 제돌 공유되지 않고서 시스템을 도입하면, 아무래 완성도 높게 구축된 시스템이라도 현업에게는 "생각보다 불편한 시스템"으로 인식될 수밖에 없다. 그래서 HRIS 프로젝트의 성패는 새로운 기능의 제공이나 자동화의 수준이 아닌 HR이 운영 기준을 정의하고 이를 책임질 수 있는지에 따라 결정된다.





[2] '우리 회사의 방식'을 계속 요구하는 순간, 시스템의 기반은 흔들릴 수 있다.


HRIS 프로젝트가 본격적으로 시작되면 현업의 요구사항 앞에 거의 예외 없이 등장하는 문구가 있다.

"기존에 이렇게 해왔으니 그대로 구현해 주세요."

이러한 요구 자체가 잘못된 것은 아니지만, 시스템의 이해보다 앞서서 등장할 때는 다소 난감하다.


특히 글로벌 표준을 기준으로 설계된 Workday를 도입하면서 이 문제는 두드러지게 발생한다. Workday의 구축 가이드를 읽어보면 "어떤 회사이든 최소한 이 정도의 공통된 HR 기준을 가지고 있을 것"이란 가정이 전제되었음을 추정할 수 있다. 그런데 프로젝트 초반부터 "우리 회사는 예외"라는 전제가 반복되기 시작하면, HRIS 프로젝트는 시스템을 이해하고 수용하기보다는 시스템을 현업에게 설득시키는 프로젝트로 변질되기 쉽다.


종종 '우리 회사의 방식'을 지키는 것이 그들의 전문성을 돋보일 수 있다고 생각하는 현업 HR 담당자들이 있기도 했다. 하지만 실제로는 반대인 경우가 적지 않았다. 과거부터 오래 유지되어 왔거나 지금 그렇게 업무를 수행하고 있다는 이유만으로 관행이 되었을 뿐, 왜 그렇게 운영했었는지 설명하지 못하는 경우가 많았다. 과거 데이터들을 추적해서 확인하면 예외적인 상황이 발생했을 때마다 담당자의 경험과 판단으로 처리 방식이 달라졌다. 그로 인해 운영 기준이 문서화되지 않은 경우가 많은 상태가 정착되었고, 이런 상태에서 '기존 방식을 그대로'를 수용한다면 시스템은 점차 복잡해질 수 있다.


하지만 Workday는 이러한 모호함을 허용하지 않는다. 조직의 기준은 무엇이고 하나의 이벤트는 누가 시작하고 마무리하는지와 같은 질문을 던지며 Workday는 반드시 명확한 답변을 요구하고 시스템에 반영하기를 요구한다. "상황에 따라 다를 수 있다"는 답변은 비즈니스 프로세스(Business Process)와 관할조직(Supervisory Organization)이란 기본 개념/구조 안에서는 존재할 수 없다. 그래서 과거에 '유연한 업무 처리'로 여겨졌던 것들이 오히려 '명확한 기준 없이 처리했던 것'으로 드러날 수 있다.


이 지점부터 프로젝트 담당자에겐 두 가지 선택지가 존재하게 된다. 먼저 HR이 고수하는 기존 업무 방식을 그대로 유지할 수 있게 Workday를 예외 처리와 우회 설계를 중심으로 구축하는 것이다. 그러면 처음에는 '우리 회사에 맞는 커스터마이징'처럼 보일 수 있지만 이러한 선택들은 시간이 지나면 운영 부담으로 돌아온다. 단순한 하나의 변경으로 인한 연쇄적인 영향이 발생하고, 새로운 담당자가 구조를 이해하는데 오랜 시간이 필요하다.


반면에 어떤 기준을 그대로 유지하고, 어떤 관행은 버릴 것인지, 어떤 예외를 프로세스에 흡수할 것인지를 대해여 명확한 판단을 내린 다음에 Workday에 구축하는 방법도 있다. 그러면 프로젝트 담당자들은 Workday에 대한 이해를 해야 하는 과제와 함께 기존의 업무를 분석하고 재정의하는 막대한 업무 부담이 발생해도 결과물은 첫 번째 선택에 비해 안정적으로 작동할 것이다.


결국 Workday 프로젝트에서 필요한 것은 '우리 회사 방식 중 무엇을 버리고 무엇을 기준으로 삼을 것인가?'를 생각하는 것이다. 이 질문에 답하지 못한 상태에서 프로젝트를 진행하면 시스템은 복잡해지면서 Workday는 불만의 대상이 된다. 반대로 이 질문을 정면으로 해결한다면 Workday 프로젝트를 계기로 기준을 정리하면서 HR의 업무 수준을 한 단계 끌어올릴 수 있을 것이다.





[3] HRIS의 실패는 구축이 아니라 '운영으로 전환되는 순간'부터 시작된다.


많은 HRIS 프로젝트들은 구축 단계까지만 보면 '무사히 끝났다'라고 평가하곤 한다. 주요 기능들을 구현하고서 일정 수준의 테스트를 통과하고 사용자 교육까지 마무리했기 때문이다. 그러나 HRIS 프로젝트가 실패한 것으로 인식되는 시점은 대부분 대부분 이 이후다. 시스템이 실제 운영 단계로 넘어가고, HR과 현업이 사용하기 시작하는 순간부터 균열이 드러난다.


가장 첫 번째로 흔한 패턴은 앞서서 언급한 것처럼 '기준이 정리되지 않은 상태로 시스템을 오픈한 경우'다. 구축 과정에서는 컨설턴트의 가이드에 따라 설계한 구조가 '정답'처럼 보인다. 하지만 운영으로 들어간다면 '이 경우는 어떻게 처리해야 하죠?", "이건 예외가 아닌가요?"라는 질문이 끊임없이 발생한다. 만약 이 상황에서 담당자들의 판단에 따라 처리 방식과 답변이 달라진다면, 시스템은 점차 일관성을 잃어갈 것이다.


두 번째 패턴은 운영 부담이 특정 개인에게 집중되는 구조이다. 구축 과정에서 가장 적극적으로 참여했던 담당자 또는 시스템 구조를 잘 이해한 HR 한두 명에게 모든 판단과 업무가 몰린다. 시스템 오픈한 초기에는 "어쩔 수 없는 과도기"로 받아들여질 수 있지만, 이 구조는 고착화되면 많은 위험을 내포하고 있다. 담당자가 퇴사를 하거나 잠시 자리를 비우는 순간 시스템 운영은 멈출 수 있다. 이때 사람에 의존하는 것을 피하기 위한 시스템을 결국 사람에게 의존하고 있다는 사실을 조직은 비로소 깨닫게 된다.


세 번째 패턴은 역할의 혼선이 발생하는 것이다. 구축 단계에서는 HR과 IT, 컨설턴트의 역할이 비교적 명확하다. 하지만 운영 단계로 넘어가면 경계가 흐려진다. HR은 "시스템이 이렇게 되어 있어서 어쩔 수 없다"라고 말하며, IT는 "운영 기준은 HR에서 정해주어야 한다"라고 답한다. 점차 현업은 "왜 이렇게 불편해졌느냐"라고 묻게 된다. 이 삼각관계 속에서 누군가 최종 판단을 내리지 않는다면, Workday는 관리하기 어려운 시스템으로 낙인찍힌다.


마지막이자 최악의 패턴은 기존 방식으로 회귀하는 것이다. Workday에서 처리하는 것은 낯설고 시간이 걸리며 번거롭다는 이유로 일부 업무가 다시 엑셀이나 메일로 돌아간다. 처음에는 "급한 건 일단 이렇게 처리하자"는 임시 조치였지만 곧 관행이 될 수 있다. 그러다 보면 HRIS에 저장된 데이터와 실제 운영 데이터의 사이에 차이가 발생하면서 어느 것이 '정답'인지 모호해진다. 이 순간부터 Workday는 신뢰를 잃고 참고용 데이터만 제공하게 된다. 그리고 의사결정은 다시 사람의 기억과 가공된 자료에 의존하게 된다.




이전 04화Workday를 감당할 수 있는가?