EWA 공급업체 선택을 위한 RFP 샘플: 60가지 평가 기준

EWA 공급업체 선택을 위한 RFP 샘플: 기업이 평가해야 할 60가지 기준

EWA 공급업체 선택을 위한 RFP는 근무한 시간, 승인 권한, 사용 가능한 금액, 은행 지출에서 급여 대조까지 전체 체인을 평가해야 하며, 단순히 인터페이스와 수수료만 비교해서는 안 됩니다. 아래 샘플은 기업이 모든 공급업체에게 동일한 질문을 하고, 증거를 요구하며 중요도에 따라 점수를 매길 수 있도록 도와줍니다.

> 간단히 말해: RFP는 10개의 그룹과 60개의 기준, 필수 조건 및 가중치 점수로 구성되어야 합니다. 각 답변은 명확히 기록되어야 합니다: 사용 가능, 구성 필요, 개발 필요 또는 불가능; 또한 증거로 문서나 데모를 첨부해야 합니다.

> 사용 주의: Nguyen Minh Khang — Chuyên viên ban chiến lược, 일당 선지급이 모든 기준을 충족한다고 보장하지 않습니다. Nhan Kiet은 실제 RFP에 참여할 때 각 항목에 대해 현재 증거로 답변해야 합니다.

1. EWA RFP는 일반 인사 소프트웨어 RFP와 어떻게 다른가요?

(더 보기: EWA 공급업체 선택 체크리스트 및 기업이 EWA 공급업체를 평가하는 기준.)

EWA는 인사 데이터, 출퇴근 기록, 급여, 개인 데이터 및 송금과 동시에 관련이 있습니다. 표시 오류는 단순히 불편을 초래할 수 있지만, 거래 상태 오류나 승인된 근무 시간 오류는 실제 금액 차이를 초래할 수 있습니다.

따라서 RFP는 다섯 가지 핵심 능력을 점검해야 합니다:

1. 미래의 근무 시간이나 승인되지 않은 근무 시간에서 수익을 창출하지 않음.
2. 잘못된 사람에게, 잘못된 계좌로 또는 중복 거래를 하지 않음.
3. 사용 가능한 금액의 모든 금액을 설명할 수 있음.
4. 은행 및 급여와 거래를 대조할 수 있음.
5. 개인 데이터를 보호하고 사고 발생 시 서비스를 유지할 수 있음.

공급업체가 이 다섯 가지 중 하나라도 증명하지 못하면, 기업은 아름다운 인터페이스나 낮은 수수료로 점수를 보충해서는 안 됩니다.

2. 공급업체에게 답변을 요구하는 방법

각 기준은 여섯 개의 열로 구성되어야 합니다:

답변 필드	내용
응답 수준	사용 가능 / 구성 필요 / 개발 필요 / 불가능
설명	기능 또는 프로세스 작동 방식
증거	문서, 스크린샷, 데이터 로그 숨김, 데모 또는 보고서
예외	기능이 작동하지 않거나 수동 작업이 필요한 조건
시간	구성/개발이 필요한 경우 준비 시간
비용	포함된 비용과 추가 비용

단순히 “있음”이라는 답변은 허용되지 않습니다. 개발이 필요한 경우, 공급업체는 범위, 승인, 기한 및 지연 시 책임을 명시해야 합니다.

3. 점수 체계 및 탈락 조건

0–5 점수 체계

점수	의미
0	불가능하거나 응답 없음
1	방향만 있고, 계획/증거 없음
2	상당한 개발이 필요하거나 확인되지 않은 제3자에 의존
3	구성 후 가능, 계획 및 책임자 있음
4	사용 가능, 데모 가능 및 문서 있음
5	사용 가능, 운영/통제 증거 및 측정 가능한 지표 있음

제안된 탈락 조건

• 완료되지 않은 근무 시간/승인되지 않은 근무 시간을 차단하지 않음;
• 중복 지출 방지 메커니즘 없음;
• 수신 계좌 인증 없음;
• 근무 시간 수정 및 거래 상태 로그 저장 없음;
• 수령한 금액을 급여에 연결하지 않음;
• 개인 데이터 처리 역할 식별 없음;
• 심각한 사고 처리 절차 제공 없음;
• 자금 흐름의 법적 본질 및 관련 당사자 설명 불가.

탈락 조건은 감정에 따라 기준을 변경하지 않도록 서류를 열기 전에 승인되어야 합니다.

4. 그룹 1 — EWA 비즈니스 및 근로자 경험 (8가지 기준)

1. 완료되고 승인된 근무 시간에서만 가치를 계산.
2. 아직 마감되지 않은 현재 날짜와 미래 날짜 차단.
3. 사용 가능한 금액과 설명 가능한 공식 표시.
4. 근무일, 수령한 금액 및 보류된 금액 세부 정보 표시.
5. 근로자가 조건을 충족하면 각 명령을 승인할 필요 없이 요청할 수 있도록 함.
6. 각 수령 전에 확인/동의 단계가 있음.
7. 거래 상태를 명확히 표시: 대기, 성공, 실패, 조사 필요.
8. 잘못된 서류, 잘못된 근무 시간 또는 미수령 시 지원 채널 제공.

요구해야 할 증거: 승인된 근무일에서 거래까지의 데모; 승인되지 않은 근무 시간의 데모; 거래 내역 및 약정 내용 샘플.

일당 선지급 시스템에서 공식은: 승인된 근무 시간 × 고객별 일당 단가 − 해당 기간에 수령한 금액 − 보류된 금액, 1,000원 단위로 내림. 이는 코드에서 확인된 정보이며, 각 고객에 대한 정책은 여전히 확인되어야 합니다.

5. 그룹 2 — 출퇴근 기록, 근무 승인 및 예외 (7가지 기준)

1. 고객 시스템, ERP 또는 앱에서 데이터 수신.
2. 다양한 근무표 및 자정 이후 교대 지원.
3. 근로자와 근무 시간 코드 간의 안정적인 연결 제공.
4. 근무 시간 보기, 수정, 승인 및 거부 권한 부여.
5. 승인된 근무 시간 수정 시 검토 필요 상태로 돌아가야 함.
6. 전/후 로그, 수정자 및 시간 기록.
7. 교대 변경, 전환, 퇴사 및 수령 후 근무 시간 감소에 대한 절차 제공.

필수 데모 시나리오: 승인된 기록을 수정하고 규칙에 따라 사용 가능한 금액이 다시 계산되는 것을 증명; 이전 흔적 삭제 금지.

일당 선지급 시스템은 현재 고객이 /kh 포털에서 작업할 수 있도록 지원하며, 고객 또는 Nhan Kiet 감독자가 권한에 따라 승인할 수 있습니다. 각 기업의 다단계 승인 프로세스와의 적합성은 별도로 테스트되어야 합니다.

6. 그룹 3 — 법적 및 계약 관리 (6가지 기준)

1. 계약 체결 법인 및 서명 권한 식별.
2. 모델의 본질 및 상계 메커니즘에 대한 법적 분석 제공.
3. 근로자와의 계약, 앱 및 커뮤니케이션 간의 일치된 조항.
4. 수수료 정책, 수수료 부담자 및 변경 조건의 투명성.
5. 잘못된 근무 시간, 잘못된 사람, 중복 지출 또는 회수 불가 시 책임.
6. 불만 처리, 서비스 종료 및 분쟁 해결 절차.

기업은 “대출이 아님”이라는 문구를 법적 결론으로 간주해서는 안 됩니다. 공급업체는 거래 구조, 각 당사자의 권리 및 의무를 설명한 후, 특정 계약의 맥락에서 법무팀이 평가하도록 해야 합니다.

7. 그룹 4 — 개인 데이터 보호 (6가지 기준)

1. 데이터 처리에서 각 당사자의 역할 식별.
2. 데이터 목록, 처리 목적 및 근거 제공.
3. 필요 시 데이터 주체의 권리 통지/동의 및 실행 메커니즘 제공.
4. 데이터 저장, 삭제, 익명화 및 반환 기한 규정.
5. 하위 처리자, 저장 위치 및 데이터 전송 흐름 공개.
6. 데이터 위반 처리 절차 및 요구에 따른 영향 평가 문서 제공.

2026년 이후 발행되는 RFP는 개인 데이터 보호법 제91/2025/QH15호 및 현재 지침에 따라 법무팀의 검토를 받아야 합니다. 주민등록번호, 사진, 위치, 장치, 은행 계좌 및 급여와 같은 민감한 필드는 별도로 설명되어야 합니다.

8. 그룹 5 — 정보 보안 (7가지 기준)

1. 환경 및 민감한 서비스의 아키텍처 분리.
2. 최소한의 인증, 권한 부여 및 정기적인 권한 검토.
3. 데이터 전송 및 저장 시 암호화.
4. 키, 비밀 및 은행 연결 정보 관리.
5. 감사 로그, 비정상 행동 모니터링 및 경고.
6. 취약점 관리, 업데이트 및 독립 보안 테스트.
7. 사고 대응, 백업, 복구 및 지속적인 비즈니스 연습.

공급업체는 서류 단계, 현장 심사 또는 보안 데이터 룸에서 제공할 증거를 명확히 해야 합니다. 내부 테스트 수는 펜테스트 또는 독립 인증을 대체할 수 없습니다.

9. 그룹 6 — 통합 및 데이터 품질 (6가지 기준)

1. API/파일 사양 및 데이터 사전 제공.
2. 두 시스템이 다를 때 표준 데이터 소스 식별.
3. 중복, 누락, 형식 오류 및 총 제어 검사 제공.
4. 다시 동기화, 중복 입력 방지 및 버전 관리 메커니즘 제공.
5. 테스트 환경, 모의 데이터 및 승인 기준 제공.
6. 지연 보고서, 오류 로그 및 처리 절차 제공.

공급업체는 기술 실행 일정과 약속된 SLA를 구분해야 합니다. 예를 들어, 일당 선지급 시스템은 현재 30분마다 시트 동기화 및 매일 ERP를 실행합니다; RFP는 여전히 서비스 수준, 측정 방법 및 서면 예외를 요구해야 합니다.

10. 그룹 7 — 은행, 지출 및 중복 거래 방지 (6가지 기준)

1. 수신자 및 본인 계좌 확인.
2. 각 시도에서 불변의 고유 거래 코드 제공.
3. 동일한 요청에 대한 두 개의 지출 명령을 방지하는 동시 잠금 제공.
4. 유효한 응답/서명이 있을 때만 성공 기록.
5. 상태가 불명확할 때 대기하고 조사 메커니즘 제공.
6. 비상 정지 스위치 및 제어된 재활성화 권한 제공.

현재 표준 흐름에서 일당 선지급은 VPBank를 통해 본인 확인된 VPBank 계좌로 지출합니다. 다른 은행을 사용하는 특별한 경우와 적용 범위는 Nhan Kiet의 확인을 받아야 하며, RFP에 표준 기능으로 자동 기록되어서는 안 됩니다.

11. 그룹 8 — 대조, 급여 및 감사 (5가지 기준)

1. 개인, 고객 및 급여 기간별 거래 보고서 제공.
2. 은행 명세서와 대조 및 보류 금액 절차 제공.
3. 수령한 금액을 급여에 반영하는 파일/API 제공.
4. 사용된 근무 시간이 다음 기간에 누적되지 않도록 제어 제공.
5. 회수 불가 금액에 대한 장부 및 처리 절차 제공.

요구해야 할 증거: 근무 시간, 수령 요청, 은행 응답, 대조 보고서 및 개인 정보가 숨겨진 급여 명세서를 포함한 완전한 샘플 데이터 세트.

12. 그룹 9 — SLA, 지원 및 구현 (5가지 기준)

1. SLA 가용성, 응답 및 복구가 숫자로 정의됨.
2. P1–P4 등급, 주요 연락처 및 에스컬레이션 메커니즘 제공.
3. 파일럿, 교육, 커뮤니케이션 및 변경 관리 계획 제공.
4. RTO/RPO, 유지보수 일정 및 사고 통지 제공.
5. 정기적인 서비스 보고서 및 근본 원인 분석 제공.

“거의 즉시”와 같은 문구는 SLA 점수를 매기기에 충분하지 않습니다. RFP는 시계가 언제 시작되고 언제 멈추는지, 어떤 로그가 표준 소스인지, 어떤 경우가 제외되는지를 명확히 해야 합니다.

13. 그룹 10 — 상업적, 역량 및 서비스 종료 (4가지 기준)

1. 전체 가격 구조: 구현, 통합, 운영, 거래 및 추가 개발.
2. 재정적, 운영적 역량 및 참조 사례.
3. 데이터 소유권, 데이터 내보내기 및 전환 지원.
4. 권한 회수, 데이터 삭제/반환 및 종료 후 지원 절차.

새로운 공급업체를 제외하기 위해 너무 유사한 사례를 요구하지 말고, 증거의 품질, 통제 능력 및 안전한 파일럿 실행 능력을 평가하십시오.

14. 제안된 점수 가중치

그룹	가중치
비즈니스 및 경험	15%
출퇴근 기록 및 예외	12%
법적/계약	12%
개인 데이터	12%
정보 보안	15%
통합	8%
은행/지출	10%
대조/급여	8%
SLA/구현	5%
상업적/서비스 종료	3%

가중치가 있는 총점은 탈락 조건을 대체하지 않습니다. 100점 만점에 90점을 받았지만 중복 지출을 방지하지 못하는 공급업체는 파일럿에 참여해서는 안 됩니다.

15. 공급업체 평가의 세 가지 단계

(더 보기: 일당 선지급 심사 서류 및 EWA 파일럿 계획 샘플 및 확장 기준.)

단계 1 — 서류

완전성, 탈락 조건 및 법적/보안 증거 점검.

단계 2 — 시나리오에 따른 데모

공급업체가 가장 아름다운 흐름을 선택하지 않도록 합니다. 기업은 야간 교대, 승인된 근무 시간 수정, 보류 거래, 퇴사 및 최종 대조와 같은 공통 시나리오를 제공합니다.

단계 3 — 통제된 파일럿

작은 범위를 선택하고, 급여와 병행하여 실행하며, 중지 임계값을 설정하고 KPI를 측정합니다. 차이가 설명되고 올바르게 처리된 후에만 확장합니다.

16. 자주 묻는 질문

가장 낮은 수수료의 공급업체를 선택해야 하나요?

통합, 지원, 데이터 처리 및 예외 운영을 포함하지 않은 총 비용이라면 선택하지 않는 것이 좋습니다. 거래 오류나 급여 불일치 비용은 단가 차이보다 클 수 있습니다.

60가지 기준을 모두 요구해야 하나요?

모든 기준이 동일한 가중치를 갖는 것은 아니지만, 기업은 전체적으로 답변하여 어떤 공백을 수용하고 있는지 알아야 합니다.

데모가 성공하면 운영에 들어갈 수 있나요?

아니요. 데모는 기능 흐름을 증명하지만, 파일럿은 실제 데이터, 권한 부여, 지원 및 통제된 범위 내에서의 대조를 점검합니다.

공급업체가 “개발 필요”라고 답할 수 있나요?

예, 범위, 시간, 비용, 승인 기준 및 의존 위험을 명확히 제시한다면 가능합니다. 이를 기존 기능으로 평가해서는 안 됩니다.

일당 선지급은 현재 60가지 기준을 모두 충족하나요?

이 글은 그러한 결론을 내리지 않습니다. 많은 기술적 능력은 코드에서 비롯되지만, 법적 서류, SLA, 펜테스트, 상업 정책 및 운영 증거는 권한 있는 부서에서 제공해야 합니다.

17. 결론

좋은 RFP는 기업이 “애플리케이션에 무엇이 있는가?”라는 질문을 “전체 체인이 통제 가능한가, 증거는 어디에 있는가?”라는 더 중요한 질문으로 변환할 수 있도록 도와줍니다. 60가지 기준은 HR, 법무, IT, 정보 보안, 재무, 급여 및 구매 부서 간의 공통 언어를 만듭니다. 적합한 공급업체는 단순히 원활한 흐름을 시연할 수 있을 뿐만 아니라, 데이터 오류, 은행 지연 또는 중간에 퇴사한 근로자가 발생했을 때 어떤 일이 발생하는지 설명할 수 있어야 합니다.

---

저자: Nguyen Minh Khang — Chuyên viên ban chiến lược, Nhan Kiet Manpower Supply Co., Ltd.

기업을 위한 일당 선지급 솔루션 상담: 핫라인 0937.022.655 · 이메일 info@nhankiet.vn · 기업을 위한 일당 선지급