HR 시스템의 사용자는 누구인가

그리고 생산자는 누구인가

지난 글에서 HR 시스템은 조직이 사람을 어떻게 보는지를 코드로 옮긴 결과물이라고 썼다. 그렇다면 질문을 하나 더 던져볼 수 있다. 그 코드는 누구의 손에 쥐어지는가.

기능 목록을 세어보면

아무 HR 시스템이나 골라 기능 목록을 펼쳐놓고 세어보자. 인사 담당자가 쓰는 기능은 쉽게 수십 개를 넘는다. 조직 관리, 발령, 급여 계산, 근태 마감, 평가 운영, 교육 이수 관리, 각종 통계와 보고서. 화면 하나하나가 촘촘하다.

임직원이 쓰는 기능은 몇 개인가. 급여명세서 확인. 휴가 신청. 재직증명서 출력. 연말정산 자료 제출. 열 손가락을 다 접기도 전에 끝난다.

시스템의 이름은 ‘인사 시스템’이고, 회사에는 인사 담당자보다 임직원이 압도적으로 많다. 그런데 기능의 무게중심은 정반대에 놓여 있다.

이상한 일은 아니다. 애초에 이 시스템의 목적이 ‘인적자원의 관리’였기 때문이다. 관리하는 쪽을 위한 도구인 것이 당연했다.

체류 시간이라는 잘못된 질문

그래서 임직원에게 HR 시스템은 한 달에 몇 번 열지 않는 시스템이다. 여기서 이런 질문이 나올 법하다. 임직원이 HR 시스템에 더 오래 머물게 만들어야 하는가.

나는 이 질문이 틀렸다고 생각한다.

체류 시간은 광고를 파는 서비스의 지표다. 오래 머물수록 노출이 늘고 수익이 나는 구조에서나 의미가 있다. 업무 시스템은 그 반대다. 휴가 신청에 3분 걸리는 시스템보다 30초 걸리는 시스템이 낫다. 급여명세서를 찾는 데 화면을 네 번 넘겨야 하는 시스템보다 한 번에 보여주는 시스템이 낫다. 오래 머물렀다면 그건 대개 불편했다는 뜻이다.

다만 한 가지는 짚어야겠다. 지금 임직원 화면이 간결한 것은 잘 설계했기 때문이 아니다. 대부분의 HR 시스템에서 임직원 화면은 짧으면서 동시에 불편하다. 짧은 이유는 절제해서가 아니라 만들어두지 않았기 때문이다. 의도된 간결함이 아니라 방치된 결과다.

그러니 질문을 바꿔야 한다. 얼마나 오래 머무는가가 아니라, 머무는 동안 무엇을 하는가로.

소비하는 사람과 생산하는 사람

임직원이 HR 시스템 앞에서 하는 일을 분해해 보면 세 가지로 정리된다.

요청한다. 조회한다. 제출한다.

셋에는 공통점이 있다. 요청은 승인을 기다리며 끝나고, 제출은 마감에 쫓겨 이루어지고, 조회는 이미 결정된 결과를 확인할 뿐이다. 임직원은 이 시스템에서 아무것도 만들지 않는다.

반면 담당자는 만든다. 조직도를 만들고, 직무 체계를 만들고, 평가 기준을 만들고, 제도를 만든다. 생산이라는 행위는 오랫동안 담당자 권한을 가진 소수의 전유물이었다.

여기서 지난 글의 이야기와 만난다. 실무에서 임직원 화면은 담당자 화면의 권한 제한 버전인 경우가 많다. 같은 데이터 모델 위에서 보이는 필드만 줄인 형태다. 조직장은 승인 버튼이 하나 추가된 임직원이고. 역할이 곧 행위의 성격을 결정하도록 설계되어 있는 것이다.

이건 권한 설정의 문제가 아니다. 시스템이 사람을 나누는 방식의 문제다.

셀프서비스라는 함정

그렇다면 임직원에게도 만들 수 있는 기능을 주면 되는가. 조심할 부분이 있다.

이미 한 번 시도된 적이 있기 때문이다. 1990년대 후반에 등장해 2000년대에 확산된 ESS(Employee Self-Service)가 그것이다. 인사팀이 대신 입력해주던 개인정보를 임직원이 직접 고치게 되고, 근태를 직접 등록하게 되고, 연말정산 서류도 직접 올리게 됐다.

무엇이 넘어갔는가. 일이 넘어갔다. 권한이 아니라.

그래서 ‘임직원에게도 생산 기능을 주자’는 말은 자칫 ‘인사팀 일을 임직원에게 떠넘기자’로 읽힐 수 있다. 구분이 필요하다.

기준은 하나다. 그 산출물은 누구의 것인가.

임직원이 근태를 입력하는 건 회사의 기록을 위한 입력이다. 노동만 이전됐을 뿐 결과물은 회사가 가져간다. 반면 임직원이 남긴 기록이 본인의 자산이 된다면 이야기가 다르다. 같은 ‘입력’이라도 소유의 방향이 반대다.

연말이면 반복되는 장면

구체적인 예를 하나 들어보자.

평가 시즌이 오면 대부분의 직장인이 같은 자세를 취한다. 빈 입력창을 띄워놓고 지난 1년을 거슬러 올라가는 것이다. 3월에 뭘 했더라. 그 프로젝트가 언제 끝났지. 메신저를 뒤지고, 메일함을 뒤지고, 캘린더를 뒤진다. 결국 기억나는 몇 개만 적는다. 기억나는 것과 중요했던 것이 같지 않다는 걸 알면서도.

이 고통의 원인은 명확하다. 1년 치 기억을 한 번에 소환해야 하기 때문이다.

그런데 정말 그 1년 동안 아무것도 남지 않았을까. 남았다. 완료한 업무가 있고, 참여한 프로젝트가 있고, 주고받은 피드백이 있다. 다만 HR 시스템이 그것을 받아두지 않았을 뿐이다.

여기서 수시 기록이라는 대안이 나온다. 연말에 몰아서 쓰는 대신 평소에 조금씩 남겨두는 것. 타당해 보이지만 반론도 분명하다. 그것도 결국 일이 늘어나는 것 아닌가. 실제로 주간보고나 업무일지를 도입했다가 형식적인 문서 작업만 늘어난 조직이 적지 않다.

그래서 방향은 ‘더 쓰게 하는 것’이 아니라 ‘이미 있는 것을 모으는 것’이어야 한다고 생각한다. 임직원이 일하면서 자연스럽게 남긴 흔적을 시스템이 주워 담고, 임직원은 그것을 확인하고 다듬기만 하면 되는 구조. 생산의 부담을 지우지 않으면서 생산의 결과를 갖게 하는 방식이다.

이렇게 보면 주장이 조금 달라진다. 임직원에게 기능을 더 주자는 이야기가 아니다. 임직원이 이미 만들어낸 것을 시스템이 왜 계속 버리고 있는가라는 이야기다.

다시, 사용자는 누구인가

이렇게 쌓인 기록은 평가에만 쓰이지 않는다. 본인의 경력 정리에 쓰이고, 다음 목표를 세우는 근거가 되고, 때로는 이 회사를 떠날 때 함께 간다. 회사 입장에서 불편한 이야기일 수 있다. 하지만 그것이 자산의 정의다. 가져갈 수 없다면 자산이 아니다.

체류 시간으로 돌아가 보자. 이런 시스템에서 임직원의 체류 시간은 늘어날 수도 있다. 하지만 그건 목표가 아니라 결과다. 머물 이유를 만들어줬기 때문에 머무는 것이고, 그 이유는 여기에 만들어둔 것이 있기 때문이어야 한다.

HR 시스템의 사용자는 누구인가. 답은 이미 정해져 있다. 회사의 모든 사람이다. 진짜 질문은 그다음이다. 그 사람들 중 몇 명이 이 시스템 안에서 무언가를 만들 수 있는가.




Enjoy Reading This Article?

Here are some more articles you might like to read next:

  • HR시스템은 사람을 무엇으로 보고 있을까?
  • Dynamic Form Submit
  • Dynamic Form Search - Refactoring
  • Dynamic Form Search with Spring Boot + Thymeleaf