Digitale Anwendungen

Am Anfang steht kein Entwurf der Oberfläche, sondern der Prozess. Wir schreiben auf, wer welche Daten anlegt, wer sie freigibt, wer sie sehen darf und was am Ende damit geschieht. Daraus entsteht ein Datenmodell mit Entitäten, Beziehungen, Pflichtfeldern und Statuswechseln. Erst danach sprechen wir über Masken und Schaltflächen.

Die Umsetzung läuft in kurzen Zyklen. Wir liefern früh eine lauffähige Version mit dem Kern des Prozesses, lassen sie von den Menschen testen, die später damit arbeiten, und bauen die Nebenwege danach aus. Als technische Basis nutzen wir je nach Anforderung WordPress mit eigenen Post-Types und REST-Endpunkten, ein PHP-Framework wie Laravel oder ein JavaScript-Frontend auf einer eigenen API.

Zum Umfang gehört auch das, was selten im Lastenheft steht: Rollen und Rechte, eine Historie der Änderungen, der Import bestehender Datenbestände, Benachrichtigungen per E-Mail, Exporte für die Buchhaltung und eine Testumgebung, auf der Sie Änderungen prüfen können, bevor sie produktiv gehen.

Eine eigene Anwendung lohnt sich, wenn der Prozess selbst ein Unterscheidungsmerkmal ist. Wer Konfigurationen kalkuliert, Termine mit Maschinen und Personal verplant, Angebote aus Stücklisten erzeugt oder Kundendaten aus mehreren Quellen zusammenführt, findet dafür selten ein Standardprodukt, das ohne Verrenkungen passt.

Der zweite typische Anlass sind gewachsene Tabellenlandschaften. Wenn eine Excel-Datei per Mail zwischen Abteilungen wandert, mehrere Versionen parallel existieren und niemand mehr sagen kann, welche die gültige ist, löst eine Anwendung mit Nutzerkonten, Änderungshistorie und klaren Zuständigkeiten dieses Problem an der Wurzel.

Nicht sinnvoll ist eine Eigenentwicklung, wenn ein etabliertes Produkt den Bedarf weitgehend abdeckt und der Rest über eine Schnittstelle oder eine Erweiterung lösbar ist. Buchhaltung, Lohnabrechnung und Warenwirtschaft kauft man besser ein, statt sie nachzubauen. Wir sagen das auch dann, wenn es gegen den größeren Auftrag spricht, und beschreiben stattdessen, welche Ergänzung rund um das Standardsystem den eigentlichen Unterschied macht.

Das Rechtekonzept entscheidet später über den Aufwand. Wir klären früh, ob Berechtigungen an Rollen hängen oder an einzelnen Datensätzen, ob Vorgesetzte die Vorgänge ihres Teams sehen sollen und ob externe Beteiligte einen eigenen, eingeschränkten Zugang brauchen. Nachträglich in ein fertiges Datenmodell eingezogen, wird daraus ein Umbau statt einer Ergänzung.

Bei der Anmeldung nutzen wir vorhandene Verzeichnisse, wo es sie gibt. Ein Login über Microsoft Entra ID oder Google Workspace erspart eine zweite Passwortverwaltung und sorgt dafür, dass ein gesperrtes Konto auch in der Anwendung gesperrt ist. Wo eigene Konten nötig sind, gehören Zwei-Faktor-Authentifizierung und ein sauber gebauter Passwort-Reset dazu.

Zum Betrieb gehören Backups, die schon einmal zurückgespielt wurden, ein Fehlerprotokoll, das tatsächlich jemand liest, und die Trennung von Entwicklungs-, Test- und Produktivumgebung. Für Rechenwege, an denen Geld hängt, hinterlegen wir automatisierte Tests. Außerdem halten wir fest, welche Abhängigkeiten in welchem Rhythmus aktualisiert werden müssen.