Your Asset Maintenance Data Template
Your Asset Maintenance Data Template
- Recommended attributes for comprehensive analysis
- Critical process milestones to monitor
- System-specific extraction guidance for Oracle
Asset Maintenance Attributes
| Name | Description | ||
|---|---|---|---|
|
Activity
ActivityName
|
The name of the event or status change occurring in the workflow. | ||
|
Description
This attribute captures the specific step performed in the maintenance process, such as 'Work Order Created', 'Operation Started', or 'Work Order Closed'. It represents the nodes in the process map. Analysts use this to visualize the process flow, identify variants, and detect bottlenecks between specific process steps.
Why it matters
Required to define the process flow and sequence of events.
Where to get
Derived from transaction history tables or status change logs.
Examples
Maintenance Work Order CreatedWork Order ReleasedOperation Completed
|
|||
|
Event Timestamp
EventDateTime
|
The date and time when the activity occurred. | ||
|
Description
This attribute records the exact moment an event took place. It is used to order activities chronologically within a case and to calculate the duration between steps. Accurate timestamps are critical for calculating cycle times, identifying delays, and measuring performance against SLAs.
Why it matters
Essential for establishing the timeline of the process.
Where to get
CREATION_DATE or LAST_UPDATE_DATE columns in transaction tables.
Examples
2023-10-15T08:30:00Z2023-10-15T09:15:00Z2023-10-16T14:00:00Z
|
|||
|
Maintenance Work Order
WorkOrderNumber
|
The unique identifier for the maintenance work order. | ||
|
Description
The Work Order Number serves as the unique case identifier for the maintenance process. It tracks the lifecycle of a maintenance task from the initial request or schedule generation through to execution, completion, and financial closure. In analysis, this attribute is the central key for joining event data with case-level attributes. It allows analysts to group all activities related to a single job and calculate end-to-end cycle times.
Why it matters
It is the primary key for the process instance, essential for reconstructing the case history.
Where to get
WIE_WORK_ORDERS_B table, column WORK_ORDER_NUMBER
Examples
WO-2023-0015WO-2023-0089WO-2023-1102
|
|||
|
Last Data Update
LastDataUpdate
|
Timestamp of the most recent data extraction. | ||
|
Description
The date and time when the data was last extracted or refreshed in the process mining tool. It helps users understand how current the analysis is. This is a system metadata field required for data governance.
Why it matters
Ensures users know the freshness of the data.
Where to get
System time at extraction.
Examples
2023-10-30T12:00:00Z
|
|||
|
Source System
SourceSystem
|
The name of the system where the data originated. | ||
|
Description
Indicates the source software or database from which the record was extracted. In this context, it is typically 'Oracle Maintenance Cloud'. Essential in multi-system environments to track data lineage.
Why it matters
Tracks data lineage in multi-system environments.
Where to get
Hardcoded during extraction.
Examples
Oracle Maintenance CloudOracle Cloud ERP
|
|||
|
Actual Completion Date
ActualCompletionDate
|
The date and time when the maintenance work was finished. | ||
|
Description
Records the final completion of the physical work. This timestamp is used to close the execution phase of the lifecycle. It is the end point for Technical Execution Cycle Time and start point for Administrative Lag Time.
Why it matters
Marks the end of the technical execution phase.
Where to get
WIE_WORK_ORDERS_B table, column COMPLETED_DATE or CLOSED_DATE.
Examples
2023-10-252023-10-262023-10-27
|
|||
|
Actual Start Date
ActualStartDate
|
The actual date and time when work commenced. | ||
|
Description
Records when the technician actually started the work. This is often triggered by an 'Operation Started' transaction. Used to calculate the Material Fulfillment Delay (end point) and Resource Scheduling Fluidity.
Why it matters
Critical for calculating execution duration vs planning.
Where to get
WIE_WORK_ORDERS_B table, column ACTUAL_START_DATE.
Examples
2023-10-212023-10-222023-10-23
|
|||
|
Asset Number
AssetNumber
|
The unique identifier of the equipment being maintained. | ||
|
Description
Identifies the specific physical asset or machine that is the subject of the maintenance work order. It links the process to the asset hierarchy. This is crucial for the Asset Rework Frequency KPI, enabling analysts to spot machines that break down repeatedly.
Why it matters
Links maintenance activities to specific physical equipment.
Where to get
WIE_WORK_ORDERS_B table, column ASSET_ID (join to CSI_ITEM_INSTANCES).
Examples
PUMP-101HVAC-Unit-5CONVEYOR-BELT-A
|
|||
|
Assigned Technician
AssignedTechnician
|
The person or resource group assigned to execute the task. | ||
|
Description
Captures the user or employee ID of the technician responsible for the work. This may be assigned at the header or operation level. Used in Technician Utilization and Labor analysis to identify skill gaps or over-utilized resources.
Why it matters
Enables resource performance analysis and capacity planning.
Where to get
WIE_OPERATION_RESOURCES table or similar assignment table.
Examples
J. SmithTech-005External Contractor
|
|||
|
Maintenance Type
WorkOrderType
|
Categorizes the work order as preventive, corrective, or predictive. | ||
|
Description
This attribute defines the nature of the maintenance work. Common values include Preventive, Corrective, Emergency, or Condition-Based. It is vital for the Proactive Maintenance Ratio KPI, allowing analysts to compare the volume of planned work versus unplanned reactions to failures.
Why it matters
Distinguishes between planned maintenance and reactive repairs.
Where to get
WIE_WORK_ORDERS_B table, column WORK_ORDER_TYPE_ID (joined to type definition).
Examples
PreventiveCorrectiveEmergency
|
|||
|
Organization Code
OrganizationCode
|
The code for the maintenance organization or plant. | ||
|
Description
Represents the specific business unit, plant, or facility responsible for the maintenance work. It allows for regional or facility-based benchmarking. Used to map performance differences between different sites or operational units.
Why it matters
Segment analysis by physical location or business unit.
Where to get
WIE_WORK_ORDERS_B table, column ORGANIZATION_ID.
Examples
M1NY-PLANTLON-DEPOT
|
|||
|
Priority
Priority
|
The urgency level assigned to the work order. | ||
|
Description
Indicates the importance of the work order, such as Critical, High, Medium, or Low. This drives the scheduling and resource allocation. Important for the Work Order Conversion Efficiency dashboard to ensure critical faults are prioritized correctly.
Why it matters
Determines the target response time and resource allocation.
Where to get
WIE_WORK_ORDERS_B table, column WORK_ORDER_PRIORITY_ID.
Examples
CriticalHighStandard
|
|||
|
Work Order Status
WorkOrderStatus
|
The current lifecycle state of the work order. | ||
|
Description
Indicates the status of the work order, such as Unreleased, Released, On Hold, Completed, or Closed. This helps filter cases that are still open versus those that have finished. Used in dashboarding to visualize the current work in progress (WIP) and to identify orders stuck in specific states.
Why it matters
Provides a snapshot of the work order's progress.
Where to get
WIE_WORK_ORDERS_B table, column WORK_ORDER_STATUS_ID.
Examples
ReleasedOn HoldClosed
|
|||
|
Actual Labor Hours
ActualLaborHours
|
Total hours spent by technicians on this work order. | ||
|
Description
The sum of all duration values recorded in labor transactions for the work order. This measures the actual effort expended. Used in Estimated versus Actual Labor Variance KPI to assess planning accuracy.
Why it matters
Key metric for costing and workforce efficiency.
Where to get
Aggregated from WIE_WORK_ORDER_TRANSACTIONS (Resource transactions).
Examples
4.512.00.75
|
|||
|
Asset Category
AssetCategory
|
Grouping of assets into types like HVAC, Fleet, or Production Line. | ||
|
Description
Classifies the asset into broader groups. This allows for high-level analysis of maintenance performance across different types of equipment. Used in the Maintenance Lead Time Overview dashboard to identify which equipment classes cause the most delays.
Why it matters
Enables aggregated analysis of maintenance performance by equipment type.
Where to get
Derived from the Item Category assigned to the Asset ID.
Examples
Heavy MachineryFleet VehiclesFacilities
|
|||
|
Estimated Labor Hours
EstimatedLaborHours
|
Planned labor hours for the work order. | ||
|
Description
The amount of time the planner estimated the job would take. This is set during the planning or release phase. Compared against Actual Labor Hours to determine the variance and improve future planning standards.
Why it matters
Benchmark for assessing execution efficiency.
Where to get
WIE_OPERATION_RESOURCES table, planned quantity.
Examples
5.010.01.0
|
|||
|
Is Rework
IsRework
|
Flag indicating if this work order is a repeat repair. | ||
|
Description
A boolean flag that evaluates to true if another work order was closed for the same Asset ID within a preceding 30-day window. This is a calculated attribute. It directly supports the Asset Rework Frequency KPI and helps identify poor quality repairs or failing assets.
Why it matters
Identifies quality issues and recurring failures.
Where to get
Calculated in the data transformation layer.
Examples
truefalse
|
|||
|
Request Date
RequestDate
|
Date when the initial maintenance request was received. | ||
|
Description
The timestamp indicating when the need for maintenance was first identified and logged. This forms the start of the lead time calculation. Critical for the Work Order Conversion Lead Time KPI to measure the delay between identifying a problem and creating the order.
Why it matters
Marks the beginning of the end-to-end process lifecycle.
Where to get
WIE_WORK_ORDERS_B table, derived from source request link.
Examples
2023-10-012023-10-052023-11-12
|
|||
|
Scheduled Start Date
ScheduledStartDate
|
The planned start date for the maintenance work. | ||
|
Description
The date and time when the work was scheduled to begin. Comparison against Actual Start Date reveals schedule adherence. Used in Scheduling and Slippage Analysis to detect disruptions in the maintenance plan.
Why it matters
Baseline for measuring schedule adherence and slippage.
Where to get
WIE_WORK_ORDERS_B table, column PLANNED_START_DATE.
Examples
2023-10-202023-10-212023-10-22
|
|||
|
SLA Target Date
SlaTargetDate
|
The deadline by which the work order must be completed. | ||
|
Description
Calculated based on the priority and the creation date. It represents the commitment to the business for asset restoration. Used for the SLA Achievement Rate KPI to determine if maintenance is meeting its service obligations.
Why it matters
Defines the success criteria for timeliness.
Where to get
Usually a custom field or derived from Priority configuration.
Examples
2023-11-012023-11-052023-11-10
|
|||
|
Total Cost
TotalCost
|
The total financial cost incurred for the work order. | ||
|
Description
Sum of material, labor, and overhead costs associated with the work order. This is typically finalized during the 'Maintenance Costs Transferred' activity. Used in Maintenance Planning Accuracy analysis to compare budget vs actual spend.
Why it matters
Primary financial metric for maintenance activities.
Where to get
Costing module tables linked to Work Order ID.
Examples
1500.00250.505000.00
|
|||
|
Work Order Description
WorkOrderDescription
|
Brief text describing the issue or task. | ||
|
Description
A free-text field entered by the requestor or planner describing the problem or the required work. It provides context that structured data might miss. Useful for text analysis or manual review of 'Other' work types.
Why it matters
Provides human-readable context for the maintenance task.
Where to get
WIE_WORK_ORDERS_B table, column WORK_ORDER_DESCRIPTION.
Examples
Replace conveyer belt motorMonthly safety inspectionFix oil leak on Pump A
|
|||
Asset Maintenance Activities
| Activity | Description | ||
|---|---|---|---|
|
Labor Hours Recorded
|
The logging of time spent by a technician on the work order. This is a transactional event where costs are accrued against the maintenance activity. | ||
|
Why it matters
Tracks effort and cost accumulation. Multiple events of this type indicate ongoing work and are used to calculate total labor variances.
Where to get
Derived from WIE_RESOURCE_TRANSACTIONS table.
Capture
Logged when transaction X executed
Event type
explicit
|
|||
|
Maintenance Request Created
|
The initial submission of a maintenance request via the self-service portal or help desk interface. This event captures the first indication of a fault or required service before it becomes a formal work order, typically found in the Work Requests table. | ||
|
Why it matters
Marks the true start of the maintenance demand cycle. Essential for calculating the lead time between fault identification and the generation of an actionable work order.
Where to get
Derived from the MNT_WORK_REQUESTS table using the CREATION_DATE field.
Capture
Logged when a record is inserted into the Work Requests table
Event type
explicit
|
|||
|
Maintenance Work Order Created
|
The system generation of the Work Order entity, either converted from a request or created manually. This event establishes the Case ID for process mining and sets the baseline for planning and execution. | ||
|
Why it matters
The primary anchor event for the process instance. It separates the intake phase from the planning and execution phase.
Where to get
Derived from WIE_WORK_ORDERS_B table using the CREATION_DATE timestamp.
Capture
Logged when the WO header record is created
Event type
explicit
|
|||
|
Materials Issued
|
The actual deduction of inventory from the warehouse issued to the specific work order. This represents the physical movement of parts to the maintenance location. | ||
|
Why it matters
A tangible sign that work is preparing to start. Comparing this to the 'Released' event highlights delays in the warehouse picking process.
Where to get
Derived from INV_MATERIAL_TXNS table where TRANSACTION_SOURCE_TYPE_ID links to the Work Order.
Capture
Logged when transaction X executed
Event type
explicit
|
|||
|
Operation Started
|
The commencement of a specific operation (e.g., Op 10, Op 20) within the work order. This is the precise moment technical work begins on a task. | ||
|
Why it matters
Represents the 'Work Commenced' milestone. Essential for calculating the actual wrench time versus the planned duration.
Where to get
Derived from WIE_WO_OPERATIONS_B status changes or the first resource transaction timestamp for the operation.
Capture
Derive from comparing field X to Y
Event type
inferred
|
|||
|
Work Order Closed
|
The final administrative closure of the work order. No further costs can be accrued, and the order is finalized for accounting. | ||
|
Why it matters
Marks the end of the administrative lifecycle. The time between Completed and Closed represents the administrative lag.
Where to get
Derived from WIE_WO_STATUS_HISTORY where STATUS_CODE changes to 'CLOSED'.
Capture
Compare status field before/after
Event type
explicit
|
|||
|
Work Order Completed
|
The technical completion of the entire work order. This signifies that the physical asset is repaired and ready for service, though financial processing may continue. | ||
|
Why it matters
The effective end of the maintenance intervention from an operations perspective. Used to calculate SLA adherence.
Where to get
Derived from WIE_WO_STATUS_HISTORY where STATUS_CODE changes to 'COMPLETED'.
Capture
Compare status field before/after
Event type
explicit
|
|||
|
Work Order Released
|
The status change moving the work order from a Draft or Unreleased state to Released. This action authorizes the consumption of materials and resources against the order. | ||
|
Why it matters
Indicates the end of the planning phase and the authorization for execution to begin. Delays here indicate planning bottlenecks.
Where to get
Derived from WIE_WO_STATUS_HISTORY where STATUS_CODE changes to 'RELEASED'.
Capture
Compare status field before/after
Event type
inferred
|
|||
|
Maintenance Costs Transferred
|
The transfer of accumulated costs from the maintenance system to the Cost Management module. This acts as the financial settlement. | ||
|
Why it matters
Confirms that the financial impact of the maintenance has been recognized. Essential for 'Maintenance Planning Accuracy' analysis.
Where to get
Derived from Cost Accounting distribution tables linked to the Work Order transaction source.
Capture
Logged when transaction X executed
Event type
inferred
|
|||
|
Materials Allocated
|
The reservation or allocation of required spare parts and components to the work order. This ensures inventory is available before work commences. | ||
|
Why it matters
Critical for analyzing supply chain readiness. If this step is delayed, it suggests inventory shortages or slow procurement planning.
Where to get
Derived from WIE_WO_COMPONENTS_B table based on the CREATION_DATE or ALLOCATION_DATE.
Capture
Logged when transaction X executed
Event type
explicit
|
|||
|
Operation Completed
|
The completion of a specific step (Operation) in the routing. Signals that a specific portion of the technical work is finished. | ||
|
Why it matters
Provides granular visibility into progress. 'Maintenance Task Executed' is typically derived from the completion of the final operation.
Where to get
Derived from WIE_WO_OPERATIONS_B status changes or transaction history showing completion.
Capture
Compare status field before/after
Event type
inferred
|
|||
|
Quality Inspection Recorded
|
The entry of quality results associated with the maintenance work order. This validates that the repair meets safety and operational standards. | ||
|
Why it matters
Ensures compliance. Missing quality checks before completion can indicate safety risks or process deviations.
Where to get
Derived from QA_RESULTS or similar Quality Collection Plan tables linked to the Work Order ID.
Capture
Logged when transaction X executed
Event type
explicit
|
|||
|
Work Order Canceled
|
The termination of a work order before successful completion. This may happen if the work was duplicate, unnecessary, or consolidated. | ||
|
Why it matters
Identifying high cancellation rates can reveal issues with the request intake process or duplicate detection logic.
Where to get
Derived from WIE_WO_STATUS_HISTORY where STATUS_CODE changes to 'CANCELED'.
Capture
Compare status field before/after
Event type
explicit
|
|||
|
Work Order On Hold
|
The status of the work order is changed to 'On Hold', stopping execution. This typically occurs due to missing parts, lack of access, or safety issues. | ||
|
Why it matters
A major source of process inefficiency. Identifying the frequency and duration of holds is key to reducing overall lead time.
Where to get
Derived from WIE_WO_STATUS_HISTORY where STATUS_CODE changes to 'ON_HOLD'.
Capture
Compare status field before/after
Event type
explicit
|
|||
|
Work Order Scheduled
|
The assignment of specific start dates or specific resources (technicians/tools) to the work order operations. This updates the planned schedule dates in the system. | ||
|
Why it matters
Measures the efficiency of the dispatching or scheduling team. Gaps between release and scheduling indicate resource contention.
Where to get
Derived from updates to WIE_OPERATION_RESOURCES or WIE_WO_OPERATIONS_B scheduling columns.
Capture
Compare status field before/after
Event type
inferred
|
|||