貴社の資産保守データテンプレート

汎用プロセスマイニングテンプレート
貴社の資産保守データテンプレート

貴社の資産保守データテンプレート

汎用プロセスマイニングテンプレート

こちらは資産保全向けの汎用プロセスマイニングデータテンプレートです。より具体的なガイダンスが必要な場合は、システム固有のテンプレートをご利用ください。

特定のシステムを選択
  • 標準的な保全マイルストーンの包括的なリスト
  • 詳細なパフォーマンス分析のために設計された柔軟なアトリビュートスキーマ
  • あらゆる企業資産管理データソースとの完全な互換性
イベントログについて初めての方へ: プロセスマイニングのイベントログ作成方法.

資産保全アトリビュート

これらの推奨データ項目は、イベントログにコンテキストを提供し、設備タイプ、優先度、および場所に基づいて保守作業指示書を分析することを可能にします。
5 必須 9 推奨 2 任意
名前 説明
アクティビティ名
ActivityName
ワークフロー内で発生する特定のタスク、ステータス変更、またはイベント。
説明

この属性は、保守作業指示書のライフサイクル中に取られた手順を定義します。作成済み、承認済み、進行中、保留中、完了済みといった、作業指示書が通過する明確な状態を捕捉します。

正確なプロセスマイニングのために、この項目は様々なシステムイベントを読み取り可能なアクティビティに正規化します。これは、プロセスマップの可視化、ステージ間の移行時間の計算、および作業指示書が以前のステータスに戻る手戻りループの特定に不可欠です。

その重要性

プロセスマップ内のノードを定義し、ワークフローを再構築するために必要です。

取得元

ステータス履歴テーブル、トランザクションログ、または作業指示書変更ログから派生します。

作業指示書作成済み材料発行済み承認済みステータスが「進行中」に変更されました作業指示書クローズ済み
イベントのタイムスタンプ
EventTimestamp
`アクティビティ`が`発生`した`特定`の`日付`と`時刻`です。
説明

この属性は、保守ログ内のすべてのイベントに時間的コンテキストを提供します。ステータスが変更された、またはソースシステムでトランザクションがコミットされた正確な瞬間を記録します。

タイムスタンプは、プロセスマイニングにおけるすべての期間ベースのメトリクスの基礎となります。これらにより、サイクルタイム、リードタイム、およびリソースアイドル時間の計算が可能になります。連続して発生するイベントを適切に順序付けるためには、高精度なタイムスタンプが必要です。

その重要性

イベントの順序付けとすべての期間メトリクスの計算を可能にします。

取得元

活動とともにトランザクションログ、履歴テーブル、または監査証跡で確認できます。

2023-10-15T08:30:00Z2023-10-15T14:45:22Z2023-11-01T09:00:00Z2023-11-02T16:20:15Z
ソースシステム
SourceSystem
レコードの発生元であるアプリケーションまたはデータベースの名前。
説明

この属性は、データを生成したソフトウェア環境を特定します。複雑な保守環境では、データはERP、専門のCMMS、またはIoT監視プラットフォームから供給される場合があります。

分析において、この項目は複数のシステムが単一のプロセスモデルに取り込まれる際にデータをフィルタリングするのに役立ちます。データリネージの検証に貢献し、異なるレガシーシステム間のデータ品質やプロセス変動を比較するために使用できます。

その重要性

マルチシステム環境におけるデータトレーサビリティを保証します。

取得元

抽出プロセス中にハードコードされるか、システム設定からマッピングされます。

SAP ECCIBM MaximoInfor EAMOracle Maintenance CloudHexagon EAM
作業指示書番号
WorkOrderNumber
保守案件または作業指示書の一意の識別子です。
説明

この属性は、プロセスマイニング分析の中心的なケース識別子として機能します。これは、最初の要求または予防的なトリガーから完了および財務上の締めまで、単一のエンドツーエンドの保守サイクルを表します。

分析において、この項目は関連するすべてのイベント、コスト、およびリソースログをグループ化するための主キーとして機能します。これにより、プロセスマイニングエンジンは特定のジョブのライフサイクルを再構築し、アナリストは作業の流れを追跡し、ケースレベルでボトルネックを特定し、特定の成果を作業指示タイプや優先度と関連付けることができます。

その重要性

ユニークなプロセスインスタンスを区別するために必要な、基本的なケースIDです。

取得元

通常、作業指示ヘッダーテーブル(例:MaximoのWONUM、SAPのAUFNR)で見つかります。

WO-2023-884110049221PM-552-AREQ-992104500021
最終データ更新
LastDataUpdate
レコードが最後に抽出または更新された日時を示すタイムスタンプ。
説明

この属性は、分析に使用されるデータセットの通貨を追跡します。これにより、アナリストはデータの鮮度を理解し、運用システムとプロセスマイニング環境間の潜在的なレイテンシーの問題を特定するのに役立ちます。

これは物理的なプロセスフローの一部ではありませんが、データガバナンスにとって非常に重要です。関係者がリアルタイムデータを見ているのか、それとも以前の締め期間のスナップショットを見ているのかを確実に把握できるようにします。

その重要性

データの鮮度検証と増分ロードの管理を支援します。

取得元

実行時にETLパイプラインまたは抽出スクリプトによって生成されます。

2023-12-01T00:00:00Z2023-12-01T12:00:00Z2023-12-02T06:00:00Z
予防保全ですか
IsPreventive
作業指示書が予防保全プログラムの一部であるかどうかを示すフラグです。
説明

このブール属性は、作業指示書タイプを「予防保全」と「非予防保全」という二項分類に簡素化します。多くの場合、作業指示タイプコードから導出されます。

このフラグは、ダッシュボードをフィルタリングしてPMコンプライアンスに焦点を当てる最も速い方法です。また、保守組織の成熟度を測定するための標準的な業界指標であるPM/CM比率KPIの計算を簡素化します。

その重要性

予防保全比率のフィルタリングとKPI計算を簡素化します。

取得元

作業指示書タイプまたは特定のシステムフラグ(例:PPMフラグ)から派生します。

truefalse
作業指示書タイプ
WorkOrderType
保全作業を予防保全、是正保全、緊急保全、またはプロジェクトベースに分類します。
説明

この属性は、保守作業の性質を分類します。一般的な値は、計画的な作業(予防保全)と計画外の停止(是正保全または緊急保全)を区別します。これは、ほぼすべてのEAM/CMMSシステムにおける標準的な項目です。

アナリストはこの項目を使用してプロセスモデルをセグメント化します。緊急修理と予防保全のワークフローを比較すると、多くの場合、プロセスパス、承認要件、およびサイクルタイムが著しく異なることが明らかになります。これは、予防保全と事後保全の比率を計算するための主要なディメンションです。

その重要性

計画作業と計画外作業間の分析をセグメント化するために不可欠です。

取得元

作業指示ヘッダーテーブル(例:MaximoのWORKTYPE、SAPのAUART)。

予防是正緊急予測設備投資プロジェクト
保全部門
MaintenanceDepartment
作業の実行を担当する組織単位または作業場。
説明

この属性は、作業指示書に割り当てられたチーム、職種、または部門(例:電気、機械、計装、設備管理など)を特定します。

このビューは、異なるチーム間のパフォーマンスベンチマークを可能にします。アナリストは、部門間のサイクルタイム、未処理件数、および手戻り率を比較して、特定の職種におけるトレーニングニーズやリソース不足を特定することができます。

その重要性

異なるチーム間でのパフォーマンスとバックログのベンチマークを可能にします。

取得元

作業指示ヘッダー(例:SAPのWork Center、MaximoのCrew ID)。

機械工場電気保全施設Contractor-Ext計装
優先度レベル
PriorityLevel
作業指示書に割り当てられた緊急度または重要度です。
説明

この属性は、保守タスクが運用にとってどれほど重要であるかを示します。値は通常、数値コード(1、2、3)から記述的なラベル(緊急、高、中、低)まで様々です。これは、必要な応答時間とリソース割り当てを決定します。

プロセス分析において、この属性はSLAコンプライアンスの確認に使用されます。アナリストは、優先度の高い項目が実際に優先度の低い項目よりも早くプロセスを通過しているか、あるいは承認のボトルネックで滞っているかを調査します。

その重要性

SLAコンプライアンス分析とリソース優先順位付けチェックを可能にします。

取得元

作業指示ヘッダーテーブル(例:MaximoのPRIORITY、SAPのPRIOK)。

1 - Critical2 - High3 - Medium4 - Low緊急
実労働時間
ActualLaborHours
技術者が作業指示書に費やした総作業時間です。
説明

この属性は、作業指示書に記録されたすべての作業時間の期間を集計します。これは、タスクを完了するために実際に費やされた労力を反映します。

この指標は、人員の稼働率と作業効率を計算するために不可欠です。実績時間と見積もり時間を比較することで、計画プロセスの精度が明らかになります。大きな差異は、不明確な業務範囲やスキルギャップを示している可能性があります。

その重要性

労力を測定し、稼働率と計画精度を計算するために使用されます。

取得元

タイムシートまたは労働取引テーブルから集計されます。

4.512.00.548.0160.0
目標完了日
TargetCompletionDate
作業指示書が完了すべきスケジュールされた期限。
説明

この属性は、スケジューラによって計画された、またはSLAによって定められた期日を表します。これは、納期遵守の計算の参照点として機能します。

実際の完了日とこの目標日を比較することで、スケジュール遵守と遅延メトリクスの計算が可能になります。大きな乖離は、計画の非効率性やリソースの制約を示唆しています。

その重要性

遅延とスケジュールコンプライアンスを計算するためのベースラインです。

取得元

作業指示書スケジューリングタブ(例:SAPのGLTRP、MaximoのSCHEDFINISH)。

2023-11-15T17:00:00Z2023-12-01T08:00:00Z2023-10-30T16:30:00Z
総実績コスト
TotalActualCost
人件費、材料費、サービス費を含む、発生した総費用です。
説明

この属性は、作業指示書に関連するすべての財務計上を合計します。これは、保守活動の最終的な経済的影響を示します。

コスト分析は、資産管理におけるプロセスマイニングの主要な推進要因です。この属性は、保守に最も費用がかかる資産クラスを特定し、修理コストが資産の交換価値を超える外れ値を浮き彫りにするのに役立ちます。

その重要性

財務影響分析と予算差異報告の中心となります。

取得元

コスト集計テーブル、または注文にリンクされたGL仕訳から集計されます。

1500.00245.5010000.000.00560.75
資産ID
AssetId
保守対象の設備または施設の一意の識別子です。
説明

この属性は、作業指示書を現場の物理オブジェクトにリンクさせます。これは、保守対象資産のタグ番号、機器ID、または機械コードを表します。

これは、「不良資産」や頻繁な修理が必要な資産を特定するために不可欠です。資産ID別に作業指示書を集計することで、アナリストは平均故障間隔(MTBF)を計算し、保守予算の不均衡な量を消費する設備を特定することができます。

その重要性

特定の機器のパフォーマンス分析とMTBF計算を可能にします。

取得元

作業指示ヘッダーテーブル(例:MaximoのASSETNUM、SAPのEQUNR)。

PUMP-4410HVAC-BLDG-1CONVEYOR-02FLEET-TRUCK-99CNC-LATHE-05
資産重要度
AssetCriticality
資産の運用上の重要性を示す評価です。
説明

この属性は、故障が安全性、環境、または生産に与える影響に基づいて資産を分類します。これは通常、資産マスターレコード上の静的属性ですが、作業指示書にスナップショットとして頻繁に記録されます。

この属性を使用することで、アナリストは保守チームが重要資産の作業を適切に優先しているかを判断できます。最も重要な設備が予防保全スケジュールに最高レベルで遵守していることを確認するのに役立ちます。

その重要性

保全の焦点をビジネスリスクと運用上の影響に合わせるのに役立ちます。

取得元

資産マスターデータ、または非正規化されている場合は作業指示書ヘッダー。

A - 非常に重要B - 必要不可欠C - 二次的安全上重要生産上重要
割り当てられたリソース
AssignedResource
作業に割り当てられた特定の技術者またはリーダー。
説明

この属性は、保守タスクの実行責任者である個人または主任技術者を特定します。部門がグループを追跡するのに対し、これは特定の個人を追跡します。

この粒度の高さは、スタッフ間の作業負荷配分を分析するのに役立ちます。特定の技術者が常に過負荷になっているか、特定の個人が高い手戻り率を示しているかを浮き彫りにし、トレーニングの必要性を示唆することがあります。

その重要性

ワークロードバランシング分析と個別のパフォーマンスメトリクスを可能にします。

取得元

作業指示書の割り当て、または人件費詳細テーブル。

J. SmithA. DoeTech-001Vendor-XYZチームリーダー5
勤務地
WorkLocation
作業が実施される物理サイトまたは機能ロケーション。
説明

この属性は、資産が存在する地理的または機能的なエリアを定義します。特定の建物、フロア、または遠隔地である場合があります。

位置データは、移動時間の非効率性やロジスティクスを分析するのに役立ちます。もし技術者が優先度の低い作業のために遠隔地間を移動するのにかなりの時間を費やしている場合、プロセスマイニングはより良いルート計画や場所による作業指示書のグループ化の機会を浮き彫りにすることができます。

その重要性

ロジスティクス分析とロケーション固有のボトルネックの特定を支援します。

取得元

作業指示ヘッダーまたはリンクされた資産位置テーブル。

A棟 - 2階北工場サイト55遠隔ポンプステーションワークショップ
必須 推奨 任意

資産保全活動

このセクションでは、正確なプロセスディスカバリとボトルネック特定を確実にするために、データから捕捉すべき不可欠なプロセスステップとマイルストーンの概要を説明します。
7 推奨 9 任意
アクティビティ 説明
作業指示書クローズ済み
作業指示書が財務的にロックされ、アーカイブされる最終管理ステップ。これ以上の費用や労働時間を計上することはできません。
その重要性

システムにおけるケースの絶対的な終了を示します。ここでの遅延は、管理上のバックログを示唆しています。

取得元

ステータスが「クローズ済み」、「アーカイブ済み」、または「CLSD」に変更されたときに捕捉されます。

取得

「クローズ済み」への最終的なステータス変更を捕捉します

イベントタイプ explicit
作業指示書スケジュール済み
作業指示書に特定の労働リソース、チーム、または確定されたカレンダースロットを割り当てること。これにより、オーダーはバックログからアクティブな日次または週次スケジュールに移動します。
その重要性

ジョブがバックログにある時間と、特定の技術者を待機する時間を区別します。

取得元

作業割り当てまたは派遣記録の作成から派生します。

取得

リソースが割り当てられた、またはディスパッチステータスが設定された際のタイムスタンプ

イベントタイプ explicit
作業指示書作成済み
システムにおける保全作業指示書記録の正式な生成。これによりケースIDが確立され、計画、スケジューリング、および実行のベースラインが設定されます。
その重要性

これはプロセスの中心的なアンカーポイントであり、管理上の保守ライフサイクルの開始を定義します。

取得元

メインの作業指示書ヘッダーテーブルの作成タイムスタンプから抽出されます。

取得

ユニークな作業指示書IDが生成されたときのタイムスタンプを記録します

イベントタイプ explicit
作業指示書完了済み
実際の作業が技術的に完了した状態です。資産は運用に戻されますが、管理上の財務処理が残る場合があります。
その重要性

修理期間と資産ダウンタイムの終了を計算するために使用される主要なタイムスタンプ。

取得元

ステータスが「完了」、「TECO」、または「終了」に変更されたときに捕捉されます。

取得

技術的完了を示すステータス変更を捕捉します

イベントタイプ explicit
作業指示書承認済み
作業範囲、費用見積もり、および計画がレビューされ承認されたことを示す承認ステータス変更。作業は現在、実行のためにリリースされています。
その重要性

これは、計画と予算のハードルをクリアするために必要な管理上のリードタイムを測定します。

取得元

通常、ステータスが「承認済み」「リリース済み」「許可済み」に変更された際に記録されます。

取得

承認を示すステータス変更イベントをフィルタリングします

イベントタイプ explicit
作業指示書開始済み
技術者が資産に対する物理的な作業を開始する瞬間。これは計画と待機から実際の実行への移行を示します。
その重要性

平均復旧時間(MTTR)の計算や、管理上の待機時間と作業時間を区別するために不可欠です。

取得元

通常、「進行中」へのステータス変更、または最初の人件費入力のタイムスタンプによって示されます。

取得

「進行中」または「開始済み」へのステータス変更を捕捉します

イベントタイプ explicit
労働時間記録済み
技術者が作業指示書に対して実際に費やした時間を記録します。この活動は、異なるチームメンバーが作業に貢献するにつれて、複数回繰り返されることがよくあります。
その重要性

コスト計算と稼働率分析の基礎を提供します。労働時間入力間のギャップはプロセスの中断を示唆する可能性があります。

取得元

時間確認テーブルまたは労働トランザクションログから抽出されます。

取得

オーダーに対する時間計上の各インスタンスを記録します

イベントタイプ explicit
作業指示書キャンセル済み
正常な完了前の作業指示書の早期終了。これは、作業が不要、重複、または統合されたと判断された場合に発生します。
その重要性

高いキャンセル率は、上流のリクエストのフィルタリングが不十分であるか、重複データ入力の問題を示している可能性があります。

取得元

ステータスが「キャンセル済み」、「却下済み」、または「無効」に変更されたときに捕捉されます。

取得

キャンセルを示す最終ステータス値をフィルタリングします

イベントタイプ explicit
作業指示書保留中
作業指示書のステータスが保留状態に変更され、実行が停止されます。これは通常、部品不足、アクセス不可、または安全上の問題が原因で発生します。
その重要性

標準的なプロセスフローを阻害するボトルネックと外部依存関係を特定します。

取得元

ステータス履歴から明示的に捕捉され、値が「保留」、「一時停止」、または「ブロック済み」に移行したとき。

取得

保留状態を示すステータス変更をフィルタリングします

イベントタイプ explicit
保全リクエスト作成済み
オペレーターまたは自動システムによる不具合報告またはサービスリクエストの初回提出。これはしばしば正式な作業指示書に先行し、需要ライフサイクルの真の開始を示します。
その重要性

このステップを捕捉することで、問題が特定された時点から、保全チームがそれを受理した時点だけでなく、合計応答時間を計算することが可能になります。

取得元

通常、サービス要求ログ、ヘルプデスクのチケット管理テーブル、または通知履歴テーブルで見つかります。

取得

作業指示書にリンクされた上流のリクエストオブジェクトの作成タイムスタンプを抽出します

イベントタイプ explicit
保全手戻り記録済み
完了したジョブが拒否されたか、すぐに失敗し、「進行中」にステータスが戻される必要があることを示します。これはプロセスループを表します。
その重要性

技術トレーニングの問題や低品質な予備部品を示す重要な指標です。

取得元

ステータスが「完了」から「進行中」に後方遷移したとき、または明示的に手戻りコードとして記録されたときに推測されます。

取得

後方ステータス遷移または手戻りフラグを特定します

イベントタイプ inferred
優先度更新
作業指示書が最初に作成された後に、その重要度または緊急度が変更された場合を指します。これにより、新しい優先度の値とその決定時刻が記録されます。
その重要性

頻繁な優先度変更は、劣悪なトリアージプロセスやバックログキューを回避するためのシステム操作を示している可能性があります。

取得元

通常、フィールド監査証跡または優先度フィールドを監視するシステム履歴ログに記録されます。

取得

監査ログ内の優先度フィールドへの変更を特定します

イベントタイプ explicit
品質検査完了
修理が検査、測定、またはテストされる特定の検証ステップです。これにより、資産が運用基準を満たしていることを確認してからサービスに戻します。
その重要性

コンプライアンスおよび安全分析に不可欠です。このステップでの失敗は手戻りループを引き起こします。

取得元

検査ログ、チェックリスト完了、または特定のステータスマイルストーンで確認できます。

取得

検査タスクの完了または品質ステータス更新を特定します

イベントタイプ explicit
材料発行済み
在庫から作業指示書への予備部品の物理的な発行。これにより、材料が利用可能であり消費されたことを確認します。
その重要性

部品が実際に使用されたことを検証し、材料の入手遅延に関する時間を停止します。

取得元

請求タイプが作業指示書にリンクされている在庫トランザクションログで確認できます。

取得

在庫発行トランザクションからタイムスタンプを抽出します

イベントタイプ explicit
材料要求作成済み
予備部品または消耗品の正式な要求が作業指示書にリンクされます。これにより、修理に必要なサプライチェーンのサブプロセスが開始されます。
その重要性

サプライチェーンの依存関係や材料不足による遅延を分析するために不可欠です。

取得元

材料要件テーブル、またはステータスが「材料待ち」に変更されたときに確認できます。

取得

作業指示書にリンクされた材料明細の作成を特定します

イベントタイプ explicit
目標日更新済み
作業指示書の計画開始日または完了日の更新。これは、リソースの可用性や遅延に基づいた期待値の調整を反映しています。
その重要性

期日の変更を追跡することで、KPIが実際のパフォーマンスによって達成されているのか、あるいは単に目標基準を後から動かすことで達成されているのかを特定するのに役立ちます。

取得元

スケジュール開始日または必要日フィールドへの変更を追跡する監査ログで確認できます。

取得

作業指示書の履歴にある日付フィールドの更新を捕捉します

イベントタイプ explicit
推奨 任意

抽出ガイド

プロセスマイニングに必要なデータの取得方法

抽出方法はシステムによって異なります。詳細な手順については、

ETLガイドを読む

または 特定のプロセスとシステムを選択.