EWAシステムのSLA: 30の指標に関するコミットメント

Doanh nghiệp · 18/09/2026 · 著者: Nguyễn Minh Tuấn (Chuyên viên ban chiến lược)

EWAシステムのSLAには何が必要か？勤怠管理から給与計算までの30の指標

「迅速な支払い」はSLAではありません。EWAは人事、勤怠、承認、識別、銀行、照合、給与計算に依存します。アプリの稼働時間だけを測定しても、アプリが開いても勤怠が更新されない、取引が保留されて処理されない、または期末に給与が一致しない状況が発生する可能性があります。

> 要約: EWAのSLAはユーザーの旅程と最終結果に基づいて測定されるべきです：記録が期限内に更新され、勤怠が承認され、送金指示が状態を持ち、保留中の取引が処理され、明細が一致し、給与計算が正しいデータを受け取ること。

> 警告: 本文中の閾値は設計例であり、Nhan KietやVPBankの公式SLAではありません。各コミットメントには測定式、データソース、サービススケジュール、例外、責任、制裁が承認されている必要があります。

1. SLAはSLO、KPI、OLAとどう違うのか？

SLA: 関係者間のサービスレベルのコミットメントで、通常は契約に関連付けられています。
SLO: 特定の指標に対する内部運用目標。
KPI: より広範な結果評価指標で、必ずしもサービスコミットメントではありません。
OLA: SLAを達成するための内部チーム間の運用合意。

例：顧客とのSLAは保留中の取引を一定期間内に処理することを要求し、OLAはカスタマーサポート、銀行チーム、技術チームの時間を割り当てます。

2. 各SLA指標の6つの必須要素

名前と目的。
計算式。
データソース。
測定ウィンドウとサービススケジュール。
目標/閾値。
除外、責任、報告メカニズム。

「迅速」、「タイムリー」、「ほぼ即時」などの言葉は、開始点と終了点を定義しない限り使用しないでください。

3. 開始–終了時計の特定

例：「支払い時間」は以下から始まることがあります：

労働者が確認ボタンを押した時；
サーバーが要求を受け入れた時；
指示が銀行に送信された時。

そして以下で終了します：

APIが成功を報告した時；
労働者の口座に入金された時；
取引が明細に表示された時；
労働者が受け取りを確認した時。

定義を確定しないと、両者が異なるが正しい結果を報告する可能性があります。

4. グループA — 可用性とパフォーマンス (SLA 1–5)

1. 労働者アプリの可用性率

サービスウィンドウ内でのログイン、利用可能額の表示、要求の作成能力を測定します。

2. 顧客ポータルの可用性率

表示、承認、拒否、勤怠修正機能を測定します。

3. コア画面/APIの応答時間

平均だけでなく、P95/P99のようなパーセンタイルを測定するべきです。平均は非常に遅いケースを隠すことがあります。

4. サーバーエラー率

システムエラー、入力データエラー、ユーザーエラー、サードパーティエラーを分けます。

5. メンテナンスウィンドウ

スケジュール、事前通知時間、緊急メンテナンス、影響を受ける機能を規定します。

5. グループB — 人事と勤怠管理 (6–10)

6. 人事記録の同期遅延

ソースに変更があってからEWAが反映するまでの時間、特に退職/異動者について。

7. 勤怠表の同期遅延

給与前払いは30分ごとのGoogle Sheetスケジュールと即時同期ボタンを持っています。SLAはジョブが遅れた場合やファイルがエラーの場合の測定方法を示す必要があります。

8. アプリ内勤怠の遅延

アプリ内の勤怠はリアルタイムで記録されるように設計されていますが、画面/承認ソースに反映される目標が必要です。

9. 勤怠記録の成功結合率

正しい人、顧客、日/シフトに結合された記録数を有効な記録の合計で割ります。

10. エラー勤怠記録の処理時間

システムエラーとソースデータエラーを分け、誰が修正し、応答時間を規定します。

6. グループC — 勤怠承認と利用可能額 (11–14)

11. 勤怠承認時間

これは通常、顧客/監督者のOLAであり、プラットフォームが完全に制御するものではありません。勤怠が利用可能になってから承認されるまでの時間を測定する必要があります。

12. 承認後の利用可能額更新遅延

有効な承認イベントからサーバーが新しい数値を計算/表示するまでの時間を測定します。

13. 正しい利用可能額計算率

勤怠、単価、受領済み、予約、限度額、四捨五入から再計算したサンプルで確認します。

14. ポリシー変更の適用時間

単価/限度額/予約は有効日、承認、変更後の確認が必要です。

7. グループD — 識別とアカウント (15–17)

15. OCR/CCCD確認応答時間

自動処理と人による確認が必要な例外を区別します。

16. アカウント名検索時間

システム部分と銀行部分を測定し、検索サービスが中断された場合の状態を規定します。

17. デバイス/アカウント変更処理時間

体験と不正取得防止のバランスを取り、確認と承認が必要です。

8. グループE — 銀行取引 (18–22)

18. 処理成功率

システム、銀行、アカウント、データ、ポリシーによる失敗を分ける必要があります。

19. 確認後の指示送信時間

サーバーが受け入れてから送金サービスが指示を受け取るまでの時間を測定します。

20. 結果確認時間

「口座への入金」とは一致しません。確認ソースを定義する必要があります。

21. 保留取引率

率と原因を追跡します。異常に低い場合もシステムが早急に結論を出している可能性があります。

22. 保留取引の年齢

保留に入ってから最終結論が出るまでの時間を測定し、最も長い取引と年齢グループを報告します。

給与前払いでは、保留中の取引の調査は技術レベルで5分ごとに実行されます。SLAは銀行/関係者の応答時間も考慮する必要があります。

9. グループF — 照合と給与計算 (23–26)

(詳細: EWA取引の照合と給与計算および会計を参照。)

23. T+1照合完了

給与前払いは08:00に明細ファイルを読み取るスケジュールがあります。コミットメントはファイルが利用可能になる時間、結合率、例外を決定する人を規定する必要があります。

24. 自動明細結合率

一意に結合された行数、正しいコード/金額/アカウントを条件を満たす行の合計で割ります。

25. 照合差異の解消時間

価値、人数、重複/誤送金のリスクに基づいてレベルを分けます。

26. 給与計算データの期限内提供

確認済みのファイル/API、カットオフ前、正しい人/顧客/期間を測定します。「メールを送信した」だけではありません。

10. グループG — サポートと障害対応 (27–30)

(詳細: 給与前払いの障害発生時の対応およびEWA苦情処理プレイブックを参照。)

27. 初回応答時間

有効なチケットが記録されてからユーザーが事件番号付きの応答を受け取るまでの時間。

28. 復旧/処理時間

サービスの復旧と根本原因分析（RCA）による完全解決を区別します。

29. 障害通知時間

認識、確認、初期通知、定期更新の基準を規定します。

30. RCA提供時間

RCAにはタイムライン、根本原因、影響、是正措置、予防措置が含まれている必要があります。

11. 参考障害レベルマトリックス

レベル	例	処理
P1	広範囲の重複/誤送金、ロック制御の喪失、コアサービス停止	障害指揮、適切な停止、継続的な更新
P2	多くの人が取引できない、重大な利用可能額/照合エラー	高優先度、クロスファンクショナルチーム
P3	小規模グループのエラー、代替案あり	標準SLAに従って処理
P4	情報要求/表示エラー	バックログ/通常サポート

公式レベルは金額、人数、データ、時間の閾値を持つ必要があり、感覚だけで分類しないでください。

12. SLA目標例示表

指標	例示目標	注意
コアサービスの稼働時間	99.9%/月	例示のみ、除外を定義する必要があります
API応答P95	≤ 2秒	銀行APIを分ける
シート同期	30分サイクル	有効なソースデータから計算
P1チケット応答	≤ 15分	24/7の待機スケジュールが必要な場合
P2チケット応答	≤ 30分	処理完了を意味しません
T+1照合	締め時間に完了	銀行ファイルに依存
給与計算提供	承認済みカットオフ前	チェックサム/受領確認あり

表中のすべての数値は記述方法を示すためのものであり、給与前払いのコミットメントとして使用しないでください。

13. 正しい稼働時間の計算方法

一般的な式：

稼働時間 = (サービスウィンドウの総分数 − SLA計算の中断分数) ÷ サービスウィンドウの総分数 × 100%

契約には以下を規定する必要があります：

測定される機能；
外部からの測定か内部ログか；
部分的な中断の計算方法；
メンテナンスが除外されるかどうか；
インターネット/銀行の依存関係；
四捨五入とタイムゾーン；
データの争議処理方法。

14. 除外を広くしすぎない

「サードパーティによるすべてのエラー」などの条項は、銀行とインフラがEWAの重要な部分であるため、SLAを無意味にする可能性があります。

以下を分けるべきです：

プロバイダーが調整責任を負うエンドツーエンドのSLA；
銀行/顧客に依存する指標；
関係者間のOLA；
原因がどこにあっても通知義務と代替案。

15. RTOとRPO

RTO: 中断後のサービス復旧目標時間。
RPO: 時間に基づいて失われる可能性のある最大データ量。

EWAは以下に対して独自のRTO/RPOが必要です：

記録/勤怠；
利用可能額；
取引；
監査ログ；
照合/給与計算。

金融取引は、通信内容よりも厳しい要件が必要です。目標は、リハーサルが行われ、重複がない復旧の証拠がある場合にのみ意味があります。

16. データとセキュリティのためのSLA

(完全なフレームワーク: EWA導入時のデータセキュリティとプライバシーを参照。)

稼働時間以外にも、以下に関する合意が必要です：

乗っ取りが疑われるアカウントのロック時間；
退職者の権限回収；
脆弱性のレベルに応じた修正；
データ侵害の通知；
ログ/証拠の提供；
データ主体の要求処理；
バックアップと復旧テスト；
定期的な権限レビュー；
終了時のデータ削除/返却。

公式の期限は法律とリスク評価に適合している必要があり、国際的なテンプレートを機械的にコピーしないでください。

17. サービスクレジットは十分か？

サービスクレジットはコンプライアンスを促進する可能性がありますが、以下を代替するものではありません：

誤った金銭の是正；
データ保護義務；
苦情処理；
契約/法律に基づく補償；
停止/拡張の権利；
再発防止計画。

重大な金融エラーに対しては、小さな料金減額よりも具体的なブロック条件と責任が重要です。

18. 月次SLAレポートに含めるべきもの

適用される30の指標の結果；
3〜6か月のトレンド；
違反回数と期間；
顧客/ソース別の分析；
保留中の取引と年齢；
照合/給与計算の差異；
P1〜P4とRCA；
大規模なメンテナンス/変更；
苦情と再開；
是正措置、所有者、期限；
次の期間の予想リスク。

平均的な美しい数字で重大なエラーを隠してはなりません。

19. SLA構築の6ステッププロセス

旅程と依存関係を描く。
労働者/企業にとって重要な結果を選ぶ。
メトリック、ソース、測定時計を特定する。
コミットメント前にベースラインを測定する。
目標、除外、OLA、制裁を交渉する。
パイロット、レビュー、拡大前に調整する。

システムにベースラインがない場合、市場が通常記載しているからといって高いレベルをコミットしないでください。

20. SLAのデューデリジェンスチェックリスト

(ドキュメントセット: 給与前払いのデューデリジェンスドキュメントを参照。)

サービスウィンドウの定義がある。
処理時間の開始/終了点がある。
独立した追跡可能なデータソースがある。
パフォーマンスのパーセンタイルがある。
サードパーティエラーが無制限に除外されていない。
保留中の取引のSLAがある。
照合と給与計算のコミットメントがある。
客観的な閾値を持つP1〜P4がある。
障害更新スケジュールがある。
RTO/RPOとリハーサルがある。
データ/セキュリティのSLAがある。
定期的な報告とレビューがある。
監査/データ争議の権利がある。
適切なサービスクレジット/責任がある。
規模の変化に応じたSLA修正メカニズムがある。

21. よくある質問

30秒以内の支払いはSLAですか？

契約が開始点、終了点、取引達成率、アカウント/銀行条件、例外を定義している場合のみです。そうでなければ、それは単なる体験メッセージです。

99.9%の稼働時間はEWAに十分ですか？

十分ではありません。アプリはオンラインでも、勤怠が更新されない、または銀行が処理しない可能性があります。エンドツーエンドのチェーンに基づいたSLAが必要です。

保留中の取引はSLA違反と見なされますか？

保留中の取引率と年齢に関する独自の指標が必要です。いくつかの保留状態は安全管理ですが、無期限に存在することはできません。

顧客が勤怠承認を遅らせた場合、プロバイダーの責任ですか？

通常は顧客の依存/OLAです。SLAは有効な承認前後の時間を分ける必要があります。

SLAをウェブサイトで公開すべきですか？

承認されたフレームワークまたはサービスステータスを公開することができます。詳細な契約目標は顧客によって異なる可能性があり、証拠がない数値を公開しないでください。

---

著者: Nguyen Minh Tuan — Chuyên viên ban chiến lược, Nhan Kiet Manpower Supply Co., Ltd.

企業向け給与前払いソリューションの相談: ホットライン 0937.022.655 · メール info@nhankiet.vn · 企業向け給与前払い

← ニュース