Stand: 2026-03-05

Übergeordnet: WvdS-Plattform — Gesamtübersicht Verwandt: 2. CAFM-Architektur ← | 3.1 Prüfwesen | 3.2 Aufträge | 3.3 Sicherheitsgespräche | 3.4 Legacy-Analyse

Prüfung, Reparatur und Sicherheitsdokumentation sind in der aktuellen Systemlandschaft strukturell entkoppelt. WIS und TimeTrain übernehmen die Planung gesetzlicher Wiederholungsprüfungen für EMR- und Mechanik-Objekte. Die Durchführung — also das eigentliche Prüfprotokoll — landet in einer von fast vierzig separaten AMED-Anwendungsmodulen, je nachdem ob es sich um eine BGV-A3-Prüfung, eine Blitzschutzprüfung, eine Kraftverteiler-Kontrolle oder eine Beleuchtungsmessung handelt. Für Reparaturen gibt es die AMED-Reparaturliste mit über hunderttausend Einträgen auf der einen Seite und die ENIVERS-ARBEIT-Tabelle mit knapp fünfunddreißigtausend Einträgen auf der anderen — beide parallel, beide unverbunden.

Das hat eine unmittelbar spürbare Konsequenz: Wenn eine Prüfung einen Mangel ergibt und daraufhin ein Reparaturauftrag ausgelöst wird, existiert diese Verbindung nirgends formal. Sie entsteht bestenfalls durch identische Datumsangaben und dasselbe Anlagenkennzeichen, die jemand manuell zuordnet. Eine lückenlose Nachverfolgung — von der Prüfregel über den festgestellten Mangel bis zum abgeschlossenen Reparaturauftrag — ist mit den vorhandenen Systemen nicht möglich.

Hinzu kommt, dass WIS und TimeTrain nur einen Teil des Prüfspektrums abdecken. Prüfarten wie BGV A3, Blitzschutz, FI-Schutz, Sicherheitsbeleuchtung oder Rohrleitungsprüfungen sind vollständig außerhalb von WIS organisiert. Es gibt keinen einheitlichen Fälligkeitskalender, der alle Prüfarten zusammenführt, und keine gemeinsame Auswertung darüber, welche Anlage wie viele offene Prüfaufgaben aus verschiedenen Disziplinen hat.

Sicherheitsgespräche und SIL-Bewertungen werden in AMED pro EZA-Instrument geführt, in ENIVERS dagegen pro Schutzziel. Beide Systeme verwenden dasselbe Risikomodell mit vier Dimensionen (Schadensausmaß, Aufenthaltsdauer, Gefahrenvermeidung, Eintrittswahrscheinlichkeit), haben sich aber unabhängig voneinander entwickelt. Ein EMR-Ingenieur, der die SIL-Bewertung eines Instruments mit seinem Schutzziel verknüpfen möchte, muss heute beide Systeme separat aufrufen.

Das neue PIMS beseitigt diese Trennungen durch ein einziges zentrales Konzept: work.order. Ob eine Wiederholungsprüfung, eine Instandsetzung nach Schadensmeldung, eine planmäßige Wartung oder eine projektbezogene Umbaumaßnahme — alle Arbeiten werden in derselben Struktur erfasst. Das schafft eine durchgängige Kette: Eine Prüfregel erzeugt einen Prüfauftrag. Der Prüfer dokumentiert das Ergebnis. Ein festgestellter Mangel erzeugt eine Schadensmeldung, die direkt einen Reparaturauftrag öffnet. Dieser Auftrag ist lückenlos rückverfolgbar bis zur ursprünglichen Prüfvorschrift. Für Audits, Betriebsprüfungen und interne Kontrollen bedeutet das: kein manuelles Zusammensuchen mehr, keine Lücken in der Dokumentationskette.

PIMS = Plant Inspection Management System — beantwortet:

• Was muss geprüft werden? (inspection.rule, inspection.prerequisite)
• Wann ist es fällig? (inspection.schedule — im Kern: work.order vom Typ U)
• Was wurde getan? (inspection.result, work.order abgeschlossen)
• Was muss repariert werden? (fault.report → work.order vom Typ R)
• Sicherheitsgespräch geführt? (safety.conversation)

PIMS verwaltet keine Assets selbst — alle Objekte (TP, Equipment, Rohre) liegen in ENIVERSCAFM. PIMS referenziert sie über asset.item.id.

ENIVERSPIMS
├── inspection.*   — Prüfdefinition + Ergebnisse
│   ├── inspection.discipline_type   — erweiterbare Prüftypen-Tabelle
│   ├── inspection.rule              — Prüfparameter (aus WIS: iv, bz, gp, eie, pv, po, bv)
│   ├── inspection.prerequisite      — Dokumentanforderungen pro Item (aus AMED EZAPrufVor)
│   ├── inspection.result            — Prüfprotokoll (linked an work.order)
│   └── inspection.measurement       — Messwerte (aus AMED EZALebMess/EZAMessHist)
│
├── work.*         — Arbeitsaufträge (unified)
│   ├── work.order                   — zentraler Auftrag (Prüfung U, Reparatur R, Wartung W, ...)
│   ├── work.order_cost              — Kosten (Material, Fremdleistung, Montage)
│   └── work.plan                    — Arbeitsplan (aus ENIVERS tblArbeitPlan)
│
├── safety.*       — Sicherheitsgespräche + SIL-Bewertung
│   ├── safety.conversation          — unified (AMED EZASichGesp + ENIVERS tblSicherheitGespraech)
│   ├── safety.conversation_actor    — Aktoren/Sensoren pro Gespräch
│   ├── safety.conversation_justif.  — Begründungen/Stufen (aus LD tblSicherheitGespraechBegruendung)
│   └── safety.conversation_sign     — Unterschriften
│
└── fault.*        — Schadensmeldungen
    ├── fault.report                 — Schaden/Mangel (aus AMED Reparaturliste, 100.159 Einträge)
    └── fault.plan                   — Reparaturplanung (aus ReparaturListePlan/Ext)

                    inspection.rule
                    inspection.prerequisite
                           │
                           │ generiert (periodisch)
                           ▼
                    work.order (ART='U' — Überprüfung)
                           │
                    ┌──────┴──────┐
                    │             │
                    ▼             ▼
               [Bestanden]   [Mangel gefunden]
                    │             │
                    ▼             ▼
           inspection.result   fault.report
                                   │
                                   ▼
                           work.order (ART='R' — Reparatur)
                                   │
                           [Sicherheitsgespräch nötig?]
                                   │
                                   ▼
                           safety.conversation

Kernidee: work.order ist das zentrale Koordinationsobjekt — sowohl für Prüfungen (Typ U) als auch für Reparaturen (Typ R), Wartungen (Typ W) und alle anderen Arbeiten. Inspiriert vom ENIVERS ARBEIT-Konzept (34.938 Zeilen, 59 Spalten, Typ-Mix R/U/W/S…).

Details: 3.4 Legacy-Analyse (PIMS)