汎用データテンプレート
汎用データテンプレート
- あらゆるプロセスに対応する汎用的な構成
- 用途に合わせて調整できる柔軟な属性
- 主要なソースシステムに対応
これは汎用のプロセスマイニング用データテンプレートです。より詳しい手順については、プロセス別のテンプレートをご利用ください。
属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ Activity | 発生したプロセスのステップまたはイベントの名前です。 | ||
| 説明 アクティビティ項目は、プロセスの各時点で何が起きたかを示します。アクティビティには一貫した名前を付け、業務上意味のあるイベントを表すようにしてください。 重要な理由 アクティビティ名によって、プロセスマップの表示方法や分析内容が決まります。 入手先 ソースシステムのステータス変更、アクションの種類、イベントの説明から特定してください。 例 ケース作成レビュー完了支払い処理完了 | |||
| ケースID CaseId | 各プロセスインスタンスを一意に識別するIDです。 | ||
| 説明 ケースIDは、同じプロセスインスタンスに属するすべてのイベントを結び付ける基本の識別子です。イベントログ内の各イベントには、ケースIDが必要です。 重要な理由 適切なケースIDがないと、プロセス内の個々のケースの流れを追跡できません。 入手先 主要な取引テーブルの主キーまたは参照番号を使用してください。 例 ORD-2024-001234TKT-98765REQ-0042 | |||
| タイムスタンプ StartTime | アクティビティの開始時刻です。日付と時刻を含めてください。 | ||
| 説明 タイムスタンプは、各アクティビティが発生した時刻を記録します。サイクルタイムの算出、ボトルネックの特定、イベントの順序の把握に欠かせません。 重要な理由 タイムスタンプがあれば、サイクルタイムの分析やボトルネックの検出など、時間に基づく分析ができます。 入手先 ソースシステムで取得できる、最も正確なタイムスタンプを使用してください。 例 2024-03-15T09:30:00Z2024-03-15T14:45:30Z | |||
| ケース種別 CaseType | 処理対象となるケースのカテゴリまたは種類です。 | ||
| 説明 ケースを種類別に分類し、カテゴリごとに比較できます。ケースの種類によって、プロセスの経路やパフォーマンスが異なることがよくあります。 重要な理由 ケースの種類ごとに分類して分析すると、カテゴリ間のパフォーマンスの違いが明らかになります。 入手先 種類コード、カテゴリ項目、分類属性を探します。 例 標準優先複雑 | |||
| ユーザー User | アクティビティを実行した担当者です。 | ||
| 説明 各アクティビティを実行したユーザーまたはリソースを特定します。リソース分析、作業負荷の平準化、パフォーマンスの比較に役立ちます。 重要な理由 リソース分析により、研修の必要性や作業負荷の偏りを特定できます。 入手先 各イベントに関連付けられたユーザーID、従業員番号、またはユーザー名を確認してください。 例 ジョン・スミス従業員番号12345ユーザー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 | ケースがどのように開始または受け付けられたかを示します。 | ||
| 説明 ケースがプロセスに入ったチャネルを特定します。チャネルごとに特性やパフォーマンスが異なることがよくあります。 重要な理由 チャネル分析により、どの受付方法が最も効率的か明らかになります。 入手先 ソースを示す項目、チャネルコード、発生元の項目を探します。 例 ウェブポータルメール電話API | |||
| リソース Resource | アクティビティを実行したリソース(人またはシステム)です。 | ||
| 説明 人が実行したか自動処理されたかを問わず、アクティビティの実行主体を示す汎用の識別子です。人とシステムのどちらもアクティビティを実行する場合に役立ちます。 重要な理由 リソースを追跡することで、人による処理と自動処理のパフォーマンスを比較できます。 入手先 ユーザーとシステムアカウントの両方を含む可能性がある、実行主体の識別子を探します。 例 user_123AUTO_SYSTEMbot_processor | |||
| 事業部門 BusinessUnit | ケースに関連付けられた事業部門です。 | ||
| 説明 ケースを担当する、またはケースに関連する事業部門や部門を特定します。複数の事業部門を持つ組織で役立ちます。 重要な理由 事業部門分析により、組織をまたいだパフォーマンスの傾向が明らかになります。 入手先 事業部門コード、部門の識別子、利益センターの割り当てを探します。 例 小売エンタープライズSMB | |||
| 最終データ更新日時 LastDataUpdate | このレコードが最後に更新された日時です。 | ||
| 説明 このレコードが最後に更新された日時を示すタイムスタンプです。データの増分読み込みや鮮度の追跡に役立ちます。 重要な理由 更新を追跡すると、データの増分読み込みや品質の監視に役立ちます。 入手先 最終更新日時のタイムスタンプや変更追跡の項目を探します。 例 2024-03-15T12:00:00Z2024-03-16T08:30:00Z | |||
| 国 Country | ケースに関連付けられた国です。 | ||
| 説明 ケースに関係する地理的な場所です。地域ごとのプロセスパフォーマンスやコンプライアンス要件の違いを分析する際に役立ちます。 重要な理由 地理分析により、地域ごとの違いやコンプライアンスの傾向が明らかになります。 入手先 国コード、地域の識別子、所在地の項目を探します。 例 米国ドイツ日本 | |||
| 地域 Region | ケースの地理的な地域です。 | ||
| 説明 国より広い範囲を示す地理的な区分です。複数の国にまたがって業務を行う場合の地域分析に役立ちます。 重要な理由 地域分析により、地理的な区域ごとのパフォーマンスを把握できます。 入手先 地域コードを探すか、国の情報から地域を割り出します。 例 欧州・中東・アフリカ南北アメリカアジア太平洋 | |||
| 自動化コスト ActivityAutomationCost | このアクティビティを自動化した場合のコストです。 | ||
| 説明 このアクティビティを自動化して実行する場合の推定コストです。自動化の投資対効果分析に役立ちます。 重要な理由 手作業と自動化のコストを比較すると、導入の必要性を説明しやすくなります。 入手先 通常、自動化されたプロセスの標準コストモデルに基づいて設定します。 例 0.502.005.00 | |||
| 自動化済みかどうか IsAutomated | アクティビティが自動で実行されたかどうかです。 | ||
| 説明 アクティビティがシステムによる自動処理か、ユーザーによる手作業かを示します。自動化の状況を把握するうえで欠かせません。 重要な理由 自動化分析により、さらなる自動化の機会が明らかになります。 入手先 ユーザーの種類(システムまたは人)や自動化フラグから判定します。 例 truefalse | |||
| 製品 Product | ケースに関連する製品またはサービスです。 | ||
| 説明 ケースに関連する製品、サービス、提供内容を特定します。製品単位でプロセスパフォーマンスを分析できます。 重要な理由 製品分析により、製品によってプロセスの特性が異なるかどうかが明らかになります。 入手先 製品コード、SKU、サービスの識別子を探します。 例 製品AサービスプランProSKU-12345 | |||
| 顧客 Customer | ケースに関連する顧客または取引先です。 | ||
| 説明 ケースに関連する顧客、取引先、外部関係者を特定します。顧客を軸にプロセスパフォーマンスを分析できます。 重要な理由 顧客分析により、顧客体験の傾向が明らかになります。 入手先 顧客ID、口座番号、取引先の識別子を探します。 例 CUST-001234Acme CorpACC-98765 | |||
| 顧客セグメント CustomerSegment | 顧客のセグメントまたは階層です。 | ||
| 説明 顧客をセグメント、階層、価値で分類します。顧客セグメントによってサービス水準が異なるか分析する際に役立ちます。 重要な理由 セグメント分析により、価値の高い顧客が適切に対応されているか確認できます。 入手先 セグメントコード、階層の割り当て、顧客分類の項目を探します。 例 エンタープライズSMB消費者 | |||
アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| ケース作成 | プロセスで新しいケースを開始する最初のイベントです。顧客からの依頼、社内の必要性、自動イベントなどをきっかけに、新しい業務がシステムに登録された時点を示します。 | ||
| 重要な理由 プロセスの正式な開始を示し、サイクルタイム全体と処理量の算出に欠かせません。 入手先 ソースシステムで、作成日時、申請日、初期ステータスの変更を確認します。 記録 主要な取引またはレコードの作成タイムスタンプ イベントタイプ explicit | |||
| ケース完了 | ケースが正常に完了し、クローズされた状態です。プロセスインスタンスの終了を示します。 | ||
| 重要な理由 サイクルタイムと処理量の算出に欠かせません。完了率から、プロセスの有効性を把握できます。 入手先 完了のタイムスタンプ、クローズ済みのステータス、最終結果の記録を確認します。 記録 完了またはクローズのタイムスタンプ イベントタイプ explicit | |||
| データ検証 | 必要な情報がそろっており、正確であることを確認する工程です。システムによる自動チェックの場合も、担当者による手動確認の場合もあります。 | ||
| 重要な理由 早い段階で検証を行うと、後工程での問題や手戻りを防げます。この工程がない場合、サイクルタイムが長くなる傾向があります。 入手先 検証ステータスの変更、確認タイムスタンプ、品質チェックの完了記録を確認します。 記録 ステータス変更または検証完了のタイムスタンプ イベントタイプ explicit | |||
| レビュー完了 | レビューまたは承認の工程が完了した状態です。多くのプロセスでは、次に進む前に1回以上のレビューが必要です。 | ||
| 重要な理由 レビュー工程は、よくボトルネックになります。レビューにかかる時間を把握すると、承認の遅れを特定できます。 入手先 承認のタイムスタンプ、レビュー完了記録、承認記録を確認します。 記録 承認またはレビュー完了のタイムスタンプ イベントタイプ explicit | |||
| 処理開始 | ケースの実作業が始まります。キューでの待機から、実際の処理に移った時点を示します。 | ||
| 重要な理由 割り当てから処理開始までの時間差から、キューでの待ち時間や業務量の問題が分かります。 入手先 作業開始を示すステータス変更、最初の対応のタイムスタンプ、アクティビティログの記録を確認します。 記録 割り当て後の最初のアクティビティ、または明示的な開始タイムスタンプ イベントタイプ inferred | |||
| 担当者への割り当て | ケースを特定の担当者またはチームに割り当て、処理を進める責任者を決めます。 | ||
| 重要な理由 割り当ての効率は、業務の開始速度に影響します。ここでの遅延は、振り分けや業務量に問題があることを示します。 入手先 システムで、割り当ての変更、担当者の変更、キューへの登録を確認します。 記録 割り当てまたは担当者の変更タイムスタンプ イベントタイプ explicit | |||
| アクションの実行 | プロセス内の特定のアクションまたはタスクが完了した状態です。 | ||
| 重要な理由 個々のアクションを追跡すると、サイクルタイムに最も影響する工程を特定できます。 入手先 タスク完了のタイムスタンプ、アクションログ、工程の完了記録を確認します。 記録 タスクまたはアクション完了のタイムスタンプ イベントタイプ explicit | |||
| エスカレーション | ケースを上位の担当者または専門チームに引き継いだ状態です。 | ||
| 重要な理由 エスカレーションは、通常の手順では対応できないケースを示します。発生率が高い場合は、トレーニングやプロセスに問題がある可能性があります。 入手先 エスカレーション記録、担当階層の変更、専門チームのキューへの移管を確認します。 記録 エスカレーションのタイムスタンプ、または専門チームのキューへの移管記録 イベントタイプ explicit | |||
| ケースのキャンセル | ケースが完了前にキャンセルまたは放棄された状態です。 | ||
| 重要な理由 キャンセルの傾向から、プロセス設計、顧客ニーズ、前工程の問題が見えてきます。 入手先 キャンセルのタイムスタンプ、放棄のステータス、終了記録を確認します。 記録 キャンセルまたは終了のタイムスタンプ イベントタイプ explicit | |||
| 例外の発生 | 特別な対応やエスカレーションが必要な問題または例外が特定された状態です。 | ||
| 重要な理由 例外は、手戻りや遅延につながることが少なくありません。記録を追跡すると、根本原因や予防策を特定できます。 入手先 エラーログ、例外フラグ、エスカレーション記録、特別対応を示す項目を確認します。 記録 システムログに記録された例外またはエラーのタイムスタンプ イベントタイプ explicit | |||
| 情報の依頼 | 顧客、取引先、社内関係者に追加情報を依頼した状態です。 | ||
| 重要な理由 情報を依頼するとプロセスが中断し、大幅な遅延につながることがあります。依頼を減らすことで、サイクルタイムを短縮できます。 入手先 依頼に関する連絡記録、「情報待ち」へのステータス変更、保留のタイムスタンプを確認します。 記録 依頼のタイムスタンプ、または待機状態へのステータス変更 イベントタイプ explicit | |||
| 情報の受領 | 依頼した追加情報を受け取り、ケースを再開できる状態です。 | ||
| 重要な理由 情報依頼への回答時間は、サイクルタイムに大きく影響します。回答が早ければ、完了までの時間を短縮できます。 入手先 回答の受領記録、保留状態からのステータス変更、文書のアップロード日時を確認します。 記録 回答受領のタイムスタンプ、または待機状態からのステータス変更 イベントタイプ explicit | |||
| 意思決定 | プロセスの重要な意思決定に達し、決定が確定した状態です。 | ||
| 重要な理由 意思決定には承認が必要な場合が多く、ボトルネックになることもあります。決定の経緯を明確に記録すると、コンプライアンスの確保に役立ちます。 入手先 決定記録、承認・却下のフラグ、結果の確定記録を確認します。 記録 意思決定のタイムスタンプ、または結果の記録 イベントタイプ explicit | |||
データ抽出ガイド
データの抽出方法はシステムによって異なります。詳しい手順は、
利用を始めませんか?
このテンプレートを出発点としてダウンロードするか、お使いの技術に合わせて検証済みの抽出クエリを掲載した、システムごとのガイドをご覧ください。
今日からプロセスの最適化を始める
ProcessMindで、これまで見えなかったプロセスの実態を明らかにしましょう
クレジットカード不要