Schnittstellenmatrix: RACI-Struktur, Verantwortlichkeiten

Die Schnittstellenmatrix ist zeilenorientiert nach Systemen und Prozessen aufgebaut. Jede Zeile bildet genau eine operative oder steuernde Schnittstelle ab. Für jede Schnittstelle werden ein führender Datensatz oder ein führendes System, ein eindeutiger accountable Owner, operative responsible Rollen, verpflichtend zu konsultierende Rollen sowie reine Informationsadressaten festgelegt. Das verhindert unklare Parallelverantwortungen und macht abweichende Freigabezuständigkeiten sichtbar. Die Grundlogik entspricht dem RACI-Verständnis, nach dem Verantwortlichkeiten in Geschäfts- und Projektaktivitäten eindeutig zugewiesen werden und mindestens eine accountable Instanz vorhanden sein muss.

Fachlich wird zwischen drei Schnittstellenarten unterschieden. Objektbezogene Schnittstellen betreffen Stammdaten, Anlagen- und Dokumentenbezüge. Ereignisbezogene Schnittstellen betreffen Alarme, Tickets, Störungen, Rechteanträge, Freigaben und Wiederanläufe. Dokumentbezogene Schnittstellen betreffen Revisionsstände, Prüf- und Betreiberpflichtennachweise, Handover-Pakete sowie KPI- und Managementreports. Diese Trennung ist mit aktuellen Plattformfähigkeiten konsistent, da marktübliche CAFM-/IWMS-Lösungen offene Integrations- und Konfigurationstools, IoT-Services und ERP-Anbindungen bereitstellen, während GLT-/BMS-Plattformen offene Architektur, Drittanbieterintegration, Northbound-/Southbound-Integration sowie standardisierte Kommunikationsprotokolle und alarmorientierte Bedien- und Routingfunktionen vorsehen.

Für die Ausschreibung wird je Attribut- und Vorgangsgruppe ein führender Datenträger festgelegt. Das CAFM bzw. IWMS führt Objekt- und Vorgangsstrukturen, Arbeitsaufträge, Prüf- und Nachweisreferenzen sowie Reportingbezüge. Die GLT führt Automationszustände, Alarmursprünge, Trends und feldnahe Betriebsdaten. Das ERP führt Kosten-, Beschaffungs- und Freigabereferenzen. Herstellerdokumentationen belegen die technische Tragfähigkeit dieses Zuschnitts durch offene APIs, OSLC-Kopplungen, ERP-Integration, Smart-Building-Verbindungen sowie Alarm-zu-Workflow-Mechanismen.

Die RACI-Begriffe werden in diesem Anhang wie folgt verwendet. Responsible bezeichnet die ausführende Rolle, die die Schnittstelle operativ bearbeitet, Daten liefert oder Maßnahmen umsetzt. Accountable bezeichnet die Instanz mit Ergebnishoheit, Freigabeverantwortung und Abschlussentscheidung. Consulted bezeichnet Rollen, die vor Freigabe oder Entscheidung zwingend einzubinden sind. Informed bezeichnet Rollen, die über Status, Entscheidung oder Abschluss zu unterrichten sind. Die Grundregel lautet: je Schnittstelle genau eine accountable Instanz; mehrere responsible Rollen sind zulässig, wenn operative Ausführung und Systemadministration getrennt sind.

Für den vorliegenden Zuschnitt gilt folgende Rollenverteilung. Der Bauherr/Auftraggeber ist accountable für retained Entscheidungen, Budget- und Umfangsänderungen, kritische betriebliche Freigaben, Projektübergaben, KPI-/SLA-Festlegungen und Managementeskalationen. Der FM-Provider ist verantwortlich für operative Leistungserbringung, Service Desk, Dispatch, Koordination von Arbeitsaufträgen und Steuerung eingebundener Nachunternehmer. Die Technische Betriebsführung ist accountable im Regelbetrieb für technische Priorisierung, Freigaben innerhalb delegierter Betriebsgrenzen, Wartungs- und Prüfsteuerung, Nachweisführung, Standard Changes und die erste fachliche Eskalationsstufe. Der CAFM-Administrator ist verantwortlich für Datenmodellpflege, Workflowkonfiguration, Ticket- und Nachweisstruktur, Berichtsextrakte sowie strukturelle Datenqualität. Der GLT-Integrator ist verantwortlich für Alarmrouting, Punkt- und Ereignislogik, Parametrierungen, Trend- und Statusschnittstellen sowie technische Re-Integration nach Änderungen oder Störungen. Der IT-Betrieb ist accountable für Identitäts- und Berechtigungsmanagement, Fernzugriff, Netz- und Sicherheitsfreigaben, Middleware, Backup-, Zeit- und Verfügbarkeitsaspekte systemnaher Schnittstellen. Externe Dienstleister sind verantwortlich für fachgewerkspezifische Leistungen, Prüfungen, OEM-Eingriffe und Rückmeldungen. Die Nutzervertretung wird bei nutzerwirksamen Änderungen, Abschaltungen, Servicefenstern, Kommunikationslagen und XLA-/Erlebniswerten konsultiert und im Ereignisfall informiert. Die Notwendigkeit, alle Nachfrage- und Betreiberorganisationen einschließlich externer Parteien, Meldewege, Vertretungen und Zugriffe eindeutig festzulegen und aktuell zu halten, ist in den BSI-Unterlagen ausdrücklich hervorgehoben.

Die nachstehende Matrix bildet den vollständigen Schnittstellenzuschnitt für den Ausschreibungsgegenstand dieses Anhangs ab. Die Auswahl der Zeilen folgt der im TTS-Konzept angelegten Betriebs-, Freigabe- und Datensystematik und ist an aktuelle FM-/GA-Integrationsmuster gespiegelt.

Abkürzungen der Stakeholder: AG = Bauherr/Auftraggeber, FMP = FM-Provider, TBF = Technische Betriebsführung, CAFM = CAFM-Administrator, GLT = GLT-Integrator, IT = IT-Betrieb, EXT = Externe Dienstleister, NUV = Nutzervertretung

Die Matrix folgt zwei verbindlichen Regeln. Erstens erhält jede Zeile genau eine accountable Instanz. Zweitens entstehen mehrere responsible Rollen nur dort, wo Ausführung, Systemadministration und fachtechnische Umsetzung voneinander getrennt sind. Damit werden Verantwortungsüberlagerungen vermieden, ohne notwendige Mitwirkungspflichten auszublenden. Die zugrunde liegende Ein-Owner-Logik ist sowohl mit dem allgemeinen RACI-Verständnis als auch mit den BSI-Anforderungen an dokumentierte Zuständigkeiten, Schnittstellen und Eskalationen konsistent.

Die Eskalations- und Abstimmungswege sind je Schnittstelle so festgelegt, dass das führende System, der Primärweg der Bearbeitung, die Regelkommunikation, die Eskalationskette und die SLA-/OLA-Verknüpfung ohne Auslegungsspielraum erkennbar sind. Dies ist insbesondere deshalb erforderlich, weil aktuelle TGM-/GA-Fachvorgaben ausdrücklich verlangen, Schnittstellen, Meldewege, Vertretungen, physische und Remote-Zugriffe, Ticket-Systeme sowie Eskalationsstufen vorab festzulegen und nicht erst im Störungsfall zu verhandeln. Herstellerseitig wird dies durch Alarmfilter, Benutzerzuweisungen, Benachrichtigungsmechanismen, offene Integrationsschnittstellen und workflowfähige Eventmodelle unterstützt.

Für die nachfolgende Tabelle gelten folgende Kürzel. SLA-RT = Reaktionszeit, SLA-RS = Wiederherstellungszeit, SLA-DQ = Datenqualität/Aktualität, SLA-CHG = Change-Durchlauf, SLA-RPT = Berichtstermin, SLA-HO = Handover-Frist, OLA-SYS = interne Übergabe zwischen Systemrollen, OLA-DSP = interne Dispatch-Übergabe, OLA-APP = interne Freigabezeit.

• Schnittstellen-Meetings werden systematisch nach Zweck getrennt geführt:

• operatives Board für Tickets,

• Alarme und Rückstände;

• Integrationsrunde für CAFM/GLT/IT;

• Change Board für Änderungen;

• KPI-/SLA-Review für Leistungsauswertung;

• Governance-Termin für retained Entscheidungen und Abweichungsfreigaben.

• Protokolle sind spätestens 24 Stunden nach Termin bereitzustellen und enthalten mindestens

• Datum,

• Teilnehmer,

• betroffene Assets oder Systeme,

• Referenz-ID des führenden Datensatzes,

• Entscheidung,

• Maßnahmenverantwortliche,

• Frist,

• Eskalationsstufe und Verknüpfung zum einschlägigen SLA-/OLA-Kriterium.

Änderungen an Rollen, Rechten, Prozessen, Meldewegen oder Eskalationsstufen lösen zwingend eine Fortschreibung der Matrix, der Kontaktkette und der zugrunde liegenden Protokollvorlagen aus.

Die Eskalationsstufen sind auslöserbezogen und nicht organisationsbezogen zu lesen. Ereignisse mit rein operativer Tragweite verbleiben innerhalb der delegierten Betriebsgrenzen. Ereignisse mit Sicherheits-, Verfügbarkeits-, Budget-, Umfangs- oder IT/OT-Relevanz werden unverzüglich auf die nächsthöhere Stufe gehoben. Für GA-bezogene externe Schnittstellen sind dabei nur die tatsächlich erforderlichen Übergänge freizugeben; für alle freigegebenen Wege sind Authentisierung, Segmentierung, dokumentierte Zugriffe, Benutzerzuweisung und Wiederherstellungslogik verbindlich vorzusehen.

• die endgültige Systemliste mit Versionen,

• Produktiv- und Testumgebungen,

• Middleware- bzw. Broker-Komponenten und den tatsächlich eingesetzten Protokollen;

• die exakten organisatorischen Rollennamen einschließlich Stellvertretungen, Rufbereitschaften und 24/7-Erreichbarkeiten;

• die endgültigen SLA-, OLA- und gegebenenfalls XLA-Werte einschließlich Reaktions-, Wiederherstellungs-, Datenaktualitäts-, Reporting- und Freigabefristen;

• die genaue Abgrenzung zwischen Standard Change, kritischem Change und Projektänderung;

• die verbindlichen Verantwortungsübernahmen bei Drittlieferanten, OEMs und Gewährleistungsträgern;

• die finalen Handover-Punkte zwischen Bau, Betrieb, Produktion, IT/OT und externen Servicepartnern;

• die konkrete Zuordnung des führenden Systems je Attributgruppe und je Vorgangsart;

• die endgültigen CAFM-Datenmodell-IDs, Objektklassen, Pflichtattribute, Referenz- und Mappingfelder;

• die GLT-Punktlisten, Alarmklassen, Prioritäten, Routingregeln und Quittierungslogiken; die ERP-Referenzen für Kostenstellen, Innenaufträge, Bestellarten und Budgetobjekte;

• die verbindlichen Protokollvorlagen für Operations Board, Change Board, KPI-/SLA-Review, Übergabeboard und Notfalllagebild;

• die Abnahmekriterien für Schnittstellenfunktion, Testnachweise und Datenvollständigkeit; sowie die datenschutz- und IT/OT-sicherheitsbezogenen Detailfestlegungen für Fernzugriff, Session Logging, Rollenverwaltung und revisionssichere Archivierung.