CAFM: Customizing/Erweiterungsentwicklung

• Plug-ins / Add-Ins: Dies sind kleine Software-Komponenten, die in das Hauptsystem eingebettet werden, um dessen Verhalten zu erweitern. Viele CAFM-Systeme bieten offizielle Plugin-Schnittstellen oder SDKs an. Ein Plugin könnte z.B. ein selbst entwickeltes Modul sein, das bei bestimmten Events eigene Aktionen ausführt. Beispiel: In Planon (einem IWMS) dürfen Kunden Java-basierte Business-Regeln implementieren und als Erweiterung registrieren. Diese greifen z.B. beim Speichern eines Datensatzes und können dann benutzerdefinierte Validierungen oder Berechnungen durchführen. Ein anderes Beispiel: Ein Plugin für eine CAFM-Helpdesk-Software könnte die Ticketmaske um eine Anbindung an ein Wissensdatenbank-System erweitern (zusätzlicher Button „Lösungsvorschläge suchen“). Technisch gesehen wird hier Code geschrieben, der in den Prozess des Hauptsystems einklinkt. Der Hersteller stellt hierfür oft definierte Hooks oder Extension Points bereit. Vorteil: Plugins laufen innerhalb der CAFM-Plattform, können auf deren API zugreifen und verhalten sich wie ein Teil der Standardsoftware – idealerweise ebenfalls releasekompatibel, solange sie die offiziellen Schnittstellen nutzen.

• Individuelle Module: Darunter versteht man größere Erweiterungen, die als eigenständige Module dem CAFM hinzugefügt werden. Viele CAFM-Lösungen sind modular aufgebaut und erlauben kundenspezifische Module. Zum Beispiel könnte man ein Modul „Inventarmanagement“ ergänzen, falls das System so etwas nicht hat, und es ins Hauptmenü integrieren. Dazu gehört meist das Anlegen eigener Tabellen, Masken und Funktionen. Tools wie der waveware® CONSTRUCTOR von Loy & Hutz erlauben die schnelle Entwicklung kompletter Datenbankanwendungen als Module innerhalb der Plattform. Diese Module nutzen dann die gemeinsame Infrastruktur (Benutzerverwaltung, Berechtigungen, UI-Framework) mit, fügen aber neue Fachfunktionen hinzu. Solche Entwicklungen sind aufwändiger als kleine Plugins, bieten aber maximale Flexibilität. Wichtig ist, sie so umzusetzen, dass sie updatesicher integriert sind – oft durch Nutzung von vom Hersteller vorgesehenen Erweiterungsplätzen und Namensräumen.

• Eigene Funktionen und Skripte: Eine weniger sichtbare, aber sehr verbreitete Art der Erweiterung sind Scripts oder Funktionsbibliotheken, die bestimmte Aufgaben lösen. Beispielsweise könnte ein Team einen komplexen Algorithmus zur Reinigungszeitberechnung entwickeln (auf Basis von Flächentyp, Verschmutzungsgrad etc.), der im Standard so nicht vorhanden ist. Diese Logik kann als eigene Funktion hinterlegt werden, die z.B. beim Erstellen eines Reinigungsauftrags aufgerufen wird. Oft bietet die CAFM-Software Möglichkeiten, solche Funktionen als Server-seitiges Script (z.B. JavaScript, Python oder proprietäre Scriptsprachen) einzubinden. Auch Berichts-Makros oder Formular-Skripte (ähnlich VBA in Excel) gehören dazu. Diese Art der Erweiterung wird meist genutzt, um Berechnungen, Datenvalidierungen oder Massenänderungen zu automatisieren, wenn die Standard-Regeln nicht ausreichen.

• Microservices und externe Anwendungen: In jüngerer Zeit verfolgen einige Anwender den „Clean Core“-Gedanken, d.h. das CAFM-Kernsystem möglichst unangetastet zu lassen und stattdessen externe Microservices anzubinden. Ein Microservice ist eine kleine, unabhängige Anwendung, die über Schnittstellen (etwa REST-API) mit dem CAFM kommuniziert. Beispiel: Ein separater Energie-Monitoring-Service ruft regelmäßig Zählerdaten von IoT-Sensoren ab und überträgt die aggregierten Ergebnisse per API ins CAFM, wo sie in Berichten erscheinen. Oder ein Chatbot-Service, der Benutzeranfragen entgegennimmt und Tickets im CAFM anlegt. Solche Services laufen eigenständig (z.B. in der Cloud) und nutzen lediglich die Schnittstellen des CAFM – das Kernsystem bleibt unverändert. Der Vorteil: Updatesicherheit – da der Core unberührt bleibt – sowie Skalierbarkeit, da die Microservices getrennt betrieben werden können. Allerdings erfordert dies mehr Integrationsaufwand (API-Management, Authentifizierung, etc.). Moderne IWMS-Cloudlösungen (etwa von Nakisa) sind häufig selbst als Microservice-Architektur umgesetzt und erlauben das Anbauen eigenständiger Services mit nativem API-Zugriff.

• Integration in Eigenentwicklungen: Manchmal wird die CAFM-Funktionalität auch durch Kopplung mit eigenentwickelten Tools erweitert. Z.B. könnte ein Facility Management ein eigenes Web-Portal für Hausmeistermeldungen bauen (weil es genau deren Anforderungen entspricht) und dieses Portal per Webservice ans CAFM anbinden, sodass die Meldungen automatisch als Tickets ins System fließen. Hier wird das CAFM eher als Backend verwendet, während die eigentliche neue „Funktion“ (Portal) komplett separat entwickelt ist.

Bei jeder Form von Erweiterungsentwicklung ist entscheidend, dass die Schnittstellen und Erweiterungsmöglichkeiten des Herstellers respektiert werden. So bleibt die Lösung wartbar. Gute CAFM-Systeme liefern klare Frameworks für Erweiterungen: etwa definierte API-Bibliotheken, Hook-Punkte für Events und ausführliche Dokumentation, wie man Erweiterungen registriert und deployt.Ein typischer Erweiterungsprozess kann so aussehen: Der Entwickler erstellt die Erweiterung in einer IDE (z.B. Java-Klasse), bindet die vom CAFM-Anbieter bereitgestellte API-Bibliothek ein, kompiliert den Code, registriert dann die neue Erweiterung im System (oft über eine Admin-Konsole) und verknüpft sie mit dem entsprechenden Geschäftsobjekt oder Event. Nach dem Test wird die Erweiterung produktiv geschaltet. Wichtig ist auch hier: möglichst lose Kopplung zum Kernsystem, d.h. keine direkten Datenbankmanipulationen an Standardtabellen etc., sondern alles über die offiziellen Schnittstellen.

• Validierungsregeln: Um Eingabefehler oder unvollständige Daten zu vermeiden, können Validierungen definiert werden. Beispiel: Wenn ein Nutzer einen neuen Wartungsauftrag erfasst, soll geprüft werden, ob das Feld „Anlagennummer“ gefüllt ist und ob die Nummer tatsächlich existiert. Solche Prüfungen lassen sich per Regel konfigurieren; bei Verstoß kann das System eine Fehlermeldung im Dialog anzeigen. In Planon manifestieren sich z.B. Business Rules oft als Dialoge mit Fehler- oder Warnhinweisen[25]. Diese Regeln werden meist beim Speichern oder Statuswechsel ausgelöst und greifen noch vor der endgültigen Datenbank-Speicherung ein. Technisch werden sie oft als If-Then-Regeln oder als Skript (z.B. Groovy, JavaScript) hinterlegt. Wichtig: Solche Validierungen laufen im Rahmen des Systems, berücksichtigen aber i.d.R. keine Benutzerberechtigungen (d.h. sie greifen global, unabhängig davon, wer speichert).

• Automatisierungen: Darunter fallen hintergrund oder live ausgeführte Aktionen, die dem Benutzer Arbeit abnehmen. Beispiel: Automatisches Befüllen eines Feldes basierend auf einer Regel – etwa wenn der Raum in einem Ticket angegeben wird, setzt das System automatisch das zugehörige Gebäude-Feld, um Konsistenz zu wahren. Ein anderes Beispiel sind Trigger, die auf Datenänderungen reagieren: Wird eine Störung als „erledigt“ markiert, soll automatisch die zugehörige Aufgabe geschlossen und der Melder per E-Mail informiert werden. Solche Automatismen sind häufig per Workflow-Manager einstellbar. Einige Systeme bieten auch Betriebsdienste an, die periodisch im Hintergrund laufen (ähnlich Cron-Jobs). Beim CAFM NOVA gibt es z.B. den Workload-Dispatcher, der Hintergrundprozesse wie automatischen Mailversand oder zyklische Datenexports durchführt. Der Admin kann hier Regeln konfigurieren: „Führe Aktion X täglich um 0 Uhr aus“ oder „sende Mail, wenn Ereignis Y eintritt“.

• Eskalationen und Benachrichtigungen: Ein klassisches Feld sind Eskalationsregeln. Diese sorgen dafür, dass Fristen überwacht und Verantwortliche rechtzeitig erinnert werden. Beispielsweise kann man definieren, dass eine Störungsmeldung nach 48 Stunden ohne Bearbeitung eskaliert wird: Das System verschickt dann automatisch eine E-Mail an den Teamleiter oder erzeugt einen Alarm in der Oberfläche. Viele CAFM-Systeme haben integrierte Eskalationsmodule, wo man Schwellwerte konfigurieren kann. So berichtet der Hersteller wave Facilities etwa, dass über das ESCALATION-Feature Grenzwerte mit Alarmen versehen werden können – bei Überschreitung werden definierte Personen sofort per E-Mail benachrichtigt. Diese Logiken laufen ebenfalls automatisiert im Hintergrund.

• Benutzerdefinierte Aktionen (GUI-Aktionen): In manchen Fällen möchte man dem Nutzer Buttons oder Menüeinträge bieten, um bestimmte Skripte manuell auszuführen. Beispielsweise ein Button „Abrechnungslauf starten“, der auf Klick ein hinterlegtes Script startet, welches alle offenen Kosten sammelt und abrechnet. Solche GUI-Aktionen können per Customizing oft hinzugefügt werden, indem sie mit einem Skript oder einer Funktionsaufruf verknüpft werden. Der Nutzer initiiert also bewusst den Vorgang, aber die Logik dahinter ist kundenspezifisch.

Die Umsetzung dieser Regeln und Skripte variiert je nach System. Einige bieten einfache Regel-Dialoge, wo man Bedingungen und Aktionen auswählt (für Standardfälle wie Pflichtfeld oder Werteprüfung). Andere haben Skript-Editoren, in denen man Code eingibt. Bei IBM Maximo z.B. gibt es Automation Scripts, die in Jython, JavaScript o.ä. geschrieben werden können; Launch Points definieren, wann sie triggern (Objekt Save, Status Change etc.). Diese Skripte sind halb-offiziell: Die Plattform stellt das Framework bereit, und beim Upgrade werden die Skripte zwar mitübernommen, aber ihre Inhalte müssen vom Kunden betreut werden (falls Breaking Changes auftreten). Das ist ein generelles Prinzip: Das System unterstützt das Rahmenwerk für eigene Regeln, garantiert aber nicht die fehlerfreie Funktion des vom Kunden geschriebenen Codes. Dennoch sind Skript-Erweiterungen oft upgrade-freundlicher als harte Code-Modifikationen, da sie an definierten Schnittstellen hängen und vom Hersteller beim Patchen zumindest berücksichtigt werden (im Sinne von: sie werden nicht überschrieben, und Änderungen werden angekündigt.

Von den Möglichkeiten her kann man mit Skript- und Regellogik enorm viel erreichen: Von der Datenvalidierung, Berechnung abhängiger Werte, über das Generieren von Folgeprozessen (z.B. automatisch einen Wartungsauftrag anlegen, wenn ein Sensor einen Alarm sendet) bis hin zur Integration mit externen Services (z.B. per Script einen Webservice aufrufen). Damit fungieren diese Mechanismen als Werkzeugkasten für Individualanforderungen – oft ohne vollwertiges externes Development-Projekt. Wichtig ist, diese Skripte gut zu dokumentieren und zu testen (siehe unten), da sie Teil der individuellen Logik werden.

• Datenintegration: Bestehende Fremdsysteme (z.B. ERP, HR-System, Gebäudeautomation) können direkt mit dem CAFM kommunizieren. Ein Beispiel ist die Anbindung von SAP – einige CAFM-Systeme liefern spezielle Connectoren für SAP über BAPI/RFC oder IDoc-Schnittstellen. Darüber können z.B. Raum- und Kostenstelleninformationen mit SAP FI/CO abgeglichen oder Wartungsaufträge zwischen Instandhaltungsmodul und SAP PM ausgetauscht werden.

• Aufbau eines IT-Ökosystems: Über Schnittstellen lässt sich rund um das CAFM ein individuelles Ökosystem bauen. So bietet etwa NOVA-FM mit dem NOVA-Connector eine neutrale Schnittstellenschicht an, zu der es verschiedene Plug-ins gibt: SQL, Excel/CSV, XML, IFC (für BIM), CAD, Web-Services etc. Damit können praktisch beliebige Datenquellen angebunden werden – von CAD-Grundrissdaten bis zur Excel-Liste. Diese Connector-Plugins übernehmen die Transformation und Einspielung der Daten. Das Resultat: Das CAFM wird zum zentralen Hub, der mit allen umliegenden Systemen vernetzt ist, ohne dass manuelle Datenpflege in mehreren Systemen nötig wäre.

• Webservices & Mobile Apps: Die meisten CAFM-Anbieter haben Web-APIs entwickelt, um mobile Apps oder Webportale anzudocken. Beispiel: NOVA-FM besitzt eine leistungsstarke REST-WebAPI, die es den nativen Apps erlaubt, permanent Daten auszutauschen. Das gleiche API steht aber auch Kunden offen, um eigene Applikationen anzubinden. Ein Unternehmen könnte damit z.B. ein Self-Service-Mietermeldeportal implementieren: Die Web-App nutzt die API, um neue Meldungen ins CAFM zu schreiben und Statusupdates abzurufen. Die API sorgt für sichere Authentifizierung und definiert klar, welche Objekte und Felder zugänglich sind.

• Microservices-Anbindung: Wie im vorherigen Abschnitt erwähnt, können über APIs auch eigenständige Microservices mit dem CAFM interagieren. Ein IoT-Datenservice etwa könnte kontinuierlich Sensordaten (Temperaturen, Zählerstände, Bewegungssensoren etc.) aufnehmen und via API ans CAFM schicken, wo sie ausgewertet und dargestellt werden. Umgekehrt kann das CAFM über APIs Befehle an externe Systeme senden – z.B. einen Ticket-Export an ein BI-System, oder das Auslösen einer Push-Nachricht in einer Kommunikationsplattform, wenn ein bestimmtes Ereignis eintritt.

• Import/Export und Migrationsschnittstellen: Schon im Zuge der Einführung kommen Schnittstellen ins Spiel, etwa um Altdaten zu migrieren. Hierfür gibt es oft Batch-Imports (CSV/Excel-Upload) oder ETL-Tools. Diese werden in Betrieb weiterhin genutzt, z.B. um regelmäßig Stammdaten aus einer anderen Quelle zu aktualisieren (Personaldaten aus HR-System etc.). Die Updatefähigkeit bleibt erhalten, wenn man dafür offizielle Imports verwendet, statt direkt in die DB zu schreiben.

• Beispiel einer API-Nutzung: Ein Raumbuchungs-System (z.B. MS Exchange/Outlook oder eine spezialisierte App) soll mit dem CAFM verknüpft werden. Über die API des CAFM kann die Buchungs-App z.B. prüfen, welche Räume im CAFM verfügbar sind und eine Buchung als Reservierung ins CAFM eintragen. Gleichzeitig kann das CAFM über Webhooks mitteilen, wenn sich an einem Raumstatus etwas ändert (z.B. Raum gesperrt wegen Wartung), damit die Buchungs-App das berücksichtigt. All dies passiert über definierte REST-Endpunkte. Für den Endnutzer wirkt es nahtlos: Ob er über Outlook oder das CAFM bucht, ist egal – im Hintergrund synchronisieren die Systeme ihre Daten via API.

• Sicherheit und Steuerung: Wichtig ist beim Einsatz von APIs die Governance. Nicht jeder soll unbegrenzt Daten abrufen oder manipulieren können. Daher arbeiten APIs mit Authentifizierungsmechanismen (API-Keys, OAuth, etc.) und Berechtigungen. Zudem sollte die Nutzung dokumentiert sein, damit Updates des CAFM (die evtl. API-Änderungen mit sich bringen) mit den Entwicklern der angebundenen Dienste abgestimmt werden können.

• Es ermöglichen offene Schnittstellen eine hohe Erweiterbarkeit, indem sie dem CAFM Tore zur Außenwelt öffnen. Die Kunst liegt darin, diese Integration sauber umzusetzen – im Sinne von entkoppelt, sicher und den Update-Vorgaben entsprechend – damit das Gesamtsystem stabil und updatefähig bleibt.

• E-Mail-Services: E-Mail bleibt ein zentraler Kanal im Facility Management – sei es für Störungsmeldungen, Benachrichtigungen oder Auftragskommunikation. Ein CAFM-System sollte daher an Mailserver angebunden sein. Meist geschieht dies durch Konfiguration eines SMTP-Servers für ausgehende Mails (für automatische Benachrichtigungen, z.B. „Arbeitsauftrag wurde erledigt“ an den Melder) und ggf. eines IMAP/POP3 für eingehende Mails (etwa um per E-Mail gemeldete Störungen automatisch als Tickets zu erfassen). Aus Customizing-Sicht richtet man z.B. Mail-Templates ein und bestimmt, wann welche E-Mail auszulösen ist. Zum Beispiel kann der Workload-Dispatcher bei NOVA so konfiguriert werden, dass er bei bestimmten Ereignissen E-Mails verschickt. Dies geschieht releasesicher, da es eine Standardfunktion ist.

• IoT-Plattformen: Die Integration von IoT (Internet of Things) gilt als großer Trend im FM. Sensoren liefern Echtzeitdaten zu Gebäuden – von Temperatur, Luftqualität über Belegung bis hin zu Maschinendaten. Die Verbindung zum CAFM ermöglicht zustandsbasiertes Handeln: Das System kann z.B. automatisch einen Wartungsauftrag erzeugen, wenn ein Schwellwert überschritten wird, oder eine Reinigung veranlassen, wenn ein Raum genutzt wurde. Damit das gelingt, müssen IoT-Plattformen (die die Sensordaten sammeln) mit dem CAFM sprechen. Möglich ist eine direkte Kopplung, wenn der Sensor direkt ans CAFM meldet (sofern das CAFM Protokolle wie MQTT, BACnet o.ä. versteht). Häufiger jedoch läuft es über Middleware/IoT-Plattformen, die per API mit dem CAFM interagieren. Man ordnet den eingehenden Sensordaten zunächst im CAFM ein Objekt zu (z.B. Sensor-ID X gehört zu Raum 101). Dann definiert man Regeln im CAFM, was bei bestimmten Datenereignissen passiert (z.B. „Wenn Status ‘Raum unbesetzt’ detektiert -> sende Reinigungsauftrag”, oder „Wenn Messwert > Schwellwert -> erstelle Instandhaltungsticket”)[31]. GEFMA hat die Bedeutung dieser Kopplung erkannt und 2023 die Richtlinie 444 um IoT-Datenmanagement erweitert – sprich: ein modernes CAFM sollte IoT-fähig sein. Für die Umsetzung bieten einige Hersteller out-of-the-box IoT-Module an, andere erlauben es über generische Schnittstellen. Ein erfolgreiches Beispiel: Sensoren melden über eine IoT-Plattform akenza an das CAFM FAMOS die Verbrauchsdaten; das CAFM analysiert und alarmiert bei Abweichungen, sodass FM-Verantwortliche proaktiv reagieren können. Insgesamt steigert diese Verzahnung die Automation und Effizienz im Gebäude erheblich.

• BIM und CAD: Facility Management greift zunehmend auf Bauwerksdatenmodelle (BIM) und CAD-Zeichnungen zurück. Daher ist eine typische Integration, CAD-Pläne oder BIM-Daten in das CAFM zu übernehmen. Viele CAFM-Systeme haben CAD-Schnittstellen oder BIM-Imports (z.B. IFC4-Unterstützung). So kann man z.B. aus einem BIM-Modell Räume und Flächen ins CAFM importieren und dort weiterverwenden. Umgekehrt können Änderungen im CAFM zurück ins BIM gespiegelt werden (etwa neue Raumnummern ins Modell schreiben). Solche Funktionen sind oft als Plugins realisiert – beim NOVA-Connector z.B. gibt es ein IFC4-Plugin und CAD-Plugins. Praktisch bedeutet das: Der CAFM-Anwender kann auf Knopfdruck eine aktuelle CAD-Zeichnung einlesen, die Software mappt die enthaltenen Räume/Flächen auf die Datenbankobjekte, und er hat dann im CAFM aktuelle Flächendaten und grafische Übersichten. Diese Integration macht das Datenmanagement konsistenter und erspart Doppelerfassungen.

• ERP/Finance-Systeme: Viele FM-Informationen hängen mit Finanzen zusammen (Mietkosten, Betriebskostenabrechnung, Abschreibungen von Assets etc.). Darum werden CAFM-Systeme häufig mit ERP-Systemen integriert. Beispiel: Ein CAFM erzeugt die Aufträge für externe Dienstleister, aber die Abrechnung soll über SAP erfolgen. Hier kann eine Schnittstelle die Auftragsdaten ans SAP übergeben und dort die Rechnung erstellen lassen. Im Gegenzug erhält das CAFM den Rechnungsstatus zurück. Solche Integrationen sind komplexer und berühren oft geschäftskritische Prozesse, daher sollten sie robust (Transaktionssicherheit, Fehlerhandling) gebaut werden. Im Idealfall stellt der CAFM-Anbieter bereits SAP-Konnektoren bereit (wie erwähnt), andernfalls erfolgt die Kopplung über definierte Datenaustauschformate (z.B. regelmäßiger Export von Buchungsdaten aus dem CAFM und Import in ERP).

• Single Sign-On und Identity Services: Nicht zuletzt zählt auch die Einbindung externer Authentifizierungsdienste (AD/LDAP, SAML, Azure AD etc.) zum Erweiterungsumfang. Damit Nutzer sich nicht x-mal anmelden müssen, werden CAFM-Logins oft mit dem zentralen Verzeichnis synchronisiert. Das gilt als Standard-Integration bei Enterprise-Software.

• Release-sichere Erweiterungen sind alle Anpassungen, die den Software-Standard nicht verletzen. Sie nutzen offizielle Erweiterungspunkte, APIs oder Konfigurationen, sodass beim Update auf eine neue Version keine Konflikte auftreten. Wie bereits erwähnt, werden solche Erweiterungen oft in separaten Namespaces oder Projekten vorgenommen, welche vom Hersteller für Kunden vorgesehen sind. Ein sehr anschauliches Zitat stammt aus der SAP-Welt: „Erweiterungen sind – im Gegensatz zu Modifikationen – grundsätzlich releasefähig, da sie nicht im SAP-Original, sondern in einem für den Kunden reservierten Namensraum vorgenommen werden“. Übertragen auf CAFM heißt das: Wenn wir z.B. eine neue Tabelle hinzufügen oder ein Plugin schreiben, tun wir dies, ohne den Standardcode zu ändern; im Ergebnis kann der Hersteller beim Update seine Standardobjekte austauschen, ohne unsere Erweiterung zu überschreiben. Idealerweise erkennt das System nach dem Update die Erweiterung weiterhin und integriert sie wieder (viele Plattformen laden z.B. kundeneigene Plugins beim Start automatisch, sofern sie gegen die neue Version kompatibel sind). Auch Customizing-Einstellungen (wie neue Felder, Maskenkonfigurationen) bleiben erhalten, sofern sie im Datenmodell und Metadatenbank sauber hinterlegt sind – daher betonen Anbieter wie HSD für NOVA-FM, dass trotz umfangreicher Customizing-Möglichkeiten das System „jederzeit updatefähig“ bleibt[.

• Systemnahe Modifikationen hingegen bedeuten, dass man direkt am Standardobjekt Änderungen vornimmt. Das kann z.B. sein: Ändern eines SQL-Statements im Auslieferungs-Bericht, Manipulieren von Kern-DB-Tabellen (Kolumnen löschen/ändern), Überschreiben von Original-Dateien oder Code-Modulen. Solche Modifikationen sind nicht releasefest, denn beim nächsten Patch wird der Hersteller typischerweise seine Originaldateien überschreiben und die Änderung geht verloren (oder führt zu Konflikten). Ein Beispiel: Man fügt direkt in einer Standard-Formulardatei des Web-Clients eigene Felder hinzu, weil man keinen offiziellen Maskeneditor hat. Beim nächsten Update wird diese Datei ersetzt – die eigenen Felder wären weg, oder das Update schlägt fehl. Ebenso riskant: direkte Änderungen in der Datenbank-Struktur ohne Nutzung des vorgesehenen Customizing – etwa Trigger oder Prozeduren anlegen, die der Hersteller nicht kennt. Diese können nach einem Upgrade Fehler verursachen, weil sie mit geänderten Strukturen nicht mehr harmonieren.

• Best Practice ist klar: Modifikationen des Kernsystems strikt vermeiden. Stattdessen stets die vom Hersteller angebotenen Mechanismen nutzen („Keep the core clean“). In ERP-Projekten ist diese Erkenntnis seit Jahren etabliert, und es gilt genauso für CAFM. Sollte ein Wunsch absolut nicht ohne Core-Modifikation umsetzbar sein, muss man sorgfältig prüfen, ob der Nutzen das hohe Risiko rechtfertigt. Oft gibt es alternative Wege, die etwas aufwändiger erscheinen, aber upgrade-sicher sind (z.B. lieber ein externes Tool bauen, als im Standard rumzufuschen).

• Manche Anbieter erlauben sog. Core-Hacks gar nicht erst, indem sie Cloud-only arbeiten oder den Code nicht offenlegen. Bei On-Premise-Systemen liegt es aber teils in der Hand des Kunden – hier ist Governance gefragt, damit Entwickler nicht aus Bequemlichkeit doch am Core manipulieren.

• Releasefähigkeit prüfen: Bei jeder Erweiterung sollte man die Frage stellen: Was passiert damit, wenn wir auf die nächste Version updaten? Im Idealfall hat der Hersteller in Dokumentation angegeben, welche Arten von Anpassungen garantiert upgrade-kompatibel sind. Z.B. kann IBM bei Maximo sagen: neue Felder via Database Configuration oder neue Screens via Application Designer werden von Patches nicht angetastet und sind somit unkritisch. Hingegen eigenhändige Java-Code-Anpassungen sind problematisch. Dieses Wissen muss ins Architektur-Design der Erweiterung einfließen: Wenn z.B. eine geforderte Änderung nur durch Modifikation erreichbar wäre, sollte man das Konzept ändern (vielleicht doch ein Workaround via Erweiterungs-API etc.).

• In Summe bewahrt die konsequente Trennung von Standard und Kundenerweiterung das System vor „Technischem Schuld“-Ballast. Nur so kann man zukünftige Updates, Security-Patches oder Anbieter-Support problemlos in Anspruch nehmen. Im Zweifel lieber mit dem Hersteller abstimmen, wie ein bestimmtes Ziel erreicht werden kann, ohne die Releasefähigkeit aufzugeben.

• Planung vor Umsetzung: Bereits beim Design von Customizing oder Erweiterungen sollte die Update-Fähigkeit mitbedacht werden. Das heißt, Entwickler informieren sich über die Upgrade-Tools und -Prozesse des CAFM-Herstellers. Manche Systeme bieten z.B. einen Customization Manager, der bei Upgrades hilft (z.B. ein Tool, das alle kundenspezifischen Änderungen protokolliert hat und ins neue Release migriert). IBM Maximo z.B. hat ein Konzept des Customization Archives, das beim Upgrade ausgelesen wird, um kundenspezifische Konfigurationen zu übernehmen. Wenn man solche Tools hat, sollte man sie konsequent nutzen – und nur im Rahmen dessen customizen, was darüber auch migriert werden kann.

• Doku der Anpassungen für Updates: Es ist ratsam, eine Übersicht aller Erweiterungen zu führen (eine Art Customizing-/Entwicklungs-Liste). Darin steht: welches Objekt wurde hinzugefügt/geändert, wo greift eigener Code ein, etc. Diese Liste hilft beim Update zu prüfen, ob es potenzielle Konfliktstellen gibt. Z.B. wenn im neuen Release die Datenbank erweitert wurde – kollidiert das mit unseren eigenen Tabellen? Oder wenn der Hersteller einen Workflow grundlegend geändert hat – funktionieren unsere angekoppelten Plugins noch?

• Vorab-Tests mit neuer Version: Idealerweise richtet man eine Testumgebung mit der neuen Version ein (oder nutzt vom Hersteller bereitgestellte Preview-Versionen), um die eigenen Customizings dort gegenzutesten, bevor man produktiv updatet. So können Probleme früh erkannt und behoben werden, ohne den Live-Betrieb zu stören. In der Praxis bedeutet das: Sobald der Hersteller ein Upgrade ankündigt, sollte das FM/IT-Team die Release Notes durchgehen und auf Änderungen prüfen, die unsere Erweiterungen tangieren könnten. Dann spielt man das Update in der Staging-Umgebung ein und führt einen Regressionstest der wichtigsten angepassten Funktionen durch.

• Kompatibilität von Scripts und APIs: Bei eigenem Code muss man auch auf die verwendeten Sprachen und Bibliotheken achten. Beispiel: Wenn man Java-Skripte nutzt und das System auf eine neue Java-Version wechselt (wie von Java 1.7 auf 1.8), kann es sein, dass gewisse Scripts nicht mehr laufen. Der Hersteller mag zwar warnen und sogar mit Migrationshilfen kommen, letztlich muss man aber selbst die Skripte anpassen. Ebenso bei API-Updates: Wenn das CAFM eine API-Methode ändert oder entfernt, muss der aufrufende Custom-Microservice entsprechend angepasst werden. Daher sollten eigene Erweiterungen möglichst auf öffentlichen, stabilen APIs basieren, nicht auf internen Tricks. Und man sollte sich auf Mailinglisten/Supportinfos des Herstellers halten, um solche Änderungen rechtzeitig zu erfahren.

• Versionierung eigener Erweiterungen: Es ist sinnvoll, auch eigene Module/Plugins in Versionen zu führen. Beispielsweise wenn man ein selbst entwickeltes Helpdesk-Portal hat, vergibt man dafür eine Versionsnummer. Bei Änderungen oder Anpassungen an neue CAFM-Versionen erhöht man die Version und dokumentiert, welche CAFM-Version damit kompatibel ist. So behält man den Überblick, welche Variante des Plugins auf welchem Systemstand eingesetzt werden muss.

• Roll-back-Plan: Updatefähigkeit heißt auch, im Notfall zur alten Version zurückkehren zu können, falls etwas schiefgeht. Deshalb vor einem großen Systemupgrade immer ein Backup der alten Umgebung behalten, und sicherstellen, dass man im Zweifelsfall umschalten kann (z.B. neue Version parallel installieren, dann toggeln – falls Probleme, zurück auf alte). Da Customizing oft in der DB steckt, gehört ein DB-Backup dazu. Bei eigenem Code sollte die alte Jar/DLL etc. archiviert sein.

• Automatisierte Tests: Wer sehr fortgeschritten ist, kann für eigene Erweiterungen auch Tests automatisieren (Unit-Tests für eigenständige Module, oder Scripts zum Durchklicken der UI für Standard-Workflows). Das ist im CAFM-Kontext nicht immer leicht, aber für Kernfunktionen evtl. machbar. So würde ein Upgrade im Test direkt zeigen, ob beispielsweise alle kritischen Reports noch funktionieren.

Es ist die Haltung „Updates sind etwas Gutes, wir wollen sie ohne Schmerzen mitmachen können“ wichtig. Es verhindert, dass ein CAFM-System durch heavy Customizing auf einem alten Versionsstand „einfriert“ (was Sicherheits- und Supportprobleme nach sich zieht). Mit Weitsicht beim Entwickeln und sauberer Trennung von Standard vs. Custom erzielt man eine hohe Release-Fähigkeit – d.h. Updates lassen sich einspielen und die Anpassungen funktionieren weitgehend weiterhin oder erfordern nur geringe Nacharbeiten.

• Entwicklungstest (Developer Testing): Bereits der Entwickler sollte seine Änderung in einer isolierten Umgebung testen. Bei Skripten und Code bedeutet das Unit-Tests, falls möglich, oder zumindest manuelles Durchprobieren der neuen Logik in der Entwicklungsumgebung. Bei reinem Customizing (z.B. neues Pflichtfeld) kann der Entwickler in einer Test-Instanz prüfen, ob das Verhalten wie gewünscht ist.

• Funktions- und Integrationstest (Fachtest): Sobald die Änderung implementiert ist, folgt ein gezielter Test der betroffenen Funktionalität. Hier wird geprüft: Tut die Erweiterung was sie soll? Z.B. wenn ein Workflow angepasst wurde, alle Pfade durchspielen (Genehmigung erteilt, Genehmigung abgelehnt etc.). Ebenso wichtig: Integrationstest, d.h. wirkt sich die Änderung negativ auf andere Module aus? (Beispiel: neues Pflichtfeld – können dann noch alle bestehenden Datensätze gespeichert werden, oder blockiert das plötzlich z.B. Importe?). In dieser Phase arbeitet oft der CAFM-Berater oder Key User eng mit dem Entwickler zusammen, um sowohl technische als auch fachliche Korrektheit zu validieren.

• Testumgebung mit Echtdaten (Systemtest): Idealerweise hat man eine dedizierte Testumgebung, die der Produktion ähnelt.Dort wird die neue Version des Systems mit allen Anpassungen eingespielt. Man sollte mit realistischen Testdaten arbeiten – oft nimmt man einen Abzug der Produktivdatenbank (natürlich anonymisiert, falls nötig). In dieser Umgebung werden alle relevanten Funktionen und Prozesse des Systems durchgespielt.

• Standardfunktionen (Regressionstest, um sicherzugehen, dass nichts Basisfunktionalität zerstört wurde),

• neue/angepasste Funktionen (zielgerichtete Testszenarien für die Erweiterung),

• Schnittstellen (z.B. läuft der Datenimport noch, gehen E-Mails noch raus, etc.),

• nicht-funktionale Tests wie Performance, falls z.B. eine Massendatenverarbeitung neu dazukam.

• Benutzerakzeptanztest (UAT): Es ist äußerst wichtig, auch Endanwender oder zumindest Key User in die Tests einzubeziehen. Sie nutzen das System anders und entdecken Usability-Probleme oder fachliche Unstimmigkeiten, die Entwickler übersehen. Im UAT prüfen Vertreter der späteren Nutzergruppe, ob die Erweiterung ihren Anforderungen entspricht und intuitiv bedienbar ist. Das Feedback daraus fließt in finale Korrekturen ein.

• Go-Live-Vorbereitung und Fallback: Bevor in Produktion gegangen wird, sollte ein Rollback-Plan erstellt werden: Was tun, wenn nach Go-Live etwas schiefgeht? Idealerweise hat man, wie erwähnt, ein Backup oder kann auf vorherige Version zurückschalten. Man kommuniziert den Stakeholdern, dass eine Änderung kommt, und vereinbart ggf. einen Zeitraum verstärkter Überwachung (z.B. „Wir deployen am Freitag, und beobachten dann das Wochenende über das System“). Sollte ein kritischer Fehler auftreten, muss klar sein, wer entscheidet, ggf. die Änderung zurückzunehmen. Ein Stufenplan (Pilotierung) kann sinnvoll sein: Z.B. zuerst in einer Abteilung ausrollen, testen, dann auf alle ausweiten – falls anwendbar.

• Dokumentation und Abnahme: Alle Testergebnisse sollten protokolliert werden[43] – welche Tests wurden durchgeführt, was war das Resultat, welche Fehler wurden gefunden und behoben. Am Ende der Testphase steht idealerweise ein Abnahmeprotokoll: Die verantwortlichen Fachbereichsleiter unterschreiben, dass aus ihrer Sicht alles funktioniert. Das schafft Klarheit und schützt auch vor späteren Missverständnissen („das hat doch nie richtig funktioniert“ – „aber es wurde abgenommen“).

Im Grunde folgt ein CAFM-Projekt damit denselben Prinzipien wie andere IT-Projekte. Allerdings wird Testen im FM-Kontext manchmal unterschätzt (“ist ja nur eine Datenbank für Räume…”). Dabei hängen oft sicherheitsrelevante oder geschäftskritische Prozesse dran (z.B. Prüftermine für Geräte – ein Fehler hier kann gesetzliche Konsequenzen haben). Strukturiertes Testmanagement stellt sicher, dass das System stabil, sicher und effektiv läuft[37]. In Großunternehmen ist es üblich, eine klare Teststrategie und Testpläne zu definieren und sämtliche Ergebnisse systematisch zu dokumentieren[37]. Dies gewährleistet, dass das CAFM-System nach Anpassungen wirklich die Anforderungen erfüllt und reibungslos in die bestehende IT-Landschaft integriert ist[44].

• Um die vorgenannten Tests und Update-Vorbereitungen sauber durchführen zu können, braucht es eine geeignete Systemlandschaft. Bewährt hat sich das Dreistufenmodell: Entwicklung (DEV), Test/QS (TEST) und Produktion (PROD) – häufig auch um eine Staging- oder Integrationsstufe erweitert (DTAP-Modell: Development, Test, Acceptance, Production)[

• Entwicklungsumgebung (DEV): Hier werden alle Customizing-Einstellungen zuerst vorgenommen und alle Erweiterungen entwickelt. Es ist der Spielplatz der Entwickler und Key User. Diese Umgebung enthält typischerweise Testdaten, kann aber auch mal mit anonymisierten echten Daten befüllt werden, um realistischere Bedingungen zu haben. In DEV hat man volle Administratorrechte, um Schemaänderungen, Skripte etc. auszuprobieren, ohne Risiko für den Live-Betrieb. Oft nutzen Entwickler auch lokale Tools (z.B. IDE mit API-Zugriff) parallel zur DEV-Instanz.

• Test-/QS-Umgebung (TEST): Diese entspricht möglichst genau der späteren Produktionsumgebung – sowohl von der Softwareversion, Konfiguration als auch den Daten her[39]. Hierhin werden die in DEV erstellten Anpassungen übertragen (deployed), um sie unabhängig vom Entwicklungskontext zu prüfen. Im Idealfall hat TEST einen regelmäßigen Refresh von Produktivdaten oder zumindest einen repräsentativen Datenbestand. Die Konfiguration sollte identisch zu PROD sein, abgesehen von bewusst unterschiedlichen Parametern (z.B. Mailversand geht in TEST evtl. in ein Dummy-Postfach, um keine echten Mails zu senden). Auf TEST laufen die beschriebenen Tests (Funktion, Integration, UAT etc.). Es kann auch ein Abnahme-System separat geben (in manchen Firmen entspricht "TEST" dem Abnahme-System = User Acceptance Test). Wichtig ist: Keine Entwicklung auf diesem System! Änderungen hier sollten dokumentiert werden, damit sie in DEV nachgezogen werden – oder man macht gleich alle Änderungen in DEV und spielt sie erneut ein.

• Produktivumgebung (PROD): Das ist das Live-System, auf dem die Endbenutzer arbeiten. Dorthin kommt nur, was in TEST abgenommen wurde. Der Wechsel von TEST nach PROD sollte kontrolliert über ein Deployment erfolgen, möglichst nachvollziehbar und automatisiert. Beispielsweise: Customizing-Einstellungen werden über Konfigurationspakete exportiert und in PROD importiert; selbst geschriebene Plugins werden als Version X.Y in PROD installiert; Datenbankänderungen werden via Migrationsskript eingespielt. Idealerweise wird PROD während Deployments kurz in den Wartungsmodus gesetzt, um Inkonsistenzen zu vermeiden.

• Deployment-Strategien: Je nach Größe des Projektes kann das Deployment manuell oder automatisiert geschehen. Bei kleineren Änderungen (z.B. neuer Report) genügt oft ein manueller Import. Bei größeren Entwicklungen empfiehlt sich eine Versionsverwaltung (Git o.ä.) für den Code und ein automatisiertes Build/Deploy-Skript. Continuous Integration ist im CAFM-Bereich noch nicht überall Standard, aber bei hoch integrierten Teams machbar: D.h. ein Commit eines Plugins könnte automatisch auf dem Testsystem aktualisiert werden usw. Wichtig beim Deployment: Reihenfolge und Abhängigkeiten beachten. Z.B. zuerst Datenbank anpassen (neue Felder), dann Code deployen, dann Konfiguration. Außerdem vorab prüfen, ob Migration von Bestandsdaten nötig ist (wenn ein Feld umbenannt wurde etc., entsprechende Updates in der DB durchführen).

• Mehr-Mandanten oder Cloud-Szenarien: Wenn das CAFM in der Cloud betrieben wird, stellt der Anbieter oft isolierte Tenants für DEV, TEST, PROD bereit. Hier muss man schauen, wie man Konfigurationsänderungen zwischen diesen Tenants transportiert – oft über vom Hersteller bereitgestellte Transportwerkzeuge. Das Prinzip DEV→TEST→PROD bleibt aber gleich.

• Synchronisation der Umgebungen: Eine Herausforderung ist es, die Konsistenz zwischen den Umgebungen zu halten. Es sollte vermieden werden, dass in PROD andere Einstellungen sind als in DEV, die dann beim nächsten Deployment überschrieben würden. Praktisch muss man ggf. restriktiv sein: In PROD keine spontane Konfig-Änderung, sondern immer in DEV vornehmen, testen, transportieren. Wenn Notfälle in PROD direkt gelöst werden (z.B. ein Feld schnell verpflichtend gemacht), muss das in DEV/TEST nachgezogen werden.

• Es garantiert ein sauber aufgesetzter DTAP-Prozess, dass Änderungen nicht direkt ungeprüft ins Livesystem gelangen, sondern kontrolliert entwickelt, getestet und ausgerollt werden. Dies minimiert Ausfallrisiken und Qualitätsprobleme. Gerade weil FM-Software oft viele Schnittstellen hat (siehe oben), ist eine Testinstanz zum Überprüfen der Integration unerlässlich: „Die Testumgebung ähnelt der produktiven Umgebung so stark wie möglich, um sicherzustellen, dass alles ordnungsgemäß funktioniert“ – dieser Grundsatz sollte immer gelten.

• Technische Dokumentation der Erweiterungen: Für jede entwickelte Komponente (sei es ein Skript, ein Plugin, ein neuer Bericht) sollte eine technische Beschreibung vorliegen. Diese umfasst im Minimalfall: Zweck der Erweiterung, Funktionsweise, betroffene Objekte/Tabellen, Triggerpunkte (wann läuft sie?), und Entwickler/Datum. Idealerweise liegt der Quellcode in einem Repository, und es gibt darin Kommentare an entscheidenden Stellen (damit ein anderer Entwickler die Logik versteht). SAP geht z.B. so weit, dass jede Erweiterung selbst dokumentiert ist und man diese Doku direkt im System über eine Schaltfläche abrufen kann – ein sinnvolles Feature, das man analog auch ohne SAP implementieren kann (z.B. in einem Wiki oder einem zentralen Dokument).

• Customizing-Dokumentation (Konfigurationsdokumente): Neben dem Code muss auch Parametrierung dokumentiert werden. Wenn z.B. 50 neue Felder angelegt wurden, sollte eine Liste existieren: Welches Feld (Name, Typ), wo verwendet, wer hat es angefordert, wann angelegt. Auch neue Katalogeinträge, Rollen/Berechtigungen, Workflows etc. gehören in die Dokumentation. Viele Beratungsfirmen erstellen am Projektende ein Customizing-Handbuch, das all diese Punkte aufzählt. Dieses Dokument ist Gold wert, wenn später Erweiterungen geändert oder neue Leute eingearbeitet werden müssen.

• Übergabedokumente: Falls externe Entwickler oder Dienstleister im Spiel sind, muss bei Projektende eine saubere Übergabe ans interne Team oder den Betrieb erfolgen. Dazu dient ein Dokument (oder Workshop), der erläutert: Welche Erweiterungen wurden gebaut? Wie ist die Architektur? Wie kann man sie pflegen? Gibt es besondere Abhängigkeiten oder Stolperfallen? Beispielsweise: „Modul X wurde mit .NET 5 entwickelt, zum Übersetzen wird Visual Studio 2019 benötigt, der Code liegt in Repository Y, beim Deployment ist Sequence Z einzuhalten“. Solche Hinweise sind für den nachhaltigen Betrieb enorm wichtig.

• Nachvollziehbarkeit für Dritte: Oft kommt es vor, dass die Person, die ursprünglich customizet hat, nach ein paar Jahren nicht mehr verfügbar ist. Dann steht ein Nachfolger vor dem Puzzle „warum hat man das damals so gemacht?“. Gute Dokumentation liefert hier Antworten: z.B. Protokolle der Entscheidungsmeetings, Change Requests mit Begründungen, etc. So kann man nachvollziehen, weshalb eine bestimmte Logik so umgesetzt wurde und ob sie heute ggf. geändert werden kann, ohne alte Anforderungen zu verletzen.

• Änderungshistorie (Changelog): Es empfiehlt sich, eine Chronik der Änderungen zu führen. Diese kann in einfachster Form eine Excel-Liste sein mit Spalten Datum, Version, Änderung, betroffene Module, Durchführer. Oder man nutzt ein Ticketsystem/Änderungsmanagement-Tool, in dem jedes Change Request erfasst und abgeschlossen wird. Wichtig ist: Bei einem Problem in Produktion kann man dann nachsehen, welche Änderungen zuletzt gemacht wurden (und das Problem evtl. auslösen). Ein offizielles Changelog ist auch für den Hersteller-Support hilfreich, falls dieser bei Problemen unterstützt – er sieht dann gleich, dass z.B. eine eigene Erweiterung im Spiel ist.

• Benutzerdokumentation: Nicht zu vergessen – wenn Customizing auch Auswirkungen auf Nutzer hat (neue Felder, geänderte Prozesse), sollte auch die Anwenderdokumentation aktualisiert werden. Das kann bedeuten, Handbücher oder Online-Hilfen anpassen, Schulungsunterlagen erweitern usw. Ein typischer Fehler ist, dass nach vielen Anpassungen die Doku nicht Schritt hält und Nutzer dann im Dunkeln tappen, wie sie die neuen Felder/Masken nutzen sollen.

• Kommentierung im System: Neben externen Dokus sollte man auch im System selbst dokumentieren, wo es geht. Beispiel: In vielen CAFM-Systemen kann man für Felder und Tabellen Beschreibungen hinterlegen – hier sollte man den Zweck des Feldes eintragen. Für Workflows kann man Kommentare hinzufügen („dieser Workflow setzt Feld X aus Y Gründen“). So finden künftige Administratoren schon im System Hinweise.

• Verlinkung von Anforderungen und Umsetzung: In einem idealen Szenario hat man für jede Anforderung (Use Case) die Umsetzungsschritte dokumentiert. Z.B. Anforderung: „Automatische Eskalation überfälliger Tickets“ – Umsetzung: „Eskalationsregel konfiguriert plus Notification-Script erstellt, siehe Doku Abschnitt soundso“. Dadurch sieht man schnell, welche Erweiterungen zusammengehören und welchen Geschäftsprozess sie bedienen.

Dokumentation kostet Zeit und wird im Eifer des Projektgeschäfts gerne nach hinten geschoben. Es zeigt sich aber immer wieder, dass fehlende Dokumentation später viel mehr Zeitverlust und Risiken bedeutet – etwa wenn bei einem Update niemand genau weiß, was angepasst wurde (und man es mühsam herausfinden muss). Deshalb gehört die Dokumentation der Anpassungen als fester Bestandteil in jedes CAFM-Projekt und sollte laufend gepflegt werden, nicht erst am Schluss „irgendwie hingeschrieben“.

• Rollen und Verantwortlichkeiten: Typischerweise sind an CAFM-Anpassungen mehrere Rollen beteiligt: - Ein CAFM-Manager/Administrator auf Fachseite, der die Anforderungen koordiniert und oft selbst einfache Customizings durchführen kann (Masken anpassen, Felder pflegen, etc.). - Key User in den Fachabteilungen (z.B. Technischer Leiter, Raumplanung etc.), die wissen, was sie brauchen, und die Spezifikationen für Anpassungen liefern. - Entwickler / technische Experten (intern in der IT-Abteilung oder extern vom Anbieter/Integrator), die die komplexeren Erweiterungen umsetzen und die technische Architektur betreuen. - Change Manager / Projektleiter, der überblickt, welche Änderungen wann eingeplant werden, und die Kommunikation steuert.

• Es ist sinnvoll, für das CAFM einen inhaltlich Verantwortlichen zu benennen (oft FM-Leiter oder IT-Application-Manager) und einen technisch Verantwortlichen (für Systemtechnik). Diese Personen sollten bei allen Customizing-Entscheidungen einbezogen sein.

• Change-Management-Prozess: Änderungen am CAFM-System sollten einem geregelten Änderungsprozess unterliegen – ähnlich wie bei anderen kritischen Systemen (ITIL Change Management). Das heißt: - Es gibt einen Weg, wie Bedarfe angemeldet werden (z.B. ein Fachbereich meldet: „Wir brauchen ein neues Feld für xyz“ oder „Bericht ABC soll andere Daten zeigen“). - Diese Anforderungen werden bewertet und priorisiert: z.B. im Rahmen eines CAFM-Steuerungsgremiums oder Jour Fixe zwischen FM und IT. Man prüft Aufwand, Nutzen, Auswirkungen. - Für genehmigte Changes wird ein Umsetzungstermin geplant (ggf. gebündelt in Releases, z.B. „Quartalsweise spielen wir gesammelte Änderungen ein“). - Während der Umsetzung wird der Fortschritt dokumentiert, und am Ende erfolgt eine Abnahme (wie oben beschrieben). - Jede Änderung hat einen Freigabeschritt, idealerweise schriftlich: Fachliche Freigabe (das Ergebnis erfüllt die Anforderung) und technische Freigabe (System stabil, keine negativen Nebeneffekte).

• Durch solch einen Prozess stellt man sicher, dass nicht willkürlich am System herumkonfiguriert wird, sondern alles abgestimmt und nachverfolgbar ist. Insbesondere verhindert man damit das Risiko, dass parallel widersprüchliche Änderungen erfolgen (z.B. Abteilung A ändert ein Feld aus eigenem Antrieb, während Abteilung B eine andere Idee dazu hat).

• Governance-Gremium: In größeren Organisationen ist es üblich, ein CAFM-Kernteam oder Gremium zu haben, das die Weiterentwicklung steuert. Dort sitzen Vertreter aller wichtigen Stakeholder (Technik, Infrastruktur, ggf. kaufm. FM, IT). Dieses Gremium priorisiert Anforderungen und setzt Standards (z.B. „Keine Entwicklung ohne vorher zu prüfen, ob Standardfunktion reicht“ oder „Benennungskonventionen für neue Felder“ etc.). Auch Fragen der Compliance werden hier berücksichtigt: Muss bei Änderungen die interne Revision informiert werden? Gibt es regulatorische Anforderungen (z.B. hinsichtlich Betreiberverantwortung), die eingehalten werden müssen?

• Externe vs. interne Entwicklung: Abhängig von der verfügbaren Expertise entscheidet man, wer die Anpassungen durchführt. Manche Unternehmen verlassen sich stark auf den Hersteller oder dessen Partner für Erweiterungen – was den Vorteil hat, dass Profis am Werk sind, die das System in- und auswendig kennen. Andere haben eine eigene IT, die z.B. eigene Reports oder Schnittstellen schreibt. Beide Wege sind gangbar; wichtig ist klare Verantwortlichkeit. Falls Externe entwickeln, sollte intern jemand das Wissen mit aufnehmen (siehe Doku/Übergabe). Falls intern entwickelt wird, sollten die Mitarbeiter entsprechende Schulungen vom Hersteller bekommen, um nicht „am System vorbei“ zu entwickeln.

• Rechteverwaltung für Customizer: Auf technischer Ebene muss man steuern, wer überhaupt das Recht hat, Änderungen vorzunehmen. In Produktivsystemen sollte nur ein eng begrenzter Personenkreis Admin-Rechte haben, um Customizings einzuspielen. In Test/Dev können mehr Leute mitmachen. Manche CAFM-Systeme bieten differenzierte Berechtigungen, z.B. darf ein Key User Berichte ändern, aber keine Felder anlegen. Solche Mechanismen sollte man nutzen.

• Risiko- und Impact-Analyse vor Changes: Ein Bestandteil der Governance ist auch, vor jeder größeren Änderung eine Impact-Analyse zu machen: Welche Module sind betroffen? Können dadurch bestehende Prozesse gestört werden? Brauchen wir Schulungen für User? Solche Fragen klärt man am besten im Change Advisory Board (CAB) oder einem ähnlichen Forum, bevor „der Techniker mal schnell was ändert“. Gerade weil CAFM oft viele Abteilungen berührt, ist es wichtig, dass eine Änderung nicht isoliert betrachtet wird. Beispiel: Eine Anpassung im Wartungsworkflow könnte Auswirkungen auf das Berichtswesen (KPI-Auswertung) haben; das sollte vorher mit allen Beteiligten abgestimmt sein.

• Release-Management: Wenn viele Änderungen anstehen, kann man diese in Bündeln (Releases) zusammenfassen, um nicht ständig kleinteilig ändern zu müssen. Etwa: Im Halbjahr 1 sammeln wir alle Wünsche, setzen sie um, Testphase, dann Release 1.1 einspielen. Halbjahr 2 ähnlich für Release 1.2, etc. Dies schafft Transparenz und Planbarkeit. Kleinere Bugfixes können natürlich ad-hoc, aber größere Dinge eben gesammelt. Der Hersteller selbst bringt ja auch oft gebündelte Releases heraus; das kann man intern spiegeln.

• Insgesamt sorgt solide Governance dafür, dass Customizing kontrolliert abläuft: passend zu den Unternehmenszielen, im Rahmen des Budgets und ohne die Systemstabilität zu gefährden. Und klar definierte Rollen & Prozesse verhindern Wildwuchs und Wissensmonopole, was letztlich die CAFM-Lösung nachhaltig erfolgreich macht.

• Upgrade-Probleme: Wie ausführlich beschrieben, besteht ein großes Risiko darin, durch unbedachte Anpassungen den Upgrade-Pfad zu verbauen. Im schlimmsten Fall bleibt man auf einer alten Version „stecken“, weil die Eigenanpassungen mit neueren Releases inkompatibel sind. Das führt zu Sicherheitslücken (fehlende Patches) und irgendwann zu Hersteller-Supportverlust. Auch kann ein Upgrade unverhältnismäßig teuer werden, wenn zahlreiche Anpassungen migriert oder neu entwickelt werden müssen.

• Abhängigkeit von Schlüsselpersonen (Know-how-Verlust): Oft sind Customizings das Werk einzelner Experten. Wenn diese das Unternehmen verlassen oder länger ausfallen, fehlt das Wissen über die Funktionsweise der Erweiterungen. Ohne ausreichende Dokumentation kann schon nach kurzer Zeit niemand mehr genau sagen, was eine bestimmte Regel oder ein Script tut – ein enormes Betriebsrisiko. Neue Anforderungen können dann langsamer umgesetzt werden, weil erst das Alte verstanden werden muss.

• Erhöhte Komplexität und Fehleranfälligkeit: Jede Abweichung vom Standard erhöht die Systemkomplexität. Viele individuelle Regeln und Module können sich gegenseitig beeinflussen und unvorhergesehene Seiteneffekte auslösen. Z.B. könnte eine Validierungsregel mit einem anderen Workflow kollidieren, was erst im Live-Betrieb auffällt. Komplexität erschwert auch den Support: der Hersteller-Support kann bei stark modifizierten Systemen Probleme schlechter analysieren („Das ist ja gar nicht der Standard, da müssen Sie selbst schauen“).

• Höhere Wartungskosten: Individuallösungen erfordern auf Dauer mehr Betreuung – regelmäßige Anpassung an geänderte Rahmenbedingungen, Monitoring der eigenen Scripts, etc. Insbesondere Schnittstellen zu externen Services müssen kontinuierlich gepflegt werden (wenn z.B. der externe Service ein API-Update hat). Ohne Ressourcenplanung hierfür kann die Lösung mit der Zeit instabil werden.

• Performance- und Skalierungsprobleme: Unsauber implementierte Erweiterungen können die Systemleistung beeinträchtigen. Z.B. ein ineffizientes Script, das bei jedem Speichern läuft und die Antwortzeit erhöht, oder ein externer Serviceaufruf in der Transaktion, der das UI warten lässt. Solche Effekte müssen im Blick behalten werden. Auch kann die Datenmenge steigen (z.B. durch neue Felder/Tabellen) – wenn das System dafür nicht optimiert ist, können Abfragen langsamer werden.

• Sicherheitslücken: Eigenentwicklungen können Schwachstellen einführen, etwa wenn Eingaben nicht ordentlich validiert werden (SQL-Injection etc.) oder zu großzügige Rechte benötigt werden. Auch bei Integration mit Cloud-Services sind Aspekte wie Verschlüsselung, Zugriffsschutz essentiell – ein Versäumnis hier öffnet Türen für Angreifer, was in sensiblen FM-Daten (Zutrittskontrollen, Personendaten) sehr kritisch wäre.

• Scope Creep / Over-Customization: Ein weiches Risiko ist, dass man zu viel customized. Aus Begeisterung an den Möglichkeiten werden immer mehr spezielle Wünsche umgesetzt, die vielleicht gar keinen großen Mehrwert bringen, aber Aufwand und Komplexität steigern. Irgendwann ist das System so sonderangefertigt, dass Upgrades scheuen und die Implementierung ursprünglicher neuer Standardfunktionen behindert wird (weil man lieber eigene Lösung weiter pflegt).

• Standard vor Individuell: Immer prüfen, ob ein vorhandenes Feature den Bedarf decken kann, bevor man neu entwickelt. Oft lässt sich mit kreativer Nutzung der Standardfunktionen viel erreichen. Faustregel: So viel Standard wie möglich, so viel Customizing wie nötig. Keine „Programmierung um der Programmierung willen“.

• Fokus auf Mehrwert: Customization-Aufwand sollte in Relation zum Nutzen stehen. Im Zweifel Prioritäten setzen: erst die Anpassungen mit größtem geschäftlichen Nutzen umsetzen. Weniger dringliche oder „Nice-to-have“-Wünsche zurückstellen. Wie es ein Leitfaden ausdrückt: „Fokussieren Sie Customizing auf Bereiche, die den größten Mehrwert liefern.“. So bleibt Aufwand beherrschbar und man verzettelt sich nicht in Details.

• Schrittweise Automatisierung: Insbesondere bei komplexen Workflow-Automatismen gilt: klein anfangen, dann steigern. „Workflows erst einfach starten und Komplexität schrittweise erhöhen“, um nicht unnötig komplizierte Regeln zu bauen, die keiner mehr versteht. Jede Automatisierung sollte echte manuelle Arbeit einsparen, aber keine neuen Probleme schaffen.

• Saubere Entwicklungsrichtlinien: Falls Code geschrieben wird, sollten Coding-Standards vereinbart sein (Namenskonventionen, Fehlerbehandlung, Logging etc.). So können auch andere Entwickler den Code leichter übernehmen. Ebenso sollte klar sein, wo eigener Code liegt (z.B. in separatem Namespace com.company.* statt im Namespace des Herstellers).

• Konsequente Dokumentation & Wissensweitergabe: Wie oben betont, die Dokumentation nicht schleifen lassen. Regelmäßig Updates der Doku nachziehen. Außerdem macht es Sinn, Wissen zu teilen – z.B. Team-Review von Code (Vier-Augen-Prinzip), Pair-Programming bei kritischen Dingen, oder interne kleine Schulungen, wenn jemand etwas Neues im System gebaut hat. So entsteht nicht das „One-Man-Show“-Problem.

• Monitoring nach Livegang: Nach Einführung von Erweiterungen sollte man das System engmaschig beobachten. Performance-Metriken im Blick behalten (CPU, DB-Load), Logfiles auf Fehler scannen, Nutzer-Feedback einholen. So erkennt man früh, falls eine Erweiterung im Alltag Probleme macht (z.B. viele Fehlermails, oder ein geplanter Job läuft deutlich länger als gedacht). Mit diesem Feedback kann man schnell nachsteuern.

• Fall-Back & Notfallplan: Für kritische Erweiterungen sollte ein Notfall-Aus-Schalter vorgesehen sein. Beispielsweise, wenn ein neuer automatisierter Prozess spinnt und massenhaft Tickets erstellt, muss man ihn sofort deaktivieren können (sei es durch einen Config-Schalter oder notfalls durch Stoppen eines Dienstes). In Code kann man z.B. Feature-Toggle einbauen. Auf diese Weise kann man im Ernstfall den Schaden begrenzen, bis eine Lösung gefunden ist.

• Enger Kontakt zum Hersteller: Gerade wenn es um tiefe Erweiterungen geht, lohnt es sich, den Hersteller (oder dessen Community) zu kontaktieren. Vielleicht gibt es von deren Seite Best Practices, oder ein ähnliches Add-On wurde schon mal gemacht. Auch bei Upgrades ist es sinnvoll, dem Hersteller-Support vorab die Liste eigener Anpassungen zu geben – manchmal können sie vor bekannten Problemen warnen. Zudem sollte man neue Releases und Patches direkt darauf prüfen, ob sie Features bieten, die eigene Workarounds überflüssig machen könnten.

• Prototyping: Bei sehr komplexen Anforderungen erst einen Proof-of-Concept bauen, bevor man es im großen Stil integriert. Beispielsweise ein kleiner Test, ob eine IoT-Anbindung klappt und nützliche Daten liefert, bevor man hunderte Sensoren einbindet. So kann man technischen und fachlichen Erfolg früh validieren.

• Change Management für Endnutzer: Jede Änderung – so technisch sie ist – hat auch Einfluss auf die Nutzer. Daher immer die Change-Kommunikation und Schulung mitdenken. Nutzer sollten informiert werden, warum ein neues Feld da ist, wie der neue Workflow geht etc. Gutes Change Management erhöht die Akzeptanz und senkt Fehlbedienungen, was wiederum den Support entlastet.

Man kann sagen, dass Customizing und Erweiterungsentwicklung im CAFM ein mächtiges Instrument sind, um das Optimum aus der Software herauszuholen. Richtig eingesetzt, schafft man damit eine passgenaue Lösung, die Standard-Funktionalität und individuelle Anforderungen vereint. Wichtig ist, dies kontrolliert, dokumentiert und zukunftsorientiert anzugehen – dann überwiegen klar die Vorteile. Wenn man hingegen unkoordiniert vorgeht, kann man sich und dem System schaden. Mit den genannten Best Practices und einem Bewusstsein für Risiken lässt sich dies vermeiden.

Durch eine strukturierte, best-practice-orientierte Vorgehensweise wird die Dienstleistung „CAFM: Customizing und Erweiterungsentwicklung“ zu einem Erfolgsfaktor: Das CAFM-System wird zum lebenden Organismus, der sich den Unternehmensprozessen anpasst und mit ihnen wächst – ohne dabei seine Stabilität und Upgrade-Fähigkeit zu verlieren. So erzielt man langfristig einen hohen Nutzen und garantiert, dass das CAFM-System den wandelnden Anforderungen im Facility Management stets gewachsen ist.