Das Modell stirbt beim ersten Pumpentausch

Montag, sieben Uhr, die Umwälzpumpe im Heizkreis Ost steht. Der Instandhalter hat bis Mittag eine neue eingebaut, ein anderes Fabrikat, weil der Großhändler nur das auf Lager hatte. Er fotografiert das Typenschild, schickt das Bild in die Gruppe, und im CAFM wird der Auftrag auf erledigt gesetzt. Das Modell, das die Planer bei der Übergabe vor zwei Jahren abgeliefert haben, liegt auf dem Laufwerk und zeigt die alte Pumpe.

Achtzehn Monate später wird die Kesselanlage erneuert. Der Planer bekommt das Modell als Bestand, mit dem Hinweis, es sei nach ISO 19650 erstellt. Er plant die Hydraulik auf eine Pumpe, die es nicht mehr gibt, und merkt es auf der Baustelle.

Niemand hat einen Fehler gemacht. Der Instandhalter hat geliefert, was bestellt war. Das CAFM zeigt erledigt. Das Modell zeigt den Tag der Übergabe. Die Szene ist erfunden, das Muster kennt jeder, der ein Gebäude länger als die Gewährleistung betreibt.

Eine Schleife statt einer Phase

ISO 19650-2 hat ein Ende. Der achte Schritt heißt Projektabschluss, danach ist der Prozess vorbei. ISO 19650-3 hat keines. Sie verlangt, dass der Prozess während der gesamten Betriebsphase jedes ausgewählten Assets läuft, und die letzte Entscheidung in ihrem Prozessbild fragt nur, ob der Besteller noch für das Asset verantwortlich ist. Solange ja, geht es zurück an den Anfang.

Die acht Aktivitäten sind dieselben wie in der Lieferphase, in anderer Form. Beurteilung und Bedarf, Ausschreibung oder Aufforderung zur Leistung, Reaktion darauf, Bestellung, Mobilisierung, Erstellung, Annahme, und statt des Projektabschlusses die Anreicherung des Asset-Informationsmodells. Der Unterschied liegt nicht in den Schritten. Er liegt darin, was sie anstößt. In der Lieferphase sind das Meilensteine. Im Betrieb sind es Ereignisse, und die Norm nennt sie auslösende Ereignisse.

Dabei gibt es zwei Arten, und der Unterschied ist der Zeitpunkt der Beauftragung. Jährliche Wartung, Inspektionen, strategische Liegenschaftsüberprüfungen, Abrufverträge für gewöhnliche Reparaturen: Diese Ereignisse sind vorhersehbar, der Bereitsteller wird davor beauftragt, und die Norm verlangt von ihm, seine Leute und seine Technik in Bereitschaft zu halten, bis das Ereignis eintritt. Unerwartete Ausfälle, Unfälle, Hochwasser und die Entscheidung für ein neues Projekt sind die andere Art. Da wird nach dem Ereignis bestellt. Und wer ein Asset kauft, bekommt das Modell vom bisherigen Eigentümer und prüft es gegen die eigenen Anforderungen, ohne je etwas bestellt zu haben.

Neunzehn Anlässe, und der Wartungsvertrag ist einer

Die Norm verlangt vom Besteller, die vorhersehbaren Ereignisse zu ermitteln und aufzuschreiben, bei denen im Betrieb neue oder geänderte Information über ein Asset entsteht oder gebraucht wird. Der Anhang nennt neunzehn Beispiele. Inspektion. Instandhaltung, geplant oder als Reaktion. Kleinere Arbeiten wie Reparatur und Komponentenaustausch, größere wie Sanierung. Ersatz, Lebensende, geänderte Vorschriften, geänderte Anforderungen des Regulierers, Notfallplanung, eine neue Bewertung des Risikos oder des Werts. Und drei, die in Betreiberorganisationen selten als Informationsereignis gelten: der Wechsel des Eigentümers, des Betreibers und des Instandhaltungsdienstleisters.

Für jedes dieser Ereignisse benennt der Besteller einen federführenden Bereitsteller, auch für die, die im Katalog nicht standen. Und für jede Bestellung und jedes Ereignis legt er Austausch-Informationsanforderungen fest: welche Information in welcher Bedarfstiefe, mit welcher Frist, nach welchen Annahmekriterien. Die Norm hebt dabei einen Fall eigens hervor. Bei Ereignissen, die eine Notfallreaktion verlangen, etwa dem vorhersehbaren Ausfall kritischer Betriebsmittel, sind die Anforderungen im Voraus vorzubereiten, damit die Bestellung sofort ausgelöst werden kann.

Der Pumpentausch vom Anfang ist Ereignis Nummer fünf in der Liste. Der Instandhalter hatte einen Wartungsvertrag, aber keine Informationsanforderung, und darum war das Foto vom Typenschild die vollständige Lieferung. Bestellt worden war nichts anderes.

Nicht jedes Asset

Bevor irgendetwas bestellt wird, verlangt die Norm eine Auswahl. Der Besteller ermittelt die Assets, bei denen das Management der Information einen Nettonutzen bringt, und die Norm meint das wörtlich: Kosten und Nutzen, einschließlich der Ressourcen für Erfassung und Pflege und dessen, was eine nachträgliche Erfassung kosten würde. Als Kriterien nennt sie das Eigentum, die Strukturpläne der Organisation, die Wirkung des Assets auf Effizienz und Effektivität des Betriebs, seine Bedeutung für die wesentlichen Geschäftsvorgänge und seinen Zustand. Ein Bestandsmodell für alles ist demnach kein Ziel der Norm. Es ist der Fehler, den sie mit dem ersten Schritt verhindern will.

Erst danach kommt die Kaskade. Aus den Anforderungen der Organisation folgen die Anforderungen je Asset, daraus die Austauschanforderungen je Bestellung und Ereignis, und die werden vom Asset-Informationsmodell erfüllt. Die Frage ist nie, was man über die Pumpe wissen könnte. Sie lautet, welche Entscheidung der Organisation an der Pumpe hängt. Fällt bei ihrem Ausfall ein Rechenzentrum aus, steht sie auf der Liste. Versorgt sie den Heizkörper im Archivflur, vielleicht nicht.

Die Norm sagt selbst, wie sie skaliert. Ihre langen Listen mit Punkten, die der Besteller in Betracht ziehen muss, dürfen bei kleinen Assets rasch abgehakt oder als nicht relevant verworfen werden, und als Weg dorthin nennt sie Vorlagen je Größenklasse. Ein Portfolio mit dreihundert Gebäuden und ein einzelnes Amtsgebäude arbeiten mit demselben Prozess und verschieden dicken Ordnern.

Das Asset-Informationsmodell ist kein Programm

Die Norm verlangt, dass das Asset-Informationsmodell föderiert ist, also Inhalte verschiedener Bereitsteller aufnehmen kann. Sie legt keine Speichertechnologie fest und schließt keine aus. Das Modell darf aus einer beliebigen Kombination neuer und bestehender Unternehmenssysteme bestehen, CAFM, ERP, Dokumentenablage, Geodaten, Zustandsüberwachung, solange sie verknüpft sind und ihre Inhalte nach dem Arbeitsablauf der gemeinsamen Datenumgebung gelenkt werden. Das ist die Stelle, an der viele Diskussionen über die Betriebsphase falsch abbiegen. Sie handeln von Software. Die Norm handelt davon, was jeder Informationscontainer tragen muss, egal wo er liegt.

Fünf Dinge muss die Datenumgebung dafür können. Jedem Container eine eindeutige Kennung nach dokumentierter Konvention geben. Ihm Status, Bearbeitungsstand und Klassifikation als Attribute zuordnen. Ihn von einem Status in den nächsten überführen. Bei jedem Übergang festhalten, wer das wann getan hat. Und den Zugang je Container steuern. Ein Foto in einer Chatgruppe kann keines davon. Das CAFM kann es vielleicht, und die Frage ist, ob der Pumpentausch dort mit Kennung, Status und Stand ankommt oder als Häkchen.

Dazu kommen zehn Prozesse, mit denen das Modell gepflegt wird, und die Liste liest sich wie ein Katalog dessen, was in der Szene vom Anfang gefehlt hat. Wer erstellt, pflegt, überträgt, archiviert. Was bei einem Wechsel des Eigentümers oder Bestellers mit dem Modell passiert. Versionskontrolle und Prüfung gegen die Anforderungen. Löschen, was veraltet oder unzuverlässig ist. Schutz vor technischer Überalterung, damit die Datei in zwölf Jahren noch zu öffnen ist. Und als letzter Punkt das vereinbarte Maß der Übereinstimmung zwischen dem Inhalt des Modells und dem Zustand des Assets. Die Norm nennt als Maß dafür das Zeitintervall: wie lange darf zwischen der Änderung an der Pumpe und ihrem Abbild im Modell liegen. Ein Tag, dreißig Tage, ein Jahr. Irgendeine Zahl, die jemand unterschrieben hat.

Ein Modell, das niemand pflegt, ist kein Bestandsmodell. Es ist ein Foto vom Tag der Übergabe.

Der Einwand, der bleibt

Der Einwand lautet: Wir haben ein CAFM. Das stimmt meistens, und es ist kein Widerspruch. Das CAFM steht im Anhang der Norm als eines der Systeme, aus denen das Asset-Informationsmodell bestehen kann. Die Frage ist nicht, ob es da ist. Die Frage ist, ob der Pumpentausch darin mit Kennung, Status und Bearbeitungsstand ankommt, ob das Modell davon erfährt und ob jemand vereinbart hat, bis wann.

Ehrlich ist auch das andere. Der Prozess kostet im Ruhezustand Geld. Der Bereitsteller hält Leute und Technik in Bereitschaft für ein Ereignis, das vielleicht erst in achtzehn Monaten eintritt. Die Pflegeprozesse laufen ohne Anlass. In der Lieferphase gibt es eine Abnahme, an der etwas fällig wird. Im Betrieb wird nichts fällig, und das ist der eigentliche Grund, warum der Prozess nicht läuft. Der Grund ist keine Unkenntnis. Es gibt keinen Termin, an dem jemand fragt. Die Norm weiß das. Sie empfiehlt, den Nutzen des ganzen Prozesses in regelmäßigen Abständen formell zu prüfen, Kosten gegen Nutzen. Wer nach zwei Jahren keinen findet, nimmt das Asset von der Liste. Das widerspricht der Norm nicht. Das Modell verrotten zu lassen und weiter Bestand zu nennen, ist die andere Variante, und sie steht nirgends.

Das Projekt endet mit der Übergabe. Das Asset fängt dort erst an.

Was ein Betreiber in dieser Woche tun kann

Nichts davon braucht ein neues System. Es braucht vier Entscheidungen, die bisher niemand getroffen hat, weil sie nie fällig waren.

1. Die Assets aufschreiben, bei denen gepflegte Information einen Nettonutzen hat, mit einem Satz Begründung je Zeile. Was nicht auf die Liste kommt, wird bewusst nicht gepflegt. Das ist ein Ergebnis, kein Versäumnis.
2. Die Ereignisse der nächsten zwölf Monate notieren, Wartung, Inspektionen, bekannte Umbauten, auslaufende Verträge, und zu jedem die Frage: Wer liefert danach welche Information, und ist der schon beauftragt?
3. Eine Zahl festlegen, wie viele Tage zwischen einer Änderung am Asset und ihrem Abbild im Modell liegen dürfen. Die Zahl darf groß sein. Sie muss nur existieren und jemandem gehören.
4. Das Asset-Informationsprotokoll in den nächsten Wartungsvertrag nehmen: Rechte am Modell, Lizenz, und was bei Kündigung mit den Daten passiert. Der Dienstleisterwechsel ist selbst ein auslösendes Ereignis, und er ist der Moment, in dem das sonst verhandelt wird.

Die Anforderungen der Organisation und die je Asset erzeugt der Generator kostenlos aus Ihren Angaben, die Vorlagen dazu stehen hier und hier. Was fehlt, ist selten das Dokument mit den Anforderungen. Es ist der Katalog der Ereignisse, die Pflegeprozesse und das Protokoll im Vertrag.

Quellen

• ISO 19650-3:2020, Informationsmanagement mit BIM, Betriebsphase der Assets. Zitierte Stellen: Einleitung 0.1 zu den Ereignisarten und zur Verhältnismäßigkeit, 0.3 zum Umgang mit den Listen, 0.6 zur regelmäßigen Prüfung des Nutzens, 4.1 und Bild 4 zum Prozess, 4.2 zum Verhältnis zu Teil 2, 5.1.3 zur Auswahl der Assets, 5.1.5 zu den vorhersehbaren Ereignissen, 5.1.9 zur Datenumgebung, 5.1.11 zum föderierten Modell, 5.1.12 zu den Pflegeprozessen, 5.1.13 zum Protokoll, 5.2.1 und 5.2.2 zu Bereitsteller und Anforderungen je Ereignis, 5.5.4 zur Bereitschaft, 5.7.2 zur Annahme beim Erwerb, 5.8.1 zur Anreicherung, Anhang A.3 mit den Beispielen für Ereignisse und A.5 mit den Beispielen für Unternehmenssysteme.
• ISO 19650-1:2018, Begriffe und Grundsätze, Abschnitt 12 zur gemeinsamen Datenumgebung und 11.2 zur Informationsbedarfstiefe. Die deutschen Bezeichnungen folgen der deutschsprachigen Ausgabe der Norm.
• Auf dieser Website: ISO 19650 erklärt, Organisatorische Informationsanforderungen, Asset-Informationsanforderungen.