給与計算処理データテンプレート
給与計算処理データテンプレート
- 給与計算分析のための標準化されたデータ属性
- UKG Proで追跡すべき必須のプロセス節目
- システム統合のための技術抽出ガイダンス
給与計算処理属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
給与計算プロセスで実行される特定のイベントまたはステップです。 | ||
|
説明
この属性は、「タイムシート提出済」、「総支給額計算済」、「支払い実行済」など、給与計算ワークフロー内で発生するステップの名前を捕捉します。これは、プロセスマップのフローを定義します。 これらの値は通常、UKG Pro環境内の監査ログ、システムステータス変更テーブル、またはタイムスタンプ付きトランザクション更新から抽出されます。データ変換中に一貫した命名規則が適用され、プロセスグラフでの可読性が確保されます。
その重要性
これは、プロセスマップのノードを定義する必須の活動属性です。
取得元
システム監査ログ、ワークフロー履歴、またはトランザクションタイムスタンプ列
例
タイムシート提出済総支給額計算済み支払い実行
|
|||
|
ソースシステム
SourceSystem
|
データの記録システムです。 | ||
|
説明
この属性は、データ記録の発生元を特定します。この特定のコンテキストでは、値は静的にUKG Proに設定されます(複数のインスタンスが存在する場合は特定のインスタンス名)。これは、給与データがERPの総勘定元帳データと混在する可能性のある複数システムプロセスマイニングにとって非常に重要です。 これにより、アナリストは、給与計算プラットフォーム内でのみ発生するステップと、外部の勤怠管理システムから統合されたステップのみを表示するようにビューをフィルタリングできます。
その重要性
データリネージと複数システム分析のための必須属性です。
取得元
静的値またはシステム設定テーブル
例
UKG ProUltiProレガシー勤怠管理システム
|
|||
|
タイムスタンプ
EventTimestamp
|
アクティビティが発生した日時。 | ||
|
説明
この属性は、活動が実行された正確な時刻を記録します。イベントを正しく順序付けし、ステップ間の期間を計算するために不可欠です。連続して発生する自動化されたステップを区別するためには、高精度なタイムスタンプが推奨されます。 給与計算のコンテキストでは、これがサイクル時間分布とSLAコンプライアンスに関するダッシュボード分析を推進します。正確なタイムスタンプがなければ、総支給額から純支給額への計算速度やタイムシート承認の遅延を測定することは不可能です。
その重要性
これは、イベントを順序付けるために必要な必須のStartTime属性です。
取得元
トランザクションのステータス変更に関連する日付/時刻列
例
2023-10-01T09:15:00Z2023-10-01T14:30:45Z2023-10-03T08:00:00Z
|
|||
|
最終更新日
LastUpdateDate
|
データ行に対する最新の変更のタイムスタンプです。 | ||
|
説明
この属性は、記録がデータベースで最後に変更された日時を示します。イベントタイムスタンプに似ていますが、増分データ読み込みやデータ整合性チェックに特化して使用されます。 これにより、プロセスマイニングモデルが給与記録の最新の状態を反映し、給与担当者による遅延調整や遡及修正を捕捉します。
その重要性
増分データ更新のための必須属性です。
取得元
LastModifiedDateのようなシステムメタデータ列
例
2023-10-05T17:00:00Z2023-10-06T09:00:00Z
|
|||
|
給与記録
PayrollRecordId
|
特定の給与期間内の特定の従業員を表す一意の識別子です。 | ||
|
説明
給与記録は、プロセスマイニング分析における中心的なケース識別子として機能します。これは、従業員IDと給与期間終了日(または給与グループインスタンス)を組み合わせて概念的に構築されます。これにより、個々の従業員に関するすべての給与サイクルが個別のケースとして扱われ、経時的な反復プロセスの分析が可能になります。 UKG Proでは、これは通常、給与ヘッダーテーブルまたは類似のトランザクション記録から派生する複合キーです。このIDでグループ化することで、アナリストはタイムシート提出から最終支払い、税務申告までのエンドツーエンドのジャーニーを再構築できます。
その重要性
これは、すべての給与計算活動をグループ化してプロセスインスタンスを形成する必須のケースIDです。
取得元
UKG Pro給与ヘッダーまたは従業員給与履歴テーブルから導出
例
EMP001-20231015EMP492-20231031EMP883-20231115
|
|||
|
SLA期限
SlaProcessingDeadline
|
支払い実行完了の目標日時です。 | ||
|
説明
この属性は、銀行振込をタイムリーに確実に行うために、給与計算プロセスがいつまでに完了しなければならないかの内部または外部の期限を定義します。これは「SLAコンプライアンスおよび期限モニターダッシュボード」のコア属性です。 実際の「支払い実行済」タイムスタンプとこの期限を比較することで、期限内パフォーマンス率の計算が可能になり、リスクのある記録を優先するのに役立ちます。
その重要性
SLA遵守状況を計算するための基準点です。
取得元
給与カレンダー、または支払日から銀行処理日数を引いたもの
例
2023-10-13T16:00:00Z2023-10-28T16:00:00Z
|
|||
|
SLA違反
IsSlaBreached
|
支払いが期限後に実行されたかどうかを示すフラグ。 | ||
|
説明
このブール属性は、「支払い実行済」タイムスタンプと「SLA期限」を比較する計算メトリックです。これは「給与計算SLA遵守率KPI」の直接的な推進要因となります。 これを事前に計算しておくことで、ダッシュボードを即座にフィルタリングして問題ケースのみを表示し、期限が守られなかった根本原因分析を容易にします。
その重要性
コンプライアンス監視のためのKPIドライバーです。
取得元
計算済み: PaymentTime > SlaDeadline
例
truefalse
|
|||
|
コストセンター
CostCenter
|
財務配賦のためのコストセンターコードです。 | ||
|
説明
コストセンター属性は、給与費用が総勘定元帳のどこに配賦されるかを定義します。部門と類似していますが、より詳細な財務ビューを提供することがよくあります。 この属性は、「時間追跡承認パフォーマンスダッシュボード」で使用され、特定のコストセンターの承認階層が遅いかどうかを特定します。また、総支給額から純支給額への計算段階で、給与費用が正しい財務上の区分に流れ込んでいるかを検証するのにも役立ちます。
その重要性
財務分析をサポートし、予算単位ごとのボトルネックを特定します。
取得元
従業員職務または配賦テーブル
例
CC-5001CC-9002オーバーヘッド・コーポレーション
|
|||
|
サイクルタイム(日数)
CycleTimeDays
|
初期化から支払い実行までの合計期間です。 | ||
|
説明
この期間属性は、各記録のプロセスのエンドツーエンド時間を測定します。これは「給与サイクル時間分布ダッシュボード」を支えます。 異なる給与グループや部門間の「サイクル日数」の差異を分析することで、非効率性が明らかになり、手作業による修正がプロセス全体の速度に与える影響を定量化するのに役立ちます。
その重要性
プロセス効率の主要指標です。
取得元
計算済み: 支払いタイムスタンプ - 初期化タイムスタンプ
例
3.55.01.2
|
|||
|
監査例外あり
HasAuditException
|
監査例外がトリガーされたかどうかを示すフラグ。 | ||
|
説明
このブール属性は、このケースで「監査例外フラグ付け済」アクティビティが一度でも発生したかどうかを示します。これは「初回パス給与計算精度率KPI」をサポートします。 これにより、アナリストは介入が必要だったケースから「クリーン」なケースを迅速に分離でき、「監査例外および修正トレンドダッシュボード」における手戻り原因の分析を簡素化します。
その重要性
介入が必要なケースを特定します。
取得元
「監査例外フラグ設定」アクティビティの存在から導出
例
truefalse
|
|||
|
税管轄区域
TaxJurisdiction
|
税務申告の主要な州または地方です。 | ||
|
説明
この属性は、給与記録に関連付けられた主要な税管轄区域を特定します。これは「複数州税務申告タイムラインダッシュボード」にとって不可欠です。 税管轄区域に基づいてプロセスフローを分析することで、コンプライアンスチームは、特定の州で一貫して申告完了が遅いかどうか、または複数州の従業員が単一州の従業員よりも多くの監査例外を引き起こしているかどうかを特定できます。
その重要性
コンプライアンス監視と地理的分析に不可欠です。
取得元
税務所在地または従業員税テーブル
例
CANYTX
|
|||
|
給与グループ
PayGroup
|
給与計算処理のための従業員の論理的なグループ化です。 | ||
|
説明
給与グループは、UKG Proにおける基本的な設定であり、従業員群に対する給与の支払い頻度(週払い、隔週払い)と処理ルールを決定します。これは、主要なバッチ識別子として機能します。 この属性は、「給与サイクル時間分布ダッシュボード」にとって不可欠です。これにより、役員給与と時給制工場労働者のような異なるグループ間の処理パフォーマンスを比較し、特定の設定がシステム的な遅延を引き起こしているかどうかを特定できます。
その重要性
給与計算パフォーマンスのグループ化と比較のための主要なディメンションです。
取得元
給与ヘッダーまたは給与グループ設定テーブル
例
US-隔週払いCA-週次幹部-月次
|
|||
|
給与担当者
PayrollSpecialist
|
記録を処理した担当者のユーザーIDまたは名前です。 | ||
|
説明
この属性は、記録の承認、データ修正、または支払い実行を担当する特定の給与管理担当者またはスペシャリストを特定します。これは「汎用ユーザー」属性にマッピングされます。 このデータは「スペシャリストワークロードとスループットダッシュボード」にとって不可欠です。これにより、経営陣はチーム全体での作業配分を可視化し、特定の個人が過負荷になっているか、承認フェーズでボトルネックとなっているかを特定できます。
その重要性
リソース分析とワークロードの均衡化に関する洞察を可能にします。
取得元
トランザクションテーブルの監査ログまたは「ModifiedBy」列
例
jsmithmdoesystem_admin
|
|||
|
給与期間終了日
PayPeriodEndDate
|
処理されている給与期間の最終日です。 | ||
|
説明
この属性は、給与サイクルの締め日を示します。提出が遅れているかどうかを判断するための重要な参照点として機能します。 これは「タイムシート提出済」アクティビティの開始時間とともに使用され、遅延時間を判断し、「給与サイクル時間分布ダッシュボード」の主要なグループ化要素となります。
その重要性
給与サイクルの時間的基準点です。
取得元
給与ヘッダーまたは期間設定
例
2023-09-302023-10-15
|
|||
|
総支給額
GrossPayAmount
|
控除および税金が適用される前に計算された総支給額です。 | ||
|
説明
この属性は、記録のために計算された総支給額の金額を表します。これは、コストベースのプロセス分析を可能にするために「アクティビティ金額」にマッピングされます。 総支給額を分析することで、「総支給額から純支給額への計算速度ダッシュボード」に役立ちます。ダッシュボードは主に時間を測定しますが、支払いプロセスの複雑さ(および価値)と時間を相関させることで、高額または複雑なコミッション計算がパフォーマンス問題の原因であるかどうかを明らかにできます。
その重要性
バリューストリーム分析と外れ値検出を可能にします。
取得元
給与計算結果または給与台帳テーブル
例
2500.0010500.50480.00
|
|||
|
臨時計算あり
IsOffCycle
|
給与計算実行が標準スケジュール外であるかどうかを示すフラグ。 | ||
|
説明
このブール属性は、給与記録がオフサイクル実行に属するかどうかを識別します。これは「オフサイクル給与計算量KPI」を計算するために使用されます。 オフサイクル実行は通常、コストが高く、手作業が多くなります。このフラグで「プロセスバリアントパス分析ダッシュボード」をフィルタリングすることで、エラー修正やアドホック支払いのために取られた非標準パスが強調表示されます。
その重要性
プロセス逸脱と手戻りを分析するための主要フィルターです。
取得元
給与ヘッダーにおける「チェック日付」と「期間終了日」のロジック
例
truefalse
|
|||
|
部署
DepartmentCode
|
従業員に関連付けられた部門コードです。 | ||
|
説明
この属性は、給与記録を特定の組織単位にリンクします。これは、「監査例外および修正トレンドダッシュボード」にとって不可欠であり、組織がどの部門で一貫してエラーが発生しているか、または手作業による介入が必要かを把握できるようにします。 部門別にデータをセグメント化することで、アナリストは特定の管理者がタイムシート承認プロセスに関するトレーニングを必要としているか、または特定の事業単位が複雑な給与ルールにより計算遅延を引き起こしているかを特定できます。
その重要性
組織セグメンテーションと根本原因分析に不可欠です。
取得元
従業員マスターまたは職務履歴テーブル
例
DEPT-100FINANCE-01OPS-WEST
|
|||
|
インセンティブ元
IncentiveSource
|
インセンティブデータの発生元(例:SalesForce、Excelインポートなど) | ||
|
説明
この属性は、給与記録にインポートされたインセンティブまたはコミッションデータのソースを特定します。これは「インセンティブデータインポート精度ダッシュボード」をサポートします。 この属性を「インセンティブデータ手戻り頻度KPI」と関連付けることで、チームは特定のアップストリームファイル(例:北東地域営業レポート)が書式設定エラーやデータ品質問題に一貫して陥りやすいかどうかを判断できます。
その重要性
品質問題を外部データプロバイダーにまで遡って追跡します。
取得元
インポートログファイル名またはバッチIDの説明
例
営業コミッションデータ連携手動ボーナスアップロード役員報酬システム
|
|||
|
修正カテゴリ
CorrectionCategory
|
実行されたデータ修正の種類(例:勤務時間、レート、控除)です。 | ||
|
説明
「データ修正実行済」アクティビティが発生した場合、この属性は修正の性質を捕捉します。これは「手動データ修正率KPI」にとって不可欠です。 修正が主に「勤怠入力」と「福利厚生控除」のどちらに関連しているかを理解することで、ビジネスは特定のアップストリームシステムやチームをプロセス改善の対象とすることができます。
その重要性
手戻り原因に関する詳細な情報を提供します。
取得元
監査ログ「フィールド変更」列
例
勤怠入力調整遡及給与税コード更新
|
|||
|
従業員タイプ
EmployeeType
|
従業員の分類(例:正社員、パートタイム、契約社員)。 | ||
|
説明
この属性は、給与記録に関連付けられた個人を分類します。これは「時間追跡承認パフォーマンスダッシュボード」で使用されます。 異なる従業員タイプは、タイムシート提出行動や承認ワークフローが異なることがよくあります。この属性でセグメント化することで、システム的なプロセス問題と特定の労働力セグメントに固有の行動パターンを区別するのに役立ちます。
その重要性
ワークフォースカテゴリ別に分析をセグメント化します。
取得元
従業員マスターテーブル
例
フルタイムパートタイム契約社員
|
|||
給与計算処理活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
支払い実行
|
従業員への資金の有効日または実際の振込日です。これは、報酬義務が果たされたことを示します。 | ||
|
その重要性
「SLAコンプライアンス」を検証し、従業員がコミットされた日付に支払われることを確認するために使用されます。
取得元
確定済みの給与ヘッダー記録にある「チェック日付」または「通知日付」フィールドを使用します。
取得
トランザクションpayment_postが実行されたときに記録されました
イベントタイプ
explicit
|
|||
|
税務申告完了済
|
関連する管轄区域(連邦、州、地方)への税務データの提出が成功したことです。これは支払い後に行われることがよくあります。 | ||
|
その重要性
「複数州税務申告タイムライン」ダッシュボードに不可欠であり、規制遵守と罰金回避を確実にします。
取得元
税務申告インターフェースまたは支払いサービスログで、「申告済み」または「承認済み」を示すステータス更新を取得します。
取得
トランザクションtax_file_transmitが実行されたときに記録されました
イベントタイプ
explicit
|
|||
|
給与記録初期化済
|
新しい給与グループインスタンス内で、従業員に対する特定の給与明細項目が作成されることです。これは、従業員がアクティブであり、現在の処理サイクルに紐付けられていることを示します。 | ||
|
その重要性
コアシステム内での給与計算処理フェーズの公式開始を示します。勤怠データ取得期間と実際の給与計算処理期間を区別するために不可欠です。
取得元
特定の支給日の従業員給与またはチェックヘッダーテーブルにレコードが挿入されたときのタイムスタンプを特定します。
取得
トランザクションpay_period_createが実行されたときに記録されました
イベントタイプ
explicit
|
|||
|
給与記録承認済
|
個別記録または給与グループ全体に対する最終承認です。このアクションにより、記録はそれ以上の変更ができないようロックされ、支払い生成のためにキューに入れられます。 | ||
|
その重要性
作業フェーズと最終化フェーズを分ける重要な節目です。「銀行振込ファイルリードタイム」の計算に使用されます。
取得元
給与期間管理テーブルで、支給グループまたは個別のチェックレコードのステータスが「承認済み」または「ロック済み」に変更されたものを取得します。
取得
トランザクションapprove_pay_groupが実行されたときに記録されました
イベントタイプ
explicit
|
|||
|
インセンティブデータインポート済み
|
コミッション、ボーナス、一時金などの外部報酬データの取り込みです。これは通常の勤務時間とは異なり、多くの場合、バッチファイルアップロードを伴います。 | ||
|
その重要性
この活動後の高い失敗率や手戻りは、データマッピングや外部ファイルの品質に関する問題を示しており、給与計算の遅延の一般的な原因となります。
取得元
システムログまたはバッチインポート履歴で、ファイルタイプが「インセンティブ」または「追加給与」に関連するものを取得します。
取得
トランザクションimport_batch_dataが実行されたときに記録されました
イベントタイプ
explicit
|
|||
|
タイムシート承認済
|
提出された勤務時間に対する管理者の承認であり、支払い処理のためにそれらを検証します。このステップにより、データが給与計算エンジンへのインポートのためにロック解除されます。 | ||
|
その重要性
このステップのボトルネック分析により、経営陣のレビューによる遅延が明らかになり、給与計算担当者がデータを処理できる時間に直接影響します。
取得元
勤怠管理履歴でステータスが「承認済み」または「署名済み」に変更されたものを取得します。
取得
トランザクションtime_card_approveが実行されたときに記録されました
イベントタイプ
explicit
|
|||
|
タイムシート提出済
|
従業員または管理者が給与期間のタイムカードを提出するイベントです。これは、未加工の勤務時間データがより広範な給与計算ワークフローに取り込まれることを示しますが、コア給与計算に流れる前に勤怠管理モジュールで発生することもあります。 | ||
|
その重要性
エンドツーエンドの給与計算サイクルにおける最も早い開始タイムスタンプを設定します。作業実績と給与データ取り込み間の遅延を測定するために不可欠です。
取得元
勤怠管理監査ログまたはタイムカード履歴テーブルで、ステータスフィールドが「提出済み」に変更されたものを取得します。
取得
トランザクションtime_card_submitが実行されたときに記録されました
イベントタイプ
explicit
|
|||
|
データ修正実行済み
|
初回計算後、最終承認前に行われる給与レコードへの手動修正(例:勤務時間調整、税金の変更)です。 | ||
|
その重要性
これは手戻りの主要な測定基準です。これを追跡することで、「手動データ修正率KPI」が有効になります。
取得元
監査ログ内でユーザーIDが「System」ではない、従業員給与詳細または控除テーブルへの更新を取得します。
取得
トランザクションupdate_pay_detailが実行されたときに記録されました
イベントタイプ
explicit
|
|||
|
監査例外フラグ設定
|
システムまたはユーザーが、マイナス給与、税コードの欠落、SLA警告などの不一致を特定することです。これにより、記録は注意が必要な状態になります。 | ||
|
その重要性
「監査例外と修正のトレンド」ダッシュボードに直接反映されます。ここでの高いボリュームは、上流のデータ品質の問題を示します。
取得元
特定の従業員IDに関連するシステム警告ログまたは給与期間メッセージテーブルのレコードを特定します。
取得
トランザクションvalidation_warningが作成されたときに記録されました
イベントタイプ
explicit
|
|||
|
福利厚生控除適用済み
|
システムは、税引前および税引後の福利厚生控除(医療保険、401kなど)を総支給額に適用します。このロジックは通常、総支給額が決定された直後に実行されます。 | ||
|
その重要性
ここでのエラーは手動修正を必要とすることがよくあります。このステップを分離することで、遅延が福利厚生エンジンまたは設定の問題に起因するかどうかを判断できます。
取得元
計算バッチのタイムスタンプ、または従業員控除履歴テーブルの作成タイムスタンプを観察することで推測されます。
取得
フィールド「calculation_stage」の比較から導出
イベントタイプ
inferred
|
|||
|
税金計算済
|
複数州の税計算ロジックが適用され、純支給額が決定される計算エンジンの最終段階です。これにより、自動計算フェーズが完了します。 | ||
|
その重要性
「総支給額から手取り額へ」のシーケンスを完了します。ここでの長い所要時間は、税務エンジンのパフォーマンス問題や、複雑な複数管轄区域設定の問題を示唆しています。
取得元
システムジョブログの計算バッチプロセスの「終了時間」または従業員税務テーブルのタイムスタンプから推測されます。
取得
計算ジョブ終了前後のステータスフィールドを比較
イベントタイプ
inferred
|
|||
|
給与明細公開済
|
給与明細がセルフサービスポータルで従業員に表示されることです。これにより、コミュニケーションループが完了します。 | ||
|
その重要性
技術的にブロックするステップではありませんが、公開の遅れはヘルプデスクへの問い合わせを増加させ、従業員満足度に影響を与えます。
取得元
給与グループ設定における「Check Date」または特定の「Self Service Release Date」設定から推測されます。
取得
フィールド「check_date」と「release_policy」の比較から導出
イベントタイプ
inferred
|
|||
|
給与計算結果プレビュー済
|
ユーザーが給与台帳またはプレビューレポートを開き、計算結果を検証する活動です。これは自動処理から人手によるレビューへの移行を示します。 | ||
|
その重要性
検証フェーズの開始を示します。計算とプレビューの間に長いギャップがある場合、リソースの可用性に関する問題を示唆しています。
取得元
ユーザーが「給与台帳」または「事前チェック」レポートにアクセスした監査ログから取得します。
取得
トランザクションreport_view_previewが実行されたときに記録されました
イベントタイプ
explicit
|
|||
|
総支給額計算済み
|
システムが勤務時間、レート、インセンティブデータに基づいて総支給額を決定する最初の計算実行です。これは控除や税金が適用される前に発生します。 | ||
|
その重要性
ここから「Taxes Calculated(税金計算済み)」までの時間を測定することで、システムパフォーマンス分析に必要な「総支給額から手取り額への計算速度」指標が得られます。
取得元
システムジョブログの計算バッチプロセスの「開始時間」から推測されます。
取得
計算ジョブ開始前後のステータスフィールドを比較
イベントタイプ
inferred
|
|||
|
銀行振込ファイル生成済み
|
銀行への送信のために、NACHAまたは直接預金ファイルを技術的に生成することです。これにより、資金移動の準備が整います。 | ||
|
その重要性
ここでの遅延は、銀行の締め切りを逃す直接的なリスクとなります。「銀行振込生成速度」ダッシュボードをサポートします。
取得元
システムジョブログでACH/直接預金ファイル作成ジョブが完了したときのタイムスタンプを取得します。
取得
トランザクションcreate_ach_fileが実行されたときに記録されました
イベントタイプ
explicit
|
|||