Eine Standardlösung war im Einsatz. Gebaut wurde trotzdem.

Zwei Betriebe aus der Tor-, Tür- und Zutrittstechnik hatten eine Standardsoftware für ihre Einsätze im Haus. Sie deckte den Alltag ab, nicht aber die Stellen, an denen die Arbeit hängt: die Akte einer Anlage über Jahre, die Rückmeldung aus einem Technikraum ohne Netz. materium software hat dafür eine eigene Field-Service-Software gebaut. Was sie können muss, wurde vorher an echten Kundendaten geprüft.

2kunden produktiv

1standard abgelöst

Eure Standardsoftware passt nicht zu euren Abläufen?

Kostenloses Erstgespräch buchen

Steckbrief

Kunde: Zutrittswerk Gruppe (Tor-, Tür- und Zutrittstechnik) · ein zweiter Betrieb derselben Branche
Zeitraum: PoC-Phase abgeschlossen, danach Ausbau in Etappen, fertiges Produkt bei beiden Kunden
Umfang: Einsatzsteuerung
Anlagenakte
Offline-Betrieb
Rückmeldung vom Einsatzort
Art des Belegs: Projektstatus und dokumentierte Machbarkeits- und Lasttests an echten Kundendaten

Die ganze Geschichte

Ausgangslage

Der Standard war da. Die Schmerzpunkte blieben.

Beide Betriebe warten und prüfen technische Anlagen beim Kunden vor Ort: Tore, Türen, Zutrittstechnik. Für die Einsatzsteuerung war eine Standardlösung im Einsatz. Sie deckte den allgemeinen Teil ab, den Termin, den Auftrag, die Adresse.

Sie fehlte an drei Stellen, und dort hängt die eigentliche Arbeit:

Die Geschichte einer Anlage über Jahre, nicht nur der nächste Auftrag.
Die Rückmeldung aus einem Technikraum, in dem stundenlang kein Netz ist.
Das Prüfergebnis gehört zur Anlage, nicht zum Auftrag.

Das ist der Fall, für den es unsere Nein-Liste gibt: Wir empfehlen keine Standardsoftware und verkaufen keine. Wenn ein eingesetzter Standard den Ablauf nicht trägt, stellen wir die Frage, welches Stück wirklich fehlt.

Aufgabe

Vor dem Bau: an echten Daten gegenprüfen.

Statt einen Anforderungskatalog zu schreiben, wurden die kritischen Annahmen vorab getestet: mit Machbarkeits- und Lasttests an echten Kundendaten und mit Begehungen vor Ort. Geklärt wurde dabei, was sich in einem Workshop nicht klären lässt.

Drei Fragen waren dabei zu lösen:

Wie verhält sich die Anwendung, wenn im Technikraum stundenlang kein Netz da ist?
Trägt das Datenmodell die gewachsene Anlagenhistorie, oder nur den nächsten Auftrag?
Was passiert bei Rückkehr ins Netz, wenn zwei Leute dieselbe Anlage bearbeitet haben?

Diese Tests sind der Grund, warum der spätere Bau ohne die üblichen Überraschungen ausgekommen ist. Sie sind heute die Blaupause für den Machbarkeits-Sprint, der einem Projekt vorausgeht, wenn noch offen ist, ob es trägt.

Was gebaut wurde

Einsatzliste, Anlagenakte, Offline-Betrieb.

Entstanden ist eine Field-Service-Anwendung für den Einsatz beim Kunden. Der Techniker bekommt auf dem Gerät alles, was er für den Termin braucht, und gibt zurück, was er vorfindet:

Einsatzliste. Termine, Anlagen, Ansprechpartner und Unterlagen für den Tag, an einer Stelle.
Anlagenakte. Die Geschichte der jeweiligen Anlage über Jahre: was verbaut ist, was geprüft wurde, was beim letzten Mal auffiel.
Rückmeldung vor Ort. Prüfergebnis und Bericht entstehen am Einsatzort und gehören zur Anlage, nicht zum Auftrag.
Offline als Normalfall. Gearbeitet wird ohne Netz, abgeglichen wird, sobald wieder Netz da ist.

Gebaut wurde in Etappen mit festem Umfang. Nach der abgeschlossenen PoC-Phase folgte der Ausbau Schritt für Schritt. Bei beiden Kunden steht heute ein fertiges Produkt. Bei Zutrittswerk ist die Anwendung zusätzlich an das neue ERP angebunden. Dieser Teil ist unter Schnittstellen und Systemintegration beschrieben.

Einsatzliste im Funkloch: erfasst wird weiter, die Anlagenakte samt Historie liegt auf dem Gerät.

Ergebnis

Was dieser Fall zeigt.

Der Beleg ist die Ablösung selbst: Eine Standardlösung war im Einsatz, sie hat die Schmerzpunkte nicht gelöst, und danach ist bei zwei Kunden ein fertiges Produkt entstanden.

„Früher bedeutete Außendienst ein Chaos aus Excel-Listen und Telefonaten. Dank der Software sind Wartungen, Anfahrtswege und Einsätze jetzt optimal im Voraus geplant, während die Rückmeldungen nahtlos in die digitale Anlagenakte fließen. Das spart uns unnötige Fahrten und macht unsere Einsatzplanung extrem effizient. Die Zusammenarbeit [mit materium software] verlief agil und problemlos. Das Tool ist perfekt auf unsere Abläufe abgestimmt, so hätten wir es mit einer Standardlösung nie hinbekommen.“

Christoph Merkt, Gründer und Geschäftsführer, Zutrittswerk Gruppe

Was der Fall zeigt

Bei zwei Betrieben läuft heute ein fertiges Produkt im Tagesgeschäft.
Eine eingesetzte Standardlösung wurde abgelöst, weil sie die entscheidenden Stellen nicht trug.
Die kritischen Annahmen, Offline-Betrieb und Anlagenhistorie, wurden vor dem Bau an echten Kundendaten getestet.
Erst prüfen, dann bauen erspart die üblichen Überraschungen. Das Vorgehen ist heute unser Machbarkeits-Sprint.

Eine Wirkungszahl, etwa eingesparte Minuten, wurde für diese Anwendung nicht gemessen.

Wie es weitergeht

Was als Nächstes ansteht.

Bei Zutrittswerk läuft der Ausbau der angebundenen Systeme weiter. Eine KI-Wissensdatenbank ist im Aufbau, nicht produktiv. Für die Field-Service-Anwendung selbst geht es um Betrieb und Weiterentwicklung, geregelt als eigener Vertrag.

Die Leistung hinter diesem Fall beschreibt Individualsoftware. Wie Betrieb, Übergabe und die Exit-Regel geordnet sind, steht auf Zusammenarbeit. Welche Faktoren den Aufwand für so eine Anwendung treiben, erklärt der Artikel Was kostet Individualsoftware?

Aktualisiert am 06. Oktober 2026 · Autor: Timo Reum

Der nächste Schritt

Ein Standard, der den Ablauf nicht trägt?

30 Minuten am Telefon, danach eine Seite schriftliche Einschätzung. Wer lieber schreibt, schickt das Anliegen schriftlich.

Kostenloses Erstgespräch buchen Anliegen schriftlich schicken

Alle Projekte ansehen