お客様の資産メンテナンスデータテンプレート
お客様の資産メンテナンスデータテンプレート
- メンテナンス属性の包括的なリスト
- 追跡すべき重要なプロセスマイルストーン
- 詳細な技術抽出ガイダンス
資産メンテナンス属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ Activity | 作業指示書ライフサイクルで発生した特定のイベントまたはステータス変更。 | ||
| 説明 この属性は、「作業指示書承認済み」や「労働時間記録済み」など、メンテナンスプロセスで実行されたステップを表します。IBM Maximoでは、これは通常、履歴テーブルのステータス変更や労働時間報告などの特定のトランザクションログから派生します。 これはプロセスマップのノードを形成し、ステップのシーケンスを可視化することを可能にします。これらの値を分析することで、組織はプロセスバリアント、ループ、および標準的なメンテナンス手順からの逸脱を特定できます。 その重要性 プロセスマップの作成とワークフロー実行の理解に不可欠な、プロセスの「何を」定義します。 取得元 テーブル: WOSTATUS (列: STATUS) または WOLOG 例 APPRINPRGCOMPCLOSEWMATL | |||
| イベントのタイムスタンプ EventTimestamp | 活動が発生した具体的な日時です。 | ||
| 説明 この属性は、ステータス変更や労働時間の記録など、イベントが発生した正確な瞬間を記録します。これにより、リードタイムや期間計算を含むすべてのパフォーマンス分析に必要な時間的次元を提供します。 正確なタイムスタンプは、「平均計画および承認リードタイム」の計算とイベントの正しいシーケンスを確保するために不可欠です。Maximoでは、これは通常、ステータスレコードの変更日です。 その重要性 イベントを時系列で並べ、すべての時間ベースのKPIを計算するために必要です。 取得元 テーブル: WOSTATUS、列: CHANGEDATE 例 2023-10-12T08:30:00Z2023-10-12T14:15:00Z2023-10-13T09:00:00Z | |||
| メンテナンス作業指示書 WorkOrderNumber | メンテナンス作業指示書の一意の英数字識別子。 | ||
| 説明 この属性は、メンテナンスプロセスの中央ケース識別子として機能します。IBM Maximoシステム内の各作業指示書を一意に区別し、関連するすべてのアクティビティ、労働トランザクション、資材使用状況を単一の実行済み作業にリンクさせます。 プロセスマイニング分析では、このIDは個々のイベントをまとまったケースにグループ化するために使用されます。これにより、アナリストは最初の要求作成から承認、実行、最終的な管理上の完了に至るまで、メンテナンス作業のエンドツーエンドのライフサイクルを追跡できます。 その重要性 プロセスフローを再構築するための基本的な鍵であり、部門横断的な特定のジョブの追跡を可能にします。 取得元 テーブル: WORKORDER、列: WONUM 例 WO100234WO100235CM-99281PM-11002 | |||
| ソースシステム SourceSystem | `データ`の`発信元``システム`名です。 | ||
| 説明 データレコードのソースアプリケーションを特定します。この文脈では、通常「IBM Maximo」となります。複数のメンテナンスシステムからのデータを結合したり、ERPデータと統合したりする場合に特に役立ちます。 プロセスマイニングプロジェクトが複数のCMMSインスタンスを含む複雑なシステムランドスケープにまたがる場合、アナリストは記録システムによってビューをフィルタリングできます。 その重要性 マルチシステム環境におけるデータリネージとトレーサビリティを確保します。 取得元 抽出時にハードコード 例 IBM MaximoMaximo PRODMaximoレガシー | |||
| 最終データ更新 LastDataUpdate | データが抽出された、または最後に更新されたタイムスタンプ。 | ||
| 説明 プロセスマイニングのためにレコードが最後に処理または抽出された時期を示します。これにより、データの鮮度と信頼性を評価し、分析がメンテナンス運用の最新の状態を反映していることを保証するのに役立ちます。 この属性は、増分データロードにとって不可欠であり、ダッシュボードが作業指示のステータスとバックログに関する最新情報を表示していることを検証するためにも重要です。 その重要性 データの遅延と鮮度を理解する上で重要です。 取得元 抽出時のシステム時刻 例 2023-11-01T00:00:00Z2023-11-01T12:00:00Z | |||
| 作業指示書タイプ WorkType | 作業指示を予防 (PM)、是正 (CM)、または緊急 (EM) に分類します。 | ||
| 説明 この属性は、メンテナンス作業の性質を分類します。Maximoにおける一般的な値には、PM(予防メンテナンス)、CM(是正メンテナンス)、EM(緊急メンテナンス)があります。この分類は、「プロアクティブ対リアクティブメンテナンス」ダッシュボードの基盤となります。 この属性でフィルタリングすることで、アナリストは「緊急メンテナンス比率」KPIを計算し、事後的な火消しから計画的な信頼性作業へとメンテナンス戦略がどのように変化しているかを特定できます。 その重要性 計画的作業と非計画的作業を区別し、メンテナンス成熟度の重要な指標となります。 取得元 テーブル: WORKORDER、列: WORKTYPE 例 PMCMEMCP修正 | |||
| 優先度 Priority | 作業指示書に割り当てられた緊急度レベル。 | ||
| 説明 作業指示の重要性と緊急性を示す数値またはカテゴリ値です。Maximoでは、通常、数値が小さいほど緊急性が高いことを示します (例: 1 = 緊急)。 この属性は、バックログでの作業の優先順位付けに使用され、「重要資産SLAパフォーマンス」ダッシュボードに不可欠です。優先度の高い作業が、優先度の低いタスクと比較して、必要な速度で実際に処理されているかを判断するのに役立ちます。 その重要性 組織が最も緊急なタスクにリソースを集中しているかどうかを分析できます。 取得元 テーブル: WORKORDER、列: WOPRIORITY 例 1234 | |||
| 実際の労働時間 ActualLaborHours | すべての技術者が作業指示書に費やした合計実働時間。 | ||
| 説明 作業指示書に対して記録されたすべての労働時間の集計。この指標は、リソース稼働率の現実的な検証となります。「技術者稼働率差異」KPIをサポートします。 人件費の計算や、特定のタスクの実際の実行にかかる時間に関する過去のデータを提供することで、将来の作業計画を改善するために使用されます。 その重要性 人件費および効率分析の主要な指標。 取得元 テーブル: WORKORDER、列: ACTLABHRS 例 2.55.012.0 | |||
| 実際の完了日 ActualFinishDate | 物理的な作業が完了した日時。 | ||
| 説明 メンテナンス作業が技術的に完了した時期を記録します。これはチケットの管理上のクローズとは異なります。この日付を「目標完了日」と比較することで、SLAコンプライアンスを計算できます。 「作業指示書管理リードタイム」ダッシュボードで使用され、作業完了からシステムでの事務処理完了までの遅延を測定します。 その重要性 技術実行フェーズの終了をマークします。 取得元 テーブル: WORKORDER、列: ACTFINISH 例 2023-10-15T16:00:00Z2023-10-16T10:30:00Z | |||
| 担当技術者 AssignedResource | 作業の実行に割り当てられた特定の担当者または主任技術者。 | ||
| 説明 作業指示の責任者である個人または主任技術者を特定します。これは「担当」フィールドで見つけるか、労働割り当てから導き出すことができます。「リソースおよび請負業者生産性」ダッシュボードを有効にします。 この属性を分析することで、「メンテナンスワークロード分散」ビューにおけるワークロードの不均衡を特定し、異なる技術者またはクルー間の効率性を比較することができます。 その重要性 労働力生産性の分析とワークロードのバランス調整の鍵となります。 取得元 テーブル: WORKORDER、列: LEAD (またはASSIGNMENTテーブルから) 例 JSMITHBPATELMRODRIGUEZ | |||
| 現在のステータス Status | 作業指示書の現在のライフサイクル状態。 | ||
| 説明 作業指示書の現在の管理ステータス(例:'APPR'、'WAPPR'、'COMP')。アクティビティ属性が変更履歴を捕捉するのに対し、この属性は最終的な既知の状態を捕捉します。 データセットをフィルタリングして「オープン」な注文と「クローズ済み」の注文のみを表示するのに役立ち、「メンテナンス作業負荷配分」分析をサポートします。 その重要性 現在の作業負荷とバックログのスナップショットを提供します。 取得元 テーブル: WORKORDER、列: STATUS 例 APPRCLOSEINPRG | |||
| 目標完了日 TargetCompletionDate | 作業指示書の予定または必須の期限。 | ||
| 説明 作業指示書が完了予定の期日。これは通常、優先順位と生成日に基づいて計算されます。「重要資産SLAパフォーマンス」ダッシュボードのベンチマークとして機能します。 このフィールドを「実際の完了日」と比較することで、アナリストは納期遵守率を判断し、どの資産カテゴリが頻繁にメンテナンス期間を逸脱しているかを特定できます。 その重要性 SLA遵守およびスケジュールコンプライアンスを測定するためのベースライン。 取得元 テーブル: WORKORDER、列: TARGCOMPDATE 例 2023-10-20T17:00:00Z2023-10-25T08:00:00Z | |||
| 資産番号 AssetNumber | メンテナンス対象機器または資産の一意の識別子。 | ||
| 説明 メンテナンス作業の対象となる特定の機械、車両、または施設コンポーネント。これはプロセスデータを物理的な資産階層に接続します。「バッドアクター」—頻繁に故障する資産—を特定するために不可欠です。 「メンテナンス品質と手戻り率」分析で使用されるこの属性は、資産ごとの作業指示書を集計して平均故障間隔(MTBF)を計算し、慢性的な信頼性問題を特定することを可能にします。 その重要性 プロセス実行と物理インフラのパフォーマンスを連携させます。 取得元 テーブル: WORKORDER、列: ASSETNUM 例 PUMP-101HVAC-02FLEET-99 | |||
| 資産重要度 AssetCriticality | 資産が事業運営にとってどれほど重要かを示すスコアです。 | ||
| 説明 資産レコードに存在する分類 (通常1~10またはA/B/C) で、故障の結果を示します。これは作業指示ビューに結合する必要があります。 この属性は「重要資産SLAパフォーマンス」ダッシュボードに必須です。これにより、分析が最も重要な事項に焦点を当てるようにします。つまり、重要な発電機の遅延は、休憩室のコーヒーメーカーの遅延よりも重く評価されます。 その重要性 ビジネスリスク別にプロセスパフォーマンスをセグメント化できます。 取得元 テーブル: ASSET、列: PRIORITY (ASSETNUM経由で結合) 例 1510 | |||
| SLA違反 IsSlaBreached | 実際の完了日が目標日を超過したかどうかを示すフラグです。 | ||
| 説明 「実際の完了日」と「目標完了日」を比較するブール型の計算フィールドです。実績が目標よりも大きい場合、値は真となります。 この事前計算されたメトリックにより、「重要資産SLAパフォーマンス」ダッシュボードが簡素化され、実行時に日付計算を行うことなく、失敗したSLAの数を即座に把握できます。 その重要性 パフォーマンスコンプライアンスの即時可視化。 取得元 ACTFINISHとTARGCOMPDATEから計算 例 truefalse | |||
| サイトID SiteId | 複数サイトのMaximo実装における高レベルのサイト識別子。 | ||
| 説明 大規模組織では、Maximoはしばしば「サイト」によって分割されます。この属性は、データベースレベルで異なる工場や施設を区別します。 「標準メンテナンスプロセスコンプライアンス」分析において、異なる事業部門間のパフォーマンスをベンチマークする上で不可欠であり、比較が正しい運用コンテキスト内で行われることを保証します。 その重要性 マルチサイト展開でのデータ範囲設定に不可欠です。 取得元 テーブル: WORKORDER、列: SITEID 例 ベッドフォードナシュアテキサス | |||
| 仕入先 Vendor | 該当する場合、作業指示書に割り当てられた第三者請負業者。 | ||
| 説明 メンテナンス作業を担当する外部企業を特定します。これは作業がアウトソーシングされた場合に設定されます。「請負業者実行効率」KPIにとって極めて重要です。 この属性の分析により、メンテナンス組織は異なるベンダーのパフォーマンス (コスト、速度、品質) を互いに比較し、また内部チームと比較することができます。 その重要性 ベンダー管理とアウトソーシングパフォーマンス分析を可能にします。 取得元 テーブル: WORKORDER、列: VENDOR 例 ACMEサービスシーメンスファーストリペア株式会社 | |||
| 報告日 ReportedDate | 問題が最初に報告された、またはリクエストが作成された日時。 | ||
| 説明 メンテナンスの必要性が最初に特定され、システムに入力された時点を示すタイムスタンプ。これは顧客体験タイムラインの真の開始点となります。 この報告日から作業が実際に開始されるまでの期間を測定することで、「平均計画および承認リードタイム」を計算するために使用されます。これにより、メンテナンス組織の応答性を評価するのに役立ちます。 その重要性 メンテナンスライフサイクル全体の応答性の開始ラインを確立します。 取得元 テーブル: WORKORDER、列: REPORTDATE 例 2023-10-10T08:00:00Z2023-10-10T09:15:00Z | |||
| 場所 Location | 作業が実行される機能的なロケーションまたは物理的なサイト。 | ||
| 説明 資産が存在する物理的な領域または機能ロケーションコードを指定します。これは特定の資産番号よりも広範であり、地理的またはゾーン分析に役立ちます。 「メンテナンス作業負荷配分」ダッシュボードで使用され、メンテナンスアクティビティのホットスポットを可視化し、サイト間を移動する技術者のロジスティクスを計画するために利用されます。 その重要性 ロジスティクスとリソース配分の地理空間的コンテキストを提供します。 取得元 テーブル: WORKORDER、列: LOCATION 例 BRILER-RMPLANT-AOFFICE-1 | |||
| 推定労働時間 EstimatedLaborHours | 作業指示書に必要な計画された労働時間。 | ||
| 説明 計画フェーズ中にタスクを完了するために見積もられた合計時間数。これは「労働力見積もり精度ダッシュボード」で「実際の人件費」と比較されます。 この値と実測値との間に大きな差異がある場合、計画の不備、標準作業手順の欠如、または予期せぬ資産状態により想定以上の作業が必要になったことを示しています。 その重要性 計画精度とリソース予測を評価するために不可欠です。 取得元 テーブル: WORKORDER、列: ESTLABHRS 例 2.04.58.0 | |||
| 故障コード FailureCode | 資産が故障した理由を説明する標準化されたコード。 | ||
| 説明 技術者が選択する構造化されたコードで、故障の原因を分類します (例:「摩耗」、「電気的」、「オペレーターエラー」)。これは根本原因分析 (RCA) に不可欠です。 これらのコードを集約することで、エンジニアリングチームは資産ベース全体でシステム的な問題を特定し、「メンテナンス品質と手直し率」分析を推進し、予防メンテナンス戦略の変更を通知するのに役立ちます。 その重要性 信頼性エンジニアリングと故障分析のための主要なデータポイント。 取得元 テーブル: WORKORDER、列: FAILURECODE 例 漏れオーバーヒート振動 | |||
| 緊急 IsEmergency | 作業指示が緊急であるかどうかを示すフラグです。 | ||
| 説明 作業タイプまたは優先度に基づいて計算されるブール型フラグです。作業タイプが「EM」(緊急) であるか、優先度が1の場合に真となります。 この簡略化された属性により、ダッシュボードでのフィルタリングが容易になり、視覚化レイヤーで複雑なロジックを使用することなく、「緊急メンテナンス比率」を分離できます。 その重要性 リアクティブメンテナンス分析のためのフィルタリングを簡素化します。 取得元 WORKTYPEから計算 例 truefalse | |||
| 総実費 TotalActualCost | 作業指示書の人件費、資材費、サービス費、工具費の合計。 | ||
| 説明 メンテナンス作業の総財務的影響を表します。Maximoでは、これは様々なコスト構成要素(人件費 + 資材費 + サービス費 + 工具費)の合計です。 この属性により、コストベースのプロセスマイニングが可能となり、プロセスの非効率性(遅延や手戻りなど)を財務損失と直接関連付けることができます。最も高額なメンテナンスタイプや資産クラスを特定するのに役立ちます。 その重要性 運用活動と財務実績を連携させます。 取得元 テーブル: WORKORDER、列: ACTMATCOST + ACTLABCOST + ACTSERVCOST + ACTTOOLCOST 例 150.002500.500.00 | |||
資産メンテナンスアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| メンテナンスリクエスト作成済み | システム内で作業指示書が生成される最初のイベントで、多くの場合、サービスリクエストまたは自動スケジュールから発生します。これは、WORKORDERテーブルの作成タイムスタンプまたはWOSTATUS履歴の初期エントリから明示的に取得されます。 | ||
| その重要性 プロセスインスタンスの開始をマークし、総解決時間と初期対応の応答性を測定するためのベースラインを設定します。 取得元 WORKORDER.REPORTDATE または WOSTATUSテーブルの初期エントリ(通常ステータスはWAPPR) 取得 トランザクションが作業指示書レコードを作成した際に記録 イベントタイプ explicit | |||
| 作業指示書キャンセル | 作業が不要、重複、または不可能と判断されたため、プロセスが途中で終了します。これは最終状態です。 | ||
| その重要性 作業指示キャンセル分析ダッシュボードにフィードします。高率のキャンセルは、要求生成における上流プロセス障害を示します。 取得元 STATUS = 'CAN' のWOSTATUSテーブル 取得 トランザクションのステータスがCANに変更された際に記録 イベントタイプ explicit | |||
| 作業指示書クローズ済み | 作業指示書が財務的に決済され、読み取り専用となる最終的なライフサイクルイベント。それ以上の請求はできません。 | ||
| その重要性 管理リードタイムの終了をマークします。ここでの遅延は財務報告に影響します。 取得元 STATUS = 'CLOSE' のWOSTATUSテーブル 取得 トランザクションのステータスがCLOSEに変更された際に記録 イベントタイプ explicit | |||
| 作業指示書完了済み | 技術者が物理的な作業の完了を承認します。このステータス変更により、実行時間のKPIの計測が停止します。 | ||
| その重要性 技術実行の主要な終了タイムスタンプ。SLAコンプライアンスと技術者稼働率の計算に使用されます。 取得元 STATUS = 'COMP' のWOSTATUSテーブル 取得 トランザクションのステータスがCOMPに変更された際に記録 イベントタイプ explicit | |||
| 作業指示書承認済み | 作業指示が必要な計画および財務承認チェックを通過したことを示します。これはシステム履歴におけるステータス変更から導出されます。 | ||
| その重要性 計画および承認リードタイムKPIを計算する上で重要です。ここでの遅延は、管理上のボトルネックを示します。 取得元 STATUS = 'APPR' のWOSTATUSテーブル 取得 APPR移行を特定するために、ステータスフィールドを前後で比較する イベントタイプ explicit | |||
| 作業開始 | 技術者による物理作業の実際の開始をマークします。これは、ユーザーがステータスを作業中を示すものに変更した際に明示的に記録されます。 | ||
| その重要性 計画時間と実行時間を区別するための重要なマイルストーンです。平均計画・承認リードタイムの計算に使用されます。 取得元 STATUS = 'INPRG' のWOSTATUSテーブル 取得 トランザクションのステータスがINPRGに変更された際に記録 イベントタイプ explicit | |||
| リソーススケジュール済み | 特定の労働力またはクルーが作業指示書に割り当てられる時点。これは、割り当てが生成されたとき、またはステータスが「スケジュール待ち」に移行したときに追跡されます。 | ||
| その重要性 利用可能な技術者を見つけるのにかかった時間を分離することで、計画および承認サイクル分析ダッシュボードをサポートします。 取得元 ASSIGNMENTテーブルに行が作成された、またはWOSTATUSが「WSCH」に変更された場合 取得 WOにリンクされた割り当てレコードの作成から導出する イベントタイプ inferred | |||
| 労働時間記録済み | 特定の作業指示書に技術者が実際に費やした時間の入力を示します。異なる技術者が貢献する場合、1つの作業指示書に対して複数のエントリが発生することがあります。 | ||
| その重要性 労働見積精度ダッシュボードに、見積もりと比較するための実績を提供します。 取得元 作業指示書にリンクされたLABTRANSテーブルの各エントリ 取得 LABTRANSでトランザクションが発生した際に記録 イベントタイプ explicit | |||
| 品質チェック失敗 | 完了した作業がレビュー中に却下され、ステータスが「進行中」に戻される場合に発生します。手戻りループを表します。 | ||
| その重要性 プロセス障害を強調することで、「メンテナンス品質と手直し率」ダッシュボードを直接サポートします。 取得元 WOSTATUSがCOMPからINPRGまたはWAPPRに戻る遷移から推論 取得 WOSTATUS履歴フィールドを比較して、後方遷移から導出する イベントタイプ inferred | |||
| 検査完了 | ライフサイクル中に安全性または技術的な検査が実施されたことを示します。これはしばしばステータス変更またはチェックリスト測定の完了によって示されます。 | ||
| その重要性 安全とコンプライアンス文書ダッシュボードにとって重要です。規制手順が省略されていないことを保証します。 取得元 WOSTATUSが'INSP'または類似のカスタムステータスに変更される、またはMEASUREMENTエントリの完了 取得 ステータスフィールドを前後で比較 イベントタイプ inferred | |||
| 目標日付更新 | 予定完了日またはSLAターゲットの変更を記録します。これにより、遅延に対応するために期待値がいつ変更されたかを特定するのに役立ちます。 | ||
| その重要性 重要資産SLAパフォーマンスの分析や、SLA違反を回避するために日付が変更される「不正行為」を特定するために重要です。 取得元 TARGETCOMPDATEまたはSCHEDFINISHフィールドの監査証跡 取得 トランザクションが日付フィールドを更新した際に記録 イベントタイプ explicit | |||
| 資材払い出し | 在庫から作業指示書への部品の物理的な消費または払い出しを記録します。これにより、部品が利用可能であり、使用されていることを確認します。 | ||
| その重要性 サプライチェーンプロセスを検証し、メンテナンス介入の総費用分析に影響を与えます。 取得元 ISSUETYPE = 'ISSUE' のMATUSETRANSテーブル 取得 MATUSETRANSでトランザクションが発生した際に記録 イベントタイプ explicit | |||
| 資材要求提出済み | メンテナンス作業に必要なスペアパーツや消耗品が要求されたことを示します。これは、ステータスが「資材待ち」に変更されたり、資材所要明細が作成されたりすることで推測できます。 | ||
| その重要性 資材準備ダッシュボードにとって不可欠であり、作業実行を妨げるサプライチェーンの遅延を特定します。 取得元 STATUS = 'WMATL' のWOSTATUSテーブル、またはWPMATERIALテーブルでのエントリ作成 取得 WMATLへのステータス変更から推論 イベントタイプ inferred | |||
抽出ガイド
ステップ
データベースビュー戦略の確立: ProcessMindはフラットなイベントログを必要とし、Maximoはデータを階層的に (WORKORDERにヘッダー、WOSTATUSに履歴、WOLABTRANSにコスト) 保存するため、最も堅牢な方法は、まずMaximoデータベースにデータベースビューを作成することです。このビューが統合フレームワークのソースとして機能します。
SQLビューの作成: データベース管理ツール (SQL Developer、SSMS) 内で、クエリセクションに提供されているSQLを実行します。これにより、
WORKORDER、WOSTATUS、WOLABTRANS、MATUSETRANS、およびA_WORKORDER(監査) が単一のフラットな構造に統合されます。Maximoへのビューの登録: 管理者としてMaximoにログインします。システム構成、プラットフォーム構成、データベース構成に移動します。
PM_WO_EVENTLOGという名前の新しいオブジェクトを作成します。これを前のステップで作成したデータベースビューにマッピングします。ConfigDBを実行して登録します (通常、ビューのダウンタイムは不要ですが、手順を確認してください)。オブジェクト構造の作成: 統合、オブジェクト構造に移動します。
MX_PM_EVENTSという名前の新しいオブジェクト構造を作成します。PM_WO_EVENTLOGをソースオブジェクトとして追加します。利用可能であれば、フラット構造のサポートがチェックされていることを確認してください。公開チャネルの設定: 統合、公開チャネルに移動します。
MX_PM_EVENTSオブジェクト構造に関連付けられた新しいチャネルPC_PM_EVENTSを作成します。これにより、必要に応じて処理ルールを定義できます。外部システムの設定: 統合、外部システムに移動します。ターゲットシステムを選択 (または汎用EXTSYSを作成) します。
PC_PM_EVENTS公開チャネルをこのシステムに追加します。データエクスポートの有効化: 外部システムアプリケーションで、データエクスポート機能タブを使用します。
PC_PM_EVENTSチャネルを選択します。エクスポート範囲を制限するために、ここでSQL Where句 (例:EVENTTIMESTAMP >= '2023-01-01') を指定できます。データのエクスポート: エクスポートをクリックします。システムはファイル (構成されているエンドポイントに応じてXMLまたはCSV) を生成します。ProcessMindの場合、CSVが推奨されます。エンドポイント (例:
MXFLATFILE) がCSVを出力するように構成されていることを確認してください。出力の検証: 生成されたCSVファイルを開きます。ヘッダーがクエリで定義された属性 (WorkOrderNumber、Activityなど) と一致し、階層的なXMLタグが残っていないことを確認してください。
最終フォーマット: MaximoのCSVエクスポートに標準システムメタデータ列 (例:
OWNER1、ORGID) が含まれている場合、不要であればそれらを削除します。クリーニングされたCSVをProcessMindにロードします。
設定
- Maximoステータス同義語: Maximoではカスタムステータスコード (例: APPR, WAPPR) を使用できます。クエリは標準の内部値を想定しています。カスタムステータスを正しくマッピングするには、お使いのシステムの
WOSTATUSドメインのSYNONYMDOMAINを確認してください。 - 監査テーブル: 「目標日更新」の抽出は
A_WORKORDER監査テーブルに依存しています。WORKORDERオブジェクトに対して監査が有効になっていない場合、この特定のアクティビティは行を生成しません。重要であれば、データベース設定で監査を有効にしてください。 - 日付範囲: 初期ロードの場合、
EVENTTIMESTAMPで過去6〜12ヶ月間にわたってフィルタリングしてください。大規模な履歴ロードは、統合フレームワークのWebインターフェースを介してタイムアウトする可能性があります。5万行を超えるデータセットにはバックグラウンド処理を使用してください。 - サイト/組織フィルター: Maximoはマルチサイトシステムです。プロセス分析が特定の施設にスコープされている場合は、常に
SITEIDでフィルタリングしてください。 - パフォーマンス:
UNION ALLクエリはリソースを大量に消費します。WOSTATUS.WONUM、WOLABTRANS.REFWO、MATUSETRANS.REFWOにデータベースインデックスが存在することを確認してください。
a クエリ例 config
/* Create a Database View or Run directly to extract Event Log */
/* 1. Maintenance Request Created */
SELECT
W.WONUM AS WorkOrderNumber,
'Maintenance Request Created' AS Activity,
W.REPORTDATE AS EventTimestamp,
'Maximo' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate,
W.WORKTYPE AS WorkType,
W.WOPRIORITY AS Priority,
W.ASSETNUM AS AssetNumber,
W.LEAD AS AssignedResource,
W.ACTFINISH AS ActualFinishDate,
W.TARGCOMPDATE AS TargetCompletionDate,
0 AS ActualLaborHours,
W.ASSETLOCPRIORITY AS AssetCriticality,
W.STATUS AS Status
FROM WORKORDER W
WHERE W.REPORTDATE IS NOT NULL
UNION ALL
/* 2. Status Driven Activities (Approved, Scheduled, Commenced, Completed, Closed, Cancelled, etc.) */
SELECT
S.WONUM AS WorkOrderNumber,
CASE
WHEN S.STATUS = 'APPR' THEN 'Work Order Approved'
WHEN S.STATUS = 'WMATL' THEN 'Material Requisition Submitted'
WHEN S.STATUS = 'WSCH' THEN 'Resources Scheduled'
WHEN S.STATUS = 'INPRG' THEN 'Work Commenced'
WHEN S.STATUS = 'INSP' THEN 'Inspection Completed' /* Verify Synonym */
WHEN S.STATUS = 'COMP' THEN 'Work Order Completed'
WHEN S.STATUS = 'REJECT' THEN 'Quality Check Failed' /* Verify Synonym */
WHEN S.STATUS = 'CLOSE' THEN 'Work Order Closed'
WHEN S.STATUS = 'CAN' THEN 'Work Order Cancelled'
ELSE 'Status Change: ' || S.STATUS
END AS Activity,
S.CHANGEDATE AS EventTimestamp,
'Maximo' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate,
W.WORKTYPE AS WorkType,
W.WOPRIORITY AS Priority,
W.ASSETNUM AS AssetNumber,
S.CHANGEBY AS AssignedResource,
W.ACTFINISH AS ActualFinishDate,
W.TARGCOMPDATE AS TargetCompletionDate,
0 AS ActualLaborHours,
W.ASSETLOCPRIORITY AS AssetCriticality,
S.STATUS AS Status
FROM WOSTATUS S
JOIN WORKORDER W ON S.WONUM = W.WONUM AND S.SITEID = W.SITEID
WHERE S.STATUS IN ('APPR', 'WMATL', 'WSCH', 'INPRG', 'INSP', 'COMP', 'REJECT', 'CLOSE', 'CAN')
UNION ALL
/* 3. Labor Hours Recorded */
SELECT
L.REFWO AS WorkOrderNumber,
'Labor Hours Recorded' AS Activity,
L.STARTDATE AS EventTimestamp,
'Maximo' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate,
W.WORKTYPE AS WorkType,
W.WOPRIORITY AS Priority,
W.ASSETNUM AS AssetNumber,
L.LABORCODE AS AssignedResource,
W.ACTFINISH AS ActualFinishDate,
W.TARGCOMPDATE AS TargetCompletionDate,
L.REGULARHRS AS ActualLaborHours,
W.ASSETLOCPRIORITY AS AssetCriticality,
W.STATUS AS Status
FROM WOLABTRANS L
JOIN WORKORDER W ON L.REFWO = W.WONUM AND L.SITEID = W.SITEID
UNION ALL
/* 4. Material Issued */
SELECT
M.REFWO AS WorkOrderNumber,
'Material Issued' AS Activity,
M.TRANSDATE AS EventTimestamp,
'Maximo' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate,
W.WORKTYPE AS WorkType,
W.WOPRIORITY AS Priority,
W.ASSETNUM AS AssetNumber,
M.ISSUETO AS AssignedResource,
W.ACTFINISH AS ActualFinishDate,
W.TARGCOMPDATE AS TargetCompletionDate,
0 AS ActualLaborHours,
W.ASSETLOCPRIORITY AS AssetCriticality,
W.STATUS AS Status
FROM MATUSETRANS M
JOIN WORKORDER W ON M.REFWO = W.WONUM AND M.SITEID = W.SITEID
WHERE M.ISSUETYPE = 'ISSUE'
UNION ALL
/* 5. Target Date Updated (Requires Audit Table) */
SELECT
A.WONUM AS WorkOrderNumber,
'Target Date Updated' AS Activity,
A.AUDITSTAMP AS EventTimestamp,
'Maximo' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate,
W.WORKTYPE AS WorkType,
W.WOPRIORITY AS Priority,
W.ASSETNUM AS AssetNumber,
A.AUDITUSER AS AssignedResource,
W.ACTFINISH AS ActualFinishDate,
A.TARGCOMPDATE AS TargetCompletionDate,
0 AS ActualLaborHours,
W.ASSETLOCPRIORITY AS AssetCriticality,
W.STATUS AS Status
FROM A_WORKORDER A
JOIN WORKORDER W ON A.WONUM = W.WONUM AND A.SITEID = W.SITEID
WHERE A.TARGCOMPDATE IS NOT NULL
AND A.TARGCOMPDATE <> COALESCE((SELECT TOP 1 PREV.TARGCOMPDATE FROM A_WORKORDER PREV WHERE PREV.WONUM = A.WONUM AND PREV.AUDITSTAMP < A.AUDITSTAMP ORDER BY PREV.AUDITSTAMP DESC), '1900-01-01') ステップ
データベース接続: IBM Maximoバックエンドデータベース (一般的にDB2、Oracle、またはSQL Server) への読み取り専用JDBCまたはODBC接続を確立します。ユーザーがWORKORDER、WOSTATUS、LABTRANS、MATUSETRANSテーブルに対するSELECT権限を持っていることを確認してください。
スコープの特定: 抽出する必要がある特定のSITESまたはORGIDSを決定します。Maximoはマルチサイトシステムであり、作業指示番号 (WONUM) はSITEIDと組み合わせた場合にのみ一意です。通常、REPORTDATE (作成日) またはSTATUSDATEでフィルタリングすることにより、日付範囲を決定します。
データモデルの理解: WORKORDERテーブルはヘッダーとして機能します。WOSTATUSテーブルにはライフサイクル変更の履歴が含まれています。LABTRANSテーブルには詳細な労働入力が、MATUSETRANSには資材移動が含まれています。これらはUNION ALLを使用して結合し、単一のイベントストリームを形成する必要があります。
同義語の処理: Maximoは、SYNONYMDOMAINで定義されたステータスに対して、内部値 (MAXVALUE) と表示値 (VALUE) を使用します。クエリは、同じ論理ステータスに対して異なる表示ラベルを使用する可能性のある異なるサイト間で一貫性を確保するために、内部MAXVALUEでフィルタリングすることが理想的です。
クエリの準備: クエリセクションで提供されているSQLをコピーします。[Your Database Schema]や[Start Date]などのプレースホルダーを実際の値に置き換えてください。お使いの環境で検査や品質チェックに特定のカスタムステータスコードを使用している場合は、それぞれのセクションのWHERE句を更新してください。
抽出の実行: クエリを実行します。データの量によっては、データベースのタイムアウトを避けるために、これをバッチ (例: 月ごと) で実行する必要がある場合があります。
データの検証: すべての作業指示に「メンテナンスリクエスト作成」イベントが存在することを確認します。タイムスタンプがProcessMindと互換性のある形式 (ISO 8601が推奨) であることを確認してください。
後処理: Maximoのタイムスタンプには通常ミリ秒が含まれています。これらを保持して、連続して発生するイベントの正しいソート順序を維持するようにしてください。
エクスポート: 結果をCSVまたはParquetファイルとして保存します。列ヘッダーは、クエリ出力で定義された属性と一致している必要があります。
ProcessMindアップロード: ファイルをProcessMindにインポートします。「WorkOrderNumber」をケースID、「Activity」をアクティビティ名、「EventTimestamp」をタイムスタンプとしてマッピングします。
設定
- データベースプラットフォーム: Maximoは通常、IBM DB2、Oracle、またはSQL Server上で動作します。提供されている構文は標準SQLですが、特定のプラットフォームによっては、日付関数の微調整 (例: TO_DATE vs CAST) が必要になる場合があります。
- 日付フィルタリング: WORKORDERテーブルのREPORTDATE列を使用して、プロセスインスタンスの範囲を定義します。過去12ヶ月間のローリングウィンドウが標準です。
- サイトIDの重要性: 一意性をWONUMのみに頼るべきではありません。複数のサイトを分析する場合は、常にWONUMとSITEIDを連結するか、SITEIDをケース属性として含めてください。
- ステータスロジック: Maximoはカスタムステータス値を許可します。WMATLやCOMPのような標準ステータスで結果が得られない場合は、SYNONYMDOMAINテーブルを確認してください。
- パフォーマンス: LABTRANSおよびMATUSETRANSテーブルは非常に大きくなる可能性があります。これらのテーブルがREFWOとSITEIDでインデックス化されていることを確認してください。
a クエリ例 sql
SELECT
W.WONUM AS WorkOrderNumber,
'Maintenance Request Created' AS Activity,
W.REPORTDATE AS EventTimestamp,
'Maximo' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate,
W.WORKTYPE AS WorkType,
W.WOPRIORITY AS Priority,
W.ASSETNUM AS AssetNumber,
W.LEAD AS AssignedResource,
W.ACTFINISH AS ActualFinishDate,
W.TARGCOMPDATE AS TargetCompletionDate,
W.ACTLABHRS AS ActualLaborHours,
W.ASSETLOCPRIORITY AS AssetCriticality,
W.STATUS AS Status
FROM
WORKORDER W
WHERE
W.REPORTDATE >= '2023-01-01'
UNION ALL
SELECT
WS.WONUM AS WorkOrderNumber,
CASE
WHEN WS.STATUS = 'APPR' THEN 'Work Order Approved'
WHEN WS.STATUS = 'WMATL' THEN 'Material Requisition Submitted'
WHEN WS.STATUS = 'WSCH' THEN 'Resources Scheduled'
WHEN WS.STATUS = 'INPRG' THEN 'Work Commenced'
WHEN WS.STATUS = 'INSP' THEN 'Inspection Completed'
WHEN WS.STATUS = 'COMP' THEN 'Work Order Completed'
WHEN WS.STATUS = 'REJECT' THEN 'Quality Check Failed'
WHEN WS.STATUS = 'CLOSE' THEN 'Work Order Closed'
WHEN WS.STATUS = 'CAN' THEN 'Work Order Cancelled'
ELSE 'Status Change: ' || WS.STATUS
END AS Activity,
WS.CHANGEDATE AS EventTimestamp,
'Maximo' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate,
W.WORKTYPE AS WorkType,
W.WOPRIORITY AS Priority,
W.ASSETNUM AS AssetNumber,
WS.CHANGEBY AS AssignedResource,
W.ACTFINISH AS ActualFinishDate,
W.TARGCOMPDATE AS TargetCompletionDate,
W.ACTLABHRS AS ActualLaborHours,
W.ASSETLOCPRIORITY AS AssetCriticality,
WS.STATUS AS Status
FROM
WOSTATUS WS
JOIN
WORKORDER W ON WS.WONUM = W.WONUM AND WS.SITEID = W.SITEID
WHERE
W.REPORTDATE >= '2023-01-01'
AND WS.STATUS IN ('APPR', 'WMATL', 'WSCH', 'INPRG', 'INSP', 'COMP', 'REJECT', 'CLOSE', 'CAN')
UNION ALL
SELECT
L.REFWO AS WorkOrderNumber,
'Labor Hours Recorded' AS Activity,
L.STARTDATE AS EventTimestamp,
'Maximo' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate,
W.WORKTYPE AS WorkType,
W.WOPRIORITY AS Priority,
W.ASSETNUM AS AssetNumber,
L.LABORCODE AS AssignedResource,
W.ACTFINISH AS ActualFinishDate,
W.TARGCOMPDATE AS TargetCompletionDate,
W.ACTLABHRS AS ActualLaborHours,
W.ASSETLOCPRIORITY AS AssetCriticality,
W.STATUS AS Status
FROM
LABTRANS L
JOIN
WORKORDER W ON L.REFWO = W.WONUM AND L.SITEID = W.SITEID
WHERE
W.REPORTDATE >= '2023-01-01'
UNION ALL
SELECT
M.REFWO AS WorkOrderNumber,
'Material Issued' AS Activity,
M.TRANSDATE AS EventTimestamp,
'Maximo' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate,
W.WORKTYPE AS WorkType,
W.WOPRIORITY AS Priority,
W.ASSETNUM AS AssetNumber,
M.ENTERBY AS AssignedResource,
W.ACTFINISH AS ActualFinishDate,
W.TARGCOMPDATE AS TargetCompletionDate,
W.ACTLABHRS AS ActualLaborHours,
W.ASSETLOCPRIORITY AS AssetCriticality,
W.STATUS AS Status
FROM
MATUSETRANS M
JOIN
WORKORDER W ON M.REFWO = W.WONUM AND M.SITEID = W.SITEID
WHERE
W.REPORTDATE >= '2023-01-01'
AND M.ISSUETYPE = 'ISSUE'
UNION ALL
SELECT
WC.WONUM AS WorkOrderNumber,
'Target Date Updated' AS Activity,
WC.CHANGEDATE AS EventTimestamp,
'Maximo' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate,
W.WORKTYPE AS WorkType,
W.WOPRIORITY AS Priority,
W.ASSETNUM AS AssetNumber,
WC.CHANGEBY AS AssignedResource,
W.ACTFINISH AS ActualFinishDate,
W.TARGCOMPDATE AS TargetCompletionDate,
W.ACTLABHRS AS ActualLaborHours,
W.ASSETLOCPRIORITY AS AssetCriticality,
W.STATUS AS Status
FROM
WOCHANGE WC
JOIN
WORKORDER W ON WC.WONUM = W.WONUM AND WC.SITEID = W.SITEID
WHERE
W.REPORTDATE >= '2023-01-01'
AND (WC.MODIFIEDATTRIBUTE = 'TARGCOMPDATE' OR WC.MODIFIEDATTRIBUTE = 'SCHEDFINISH')