HRCOACH AX METHODOLOGY
거대한 하나의 시스템이 아니라 프로세스와 문서로 된 업무 단위를 앱으로 만들고, 필요한 만큼 조립해 씁니다. HRcoach가 앱을 만드는 방식입니다.
CHAPTER 01
역량모델부터 교육 추천까지 이어지는 통합 e-HR을 구축했지만, 1년 뒤 아무도 쓰지 않는 시스템이 되었습니다.
작은 변화에도 거대한 시스템은 응답하지 못했고, 운영할 사람도 남아 있지 않았습니다.
“수많은 단일 프로세스로 정형화된 산출물을 내놓는 인사시스템은 실패하기 십상입니다. 시스템을 잘못 만들어서가 아니라, 인사 업무에 대한 고찰이 부족했기 때문입니다.”
많은 회사들에서 e-HR을 구축하거나 도입합니다만, 정말 구축/도입 후 만족한다는 곳은 많지 않은 듯 합니다. 요구사항이 많았던 것에 비하면 빡빡하고, 안돌아가고, 잘 안맞습니다. 비싸게 구축해도 그렇습니다. 아니, 비싸게 구축할수록 더 그렇습니다. 이건 왜 그럴까요? 제 경험에 비추어 한번 얘기해 보겠습니다.
벌써 한참 된 이야기이긴 합니다만, 통합 e-HR을 구축하면서 역량모델-역량진단-역량기반 학습과정 자동추천-IDP(자기개발계획) 수립-교육과정운영-운영결과 피드백 하는 LMS를 포함한 전체 시스템을 구축했습니다. 당시로서는 역량을 가지고 선발과 개발 모두에 활용하고, 거기에 교육과정 추천까지 연결하니, 그야말로 혁신적인 시스템이었습니다.
그런데 최종 PM이었던 제가 그 회사를 퇴사한 후 1년이후 들려온 이야기는, 아무도 이를 쓰지않고 운영할 인력도 없다는 소식이었습니다. (공교롭게도 저 이후 많은 이들이 퇴사를 하는 바람에 흐름이 단절됨) 중간에 조금의 변동, 방식의 전환이 필요한 부분에 대해, 이 거대한 시스템이 응답하지 않았기 때문에, 특히 이를 제대로 운영해 줄 인력이 남아있지 않아서 역사의 퇴물로 변한 것이었습니다. 정말 심혈을 기울여 만들었던 시스템이라 매우 가슴이 아팠던 기억이 납니다.
많은 구축형 인사시스템의 결과가 이랬습니다. 의욕적으로 인사컨설턴트가 정립해 시스템화한 부분들은 왜 그렇게 복잡하게 운영해야 하는지 이해도 안되었고, 이를 전문적으로 운영해 줄 사람도 없었으며, 특히 이를 사용하는 사람들의 불만으로 인해 새로 리뉴얼을 하거나 기능삭제를 하는 경우가 많았습니다. 그런데 이는 시스템을 잘 못 만들었다는 단순한 이유가 아니라, 인사업무에 대한 고찰이 부족했기 때문 아닐까.. 한참 후에 그렇게 생각하게 되었습니다. 수 많은 단일 프로세스로, 정형화된 산출물을 내놓는 인사시스템은 실패하기 십상이라 생각합니다.
CHAPTER 02
처음의 윤곽은 명확하지만, 예외·현업의 불만·에누리 같은 현실이 하나씩 들어오면 전체 균형이 무너집니다.
처음부터 완벽한 설계도가 없다면, 하나의 흐름으로 완벽한 하나의 시스템을 만들어서는 안 됩니다.
미술시간에 무엇을 만들 때, 처음에 기획했던 것도 좋았고, 대략 윤곽만 있었을 때는 제법 그럴 듯 했던 것들이 손을 대면 댈수록 이상해지거나 처음 의도했던 모습과 달라지는 걸 경험하신 적이 있었을 것입니다. 초기형태는 대체로 구축의 본질목적, 원칙 같은 것이어서 대체로 명확한 것이었는데, 자꾸 "현실" 이슈가 하나씩 들어오면서 이를 구현하려고 보니, 나중엔 이상한 모양이 되버리더라.. 하는 것입니다. 간혹은 예외도 있고, 현업의 불만도 있고, 에누리도 있고... 이를 반영하기 시작하니 시스템이 수용하기 어렵습니다.
생각해보면, 모든 일이 그렇고 시스템도 그렇습니다. 기본적으로 많은 시스템들이 나중에 리뉴얼을 하면서 편의성도 높이고, 보다 복잡한 형태로 세부기준을 추가로 산입해야 되는 경우도 발생하는데, 이는 처음부터 알 수가 없었던 부분입니다. 그러므로 처음부터 기획된 완벽한 조각 설계도가 있다면 모르지만, 그게 아니라면 하나의 흐름으로 완벽한 하나의 시스템으로 구축해서는 안됩니다.
CHAPTER 03
요청이 들어오면 참조 문서를 확인하고, 논의·판단을 거쳐 결과 문서를 남깁니다. 시스템에서 하든 손으로 하든 같습니다.
프로세스와 문서를 묶은 하나의 단위업무가 곧 하나의 AI 앱이 되고, 각 앱은 대체·확장·삭제할 수 있도록 모듈로 만듭니다.
※ 중간 업무를 수기 작성 문서로 대체해 후속 앱으로 이어가는 기능은 추후 제공 예정입니다.
관리업무는 보통 누군가의 신청, 요청, 지시, 이슈발생 시 시작하며, 이를 수행하기 위한 도메인 지식으로 기존 참조문서들이 존재하는 경우가 많습니다. 그리고 이를 근거로 논의, 협업, 처리, 분석 등을 거쳐 판단, 적용, 정리하는 단계에 이르렀다가, 이를 종합한 결과문서로 정리해 보고, 공유, 조치 등을 진행하는 대략적인 패턴을 가집니다. 말하자면 일(Task)은 온/오프라인 상의 프로세스와 각종 참조문서/산출문서(정보)로 구성될 수 있다는 얘기입니다.
시스템에서도, 각 프로세스가 있고, 이를 처리하여 정보(문서)를 남긴다는 점에서 동일합니다. 즉, 일이 시스템에서 일어나든, 수기로 진행하든 프로세스와 정보/문서의 연결로 파악될 수 있습니다. 프로세스와 문서를 묶어 놓으면 처리할 단위업무가 되는데, 우리는 이를 AI앱으로 만들 수 있습니다.
그런데 사실상 너무 복잡하거나, 오프라인의 업무가 많이 일어나는 일이면 시스템이 이를 모두 담을 수 없게 되는데, 결국 일부 과정은 수기 또는 임의의 정보를 입력해 중간처리하는 경우도 왕왕 있기 마련입니다. 우리는 이 부분까지도 인사AX의 영역이라 생각해서 가능하면 할 수 있는 데까지는 자동화해야 되며, 장기적으로 전체 영역에 대해 인사AX로 전환할 수 있도록 노력할 필요가 있습니다. 당연히 이렇게 해도 전환이 어려운 부분들은 별도의 프로세스를 거쳐 수기로 작성된 문서를 다음 프로세스로 넘겨 연결되도록 하는 체계로 구축되어야 하겠습니다.
때로는 상사나 경영자의 지시로 예외를 반영하거나, 별도 세부기준을 추가해 진행해야 하는 경우도 발생하는데, 이런 추가 프로세스는 중간단계의 프로세스를 대체하거나 Skip 하는 방향으로 진행될 수 있어야 합니다. 그래서 수정된 문서나 수기, 직접 작성한 문서정보를 별도로 이후 후속 프로세스로 전달해 이어지도록 하는 체계가 필요합니다. 말하자면, AX자체에서 하나씩 조립해서 전체를 만들되, 각각은 대체되거나 확장/삭제/조정이 될 수 있도록 모듈화 될 필요가 있다는 말입니다.
CHAPTER 04
인사의 출발은 직무 정보이고, 이는 채용·성과·보상·육성으로 흘러갑니다. 하지만 이 기초 데이터를 갖춘 회사는 많지 않습니다.
선행 문서가 없으면 담당자가 간단히 정리해 넘길 수 있도록, 각 단위를 독립된 Micro SaaS로 만듭니다.
인사AX 구축의 어려움은 위의 "변주" 내용만 있는 게 아닙니다. 전에 공유드렸던, 통합성과 일관성의 반영을 위한 핵심 컨텐츠의 부재도 큰 문제입니다. 인사의 시작은 사실 직무정보이며, 직무는 성과정보와 역량정보로 나뉘어, 각각 성과평가/성과급/복지와 내외부 선발/개발육성/퇴출 등의 근거로 사용됩니다.
그런데 이런 기본 데이터들이 갖춰져 있지 않은 곳도 많습니다. 이게 갖춰져 있지 않다고 해서 시스템을 사용하지 못한다면, 대한민국에 인사AX를 할 수 있는 곳은 몇 곳 되지 않을 것입니다. 흐름 중에 몇몇은 없더라도 흐를 수 있도록 구성되어야 합니다.
대략 위와 같은 흐름으로 데이터(정보, 문서)는 흐르게 됩니다. 사실은 이를 뜯어놓고 보면 좀 더 복잡해지며, 이 복잡해진 단위 하나하나가 각각 AX에서 구현해야 되는 업무프로세스/문서의 단위가 됩니다.
기본 직무정보로 부터 각 채용 프로세스 단위로 정보/문서가 각 프로세스에 반영되어야 하는데, 이 직무정보가 현업에 없는 경우에는 인사담당자가 임의로 간단히 정리해 넘길 수 있어야 합니다. 채용포지션 문서, 역량채용기준 문서, 채용평가표 문서, ATS문서 등등 각종 문서가 단위 프로세스의 산출물이며, 선행되는 문서는 후행문서의 참조자료가 됩니다. 가령 처우산정을 하기 위해서는 선행되었던 각종 직무 기준정보와, 채용합격자 개인정보, 회사 규정정보가 합쳐져야만 제대로 계산이 되게 됩니다.
우리는 상기의 내용에서 프로세스와 문서의 단위를 정형적으로 단일 시스템에서 사용하기 보다는, 각각의 모듈화된 형태(Micro SaaS)로 쓸 수 있도록 해야 하며, 어떤 예외적 상황에서는 이 모듈을 쓰지않고 수기로 간단히 정리한 문서를 이후 프로세스에 태울 수도 있어야 원활한 운영이 가능해집니다.
CHAPTER 05
주니어 채용담당자는 공고 운영·전형 일정 앱을, 시니어는 핵심인재 채널 관리·콜드메일 앱을 씁니다. 역할이 바뀌면 앱을 더하거나 빼면 됩니다.
원칙과 방향은 명확히 하되, 자동화를 해나가면서 표준화를 정립하는 것이 현실적인 길입니다.
※ 역할별로 앱을 모아 쓰는 개인 마이앱은 추후 제공 예정입니다.
위의 기본적 형태를 넘어서, 향후 구축된 인사AX로 일을 한다는 것을 상징적으로 표현한다면 아래와 같습니다. 인사담당자 홍길동은 회사에 출근해서 업무포털에 로그인해 마이앱 페이지에 들어갑니다. 거기에는 본인의 역할에 맞는 성과책임과 연관된 업무프로세스-산출문서로 정립된 단위모듈들이 정립되어 있습니다. 그리고 오늘의 현황을 보면서 처리해야 할 모듈단위를 클릭해 일을 AI를 통해 해나갑니다.
위에서 홍길동이 주니어라면, 본인의 마이앱 페이지에 공고운영AI앱, 전형일정관리AI앱 등이 들어가 있고, 이를 실행시켜서 신청된 각종 자료를 업로드하고, AI로 처리하면 됩니다. 시니어는 쓰는 앱 자체가 다릅니다. 주요인재 채널관리를 통해, 정기적으로 유입시켜야 할 외부 핵심인재에 자동 콜드콜메일링을 처리하는 등의 업무처리를 하게 됩니다. (그렇다고 주니어, 시니어가 사용하는 앱의 사용권한이 모두 엄격히 관리될 필요는 없고, 몇몇만 권한설정하면 됨) 말하자면, 인사의 각 업무모듈(프로세스+문서)이 성과책임에 맞게 조립되어 있고, 각자가 역할 변경 시 필요한 앱을 추가하거나 삭제해 사용할 수 있게 되지 않을까 합니다.
이전에 4단계 업무처리 AI앱에 대해 공유드린 적 있습니다. 업무처리를 하는 4단계에서도 일부 수동/수기 진행이 가능하도록 할 필요가 있다는 말씀을 드렸습니다. 인사를 겪어보니 워낙 변동성이 많아 단일시스템으로 하기 어렵기 때문입니다.
그런데 여기서 헷갈리지 말아야 할 부분이 있습니다. 매년 다르게 직원 연봉인상 방법론을 적용하면, 이는 시스템으로 절대 구현할 수 없습니다. 아니, 이렇게 한다는 것 자체가 인사의 방향이 없다는 말과 같습니다. 원칙과 방향은 명확해야 하고, 일관성도 유지해야 합니다. 잠깐 돌아가거나, 현실적으로 어려움이 있어 바꿔 진행하는 것은 괜찮지만 원칙도 없고 방법론도 없이 매양 달라지게 하는 것이라면 AX가 아니라, AX할애비가 와도 해결되지 못할 것입니다.
그렇다고 완전히 표준화를 한다음에 하라는 것도 아닙니다. 여건상 먼저 자동화를 해나가면서 표준화를 정립하고, 이것이 일관된 AX방향으로 종합되게 만드는 게 현실적인 대안이 될 것 같습니다.
거대한 시스템 대신,
오늘 필요한 업무 하나부터.
회사 규정을 올리면 판단과 근거 문서가 나오는 앱으로 시작해 보세요.