KI im Facility Management: Störungen, Einsätze und Leistungsnachweise verbinden

Um 22:47 Uhr meldet ein Mieter telefonisch: „Im dritten Stock tropft Wasser aus der Decke.“ Der Gebäudekomplex hat mehrere Treppenhäuser, über der genannten Fläche verlaufen verschiedene Leitungen und im System existieren zwei ähnlich benannte Objekte. KI im Facility Management kann die Meldung strukturieren und fehlende Angaben abfragen. Ob eine akute Gefährdung vorliegt, welche Absperrung erforderlich ist und welcher Bereitschaftsdienst ausrückt, muss ein kontrollierter Notfallprozess entscheiden.

Der eigentliche Engpass liegt selten in der Nachricht allein. Objektstamm, technische Anlagen, Verträge, Servicezeiten, Bereitschaften und frühere Einsätze befinden sich häufig in getrennten Systemen. Ein Mitarbeiter überträgt die Meldung aus Telefon oder E-Mail, sucht den Standort, prüft den Vertrag und ruft mehrere Personen an. Nach dem Einsatz fehlen wiederum Material, Foto oder Unterschrift für die Abrechnung.

SW Business Solutions entwickelt keine unveränderliche Facility-Management-Komplettlösung. Vorhandene CAFM-, ERP-, CRM-, Gebäudeleit-, Dokumenten- und Ticketsysteme bleiben führend, wenn sie den Betrieb tragen. SW Business Solutions verbindet sie und entwickelt fehlende Schnittstellen, mobile Oberflächen, Prüfworkflows, Datenmodelle und KI-Komponenten für den konkreten Gebäudeservice.

KI im Facility Management beginnt mit einer eindeutigen Ereigniskette

Eine Störung wird erst dann steuerbar, wenn Kanal, Objekt, Anlage, Vertrag, Einsatz und Nachweis zum selben Vorgang gehören. Dafür benötigt jeder Fall eine eindeutige Vorgangsnummer. Ein Foto, eine E-Mail oder ein Telefontranskript wird diesem Vorgang zugeordnet, behält aber seine eigene Herkunft und Version.

Ein Sprachmodell kann aus „bei der Lüftung im Seminarraum klappert etwas“ mögliche Felder erzeugen. Es darf nicht raten, welche der drei Lüftungsanlagen gemeint ist. Die Anwendung zeigt passende Objekte und fragt gezielt nach Raumnummer, Anlagenkennzeichnung oder Foto.

Meldungen aus Telefon, E-Mail und Portal zusammenführen

Ein Portal kann Pflichtfelder erzwingen. In der Praxis kommen Störungen trotzdem telefonisch, per E-Mail, über einen Hausmeister oder als Freitext aus einer Mieter-App. Die Eingänge müssen nicht gleich aussehen, am Ende aber dasselbe Vorgangsmodell füllen.

Ein kontrollierter Ablauf kann so arbeiten:

1. Die Originalmeldung wird unverändert gespeichert.
2. Das System erkennt Kanal, Absender und möglichen Kunden.
3. KI extrahiert Objekt, Ort, Symptom, Zeitpunkt und genannte Auswirkungen.
4. Eindeutige Stammdaten werden regelbasiert ergänzt.
5. Fehlende kritische Angaben werden abgefragt.
6. Ein Vorgang entsteht erst mit nachvollziehbarem Objektbezug.
7. Unsichere Fälle landen bei der Leitstelle oder Bereitschaft.

Bei einem Anruf außerhalb der Bürozeiten kann ein KI-Telefonassistent für Überlauf und Bereitschaft die strukturierten Angaben aufnehmen. Er sollte dem Anrufer die Adresse, Rückrufnummer und Problembeschreibung wiederholen. Eine bestätigte Aufnahme ist noch keine Zusage, dass ein Techniker in einer bestimmten Zeit eintrifft.

Die Qualität lässt sich an falsch zugeordneten Objekten, fehlenden Rückrufdaten, manueller Erfassungszeit und Meldungen ohne bearbeitbaren nächsten Schritt messen. Eine hohe Automatisierungsquote allein sagt wenig aus, wenn dringende Fälle falsch eingeordnet werden.

Objekt- und Anlagenstamm sind wichtiger als ein großes Sprachmodell

Mehrere Liegenschaften können ähnliche Gebäudenamen, Raumbezeichnungen und Anlagentypen verwenden. Eine „Heizung Haus 2“ ist ohne Standort und technische Kennung nicht eindeutig. Der Objektstamm benötigt eine Hierarchie, die zum realen Betrieb passt: Auftraggeber, Vertrag, Liegenschaft, Gebäude, Etage, Bereich, Anlage und Bauteil.

Für jede wartungsrelevante Anlage sind je nach Prozess beispielsweise Hersteller, Typ, Seriennummer, Standort, Inbetriebnahme, Dokumente, Wartungsplan und zuständige Gewerke erforderlich. Dubletten und veraltete Bezeichnungen führen auch bei guter KI zu falschem Kontext.

Das BIM-Portal des Bundes betont für digitale Bauwerksmodelle, dass Auftraggeber festlegen müssen, welche Informationen in welcher Detaillierung und welchem Format geliefert werden. Diese Logik gilt ebenso für den Betrieb: Ein Modell ist nur nützlich, wenn der Informationsbedarf des Gebäudeservices vorab definiert wurde. Ein aufwendiges 3D-Modell ist für die Störungsbearbeitung nicht zwingend. Eindeutige Anlagenkennungen und gepflegte Merkmale sind oft der bessere Anfang.

KI kann ähnliche Anlagennamen oder widersprüchliche Standorte markieren. Zusammengeführt werden Stammsätze erst nach fachlicher Prüfung. Sonst verschwindet möglicherweise die Historie einer real vorhandenen Anlage in einem falschen Datensatz.

Kritische Störungen benötigen feste Notfall- und Eskalationsregeln

Wasser, Brandgeruch, Stromausfall, Aufzugstillstand oder der Ausfall einer sicherheitsrelevanten Anlage können Menschen und Betrieb gefährden. Ein frei formulierendes Modell ist nicht die letzte Entscheidungsinstanz für solche Fälle.

Der sichere Prozess kombiniert mehrere Ebenen:

• feste Warnbegriffe und bestätigende Rückfragen
• objektbezogene Notfallpläne und Kontaktketten
• vertraglich definierte Bereitschaften
• manuelle Eskalation bei Unsicherheit
• protokollierte Übergabe mit Zeitpunkt

Ein Modell kann „Wasser läuft aus der Decke“ von „Wasserfleck seit letzter Woche“ unterscheiden und eine Priorität vorschlagen. Die Anwendung prüft zusätzlich, ob das Objekt eine besonders schützenswerte Nutzung hat, welche Leitungen bekannt sind und welche Rolle entscheiden darf. Fehlt der Objektkontext, wird nicht automatisch herunterpriorisiert.

Die Rückfallebene muss auch ohne KI funktionieren. Bei Modell- oder Netzwerkausfall greifen definierte Telefonziele, Checklisten und Rufbereitschaften. Ein sicherheitskritischer Prozess darf nicht davon abhängen, dass ein externer Sprachdienst erreichbar ist.

Vertrags-SLAs sind keine Schätzung der KI

Ein Service-Level kann Reaktions-, Rückmelde- oder Wiederherstellungszeiten festlegen. Welche Uhr läuft, hängt von Vertrag, Leistungsart, Objekt, Priorität und Servicekalender ab. Ein Modell darf diese Bedingungen nicht aus einem ähnlich klingenden Vertrag ableiten.

Die SLA-Logik wird strukturiert hinterlegt:

• gültiger Vertrag und Leistungsbereich
• vereinbarte Prioritätsklassen
• Beginn, Pause und Ende einer Frist
• Geschäfts-, Bereitschafts- und Feiertagskalender
• erforderliche Eskalationsstufe
• dokumentierte Gründe für zulässige Unterbrechungen

KI kann Vertragsdokumente bei der Erfassung unterstützen und auf mögliche Klauseln hinweisen. Eine verantwortliche Person überführt freigegebene Regeln in das System. Im laufenden Vorgang berechnet eine deterministische Funktion die Fristen. So lässt sich später erklären, weshalb ein Fall eskaliert wurde.

Ein roter Hinweis „SLA gefährdet“ benötigt den Bezug zum konkreten Zeitwert und Status. Eine bloße Stimmungseinschätzung aus dem Meldungstext wäre dafür ungeeignet.

Klassifikation führt zum Gewerk, nicht automatisch zum richtigen Techniker

Die Meldung „Licht im Flur fällt immer wieder aus“ kann Elektrik, Steuerung, Präsenzsensor oder Leuchtmittel betreffen. KI kann ein wahrscheinliches Gewerk vorschlagen und passende Fragen auslösen. Die endgültige Einsatzplanung benötigt weitere Bedingungen.

Dazu gehören Qualifikation, Objektberechtigung, Bereitschaft, Arbeitszeit, Entfernung, benötigte Werkzeuge, Ersatzteile und bekannte Zugangsbedingungen. Bei Fremdfirmen kommen Vertragsumfang und Beauftragung hinzu. Eine mathematische Zuordnung kann mehrere geeignete Einsätze bündeln; das Modell liefert höchstens Klassifikation oder Zeitprognose.

Die Disposition sieht, warum ein Techniker vorgeschlagen wird. Eine Person kann ablehnen, etwa weil eine Spezialfreigabe fehlt oder ein Ersatzteil erst am nächsten Morgen verfügbar ist. Ablehnungsgründe verbessern Stammdaten und Regeln, werden aber nicht ungeprüft als Trainingsdaten übernommen.

Einsatzvorbereitung bringt Objektwissen auf das mobile Gerät

Vor Ort fehlen oft genau die Informationen, die im Büro vorhanden sind: letzter Befund, Anlagenfoto, Zugangscode, Ansprechpartner, Schaltplan oder verwendetes Ersatzteil. Ein digitaler Einsatz bündelt nur die Daten, die für den Auftrag erforderlich sind.

Eine mobile Technikeransicht kann enthalten:

• bestätigte Adresse und Zugangsweg
• betroffene Anlage mit Kennzeichnung und Foto
• aktuelle Störungsbeschreibung und Rückfragen
• letzte relevante Einsätze
• freigegebene Anleitung und Sicherheitsinformation
• erwarteter Leistungsumfang
• erforderliche Nachweisfelder

Die eigene Monteur-App für Unternehmen vertieft mobile Aufträge, Fotos, Offline-Nutzung und Statusrückmeldungen. Für den Facility-Service ist entscheidend, dass die App nicht alle Objekt- und Vertragsdaten kopiert. Sie erhält einen begrenzten, versionierten Einsatzkontext.

In Kellern und Technikräumen fehlt häufig eine stabile Verbindung. Zulässige Daten werden verschlüsselt offline bereitgestellt. Bei der späteren Synchronisierung prüft das System, ob sich Auftrag oder Priorität zwischenzeitlich geändert haben. Ein älterer Offline-Status überschreibt keine neuere Dispositionsentscheidung.

Wissenszugriff braucht freigegebene Quellen und Versionen

Techniker benötigen Herstellerunterlagen, objektspezifische Hinweise, frühere Befunde und interne Arbeitsanweisungen. Eine KI-Suche kann passende Textstellen finden und mit Quellenangabe anzeigen. Sie sollte keine Reparaturanweisung aus mehreren Dokumenten frei zusammensetzen, wenn dadurch sicherheitsrelevante Schritte verändert werden.

Jede Antwort nennt Dokument, Version und Gültigkeitsbereich. Ein Handbuch für eine ähnliche Anlagenserie ist kein Beleg für die konkret verbaute Anlage. Veraltete Dokumente bleiben archiviert, werden in der Standardsuche aber gesperrt oder deutlich gekennzeichnet.

Der Zugriff folgt Rollen und Objektzugehörigkeit. Ein externer Dienstleister sieht die für seinen Auftrag freigegebenen Unterlagen, nicht sämtliche Grundrisse, Schlüsselpläne oder Mieterdaten. Korrekturen aus einem Einsatz werden zunächst als Hinweis erfasst und erst nach fachlicher Prüfung in die Wissensbasis übernommen.

Gebäudeleittechnik und Störungsmeldung beschreiben verschiedene Beobachtungen

Die Gebäudeleittechnik meldet Messwert, Grenzwertverletzung oder Schaltzustand. Ein Nutzer beschreibt dagegen eine Wirkung: Raum zu kalt, Geräusch, Geruch oder Ausfall. Beide Informationen können denselben Vorgang betreffen, sind aber nicht identisch.

Eine Integration ordnet GLT-Meldungen über Anlagenkennung und Zeitfenster einem Vorgang zu. Regeln fassen bekannte Alarmfolgen zusammen, damit aus einem Primärfehler nicht Dutzende unabhängige Tickets entstehen. KI kann Muster in zeitlichen Verläufen erkennen, benötigt jedoch belastbare Sensor- und Zustandsdaten.

Das Fraunhofer ISE verbindet bei COMETH regelbasierte und KI-gestützte Fehlerdiagnose für gebäudetechnische Anlagen. Als mögliche Ursachen für ineffizienten Betrieb nennt das Institut unter anderem falsche Betriebszeiten, fehlerhafte Sensoren, defekte Aktoren und ungeeignete Regelungen. Das ist eine wichtige Abgrenzung: Ein auffälliger Messwert kann ebenso auf einen Sensorfehler wie auf einen Anlagenfehler hindeuten.

Bevor ein Modell Wartung empfiehlt, werden Sensor-ID, Einheit, Abtastrate, Kalibrierung, Ausfälle und Änderungen an der Regelung geprüft. Das Fachpersonal entscheidet, ob eine Kontrolle, Wartung oder Anpassung des Betriebs erforderlich ist.

Zustandsbasierte Wartung benötigt genügend vergleichbare Betriebsdaten

Vorausschauende Wartung verspricht Hinweise vor einem Ausfall. In einem heterogenen Gebäudebestand fehlen dafür oft vergleichbare Daten: Anlagen unterscheiden sich nach Baujahr, Hersteller, Belastung und Wartung. Störungen werden als Freitext dokumentiert und ausgetauschte Bauteile nicht eindeutig erfasst.

Ein erster Schritt ist deshalb häufig Condition Monitoring mit verständlichen Regeln und Trendgrenzen. Machine Learning lohnt sich, wenn genügend historische Verläufe und bestätigte Fehlerereignisse vorhanden sind. Seltene, aber schwerwiegende Ausfälle bieten möglicherweise zu wenig Trainingsfälle.

Ein Modell gibt einen Risikohinweis mit Beobachtungszeitraum und relevanten Signalen aus. Es löst keine kostenpflichtige Wartung ohne Freigabe aus. Gemessen werden bestätigte Hinweise, Fehlalarme, Vorwarnzeit und tatsächlich vermiedene Betriebsunterbrechungen. Eine allgemeine „KI-Gesundheitszahl“ ohne erklärbaren Bezug hilft dem Techniker wenig.

Leistungsnachweise müssen Tätigkeit und Freigabe getrennt dokumentieren

Nach dem Einsatz steht häufig „Störung behoben“ im Freitext. Für interne Kontrolle, Auftraggeber und Abrechnung kann das zu wenig sein. Ein prüfbarer Nachweis verbindet den Vorgang mit Ankunft, Arbeitsbeginn, Befund, Tätigkeit, Material, Abschlussstatus und gegebenenfalls Foto oder Unterschrift.

Nicht jedes Feld beweist dasselbe. Ein GPS-Punkt zeigt einen Gerätestandort, aber keine ausgeführte Arbeit. Ein Foto dokumentiert einen sichtbaren Zustand, aber nicht automatisch Funktionsfähigkeit. Eine Unterschrift bestätigt nur den definierten Inhalt der Bestätigung. Diese Bedeutungen werden im Prozess festgelegt.

KI kann einen diktierten Technikerbericht in Felder aufteilen und fehlende Angaben markieren. Vor Abschluss sieht der Techniker den erzeugten Text und bestätigt ihn. Material und Zeit stammen aus kontrollierten Eingaben oder verbundenen Systemen, nicht aus der Textzusammenfassung.

Bei wiederkehrenden Leistungen wie Reinigung oder Prüfung kann eine Checkliste geeigneter sein als generative KI. Abweichungen werden als eigener Befund mit Foto und Maßnahme dokumentiert. Der Auftraggeber erhält nur die für Vertrag und Nachweis freigegebenen Informationen.

Dokumenten-KI bereitet Fremdleistungsbelege für die Prüfung vor

Wartungsfirmen und Nachunternehmer liefern Berichte als PDF, Scan oder E-Mail. Dokumenten-KI kann Objekt, Datum, Anlage, Tätigkeit, Material und Berichtnummer extrahieren. Anschließend gleicht ein Regelwerk die Angaben mit Bestellung, Einsatz und Vertrag ab.

Ein ähnlicher Objektname reicht nicht für eine automatische Buchung. Eindeutige Bestell- oder Vorgangsnummer, Leistungstag und Lieferant erhöhen die Zuverlässigkeit. Unsichere Zuordnungen werden mit dem Original nebeneinander angezeigt.

Das Originaldokument bleibt erhalten. Extrahierte Felder, Korrekturen und Freigaben werden separat protokolliert. Der Beitrag zur Dokumentenverarbeitung mit KI erklärt diese Trennung für weitere Geschäftsunterlagen.

Kundenkommunikation darf nur bestätigte Statusdaten verwenden

Ein Auftraggeber möchte wissen, ob die Meldung eingegangen ist, wer sich kümmert und wann ein Ergebnis vorliegt. Automatische Kommunikation kann diese Fragen beantworten, wenn der Status aus dem führenden Einsatzsystem stammt.

Geeignete Ereignisse sind Meldung erfasst, Rückfrage offen, Einsatz disponiert, Techniker unterwegs, Zugang nicht möglich, Arbeit unterbrochen, technische Prüfung abgeschlossen und Nachweis verfügbar. „Behoben“ wird erst gesendet, wenn der Techniker oder eine definierte Fachrolle den Status bestätigt hat.

Eine KI formuliert den freigegebenen Status verständlich. Sie erfindet keine Ankunftszeit und nennt keine interne Diagnose als gesicherte Ursache. Bei hoher Auswirkung oder wiederholter Störung übernimmt ein verantwortlicher Ansprechpartner die Kommunikation.

CAFM, ERP, GLT, DMS und Telefonie behalten klare Zuständigkeiten

Die Architektur verhindert eine zweite, von der KI erzeugte Gebäudewelt:

Die Integrationsschicht ordnet Kennungen zu, überträgt Statusereignisse und behandelt Fehler. Wiederholte Nachrichten erzeugen keinen doppelten Einsatz. Eine Warteschlange zeigt unbekanntes Objekt, fehlenden Vertrag, ungültige Anlagen-ID oder abgelehnte Buchung.

SW Business Solutions entwickelt dafür API-Schnittstellen und individuelle Konnektoren. Wenn ältere CAFM- oder GLT-Systeme keine moderne API anbieten, können geprüfte Datei-, Datenbank- oder Middleware-Wege sinnvoll sein. Die Softwarearchitektur von SW Business Solutions legt fest, welches System welche Wahrheit führt und wie der Betrieb bei Ausfällen weiterarbeitet.

Gebäudeautomation darf nicht ungeschützt an einen KI-Dienst gekoppelt werden

Eine Verbindung zur Gebäudeautomation kann über Komfort und Energie hinaus betriebsrelevante Anlagen beeinflussen. Schreibzugriffe benötigen deshalb eine wesentlich strengere Prüfung als eine lesende Datenanalyse.

Das BSI behandelt technisches Gebäudemanagement und Gebäudeautomation in eigenen IT-Grundschutz-Bausteinen. Die Umsetzungshinweise betonen unter anderem Rollen und Berechtigungen, dokumentierte Zuständigkeiten und die Absicherung der beteiligten Systeme. Für ein KI-Projekt bedeutet das: Datenzugriff, Netzsegment, Identität, Protokollierung und erlaubte Funktionen werden vorab festgelegt.

Ein Analysemodell erhält möglichst nur die erforderlichen Messdaten. Es steuert keine Anlage frei über Textbefehle. Soll ein Optimierungsvorschlag in Sollwerte einfließen, geschieht das über begrenzte Wertebereiche, technische Schutzfunktionen und verantwortliche Freigaben. Gebäudesicherheit bleibt unabhängig vom KI-Dienst gewährleistet.

Beschäftigtendaten werden nicht zum Nebenprodukt der Optimierung

Mobile Einsätze erzeugen Zeit-, Standort- und Nutzungsdaten. Diese können Rückschlüsse auf Beschäftigte zulassen. Zweck, Erforderlichkeit, Zugriff und Aufbewahrung werden vor dem Pilot festgelegt; Datenschutz und betriebliche Mitbestimmung sind abhängig vom Einsatz einzubeziehen.

Für die Prozessanalyse genügt häufig die Dauer eines Statusabschnitts oder der Anteil unvollständiger Nachweise. Eine öffentliche Rangliste einzelner Techniker ist dafür nicht erforderlich. Freitext wird auf persönliche oder sachfremde Angaben geprüft, bevor er für Modellentwicklung genutzt wird.

Mitarbeitende müssen Korrekturen vornehmen können, wenn KI eine Meldung falsch klassifiziert oder einen Bericht missverständlich zusammenfasst. Diese Korrektur verbessert den konkreten Vorgang. Sie wird erst nach Prüfung als Trainingsbeispiel verwendet.

Wirtschaftlichkeit wird an einem klaren Engpass geprüft

Für die Eingangsbearbeitung zählen Zeit bis zum bearbeitbaren Ticket, fehlende Objektzuordnungen, Rückfragen und Fehlpriorisierungen. In der Disposition sind Umplanungen, nicht ausführbare Einsätze und Anfahrten ohne Zugang relevant. Beim Nachweis zählen unvollständige Berichte, Zeit bis zur Freigabe und Rechnungskorrekturen.

Den Nutzen stehen Kosten für Stammdaten, Schnittstellen, Telefonie oder Dokumentendienst, mobile Geräte, Modellbetrieb, Sicherheit, Schulung und Betreuung gegenüber. Ein besseres Meldeformular kann wirtschaftlicher sein als ein Sprachmodell. Eine fehlende Anlagenkennung sollte durch Kennzeichnung gelöst werden, nicht durch Bilderkennung kaschiert werden.

Ein Business Case verwendet die heutige Baseline und reale Fehlerfolgen. Anbieterwerte oder Forschungsergebnisse aus anderen Gebäuden ersetzen diese Messung nicht. Der Pilot wird beendet oder neu zugeschnitten, wenn Datenaufbereitung und Kontrollen mehr Aufwand verursachen als der bearbeitete Engpass.

Ein Pilot verbindet Störungsmeldung und Objekt im Schattenbetrieb

Ein geeigneter Einstieg ist die Klassifikation wiederkehrender Störungsmeldungen für eine begrenzte Objektgruppe. Sicherheitskritische Kategorien bleiben anfangs außerhalb automatischer Weiterleitung.

Der Pilot folgt einem kontrollierten Ablauf:

1. Objektgruppe, Kanäle und erlaubte Kategorien festlegen.
2. Objekt- und Anlagenkennungen bereinigen.
3. Historische Meldungen mit bestätigtem Ergebnis prüfen.
4. Regeln für kritische Begriffe und Eskalationen definieren.
5. KI-Vorschläge neben der heutigen Bearbeitung anzeigen.
6. Objektzuordnung, Kategorie und fehlende Angaben einzeln bewerten.
7. Fehlalarme und übersehene kritische Fälle auswerten.
8. Erst nach bestandenen Kriterien ausgewählte Standardfälle weiterleiten.

Stop-Kriterien sind uneindeutige Objektbezeichnungen, fehlende Notfallmatrix, unbekannte Vertragszuständigkeit oder nicht ausreichend erkennbare kritische Meldungen. Dann werden Stammdaten, Formular oder Übergabeprozess verbessert, bevor mehr Automatisierung folgt.

SW Business Solutions verbindet Gebäudeservice und vorhandene Systeme

SW Business Solutions analysiert einen realen Störungs- oder Einsatzprozess gemeinsam mit Leitstelle, Objektleitung, Technik, Abrechnung und IT. Das Team klärt, wo Informationen entstehen, welches System führend bleibt und ob eine Regel, klassische Automatisierung, Optimierung oder KI benötigt wird.

Die individuelle Umsetzung kann umfassen:

• Omnichannel-Eingang für Telefon, E-Mail und Portal
• Objekt-, Anlagen- und Vertragszuordnung
• Notfall-, SLA- und Eskalationslogik
• CAFM-, ERP-, GLT-, CRM- und DMS-Integration
• mobile Techniker- und Prüfoberflächen
• Dokumenten- und Leistungsnachweisverarbeitung
• Wissenssuche mit freigegebenen Quellen
• Sensoranalyse und begrenzte Prognosemodelle
• Dashboards, Fehlerwarteschlangen und Modellmonitoring

Die KI-Integration von SW Business Solutions setzt Modelle nur in den Schritten ein, in denen variable Sprache, Dokumente oder Messmuster einen belegbaren Vorteil bringen. Für spezielle Objekt- und Serviceprozesse entwickelt SW Business Solutions die fehlenden Workflows und Bedienoberflächen individuell.

Als Ausgangspunkt genügt eine typische Störungsmeldung samt beteiligten Systemen und heutigem Leistungsnachweis. SW Business Solutions prüft daran, wie sich Störung, Einsatz und Nachweis kontrolliert verbinden lassen. Das Ziel ist ein Vorgang mit eindeutigem Objektkontext, nachvollziehbarer Priorität und prüfbarem Abschluss.