도입 전에 실제 업무와 예외를 정리하지 않으면 시스템은 수작업을 복제합니다
새 인사시스템을 도입하면 반복 입력이 줄고 데이터가 한곳에 모일 것이라 기대합니다. 그런데 오픈 뒤에도 기존 엑셀을 유지하고 같은 정보를 여러 화면에 입력하며 시스템이 처리하지 못한 예외를 수작업으로 보정하는 경우가 많습니다. 기능이 부족해서만은 아닙니다. 도입 전에 실제 업무의 흐름과 책임, 데이터 기준을 정리하지 않은 채 기존 절차를 그대로 옮겼기 때문입니다. 시스템은 모호한 일을 스스로 단순하게 만들지 못합니다.
중복 입력은 시스템 수보다 기준의 분리에서 생깁니다
조직 정보는 인사시스템, 비용센터는 회계시스템, 권한은 그룹웨어에 있고 변경 시점과 담당자가 다르면 같은 사실을 여러 번 입력하게 됩니다. 연동 기능을 추가하기 전에 어느 시스템이 원천인지, 변경을 누가 승인하고 언제 다른 시스템에 반영할지 정해야 합니다. 원천이 둘이면 자동 연동도 충돌을 빠르게 전달할 뿐입니다.
개통 직후에는 문의 건수만 세지 말고 사용자가 어느 단계에서 우회하는지 관찰해야 합니다. 입력을 포기하고 이메일로 보내거나 화면 값을 별도 메모에 적는 행동은 사용성보다 책임과 데이터 정의의 문제가 있을 수 있습니다. 현장의 우회로가 개선 우선순위를 알려줍니다.
사용자가 별도 파일을 만드는 이유를 무조건 저항으로 볼 수도 없습니다. 시스템 보고서가 필요한 기준일을 지원하지 않거나 예외의 맥락을 담지 못해 보조 자료가 필요할 수 있습니다. 실제 업무에서 어떤 정보를 왜 다시 가공하는지 관찰하면 기능 요구와 데이터 문제를 구분할 수 있습니다. 숨은 엑셀은 시스템 실패의 증거가 아니라 개선 방향을 알려주는 흔적입니다.
좋은 인사시스템은 모든 일을 화면 안에 가두는 시스템이 아니라, 같은 정보를 한 번만 정확히 입력하고 다음 판단으로 이어지게 하는 시스템입니다.
예외를 무시하면 가장 바쁜 순간에 수작업이 폭발합니다
휴직 중 복귀, 겸직, 소급 발령, 해외 파견처럼 빈도는 낮지만 영향이 큰 사례를 표준 흐름 밖으로 밀어두면 담당자는 메모와 별도 파일로 관리합니다. 모든 예외를 기능으로 만들 필요는 없지만 누가 승인하고 어디에 기록하며 원 데이터에 어떻게 반영할지는 정해야 합니다. 예외 처리 화면이 없더라도 추적 가능한 절차는 있어야 합니다.
프로젝트 일정이 빠듯할수록 정상 사례만 테스트하기 쉽습니다. 그러나 실제 운영 부담은 경계 사례에서 생깁니다. 현업 담당자가 과거에 가장 오래 걸렸던 사례와 오류가 많았던 상황을 가져와 시험하도록 해야 합니다. 실패한 테스트를 일정 지연으로만 보지 않고 설계의 빈틈을 발견한 성과로 보는 태도가 필요합니다.
운영 조직과 개발 조직의 역할도 이어져야 합니다. 작은 수정마다 프로젝트를 새로 시작하면 현장은 불편을 포기합니다. 오류와 개선 요구를 분류하고 영향과 빈도에 따라 우선순위를 정하며 반영 여부를 설명하는 상시 운영 구조가 필요합니다.
사용자 교육보다 역할과 책임의 변화가 먼저 설명되어야 합니다
버튼 위치를 알려줘도 누가 데이터를 책임지는지 불분명하면 입력은 늦고 오류는 HR로 돌아옵니다. 관리자와 직원이 직접 입력할 항목, HR이 검증할 항목, 시스템이 자동 계산할 항목을 구분하고 변경된 책임을 설명해야 합니다. 시스템 도입은 IT 프로젝트가 아니라 조직의 업무 분담을 다시 정하는 변화입니다.
시스템이 일을 늘렸다면 사용자가 익숙하지 않아서라고 결론 내리기 전에, 시스템이 불명확한 프로세스를 그대로 디지털화한 것은 아닌지 살펴야 합니다.
도입 성공은 로그인 수나 기능 개통으로 판단하기 어렵습니다. 중복 입력과 재작업이 줄었는지, 오류를 발견하고 고치는 시간이 짧아졌는지, 데이터 기준이 일관되어졌는지를 봐야 합니다. 새 기능을 계속 추가하기보다 사용되지 않는 단계와 불필요한 승인을 덜어내는 것도 개선입니다. 실제 업무를 먼저 이해하고 원천 데이터와 예외, 책임을 정리할 때 인사시스템은 일을 옮기는 도구가 아니라 일을 줄이는 기반이 됩니다.