이 섹션의 내용을 기반으로, 구현 시작 전에 회사에서 수행해야 할 수 있는 구현 결정 리스트를 검토하고 이해관계자, 프로젝트 팀 및 SAP SuccessFactors 구현 컨설턴트와 논의하십시오. 이렇게 하면 구현을 시작하는 데 더 잘 대비할 수 있습니다.
1. 채용 역할 정의
결정: 채용 프로세스 전반에서 필요한 역할과 책임은 무엇이며 읽기 전용 액세스와 읽기/쓰기 액세스가 필요한 사용자는 누구입니까?
구현에 중요한 이유: 처음부터 명확한 역할을 구축하면 모든 사용자가 액세스할 수 있는 작업과 데이터를 이해하여 원활한 워크플로우 진행과 민감한 정보 보호를 지원합니다.
예: 조직에서 채용 담당자(전체 편집), 채용 관리자(읽기/편집 전용 후보자 데이터), 채용 코디네이터(면접 세부사항을 제외한 읽기 전용), 재무 검토자(예산 필드에만 읽기/쓰기 권한)라는 4가지 핵심 채용 역할을 구현하기로 결정합니다.
2. 채용 요청 템플릿 구성
결정: 채용 요청 템플릿에 포함되어야 하는 필드(예: 직무 기술서, 부서, 위치, 급여) 및 각 필드를 편집하거나 볼 수 있는 권한이 있는 역할은 무엇입니까?
구현에 중요한 이유: 포괄적이고 정확하게 권한이 부여된 작업 요청 필드를 통해 다운스트림 처리를 위해 필요한 모든 데이터를 캡처하고 권한이 있는 사용자만 변경을 수행하여 오류 및 규제 준수 문제의 위험을 줄일 수 있습니다.
예: 채용 요청 템플릿에는 포지션 직급, 부서 및 급여(HR에서만 편집 가능)에 대한 필수 필드가 포함되어 있고, 채용 관리자는 직무 기술서 및 위치만 입력할 수 있습니다.
3. 채용 요청 회람 맵 디자인
결정: 채용 요청은 생성부터 게시까지 승인 단계, 역할 및 라우팅 로직(예: 단일, 반복, 협업)의 어떤 순서를 따르는가?
구현에 중요한 이유: 맞춤형 회람 맵을 통해 요청을 적절히 검토하고 올바른 순서로 승인하여 병목 현상을 방지하고 조직의 규제 준수를 보장할 수 있습니다.
예: 채용 관리자가 요청을 처음 제출하고 예산 승인을 위해 재무 검토자에게 전달한 후 정책 준수를 위해 HR로 라우팅되고 마지막으로 채용 담당자가 채용 공고를 게시합니다.
4. 후보자 데이터 액세스 및 권한 설정
의사결정: 파이프라인의 각 단계에서 후보자 정보 및 지원 상태를 조회, 편집 또는 관리할 수 있는 사용자는 누구입니까?
구현에 중요한 이유: 후보자 데이터 액세스를 적절히 제어하면 민감한 정보가 보호되고 사용자 조치가 추적되며 승인된 직원만 오퍼 승인 또는 백그라운드 점검과 같은 주요 단계를 실행할 수 있습니다.
예: 채용 담당자 및 HR만 전체 후보자 프로파일을 보고 편집할 수 있으며, 채용 관리자는 개인 또는 보상 세부사항이 아닌 인터뷰 피드백 및 상태만 검토할 수 있습니다.
5. 지원자 상태 및 파이프라인 관리 구성
의사결정: 지원자는 인재 파이프라인에서 어떤 단계를 거치게 됩니까(예: 지원서 접수, 인터뷰, 오퍼 확장), 단계 간 후보자 이동을 담당하는 역할은 무엇입니까?
구현에 중요한 이유: 명확하게 정의된 상태와 책임 역할은 투명성, 효율적인 진행 상황 추적 및 선택 프로세스 전반에서 책임을 용이하게 합니다.
예: 채용 담당자의 "지원서 수신"에서 "전화 화면"으로 이동한 다음 채용 코디네이터의 "인터뷰"로 후보자가 이동하며, HR만 모든 승인을 받은 후 후보자를 "연장된 오퍼"로 이동할 수 있습니다.