West Midlands Fire Service verabschiedet sich von der Eigenentwicklung zugunsten von SaaS

Jede Engineering-Organisation erbt irgendwann ein Gebäude, das sie nicht selbst entworfen hat: ein knarzendes Inhouse-System, das als clevere Abkürzung begann und als tragende Infrastruktur endete, die niemand mehr anfassen will. Der West Midlands Fire Service hat gerade beschlossen, sein solches Gebäude abzureißen und stattdessen in eine möblierte Wohnung einzuziehen. Wer eine Plattform im öffentlichen Sektor betreibt – oder irgendeine Plattform mit einem zehn Jahre alten Custom-CRM im Keller – sollte das hier aufmerksam lesen.

Die Schlagzeile ist klein. Das Signal ist es nicht. Ein großer britischer Feuerwehr- und Rettungsdienst hat sich für eine kommerzielle Off-the-Shelf-SaaS-Lösung entschieden und damit den Quellcode aufgegeben, den das eigene Team jahrelang gebaut und gepflegt hat. Das ist das Gebäude, das abgerissen wird – und der Umzug ist das Thema des restlichen Artikels.

Das Problem

Der WMFS ist kein kleiner Betrieb. Wie das International Fire & Safety Journal berichtete, führt der Service jährlich mehr als 20.000 Safe-and-Well-Visits durch und erteilt über 30.000 Kindern Sicherheitsunterricht. Das ist ein ernsthaftes Volumen an Terminplanung, Risikoerfassung, Nachverfolgung und Ergebnisberichten – und das alles in Wohnzimmern und Schulhallen, nicht am Schreibtisch.

Das Inhouse-System, das rund um diese Arbeitsbelastung gewachsen ist, hat seinen Job mit ziemlicher Sicherheit lange gut erledigt. Maßgeschneiderte interne Tools tun das meistens – bis sie es nicht mehr tun. Das Versagensmuster ist selten ein dramatischer Ausfall. Es ist die schleichende Steuer: Jeder neue Fragebogen erfordert einen Entwickler, jedes Geräte-Upgrade bricht die Offline-Synchronisierung, jeder Prüfzyklus legt ein weiteres Feld frei, das niemand so recht erklären kann. Wer jemals versucht hat, einer jahrzehntealten internen CRM-Datenbank eine einzige Spalte hinzuzufügen, kennt das Meeting, das darauf folgt.

Emily Fernandez, Assistant Director for Prevention beim WMFS, beschrieb den Wechsel als Prozessvereinfachung und als Bereitstellung besserer Werkzeuge für die Teams. Liest man zwischen den Zeilen, erkennt man die Rahmenbedingungen, die sich verändert haben. Mobile-first ist für jede Außendienstbelegschaft längst selbstverständlich. Offline-taugliche Datenerfassung ist eine Erwartung, keine Feature-Anfrage. Die Integration mit Microsoft 365, SharePoint und Identity-Tools wie Entra ID ist zunehmend der Standard-Unterbau der IT im britischen öffentlichen Sektor – und eine maßgeschneiderte .NET-Anwendung aus dem Jahr 2014 würde diesen Anschluss wohl nie mehr reibungslos schaffen.

Es gibt auch einen stillen Druck: den Nachweis von Ergebnissen. Präventionsarbeit war schon immer schwer zu messen, und moderne Auftraggeber erwarten Belege. Wenn das Datenmodell ein individuelles Risikoprofil nicht bis zu einem messbaren Interventionsergebnis nachverfolgen kann, verliert man dieses Argument in jedem Budgetzyklus. Das Inhouse-System war aller Wahrscheinlichkeit nach dafür gebaut, Aktivitäten zu erfassen – nicht Wirkung zu belegen. Das ist ein völlig anderes Schema, und es nachzurüsten ist der Punkt, an dem alles zusammenbricht.

Die Optionen

Wenn eine öffentliche Stelle sich daran macht, ein langlebiges internes System zu ersetzen, stehen in der Regel drei Türen offen. Der WMFS wählte Tür zwei – aber die anderen beiden lohnen sich zu betrachten, denn die meisten Leser dieses Blogs werden in einem anderen Bereich vor derselben Wahl stehen.

Tür eins: intern neu aufbauen, moderner Stack. Das vorhandene Domain-Wissen nehmen, auf Azure oder AWS migrieren, einen React Native-Client davor schalten und fertig. Verlockend, besonders wenn man ein Team hat, das den Workflow bereits versteht. Die Falle ist die, die jeder CTO irgendwann lernt: Die ersten 80 % dauern ein Jahr, die letzten 20 % fünf, und bis das Feature für den Kamera-Upload fertig ist, haben sich die Smartphones um zwei OS-Generationen weiterentwickelt. Für einen Feuerwehrdienst, dessen Kernauftrag nicht das Schreiben von Software ist, ist das fast immer eine schlechte Wette.

Tür zwei: kommerzielle Off-the-Shelf-Lösung, vertikal spezifisch. Das ist, was der WMFS gewählt hat. LearnPro Groups Prevent + Protect ist speziell für Feuerwehr- und Rettungsdienste entwickelt, läuft auf Microsoft Azure und integriert sich in Microsoft 365-Dienste einschließlich SharePoint Online und Entra ID. Es nutzt No-Code-Konfiguration, sodass der Service selbst Auftragstypen, Fragebögen und Bewertungen anpassen kann, ohne ein Jira-Ticket zu erstellen. Russell Wood, LearnPros UKFRS Market Lead, bezeichnete den WMFS als „einen der größten und innovativsten Services im Land" – die Art von Zitat, die man gerne überliest, die aber Bedeutung hat: Vertikale SaaS lebt und stirbt mit ihren Referenzkunden.

Tür drei: horizontale Plattform plus umfangreiche Anpassung. Salesforce oder Dynamics 365 nehmen, die Präventions-Workflows darauf aufbauen, alles andere integrieren. Das ist die Option, die in der Ausschreibungsunterlage immer gut aussieht und am Ende meist mehr kostet als Tür eins. Die horizontalen CRMs sind leistungsstark, aber die Lücke zwischen „unterstützt Custom Objects" und „weiß, was ein Safe-and-Well-Visit ist", wird in Beratertagessätzen bezahlt. Für einen so domänenspezifischen Workflow wie die gemeinschaftliche Brandschutzprävention finanziert man im Grunde den Anbieter dabei, schlechte vertikale SaaS für einen selbst zu bauen.

Die Abwägungsmatrix hier ist nicht subtil. Tür eins gibt Kontrolle und eine dauerhafte Wartungsrechnung. Tür drei gibt eine vertraute Plattform und eine Beratungsabhängigkeit. Tür zwei gibt Geschwindigkeit und ein Vendor-Lock-in-Problem. Der WMFS hat offensichtlich entschieden, dass das Lock-in das geringere Übel ist – und ich würde sagen, das ist richtig, sofern der Vertrag entsprechende Datenportabilitätsklauseln enthält.

Was Engineering-Teams konkret tun sollten

Wer das als Plattformverantwortlicher aus dem iGaming-, Fintech- oder Ad-Tech-Bereich verfolgt, kann die Lektion verallgemeinern. Die Frage ist nicht, ob man abstrakt bauen oder kaufen soll. Es geht darum, ob der automatisierte Workflow der eigene Wettbewerbsvorteil oder das operative Fundament ist.

Aktivitätstracking im Präventionsbereich ist Infrastruktur für einen Feuerwehrdienst. Der eigentliche Vorteil sind die Feuerwehrleute, die Beziehungen zur Gemeinschaft, das operative Urteilsvermögen. Software, die erfasst, wer welches Haus besucht hat, welche Risiken markiert wurden und ob die SMS-Nachverfolgung eine Antwort bekam, ist Infrastruktur. Infrastruktur sollte gekauft, nicht gebaut werden – es sei denn, man kann einen konkreten Grund benennen, warum die eigene Infrastruktur anders sein muss als die aller anderen.

Das praktische Playbook: Zunächst ehrlich aufschreiben, was das Inhouse-System tut, das eine vertikale SaaS nicht könnte. Lautet die Antwort „es integriert sich in unsere seltsame Identity-Einrichtung" oder „es hat Felder, die niemand mehr nutzt", hat man die Antwort. Lautet sie „es enthält fünf Jahre Feinabstimmung, die direkt unsere Kern-KPIs beeinflusst", sollte man weiterbauen.

Zweitens: Beim Gang auf den Markt sollten architektonische Grundlagen stark gewichtet werden. Cloud-native und mobile-first sind in diesem Kontext keine Marketingbegriffe. Sie sind der Unterschied zwischen einem System, das die nächsten fünf Jahre Geräte- und OS-Fluktuation übersteht, und einem, das in drei Jahren neu geschrieben werden muss. Die Offline-Funktionen, die Routenplanung und die Kamera-/Datei-Upload-Unterstützung der Prevent + Protect-Plattform sind genau die langweiligen, aber unverzichtbaren Features, die ein Inhouse-Team jahrelang zurückstellen würde.

Drittens: Konsequent auf No-Code-Konfiguration bestehen. Der einzige größte Grund, warum Inhouse-Systeme gebaut werden, war, dass kommerzielle Alternativen für jede Dropdown-Änderung einen Entwickler benötigten. Moderne vertikale SaaS hat diese Lücke weitgehend geschlossen. Wenn ein Anbieter im Demo nicht zeigen kann, wie ein Nicht-Entwickler live einen Workflow ändert, sollte man das Gespräch beenden.

Fallstricke und Sonderfälle

Der Glanz einer Beschaffungsentscheidung verblasst am Tag, an dem die Implementierung beginnt. Einige Punkte, die man bei einem ähnlichen Wechsel im Blick behalten sollte.

Die Datenmigration aus einem langjährigen Inhouse-System ist fast immer schlechter als geschätzt. Maßgeschneiderte Datenbanken häufen undokumentierte Semantik an: ein Statuscode, der in Datensätzen vor 2019 eine Sache bedeutet und danach etwas anderes, ein Freitextfeld, das manche Teams als strukturierten Tag verwendet haben. Man sollte eine forensische Datenarchäologie-Phase einplanen, keine einfache ETL-Migration.

Die Microsoft 365-Integrationsstory klingt auf einer Folie aufgeräumt. SharePoint Online und Entra ID sind gut bekanntes Terrain, aber das Innenleben – Berechtigungsvererbung, Gastzugriff, Conditional-Access-Richtlinien – kann aus einer zweiwöchigen Integration eine zweivierteljährige machen. Das Identity-Team sollte vor der Vertragsunterzeichnung ins Boot geholt werden, nicht danach.

SMS-Feedback-Schleifen mit URL-Links zu maßgeschneiderten Fragebögen sind clever – und gleichzeitig ein Albtraum für Phishing-Schulungen, der sich anbahnt. Der gleiche Mechanismus, der dem WMFS ermöglicht, Interventionswirksamkeit zu messen, sieht identisch aus wie die Smishing-Muster, die jedes Sicherheitsteam den Bürgern beibringt zu ignorieren. Domainwahl, Link-Branding und Nachrichtenformulierung sind hier wichtiger als das Engineering.

Schließlich ist die No-Code-Konfigurationsfreiheit ein zweischneidiges Schwert. Gibt man jedem Team die Möglichkeit, neue Auftragstypen und Fragebögen anzulegen, hat man innerhalb von achtzehn Monaten ein Konfigurationschaos-Problem, das dem Schema-Chaos des gerade abgelösten Systems entspricht. Governance muss von Tag eins an eingebaut sein.

Wichtigste Erkenntnisse

• Der WMFS, der seine interne Präventionssoftware durch LearnPros Prevent + Protect ersetzt, ist ein klares Beispiel dafür, dass eine öffentliche Stelle entschieden hat, operative Infrastruktur in vertikaler SaaS statt in einem maßgeschneiderten Quellcode anzusiedeln.
• Cloud-native und mobile-first Architektur mit Offline-Funktionen und Microsoft 365-Integration über SharePoint Online und Entra ID ist heute die realistische Mindestanforderung für jede Außendienst-Plattform.
• No-Code-Konfiguration für Auftragstypen, Fragebögen und Bewertungen ist das Feature, das Organisationen historisch dazu gebracht hat, intern zu bauen. Moderne vertikale SaaS hat diese Lücke weitgehend geschlossen – und es sollte in jeder Ausschreibung nicht verhandelbar sein.
• Datenmigration, Identity-Integration und SMS-basierte Feedback-Muster sind die drei Bereiche, an denen Implementierungen am häufigsten scheitern. Sie sollten explizit eingeplant werden, nicht entdeckt werden.
• Die Build-vs-Buy-Entscheidung ist wirklich eine Frage danach, ob der Workflow der eigene Wettbewerbsvorteil oder die operative Infrastruktur ist. Der WMFS hat sie richtig beantwortet. Die meisten Engineering-Teams in regulierten Branchen sollten dieselbe Frage in diesem Quartal stellen.

Zurück zum Gebäude, mit dem wir begonnen haben. Der WMFS ist nicht nur aus dem knarzendem Haus ausgezogen – er hat einen Mietvertrag für eine möblierte Wohnung unterschrieben, in der die Mülltonne bereits geleert und das WLAN schon funktioniert. Der Tausch ist Autonomie gegen Geschwindigkeit, und für einen Dienst, dessen eigentliche Mission es ist, Menschen zu schützen statt Scheduler zu warten, ist das der richtige Tausch. Der Rest von uns, der auf eigenen alternden internen Tools sitzt, sollte zumindest am neuen Gebäude vorbeigehen und sich Notizen machen.