Sap Pm

1. Environment Intake Checklist

Before answering PM questions, collect:

• SAP Release: ECC 6.0 (which EhP?) or S/4HANA (which release year?)
• Deployment model: On-premise / RISE / Cloud Public Edition
• PM Organization: Planning Plant, Maintenance Plant, Maintenance Coordination Plant
• Industry sector: Manufacturing (automotive, chemicals, electronics), energy, pharma, food & beverage
• Equipment strategy: Single-level (equipment only) vs. two-level (equipment + functional locations)
• Maintenance type focus: Breakdown, preventive, predictive, contract, or combination?
• Integration requirements: MES, predictive maintenance (PAI), mobile (SAP Asset Manager), analytics

2. Equipment Master Data (IE01/IE02/IE03)

Equipment Creation (IE01)

Key T-codes & Menu Path

• IE01: Create Equipment (SPRO → Plant Maintenance → Master Data → Equipment → Create)
• IE02: Change Equipment
• IE03: Display Equipment
• IE10: Create Fleet (for mass equipment with identical configuration)

Critical Fields (EQUI Table)

Equipment Classification

Table KLAH (classification header) + KLASP (assignment):

• Class type: EQUIPMENT, ZEQUIP (custom)
• Characteristics: Model, Manufacturer, Voltage, Capacity, Brand
• Used for: spare parts list filtering, maintenance strategy assignment, reporting

Serial Number Management

• Equipment must link to material master (EQUI.MATNR)
• Material → Accounting 1 view → Valuation Class + Serial Number Profile (MMSL)
• Serial Number Profile (MMSL): defines when system forces serial entry during GR, GI, MIGO
• Equipment History (EQUZ): automatic log of changes (creation, equipment change, tag changes)

Equipment Deletion

• Equipment cannot be deleted if it has maintenance history (QMEL, AUFK exist)
• Workaround: Flag EQUI-LOEKZ (deletion flag) = X → equipment hidden in selection, kept for history

3. Functional Location Master Data (IL01/IL02/IL03)

Hierarchical structure — represents plant's physical/logical organization

Functional Location Creation (IL01)

Key T-codes

• IL01: Create Functional Location (SPRO → Plant Maintenance → Master Data → Technical Objects → Functional Location)
• IL02: Change Functional Location
• IL03: Display Functional Location

Hierarchy Example (Two-Level Strategy)

Production Line A (ZFUNCLOC-PRODLINE-A)
├─ Section 1 (ZFUNCLOC-PRODLINE-A-SEC1)
│  ├─ Equipment: Motor, Pump, Control Panel
└─ Section 2 (ZFUNCLOC-PRODLINE-A-SEC2)
   ├─ Equipment: Conveyor, Sensor

Critical Fields (IFLO + IFLOT Tables)

Account Assignment

• Cost center (KOSTL): for cost tracking of maintenance labor + materials
• Internal order (AUFNR): for project-based maintenance (e.g., annual overhaul)
• Profit center: for P&L attribution
• WBS element: for capital project maintenance

4. Maintenance Notification (IW21/IW22/IW23)

Entry point for all maintenance requests — whether breakdown or planned

Notification Types (QMNUM Table)

Key T-codes

Critical Fields (QMEL + QMIH Tables)

Damage Code & Root Cause Workflow

Damage codes (Schädigungen) → categorize what broke

• Table maintained in: SPRO → Plant Maintenance → Notification → Configure Notification Type → Damage Codes
• Example: BEARING (Lagerschaden), SEAL (Dichtungsschaden), MOTOR_COIL (Motorwicklung)

Root cause codes → categorize why it broke

• Maintained in: SPRO → Plant Maintenance → Notification → Configure Notification Type → Cause Codes
• Example: OVERLOAD (Überbelastung), POOR_MAINTENANCE (Schlechte Instandhaltung), DESIGN_DEFECT

Activity codes → actions taken

• INSPECTION, REPAIR, REPLACEMENT, ADJUSTMENT, CALIBRATION

Notification Workflow

IW21 (Create) → IW22 (Edit, assign to equipment/FL) 
→ Create Maintenance Order (IW31) or Assign Existing (IW81)
→ Complete Notification (IW21 → Status = COMPLETED)
→ Archive / History Report (IW28, IW29)

5. Maintenance Order (IW31/IW32/IW33)

Execution unit — operationalizes a notification into scheduled work with costing

Order Types & Lifecycle

Lifecycle (Status Flow)

CRTD (Created) → PLAN (Planning) → RELD (Released) 
→ TECO (Technically Complete) → CLSD (Closed)

Key transitions:

• CRTD → RELD: IW32 (Change) → Release button (Authorization: PM.ORD.R)
• RELD → TECO: CO11N (confirmation) or manual in IW32
• TECO → CLSD: Settlement (KO88) → automatic CLSD after successful posting

Key T-codes

Critical Fields (AUFK + AFKO + AFIH Tables)

Operations & Component Planning

Operations (AFIH table) — individual tasks within maintenance order

Components (BOM link) — spare parts required

• AFIH → STPO (BOM item) → material + quantity
• Component status: Available / Withdrawn / On PO / Missing (CO24)
• Backflush: if enabled, components auto-issue at confirmation (MIGO 261 automatic)

Maintenance Labor & Costs

Labor hours collection (CO11N confirmation)

• Actual labor time entered at operation level
• Overtime multipliers applied (customizable per order type)

Spare parts cost (MIGO)

• GI from warehouse → MIGO 261 → charged to maintenance order
• Vendor-supplied parts → PO line → GR → invoice → cost posting

Overhead allocation (KO88)

• Settlement rule: Actual cost + overhead (%) → Cost center or internal order
• Example: Order cost = 5,000 EUR → + 20% overhead = 6,000 EUR → posted to cost center

External Services (Subcontracting)

• Maintenance order header → Services tab → Create purchase requisition (BANF)
• Service material type: automatically creates PR → RFQ → PO → GR → IV (MIRO)
• Typical service materials: OUTSOURCE_REPAIR, INSPECTION_LABOR

6. Preventive Maintenance (IP01/IP10/IP30)

Automated scheduling of recurring maintenance tasks

Maintenance Plans (IP01/IP02)

Plan Types

Maintenance Strategy (IP11)

Strategy = grouping of maintenance tasks → optimize scheduling

Example: Monthly production line maintenance (STRAT_PRODLINE_M)

• Task 1: Bearing lubrication (5 hours, cost center MAINT_OIL)
• Task 2: Filter replacement (3 hours, material M-FILTER-001, cost center MAINT_PARTS)
• Task 3: Inspection (4 hours, cost center MAINT_LABOR)
• Total plan: 12 labor hours, materials + labor cost per execution

Scheduling Strategy (IP11 → PLTYP / IPRFL Table)

Task Lists for Maintenance (IA01/IA05)

Reusable checklists & instructions

Task list structure (PLKO + PLPO)

• Header: task list ID, description, equipment/FL applicable
• Operations: step 10, 20, 30... each with work center + time + materials

Example: Pump Inspection Task List (TASKLIST-PUMP-INSPECT)

Step 10: Visual inspection (0.5 hrs, work center: MAINT_VISUAL)
Step 20: Vibration check (1.0 hr, equipment: VIBRATION_METER)
Step 30: Temperature measurement (0.5 hrs, sensor: TEMP_PROBE_001)
Step 40: Oil sampling (0.25 hrs, material: OIL_SAMPLE_BOTTLE)
Step 50: Report findings (0.5 hrs, work center: MAINT_ADMIN)
Total: 2.75 hours

7. Maintenance Scheduling (IP10 / IP30)

IP10 — Call Object Scheduling

Generates notifications/orders based on maintenance plans

• Input: maintenance plans (IP01) + current equipment state
• Output: QMEL (notifications) or AUFK (orders) for upcoming maintenance
• Run frequency: typically nightly batch (transaction SM36)

IP30 — Deadline Monitoring

Processes due maintenance-plan calls within the selected scheduling interval

Usage:

• Filter by the approved maintenance-plan/planning-plant scope and scheduling interval
• Review generated, skipped, held, and errored calls; the configured call-object type determines whether the plan generates an order or notification
• Do not create a separate manual IW31 order merely because a line appears overdue

7.1 Preventive Maintenance Overdue — Evidence Loop

Mandatory diagnostic order

When evidence is missing, the leading provisional cause is the plan was not scheduled, or the periodic deadline-monitoring job/variant did not select and process it, so no due call object was generated. Ask for environment context, but provide this read-only path in the same answer:

IP03 active plan/item + cycle/start/call horizon
  → IP10 scheduling overview and call status (no production save)
  → SM37 IP30 job/variant/status
  → IP30 selected/generated/skipped messages
  → MHIS call
  → IW39/IW33 order OR IW29 notification execution status

Falsify the leading cause only when MHIS contains the expected planned call and its linked order or notification exists, while SM37 also proves the appropriate IP30 job/variant completed and included the plan scope. Then reclassify the incident as execution overdue, not scheduling overdue.

Minimum evidence bundle: release/deployment, plan/item/technical object, plan type, expected due date, last normal call, IP03 scheduling parameters/status, IP10 call status, SM37 job/variant/timestamps, IP30 messages, MHIS call number, and linked IW39 order or IW29 notification status.

Intake and business-state split

Collect release/deployment/industry, user-provided maintenance plan/item and technical object, plan type, factory calendar/timezone, expected due date, last normal call, last IP30 run, and call-object category. Classify the symptom before changing anything:

1. Scheduling overdue — due call was never created.
2. Execution overdue — call/order exists but work is not completed.
3. Display-only discrepancy — dates differ because of call horizon, tolerance, shift, calendar, or timezone.
4. Counter-plan discrepancy — measured usage is missing, stale, reset, or not yet at the threshold.

Read-only evidence chain

Read-only tables/fields: MPLA-WARPL, MPOS-WARPL/WAPOS/EQUNR/TPLNR, MHIS-WARPL/ABNUM, AUFK-AUFNR/OBJNR, AFIH-AUFNR/EQUNR/TPLNR, JEST-OBJNR/STAT/INACT. Never update these with SE16N.

Hypotheses and falsifiers

H1 — IP30 did not process the plan.

• Supports: no new MHIS call after the expected date; plan excluded by variant or run failed.
• Falsifier 1: successful run log proves the plan/item was selected at that timestamp.
• Falsifier 2: the expected call already exists in MHIS and has a linked order/notification.

H1a — the plan was created but never initially scheduled, or scheduling was not saved.

• Supports: IP03 plan exists but IP10 has no established scheduling history/future call sequence.
• Falsifier 1: IP10/MHIS shows a valid scheduled call sequence around the expected date.
• Falsifier 2: adjacent calls were generated by the same schedule without a restart or start-date change.

H2 — scheduling parameters intentionally defer or hold the call.

• Supports: due date is outside call horizon, completion requirement holds the next call, or calendar shifts it.
• Falsifier 1: IP03 calculates the call inside horizon with no incomplete predecessor.
• Falsifier 2: unchanged parameters create the expected call in a representative QA preview.

H3 — counter input is stale or wrong.

• Supports: latest IW65 reading predates current operating evidence or contains reset/replacement discontinuity.
• Falsifier 1: the plan is time-based and has no counter dependency.
• Falsifier 2: current reading plus annual estimate shows the threshold is not yet reached.

H4 — scheduling succeeded; execution is overdue.

• Supports: call and order exist; IW33 shows released/partially confirmed status after the planned date.
• Falsifier 1: there is no linked call object or order.
• Falsifier 2: the order was technically completed before the deadline and completion requirement was met.

H5 — plan item or technical object is inactive/invalid.

• Supports: plan/item lock, deletion flag, invalid equipment assignment, task-list/work-center validity gap.
• Falsifier 1: every object is active and valid on the scheduling date.
• Falsifier 2: the same unchanged item produced adjacent calls normally.

Safe fixes and rollback

• Variant/job: correct in DEV/QA, run a non-creating/test selection when supported, compare selected/generated counts, then let the authorized scheduling owner promote. Roll back to the captured variant and cadence.
• Plan parameters: capture current values and future calls, change with IP02 under master-data change control, compare IP10 before/after in QA, and approve only the intended date shift. Restore captured values if dates drift.
• Initial scheduling: validate start/cycle/horizon in DEV/QA, then schedule only the approved plan. Never use restart/start-date reset casually; capture the full before/after future call list and a restore point.
• Counter: post only evidence-backed measurement through the standard measurement process. Never invent a reading to make a call due; reverse/correct under metrology audit rules if the reading is wrong.
• Execution backlog: dispatch, execute, or approved-reschedule the existing order. Never mark unperformed work complete or backdate confirmation merely to remove overdue status.
• Do not create a manual IW31 order until call history proves no call object exists. A duplicate unlinked order does not repair plan scheduling and can distort completion requirement, cost, compliance, and overdue KPI.
• Customizing: use TR, integrated QA, and rollback transport. Maintenance-plan master data follows governed master-data change history even where it is not transported.

If an erroneous production run creates calls/orders, stop the batch, record call/order IDs and dependencies, then use supported cancellation/status processing with planner, safety, production, and CO approval. Do not delete MHIS/AUFK rows.

Simulation and re-verification

Use a representative DEV/QA copy. Validate IP03 parameters → IP10 scheduling preview → IP30 test/small-scope execution → SM37 job evidence → MHIS call → IW39/IW33 order or IW29 notification. Compare expected and actual plan/item, call number, planned date, call object, and status. Start production with one plan or the smallest approved selection before returning to the normal batch scope.

ECC, S/4HANA, Public Cloud

Always name the user's release-specific app. Do not present IP10N or a Fiori app as universally available.

Counter Readings (QMSREC Table)

Equipment counters — track usage-based maintenance triggers

Recording counter reads:

• QM04: Single equipment counter read
• QM05: Multiple counters (batch entry)
• Readings feed into IP10 scheduling → if counter >= threshold, create notification

8. Breakdown Maintenance & MTBF/MTTR

Breakdown Notification Entry (IW21)

Operator or manager reports failure:

1. IW21 → Equipment/FL + Damage code + Priority
2. System creates notification (e.g., NOTIF-2024-001234)
3. Assign to maintenance team (ARBPL — work center)
4. Create order (IW31 with order type PM02)
5. Release order (RELD status) → work begins
6. Confirm completion (CO11N) → TECO
7. Settle order (KO88) → cost posted

Malfunction Start/End Time (QMEL / QMIH)

Downtime calculation:

• Total Downtime = FZEND - MERDAT
• Repair Time (MTTR) = FZEND - FZDAT
• Waiting Time = FZDAT - MERDAT (can indicate logistics delay)

MTBF (Mean Time Between Failures) Calculation

Formula: Total Equipment Uptime / Number of Failures

Uptime period: INBDT (startup date) to current date or end date

Failure count: Sum of notifications with SCHAD = malfunction codes

SAP tracking:

• EQUI-INBDT: equipment startup date
• QMEL count by equipment (table function: SELECT COUNT(*) FROM QMEL WHERE EQUNR = 'PUMP-001')
• MTBF = (days_operating) / (failure_count)

Example:

• Equipment MOTOR-001 startup: 2022-01-01
• As of 2024-04-12: 861 days operating
• Malfunction notifications: 12 failures
• MTBF = 861 days / 12 = 71.75 days average between failures

MTTR (Mean Time To Repair) Calculation

Formula: Total Repair Time / Number of Repairs

Repair time sourced:

• AUFK.FZEND - AUFK.FZDAT (actual hours spent on repair)
• Includes: labor hours (CO11N) + external service time (if PO-based)

SAP tracking:

• Table AUFK: all PM02 (breakdown) orders
• Filter: EQUNR = equipment + ORDER_TYPE = PM02
• Calculate: SUM(FZEND - FZDAT) / COUNT(*) = MTTR

Example:

• Motor MOTOR-001: 8 breakdowns over 12 months
• Total actual repair hours logged: 44 hours
• MTTR = 44 / 8 = 5.5 hours per breakdown

KPI Reporting (IW28/IW29)

IW28 — Notification Listing

• Standard SAP query: All notifications with filters (date range, equipment, status)
• Output: Excel-friendly listing with damage code, priority, creation date, completion date

IW29 — Notification Analysis (OLAP)

• Multidimensional analysis: Equipment × Damage Code × Month
• Drilldown: which equipment/codes are failure-prone
• Used to drive preventive maintenance plan decisions

9. Refurbishment & Serial Number Management

Equipment Refurbishment (Instandsetzung)

Complete overhaul of equipment — treated as major maintenance project

Order type: PM03 or special project order

Process:

1. Create maintenance order (IW31, order type PM03)
2. Assign refurbishment checklist (task list IA05)
3. GI all old/faulty parts (MIGO 261)
4. GR refurbished components (MIGO 101)
5. Update equipment master with new serial numbers if components replaced (IE02)
6. Confirmation (CO11N) → record actual hours + components replaced
7. Settlement (KO88) → post refurb cost to internal order or asset

Serial Number Management (SERGE / EQUI-SERGE)

Link between equipment and material master (MATNR)

Setup in Material Master (MM01)

• Org level: Plant
• Accounting view: Valuation class + Serial Number Profile (MMSL field)
• Serial Number Profile (MMSL):
  • Determines if serial numbers are required (batch posting) or optional (normal)
  • e.g., MMSL = "001" → Serial number required for all GR/GI of this material

Recording Serial Number in Equipment (IE01/IE02)

Field: EQUI-SERGE (equipment serial number)

• Max 30 chars
• Validated against material's serial number profile
• Used in: warranty tracking, spare parts traceability, recall management

Serial Number Change History (EQUZ)

Automatic log in EQUZ table

• Timestamp, user ID, old serial → new serial
• Useful for: component replacement audits, warranty period recalculation

Example: Motor Refurbishment Event

• Equipment MOTOR-001, Original Serial: "MOT-12345-ABC"
• Refurb replaces motor, New Serial: "MOT-67890-XYZ"
• EQUZ records: Date, User, Field=SERGE, Old=MOT-12345-ABC, New=MOT-67890-XYZ
• Warranty restart: if refurb qualifies, set INBDT to refurb completion date

10. PM-CO Integration & Cost Collection

Settlement (KO88)

Posts maintenance costs from AUFK to receiver (cost center or internal order)

Key T-codes:

• KO88: Settle individual order
• KO8G: Settle multiple orders (batch)
• KO8K: Maintain settlement rule (assignment of order type → receiver type)

Settlement Rule Setup (SPRO → Controlling → Orders → Settled Costs)

Variance Calculation (KO88 — Simulate before Actual)

Variance categories:

1. Input price variance (ABV): Material cost differences (actual price ≠ standard price)
2. Input quantity variance (AMV): More/fewer materials used
3. Overhead variance (SCRAP): Overhead surcharge % deviation
4. Remaining input (RESTINPUT): Unconfirmed costs still open

Best practice:

• Always run KO88 with "Simulate" first (F8 or simulation button)
• Review variance report → approve variances if acceptable
• Run actual settlement separately → creates FI documents (Controlling: 1200 Maintenance Costs)

Cost Planning (KALKULATIONSSCHEMA)

Annual maintenance budget planning — by equipment category, order type, cost center

Example budget structure:

• Category: Motors → Preventive (PM01) budget = 50,000 EUR
• Category: Motors → Breakdown (PM02) budget = 30,000 EUR (contingency)
• Total annual motor maintenance budget = 80,000 EUR

Tracking:

• AUFK-KOSTL → cost center commitment
• Monthly report (S_ALR_87013612 — Cost Center Actual vs. Budget) → compares maintenance spend vs. plan

11. ECC vs S/4HANA — PM Specific Differences

12. 한국 현장 특이점 (Korean Manufacturing Context)

삼성/LG/현대 공장의 SAP PM 운영 특징

설비 가동률 (Equipment Availability) 관리

• 한국 제조 표준: 최소 95% 가용율 목표 (글로벌 85% vs)
• 목표 달성: 예방보전 비율 70%, 고장정비 비율 30% 이상
• SAP tracking: IW29 → "설비가동 중단 시간 분석" 월간 report (OEE 연계)

3교대 근무 환경에서의 설비 관리

• Maintenance team: 24시간 교대근무 (Day / Evening / Night shifts)
• Notification 입력: 실시간 (각 라인의 작업자 → QMS 담당자 → PM팀에 자동 통보)
• 야간 고장 처리: 긴급 외주(Emergency Vendor) 연동 (AUFK.AUART = ER01)
• 근무 시간 외 작업 (야간할증 30%): CO11N 확인 시 "야간작업" 활동코드로 구분

안전관리와 PM 법적 연계 (산업안전보건법 제23조)

• 설비점검 이력: 무조건 5년 보관 (SAP Archive에 IW28 스냅샷)
• 부정기 점검 기록: QMEL-AUFK 링크 완전성 검증 필수 (감시원 감사 대비)
• 위험설비 (크레인, 보일러, 압력용기): 고용노동부 특별감시 → PM과 QM 완전 통합
  • 고장코드 SCHAD = "PRESSURE_RELIEF_FAIL" 발생 시 자동으로 QM 검사 오더(QM10) 생성
  • AUFK → QAIN (inspection) → 외부검사기관 위탁 처리

MES ↔ SAP PM 실시간 연동

• MES (현대 DAPS, LG MES) → 설비 상태 센서 데이터 → 5분 간격 HTTP/SOAP 호출
• SAP BAPI: BAPI_EQUI_SET_COUNTER → Equipment counter 자동 갱신
• Trigger: Counter >= Preventive Maintenance Threshold → IP10 자동 IP30 Yellow 상태 전환
• Example: Motor operating hours 10,000 threshold → MES 전송 → SAP 자동 "점검 예정" notification

외주 보전 관리 (Contract Maintenance with Vendors)

• 전문 정비업체 위탁: AUFK.AUART = PM10 + Purchase Order (ME21N) 연동
• 위탁사 작업 추적: Vendor EQUI-MFBF (equipment responsibility matrix) → 정기 외주사별 KPI 평가
• 비용: PO line → GR (MIGO 101 services) → IV (MIRO) → Cost analysis (KO88 settle to cost center)

설비별 소비자부품 (Consumable Parts) 자동 발주

• 고빈도 부품: 오일, 필터, 그리스, 밀폐제 등
• PM 예방점검 task list → 필요 부품 자동 생성 (AUFK → PR → PO auto-release)
• Example: IP01 "Monthly bearing maintenance" → Task List에 "10kg Lubricant XYZ" 지정
• → IP10 실행 시 자동으로 PR 생성 → 구매 부서 자동 승인 (workflow) → PO release

설비 성능 성과금(Incentive) 관리

• KPI 연계: MTBF ≥ 90 days → PM팀 보너스 10%, MTTR ≤ 4 hours → +5%
• 월간: IW29 OLAP → Equipment별 MTBF/MTTR 계산 → 급여 시스템(HR) 연동 (BAPI_PAYROLL_PROCESS)

설비 감가상각과의 연계 (Asset Management Integration)

• Equipment EQUI-MATNR → Asset Master (AA) 자동 링크 (S/4: AA → FIAA table)
• Maintenance cost tracking: AUFK 누적비용 / Asset net book value > 60% → 기업회계 기준 "경영상 결정" 입력
• Example: Motor 구입가 100,000 EUR, 누적 maintenance cost 63,000 EUR → 신규 구입 검토 요청

13. Standard Response Format

Follow sapstack Universal Rules:

Issue → Root Cause → Check (T-code + Table.Field) → Fix (Steps) → Prevention → SAP Note

Example: "Equipment shows MTBF 15 days — why so low?"

Issue: Motor MOTOR-001 has 8 failures in 4 months (MTBF = 15 days)

Root Cause Hypotheses:

1. Wrong damage/cause codes → notifications clustered by operator error
2. Operator misuse (overloading) → URSACHE = USER_ERROR
3. Design defect or component batch issue → QMSM-SERGE links to defective serial lot
4. Preventive maintenance never executed → check IP30 deadline monitoring

Check:

IE03 → MOTOR-001 → Equipment History tab (EQUZ)
IW24 → Filter EQUNR=MOTOR-001, date range 4 months
  → Count notifications (QMNUM)
  → Examine QMIH-URSACHE field (root cause codes)
IW28 → Report "Failure Frequency by Equipment & Cause"
  → Identify if URSACHE concentrated (indicates pattern)
IP30 → Search MOTOR-001
  → Check if any preventive tasks overdue (RED status)

Fix (if preventive maintenance overdue):

1. IP03 → display the assigned plan/item, active status, cycle, start, call horizon and completion requirement.
2. IP10 → compare the expected call sequence in DEV/QA; do not restart or save in production during diagnosis.
3. SM37 + IP30 → prove whether the deadline job/variant selected, generated, held, skipped, or errored the call.
4. If no call exists, run the smallest approved IP30 scope after QA simulation; keep generated call/object IDs.
5. If a call exists, use IW39/IW33 or IW29 to execute/reschedule that object instead of creating a duplicate.
6. Recheck MHIS call history and the next planned date; restore the prior variant/plan parameters on drift.

Fix (if root cause = design defect):

1. Create RFC ticket with equipment vendor
2. Escalate to engineering (via AUFK internal order for redesign project)
3. Flag equipment in IE02 with equipment status "Restricted" (IFLOTA flag)
4. Increase spare parts stock (MM41) until replacement arrives

Prevention:

• Establish PM02 order type cost tracking → identify underbudgeted equipment
• Monthly review: IW29 MTBF by equipment class → correlate with age/design
• Upgrade task lists (IA05) → add inspection interval reduction for high-MTBF items
• Training: operator notification accuracy (damage codes) via HR learning module

SAP Notes (if applicable):

• Check SAP Support Portal (OSS) for "equipment MTBF analysis" + equipment model

14. References

• references/ko/quick-guide.md — Maintenance order creation workflow (fast path)
• references/ko/SKILL-ko.md — Korean field language guide for PM terms
• SAP Help: SAP PM module documentation (https://help.sap.com/docs/SAP_S4HANA_CLOUD/plant_maintenance)
• Configuration: SPRO → Plant Maintenance (all customization)
• Table documentation: EQUI, IFLO, QMEL, AUFK, IP01 (F1 in SAP GUI)