RFP-skabelon til valg af EWA-leverandør: 60 vurderingskriterier

RFP-skabelon til valg af EWA-leverandør: 60 kriterier virksomheder skal vurdere

En RFP til valg af EWA-leverandør bør vurdere hele kæden fra udført arbejde, godkendelsesret, tilgængelige midler, bankudbetaling til lønafstemning, ikke kun sammenligne grænseflade og gebyrer. Skabelonen nedenfor hjælper virksomheder med at stille det samme sæt spørgsmål til alle leverandører, kræve beviser og score efter vigtighed.

> Kort sagt: RFP bør indeholde 10 grupper med 60 kriterier, obligatoriske udelukkelsesbetingelser og en vægtet scoringsskala. Hvert svar skal klart angive: tilgængelig, kræver konfiguration, kræver udvikling eller ikke opfyldt; og vedhæfte dokumentation eller en demonstration som bevis.

> Bemærk ved brug: Nguyen Minh Khang — Chuyên viên ban chiến lược, at adgang til optjent løn opfylder alle kriterier. Nhan Kiet skal besvare hvert punkt med aktuelle beviser, når de deltager i en faktisk RFP.

1. Hvordan adskiller en EWA RFP sig fra en almindelig HR-software RFP?

(Se også: Tjekliste til valg af EWA-leverandør og Hvordan virksomheder vurderer EWA-leverandører.)

EWA involverer samtidig HR-data, tidsregistrering, løn, personlige data og pengeoverførsler. En visningsfejl kan kun være en ulempe; en fejl i transaktionsstatus eller godkendt arbejde kan forårsage en reel pengeforskel.

Derfor skal RFP'en kontrollere fem kerneevner:

1. Genererer ikke penge fra fremtidigt arbejde eller ikke-godkendt arbejde.

2. Betaler ikke forkert person, forkert konto eller duplikerer transaktioner.

3. Kan forklare hver krone i de tilgængelige midler.

4. Kan afstemme transaktioner med banken og lønnen.

5. Beskytter personlige data og opretholder service ved fejl.

Hvis en leverandør ikke kan bevise en af disse fem punkter, bør virksomheden ikke kompensere med et flot design eller lave gebyrer.

2. Sådan beder du leverandøren om at svare

Hvert kriterium bør have seks kolonner:

Svar som kun indeholder “Ja” accepteres ikke. Hvis udvikling er nødvendig, skal leverandøren angive omfang, godkendelse, tidsfrist og ansvar ved forsinkelse.

3. Scoringsskala og udelukkelsesbetingelser

Scoringsskala 0–5

Foreslåede udelukkelsesbetingelser

• kan ikke blokere for ikke-udført/ikke-godkendt arbejde;

• har ingen mekanisme mod duplikerede betalinger;

• kan ikke verificere modtagerens konto;

• gemmer ikke log over ændringer i arbejde og transaktionsstatus;

• kan ikke forbinde modtagne beløb til løn;

• kan ikke identificere roller i behandling af personlige data;

• kan ikke levere proces for alvorlige hændelser;

• kan ikke forklare den juridiske natur og parterne i pengestrømmen.

Udelukkelsesbetingelser skal godkendes før åbning af dokumenter for at undgå ændring af standarder baseret på følelser.

4. Gruppe 1 — EWA-forretning og medarbejderoplevelse (8 kriterier)

1. Beregner kun værdi fra udført og godkendt arbejde.

2. Blokerer for nuværende dag, der ikke er afsluttet, og fremtidige dage.

3. Viser tilgængelige midler og forklarlig formel.

4. Viser detaljer om arbejdsdage, modtaget og tilbageholdt beløb.

5. Tillader medarbejdere at anmode proaktivt, uden at skulle godkende hver anmodning, hvis betingelserne er opfyldt.

6. Har en bekræftelses-/acceptproces før hver modtagelse.

7. Viser transaktionsstatus klart: ventende, succes, fejl, kræver undersøgelse.

8. Har supportkanal ved fejl i dokumenter, arbejde eller manglende betaling.

Bevis der bør kræves: demo fra godkendt arbejdsdag til transaktion; demo af ikke-godkendt arbejde; eksempler på transaktionshistorik og forpligtelsesindhold.

Med adgang til optjent løn er formlen i systemet: godkendt arbejde × daglig sats pr. kunde − modtaget i perioden − tilbageholdt beløb, afrundet ned til nærmeste 1.000 VND. Dette er verificeret information fra koden; politikker for hver kunde skal stadig bekræftes.

5. Gruppe 2 — Tidsregistrering, godkendelse og undtagelser (7 kriterier)

1. Modtager data fra kundesystem, ERP eller app.

2. Understøtter flere skabeloner og skift over midnat.

3. Har stabil forbindelse mellem medarbejder og tidsregistreringskode.

4. Adgangskontrol til at se, redigere, godkende og afvise arbejde.

5. Ændringer i godkendt arbejde skal vende tilbage til kontrolstatus.

6. Gemmer log før/efter, hvem der ændrede og tidspunkt.

7. Har proces for skift, overførsel, opsigelse og reduceret arbejde efter betaling.

Obligatorisk demoscenarie: ændre en godkendt post og bevise, at tilgængelige midler genberegnes efter reglerne; sletter ikke gamle spor.

Systemet til adgang til optjent løn understøtter i øjeblikket kundernes handlinger på portalen /kh; kunder eller Nhan Kiet-overvågere kan godkende efter rettigheder. Tilpasning til virksomhedens flertrinsgodkendelsesproces skal testes separat.

6. Gruppe 3 — Juridisk og kontraktstyring (6 kriterier)

1. Identificerer juridisk enhed og underskrivers autoritet.

2. Har juridisk analyse af modelens natur og modregningsmekanisme.

3. Arbejdstagerens vilkår er konsistente mellem kontrakt, app og kommunikation.

4. Gebyrpolitik, ansvarlig part og betingelser for ændringer er gennemsigtige.

5. Ansvar ved fejl i arbejde, person, duplikeret betaling eller manglende inddrivelse.

6. Klageproces, serviceophør og tvistbilæggelse.

Virksomheder bør ikke betragte sætningen “ikke et lån” som en juridisk konklusion. Leverandøren skal præsentere transaktionsstrukturen, parternes rettigheder og forpligtelser, og derefter lade juridisk afdeling vurdere i den specifikke kontraktsammenhæng.

7. Gruppe 4 — Beskyttelse af personlige data (6 kriterier)

1. Identificerer hver parts rolle i databehandling.

2. Har datakatalog, formål og behandlingsgrundlag.

3. Har meddelelse/samtykke og mekanisme til at udøve datasubjektets rettigheder efter behov.

4. Angiver opbevarings-, slette-, anonymiserings- og returperioder for data.

5. Offentliggør underbehandlere, opbevaringssteder og dataoverførselsstrømme.

6. Har proces til håndtering af databrud og vurderingsdokumentation efter behov.

RFP'er udstedt fra 2026 skal gennemgås af juridisk afdeling i henhold til Lov om beskyttelse af personlige data nr. 91/2025/QH15 og gældende vejledninger. Følsomme felter som ID, billeder, placering, enheder, bankkonti og løn skal beskrives særskilt.

8. Gruppe 5 — Informationssikkerhed (7 kriterier)

1. Arkitektur adskiller miljøer og følsomme tjenester.

2. Godkendelse, minimal adgangskontrol og periodisk rettighedsrevision.

3. Kryptering af data under overførsel og opbevaring.

4. Håndtering af nøgler, hemmeligheder og bankforbindelsesoplysninger.

5. Revisionslog, overvågning og advarsel om unormal adfærd.

6. Håndtering af sårbarheder, opdateringer og uafhængige sikkerhedstest.

7. Hændelsesrespons, backup, genopretning og kontinuerlig forretningsøvelse.

Leverandøren skal angive, hvilke beviser der leveres i dokumentationsfasen, on-site vurdering eller sikkerhedsdataværelse. Antallet af interne tests erstatter ikke pentests eller uafhængige certificeringer.

9. Gruppe 6 — Integration og datakvalitet (6 kriterier)

1. Har API/fil-specifikation og datadictionary.

2. Identificerer standarddatakilde, når to systemer er forskellige.

3. Har kontrol for duplikater, mangler, forkert format og total kontrol.

4. Har mekanisme til resynkronisering, anti-duplikering og versionsstyring.

5. Har testmiljø, simulerede data og godkendelseskriterier.

6. Har forsinkelsesrapporter, fejlposter og behandlingsproces.

Leverandøren skal skelne mellem teknisk kørselsplan og aftalt SLA. For eksempel har systemet til adgang til optjent løn i øjeblikket en synkroniseringsplan for Sheet hver 30. minut og ERP dagligt; RFP skal stadig kræve serviceniveau, målemetode og undtagelser skriftligt.

10. Gruppe 7 — Bank, betaling og anti-duplikering (6 kriterier)

1. Bekræfter modtager og hovedkonto.

2. Har unik transaktionskode, uændret ved gentagne forsøg.

3. Har samtidighedslås for at forhindre to betalinger for samme anmodning.

4. Registrerer kun succes ved gyldigt svar/signatur.

5. Holder i venteposition ved uklar status og har undersøgelsesmekanisme.

6. Har nødstop og kontrolleret genaktiveringsret.

I den nuværende standardstrøm betaler adgang til optjent løn gennem VPBank til en verificeret hovedkonto hos VPBank. Specielle tilfælde, der bruger andre banker og anvendelsesområder, skal bekræftes af Nhan Kiet, og bør ikke automatisk inkluderes i RFP som en standardfunktion.

11. Gruppe 8 — Afstemning, løn og revision (5 kriterier)

1. Har transaktionsrapporter pr. person, kunde og lønperiode.

2. Har afstemning med bankudtog og proces for ventende beløb.

3. Har fil/API til at inkludere modtagne beløb i løn.

4. Har kontrol for at sikre, at brugte arbejdsdage ikke akkumuleres i næste periode.

5. Har bog og proces for uinddrivelige beløb.

Bevis der bør kræves: et komplet datasæt med arbejde, modtageranmodning, bankrespons, afstemningsrapport og lønseddel med skjulte personlige oplysninger.

12. Gruppe 9 — SLA, support og implementering (5 kriterier)

1. SLA for tilgængelighed, respons og genopretning defineret numerisk.

2. Har P1–P4 klassifikation, kontaktpunkter og eskaleringsmekanisme.

3. Har plan for pilot, træning, kommunikation og ændringsstyring.

4. Har RTO/RPO, vedligeholdelsesplan og hændelsesmeddelelse.

5. Har periodiske servicerapporter og rodårsagsanalyser.

Udsagn som “næsten øjeblikkelig” er ikke tilstrækkelige til at score SLA. RFP skal præcisere, hvornår uret starter, stopper, hvilken log der er den officielle kilde, og hvilke tilfælde der er undtaget.

13. Gruppe 10 — Kommercielle, kapacitet og serviceophør (4 kriterier)

1. Fuld prisstruktur: implementering, integration, drift, transaktion og yderligere udvikling.

2. Finansiel kapacitet, drift og referencecases.

3. Ejerskab af data, dataeksport og support til konvertering.

4. Proces for tilbagekaldelse af rettigheder, sletning/returnering af data og support efter ophør.

Man bør ikke kræve for ensartede cases kun for at udelukke nye leverandører; i stedet bør man vurdere kvaliteten af beviserne, kontrolkapaciteten og evnen til at køre en sikker pilot.

14. Foreslået vægtning af point

Den samlede vægtede score erstatter ikke udelukkelsesbetingelser. En leverandør, der scorer 90/100, men ikke kan forhindre duplikerede betalinger, bør ikke gå videre til pilot.

15. Tre faser i leverandørvurdering

(Se også: Due diligence-dokumentation for adgang til optjent løn og Pilotplan for EWA og udvidelseskriterier.)

Fase 1 — Dokumentation

Kontrollerer fuldstændighed, udelukkelsesbetingelser og juridiske/sikkerhedsbeviser.

Fase 2 — Demo efter scenarie

Lad ikke leverandøren vælge den mest fordelagtige strøm. Virksomheden udarbejder et fælles scenarie: natvagt, ændring af godkendt arbejde, ventende transaktioner, opsigelse og slutperiodeafstemning.

Fase 3 — Kontrolleret pilot

Vælg et lille omfang, kør parallelt med løn, sæt stopgrænser og mål KPI'er. Udvid kun efter at forskelle er forklaret og korrekt håndteret.

16. Ofte stillede spørgsmål

Skal man vælge leverandøren med de laveste gebyrer?

Nej, hvis de samlede omkostninger ikke inkluderer integration, support, databehandling og undtagelsesdrift. Omkostninger ved fejlagtige transaktioner eller lønafvigelser kan overstige forskellen i enhedspris.

Er det nødvendigt at kræve alle 60 kriterier?

Ikke nødvendigvis, da ikke alle kriterier har samme vægtning, men virksomheder bør besvare dem alle for at vide, hvilke huller de accepterer.

Er en vellykket demo nok til at gå i drift?

Nej. Demo beviser funktionelle strømme; pilot tester ægte data, adgangskontrol, support og afstemning inden for kontrolleret omfang.

Kan leverandøren svare “kræver udvikling”?

Ja, hvis de klart angiver omfang, tid, omkostninger, godkendelseskriterier og afhængighedsrisici. Det bør ikke scores som en tilgængelig funktion.

Opfylder adgang til optjent løn i øjeblikket alle 60 kriterier?

Artiklen konkluderer ikke dette. Mange tekniske kapaciteter fra koden, men juridisk dokumentation, SLA, pentest, kommercielle politikker og driftsbeviser skal leveres af den relevante afdeling.

17. Konklusion

En god RFP hjælper virksomheder med at omdanne spørgsmålet “hvad kan applikationen?” til det vigtigere spørgsmål: kan hele kæden kontrolleres, og hvor er beviserne? De 60 kriterier skaber et fælles sprog for HR, juridisk, IT, informationssikkerhed, finans, løn og indkøb. En passende leverandør kan ikke kun demonstrere en glat strøm, men også forklare, hvad der sker, når data er forkerte, banken er langsom, eller medarbejderen fratræder midt i perioden.

---

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

Rådgivning om adgang til optjent løn for virksomheder: Hotline 0937.022.655 · Email info@nhankiet.vn · Adgang til optjent løn for virksomheder