Der Ursprung liegt in der Frustration
Ich komme aus der IT – allerdings nicht im Sinne von Frameworks, Buzzwords oder trendigen Technologien, sondern im Sinne von Systemen, Logik und Zusammenhängen. IT ist für mich etwas, das man begreifen kann. Etwas, das Sinn ergibt, wenn man sich die Zeit nimmt, es wirklich zu verstehen.
Genau deshalb hat mich über die Jahre immer mehr gestört, wie mit Inspektionsdaten umgegangen wird. Nicht aus böser Absicht, sondern aus Mangel an passenden Werkzeugen. Man arbeitet mit dem, was verfügbar ist – auch wenn es eigentlich nicht passt.
Das Improvisieren mit falschen Werkzeugen
Für viele Arten von Inspektionen existiert bis heute keine spezialisierte Software. Man macht Fotos. Man filmt. Man sammelt Messwerte, Notizen und Eindrücke. Die eigentliche Arbeit findet draußen statt, in Anlagen, Behältern oder Gebäuden.
Und danach beginnt das Improvisieren.
Ordner werden angelegt, Bilder umbenannt, Dateien verschoben. Inhalte wandern in Word-Dokumente oder PowerPoint-Folien, werden kopiert, neu angeordnet, kommentiert. PDFs entstehen, Versionen gehen verloren, Zusammenhänge verschwimmen.
Diese Werkzeuge sind nicht falsch. Aber sie sind für etwas anderes gebaut worden. Sie bilden weder Raum noch Kontext noch Prozess ab.
Das strukturelle Problem der Softwareentwicklung
Viele der Softwarelösungen am Markt orientieren sich nicht an den tatsächlichen Abläufen einer Inspektion. Sie sind technisch beeindruckend, funktionsreich und sauber programmiert – aber im Alltag oft schwerfällig.
Das ist kein Vorwurf an einzelne Entwickler. Es ist ein strukturelles Problem. Eine Software kann nur so gut sein wie das Verständnis der Prozesse, die sie abbilden soll. Und viele Programmierer haben mit diesen realen Abläufen schlicht nichts zu tun.
Inspektion ist aber kein theoretischer Vorgang. Sie ist situativ, räumlich, manchmal chaotisch und nie vollständig planbar.
Software trägt immer die Denkweise ihres Erstellers
Über die Jahre habe ich gelernt: Software ist kein neutrales Werkzeug. Sie trägt immer die Denkweise ihres Erstellers in sich.
Wenn jemand Prozesse nicht selbst erlebt hat, werden sie zwangsläufig abstrahiert. Vereinfacht. Verallgemeinert. Was dann entsteht, sind Systeme mit zu vielen Funktionen, falschen Prioritäten und Bedienkonzepten, die im Alltag eher stören als helfen.
Sicherheit als Teil der Architektur
Inspektionen erzeugen häufig hochsensible Daten: Bilder von Anlagen, Gebäuden, sicherheitsrelevanten Bereichen oder personenbezogene Informationen. Standardtools und fremde Cloud-Dienste bergen hier Risiken.
Selbstentwickelte Software erlaubt es, Verschlüsselung, feingranulare Rechteverwaltung und Nachverfolgbarkeit von Anfang an mitzudenken. Sicherheit wird nicht nachträglich ergänzt, sondern ist Teil der Architektur.
Integration statt Insellösung
In der Praxis arbeiten Unternehmen selten mit nur einem System. ERP-, CRM- oder andere Fachanwendungen sind längst etabliert. Eine Inspektionssoftware, die isoliert bleibt, erzeugt am Ende wieder das, was man eigentlich vermeiden wollte: manuelles Kopieren, Medienbrüche und Improvisation.
Deshalb plane ich offene Schnittstellen und flexible Export- und Importformate ein. Die Software muss sich in bestehende Strukturen einfügen – nicht das Unternehmen seine Prozesse um die Software herum verbiegen.
Benutzerakzeptanz entscheidet
Die besten Funktionen nützen nichts, wenn sie im Alltag nicht angenommen werden. Gerade Inspektoren vor Ort brauchen Werkzeuge, die sie unterstützen und nicht ausbremsen.
Deshalb entwickle ich mobil-first, mit klaren Bedienkonzepten und frühem Nutzer-Feedback. Die Software soll den Arbeitsalltag erleichtern, nicht zusätzliche Hürden aufbauen.
Wo Standardisierung endet
Ich entwickle Software nicht, weil ich noch ein weiteres Tool bauen möchte. Ich tue es, weil Standardlösungen an einem bestimmten Punkt aufhören, sinnvoll zu sein.
Inspektionen sind zu individuell, zu kontextabhängig und zu verantwortungsvoll, um sie vollständig zu abstrahieren. Genau deshalb müssen auch die Werkzeuge individuell sein: reduziert, zweckgebunden und verständlich.
Ich glaube nicht an perfekte Software. Ich glaube an Werkzeuge, die aus der Praxis heraus entstehen – mit all ihren Ecken und Kanten, aber mit einem tiefen Verständnis für den realen Einsatz.
