貴社の資産保全データテンプレート
貴社の資産保全データテンプレート
- 包括的な分析のための推奨属性
- 監視すべき重要なプロセスマイルストーン
- Oracle向けのシステム固有の抽出ガイド
設備保全属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
ワークフローで発生する`イベント`またはステータス変更の名前。 | ||
|
説明
この アナリストはこれを使用して
その重要性
プロセスフローとイベントの順序を定義するために必要です。
取得元
トランザクション履歴テーブルまたはステータス変更ログから導出されます。
例
保全作業指示作成済み作業指示リリース済み運用完了
|
|||
|
イベントのタイムスタンプ
EventDateTime
|
アクティビティが発生した日時。 | ||
|
説明
この 正確な
その重要性
プロセスのタイムラインを確立するために不可欠です。
取得元
トランザクションテーブル内のCREATION_DATEまたはLAST_UPDATE_DATE列です。
例
2023-10-15T08:30:00Z2023-10-15T09:15:00Z2023-10-16T14:00:00Z
|
|||
|
保全作業指示
WorkOrderNumber
|
保全作業指示の一意の識別子。 | ||
|
説明
作業指示番号は、保全プロセスの 分析において、この
その重要性
プロセスインスタンスのプライマリキーであり、ケース履歴を再構築するために不可欠です。
取得元
WIE_WORK_ORDERS_Bテーブル、WORK_ORDER_NUMBER列
例
WO-2023-0015WO-2023-0089WO-2023-1102
|
|||
|
ソースシステム
SourceSystem
|
`データ`の`発信元``システム`名です。 | ||
|
説明
レコードが抽出された元のソフトウェアまたはデータベースを示します。このコンテキストでは、通常「Oracle Maintenance Cloud」です。 マルチシステム環境でデータ系列を追跡するために不可欠です。
その重要性
複数のシステム環境における
取得元
抽出中にハードコードされます。
例
Oracle Maintenance CloudOracle Cloud ERP
|
|||
|
最終データ更新
LastDataUpdate
|
最新のデータ抽出`タイムスタンプ`。 | ||
|
説明
プロセス これはデータ
その重要性
ユーザーがデータの鮮度を把握できるようにします。
取得元
抽出時のシステム時刻。
例
2023-10-30T12:00:00Z
|
|||
|
作業指示ステータス
WorkOrderStatus
|
作業指示の現在のライフサイクル状態。 | ||
|
説明
未リリース、リリース済み、保留中、完了済み、クローズ済みなど、作業指示のステータスを示します。これにより、まだオープンなケースと完了済みのケースをフィルタリングできます。 ダッシュボードで現在の仕掛かり中(WIP)の作業を可視化し、特定の状態で滞留している指示を特定するために使用されます。
その重要性
作業指示の進捗状況のスナップショットを提供します。
取得元
WIE_WORK_ORDERS_Bテーブル、WORK_ORDER_STATUS_ID列。
例
リリース済み保留中クローズ
|
|||
|
保全タイプ
WorkOrderType
|
作業指示を予防保全、是正保全、または予知保全として分類します。 | ||
|
説明
この これはプロアクティブ保全比率
その重要性
計画保全と事後修理を区別します。
取得元
WIE_WORK_ORDERS_Bテーブル、WORK_ORDER_TYPE_ID列(タイプ定義に結合)。
例
予防的是正保全緊急
|
|||
|
優先度
Priority
|
作業指示に割り当てられた緊急度レベル。 | ||
|
説明
作業指示の重要度(重要、高、中、低など)を示します。これはスケジューリングとリソース割り当てを推進します。 作業指示変換効率ダッシュボードにとって重要であり、重要な障害が正しく優先されることを保証します。
その重要性
目標応答時間とリソース割り当てを決定します。
取得元
WIE_WORK_ORDERS_Bテーブル、WORK_ORDER_PRIORITY_ID列。
例
クリティカル高標準
|
|||
|
実際の完了日
ActualCompletionDate
|
メンテナンス作業が完了した日時。 | ||
|
説明
物理作業の最終完了を記録します。このタイムスタンプは、ライフサイクルの実行フェーズを終了するために使用されます。 これは技術実行サイクル時間の終了点であり、管理遅延時間の開始点です。
その重要性
技術的な実行フェーズの終了を示します。
取得元
WIE_WORK_ORDERS_Bテーブル、COMPLETED_DATEまたはCLOSED_DATE列。
例
2023-10-252023-10-262023-10-27
|
|||
|
実際開始日
ActualStartDate
|
作業が開始された実際の日時。 | ||
|
説明
技術者が実際に作業を開始した時点を記録します。これは多くの場合、「Operation Started(作業開始)」トランザクションによってトリガーされます。 資材調達遅延(終点)およびリソーススケジューリングの柔軟性を計算するために使用されます。
その重要性
計画に対する実行期間を計算するために不可欠です。
取得元
WIE_WORK_ORDERS_Bテーブル、ACTUAL_START_DATE列。
例
2023-10-212023-10-222023-10-23
|
|||
|
担当技術者
AssignedTechnician
|
タスクを実行するために割り当てられた人物またはリソース`グループ`。 | ||
|
説明
作業を担当する技術者のユーザーIDまたは従業員IDを記録します。これはヘッダーレベルまたは作業レベルで割り当てられる場合があります。 技術者稼働率および労働分析で、スキルギャップや過剰に利用されているリソースを特定するために使用されます。
その重要性
リソースのパフォーマンス分析と能力計画を可能にします。
取得元
WIE_OPERATION_RESOURCESテーブルまたは同様の割り当てテーブル。
例
J. スミスTech-005外部請負業者
|
|||
|
組織コード
OrganizationCode
|
保全組織または工場のコード。 | ||
|
説明
保全作業を担当する特定の事業部門、工場、または施設を表します。これにより、地域別または施設ベースのベンチマーキングが可能になります。 異なるサイトや運用単位間のパフォーマンスの違いをマッピングするために使用されます。
その重要性
物理的な場所または事業単位によって分析をセグメント化します。
取得元
WIE_WORK_ORDERS_Bテーブル、ORGANIZATION_ID列。
例
M1NY-PLANTLON-DEPOT
|
|||
|
資産番号
AssetNumber
|
保全対象機器の一意の識別子。 | ||
|
説明
保全作業指示の対象となる特定の物理的な資産または機械を特定します。プロセスを資産階層にリンクさせます。 これは資産再作業頻度KPIにとって非常に重要であり、アナリストが繰り返し故障する機械を特定することを可能にします。
その重要性
保全活動を特定の物理設備にリンクさせます。
取得元
WIE_WORK_ORDERS_Bテーブル、ASSET_ID列(CSI_ITEM_INSTANCESへの結合)。
例
PUMP-101HVAC-Unit-5CONVEYOR-BELT-A
|
|||
|
SLA目標日
SlaTargetDate
|
作業指示が完了しなければならない期限。 | ||
|
説明
優先度と作成日に基づいて計算されます。これは、資産復旧に対するビジネスへのコミットメントを表します。 SLA達成率KPIに利用され、保全がサービス義務を満たしているか判断するために使用されます。
その重要性
適時性の成功基準を定義します。
取得元
通常、カスタムフィールドまたは優先度設定から導出されます。
例
2023-11-012023-11-052023-11-10
|
|||
|
作業指示説明
WorkOrderDescription
|
問題またはタスクを簡潔に記述するテキストです。 | ||
|
説明
依頼者または計画者が問題や必要な作業を記述するためのフリーテキストフィールドです。構造化データでは見落とされがちな文脈を提供します。 テキスト分析や「その他」の作業タイプの手動レビューに役立ちます。
その重要性
メンテナンス作業に対する人間が理解しやすい文脈を提供します。
取得元
WIE_WORK_ORDERS_Bテーブル、WORK_ORDER_DESCRIPTION列。
例
コンベアベルトモーターの交換月次安全点検ポンプAのオイル漏れを修理
|
|||
|
合計費用
TotalCost
|
作業指示で発生した総費用。 | ||
|
説明
作業指示に関連する資材費、労務費、間接費の合計。これは通常、「Maintenance Costs Transferred(保全費用振替)」アクティビティ中に確定されます。 保全計画精度分析で使用され、予算と実際支出を比較します。
その重要性
保全活動の主要な財務指標。
取得元
作業指示IDにリンクされた原価計算モジュールのテーブルです。
例
1500.00250.505000.00
|
|||
|
実績労働時間
ActualLaborHours
|
この作業指示に技術者が費やした総時間。 | ||
|
説明
作業指示の労務 見積もりと実際の労働時間の差異
その重要性
原価計算と労働力の効率性に関する主要な指標です。
取得元
WIE_WORK_ORDER_TRANSACTIONS (リソーストランザクション) から集計されています。
例
4.512.00.75
|
|||
|
手戻り
IsRework
|
この作業指示が繰り返しの修理であるかを示すフラグです。 | ||
|
説明
過去30日以内に同じ資産IDの別の作業指示が完了していた場合にtrueとなるブール値のフラグです。これは計算属性です。 資産の再作業頻度KPIを直接サポートし、品質の低い修理や故障している資産の特定に役立ちます。
その重要性
品質問題と繰り返しの故障を特定します。
取得元
データ変換層で計算されます。
例
truefalse
|
|||
|
要求日
RequestDate
|
最初の保全要求が受領された日付です。 | ||
|
説明
メンテナンスの必要性が最初に特定され、ログに記録された時点を示す 問題の特定から注文作成までの遅延を測定する作業指示変換リードタイム
その重要性
エンドツーエンドのプロセスライフサイクルの開始を示します。
取得元
WIE_WORK_ORDERS_Bテーブル、ソースリクエストリンクから導出。
例
2023-10-012023-10-052023-11-12
|
|||
|
見積労働時間
EstimatedLaborHours
|
作業指示に対する計画労働時間。 | ||
|
説明
計画担当者がその作業にかかると見積もった時間。これは計画フェーズまたはリリースフェーズで設定されます。 実際の労働時間と比較して差異を判断し、将来の計画標準を改善するために使用されます。
その重要性
実行効率を評価するためのベンチマークです。
取得元
WIE_OPERATION_RESOURCESテーブル、計画数量。
例
5.010.01.0
|
|||
|
計画開始日
ScheduledStartDate
|
メンテナンス作業の計画開始日。 | ||
|
説明
作業が開始される予定だった日時。実際開始日と比較することで、スケジュールの遵守状況が明らかになります。 スケジューリングおよび遅延分析で使用され、保全計画の中断を検出します。
その重要性
スケジュール順守と遅延を測定するためのベースラインです。
取得元
WIE_WORK_ORDERS_Bテーブル、PLANNED_START_DATE列。
例
2023-10-202023-10-212023-10-22
|
|||
|
資産カテゴリ
AssetCategory
|
HVAC、フリート、生産ラインなどのタイプへの資産のグループ化。 | ||
|
説明
資産をより広範なグループに分類します。これにより、異なる種類の設備における保全パフォーマンスの高レベル分析が可能になります。 メンテナンスリードタイム概要ダッシュボードで使用され、どの設備クラスが最も遅延を引き起こしているかを特定するのに役立ちます。
その重要性
設備タイプごとの保全パフォーマンスの集計分析を可能にします。
取得元
資産IDに割り当てられた品目カテゴリから導出されます。
例
重機フリート車両施設
|
|||
設備保全活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
作業指示クローズ済み
|
作業指示の最終的な管理上のクローズ。それ以上の費用は発生せず、会計処理のために注文が確定されます。 | ||
|
その重要性
管理ライフサイクルの終了を示します。「完了」から「クローズ」までの時間は、管理上の遅延を表します。
取得元
STATUS_CODEが「CLOSED」に変更されたWIE_WO_STATUS_HISTORYから導出されます。
取得
ステータスフィールドを前後で比較
イベントタイプ
explicit
|
|||
|
作業指示リリース済み
|
作業指示を「下書き」または「未リリース」の状態から「リリース済み」に移行させるステータス変更。このアクションにより、注文に対する資材とリソースの消費が許可されます。 | ||
|
その重要性
計画フェーズの終了と実行開始の承認を示します。ここでの遅延は計画のボトルネックを示します。
取得元
STATUS_CODEが「RELEASED」に変更されたWIE_WO_STATUS_HISTORYから導出されます。
取得
ステータスフィールドを前後で比較
イベントタイプ
inferred
|
|||
|
作業指示完了済み
|
作業指示全体の技術的な完了。これにより、物理資産が修理され、サービス準備が整ったことを意味しますが、財務処理は継続される場合があります。 | ||
|
その重要性
運用上の観点から見たメンテナンス介入の実質的な終了。SLA遵守状況を計算するために使用されます。
取得元
STATUS_CODEが「COMPLETED」に変更されたWIE_WO_STATUS_HISTORYから導出されます。
取得
ステータスフィールドを前後で比較
イベントタイプ
explicit
|
|||
|
作業開始済み
|
作業指示内の特定の作業(例: Op 10, Op 20)の開始。これは、技術作業がタスクに対して開始される正確な瞬間です。 | ||
|
その重要性
「Work Commenced(作業開始)」マイルストーンを表します。実際の作業時間と計画された期間を比較計算するために不可欠です。
取得元
WIE_WO_OPERATIONS_Bのステータス変更、またはその作業の最初のリソーストランザクションタイムスタンプから導出されます。
取得
項目XとYを比較して派生
イベントタイプ
inferred
|
|||
|
保全作業指示作成済み
|
システムによる作業指示`エンティティ`の生成。リクエストから変換されるか、手動で作成されます。この`イベント`はプロセスマイニングの`ケース`IDを確立し、計画および実行の`ベースライン`を設定します。 | ||
|
その重要性
プロセス
取得元
WIE_WORK_ORDERS_BテーブルのCREATION_DATEタイムスタンプを使用して導出されます。
取得
WOヘッダーレコードが作成されたときに記録されます。
イベントタイプ
explicit
|
|||
|
保全要求作成済み
|
セルフサービス`ポータル`または`ヘルプデスク`インターフェースを介した保全リクエストの最初の提出。この`イベント`は、正式な作業指示となる前の故障や必要なサービスの最初の兆候を捉え、通常はWork Requestsテーブルに見られます。 | ||
|
その重要性
保全需要サイクルの真の開始を示します。故障の特定から実行可能な作業指示の生成までのリードタイムを計算するために不可欠です。
取得元
MNT_WORK_REQUESTSテーブルのCREATION_DATEフィールドを使用して導出されます。
取得
Work Requestsテーブルにレコードが挿入されたときに記録されます。
イベントタイプ
explicit
|
|||
|
記録された労働時間
|
技術者が作業指示に費やした時間の記録。これは、保全活動に対して費用が発生するトランザクション`イベント`です。 | ||
|
その重要性
工数とコストの累積を追跡します。このタイプの複数の
取得元
WIE_RESOURCE_TRANSACTIONSテーブルから導出されます。
取得
トランザクションX実行時にログ記録
イベントタイプ
explicit
|
|||
|
資材発行済み
|
特定の作業指示に対して倉庫から発行された在庫の実際の引き落とし。これは、部品が保全場所へ物理的に移動したことを表します。 | ||
|
その重要性
作業開始準備が整ったことを示す具体的な兆候です。「リリース済み」イベントと比較することで、倉庫でのピッキングプロセスにおける遅延を浮き彫りにします。
取得元
TRANSACTION_SOURCE_TYPE_IDが作業指示にリンクされているINV_MATERIAL_TXNSテーブルから導出されます。
取得
トランザクションX実行時にログ記録
イベントタイプ
explicit
|
|||
|
作業指示キャンセル済み
|
作業指示が成功裏に完了する前の終了。作業が重複していたり、不要だったり、統合された場合に発生する可能性があります。 | ||
|
その重要性
高いキャンセル率を特定することで、要求受付プロセスや重複検出ロジックの問題が明らかになる場合があります。
取得元
STATUS_CODEが「CANCELED」に変更されたWIE_WO_STATUS_HISTORYから導出されます。
取得
ステータスフィールドを前後で比較
イベントタイプ
explicit
|
|||
|
作業指示保留中
|
作業指示のステータスが「保留中」に変更され、実行が停止されます。これは通常、部品の不足、アクセス不能、または安全上の問題により発生します。 | ||
|
その重要性
プロセス非効率の主な原因です。保留の頻度と期間を特定することは、全体的なリードタイムの短縮に不可欠です。
取得元
STATUS_CODEが「ON_HOLD」に変更されたWIE_WO_STATUS_HISTORYから導出されます。
取得
ステータスフィールドを前後で比較
イベントタイプ
explicit
|
|||
|
作業指示割り当て済み
|
特定の開始日または特定のリソース(技術者/ツール)を作業指示の作業に割り当てること。これにより、システム内の計画されたスケジュール日付が更新されます。 | ||
|
その重要性
ディスパッチまたはスケジューリングチームの効率を測定します。リリースとスケジューリングの間にギャップがある場合、リソースの競合を示唆します。
取得元
WIE_OPERATION_RESOURCESまたはWIE_WO_OPERATIONS_Bのスケジューリング列への更新から導出されます。
取得
ステータスフィールドを前後で比較
イベントタイプ
inferred
|
|||
|
保全費用転送済み
|
メンテナンスシステムからコスト管理`モジュール`への累積コストの転送。これは財務決済として機能します。 | ||
|
その重要性
保全の財務的影響が認識されたことを確認します。「保全計画精度」分析に不可欠です。
取得元
作業指示トランザクションソースにリンクされた原価会計配賦テーブルから導出されます。
取得
トランザクションX実行時にログ記録
イベントタイプ
inferred
|
|||
|
品質検査記録済み
|
保全作業指示に関連する品質結果の入力。これにより、修理が安全および運用基準を満たしていることを検証します。 | ||
|
その重要性
コンプライアンスを確保します。完了前の品質チェックの欠落は、安全上のリスクやプロセスの逸脱を示唆する可能性があります。
取得元
作業指示IDにリンクされたQA_RESULTSまたは類似の品質収集計画テーブルから導出されます。
取得
トランザクションX実行時にログ記録
イベントタイプ
explicit
|
|||
|
資材割り当て済み
|
必要なスペアパーツと構成部品を作業指示に予約または割り当てること。これにより、作業開始前に在庫が利用可能であることを保証します。 | ||
|
その重要性
サプライチェーンの準備状況を分析する上で重要です。このステップが遅延する場合、在庫不足や調達計画の遅れを示唆します。
取得元
CREATION_DATEまたはALLOCATION_DATEに基づいてWIE_WO_COMPONENTS_Bテーブルから導出されます。
取得
トランザクションX実行時にログ記録
イベントタイプ
explicit
|
|||
|
運用完了
|
ルーティングにおける特定のステップ(作業)の完了。技術作業の特定の部分が完了したことを示します。 | ||
|
その重要性
進捗状況をきめ細かく可視化します。「保全タスク実行済み」は通常、最終作業の完了から導出されます。
取得元
WIE_WO_OPERATIONS_Bのステータス変更、または完了を示すトランザクション履歴から導出されます。
取得
ステータスフィールドを前後で比較
イベントタイプ
inferred
|
|||