データテンプレート: 汎用プロセス
汎用データテンプレート
- あらゆるプロセスに対応する普遍的な構造
- お客様のニーズに合わせて適応する柔軟な属性
- 主要なすべてのソースシステムと互換性があります
こちらは汎用プロセスマイニングデータテンプレートです。より具体的なガイダンスが必要な場合は、プロセス固有のテンプレートをご利用ください。
属性
| 名前 | 説明 | ||
|---|---|---|---|
アクティビティ Activity | 発生したプロセスステップまたはイベントの名前。 | ||
説明 アクティビティフィールドは、プロセス内の各ポイントで何が起こったかを識別します。アクティビティは一貫した名称を持ち、意味のあるビジネスイベントを表す必要があります。 その重要性 アクティビティ名によって、プロセスがどのように可視化され、分析されるかが決まります。 取得元 ソースシステム内のステータス変更、アクションタイプ、またはイベント記述から導出します。 例 案件作成レビュー完了支払処理済み | |||
タイムスタンプ StartTime | アクティビティが開始した時間。日付と時刻を含める必要があります。 | ||
説明 タイムスタンプは、各アクティビティがいつ発生したかを記録します。これは、サイクルタイムの計算、ボトルネックの特定、およびイベントのシーケンスの理解に不可欠です。 その重要性 タイムスタンプは、サイクルタイムやボトルネックの検出を含む、すべての時間ベースの分析を可能にします。 取得元 ソースシステムから利用可能な最も正確なタイムスタンプを使用してください。 例 2024-03-15T09:30:00Z2024-03-15T14:45:30Z | |||
案件ID CaseId | 各プロセスインスタンスの一意の識別子。 | ||
説明 ケースIDは、同じプロセスインスタンスに属するすべてのイベントを結びつける基本的な識別子です。イベントログ内の各イベントにはケースIDが必要です。 その重要性 適切なケースIDがなければ、プロセス内の個々のケースの流れを追跡することは不可能です。 取得元 主要なトランザクションテーブルから主キーまたは参照番号を使用してください。 例 ORD-2024-001234TKT-98765REQ-0042 | |||
ケース種別 CaseType | 処理中のケースのカテゴリまたはタイプです。 | ||
説明 ケースを種類別に分類することで、異なるカテゴリ間の比較が可能になります。ケースタイプが異なれば、プロセスパスやパフォーマンスも異なることがよくあります。 その重要性 ケースタイプ別にセグメント化することで、カテゴリ間のパフォーマンスの違いが明らかになります。 取得元 タイプコード、カテゴリフィールド、または分類属性を探してください。 例 標準優先度複雑 | |||
ユーザー User | アクティビティを実行した担当者。 | ||
説明 各アクティビティをどのユーザーまたはリソースが実行したかを特定します。これにより、リソース分析、ワークロード分散、パフォーマンス比較が可能になります。 その重要性 リソース分析は、トレーニングの必要性や作業負荷の不均衡を特定するのに役立ちます。 取得元 各イベントに関連付けられたユーザーID、従業員番号、またはユーザー名を探してください。 例 john.smithEMP-12345user_a1b2c3 | |||
優先度 Priority | ケースに割り当てられた優先度レベル。 | ||
説明 各ケースの緊急度または重要度を示します。優先度は、ケースの処理速度やたどる経路に影響を与えることがよくあります。 その重要性 優先度分析により、緊急のケースが適切に処理されていることを確認できます。 取得元 優先度を示すフィールド、緊急度を示す指標、またはSLA(サービス品質保証契約)のティア割り当てを探してください。 例 高中低 | |||
終了日時 EndTime | アクティビティが終了した時間(開始時間と異なる場合)。 | ||
説明 終了タイムスタンプは、各アクティビティがいつ完了したかを記録します。開始時間と終了時間の両方を含めることで、アクティビティの期間と処理時間を計算できます。 その重要性 終了時刻により、実際の作業時間と待機時間の比較計算が可能になります。 取得元 活動の完了を示す完了タイムスタンプまたはステータス変更時刻を探してください。 例 2024-03-15T10:15:00Z2024-03-15T16:30:00Z | |||
部署 Department | アクティビティを担当する組織単位。 | ||
説明 各アクティビティをどの部門、チーム、または事業部門が処理したかを特定します。チーム間の引き継ぎ分析に役立ちます。 その重要性 部門横断的な分析により、引き継ぎの遅延や組織間の摩擦が明らかになります。 取得元 部門コードまたは組織単位識別子を探してください。 例 財務運用カスタマーサービス | |||
SLA状態 SLAState | ケースがSLAの範囲内であるか、範囲外であるか。 | ||
説明 ケースが現在、サービスレベル契約を満たしているかを示します。コンプライアンス監視やエスカレーション分析に役立ちます。 その重要性 SLA追跡は、リスクのあるケースと全体のコンプライアンス率を特定します。 取得元 SLA(サービス品質保証契約)ステータスフィールド、違反指標を探すか、タイムスタンプと目標値から計算してください。 例 SLA内リスクあり違反 | |||
アクティビティCO2 ActivityCO2 | このアクティビティのカーボンフットプリントです。 | ||
説明 このアクティビティに関連する炭素排出量。プロセスのサステナビリティ分析に活用できます。 その重要性 CO2トラッキングは、サステナビリティ目標と環境報告をサポートします。 取得元 アクティビティタイプと標準排出係数から算出します。 例 0.10.52.0 | |||
アクティビティFTE ActivityFTE | この活動におけるFTE(フルタイム当量)時間 | ||
説明 このアクティビティにおけるFTE時間換算の労力。キャパシティプランニングとワークロード分析に役立ちます。 その重要性 FTEの追跡は、リソース計画と能力管理に役立ちます。 取得元 処理時間と標準FTEレートから計算するか、勤怠管理システムから抽出します。 例 0.250.51.0 | |||
アクティビティコスト ActivityCost | このアクティビティを実行するためのコストです。 | ||
説明 このアクティビティの実行に関連する金銭的コスト。コスト分析と高コストなプロセスステップの特定を可能にします。 その重要性 コスト分析は、財務的影響に基づいた改善の優先順位付けに役立ちます。 取得元 コスト配分フィールドを探すか、標準原価表から計算してください。 例 15.0045.50120.00 | |||
アクティビティ金額 ActivityAmount | このアクティビティに関連付けられた金額。 | ||
説明 このアクティビティによって処理または影響を受ける金銭的価値。価値加重分析を可能にします。 その重要性 価値分析は、財務的影響に基づいて改善の優先順位付けに役立ちます。 取得元 取引金額、請求額、または注文合計を探してください。 例 1500.0025000.00750.50 | |||
ソースシステム SourceSystem | このイベントが発生したシステム。 | ||
説明 どのソースシステムがこのイベントを記録したかを特定します。複数のシステムからデータを結合する場合に役立ちます。 その重要性 ソース追跡は、データの出所やシステム境界を理解するのに役立ちます。 取得元 定数として追加するか、抽出元から導出します。 例 SAPSalesforceServiceNow | |||
チーム Team | 部署内の特定のチーム。 | ||
説明 部署よりも詳細な組織のグループ化です。部署内で複数のチームがプロセスの異なる部分を担当する場合に役立ちます。 その重要性 チームレベルの分析は、作業負荷の配分と専門化のパターンを明らかにします。 取得元 チームコード、キュー識別子、またはグループ割り当てを探してください。 例 チームアルファエスカレーションティア2サポート | |||
チャネル Channel | ケースが開始または受付された方法。 | ||
説明 ケースがプロセスに入ったチャネルを特定します。チャネルによって特性やパフォーマンスが異なることがよくあります。 その重要性 チャネル分析により、どの受付方法が最も効率的であるかが明らかになります。 取得元 ソースインジケーター、チャネルコード、または発信元フィールドを探してください。 例 Webポータルメール電話番号API | |||
ビジネスユニット BusinessUnit | このケースに関連する事業部門です。 | ||
説明 どの事業部門または部署がこのケースを担当または関連しているかを特定します。多部門にわたる組織で役立ちます。 その重要性 事業部門ごとの分析により、組織横断的なパフォーマンスパターンが明らかになります。 取得元 事業部門コード、部門識別子、またはプロフィットセンターの割り当てを探してください。 例 小売エンタープライズSMB | |||
プロダクト Product | このケースに関連する製品またはサービスです。 | ||
説明 どの製品、サービス、または提供物がこのケースに関連しているかを特定します。製品レベルでのプロセスパフォーマンス分析が可能になります。 その重要性 製品分析により、特定の製品間でプロセス特性に違いがあるかが明らかになります。 取得元 製品コード、SKU、またはサービス識別子を探してください。 例 製品AサービスプランProSKU-12345 | |||
リソース Resource | アクティビティを実行したリソース(担当者またはシステム)。 | ||
説明 アクティビティを実行した主体(人間または自動化されたシステム)を特定する汎用的な識別子です。アクティビティが人手またはシステムの両方によって実行される場合に役立ちます。 その重要性 リソース追跡により、人間と自動化されたパフォーマンスの比較が可能になります。 取得元 実行者識別子を探してください。これには、ユーザーアカウントとシステムアカウントの両方が含まれる場合があります。 例 user_123AUTO_SYSTEMbot_processor | |||
最終データ更新 LastDataUpdate | このレコードが最後に更新された日時。 | ||
説明 このレコードの最新更新のタイムスタンプ。増分データロードと鮮度追跡に役立ちます。 その重要性 更新の追跡は、増分ロードとデータ品質監視をサポートします。 取得元 最終更新タイムスタンプまたは変更履歴フィールドを探してください。 例 2024-03-15T12:00:00Z2024-03-16T08:30:00Z | |||
処理時間 ProcessingTime | アクティビティの期間を分または秒で示します。 | ||
説明 アクティビティに実際に費やされた時間。開始時間と終了時間から計算することも、システムが追跡している場合は直接提供することもできます。 その重要性 処理時間を理解することで、最も多くの労力を消費するアクティビティを特定するのに役立ちます。 取得元 終了時刻から開始時刻を引いて計算するか、システム内の期間フィールドから抽出します。 例 4512015 | |||
国 Country | ケースに関連付けられた国です。 | ||
説明 このケースに関連する地理的位置。プロセスパフォーマンスの地域差やコンプライアンス要件の分析に役立ちます。 その重要性 地域分析により、地域ごとの差異やコンプライアンスパターンが明らかになります。 取得元 国コード、地域識別子、または場所フィールドを探してください。 例 アメリカ合衆国ドイツ日本 | |||
地域 Region | このケースの地域 | ||
説明 国よりも広い地理的な区分です。複数の国にまたがる事業の地域分析に役立ちます。 その重要性 地域ごとの分析は、地域間のパフォーマンスの違いを理解するのに役立ちます。 取得元 地域コードを探すか、国情報から導き出してください。 例 EMEAアメリカ大陸APAC | |||
自動化 IsAutomated | アクティビティが自動的に実行されたかどうか。 | ||
説明 この活動が自動化(システムによる)されたか、手動(ユーザーによる)だったかを示します。自動化レベルを理解する上で不可欠です。 その重要性 自動化分析により、さらなる自動化の機会が明らかになります。 取得元 ユーザータイプ(システムか人間か)や自動化フラグから導出します。 例 truefalse | |||
自動化コスト ActivityAutomationCost | このアクティビティが自動化された場合のコストです。 | ||
説明 このアクティビティを自動化で実行する場合の推定コスト。自動化のROI分析に役立ちます。 その重要性 手動と自動化のコストを比較することは、ビジネスケース構築に役立ちます。 取得元 通常、自動化されたプロセスに対する標準コストモデルから割り当てられます。 例 0.502.005.00 | |||
顧客 Customer | ケースに関連付けられた顧客または関係者です。 | ||
説明 ケースに関連する顧客、クライアント、または外部関係者を特定します。これにより、顧客中心のプロセスパフォーマンス分析が可能になります。 その重要性 顧客分析により、顧客体験におけるパターンが明らかになります。 取得元 顧客ID、口座番号、または取引先識別子を探してください。 例 CUST-001234アクメ株式会社ACC-98765 | |||
顧客セグメント CustomerSegment | 顧客のセグメントまたはティアです。 | ||
説明 顧客をセグメント、階層、または価値で分類します。異なる顧客セグメントが異なるサービスレベルを受けているかどうかの分析に役立ちます。 その重要性 セグメント分析は、高価値顧客が適切な対応を受けていることを確認するのに役立ちます。 取得元 セグメントコード、ティア割り当て、または顧客分類フィールドを探してください。 例 エンタープライズSMB消費者 | |||
アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
ケース完了 | ケースは正常に完了し、クローズされました。これはプロセスインスタンスの終了を示します。 | ||
その重要性 サイクルタイムやスループットの算出に不可欠です。完了率はプロセスの有効性を示します。 取得元 完了タイムスタンプ、クローズステータス、または最終結果の記録を探してください。 取得 完了またはクローズのタイムスタンプ イベントタイプ explicit | |||
データ検証済み | 必要な情報が完全かつ正確であることの検証。これは自動化されたシステムチェックである場合もあれば、チームメンバーによる手動レビューである場合もあります。 | ||
その重要性 早期検証は、後工程での問題や手戻りを防ぎます。このステップが欠落すると、サイクルタイムの長期化と相関することがよくあります。 取得元 妥当性確認のステータス変更、検証のタイムスタンプ、または品質チェックの完了記録を探してください。 取得 ステータス変更またはバリデーション完了のタイムスタンプ イベントタイプ explicit | |||
レビュー完了 | レビューまたは承認ステップが完了しました。多くのプロセスでは、次に進む前に1回以上のレビューが必要です。 | ||
その重要性 レビューのステップは、一般的なボトルネックです。レビュー期間を理解することは、承認遅延を特定するのに役立ちます。 取得元 承認タイムスタンプ、レビュー完了、または承認記録を探してください。 取得 承認またはレビュー完了タイムスタンプ イベントタイプ explicit | |||
処理開始 | ケースの作業が開始されました。これにより、キューでの待機から実際の処理へと移行します。 | ||
その重要性 割り当てから処理開始までのギャップは、キューの待ち時間やワークロードの問題を明らかにします。 取得元 作業開始を示すステータス変更、初回接触のタイムスタンプ、またはアクティビティログのエントリを探してください。 取得 割り当て後、または明示的な開始タイムスタンプ後の最初の活動 イベントタイプ inferred | |||
担当者へ割り当て済み | ケースは特定の担当者またはチームに処理のために割り当てられます。この割り当てにより、ケースを前進させる責任者が決定されます。 | ||
その重要性 割り当ての効率は、作業開始の速さに影響します。ここでの遅延は、ルーティングまたはワークロードの問題を示します。 取得元 システム内の割り当て変更、所有者変更、またはキューへのエントリを探してください。 取得 割り当てまたは所有者変更タイムスタンプ イベントタイプ explicit | |||
案件作成 | プロセス内で新しいケースを開始する初期イベント。顧客からのリクエスト、社内ニーズ、自動イベントなど、どのようなきっかけで新しい作業インスタンスがシステムに投入されたかを示すものです。 | ||
その重要性 プロセスの正式な開始を示し、総サイクルタイムとスループットの計算に不可欠です。 取得元 ソースシステムで作成タイムスタンプ、提出日、または初期ステータス変更を探してください。 取得 プライマリトランザクションまたはレコードからの作成タイムスタンプ イベントタイプ explicit | |||
アクション実行済み | プロセス内の特定の行動またはタスクが完了しました。 | ||
その重要性 個々のアクションを追跡することで、どの具体的なステップがサイクルタイムに最も影響しているかを特定できます。 取得元 タスク完了のタイムスタンプ、アクションログ、またはステップ完了の記録を探してください。 取得 タスクまたはアクション完了のタイムスタンプ イベントタイプ explicit | |||
エスカレート済み | ケースは、より高いレベルまたは専門チームにエスカレーションされ、処理されました。 | ||
その重要性 エスカレーションは、通常の対応では処理できないケースを示します。高いエスカレーション発生率は、トレーニングやプロセスの課題を示唆しています。 取得元 エスカレーション記録、階層変更、または専門チームへの転送を探してください。 取得 エスカレーション日時、または専門チームへの引き継ぎ日時 イベントタイプ explicit | |||
ケースキャンセル済み | ケースは完了前にキャンセルまたは中止されました。 | ||
その重要性 キャンセルパターンを分析することで、プロセス設計、顧客ニーズ、または上流工程の問題点が明らかになります。 取得元 キャンセルタイムスタンプ、放棄ステータス、または終了記録を探してください。 取得 キャンセルまたは終了のタイムスタンプ イベントタイプ explicit | |||
例外発生 | 特別な対応やエスカレーションが必要な問題または例外が特定されました。 | ||
その重要性 例外は手戻りや遅延の主要因となることが多く、これを追跡することで根本原因の特定と発生防止の機会を見出せます。 取得元 エラーログ、例外フラグ、エスカレーション記録、または特別処理インジケーターを探してください。 取得 システムログからの例外またはエラーのタイムスタンプ イベントタイプ explicit | |||
情報の追加依頼 | 顧客、ベンダー、または社内の関係者から追加情報が要求されました。 | ||
その重要性 情報要求はプロセスを中断させ、しばしば大幅な遅延を引き起こします。これを最小限に抑えることでサイクルタイムが改善します。 取得元 リクエストのやり取り、ステータスの「情報待ち」への変更、または保留のタイムスタンプを探してください。 取得 リクエストのタイムスタンプ、または待機状態へのステータス変更 イベントタイプ explicit | |||
情報受領 | 要求された追加情報を受領し、ケースは続行できます。 | ||
その重要性 情報リクエストへの応答時間は、サイクルタイムに大きく影響します。迅速な応答は、より迅速な完了を可能にします。 取得元 応答の受領、保留中からのステータス変更、または文書アップロードのタイムスタンプを探してください。 取得 応答受領タイムスタンプ、または待機状態からのステータス変更 イベントタイプ explicit | |||
決定済み | プロセスにおける重要な意思決定点に到達し、解決されました。 | ||
その重要性 意思決定ポイントは承認を要し、ボトルネックとなることがあります。明確な決定履歴はコンプライアンスをサポートします。 取得元 決定記録、承認/却下フラグ、または結果の確定を探してください。 取得 決定タイムスタンプまたは結果の記録 イベントタイプ explicit | |||
