CAFM: Soll-Prozessdesign und Harmonisierung

Der erste Schritt auf dem Weg zu harmonisierten Soll-Prozessen ist eine gründliche Ist-Prozessaufnahme. Dabei werden alle relevanten bestehenden Abläufe dokumentiert – z.B. durch Interviews, Workshops und Beobachtung vor Ort. Im genannten Praxisbeispiel wurden etwa „vor Ort an beiden Standorten mittels Interviews und Arbeitsbegleitung insgesamt fast 40 Prozesse aufgenommen“, um Unterschiede und Verbesserungsbedarf aufzudecken. Wichtig ist, die Ist-Prozesse vollständig und korrekt zu erfassen und anschließend gemeinsam mit den Prozessbeteiligten zu validieren. Diese Validierung (Schritt-für-Schritt-Durchsprache mit den Beteiligten) stellt sicher, dass alle verstehen, wie der aktuelle Ablauf wirklich funktioniert und wo Schwachstellen liegen.

• Erkenntnisse aus der Ist-Aufnahme: Die identifizierten Störfaktoren und Optimierungspotenziale der aktuellen Prozesse geben konkrete Ansatzpunkte für Änderungen. Beispielsweise werden unnötige Medienbrüche eliminiert, redundante Schritte gestrichen oder Verantwortlichkeiten neu zugeschnitten. Oft zeigt schon die Ist-Dokumentation, wo Prozesse stocken oder Ziele nicht erreicht werden. Diese Schwachstellen dienen als Grundstein für ein zielgerichtetes Soll-Prozessdesign. So wurde etwa in einem Projekt zunächst eine Liste aller innerhalb der Ist-Prozesse genannten „Schmerzpunkte“ erstellt und priorisiert. Anschließend prüfte man die Machbarkeit von Verbesserungen (z.B. systemseitige Lösungen) gemeinsam mit den jeweiligen Experten. Dieses systematische Vorgehen stellt sicher, dass das Soll-Modell realistisch und umsetzbar ist.

• Strategische Ziele des Unternehmens: Soll-Prozesse müssen mit den übergeordneten Zielen und der FM-Strategie im Einklang stehen. Daher werden aus der Geschäftsstrategie relevante Vorgaben abgeleitet – etwa Kostensenkungsziele, Serviceverbesserungen oder Wachstumsvorhaben – und in Prozessziele übersetzt. Beispiel: Hier war ein Ziel des Projekts „One CAFM“, die Wettbewerbsfähigkeit des Kerngeschäfts zu fördern und die Transparenz über Flächenauslastungen zu steigern. Daraus leitete man ab, dass standortübergreifende Auswertungen über freie Flächen möglich sein müssen und Prozesse so gestaltet werden, dass Flächeneffizienz mess- und optimierbar wird. Strategische Vorgaben wie „Steigerung der Flächeneffizienz um X%“ oder „Verbesserung der Reaktionszeit bei Störmeldungen“ fließen direkt in die Soll-Prozessgestaltung ein. Managementziele und KPIs beeinflussen also, welche Prozessschritte hinzugefügt oder verändert werden (z.B. Einführung eines KPI-Reportings als fester Prozessbestandteil).

• Gesetzliche und normative Anforderungen: FM-Prozesse unterliegen zahlreichen rechtlichen Auflagen (z.B. Betreiberverantwortung, Arbeits- und Brandschutz, Datenschutz) sowie Standards und Normen. Diese müssen im Soll-Prozessdesign unbedingt berücksichtigt werden, um Compliance sicherzustellen. Beispielsweise geben Vorschriften der Deutschen Gesetzlichen Unfallversicherung (DGUV) Intervalle für Prüfungen technischer Anlagen vor, die im Instandhaltungsprozess verankert sein müssen. Ein anderes Beispiel sind Wartungsprozesse: DIN EN 13306 und 15221-5 liefern Terminologie und Leitlinien für Instandhaltungsprozesse, und die GEFMA 190 Richtlinie konkretisiert Betreiberpflichten im FM. Rechtliche Anforderungen bestimmen oft Mindeststandards für Prozesse (z.B. Pflichtschritte wie Sicherheitsfreigaben, Dokumentationspflichten). Im Soll-Prozessdesign werden daher alle einschlägigen Vorgaben identifiziert und als Muss-Kriterien eingebaut. So kann sichergestellt werden, dass etwa der Prozess „Prüfung ortsveränderlicher elektrischer Betriebsmittel“ konform zu DGUV V3 abläuft oder dass bei „Wartung von Aufzügen“ die BetrSichV erfüllt wird. Strategische und rechtliche Anforderungen bilden somit gemeinsam mit der Ist-Analyse die Leitplanken, innerhalb derer die neuen Soll-Prozesse gestaltet werden.

Nach der Definition erster Entwürfe werden diese auf Machbarkeit geprüft und ggf. in Rücksprache mit Fachexperten angepasst. Gegebenenfalls führt man eine Soll-Ist-Abgleich-Workshopreihe durch, in der pro Prozess geschaut wird: Was müssen wir ändern, um vom Ist zum Soll zu gelangen? Jede Änderung wird hinsichtlich Nutzen und Aufwand bewertet. Dabei ist es legitim, auch Kosten-Nutzen-Abwägungen zu treffen: Nicht jede theoretische Verbesserung lohnt, wenn ihr Nutzen die Umsetzungskosten nicht rechtfertigt. Hier hilft es, die geplanten Prozessänderungen priorisiert anzugehen – oft beginnt man mit „Quick Wins“ (kleinen Prozessanpassungen mit großem Effekt) und adressiert aufwändigere Optimierungen schrittweise.

Die Analyse des Ist-Zustandes zeigt das „WIE ist es heute?“, die strategischen Ziele und Anforderungen geben vor „WAS wird gebraucht?“, und das Soll-Prozessdesign beantwortet schließlich „WIE machen wir es morgen besser?“.

Die Entwicklung der Soll-Prozesslandschaft erfolgt typischerweise in einem Mix aus analytischen und kreativen Methoden. Wichtig ist, die künftigen Abläufe nicht im stillen Kämmerlein zu entwerfen, sondern interaktiv mit den Fachexperten und Nutzern zu erarbeiten.

• Workshops mit Stakeholdern: In moderierten Workshops werden die Prozesse gemeinsam mit Vertretern aller relevanten Gruppen (z.B. Facility Manager, Objektleiter, Techniker, Nutzervertretungen) entworfen. Diese Workshops können pro Teilprozess stattfinden (etwa ein Workshop zu Störungsmeldung und -bearbeitung, ein weiterer zu Raumbuchungsprozessen, etc.). Ziel ist, fachübergreifend ein gemeinsames Verständnis des Soll-Ablaufs zu schaffen und Best-Practice-Ideen zu sammeln. Dabei helfen Techniken wie Whiteboard- oder Brown-Paper-Modeling, in denen der Prozess als Flussdiagramm aufgezeichnet und von der Gruppe diskutiert wird. Jeder Teilnehmer kann Verbesserungs- und Vereinfachungsvorschläge einbringen. Durch solche Workshops fühlen sich die Mitarbeiter eingebunden, können ihr Erfahrungswissen einbringen und akzeptieren das Ergebnis eher. Ein Praxisfall: Es wurde für jeden Kernprozess ein Prozessverantwortlicher benannt, der zusammen mit den Kollegen der Standorte die neuen Abläufe erarbeitete – „In den Standorten werden die einzelnen Prozessschritte in den jeweiligen Gruppen besprochen. Wir treffen immer eine gemeinschaftliche Entscheidung für den jeweiligen Best Practice.“. Dieses partizipative Vorgehen führte zu hoher Akzeptanz der definierten Prozesse.

• Geschäftsprozessmodellierung (BPMN 2.0): Zur Dokumentation und Weiterentwicklung der Prozesse hat es sich bewährt, eine formale Modellierungssprache wie Business Process Model and Notation (BPMN 2.0) einzusetzen. BPMN ermöglicht es, Prozessdiagramme mit standardisierten Symbolen zu zeichnen – z.B. Pools/Lanes für Akteure, Aktivitäten, Entscheidungs-Gateways, Ereignisse etc. In vielen Projekten werden die aufgenommenen Ist-Prozesse zunächst in BPMN-Diagramme überführt und dann als Grundlage verwendet, um Soll-Varianten zu entwerfen. Softwaretools wie Signavio, ADONIS, Visio oder ARIS helfen dabei. Vorteil: Visuelle Modelle machen den Ablauf leicht verständlich und decken Lücken oder unnötige Schleifen auf. Änderungen lassen sich per Modell schnell ausprobieren, bevor man sie real umsetzt. Zudem können BPMN-Modelle später zur Konfiguration der CAFM-Workflow-Engine dienen. Beispiel: In einem OSCAR-Projekt wurden alle Ist-Prozesse in Signavio (BPMN 2.0) visualisiert und mit den Beteiligten validiert. Im Anschluss konnten auf dieser Basis die Soll-Prozesse modelliert werden. BPMN dient quasi als „gemeinsame Sprache“ zwischen FM-Fachabteilung, Beratern und IT-Implementierern.

• Use Cases und Szenarien: Neben der prozessualen Flussbeschreibung lohnt es sich, Use Cases (Anwendungsfälle) zu definieren, um die Interaktion zwischen Nutzer und System im Kontext des Prozesses zu beschreiben. Ein Use Case beschreibt aus Benutzersicht Schritt für Schritt, wer mit dem System was tut, um ein bestimmtes Ziel zu erreichen. Beispiel: „Meldung eines technischen Defekts durch einen Mitarbeiter“ – der Anwendungsfall würde beschreiben, wie der Mitarbeiter am CAFM-Serviceportal eine Störmeldung aufgibt, welche Daten er eingibt, wie das System antwortet und den Vorgang an den Techniker weiterleitet. Solche Use Cases stellen sicher, dass die Soll-Prozesse eng mit den Systemfunktionalitäten verzahnt sind und die Benutzerfreundlichkeit berücksichtigt wird. Sie helfen auch dem Software-Anbieter/Implementierungsteam zu verstehen, welche Anforderungen das System erfüllen muss (Stichwort Anforderungserhebung). Ebenso können Szenario-Workshops durchgeführt werden, in denen typische Ablaufszenarien (z.B. „Leuchtmittelausfall im Büro“) durchgespielt werden: Was passiert vom Auslösen der Meldung bis zur Behebung? Diese Vorgehensweise deckt eventuelle Sonderfälle oder Ausnahmewege auf, die im Soll-Prozess berücksichtigt werden müssen (z.B. Eskalation, wenn eine Störung nicht binnen Frist behoben ist).

• Prozessmodellierungstools und Simulation: Fortgeschrittene Methoden schließen den Einsatz von Prozesssimulation ein. Mit entsprechenden Tools kann man digitale Modelle der Prozesse laufen lassen, um z.B. Durchlaufzeiten, Ressourcenengpässe oder Kosten zu simulieren. Das ist vor allem bei großen Organisationen sinnvoll, um verschiedene Varianten des Soll-Prozesses miteinander zu vergleichen. „Die Integration von Prozesssimulationstools kann helfen, digitale Darstellungen jedes Prozesses zu erstellen und zu beurteilen, welcher die besten Ergebnisse bietet.“ – gerade bei der Gestaltung z.B. von Service Desk Prozessen (mit wechselnden Volumina an Tickets) kann Simulation zeigen, ob personelle Kapazitäten ausreichen oder wo Wartezeiten entstehen. Auch einfache „Trockenübungen“ gehören dazu: Man kann den modellierten Soll-Prozess in einem Workshop Schritt für Schritt durchgehen (Walkthrough), um sicherzustellen, dass nichts vergessen wurde und alle Bedingungen (Freigaben, Infos) stimmen.

Zusammengefasst nutzt die Soll-Prozessentwicklung strukturierte Modellierungsansätze (BPMN, Use Cases) ebenso wie kollaborative Workshop-Formate. Wichtig ist das iterative Vorgehen: Entwurf -> Feedback einholen -> Überarbeitung. Durch die visuelle Aufbereitung und gemeinsame Diskussion werden Soll-Prozesse geschaffen, die logisch schlüssig, von den Anwendern mitgetragen und technisch realisierbar sind.

Um höchste Effizienz und Qualität zu erreichen, sollten die neu gestalteten FM-Prozesse nicht im luftleeren Raum entstehen, sondern sich an anerkannten Best-Practice-Frameworks und Normen orientieren. Eine Standardisierung gemäß bewährten Richtlinien stellt sicher, dass die Prozesse Branchenstandards erfüllen und mit externer Terminologie und Anforderungen kompatibel sind.

• GEFMA 100 (Deutscher FM-Verband): Die GEFMA 100 ist eine grundlegende Richtlinie des deutschen Facility-Management-Verbandes GEFMA. Sie besteht aus zwei Teilen – Teil 1 vermittelt die FM-Grundlagen, Teil 2 beschreibt das Leistungsspektrum im Facility Management. In dieser Richtlinie werden alle relevanten Begriffe und Aufgabenfelder des FM definiert und strukturiert. Eine Orientierung an GEFMA 100 hilft, die eigenen Prozesse im Kontext des gesamten FM-Leistungskatalogs zu verorten. Beispielsweise werden klassische Hauptprozesse wie Instandhaltung, Flächenmanagement, Reinigungsmanagement, etc. in GEFMA standardisiert beschrieben – ein Soll-Prozessdesign kann diese Beschreibungen heranziehen, um Vollständigkeit sicherzustellen. Außerdem fördert GEFMA 100 ein einheitliches Verständnis im Team: Begriffe wie „Kunde, Nutzer, Auftraggeber“ oder „Service Level Agreement“ werden klar abgegrenzt. Gerade für konzernweite Harmonisierung ist diese gemeinsame FM-Sprache wertvoll. Neben GEFMA 100 sind auch weitere GEFMA-Richtlinien relevant: z.B. GEFMA Workflow-Richtlinien (wenn vorhanden) oder GEFMA 444 (CAFМ-Softwarezertifizierung) als Qualitätsmaßstab für Systemfunktionen. Auch GEFMA 420 (Leitfaden CAFM-Einführung) bietet Hilfestellungen, welche Prozesse in welcher Tiefe zu definieren sind.

• ITIL (IT Infrastructure Library): Obwohl ITIL ursprünglich aus dem IT-Service-Management kommt, lassen sich viele Prozessprinzipien auf das Facility Management übertragen, insbesondere im Bereich Service Desk und Störungsmanagement. ITIL stellt einen weltweit anerkannten Best-Practice-Ansatz für Service-Prozesse bereit, mit klar definierten Prozesskategorien wie Incident Management (Störfallmanagement), Problem Management, Change Management, Request Fulfillment (Anfragebearbeitung) etc. Für ein CAFM-Projekt ist insbesondere das Störungs- und Auftragsmanagement analog zum Incident/Request Management in ITIL interessant. Ein zentraler FM-Helpdesk kann nach ITIL-Grundsätzen gestaltet werden: Jede Meldung erhält ein Ticket, Prioritäten und Reaktionszeiten (SLAs) werden definiert, Eskalationsregeln bei Fristüberschreitung greifen, und die Bearbeitung erfolgt nach einem strukturierten Workflow (Annahme, Klassifizierung, Zuweisung, Lösung, Abschluss). Die ITIL-Rollen (z.B. Incident Manager, Change Advisory Board) können im FM durch entsprechende Pendants ersetzt werden (z.B. Objektmanager als Incident Manager für Gebäudestörungen). Indem man sich an ITIL orientiert, standardisiert man die Serviceprozesse im FM so, dass sie messbar und optimierbar sind (Stichwort Kennzahlen wie Erstlösungsquote, durchschnittliche Bearbeitungszeit etc.). Auch das Benutzer-Erlebnis lässt sich verbessern: Ein nach ITIL aufgesetzter FM-Serviceprozess stellt sicher, dass jeder Meldende Rückmeldungen zum Status erhält und dass Wissen aus wiederkehrenden Problemen gesammelt wird (Problem Management). Kurzum, ITIL bietet einen Prozess-Baukasten für Serviceorganisationen – viele FM-Dienstleistungen (Raumreservierungsservice, Catering-Bestellungen, Reparaturmeldungen) kann man in diesen Rahmen fassen, um Professionalität und Vergleichbarkeit zu steigern.

• ISO 41001 (FM-Managementsystem-Norm): Die internationale Norm ISO 41001:2018 definiert Anforderungen an ein Facility-Management-System und liefert einen Managementrahmen ähnlich ISO 9001 (Qualität) oder ISO 14001 (Umwelt). Diese Norm „liefert Rahmenbedingungen und Voraussetzungen für ein gut funktionierendes Facility Management-System“. Obwohl ISO 41001 auf Managementsystem-Ebene angesiedelt ist, fördert sie explizit einen Prozessorientierten Ansatz bei der Entwicklung, Implementierung und Aufrechterhaltung von FM-Leistungen. Für das Soll-Prozessdesign bedeutet das: Prozesse sollen klar dokumentiert, gemessen und kontinuierlich verbessert werden. Die Norm fordert z.B., dass Verantwortlichkeiten festgelegt werden, dass Risikoabwägungen in die Prozesse einfließen und dass die Prozesse die Ziele der FM-Strategie unterstützen. Eine Organisation, die nach ISO 41001 strebt, wird ihre Soll-Prozessdokumentation so gestalten, dass Auditoren nachvollziehen können, wie die FM-Services erbracht und überwacht werden. Zwar geht ISO 41001 nicht ins Detail einzelner FM-Prozesse, aber sie schafft den Managementrahmen: Dazu gehört das Einführen eines Plan-Do-Check-Act (PDCA)-Zyklus für Prozessverbesserungen, das Festlegen von Leistungskennzahlen (KPIs) pro Prozess und die Sicherstellung der rechtlichen Konformität. Das Soll-Prozessdesign kann sich also an ISO 41001 orientieren, um Zertifizierungsfähigkeit zu erreichen – Unternehmen können künftig ihr FM nach ISO 41001 zertifizieren lassen, analog zu ISO 9001, was als Qualitätsmerkmal am Markt kommunizierbar ist.

• Weitere relevante Standards: Neben den genannten sollten auch DIN-/EN-Normen und ggf. IT-Frameworks beachtet werden. Die europäische Norm DIN EN 15221 (Teile 1–7) liefert z.B. einen Leitfaden für FM-Prozesse (Teil 5) sowie Definitionen und Strukturen für FM-Leistungen. Branchen- und unternehmensspezifische Regelwerke (z.B. VDI-Richtlinien für Instandhaltung, interne Richtlinien) können ebenfalls herangezogen werden, damit die Soll-Prozesse anschlussfähig sind. Im IT-Bereich mag COBIT für Governance oder PRINCE2 für Projektprozesse relevant sein, falls FM-Prozesse in diese Richtung greifen. Auch IT-Sicherheit (ISO 27001) oder Energiemanagement (ISO 50001) tangieren FM-Prozesse (z.B. Prozess zur Datenbackup der Gebäudetechnik oder Energieoptimierungs-Prozesse) und sollten daher inhaltlich einbezogen werden, wo nötig.

Insgesamt sorgt die Ausrichtung an Frameworks dafür, dass das Rad nicht neu erfunden wird. Man nutzt bewährte Konzepte und passt sie auf das Unternehmen an. Standardisierte Prozesse nach GEFMA, ITIL & Co. erleichtern auch die Harmonisierung: externe Dienstleister oder neue Mitarbeiter kennen diese Standards vielleicht schon und finden sich schneller zurecht. Zudem bilden sie oft die Grundlage für CAFM-Software: Viele Tools sind so gebaut, dass sie z.B. ITIL-ähnliche Ticketprozesse unterstützen oder Berichte nach GEFMA-Kostenstrukturen ausgeben können. Ein standardkonformer Soll-Prozess ist daher meist leichter im System umzusetzen und langfristig stabiler (da Benchmarks und Best Practices verfügbar sind).

Warum Harmonisierung? Größere Unternehmen haben oft unterschiedliche FM-Prozesse an verschiedenen Standorten oder in unterschiedlichen Geschäftsbereichen. Das kann daran liegen, dass einzelne Standorte eigenständig gewachsen sind, mit eigenen Teams und Tools (z.B. hatte früher jedes Werk sein eigenes CAFM-System). Die Folgen sind Inkonsistenzen und erhöhter Aufwand: Prozesse laufen nicht einheitlich ab, Vergleichbarkeit fehlt und Doppelarbeit entsteht. Genau hier setzt die Harmonisierung an – das Ziel ist, standortübergreifend „glattgezogene“ Prozesse zu etablieren, sodass alle nach dem gleichen Ablaufmodell arbeiten.

• Zentral vs. dezentral: Bei der Harmonisierung muss man abwägen, welche Prozesse zentralisiert und welche dezentral organisiert sein sollen. Zentralisierung bedeutet, dass bestimmte Prozessschritte oder Entscheidungen von einer zentralen Stelle (etwa der Zentrale oder einem Center of Excellence) ausgeführt werden. Dezentral heißt, jede Niederlassung oder Abteilung führt den Prozess eigenständig aus, evtl. mit lokalen Variationen. Oft ergibt sich eine Mischung: Strategische Steuerung und Standards zentral, operative Durchführung vor Ort. Im Soll-Prozessdesign sollte ausdrücklich festgelegt werden, welche Aufgaben zentral wahrgenommen werden und wo lokaler Spielraum bleibt. Beispiel: Ein zentraler FM-Service-Desk könnte alle Störungsmeldungen im Konzern entgegennehmen und vorqualifizieren (zentraler Prozess), während die Abarbeitung der Tickets dann durch die lokalen Haustechniker erfolgt (dezentraler Teilprozess). Auch Einkaufsprozesse im FM (z.B. Beschaffung von Dienstleistungen) lassen sich teilweise zentral bündeln (Rahmenverträge), während Bedarfsmeldung vor Ort passiert. Klar definierte Rollen und Entscheidungskompetenzen ermöglichen es, Aufgaben sowohl zentral als auch dezentral effizient zu steuern.

• Vorgehen bei der Harmonisierung: Zunächst werden alle bestehenden Prozessvarianten gesammelt (ggf. je Standort erhoben in der Ist-Phase) und miteinander verglichen. Typischerweise findet man dabei „best practices“ an einzelnen Standorten, die man auf alle übertragen möchte, und andere Praktiken, die obsolet sind. Im Design-Workshop gilt es, pro Prozess eine einheitliche Soll-Variante zu formulieren, die für alle gilt – einen Standardprozess. Hierbei ist die Einbindung der Standorte entscheidend, damit deren Wissen einfließt und sie das Ergebnis mittragen. Dieser Prozess kann moderiert von der Zentrale oder einem externen Berater erfolgen, der einen konsolidierten Prozessvorschlag vorbereitet und mit den lokalen Teams abstimmt.

• Best-Practice-Ansatz: Oft wird im Rahmen der Harmonisierung ein „Best Practice“-Prozess definiert, d.h. die optimale Abfolge, die sich aus den Erfahrungen aller Standorte ergibt. Die Frage lautet: Wie würden wir den Prozess gestalten, wenn wir bei null anfangen – unter Nutzung aller bekannten Erfolgsfaktoren? So einen Idealprozess dann global auszurollen, erfordert oft Anpassungen vor Ort (Schulung, ggf. kleine organisatorische Änderungen). In der Praxis zeigt sich aber, dass die Vorteile überwiegen: „Die FM-Prozesse sind über alle Standorte hinweg harmonisiert. Jeder einzelne Standort war vorher für sich gewachsen... unterschiedlich – jetzt haben wir eine zentrale, vereinheitlichte Datenbasis.“. Durch diese Vereinheitlichung konnten im Beispiel alle Standorte erstmals kohärent berichten: Früher musste jeder Standort separat Auswertungen liefern, nun werden „aus dem System die Miet- und Flächendaten standortübergreifend extrahiert“. Das spart enorm Zeit und ermöglicht eine konzernweite Sicht auf KPIs. Gleichzeitig sank die Fehlerquote und die Datenqualität stieg, weil nicht mehr manuell Excel-Listen aus verschiedenen Systemen zusammengeführt werden müssen.

• Rollen und Ressourcen: Eine Folge der Harmonisierung ist oft, dass manche Aufgaben zentralisiert werden (z.B. Reporting, Systempflege), was die lokalen Einheiten entlastet. „Durch die Zentralisierung der Prozesse werden die Ressourcen an den Standorten spürbar entlastet“. Statt dass jeder Standort einen eigenen Datenmanager haben muss, kann dies eine zentrale Stelle übernehmen. Das Know-how bündelt sich im zentralen Team (Center of Excellence), das Prozesse standardisiert vorgibt und bei Bedarf Support leistet. Die Standorte können sich dann stärker auf die operative Umsetzung konzentrieren. Diese klare Aufgabenverteilung muss im Soll-Konzept festgelegt sein. Natürlich sind nicht alle Prozesse zu 100% gleichförmig machbar – lokale Besonderheiten (z.B. länderspezifische Vorschriften, verschiedenartige Gebäudetypen) müssen berücksichtigt werden. Aber auch solche Abweichungen können gesteuert werden, indem man definierte Varianten im Prozess zulässt, anstatt völlig eigenständige Abläufe.

• Beispielhafte Erfolge: Harmonisierung ermöglicht zum Beispiel, Benchmarks zwischen Standorten zu ziehen (weil alle nach dem gleichen Prozess z.B. Reinigungskosten erfassen) und Lernkurven zu nutzen. Man spricht von einer „zentralen, konsistenten Datenbasis“, durch die man Kunden (hier interne Nutzer) schnell und verlässlich Auskunft geben kann – z.B. welche Flächen frei sind oder wo Leerstand ist. Die Organisation tritt nun einheitlich als Dienstleister auf, anstatt fragmentiert aufzutreten. In Zukunft können so auch neue internationale Standorte nach dem gleichen Modell ausgerollt werden, was die Skalierbarkeit erhöht.

• Harmonisierung ist also ein Balanceakt: Es gilt, höchstmögliche Einheitlichkeit herzustellen, ohne die nötige Flexibilität einzubüßen. Zentral und dezentral sind kein Widerspruch, sondern zwei Seiten eines Gestaltungsspielraums. Das Soll-Prozessdesign sollte klar dokumentieren, welche Prozesse zentral geführt werden (inkl. verantwortliche zentrale Rollen) und welche lokal ausgeführt werden – und wie beide Ebenen zusammenwirken (z.B. Meldewege, Eskalationen). Dies sorgt dafür, dass am Ende alle an einem Strang ziehen und das CAFM als gemeinsame Plattform nutzen, mit konsolidierten Prozessen statt Silo-Denken.

Ein wesentlicher Erfolgsfaktor für funktionierende Soll-Prozesse ist die klare Definition von „Wer macht was?“. In der Ist-Welt herrscht nicht selten Unklarheit darüber, wer für welchen Schritt zuständig ist – was zu Reibungsverlusten und Fingerpointing führen kann. Im Soll-Konzept müssen daher Prozessrollen und Verantwortlichkeiten eindeutig festgelegt werden.

• RACI-Matrix: RACI steht für Responsible, Accountable, Consulted, Informed, also verantwortlich, rechenschaftspflichtig, zu konsultieren, zu informieren. Eine RACI-Matrix ordnet für jede Aufgabe oder jeden Prozessschritt diesen vier Rollen Kategorien zu. Konkret heißt das: Für jede Prozessaktivität wird bestimmt, wer die Durchführung übernimmt (R), wer die letzte Entscheidungs-/Genehmigungsverantwortung trägt (A), wer als Experte/Stakeholder eingebunden wird (C) und wer über den Fortgang lediglich informiert wird (I). Durch eine solche Matrix werden die Erwartungen an jede Rolle transparent.

Die Implementierung einer RACI-Matrix im Facility Management führt zu „verbesserter Verantwortlichkeit: Jedem ist klar, wer für die Ausführung zuständig ist und wer die Letztentscheidung hat“. Kommunikationswege werden kürzer, weil man genau weiß, wen man fragen oder informieren muss, was Missverständnisse verringert. Zugleich werden Doppelarbeit und Lücken vermieden, denn überlappende Zuständigkeiten fallen auf und können bereinigt werden. Insgesamt entstehen „effizientere Abläufe und ein organisierteres, verantwortungsbewusstes Arbeitsumfeld“, was wiederum die Servicequalität steigert.

Beim Prozess „Wartungsauftrag durchführen“ könnte die RACI-Zuordnung wie folgt aussehen – R: Servicetechniker (führt die Wartung durch), A: Technischer Leiter (ist letztlich für ordnungsgemäße Durchführung verantwortlich), C: Sicherheitsbeauftragter (ist bei Fragen zur Arbeitssicherheit zu konsultieren), I: Objektleiter (wird über Abschluss informiert). Diese Logik wird für alle wesentlichen Prozesse tabellarisch festgehalten. So weiß jeder Beteiligte genau, welche Rolle er wann spielt.

In einer exemplarischen RACI-Matrix für FM-Aufgaben ist z.B. „Erstellung eines Wartungsplans“ aufgeführt mit Responsible = Facility Manager, Accountable = Leiter Facility Services, Consulted = Instandhaltungsteam und Betriebsleiter, Informed = – (keine spezielle Inform-Position). Hingegen bei „Lieferantenvertrag managen“ taucht als Consulted der Einkaufsleiter auf und als Informed wieder der Betriebsleiter. Dieses Beispiel zeigt, wie bereichsübergreifend gedacht wird: Einkauf wird z.B. konsultiert, wenn es um Verträge geht, obwohl der Prozess primär im FM liegt.

• Rollendefinitionen: Aufbauend auf der RACI-Zuordnung werden im Soll-Modell alle relevanten Rollen klar beschrieben. Das umfasst die Rollenbezeichnung, eine Beschreibung der Aufgaben/Funktion im Prozess, die benötigten Befugnisse und ggf. Qualifikationen. In FM-Prozessen sind typische Rollen z.B.: Facility Manager, Objektleiter, Techniker, Helpdesk-Mitarbeiter, Bereichsleiter FM, Nutzer/Mieter, Dienstleister, Sicherheitsbeauftragter etc. Für jeden dieser Akteure wird im Soll-Konzept festgelegt, welche Verantwortung er trägt. Oft bietet sich hier ein Rollen-&-Rechte-Konzept an, das mit dem CAFM-Berechtigungssystem verzahnt ist. Wichtig: Jede Aufgabe im Prozess muss mindestens einen Responsible haben – es darf kein Schritt entstehen, für den „sich niemand zuständig fühlt“. Ebenso sollte jede Rolle im Prozess mit sinnvollen Aufgaben verknüpft sein (niemand wird aus Versehen übersprungen oder doppelt eingebunden).

• RACI-Workshops: Um die RACI-Matrix zu erstellen, kann man ebenfalls Workshops durchführen. Man listet alle Schlüsselaufgaben eines Prozesses auf und diskutiert im Team, wer welche Rolle haben soll. Idealerweise sind hier Vertreter der späteren Rollen anwesend, um ihre Sicht einzubringen. Es kann dabei durchaus Diskussionen geben (z.B. ob der Objektleiter nur informiert wird oder doch consulted sein sollte bei einer wichtigen Entscheidung). Diese Punkte müssen bereichsübergreifend geklärt werden – aber das Ergebnis lohnt: „Klare Rollendefinitionen minimieren das Risiko, dass Aufgaben vergessen oder doppelt erledigt werden“. Nach Erstellung wird die RACI-Matrix mit allen Beteiligten kommuniziert und abgestimmt, damit jeder sein Einverständnis gibt und eventuelle Unklarheiten ausgeräumt werden.

Zusätzlich zur RACI-Methodik sollten im Soll-Prozessdesign Verantwortliche auf Prozessebene benannt werden – also Prozessowner. Für jeden Hauptprozess (z.B. Instandhaltung, Flächenmanagement) gibt es idealerweise einen Verantwortlichen, der die Einhaltung des Prozesses überwacht und als Kümmerer fungiert. Diese Rolle war der Prozessverantwortliche pro Kernprozess, der die Gestaltung und Implementierung begleitete. Solche Prozessowner sind oft auch die Accountables (A) in der RACI-Matrix für die Gesamtabläufe.

Die Dokumentation der Rollen und RACI-Matrix ist ein zentrales Ergebnis des Soll-Prozessdesigns. Sie fließt nicht nur in Schulungsunterlagen ein, sondern dient später auch als Referenz, falls es organisatorische Änderungen gibt. Zudem fördert sie ein „empowered team“: Wenn jeder seine Verantwortung kennt, können Mitarbeiter proaktiv handeln und Entscheidungen treffen, was die Arbeitszufriedenheit erhöht.

Ein modernes CAFM-System bietet zahlreiche Chancen, Prozesse durch Digitalisierung und Automatisierung effizienter zu gestalten. Im Soll-Prozessdesign sollte man daher gezielt fragen: Welche Schritte lassen sich durch die neue Software vereinfachen oder automatisieren? Wo können digitale Technologien zusätzlichen Nutzen stiften? Die Soll-Prozesse sollen so entworfen werden, dass sie optimal von den Tools unterstützt werden und umgekehrt die Funktionen des CAFM-Systems voll ausgeschöpft werden.

• Automatisierung von Routineaufgaben: Routinetätigkeiten, die bisher manuell und zeitaufwändig waren, können oft durch das CAFM-System automatisiert werden. Beispielsweise können Wartungsaufträge automatisch generiert werden, wenn ein Intervall erreicht ist, anstatt dass jemand in Excel nachhalten muss. Durch solche Automatisierungen gewinnen die Mitarbeiter Zeit für strategischere Aufgaben. Ein digitaler Prozess würde z.B. vorsehen, dass bei Eingang einer Störmeldung automatisch eine Ticketnummer erzeugt wird, die Zuständigkeit gemäß hinterlegter Regeln zugewiesen wird und der Techniker eine Benachrichtigung erhält – ohne manuellen Zwischenschritt. Auch Genehmigungsworkflows (etwa Freigabe eines Budgets oder einer Bestellung) können elektronisch mit automatischen Benachrichtigungen und Eskalationen abgebildet werden. Das Soll-Design sollte diese Automatisierungspotenziale identifizieren und direkt einplanen, damit sie bei der Systemkonfiguration berücksichtigt werden. So wird aus einem ehemals papierbasierten Prozess ein digitaler Workflow, was Durchlaufzeiten verkürzt und Fehlerrisiken (z.B. durch Vergessen einer Mail) minimiert.

• Digitale Prozessoptimierung & Workflow-Engine: Moderne CAFM/IWMS verfügen oft über integrierte Workflow-Engines. Diese ermöglichen es, Prozesslogik im System zu hinterlegen – z.B. wer bei welchem Ereignis informiert wird, welche Folgeschritte automatisiert angestoßen werden usw. Im Soll-Prozessdesign sollte man daher überlegen, wie die Prozessschritte im System ablaufen. Beispielsweise kann der Prozess „Raumbuchung“ so digitalisiert werden, dass ein Mitarbeiter in einem Self-Service-Portal einen Raum beantragt, das System prüft Verfügbarkeit und Richtlinien (z.B. Covid-Abstand, max. Belegung), gibt automatische Bestätigungen und informiert Hausservice und IT über erforderliche Leistungen (Bestuhlung, Beamer) – alles gesteuert durch definierte Workflows. Ein anderes Beispiel: Bei Wartungen kann das System automatisch Service-Tickets erzeugen, Checklisten bereitstellen und nach Abschluss gleich die nächste Fälligkeit berechnen. All dies sollte im Soll-Prozess vorgesehen sein. Wichtig ist hier die enge Zusammenarbeit mit der IT/Software-Seite: Welche Funktionalitäten bietet das ausgewählte CAFM? (z.B. Alarmierungen, mobile Apps, IoT-Integration). Das Soll-Design sollte diese Möglichkeiten aktiv nutzen, um Medienbrüche zu eliminieren. Wo früher vielleicht Papierformulare weitergegeben wurden, wird nun ein digitaler Datensatz durch den Prozess „geschleust“.

• IoT und Smart Building Integration: Die Digitalisierung im FM geht heute über rein softwareinterne Workflows hinaus – Internet of Things (IoT) und Sensorik spielen eine zunehmende Rolle. Im Soll-Prozessdesign sollte man deshalb Digitalisierungspotenziale durch IoT berücksichtigen. Beispielsweise können Sensoren in Gebäuden Echtzeitdaten liefern: Raumklimasensoren, Zählern, Bewegungssensoren etc. Diese Daten lassen sich in Prozesse einbinden, um vorausschauende oder automatisierte Abläufe zu ermöglichen. Ein typisches Beispiel ist die vorausschauende Instandhaltung: Sensoren melden Zustandsverschlechterungen (etwa Vibration an einer Maschine oder Temperaturanstieg), woraufhin das CAFM-System automatisch einen Wartungsprozess triggert, bevor es zum Ausfall kommt. So ein proaktiver Prozess wäre im Soll-Design zu verankern: Der Prozess startet nicht mehr nur zeit- oder mitarbeitergesteuert, sondern eventgesteuert durch IoT-Daten. Dies führt zu verbesserter Wartung und längerer Lebensdauer von Anlagen. Auch Smart-Building-Technologien wie intelligente Zähler können Prozesse optimieren: z.B. automatische Erfassung von Verbrauchsdaten als Teil des Energiemanagement-Prozesses, anstatt manuell Zähler abzulesen. Das Soll-Design kann vorsehen, dass monatlich IoT-Zählerstände ins System importiert werden und Abweichungen einen Prüfprozess auslösen (z.B. Leckage-Erkennung bei Wasser).

• Daten und Analytics: Digitalisierte Prozesse generieren viele Daten, die wiederum zur Prozesssteuerung genutzt werden können. Im Soll-Prozessdesign sollte man definieren, welche Kennzahlen und Berichte aus dem Prozess gezogen werden sollen (Thema KPI-Konzept). Da ein CAFM-System Datenbanken und Reporting-Tools bietet, können z.B. Prozesse so gestaltet werden, dass automatisch Auswertungen entstehen: Etwa im Wartungsprozess wird jeder Auftrag mit Aufwand und Status im System dokumentiert, sodass man am Monatsende per Knopfdruck sieht, wie viele Aufträge erledigt, verspätet oder offen sind (und wo Engpässe liegen). Die Digitalisierung ermöglicht eine bessere Entscheidungsfindung und Datenanalyse, was man aktiv nutzen sollte. Beispielsweise könnte das Soll-Design vorsehen, dass im Prozess „Lieferantenmanagement“ alle Leistungen und Kosten im System erfasst werden, um später Preis-Leistungs-Analysen per Dashboard zu fahren. Oder ein Prozess „Raumbelegung verwalten“ integriert IoT-Bewegungsdaten, um Nachnutzungsanalysen zu erstellen. Diese Mehrwerte der Daten gilt es mitzudenken – Digitalisierung im FM heißt nicht nur analog -> elektronisch, sondern auch klüger entscheiden durch Daten.

• Beispielhafte Nutzenaspekte: Durch Digitalisierung verbessern sich Effizienz und Produktivität deutlich: Routinetätigkeiten laufen schneller und weitgehend automatisch ab, Mitarbeiter können sich wichtigeren Dingen widmen. Auch die Kommunikation wird verbessert: Digitale Plattformen (z.B. CAFM-Webportal oder mobile App) erlauben es, Informationen schnell und ortsunabhängig auszutauschen. Ein Techniker vor Ort kann etwa per Tablet den Auftrag sehen, Rückmeldung geben oder Fotos anhängen, was früher in Papierform oder telefonisch erfolgen musste. Transparenz steigt, weil alle Prozessbeteiligten den Status online verfolgen können (kein „Schwarzes Loch“, wo eine Anfrage bleibt). Schließlich resultiert Kostenersparnis: Prozesse brauchen weniger manuelle Arbeit und Zeit, was Personalkapazitäten frei macht, und durch optimierte Abläufe werden z.B. Wartezeiten oder Überbestände reduziert. Die Digitalisierung im FM kann so Betriebskosten senken – sei es durch Energieeffizienz (smarte Steuerung) oder durch effizientere Wartungsplanung, die teure Ausfälle vermeidet.

• Praxis-Tipp: Im Soll-Prozessdesign sollte man idealerweise gemeinsam mit IT-Experten oder dem CAFM-Anbieter einen Abgleich machen, welche Prozessschritte technisch automatisierbar sind. Nicht selten ergeben sich dabei kreative Lösungen: Vielleicht kann eine E-Mail-Schnittstelle genutzt werden, um automatische Benachrichtigungen an externe Dienstleister zu senden, oder ein QR-Code am Gerät vereinfacht die Identifikation im Prozess (Techniker scannt Code, der Auftrag öffnet sich in der App). Solche Ideen sollten ins Soll-Konzept einfließen, damit bei der Implementierung klar ist, was zu konfigurieren oder entwickeln ist.

Das Soll-Prozessdesign im digitalen Zeitalter bedeutet Prozesse so zu gestalten, dass sie durchgängig IT-gestützt, wo möglich automatisiert und datengetrieben sind. Die CAFM-Funktionen (von Workflow über Mobile bis IoT-Anbindung) sind dabei unsere Werkzeugkiste, aus der wir Lösungen einbauen. Dadurch erreichen wir Prozesse, die nicht nur schneller, sondern auch smarter sind – ein entscheidender Wettbewerbsvorteil für das Facility Management.

Nachdem die Soll-Prozesse entworfen und dokumentiert wurden, ist es wichtig, diese vor der endgültigen Umsetzung zu überprüfen und abnehmen zu lassen. Dieser Schritt stellt sicher, dass die geplanten Abläufe in der Praxis funktionieren, von den Anwendern akzeptiert werden und die Anforderungen erfüllen.

• Review-Workshops mit Fachexperten: Die erarbeiteten Prozessmodelle werden in gemeinsamen Durchsprachen mit den Prozessbeteiligten und Entscheidungsträgern geprüft. In solchen Review-Workshops geht man jeden Soll-Prozess Schritt für Schritt durch – am besten anhand eines konkreten Beispielszenarios – und fragt: Ist der Ablauf logisch und vollständig? Hat jeder Schritt einen Verantwortlichen? Sind Ausnahmen berücksichtigt? Hier können die späteren Endnutzer (z.B. Hausmeister, Helpdesk-Mitarbeiter) Feedback geben, ob der Prozess realistisch ist und wo evtl. Nachbesserungen nötig sind. Oft stellt sich heraus, dass noch „Use Cases“ fehlen oder einzelne Schritte unklar sind. Dieses Feedback wird protokolliert und fließt in die Feinjustierung der Prozesse ein. Erst wenn in der Runde Konsens besteht, dass der Prozess sinnvoll und machbar ist, gilt er als validiert. Ein bewährter Ansatz ist es, die Prozesse in diesen Workshops probeweise „durchzuspielen“ – z.B. wird eine Störung vom Anruf bis zur Behebung fiktiv durchlaufen, um zu sehen, ob alle Beteiligten wissen, was zu tun ist und ob das CAFM überall unterstützt.

• Prototyping im System: Falls zeitlich und ressourcentechnisch machbar, lässt sich ein Prototyp der Prozesse im CAFM-System einrichten. Das bedeutet, dass man in einer Test- oder Sandbox-Umgebung exemplarisch die Workflows oder Masken so konfiguriert, wie es der Soll-Prozess vorsieht. Damit können die Nutzer die neuen Abläufe quasi „live“ ausprobieren, ohne gleich produktiv zu gehen. Beispielsweise könnte man einen Prototypen für den Raumreservierungsprozess bauen: Das neue Antragsformular, der Genehmigungsworkflow und die Benachrichtigungen werden einmal in der Software aufgesetzt und getestet. So können noch vor dem Go-Live eventuelle Schwachstellen erkannt werden (vielleicht merkt man, dass eine benötigte Information im Formular fehlt, oder dass die Mailbenachrichtigung an den falschen Personenkreis geht). Prototyping erlaubt es, frühzeitig Fehlannahmen zu korrigieren und erhöht das Vertrauen der Anwender, weil sie etwas anfassen können. Die iGrafx-Methodik betont: „Sobald die Ziele des neuen Prozesses klar sind, ist es einfacher, Prototypen zu erstellen, mit denen neue Arbeitsabläufe getestet werden.“ Zwar ist dies oft ein iterativer Versuch-und-Irrtum-Prozess, aber dadurch werden wertvolle Erkenntnisse gewonnen. Wichtig: Ein Prototyp ist nicht das endgültige Produkt, sondern dient der Erprobung und Validierung, nicht als fertige Lösung (ähnlich wie im Design Thinking – ausprobieren, lernen, verbessern).

• Prozess-Simulation: Wie bereits erwähnt, kann eine Simulationstool eingesetzt werden, um den Prozess unter verschiedenen Bedingungen durchzuspielen – z.B. um zu sehen, ob er bei hohem Aufkommen an Tickets immer noch funktioniert oder wo Engpässe entstehen. „Die Integration von Prozesssimulationstools ermöglicht es, digitale Darstellungen jedes Prozesses zu erstellen und zu beurteilen, welcher die besten Ergebnisse bietet.“. Man könnte z.B. simulieren: Was passiert, wenn 100 Störmeldungen in einer Woche eingehen? – sind ausreichend Ressourcen eingeplant, oder bildet sich eine Warteschlange? Solche Simulationsergebnisse können zur Optimierung vor dem Realstart genutzt werden (etwa indem man Schwellenwerte für Eskalationen einführt oder zusätzliche Ressourcen für Peak-Zeiten vorsieht).

• Pilotbetrieb (Testlauf): In manchen Fällen wird ein Pilotprojekt durchgeführt, um die neuen Prozesse im Echtbetrieb auszuprobieren, allerdings in kleinem Umfang. Beispielsweise könnte man den Soll-Prozess „Instandsetzung“ zunächst in einem Pilot-Standort und für einen begrenzten Zeitraum live schalten. Dabei wird beobachtet, ob alles wie geplant abläuft, und es werden Erfahrungen gesammelt. Die Pilotanwender geben Rückmeldung, ob der Prozess verständlich und praktikabel ist. Etwaige Probleme können dann noch korrigiert werden, bevor das System konzernweit ausgerollt wird. Dies ist insbesondere bei sehr umfangreichen Prozessänderungen ratsam oder wenn erhebliche Veränderungen in den Arbeitsgewohnheiten der Mitarbeiter erforderlich sind.

• Abnahme und Freigabe: Die formelle Abnahme der Soll-Prozesse erfolgt, wenn alle relevanten Stakeholder (Fachbereichsleiter, Prozessowner, Projektleitung, ggf. Compliance/Revision) mit dem Ergebnis einverstanden sind. In der Praxis wird dazu oft ein Prozesshandbuch oder eine Dokumentation vorgelegt, die von den Verantwortlichen gegengezeichnet wird. Gerade bei externen Beratungsleistungen (wie „CAFM: Soll-Prozessdesign und Harmonisierung“) gehört es zum Leistungsumfang, dem Kunden diese Dokumentation zur Abnahme zu präsentieren. Abnahme bedeutet, dass die Organisation sich verpflichtet, die definierten Prozesse auch so umzusetzen. Daher sollte man vor Abnahme prüfen: Sind alle Voraussetzungen geschaffen (z.B. Kapazitäten, Budget, Systemfunktionalität)? Sind die Prozesse konform mit allen Anforderungen (hier kann es auch eine Freigabe durch die Rechtsabteilung oder Arbeitssicherheit geben, wenn relevant)? Sobald die Abnahme erfolgt ist, werden die Prozesse „offiziell“ und bilden die Grundlage für die Schulung und Implementierung.

Wichtig ist, dass die Validierung iterativ erfolgen kann. Es kann ruhig mehrere Runden von Reviews und Anpassungen geben – das ist normal, um einen optimalen Ablauf zu finden. Diese investierte Zeit zahlt sich beim Roll-out aus: Man vermeidet hektische Anpassungen im Echtbetrieb. Außerdem fördert das Einbinden der Endanwender in der Validierungsphase die Akzeptanz, denn sie sehen, dass ihr Feedback gehört wird.

Die „Trockenprobe“ der Soll-Prozesse ist ein unverzichtbarer Schritt, um aus dem theoretischen Modell eine praxistaugliche Lösung zu formen. Mit Prototypen und Tests lassen sich Kinderkrankheiten beseitigen, bevor es ernst wird. Sind alle zufrieden und hat der Prozess in Tests überzeugt, steht dem Live-Gang nichts mehr im Wege – die Prozesse gelten als abgenommen und bilden nun den Fahrplan für die Implementierung.

Die beste Prozessgestaltung nützt wenig, wenn die Menschen im Unternehmen nicht mitziehen. Daher geht Soll-Prozessdesign Hand in Hand mit Change-Management. Es gilt, alle Beteiligten frühzeitig einzubinden, Veränderungen transparent zu kommunizieren und die nötigen Fähigkeiten aufzubauen.

• Frühzeitige Einbindung der Stakeholder: Wie bereits an mehreren Stellen erwähnt, sollten Mitarbeiter und Führungskräfte, die die Prozesse ausführen, aktiv in die Gestaltung einbezogen werden. Dies ist nicht nur methodisch sinnvoll (weil die Fachleute vor Ort am besten wissen, wo Probleme und Chancen liegen), sondern schafft auch Ownership. Wenn Beschäftigte das Gefühl haben, sie konnten den neuen Prozess mitgestalten, identifizieren sie sich viel stärker damit und haben weniger Vorbehalte. In unserem Beispiel wurden daher Workshops vor Ort durchgeführt, um die neuen Abläufe gemeinsam festzulegen. Ein solcher partizipativer Ansatz verringert Widerstände, weil die Betroffenen nicht vor vollendete Tatsachen gestellt werden. Ein Sprichwort im Change-Management lautet: „People support what they help create.“ – genau das nutzt man hier. Auch während der Prozessanalyse kann man Stimmungsbilder einholen und aktive Key User oder Prozess-Champions definieren, die als Vertreter ihrer Bereiche fungieren. Stakeholder-Analyse: Zu Beginn sollte man ermitteln, welche Personengruppen vom Prozesswandel berührt werden (z.B. FM-Team, Nutzer/Mieter, IT, externe Dienstleister, Management) und diese gezielt einbeziehen.

• Kommunikation der Veränderungen: Ein strukturierter Kommunikationsplan ist essentiell, um alle Beteiligten auf die Reise mitzunehmen. Die Gründe und Ziele der Prozessharmonisierung müssen klar vermittelt werden: Warum ändern wir diesen Prozess? Welche Vorteile bringt das? Wenn Mitarbeiter den Sinn verstehen, sind sie eher bereit, alte Gewohnheiten aufzugeben. Es empfiehlt sich, regelmäßig zu kommunizieren, z.B. via Intranet-News, Rundschreiben oder Townhall-Meetings. Wichtig ist auch die Tonality: Veränderungen sollten nicht als Kritik an bisherigen Abläufen dargestellt werden, sondern als gemeinsamer Schritt nach vorn. Erfolgsgeschichten (z.B. „Standort X hat mit dem neuen Prozess bereits 20% Zeit gespart“) motivieren zusätzlich. Ebenso sollte offen über Herausforderungen gesprochen werden.

Mitarbeiter haben möglicherweise Sorgen (z.B. „Verliere ich durch Automatisierung meinen Aufgabenbereich?“ oder „Werde ich mich mit der neuen Software zurechtfinden?“). Das Change-Management muss solche Ängste ernst nehmen und adressieren. Es hat sich bewährt, Feedback-Kanäle zu schaffen – etwa eine dedizierte Mailbox für Fragen oder regelmäßige Q&A-Runden mit dem Projektleiter. „Wenn man den Mitarbeitern die Möglichkeit gibt, Bedenken zu äußern und Fragen zu stellen, verringert das ihren Widerstand gegen Veränderungen.“.

• Schulungen und Qualifizierung: Neue Prozesse erfordern oft neue Fähigkeiten. Daher muss ein Schulungskonzept Teil des Change-Managements sein. Die Mitarbeiter werden sowohl im Umgang mit dem CAFM-System als auch in den prozessualen Neuerungen trainiert. Beispielsweise könnte es separate Trainingsmodule geben: eins für die Softwarebedienung (wie melde ich einen Schaden im neuen Portal?) und eins für Prozessverständnis (was ändert sich organisatorisch, z.B. „Ab sofort meldet ihr Mängel nicht mehr per Telefon, sondern per Ticket, und so geht das…“). Verschiedene Lernformate sind möglich: Präsenzschulungen, E-Learning, Workshops, Handbücher. Wichtig ist Praxisnähe – die Schulung sollte an realistischen Fallbeispielen den neuen Ablauf durchspielen. Damit wird auch gleich eine Art Generalprobe veranstaltet.

Anfangs mag es haken, daher sind Anwenderunterstützung und Nachschulungen einzuplanen. Key User oder Superuser können als erste Anlaufstelle geschult werden, damit sie Kollegen unterstützen können (Train-the-Trainer-Prinzip). Die umfassende Qualifizierung der Mitarbeiter ist entscheidend, um aus einem auf dem Papier perfekten Soll-Prozess auch einen gelebten Prozess zu machen. „Die Schulung der Mitarbeiter in neuen Prozessen kann eine Herausforderung sein… die Entwicklung umfassender Schulungsprogramme und Einholen von Feedback kann Bereiche identifizieren, die mehr Klärung erfordern.“. Also: Schulungsinhalte nachbessern, wo Teilnehmer noch unsicher sind, und ruhig fragen, wo Unklarheiten bestehen.

• Führungskräfte und Vorbildfunktion: Das Management spielt im Change eine große Rolle. Top-Down-Unterstützung ist nötig, damit der Wandel nachhaltig gelingt. Führungskräfte sollten als Promotoren der neuen Prozesse auftreten, diese aktiv einfordern und selbst befolgen. Wenn z.B. ein neuer Freigabeprozess eingeführt wird, der Abteilungsleiter aber weiterhin „per Zuruf“ entscheidet und den Prozess umgeht, sendet das falsche Signale. Daher müssen auch die Führungskräfte vom Wandel überzeugt und ggf. geschult werden. Idealerweise kommunizieren sie die Vision hinter dem Soll-Prozessdesign: Wie dieser Wandel dem Unternehmen nützt (und auch den Mitarbeitern – z.B. Entlastung von Routine, modernere Arbeitsmittel).

• Kontinuierliche Kommunikation & Feedback nach Go-Live: Change-Management endet nicht mit dem Rollout. Es ist sinnvoll, nach Einführung der neuen Prozesse ein engmaschiges Monitoring der Stimmung und Performance zu machen. Beispielsweise kann man 4-6 Wochen nach Go-Live ein Feedback-Meeting veranstalten: Was läuft gut? Wo gibt es Schwierigkeiten? So zeigt man, dass man weiterhin zuhört und unterstützt. Probleme lassen sich früh auffangen, bevor Frustration entsteht. Zudem sollten Erfolge gefeiert werden – ein kleiner Newsletter: „1000 Tickets erfolgreich mit neuem System bearbeitet – danke an alle Beteiligten!“ kann Motivation geben.

Die Einführung neuer Soll-Prozesse ist ein betrieblicher Veränderungsprozess, der aktiv gemanagt werden muss. Erfolgsfaktoren sind: Einbindung, Transparenz und Befähigung.

• Einbindung der richtigen Leute zur richtigen Zeit (vor, während, nach der Gestaltung).

• Transparenz über das Was, Warum, Wie der Veränderung (gute Kommunikation, wenig Raum für Spekulation).

• Befähigung der Mitarbeiter durch Schulung und klare Anleitung, sodass sie sich in der neuen Prozesswelt zurechtfinden.

Wenn dies beherzigt wird, werden die Soll-Prozesse nicht als Bedrohung, sondern als Verbesserung wahrgenommen. Die Mitarbeiter wissen dann genau, was von ihnen erwartet wird und warum die neue Vorgehensweise Sinn ergibt. Das Ergebnis ist eine hohe Akzeptanz und ein flüssiger Übergang in die neue Arbeitsweise – entscheidend für den Erfolg des gesamten CAFM-Projekts.

Ein umfassendes Soll-Prozessdesign hinterlässt eine Reihe von Dokumentationen und Artefakten, die sowohl im weiteren Projektverlauf (z.B. für die Systemimplementierung) als auch im operativen Betrieb (als Nachschlagewerk und Schulungsgrundlage) von großem Wert sind. Diese Ergebnisse sollten strukturiert aufbereitet und allen Beteiligten zugänglich gemacht werden.

• Prozessmodelle (BPMN-Diagramme): Für jeden definierten Soll-Prozess wird in der Regel ein grafisches Prozessmodell erstellt. Wie oben beschrieben meist in BPMN 2.0, alternativ in anderen Flowchart-Formen. Diese Diagramme zeigen alle Schritte, Entscheidungen, Schleifen und Schnittstellen des Prozesses übersichtlich auf einer Seite. Sie dienen als zentrale Referenz – sowohl für Entwickler (die daraus System-Workflows ableiten) als auch für Fachbereiche (die damit intern die Abläufe kommunizieren können). Ein gutes Prozessmodell ist verständlich, vollständig und aktuell. Zum Beispiel könnte das Prozessmodell „Störungsbearbeitung“ als Swimlane-Diagramm darstellen: Lane 1 = Melder, Lane 2 = Helpdesk, Lane 3 = Techniker, mit allen Interaktionen. Solche Grafiken kann man in Schulungsunterlagen oder QM-Handbüchern verwenden. Wichtig: Versionsstand und Gültigkeitsdatum angeben, da Prozesse sich über die Zeit ändern können (eine Prozessdokumentation ist „eine dynamische Ressource, die aktuelle Änderungen widerspiegeln sollte“).

• Prozesslandkarte: Eine Prozesslandkarte (auch Prozesslandschaft genannt) bietet einen übergeordneten Blick auf alle FM-Prozesse und wie sie zusammenhängen. Oft wird sie als hierarchische Grafik dargestellt, z.B. in Form eines Hauses oder einer Landkarte, unterteilt in Managementprozesse, Kernprozesse, Supportprozesse. Die Prozesslandkarte im FM könnte z.B. zeigen: Managementprozesse (Strategisches FM-Planung, Budgetierung, Qualitätsmanagement), Kernprozesse (Instandhaltung, Flächen- und Umzugsmanagement, Reinigungsmanagement, Sicherheit & Gesundheitsschutz, etc.), Supportprozesse (IT-Support, Personal, Einkauf soweit sie FM betreffen). Jede dieser Kacheln würde wiederum auf detailliertere Prozessmodelle verweisen. Im Projekt Ziggo wurde beispielsweise eine Prozesslandkarte „Helpdeskmeldung“ erstellt, um den gesamten Ablauf von der Meldung bis zur Erledigung mit Schnittstellen auf einen Blick darzustellen. Solch eine Landkarte ist hilfreich, um allen Stakeholdern (v.a. höherem Management) zu vermitteln, welche Prozesse das FM umfasst und wie das Zusammenspiel ist. Sie dient als Orientierungsrahmen, in dem man die einzelnen Soll-Prozessmodelle verorten kann.

• Rollenbeschreibungen und -profile: Als Ergebnis der Rollen-Definition sollten Dokumente vorliegen, die jede Rolle im Soll-Prozessmodell beschreiben. Ein Rollenprofil umfasst typischerweise: Rollenname, Ziele der Rolle, Hauptaufgaben im Rahmen der Prozesse, Verantwortlichkeiten (ggf. Auszug aus RACI), erforderliche Kompetenzen/Befugnisse, Stellvertreterregelung. Diese Rollenbeschreibungen ähneln Stellenbeschreibungen, sind aber prozessfokussiert. Sie helfen insbesondere in der Übergabe an HR oder bei organisatorischen Anpassungen (z.B. falls neue Stellen geschaffen werden müssen, kann man das Profil direkt nehmen). Außerdem sind sie nützlich für die Schulung: Jeder Mitarbeiter kann nachlesen, was von der Rolle erwartet wird. Im RACI-Kontext könnte man auch pro Rolle eine RACI-Übersicht erstellen: z.B. "Facility Manager ist Responsible für A, B, C; Accountable für D; Consulted bei E; Informed bei F".

• RACI-Matrix: Oft wird die gesamte RACI-Matrix tabellarisch dokumentiert und als eigenes Artefakt bereitgestellt. Diese Matrix kann pro Prozess oder gesammelt für alle Prozesse dargestellt werden. Sie ist ein kompaktes Nachschlagewerk, um Verantwortlichkeiten schnell zu klären. Gerade im späteren Betrieb ist dies praktisch: Wenn Unklarheit herrscht, wer z.B. einen Prozessschritt freigeben muss, schaut man in die RACI-Matrix. Im Prozesshandbuch kann sie als Anhang beigefügt sein. Wichtig ist, auch hier die Aktualität zu wahren, wenn sich organisatorisch etwas ändert.

• Prozesshandbuch bzw. Arbeitsanweisungen/Leitfäden: Ein Prozesshandbuch fasst alle oben genannten Punkte in strukturierter Form zusammen. Es kann gegliedert sein nach Prozessgruppen und enthält zu jedem Prozess eine Beschreibung (Zweck, Geltungsbereich, Kennzahlen), das Prozessdiagramm, die beteiligten Rollen (mit RACI) und ggf. verknüpfte Dokumente. Das Prozesshandbuch dient als verbindlicher Leitfaden für die Organisation. In manchen Unternehmen fließt es in das Qualitätsmanagement-System ein, d.h. es unterliegt der Dokumentenlenkung und wird regelmäßig auditiert. Alternativ oder ergänzend kann es konkrete Arbeitsanweisungen bzw. SOPs (Standard Operating Procedures) geben, die die Ausführung einzelner Prozessschritte genau beschreiben. Beispielsweise ein Leitfaden „Störung melden“ für Endnutzer, der in einfachen Schritten erklärt, wie im neuen System eine Meldung abzusetzen ist (inkl. Screenshots). Oder eine Checkliste für Techniker zur Durchführung einer Wartung nach neuem Prozess. Diese praktisch orientierten Anleitungen sichern, dass die Theorie des Prozessmodells im Alltag richtig angewendet wird.

• Systemdokumentation zur Prozesskonfiguration: Da Prozesse und System eng verzahnt sind, gehört zu den Artefakten auch eine Dokumentation, wie die Prozesse im CAFM-System eingerichtet wurden. Das kann z.B. eine Beschreibung der angelegten Workflows im System sein (wer bekommt welche Task unter welchen Bedingungen) oder eine Dokumentation der Stammdatenstrukturen, die prozessrelevant sind (z.B. Kataloge für Ticketkategorien). Diese Infos sind für die IT-Übergabe und späteren Support relevant. Oft erstellt das Implementierungsteam hier ein Konfigurationsdokument. Es ist sinnvoll, diese Systemkonfiguration mit den fachlichen Prozessdokumenten abzugleichen, damit Konsistenz besteht (z.B. gleiche Begrifflichkeiten).

• Prozesskennzahlen und Reporting-Definitionen: Falls im Soll-Prozessdesign bereits KPIs und Reports festgelegt wurden, sollten auch diese dokumentiert werden. Beispielsweise: „Im Prozess XY wird die Kennzahl Durchschnittliche Durchlaufzeit erhoben als Differenz zwischen Meldedatum und Abschlussdatum pro Ticket.“ Solche Definitionen sind wichtig, damit alle dieselbe Interpretation haben und die IT weiß, was technisch umzusetzen ist (Feld für Meldedatum etc.). Ebenso werden eventuell Report-Layouts oder Dashboards entworfen, die später im System umgesetzt werden – auch diese können hier als Mock-ups oder Beschreibung vorliegen (gehören evtl. eher zum KPI-, Reportingkonzept, das parallel entsteht).

All diese Unterlagen sollten idealerweise zentral versioniert und leicht auffindbar sein (z.B. auf dem Intranet oder einem Dokumentenmanagementsystem). Es bietet sich an, einen „Single Point of Truth“ einzurichten – etwa ein Prozessportal, wo die aktuellen Freigaben der Prozessdokumentation liegen.

Die Dokumentation ist nie endgültig „fertig“, sondern sollte kontinuierlich gepflegt werden. Sobald im laufenden Betrieb Optimierungen vorgenommen werden, sind die Artefakte zu aktualisieren, um weiterhin verbindlich zu sein. Das Prozesshandbuch sollte z.B. jährlich oder bei größeren Änderungen überarbeitet und erneut freigegeben werden. Damit schließt sich der Kreis zur kontinuierlichen Verbesserung (KVP): Das Soll-Prozessdesign von heute ist die Ist-Basis von morgen, die wiederum verbessert werden kann.