CAFM: Pilotierung/Proof of Concept

Was unterscheidet eine Pilotphase von der kompletten Systemeinführung? Im Wesentlichen sind es Umfang, Risiko und Zielsetzung. Die Pilotierung ist ein begrenzter Probelauf, während die vollständige Einführung den flächendeckenden Rollout bedeutet.

• Pilot-Einführung (schrittweises Vorgehen): Eine Pilotphase beschränkt sich auf einen kontrollierten Umfang – z.B. ein einzelnes Objekt, einen Standort oder eine Abteilung. Hier wird ein Minimum Viable Product (MVP) der CAFM-Lösung mit Kernfunktionen implementiert und von einem ausgewählten Nutzerkreis getestet. Vorteile dieses Ansatzes sind eine reduzierte Risikoexposition und die Möglichkeit, in agilen Iterationen Verbesserungen und Anpassungen vorzunehmen. Auftretende Probleme betreffen nur den Pilotbereich und können behoben werden, bevor mehr Benutzer betroffen sind. Der Hauptnachteil ist, dass die Gesamteinführung länger dauert, da erst nach Abschluss des Piloten auf alle Bereiche ausgerollt wird.

• Vollständige Einführung („Big Bang“): Hier wird das System auf einen Schlag im gesamten Unternehmen live geschaltet. Alle vorgesehenen Module und alle Nutzer gehen zeitgleich produktiv. Dies kann die Implementierungszeit insgesamt verkürzen, birgt jedoch hohe Risiken: Treten ungeahnte Probleme oder Softwarefehler auf, sind alle Prozesse betroffen. Die Anforderungen an Test und Vorbereitung sind deshalb enorm, um keine kritischen Fehler im Go-Live zu haben. Ein Big-Bang-Rollout erfordert auch erheblichen Koordinationsaufwand (z.B. Schulung aller Mitarbeiter im Vorfeld). Viele Unternehmen bevorzugen daher eine Pilotierung oder schrittweise Einführung, um das Risiko besser zu managen.

In der Praxis hat sich gezeigt, dass phasenweises Rollout durch Pilotierung meist erfolgreicher ist, da es agile Qualitätsverbesserungen erlaubt und Probleme frühzeitig aufdeckt. Die vollständige Einführung erfolgt dann erst nach dem Pilot, basierend auf den dort gewonnenen Erkenntnissen. Dennoch ist zu beachten, dass eine Pilotphase Zeit und Ressourcen kostet und daher im Projektplan bewusst eingeplant werden muss – die Einführung insgesamt dauert etwas länger, dafür aber mit deutlich geringerem Risiko eines Fehlschlags.

Die Wahl des richtigen Pilotbereichs ist kritisch für aussagekräftige Ergebnisse. Ein Pilot sollte repräsentativ sein für die später breite Nutzung, aber dennoch überschaubar genug, um kontrolliert durchgeführt zu werden.

• Repräsentatives Objekt: Wählen Sie ein Gebäude, Liegenschaftsteil oder eine Abteilung, die stellvertretend für die anstehenden CAFM-Aufgaben steht. Der Pilotbereich sollte möglichst viele der Kernprozesse beinhalten (z.B. Instandhaltung, Raumbuchung, Reinigungsmanagement), damit der Test die Realität abbildet. So werden Erkenntnisse gewonnen, die auf andere Bereiche übertragbar sind. Im kommunalen Umfeld kann dies z.B. ein exemplarisches Verwaltungsgebäude sein; im Unternehmen vielleicht der Hauptsitz oder ein typischer Standort mittlerer Größe. Wichtig ist, dass der Pilot nicht auf extremen Sonderfällen basiert, da sonst entweder unnötig viel Komplexität einfließt oder umgekehrt Erfolgsfaktoren übersehen werden, die erst in regulären Objekten auftauchen.

• Daten- und Systembasis: Achten Sie auf einen Pilotbereich, in dem die Datenlage halbwegs ordentlich ist. Ein Objekt, für das bereits vergleichsweise gute Bestandsdaten (Pläne, Anlagenlisten etc.) vorliegen, erleichtert den Start. So kann der Fokus auf die Systemnutzung statt auf aufwändige Datenerfassung gelegt werden. Auch sollte die vorhandene IT-Infrastruktur (Netzwerk, Endgeräte) im Pilotbereich repräsentativ sein – etwa wenn in der Fläche Tablets eingesetzt werden sollen, sollte dies im Pilotbereich bereits möglich sein.

• Motivation und Unterstützung vor Ort: Die Auswahl sollte ebenfalls berücksichtigen, wo es aufgeschlossene Stakeholder gibt. Ein Bereich mit engagierten Mitarbeitern, die offen für neue Lösungen sind, eignet sich besser, da hier Feedback und aktive Mitarbeit wahrscheinlicher sind. Idealerweise hat der Pilotbereich einen lokalen Verantwortlichen (z.B. Objektleiter oder Abteilungsleiter), der das Projekt unterstützt und als Change Champion fungiert. Dieser kann das Team motivieren und zwischen Projektteam und Endanwendern vermitteln.

• Größe und Komplexität: Der Pilot sollte überschaubar bleiben. Bei großen Organisationen wählt man oft ein Beispielgebäude aus, an dem das System zuerst getestet wird. Dieses Objekt sollte groß genug sein, um typische Herausforderungen zu zeigen, aber nicht so groß, dass die Pilotphase uferlos wird. Häufig bewährt sich ein mittlerer Umfang, der innerhalb von wenigen Monaten bearbeitet werden kann (z.B. ein Gebäudekomplex mit einigen hundert Räumen und typischen gebäudetechnischen Anlagen). Bei sehr kleinen Pilotszenarien besteht die Gefahr, dass wichtige Funktionen ungetestet bleiben; bei zu großen Piloten drohen Überlastung und lange Dauer.

Realistisch und praxisnah auswählen, sodass der Pilot machbare Ziele hat und gleichzeitig relevante Ergebnisse liefert. Alle in der späteren Einführung beteiligten Fachbereiche sollten sich im Pilotobjekt zumindest teilweise wiederfinden. So wird sichergestellt, dass Änderungen, Probleme und Erkenntnisse aus der Pilotphase für das Gesamtprojekt gültig sind – diese werden dokumentiert und anschließend auf die Gesamtorganisation übertragen.

In einem CAFM-Pilotprojekt konzentriert man sich auf ausgewählte Inhalte (fachliche Themen) und technische Aspekte, um die wichtigsten Erfolgsfaktoren zu prüfen.

• Prozesse und Funktionen: Zunächst werden zentrale Geschäftsprozesse des Facility Managements im System abgebildet und erprobt. Beispielsweise kann man die Arbeitsauftragserfassung und -abwicklung testen, Wartungsplanungsprozesse durchspielen oder Buchungen von Räumen und Ressourcen simulieren. Es sollten diejenigen Module/Funktionen konfiguriert werden, die in der ersten Einführungsphase relevant sind. Dabei gilt es, nicht alles auf einmal umzusetzen, sondern einen realistischen Funktionsumfang auszuwählen – Kernmodule zuerst, optionale Features später. Die Fachkonzepte (z.B. Prüfintervalle in der Instandhaltung, Workflow für Ticketbearbeitung) werden im Pilot praktisch verifiziert.

• Schnittstellen zu anderen Systemen: Ein wesentlicher technischer Schwerpunkt liegt auf den Integrationen. In der Pilotierung werden die Schnittstellen zu bestehenden IT-Systemen eingerichtet und getestet – etwa der Import von Stammdaten aus dem ERP, der Abgleich von Personaldaten mit HR-Systemen oder die Anbindung an ein Gebäudeleittechnik-System. Hier zeigt sich, ob die Datenflüsse reibungslos funktionieren und wo ggf. Konvertierungen oder Anpassungen nötig sind. Best Practice ist, alle kritischen Schnittstellen bereits im Pilot aufzusetzen und zu prüfen, um spätere Überraschungen zu vermeiden. Gerade bei CAFM ist die nahtlose Integration wichtig, um Doppelarbeit zu verhindern und konsistente Daten sicherzustellen.

• Datenmigration und -qualität: Die Pilotphase umfasst oft eine Testmigration von Daten. Dabei wird ein Ausschnitt des vorhandenen Datenbestands (z.B. die Anlagenliste eines Gebäudes, Flächendaten eines Stockwerks) ins neue System übernommen. Dieser Pilotimport dient zweierlei: Zum einen erkennt man Datenqualitätsprobleme frühzeitig (fehlende oder fehlerhafte Datenfelder, unterschiedliche Formate etc.), zum anderen kann das Team den Migrationsprozess (ETL-Skripte, Zuordnungen) erproben. Es empfiehlt sich, eine Pilot-Datenmigration mit einem kleinen Datenvolumen durchzuführen, um den Ablauf zu validieren, bevor die Gesamtmigration startet. Zudem wird der Umfang der nachzupflegenden Daten ermittelt – im Pilot zeigt sich oft, welche Informationen noch digitalisiert oder bereinigt werden müssen.

• Technische Infrastruktur & Performance: Auch technisch-operative Aspekte stehen im Fokus: Läuft das System stabil in der vorgesehenen Umgebung (Server, Netzwerk)? Müssen Anpassungen an der IT-Infrastruktur vorgenommen werden (z.B. VPN-Zugriff für externe Dienstleister, mobile Endgeräte für Hausmeister mit der App)? Ebenso kann im Pilot ein Belastungstest im kleinen Rahmen erfolgen, um die Performance zu beobachten. Zwar ist die Nutzerzahl begrenzt, aber man gewinnt Einblicke, wie das System reagiert, z.B. wenn mehrere parallele Anfragen laufen. Damit lassen sich Skalierungsfragen für den Echtbetrieb abschätzen.

• Benutzerrollen und Berechtigungen: In der Pilotierung wird typischerweise mit echten Endanwendern gearbeitet (z.B. einigen Technikern, Sachbearbeitern, Dienstleistern). Daher müssen im System Rollen, Rechte und Workflows eingerichtet werden. Die in Workshops theoretisch definierten Rollenmodelle (wer darf was sehen/tun) werden im Pilot praktisch umgesetzt. Hier zeigt sich, ob die Rechtekonzepte praktikabel sind oder ob Anpassungen nötig sind, damit die Pilot-User ihre Aufgaben erledigen können. Auch Self-Service-Funktionen (Mitarbeiter melden Störungen selbst) können im kleinen Kreis getestet werden.

Es konzentriert sich der PoC auf die wichtigsten Funktionen im Zusammenspiel mit echten Daten und Prozessen. Er deckt sowohl fachliche Abläufe als auch technische Integrationen ab. Dabei ist Abgrenzung wichtig: nicht jeder Nice-to-have-Prozess wird schon im Pilot berücksichtigt, wohl aber alle kritischen Muss-Anforderungen. Dieses konzentrierte Vorgehen stellt sicher, dass der Pilot handhabbar bleibt und dennoch alle wesentlichen Erfolgsfaktoren beleuchtet.

Die Pilotphase muss im Gesamtprojektplan klar definiert und mit Ressourcen hinterlegt werden. Zeitlich ist ein Pilot meist im Bereich einiger Monate angesiedelt – je nach Projektgröße und Komplexität.

• Phasenplanung: Üblicherweise wird das Projekt in Phasen gegliedert, z.B. Konzeption, Auswahl, Implementierung (Pilot), Rollout. Die Pilotphase bildet dabei eine eigenständige Projektetappe mit Anfang und Ende. Bereits in der Grobplanung sollte ein Zeitfenster für den Pilot eingeplant sein, inklusive Puffer für Nacharbeiten und Auswertung. Entscheidend ist, dass vor dem Pilot alle Vorarbeiten (Anforderungsanalyse, Systemauswahl, Vertragliches) erledigt sind, damit der Pilot konzentriert stattfinden kann.

• Dauer der Pilotphase: Die Länge eines Piloten variiert. Laut einer Untersuchung an Hochschulen waren 53 % der CAFM-Pilotprojekte nach wenigen Monaten abgeschlossen, 17 % dauerten bis zu einem Jahr und 22 % sogar bis zu zwei Jahre. Diese Bandbreite zeigt: komplexe Projekte können lange Piloten erfordern, während bei guter Vorbereitung ein Pilot auch in ~3 Monaten machbar ist. In der Praxis gängige Größenordnung für einen Pilot in einem überschaubaren Bereich sind 2–4 Monate. Kleinere Proof-of-Concept-Studien (z.B. Technologietests) können sogar in 4–6 Wochen abgeschlossen werden. Wichtig ist, realistische Zeitziele zu setzen: genügend Zeit, um das System solide auszuprobieren, aber auch nicht so lang, dass die Pilotdynamik verloren geht. Eine zu lange Pilotphase kann zu “Projektmüdigkeit” führen – daher klare Dauer definieren und diese kommunizieren.

• Aufwandsabschätzung: Neben der reinen Kalenderzeit muss der Ressourcenaufwand geplant werden. Ein Pilot benötigt ein dediziertes Team (Projektleiter, Key User, ggf. externe Berater) mit eingeplanten Arbeitskapazitäten. Es fallen Aufwände an für Systemkonfiguration, Datenaufbereitung, Tests, Schulungen, regelmäßige Abstimmungen und die Dokumentation der Ergebnisse. Oft wird der Aufwand für die Datenaufbereitung unterschätzt – im Pilot zeigt sich, dass erheblich Zeit in die Bereinigung und Strukturierung von Bestandsdaten fließen kann. Dies sollte in der Planung berücksichtigt und als eigener Task verankert werden. Ebenso sind Puffer vorzusehen für unvorhergesehene Probleme (z.B. ein Schnittstellenproblem, das zusätzliches Coding erfordert).

• Milestone-Planung: Zur Steuerung ist es sinnvoll, innerhalb der Pilotphase Meilensteine zu definieren – z.B. „Pilot-System konfiguriert“ (Start UAT), „Dateneinspielung abgeschlossen“, „Pilot-Betrieb gestartet“, „Pilot-Abschlussbericht vorliegend“. An diesen Punkten sollten Reviews mit Stakeholdern stattfinden, um den Fortschritt zu prüfen. So kann man bei Verzögerungen früh reagieren oder den Umfang justieren. Die Meilensteine geben auch dem Team klare Etappenziele und halten den Zeitplan auf Kurs.

(Die obigen Werte sind Richtgrößen; tatsächliche Projekte können je nach Umfang abweichen.)

Zusätzlich zur Zeit ist der Kostenaufwand abzuschätzen. Für die Pilotphase fallen oft Lizenz-/Nutzungskosten für Testumgebungen an, Kosten für externe Unterstützung (z.B. Dienstleister für Implementierung) und interne Personalkosten durch die Projektmitarbeiter. Diese sollten im Projektbudget explizit ausgewiesen werden. Auch hier hilft die Pilotphase selbst: Sie liefert Erkenntnisse, ob ursprüngliche Aufwandsschätzungen zutrafen oder angepasst werden müssen, bevor man in die breite Ausrollung geht.

Eine CAFM-Einführung ist kein rein technisches Projekt, sondern ein organisationsübergreifendes Veränderungsvorhaben. Entsprechend ist die Einbindung aller relevanten Stakeholder und Key User in der Pilotphase ein Schlüsselfaktor für den Projekterfolg.

• Projekt-Sponsor und Top-Management: Die Unterstützung durch die Führungsebene muss von Anfang an sichergestellt sein. Das Management sollte das Projekt aktiv mittragen, da es oft um strategische Ziele geht (Kostenreduktion, Qualitätsverbesserung, Mitarbeiterzufriedenheit). Ein beteiligtes Top-Management kann etwa durch regelmäßige Lenkungsausschuss-Meetings informiert bleiben und wichtige Entscheidungen (Freigaben, Ressourcen) treffen. Zudem signalisiert sichtbares Management-Engagement den Mitarbeitern die Wichtigkeit des Projekts. Nicht zuletzt stellt die Leitungsebene die nötigen finanziellen und personellen Ressourcen bereit und räumt Hindernisse aus dem Weg.

• Projektteam und Fachabteilungen: Ein interdisziplinäres Projektteam sollte verschiedene Abteilungen abdecken – typischerweise technisches, infrastrukturelles und kaufmännisches Facility Management sowie die IT-Abteilung. Dieses Kernteam plant und steuert den Pilot. Wichtig ist, dass Know-how-Träger aus den Fachabteilungen beteiligt sind, damit Praxiswissen einfließt. Sie fungieren als Vertreter ihrer Bereiche (z.B. Instandhaltung, Reinigung, Flächenmanagement) und stellen sicher, dass die jeweils wichtigsten Anforderungen im Pilot berücksichtigt werden. Auch externe Berater können im Team sein, um methodisch zu unterstützen. Im Pilotbetrieb selbst können zudem Dienstleister (z.B. Wartungsfirmen) einbezogen werden, falls diese später das System nutzen sollen (z.B. via Web-Portal).

• Key User (Schlüsselanwender): Dabei handelt es sich um ausgewählte Anwender aus den jeweiligen Bereichen, die besonders intensiv in die Pilotphase eingebunden werden. Key User testen die neuen Funktionen im Tagesgeschäft und geben Feedback aus erster Hand. Ihre frühzeitige Einbindung sorgt dafür, dass praktische Anforderungen erkannt und angenommen werden. Sie agieren auch als Multiplikatoren: Ein gut informierter Key User kann in seinem Umfeld Kolleginnen schulen und vom Nutzen der Software überzeugen. Es empfiehlt sich, pro Fachbereich einen oder mehrere Key User zu benennen und diese auch speziell zu schulen, damit sie im Pilot sicher agieren können. Laut Best Practice ist es ratsam, in jedem Bereich solche internen „Champions“* aufzubauen, die das System intern evangelisieren. Diese Key User sollten genügend Zeit für das Projekt haben und durch ihre Vorgesetzten dafür freigestellt werden.

• Endanwender und betroffene Mitarbeiter: Neben den Key Usern sollten auch die späteren Endnutzer zumindest informiert und punktuell einbezogen werden. Kommunikation ist hier das Stichwort: Alle betroffenen Mitarbeiter müssen frühzeitig mitgenommen werden, um Akzeptanz zu schaffen. Dies kann durch Informationsveranstaltungen, Newsletter oder Demo-Sessions geschehen. In manchen Fällen werden ausgewählte Endanwender in Pilot-Workshops eingeladen, um ihre Perspektive einzubringen. Das Ziel ist, mögliche Vorbehalte abzubauen und Change Management zu betreiben. Gerade im Facility Management ist es wichtig zu vermitteln, welche Vorteile das neue System für die tägliche Arbeit bringt (z.B. weniger manuelle Listen, schnellere Auskunftsfähigkeit). Mitarbeiter, die verstehen, warum die Veränderung passiert, sind eher gewillt, im Pilot mitzuwirken.

Die Pilotphase sollte nicht im stillen Kämmerlein der IT stattfinden, sondern unter Beteiligung aller relevanten Stakeholder. Ein partnerschaftlicher Einbezug aller Beteiligten fördert die Transparenz und Akzeptanz. Erfolgsfaktoren sind u.a. regelmäßige Abstimmungen mit den Stakeholdern, klare Verantwortlichkeiten im Team und offen kommunizierte Zwischenergebnisse. So entsteht das Gefühl eines gemeinsamen Projekts statt einer von oben verordneten Softwareeinführung.

Am Ende der Pilotphase muss bewertet werden, ob diese als erfolgreich gilt und ob das Projekt in den breiten Rollout gehen kann. Es empfiehlt sich, vorab klare Erfolgskriterien festzulegen, um die Pilot-Ergebnisse objektiv messen zu können.

• Fachliche Kriterien: Diese betreffen die inhaltlichen Ziele des Systems. Beispielsweise kann gemessen werden, inwieweit Prozessverbesserungen erreicht wurden. Konkrete KPIs könnten sein: Bearbeitungszeit von Instandhaltungsaufträgen (ist diese im Pilot gesunken?), Reaktionszeiten auf Störmeldungen, Transparenz der Kostenerfassung oder Datenqualität. Wenn etwa das Ziel war, Wartungspläne effizienter zu steuern, könnte ein Kriterium sein: „100% der geplanten Wartungen wurden fristgerecht über das System abgewickelt“. Oder im Raum- und Reservierungsmanagement: „Reduktion der Doppelbuchungen auf Null“. Key Performance Indicators (KPIs) aus dem operativen Betrieb helfen bei der Bewertung – z.B. Vergleich von Durchlaufzeiten oder Rückständen vor und nach Pilot. Fachlich gilt der Pilot als Erfolg, wenn die gewünschten Funktionen vom Fachbereich akzeptiert und verwendet werden und spürbare Verbesserungen oder zumindest Gleichstand gegenüber dem alten Vorgehen erreicht wurden.

• Technische Kriterien: Hier geht es um die IT-Seite des Projekts. Ein erfolgreiches Pilotprojekt sollte zeigen, dass das System stabil und performant läuft (keine gravierenden Abstürze, akzeptable Antwortzeiten im Netz). Ebenso wichtig: Die Schnittstellen funktionieren zuverlässig – z.B. werden automatisch alle relevanten Daten zwischen CAFM und ERP ausgetauscht, ohne Fehler. Ein weiteres Kriterium ist die Datenmigration: Sind die Pilot-Daten vollständig und korrekt im neuen System angekommen? (Dies lässt sich durch Abgleiche mit Altdaten prüfen). Technisch erfolgreich ist der Pilot auch, wenn das System von der Infrastruktur her passt – z.B. wenn Testnutzer auf mobilen Geräten oder via Web-Zugang problemlos arbeiten konnten (falls vorgesehen). Zudem kann man Sicherheitsaspekte bewerten: greift das Berechtigungs- und Rollenkonzept, sind keine unautorisierten Zugriffe möglich etc. Erfolgreich bedeutet, dass keine kritischen technischen Mängel verbleiben, die einem Rollout im Wege stünden. Kleinere Bugs können protokolliert und für den Feinschliff eingeplant werden, aber es darf nichts Grundlegendes mehr offen sein (z.B. unstabile Kernfunktion).

• Organisatorische Kriterien: Diese beziehen sich auf Akzeptanz, Schulung und Betrieb. Ein Kriterium ist z.B. die Nutzerakzeptanz: Lassen sich die Key User und Pilot-Anwender das System gern und korrekt nutzen? Dies kann qualitativ durch Feedback-Runden oder quantitativ durch Nutzungsstatistiken erfasst werden (Logins pro Tag, erfasste Tickets vs. Papiermeldungen etc.). Wenn etwa trotz System noch alle Störungen per Telefon gemeldet werden, wäre die Akzeptanz gering. Positivzeichen wären, wenn Pilotnutzer berichten, dass das System ihre Arbeit erleichtert. Organisatorisch wichtig ist auch, dass Schulungen wirksam waren – wurden die Anwender ausreichend befähigt? Man könnte kleine Wissenstests oder beobachtete Benutzeraktionen bewerten. Ein anderes Kriterium: Änderungsbereitschaft der Organisation – tragen die beteiligten Führungskräfte die Prozessänderungen mit, wurden Verantwortlichkeiten geklärt (z.B. wer pflegt künftig die Daten)? Schließlich gehört auch die Betriebsorganisation dazu: Ist geklärt, wer das System administriert, wer Support leistet? Ein Pilot ist organisatorisch gelungen, wenn alle nötigen Rollen besetzt und akzeptiert sind (z.B. ein CAFM-Manager als zukünftiger Systemverantwortlicher) und wenn die Nutzer bereit sind, in den Echtbetrieb zu gehen. Auch sollte evaluiert werden, ob die angestrebten wirtschaftlichen Nutzen im Kleinen sichtbar wurden (z.B. Zeitersparnis, geringere Fehlerquote) – das untermauert intern die Entscheidung für den Rollout.

Wo immer möglich, sollten die Erfolgskriterien messbar sein (SMART). Manche Kriterien sind quantitativ (KPIs, Zahlen) und lassen sich in Berichten aus dem System oder per Zeitmessung feststellen. Andere sind qualitativer Natur (Zufriedenheit, Usability) – hier bieten sich Umfragen oder strukturierte Interviews mit den Pilot-Usern an. Beispielsweise kann man am Pilotende einen kurzen Fragebogen verteilen: „Wie bewerten Sie das neue System insgesamt? Was lief gut/schlecht?“. Auch Workshops „Lessons Learned“ (s. unten) liefern Indikatoren.

Letztlich sollte am Pilotende ein Abschlussbericht erstellt werden, der die vordefinierten Kriterien fachlich, technisch, organisatorisch durchgeht und bewertet („Kriterium erfüllt / teilweise erfüllt / nicht erfüllt – Begründung – ggf. Maßnahme für Rollout“). Die klare Definition dieser Kriterien im Vorfeld schützt vor Bauchentscheidungen. Sie stellt sicher, dass die Entscheidung Go oder No-Go für die flächendeckende Einführung auf nachvollziehbaren Fakten basiert.

Für die Durchführung der Pilotphase ist ein strukturiertes methodisches Vorgehen zu empfehlen. Der Pilot sollte wie ein „Projekt im Kleinen“ aufgesetzt und gemanagt werden.

• Planung & Setup: Zu Beginn wird ein detaillierter Pilot-Plan erstellt. Darin werden Ziele, Umfang, Timeline (siehe Abschnitt 5) und Verantwortliche für die Pilotphase festgelegt. Es empfiehlt sich, gleich zu definieren, welche Daten und Prozesse im Pilot getestet werden und welche nicht – diese Abgrenzung steuert den Fokus. Ebenso sollte festgelegt werden, wie Ergebnisse erfasst werden (Dokumentationsformate) und wann Auswertungsmeetings stattfinden. Das Pilot-System wird aufgesetzt (separate Test- oder Pilot-Instanz), konfiguriert und die notwendigen Startdaten eingespielt. Bevor Nutzer rein dürfen, sollte das Projektteam intern einen Smoke-Test machen, um sicherzustellen, dass die wichtigsten Funktionen laufen.

• Protokollierung und Monitoring: Während der Pilotphase ist es wichtig, alle auftretenden Vorkommnisse systematisch zu protokollieren. Das umfasst Fehler, Änderungswünsche, Fragen der Nutzer, Performanceprobleme etc. Hierfür bietet sich ein Issue-Tracker oder ein einfaches Log-Dokument an, in dem jeder Fund mit Datum, Verantwortlichem und Bearbeitungsstatus festgehalten wird. Beispielsweise kann ein Protokollpunkt sein: „Schnittstelle HR -> CAFM: Mitarbeiter XY wird nicht übertragen – Fehlermeldung xyz (Ticket #12)“. Solche Beobachtungen werden unmittelbar im Pilot festgehalten. Ebenso sollten Änderungen/Einstellungen, die während des Pilots am System vorgenommen werden, dokumentiert werden (z.B. „25.05.: Workflow A angepasst, nun zusätzlicher Freigabeschritt durch Technikerleiter“). Diese Dokumentation stellt sicher, dass am Ende nichts unter den Teppich fällt und dient als Checkliste für die Behebung oder Übernahme ins Gesamtsystem. Das Pilotteam sollte tägliche/ wöchentliche kurze Abstimmungen einplanen, um den Stand zu synchronisieren („Daily Scrum“ Ansatz). Bei Bedarf können Zwischenergebnisse auch dem Lenkungsausschuss gemeldet werden.

• Einbindung von Feedback: Die Rückmeldungen der Pilotnutzer sind Gold wert. Eine Methode ist, regelmäßige Feedback-Runden einzuplanen – etwa wöchentlich ein kurzes Meeting mit den Key Usern: „Was lief gut? Wo hattet ihr Probleme? Vorschläge?“. Alternativ oder zusätzlich können Nutzer ihre Erfahrungen in einem einfachen Formular oder per Mail melden. Wichtig ist, eine offene Feedback-Kultur zu fördern – Nutzer sollen ehrlich sagen können, was hakt, ohne dass es als „Meckern“ ausgelegt wird. Das Projektteam wertet dieses Feedback aus und priorisiert es. Kleinere justierbare Punkte kann man direkt im Pilot ändern (z.B. Formularmasken anpassen, Berechtigungen erweitern). Größere Themen notiert man für die Nachsteuerung im Rollout. Die Nutzer sollten sehen, dass ihr Feedback gehört wird – z.B. durch Release-Notes: „Danke für euer Feedback, wir haben in Version 0.2 folgende Anpassungen gemacht ...“. Diese Iteration verbessert nicht nur das System, sondern steigert auch die Nutzerakzeptanz, weil die Anwender sich ernstgenommen fühlen.

• Zwischenevaluation: Bei längeren Pilotphasen kann es sinnvoll sein, nach der Hälfte eine kurze Zwischenauswertung zu machen. Das Projektteam prüft die bisherigen Ergebnisse gegen die Kriterien und entscheidet, ob Kurskorrekturen nötig sind. Ggf. wird der Pilotumfang angepasst (z.B. noch ein Modul zusätzlich testen, weil es gut läuft – oder einen Bereich weglassen, weil er Probleme macht). Auch kann man hier bereits über Sofortmaßnahmen entscheiden, falls gravierende Mängel auftauchen (z.B. zusätzliches Training ansetzen, Datenbereinigungskampagne starten). Ein solches Innehalten mit Review aller Stakeholder stellt sicher, dass der Pilot auf Erfolgskurs bleibt.

• Abschluss & Lessons Learned: Am Ende der Pilotphase erfolgt eine strukturierte Auswertung. Dazu gehört ein Abschlusstreffen mit allen Beteiligten (Projektteam, Key User, evtl. Management), in dem die Ergebnisse präsentiert werden. Hier sollten die vorab definierten Erfolgskriterien entlanggegangen werden (siehe Abschnitt 7) und gemeinsam festgestellt werden, ob sie erreicht wurden. Sehr hilfreich ist eine Lessons Learned-Sitzung: Welche Erfahrungen wurden gemacht? Was lief gut (beibehalten im Rollout), was lief schlecht (wie vermeiden)? Jede Stimme – vom Endbenutzer bis zum Entwickler – kann hier wertvolle Hinweise geben. Diese Erkenntnisse sind systematisch festzuhalten. Oft bietet sich an, einen Pilot-Abschlussbericht zu schreiben, der folgendes enthält: Pilotumfang, beteiligte Personen, Dauer, erreichte Ergebnisse je Kriterium, erkannte Probleme und empfohlene Lösungen, offene Punkte, Empfehlungen für die Gesamteinführung. Dieser Bericht wird dem Lenkungsausschuss/Management vorgelegt und bildet die Grundlage für die Entscheidung und Planung der nächsten Phase. Wichtig: Alle Änderungen, Probleme und Ereignisse aus der Pilotphase müssen dokumentiert und ausgewertet werden, damit sie in der Gesamteinführung berücksichtigt werden können. Nichts aus dem Pilot geht verloren – selbst wenn entschieden würde, das Projekt nicht fortzuführen, sind die Lessons Learned wertvolle Informationen (z.B. warum die Software nicht passte).

Es folgt die Methodik dem Prinzip: Plan – Do – Check – Act. Die Pilotierung wird geplant, in kontrolliertem Rahmen durchgeführt, kontinuierlich überwacht und nachbereitet. Dieses iterative Vorgehen reduziert die Projektrisiken erheblich und stellt sicher, dass der darauffolgende Rollout auf solidem Fundament aufbaut.

Gerade bei bereichsübergreifenden Projekten wie CAFM-Einführungen ist eine klare Governance wichtig – also wer entscheidet was, wer trägt welche Verantwortung – sowie eine lückenlose Dokumentation des Projektfortschritts.

• Lenkungsausschuss: Dieses Gremium, oft besetzt mit Vertretern des oberen Managements und ggf. Schlüsselabteilungen, trifft die grundlegenden Projektentscheidungen und überwacht die strategische Ausrichtung. Für die Pilotphase bedeutet das: Der Lenkungsausschuss genehmigt den Piloteinstieg (inkl. Budget, Bereichsauswahl) und wird über die Ergebnisse informiert. Er sollte die inhaltlichen Ziele absegnen und am Ende die Entscheidung über den Rollout treffen. Wichtig ist, dass der LA eigenverantwortlich Entscheidungen treffen kann und nicht auf weitere Freigaben warten muss. In der Praxis tagt der Lenkungsausschuss während des Pilots vielleicht ein- bis zweimal (Kick-off und Abschluss), bei Bedarf häufiger, wenn wesentliche Abweichungen auftreten. Er nimmt die Pilot-Ergebnisse entgegen und bewertet sie im Lichte der Projektziele. Seine Unterstützung ist essenziell, um ggf. nötige zusätzliche Ressourcen oder Richtungsänderungen schnell zu legitimieren.

• Projektleitung und -team: Die operative Steuerung obliegt der Projektleitung, die dafür sorgt, dass der Pilot nach Plan verläuft. Sie koordiniert die Teammitglieder (siehe Abschnitt 6) und stellt die Einhaltung der Projektmethodik sicher. In vielen Fällen wird für die CAFM-Einführung ein Projektleiter ernannt, der entweder aus der FM-Organisation oder der IT kommt. In der Pilotphase übernimmt er/sie die Rolle des „Dirigenten“: er organisiert Meetings, pflegt das Issue-Log, behält das Budget im Auge und kommuniziert zwischen den Ebenen. Das Projektteam selbst arbeitet oft in Teilprojekten oder Workstreams (z.B. Teilprojekt „Schnittstellen“, Teilprojekt „Datenmigration“ etc.). Hier ist eine klare Aufgabenverteilung nötig, damit jeder weiß, wofür er verantwortlich ist. Oft bewährt es sich, für den Pilot spezielle Verantwortliche zu benennen, z.B. einen Pilot-Koordinator vor Ort, der die täglichen Abläufe betreut. Governance heißt auch, dass das Team genau weiß, wann es welche Entscheidungen eskalieren muss – z.B. technische Probleme an die IT-Leitung, fachliche Zielkonflikte an den Lenkungsausschuss. Rechte und Pflichten der Rollen sollten definiert sein (am besten schriftlich im Projektauftrag): z.B. der Projektleiter hat das Recht, Prioritäten im Team zu setzen, die Teilprojektleiter haben die Pflicht, regelmäßig Status zu berichten usw.. Solche Spielregeln halten das Projekt handlungsfähig und vermeiden Kompetenzgerangel.

• Dokumentation und Reporting: Eine gründliche Projektdokumentation ist während des gesamten Vorhabens unabdingbar – insbesondere aber in der Pilotphase, wo viele Erkenntnisse gewonnen werden. Es sollten geeignete Tools/Repositories genutzt werden (z.B. ein Projekthandbuch in SharePoint, Ticketsystem, Protokolle in Confluence o.ä.). Folgende Dokumente sind typisch: Projektplan, Sitzungsprotokolle, Anforderungsdokumente, Testpläne, Änderungsprotokolle, Fehlerliste, Benutzerdokumentation etc. Während der Pilotphase wächst vor allem die Liste der Change Requests und Bugfixes – hier ist eine Versionierung und Priorisierung wichtig (z.B. ein kleines Change Advisory Board innerhalb des Teams, das über Umsetzung/Nicht-Umsetzung von Nutzerwünschen im Pilot entscheidet). Außerdem sollte jeder Zwischenbericht festgehalten werden, damit Nachvollziehbarkeit gegeben ist. Zum Abschluss des Pilots entsteht idealerweise ein Pilot-Abschlussbericht (siehe Abschnitt 8), der alle wichtigen Ergebnisse und Entscheidungen dokumentiert. Auch die Beschlüsse des Lenkungsausschusses gehören in die Projektdoku (z.B. in Form von unterschriebenen Protokollen). All diese Unterlagen bilden später die Wissensbasis für den Rollout und auch für den Betrieb des Systems.

• Qualitätssicherung und Kontrolle: Governance bedeutet auch, Mechanismen zur Qualitätssicherung zu etablieren. Im Pilot könnte das bedeuten, dass es regelmäßige Projektcontrolling-Berichte gibt (Soll-Ist-Vergleich Zeit/Kosten, Qualitätsmetriken wie Zahl offener Issues). Ein unabhängiger QS-Beauftragter oder externer Berater kann ggf. hinzugezogen werden, um den Pilot kritisch zu begleiten. Zudem sollte klar sein, wie mit Risiken umgegangen wird – ein Risikomanagement-Prozess (inkl. Risk Log) hilft, identifizierte Risiken zu verfolgen und gegenzusteuern. Beispielsweise könnte ein Risiko sein „Widerstand der Nutzer höher als erwartet“ – die Gegenmaßnahme wäre dann intensiveres Change Management; solche Punkte gehören in die Steuerungsgremien.

Kurz gesagt sorgt eine gute Governance dafür, dass das Pilotprojekt transparent und kontrolliert abläuft. Jeder weiß, wer worüber entscheidet, und die Kommunikation ist geregelt. Gleichzeitig hält die Dokumentation fest, was erreicht und beschlossen wurde. Diese Professionalität in der Pilotphase ist wichtig, denn sie strahlt auf die Gesamtprojektkultur aus und schafft Vertrauen bei allen Beteiligten, dass das Projekt im Griff ist.

• Pilot klein anfangen, aber repräsentativ gestalten: Führen Sie stets zunächst eine Pilotphase durch, bevor Sie ein neues FM-System groß ausrollen. Ein begrenzter Pilot (ein Standort, eine Abteilung) reduziert Risiken enorm und schafft Vertrauen in den späteren Rollout. Achten Sie aber darauf, dass der Pilotbereich aussagekräftig ist – er sollte messbare Quick Wins liefern, idealerweise innerhalb weniger Monate, um den Nutzen des Systems früh zu demonstrieren.

• Klare Ziele und Kriterien definieren: Legen Sie von Beginn an Erfolgskriterien fest, anhand derer der Pilot gemessen wird (siehe Abschnitt 7). Halten Sie die Ziele schriftlich fest und stimmen Sie sie mit dem Stakeholder-Gremium ab. So herrscht Einigkeit, wann der Pilot als Erfolg gilt. Unklare Erwartungen führen oft zu Endlos-Piloten oder Unzufriedenheit.

• Starke Einbindung der Stakeholder sicherstellen: Sorgen Sie für Commitment von ganz oben und aktive Beteiligung aller relevanten Bereiche. Das Management sollte als Sponsor auftreten und z.B. im Lenkungsausschuss die Richtung vorgeben. Gleichzeitig beziehen Sie künftige Anwender frühzeitig ein, um Akzeptanz zu schaffen. Benennen Sie Key User als interne Fürsprecher und statten Sie sie mit Zeit und Schulung aus. Dieses Change Management verhindert Widerstände und erleichtert die spätere breite Nutzung.

• Iteratives Vorgehen und agiles Mindset: Nutzen Sie die Pilotphase, um Rückmeldungen einzuholen und das System iterativ zu verbessern. Ein starrer Plan, der keine Änderungen während des Pilots zulässt, ist kontraproduktiv. Stattdessen: Feedback der Nutzer aufnehmen, schnell umsetzen, testen – so erhöhen Sie die Qualität schrittweise. Fehler im Pilot sind normal; wichtig ist, daraus zu lernen und Anpassungen vorzunehmen (Continuous Improvement).

• Gründliche Schulung und Support einplanen: Investieren Sie ausreichend in die Schulung der Pilotanwender. Die Nutzer müssen das System und die neuen Prozesse verstehen, sonst scheitert der Pilot an Akzeptanzproblemen. Bewährt hat sich eine Mischung aus Trainings (Workshops, Tutorials) und fortlaufendem Support (Ansprechpartner, Helpdesk) im Pilot. Dokumentieren Sie häufige Fragen und erstellen Sie eventuell eine kurze Anleitung speziell für den Pilotbetrieb. Früh erfolgreich geschulte „Early Adopters“ können als Multiplikatoren dienen und Kollegen anleiten.

• Datenqualität und Schnittstellen nicht vernachlässigen: Die besten Funktionen helfen nichts, wenn die zugrunde liegenden Daten unbrauchbar sind. Daher bereits im Pilot auf gute Datenqualität achten (ggf. vorgängig Datenbereinigung durchführen). Führen Sie eine Pilot-Datenmigration mit begrenztem Umfang durch, um das Vorgehen zu testen. Ebenso sollten alle erforderlichen Schnittstellen im Pilot aktiviert und geprüft werden (z.B. Import von Stammdaten, Export von Leistungsberichten). So stellen Sie sicher, dass das Zusammenspiel mit der restlichen IT-Landschaft funktioniert, bevor der große Rollout kommt.

• Realistisches Change Management betreiben: Rechnen Sie mit Widerstand und planen Sie Maßnahmen dagegen. Kommunikation ist zentral – erklären Sie den Zweck des Pilots und feiern Sie Erfolge („Quick Wins“) sichtbar, um Stimmung für das Projekt zu machen. Holen Sie Betriebsrat/Personalrat ins Boot, falls relevant, um Ängste (z.B. bzgl. Arbeitsplatzverlust durch Digitalisierung) abzubauen. Die Pilotphase sollte von Anfang an als Teil des Veränderungsprozesses gesehen werden, in dem Feedback willkommen ist und Fehler erlaubt sind.

• Dokumentation der Ergebnisse und Entscheidungen: Führen Sie Buch über alles Wesentliche im Pilot (Konfigurationen, Probleme, Beschlüsse). Am Ende sollte ein schriftliches Resümee vorliegen, das genau festhält, was gelernt wurde und wie man damit umgeht. Dieses Dokument ist Gold wert für den Rollout und dient auch der Nachvollziehbarkeit gegenüber Dritten (z.B. wenn Sie einen externen Auditor oder Fördermittelgeber haben). Außerdem schützt es das Projektwissen vor Personalwechsel: Sollte der Projektleiter wechseln, kann der Nachfolger die Dokumentation lesen und ist im Bilde.

• Übergang zum Rollout gut vorbereiten: Lassen Sie den Pilot nicht einfach auslaufen, sondern planen Sie einen klaren Übergabeprozess. Beispielsweise: Nach dem Pilot-Abschlussworkshop werden die beschlossenen Änderungen ins Produktivsystem übernommen, es gibt einen aktualisierten Projektplan für den Rollout, die restlichen Endnutzer werden sukzessive geschult usw. Setzen Sie ggf. den Pilotbetrieb fort, bis der Rollout startet, damit keine Nutzungsunterbrechung entsteht. Nutzen Sie die positiven Pilot-Ergebnisse als Marketing innerhalb der Organisation („In Abteilung X konnten wir dank CAFM die Wartungszeiten um 20% senken…“), um Vorfreude auf den Rollout zu wecken.

Durch Beachtung dieser Empfehlungen lässt sich die Pilotierung im CAFM-Kontext effektiv gestalten. Eine sorgfältig geplante und durchgeführte Pilotphase erhöht die Wahrscheinlichkeit einer erfolgreichen Gesamtimplementierung erheblich. Sie fungiert als Testfeld, in dem Technik, Prozesse und Mensch miteinander harmonisiert werden. Ist der Pilot gelungen, hat man nicht nur wertvolle Erkenntnisse gewonnen, sondern auch das nötige Momentum und Vertrauen, um die CAFM-/IWMS-/CMMS-Lösung im gesamten Unternehmen auszurollen und die angestrebten Vorteile voll zu realisieren.