Innovationsstrategie für Finanzinstitute

Das Zielbild beschreibt den angestrebten zukünftigen Zustand des Facility Managements. Es legt fest, wie innovative Lösungen die Planung, den Betrieb und die Weiterentwicklung von Immobilien, technischen Anlagen, Flächen und FM-Dienstleistungen unterstützen sollen.

Im Mittelpunkt stehen konkrete betriebliche Verbesserungen. Das Zielbild muss daher benennen, welche Probleme gelöst werden sollen, welche Nutzergruppen betroffen sind und welche messbaren Veränderungen erwartet werden. Eine allgemeine Aussage wie „Das Facility Management soll digitaler werden“ reicht nicht aus. Erforderlich sind präzise Zielsetzungen, beispielsweise kürzere Bearbeitungszeiten, ein schnellerer Zugriff auf gültige Dokumente oder eine bessere Transparenz über Anlagenzustände.

Das Zielbild dient als fachlicher Orientierungsrahmen für das Innovationsportfolio. Neue Ideen und Pilotprojekte werden daran gemessen, ob sie einen erkennbaren Beitrag zum angestrebten Zustand leisten.

Die Ziele müssen soweit möglich durch Kennzahlen oder überprüfbare Kriterien konkretisiert werden. Dadurch lässt sich nach einer Pilotierung feststellen, ob eine Lösung tatsächlich zur Zielerreichung beiträgt oder lediglich eine technische Funktion bereitstellt.

Innovationsprojekte sind zeitlich begrenzte Vorhaben. Sie basieren auf definierten Annahmen, einem klar abgegrenzten Testumfang und vorab festgelegten Erfolgskriterien. Während des Projekts wird geprüft, ob die vorgesehene Lösung fachlich funktioniert, von den Nutzern akzeptiert wird, wirtschaftlich vertretbar ist und in bestehende FM-Prozesse integriert werden kann.

Der Regelbetrieb beginnt erst nach einer dokumentierten Abschlussbewertung und formalen Freigabe. Vor der Übergabe müssen mindestens die dauerhaften Zuständigkeiten, Supportleistungen, Systemverantwortlichkeiten, Datenpflege, Dokumentation und erforderlichen Schulungen geregelt sein.

Damit wird verhindert, dass eine technisch erfolgreiche Pilotlösung ohne ausreichende betriebliche Vorbereitung dauerhaft eingesetzt wird. Nicht jede Pilotierung muss in den Regelbetrieb übergehen. Auch ein begründeter Abbruch kann ein wertvolles Projektergebnis sein, wenn dadurch ungeeignete Lösungen oder unverhältnismäßige Folgekosten frühzeitig erkannt werden.

Die Strukturierung nach Innovationsfeldern erleichtert die Einordnung neuer Ideen. Sie zeigt außerdem, in welchen Bereichen bereits Projekte laufen und wo noch betrieblicher Entwicklungsbedarf besteht.

Ein Vorhaben kann mehrere Innovationsfelder betreffen. Ein KI-gestütztes Wissensmanagement kann beispielsweise sowohl dem Wissensmanagement als auch der Prozessautomatisierung und Projektsteuerung zugeordnet werden. Für die Portfoliosteuerung sollte dennoch ein vorrangiges Innovationsfeld festgelegt werden.

Die Auswahl beginnt mit einer konkreten betrieblichen Herausforderung. Ausgangspunkt können wiederkehrende Bearbeitungsprobleme, lange Suchzeiten, fehlende Transparenz, uneinheitliche Datenbestände oder aufwendige Abstimmungen zwischen internen und externen Beteiligten sein.

Eine Technologie allein begründet noch kein Innovationsprojekt. Die Verfügbarkeit eines neuen KI-Systems, Sensors oder digitalen Werkzeugs ist lediglich eine technische Möglichkeit. Ein Innovationsvorhaben entsteht erst dann, wenn ein klar beschriebener Anwendungsfall, betroffene Nutzergruppen und ein erwarteter FM-Nutzen vorliegen.

Vor Aufnahme eines Innovationsfelds sollte deshalb geprüft werden:

• Welches konkrete betriebliche Problem besteht?

• Welche Gebäude, Anlagen, Prozesse oder Dienstleistungen sind betroffen?

• Wie wird das Problem derzeit bearbeitet?

• Welche qualitativen oder quantitativen Verbesserungen werden erwartet?

• Welche Daten, Systeme, Kompetenzen und Partner werden benötigt?

• Ist die Lösung in bestehende Abläufe integrierbar?

• Kann ein begrenzter und bewertbarer Pilotbereich festgelegt werden?

Innovationsfelder mit hoher strategischer Bedeutung und wiederkehrendem betrieblichem Bedarf sollten vorrangig bearbeitet werden.

Jede Phase baut auf den Ergebnissen der vorherigen Phase auf. Ein Projekt sollte nicht in die Pilotierung wechseln, solange Problemstellung, Zielsetzung und Erfolgskriterien nicht ausreichend definiert sind.

Die Dokumentation muss so aufgebaut sein, dass Entscheidungen später nachvollzogen werden können. Dazu gehören insbesondere die ursprünglichen Annahmen, vorgenommene Änderungen, gemessene Ergebnisse und Gründe für Freigaben oder Ablehnungen.

Formale Entscheidungspunkte sind nach der Vorprüfung, nach der Pilotierung und vor der Übergabe in den Regelbetrieb erforderlich.

Nach der Vorprüfung entscheidet das zuständige Gremium, ob die Idee verworfen, überarbeitet oder als Pilotprojekt weiterverfolgt wird. Grundlage sind der erwartete Nutzen, der Ressourcenbedarf, die strategische Relevanz und die Umsetzbarkeit.

Nach der Pilotierung werden die tatsächlichen Ergebnisse mit den vorab festgelegten Erfolgskriterien verglichen. Mögliche Entscheidungen sind:

• Fortführung ohne wesentliche Änderungen

• Verlängerung oder Erweiterung des Piloten

• Technische oder organisatorische Anpassung

• Vorbereitung der Skalierung

• Zurückstellung des Projekts

• Beendigung des Projekts

Vor dem Regelbetrieb muss zusätzlich bestätigt werden, dass die Lösung dauerhaft unterstützt, finanziert und organisatorisch verantwortet werden kann. Eine fachlich positive Pilotbewertung allein reicht für diese Entscheidung nicht aus.

Das Innovationsportfolio stellt sämtliche Ideen, Vorprüfungen, Pilotprojekte, Rollout-Vorhaben und bereits übergebene Lösungen in einer einheitlichen Übersicht dar. Es ist das zentrale Steuerungsinstrument für das Management und das Facility Management.

Das Portfolio schafft Transparenz über Projektstatus, erwarteten Nutzen, Ressourceneinsatz, Risiken und anstehende Entscheidungen. Es verhindert, dass Innovationsvorhaben isoliert betrachtet werden, und ermöglicht einen Vergleich zwischen Projekten mit unterschiedlichen Technologien oder Anwendungsbereichen.

Darüber hinaus unterstützt es die Kapazitätsplanung. Wenn mehrere Vorhaben gleichzeitig dieselben internen Fachpersonen, Datenquellen oder technischen Schnittstellen benötigen, werden Abhängigkeiten frühzeitig sichtbar.

Ergänzend können Risiken, Abhängigkeiten, nächste Entscheidungstermine und aktuelle Maßnahmen aufgenommen werden. Die Mindestangaben müssen regelmäßig aktualisiert und einheitlich gepflegt werden.

Innovationsvorhaben werden nach Reifegrad, strategischer Bedeutung, Umsetzungsaufwand und erwartetem Nutzen eingeordnet. Eine solche Kategorisierung erleichtert die Priorisierung und verhindert, dass ausschließlich kurzfristig sichtbare Projekte verfolgt werden.

Kurzfristig realisierbare Verbesserungen zeichnen sich durch einen klaren Anwendungsfall, begrenzten Aufwand und schnell messbare Ergebnisse aus. Längerfristige Entwicklungsprojekte können einen höheren strategischen Nutzen bieten, erfordern jedoch häufig umfangreichere Datenaufbereitung, technische Integration oder organisatorische Veränderungen.

Zusätzlich sollte zwischen folgenden Reifegraden unterschieden werden:

• Frühe Idee ohne geprüfte Voraussetzungen

• Fachlich beschriebener Anwendungsfall

• Positiv vorgeprüftes Vorhaben

• Geplanter Pilot

• Laufender Pilot

• Bewerteter Pilot

• Vorbereiteter Rollout

• Übergebene Lösung im Regelbetrieb

Durch diese Einordnung kann das Management erkennen, wie ausgewogen das Portfolio aufgebaut ist und welche Projekte kurzfristig Entscheidungen oder Ressourcen benötigen.

Die Kriterien sollten nach einem einheitlichen Bewertungssystem beurteilt werden. Möglich ist beispielsweise eine Skala von eins bis fünf, wobei niedrige Werte eine geringe und hohe Werte eine starke Erfüllung des jeweiligen Kriteriums darstellen.

Die Bewertung darf nicht allein durch den Anbieter einer Lösung erfolgen. Facility Management, betroffene Nutzergruppen und erforderliche interne Fachstellen müssen einbezogen werden. Bei Unsicherheiten sind Annahmen ausdrücklich als solche zu kennzeichnen und während der Pilotierung zu prüfen.

Innovationsideen können nach erwartetem Nutzen und Umsetzungsaufwand in vier Gruppen eingeordnet werden:

Die Matrix dient als Entscheidungshilfe, ersetzt aber keine fachliche Gesamtbewertung. Ein Projekt mit hohem Aufwand kann trotz längerer Vorbereitungszeit prioritär sein, wenn es ein wesentliches betriebliches Problem löst oder auf viele Standorte übertragbar ist.

Umgekehrt sollte ein technisch leicht umsetzbares Projekt nicht automatisch bevorzugt werden, wenn sein Nutzen gering, schwer messbar oder nur für eine sehr kleine Nutzergruppe relevant ist.

FM-relevante Informationen befinden sich häufig in unterschiedlichen Dokumentenablagen, Fachsystemen, Projektordnern und persönlichen Wissensbeständen. Prozessbeschreibungen, Anlageninformationen, Arbeitsanweisungen, Projektunterlagen und Erfahrungswissen sind dadurch nicht immer schnell auffindbar.

Die Folgen sind lange Suchzeiten, uneinheitliche Auskünfte und eine hohe Abhängigkeit von einzelnen Wissensträgern. Mitarbeitende verwenden möglicherweise unterschiedliche Dokumentenversionen oder müssen wiederkehrende Fachfragen mehrfach beantworten. Bei Personalwechseln, Projektübergaben oder der Zusammenarbeit mit externen Partnern kann wichtiges Wissen verloren gehen oder nur unvollständig weitergegeben werden.

Ein weiteres Problem besteht darin, dass vorhandene Informationen zwar grundsätzlich verfügbar sind, ihre Gültigkeit oder fachliche Zuständigkeit jedoch nicht eindeutig erkennbar ist. Ein KI-gestütztes System darf daher nicht nur Inhalte auffinden. Es muss auch die zugrunde liegende Dokumentenbasis nachvollziehbar machen.

Das KI-gestützte Wissensmanagement soll berechtigten Anwendern einen schnellen, strukturierten und nachvollziehbaren Zugriff auf freigegebene FM-Informationen ermöglichen.

Die Lösung unterstützt beispielsweise bei der Suche nach Prozessbeschreibungen, Anlageninformationen, Projektunterlagen und internen Arbeitsanweisungen. Sie soll vorhandene Informationen aufbereiten, ohne die fachliche Verantwortung der zuständigen Personen zu ersetzen.

Für jede bereitgestellte Antwort muss erkennbar sein, aus welchem Dokument oder Informationsbestand sie abgeleitet wurde und welchen Versions- beziehungsweise Freigabestand die Quelle besitzt. Inhalte ohne ausreichende Grundlage müssen als nicht verfügbar oder nicht eindeutig beantwortbar gekennzeichnet werden.

Für jedes Anwendungsszenario sollte eine eigene Gruppe von Testfragen festgelegt werden. Dadurch kann geprüft werden, ob die Lösung nicht nur allgemeine Inhalte findet, sondern auch für konkrete betriebliche Aufgaben geeignet ist.

• Freigegebene FM-Dokumente und Arbeitsanweisungen

• Eindeutige Dokumentenbezeichnungen und Versionsstände

• Definierte Zugriffsberechtigungen für die vorgesehenen Nutzergruppen

• Benannte verantwortliche Personen für fachliche Prüfung und Aktualisierung

• Kennzeichnung gültiger, veralteter und archivierter Inhalte

• Nachvollziehbare Zuordnung der Dokumente zu Prozessen, Gebäuden, Anlagen oder Projekten

• Geregeltes Verfahren für die Aufnahme neuer und die Entfernung ungültiger Inhalte

Die Qualität der Lösung hängt unmittelbar von der Qualität des bereitgestellten Informationsbestands ab. Ungeordnete, widersprüchliche oder veraltete Dokumente können nicht allein durch den Einsatz von KI zuverlässig korrigiert werden.

Vor Beginn des Piloten ist deshalb zu prüfen, ob der ausgewählte Dokumentenbestand ausreichend vollständig, eindeutig bezeichnet und fachlich freigegeben ist.

Informationsbedarf → autorisierte Anfrage → Suche in freigegebenen Wissensquellen → Aufbereitung der Antwort → Anzeige der Quelle und des Dokumentenstands → fachliche Verwendung

Der Prozess beginnt mit einem konkreten Informationsbedarf eines berechtigten Anwenders. Die Anfrage wird ausschließlich in den für diese Person freigegebenen Wissensquellen verarbeitet. Anschließend bereitet die Lösung die gefundenen Inhalte in verständlicher Form auf.

Vor der fachlichen Verwendung muss der Anwender die zugrunde liegende Quelle und ihren Dokumentenstand erkennen können. Die Antwort dient als Unterstützung. Die Verantwortung für betriebliche Entscheidungen verbleibt bei der zuständigen Fachfunktion.

Der Pilot wird auf einen klar abgegrenzten Wissensbereich beschränkt. Geeignet ist beispielsweise ein definierter Prozess, ein bestimmter Dokumententyp oder ein ausgewähltes Projektgebiet mit ausreichend gepflegtem Informationsbestand.

Vor Beginn werden folgende Punkte festgelegt:

• Nutzergruppen und Zugriffsrechte

• Umfang und Qualität des Dokumentenbestands

• Repräsentative Testfragen

• Erwartete Antworten oder Bewertungsmaßstäbe

• Testzeitraum

• Verantwortlichkeiten für fachliche Prüfung

• Verfahren zur Erfassung von Fehlern und Korrekturen

• Erfolgskriterien und Abbruchbedingungen

Während des Piloten müssen sowohl erfolgreiche als auch fehlerhafte oder unvollständige Antworten dokumentiert werden. Nur dadurch lässt sich beurteilen, in welchen Anwendungsfällen die Lösung zuverlässig eingesetzt werden kann und wo weiterhin eine manuelle Prüfung erforderlich ist.

Die Kennzahlen sind vor Beginn des Piloten mit Ausgangswerten oder Zielwerten zu versehen. Beispielsweise kann die durchschnittliche heutige Suchzeit mit der Suchzeit während des Piloten verglichen werden.

Neben Durchschnittswerten sind kritische Einzelfälle zu betrachten. Eine insgesamt hohe Antwortqualität reicht nicht aus, wenn bei wichtigen Arbeitsanweisungen regelmäßig falsche oder veraltete Informationen ausgegeben werden.

Eingehende FM-Anfragen werden anhand ihres Inhalts erfasst, kategorisiert und an den voraussichtlich zuständigen FM-Bereich oder Dienstleister weitergeleitet. Die Lösung kann beispielsweise zwischen technischen Störungen, Reinigungsanliegen, Flächenfragen und allgemeinen Serviceanfragen unterscheiden.

Der Pilot sollte auf definierte Anfragearten und einen begrenzten Nutzerkreis beschränkt werden. Zu bewerten sind insbesondere die Qualität der Zuordnung, die Bearbeitungszeit, die Zahl notwendiger manueller Korrekturen und der Anteil nicht eindeutig klassifizierbarer Anfragen.

Ein erfolgreicher Einsatz setzt voraus, dass Zuständigkeiten, Kategorien und Weiterleitungsregeln eindeutig beschrieben sind. Die Automatisierung darf unklare organisatorische Verantwortlichkeiten nicht lediglich technisch abbilden.

Betriebs- und Zustandsdaten technischer Anlagen werden ausgewertet, um tatsächlichen Wartungs- oder Instandsetzungsbedarf früher und nachvollziehbarer zu erkennen. Ziel ist es, Maßnahmen nicht ausschließlich nach festen Zeitintervallen, sondern ergänzend nach erkennbaren Zustandsentwicklungen zu priorisieren.

Der Pilot sollte für ausgewählte Anlagen mit ausreichender Datenqualität durchgeführt werden. Bewertet werden die Erkennbarkeit relevanter Abweichungen, die Verlässlichkeit der Daten, die Qualität der daraus abgeleiteten Maßnahmen und der Einfluss auf die technische Verfügbarkeit.

Die fachliche Bewertung durch das Anlagenmanagement bleibt erforderlich. Datenbasierte Hinweise unterstützen die Priorisierung, ersetzen aber nicht die technische Beurteilung und Freigabe notwendiger Maßnahmen.

Belegungs- und Nutzungsdaten werden ausgewertet, um die tatsächliche Nutzung vorhandener Flächen sichtbar zu machen. Dadurch kann das Management erkennen, welche Arbeits-, Besprechungs-, Service- oder Unterstützungsflächen regelmäßig, unregelmäßig oder nur eingeschränkt genutzt werden.

Der Pilot muss klar festlegen, welche Flächen betrachtet werden, über welchen Zeitraum die Auswertung erfolgt und wie die Ergebnisse interpretiert werden. Einzelne Tage oder kurzfristige Besonderheiten dürfen nicht ohne weitere Prüfung als dauerhafter Nutzungstrend bewertet werden.

Die Ergebnisse unterstützen Entscheidungen über Flächenanpassungen. Sie ersetzen jedoch nicht die Berücksichtigung betrieblicher Anforderungen, geplanter Veränderungen und der unterschiedlichen Funktionen einzelner Flächen.

Betriebsdaten werden genutzt, um Anlagenzeiten und technische Einstellungen bedarfsgerechter anzupassen. Betrachtet werden können beispielsweise Betriebszeiten, tatsächliche Nutzung und erkennbare Abweichungen zwischen Bedarf und Anlagenbetrieb.

Im Pilotprojekt werden Ausgangszustand, vorgesehene Einstellungen und zulässige Betriebsgrenzen dokumentiert. Bewertet werden die Verbrauchsentwicklung, die technische Betriebsqualität und mögliche Auswirkungen auf die Gebäudenutzung.

Eine erfolgreiche Optimierung muss dauerhaft stabil betrieben werden können. Veränderungen sind nachvollziehbar zu dokumentieren, damit bei Abweichungen oder Beschwerden eine fachliche Prüfung und erforderlichenfalls eine Rücknahme der Einstellungen möglich ist.

Die Rollen müssen für jedes Projekt konkret benannt werden. Eine allgemeine Beteiligung eines Partners ersetzt keine eindeutige Verantwortung für Arbeitsergebnisse, Freigaben oder betriebliche Entscheidungen.

Vor Projektbeginn werden Leistungsumfang, Verantwortlichkeiten, Datenbereitstellung, Schnittstellen, Termine, erwartete Ergebnisse und Übergabekriterien vereinbart.

Dabei muss eindeutig geregelt sein:

• Welche Leistungen intern und extern erbracht werden

• Wer Daten und Dokumente bereitstellt

• Wer Ergebnisse fachlich prüft

• Welche technischen Schnittstellen benötigt werden

• Wie Änderungen am Projektumfang behandelt werden

• Welche Dokumentation am Projektende vorliegen muss

• Welche Leistungen nach dem Pilotende erforderlich sind

• Unter welchen Bedingungen eine Lösung beendet oder übergeben wird

Partnerlösungen müssen in die bestehende FM-Prozesslandschaft integrierbar sein. Eine technisch eigenständige Anwendung ohne geregelte Einbindung in Verantwortlichkeiten, Datenpflege und Support ist nicht ausreichend.

Auch die Abhängigkeit von einzelnen Partnern ist zu bewerten. Wissen über Konfiguration, Funktionsweise und betriebliche Nutzung sollte so dokumentiert werden, dass das Finanzinstitut Entscheidungen nachvollziehen und den Betrieb angemessen steuern kann.

Regelmäßige Projektberichte informieren über Fortschritt, offene Entscheidungen, Kostenentwicklung, Testergebnisse, Risiken und Abweichungen. Die Berichte müssen sich an den festgelegten Zielen und Erfolgskriterien orientieren.

Änderungen am Pilotumfang werden dokumentiert und freigegeben. Dies ist besonders wichtig, wenn während des Projekts zusätzliche Funktionen, Nutzergruppen oder Datenquellen aufgenommen werden sollen. Ohne geregeltes Änderungsverfahren besteht das Risiko, dass Ergebnisse nicht mehr mit dem ursprünglich genehmigten Pilotkonzept vergleichbar sind.

In gemeinsamen Steuerungsterminen werden mindestens folgende Punkte behandelt:

• Aktueller Projektstatus

• Erreichte Meilensteine

• Offene Aufgaben und Verantwortlichkeiten

• Abweichungen bei Terminen oder Kosten

• Qualität der bisherigen Testergebnisse

• Erforderliche Entscheidungen

• Nächste Projektphase und Freigabevoraussetzungen

Ein Pilotprojekt wird auf einen Standort, einen Prozess, einen Gebäudebereich, einen Anlagentyp oder eine definierte Nutzergruppe begrenzt. Die Abgrenzung muss so gewählt werden, dass die Lösung unter realen Bedingungen getestet werden kann, ohne bereits eine vollständige Einführung vorwegzunehmen.

Ein zu kleiner Pilot liefert möglicherweise keine belastbaren Ergebnisse. Ein zu großer Pilot erhöht dagegen Aufwand, Kosten und betriebliche Risiken. Der Pilotbereich sollte deshalb repräsentativ, fachlich beherrschbar und anhand der festgelegten Kriterien messbar sein.

Vor Beginn ist außerdem der Ausgangszustand zu dokumentieren. Nur wenn Bearbeitungszeiten, Kosten, Fehlerquoten oder andere relevante Werte vor der Einführung bekannt sind, kann die erzielte Veränderung zuverlässig bewertet werden.

Der Pilotsteckbrief ist vor der Projektfreigabe vollständig abzustimmen. Änderungen während der Durchführung müssen nachvollziehbar dokumentiert werden.

Die Skalierung erfolgt nur, wenn die Lösung fachlich funktioniert, einen belegbaren Nutzen erreicht und dauerhaft betrieben werden kann. Ein positiver technischer Test allein ist nicht ausreichend.

Vor einem Rollout müssen mindestens folgende Voraussetzungen erfüllt sein:

• Nachweisbare Erfüllung der wesentlichen Erfolgskriterien

• Dokumentierte Erkenntnisse und Korrekturen aus dem Pilotprojekt

• Definierte technische und organisatorische Standards

• Geregelter Support und klare Systemverantwortung

• Ausreichende Ressourcen für Einführung und Betrieb

• Vorbereitete Anwenderschulungen

• Geklärte System- und Prozessintegration

• Vollständige Betriebs- und Anwenderdokumentation

• Festgelegte Verfahren für Datenpflege und Weiterentwicklung

Bei der Skalierung ist zu prüfen, welche Bestandteile des Piloten standardisiert übernommen werden können und welche standort- oder prozessspezifischen Anpassungen erforderlich sind. Eine unveränderte Übertragung ist nicht automatisch sinnvoll.

Der Rollout kann schrittweise erfolgen. Dadurch lassen sich Erkenntnisse aus den ersten Übertragungen nutzen, bevor weitere Standorte oder Nutzergruppen einbezogen werden.

Die Wirtschaftlichkeitsbewertung sollte sowohl quantifizierbare als auch qualitative Nutzenbestandteile berücksichtigen. Zeit- und Kosteneinsparungen können häufig direkt gemessen werden. Verbesserungen bei Wissensqualität, Zusammenarbeit oder Transparenz müssen dagegen anhand nachvollziehbarer Bewertungskriterien beschrieben werden.

Ausgangswerte und erwartete Zielwerte sind vor der Pilotierung festzulegen. Nach Abschluss werden die tatsächlichen Ergebnisse mit diesen Annahmen verglichen. Abweichungen müssen erläutert und bei einer möglichen Skalierungsentscheidung berücksichtigt werden.

Die Bewertung berücksichtigt nicht nur die unmittelbar sichtbaren Pilotkosten. Einzubeziehen sind auch laufende Aufwände für Lizenzen, Support, Datenpflege, technische Integration, Anwenderschulungen, Dokumentation und Weiterentwicklung.

Gleichzeitig darf der Nutzen nicht ausschließlich auf den Pilotbereich begrenzt betrachtet werden. Bei einer skalierbaren Lösung ist zu prüfen, wie sich Nutzen und Kosten bei der Übertragung auf weitere Gebäude, Prozesse oder Standorte entwickeln.

Für die Managemententscheidung sollten mindestens drei Betrachtungen vorliegen:

• Aufwand und Nutzen des Pilotprojekts

• Erwarteter Aufwand und Nutzen der Einführung

• Laufender Aufwand und Nutzen im Regelbetrieb

Dadurch wird vermieden, dass eine Lösung aufgrund niedriger Pilotkosten positiv bewertet wird, obwohl ihre späteren Betriebs- oder Pflegekosten unverhältnismäßig hoch sind.

Kennzahlen müssen einheitlich definiert werden. Beispielsweise ist festzulegen, wann eine Idee als geprüft gilt, welche Voraussetzungen für einen erfolgreichen Pilot erfüllt sein müssen und ab welchem Zeitpunkt ein Projekt als an den Regelbetrieb übergeben zählt.

Die reine Anzahl von Projekten ist kein ausreichender Erfolgsnachweis. Ein umfangreiches Innovationsportfolio kann bei fehlenden Entscheidungen, wiederholten Verzögerungen oder geringer Übergabequote auf unzureichende Steuerung hinweisen.

Das Management-Dashboard zeigt Projektstatus, Investitionsbedarf, erwarteten Nutzen, bereits erreichte Ergebnisse und anstehende Entscheidungen in kompakter Form.

Eine Ampeldarstellung kann Projekte nach folgenden Kriterien unterscheiden:

• Zielerreichung

• Terminlage

• Kostenentwicklung

• Ressourcenverfügbarkeit

• Qualität der Testergebnisse

• Freigabestatus

• Betriebs- und Skalierungsfähigkeit

Grün kennzeichnet einen planmäßigen Verlauf ohne wesentliche Abweichungen. Gelb weist auf Risiken oder Entscheidungsbedarf hin. Rot zeigt wesentliche Zielabweichungen, fehlende Voraussetzungen oder einen möglichen Projektabbruch an.

Jede Ampelbewertung muss durch eine kurze Begründung und eine konkrete Maßnahme ergänzt werden. Eine farbliche Kennzeichnung ohne Handlungsbezug ist für die Managementsteuerung nicht ausreichend.

Das Dashboard sollte außerdem erkennen lassen, welche Entscheidungen bis zum nächsten Berichtstermin erforderlich sind und welche Auswirkungen eine Verzögerung auf Kosten, Termine oder Projektnutzen hätte.

Die Roadmap verbindet die einzelnen Innovationsvorhaben mit einem zeitlichen Gesamtbild. Sie zeigt, welche Projekte vorbereitet, pilotiert, skaliert oder in den Regelbetrieb übergeben werden sollen.

Abhängigkeiten zwischen Projekten müssen sichtbar gemacht werden. Ein Wissensmanagementprojekt kann beispielsweise von einer vorherigen Bereinigung und Strukturierung des Dokumentenbestands abhängen. Eine datenbasierte Instandhaltungsplanung benötigt gegebenenfalls zunächst ausreichend verfügbare und verlässliche Betriebsdaten.

Die Roadmap muss deshalb nicht nur geplante Start- und Endtermine enthalten. Sie sollte auch Meilensteine, Entscheidungspunkte, Ressourcenbedarf und wesentliche Voraussetzungen darstellen.

Die Innovationsroadmap wird regelmäßig anhand der Projektergebnisse, Managemententscheidungen und aktuellen betrieblichen Anforderungen aktualisiert.

Beendete, zurückgestellte und neu aufgenommene Projekte bleiben mit ihrem jeweiligen Entscheidungsstatus nachvollziehbar dokumentiert. Dadurch wird verhindert, dass bereits geprüfte und abgelehnte Ideen ohne veränderte Voraussetzungen erneut gestartet werden.

Bei jeder Fortschreibung sind insbesondere folgende Fragen zu prüfen:

• Haben sich betriebliche Prioritäten verändert?

• Wurden Erfolgskriterien laufender Projekte erreicht?

• Sind neue Abhängigkeiten oder Ressourcenengpässe entstanden?

• Welche Pilotlösungen sind bereit für die Skalierung?

• Welche Vorhaben müssen angepasst, zurückgestellt oder beendet werden?

• Welche Lösungen wurden vollständig in den Regelbetrieb übergeben?

Die aktualisierte Roadmap bildet gemeinsam mit dem Innovationsportfolio und dem Management-Dashboard die Grundlage für die weitere Steuerung der FM-Innovationen.