Ein zweiter Kanal zur Fachanwendung statt einer zweiten Wahrheit

Ein zweiter Kanal zur Fachanwendung ist keine zweite Anwendung, sondern eine zweite Eingabe auf dieselbe Datenbasis. Dieselbe Datenbank, dieselbe Rechtelogik, dieselben Regeln, nur bedienbar dort, wo niemand an einem Schreibtisch sitzt: im Lager, in der Werkstatt, im Außendienst. Warum diese Unterscheidung über den Aufwand entscheidet.

Was ein zweiter Kanal zur Fachanwendung technisch bedeutet

Die Anfrage kommt meist in einer von zwei Formen: Gesucht wird eine App für die Leute im Lager, oder es heißt, die vorhandene Software könne alles, aber nur am Rechner. Beides beschreibt dieselbe Lücke. Das führende System steht, es ist über Jahre gewachsen, es bildet die Fachlichkeit ab. Was fehlt, ist eine Eingabe an dem Ort, an dem die Daten entstehen.

Technisch ist die Antwort darauf schmal. Die mobile Oberfläche bildet nicht das System ab, sondern drei bis fünf Handgriffe: erfassen, scannen, bestätigen, fotografieren, abschließen. Sie spricht mit demselben Server, über dieselbe Schnittstelle, die auch die Weboberfläche benutzt. Wer welche Aktion ausführen darf, entscheidet weiterhin die Rechtelogik des führenden Systems – nicht eine zweite Rollenverwaltung im Telefon.

Der teure Gegenentwurf sieht auf den ersten Blick schneller aus: eine eigenständige Anwendung mit eigener Datenhaltung, die abends abgeglichen wird. Sie ist in der ersten Version tatsächlich früher fertig. Danach beginnt die Arbeit, die niemand einkalkuliert hat – zwei Datenstände, zwei Regelwerke, ein wöchentlicher Abgleich und die Frage, welcher Stand im Zweifel gilt. Genau diese zweite Wahrheit wollen wir vermeiden.

8 Kassen und 93 Lagerpositionen ohne manuelle Eingabe

Der Nutzen eines zusätzlichen Eingabewegs lässt sich an derselben Größe messen wie bei einer Anbindung: an der Handarbeit, die danach entfällt, und an der Abweichung zwischen zwei Ständen. Zwei Zahlen aus Projekten im Lebensmittelhandel zeigen die Größenordnung.

• 8 Kassen täglich ohne manuelle Eingabe, Abgleich auf den Cent. Vorher wurden Tageswerte abends abgetippt; danach kommen die Positionszeilen aus dem Kassensystem und werden gegen die Zählung geprüft.
• 93 Lagerpositionen ohne manuelle Eingabe. Der Bestand einer Produktion steht im Steuerpult, statt aus einer Tabelle des Vortages rekonstruiert zu werden.

Beide Zahlen stammen nicht aus einer mobilen Anwendung, und wir stellen sie hier bewusst nicht als solche dar. Sie stammen aus demselben Prinzip eine Ebene tiefer: Der Ort, an dem Daten entstehen, wird direkt an das führende System angeschlossen, statt über einen Menschen mit Tastatur. Eine mobile Oberfläche ist der Fall, in dem dieser Ort ein Mensch mit einem Telefon ist – die Frage nach der Abweichung zwischen zwei Ständen bleibt dieselbe, und sie ist die Frage, an der wir die Abnahme festmachen.

Praktisch heißt das: Das Abnahmekriterium eines solchen Vorhabens ist keine Bildschirmfolge, sondern ein Vergleich. Erfasste Menge gegen gebuchte Menge, erfasste Position gegen Beleg, Zeitstempel gegen Schicht. Was sich nicht vergleichen lässt, taugt nicht als Kriterium – dann ist die Abnahme eine Geschmacksfrage, und das ist der Anfang der meisten Streitigkeiten über Software.

Wo wir von einer eigenen App abraten

Nicht jede Lücke braucht eine installierte Anwendung. Drei Fälle, in denen wir abraten oder zuerst den kleineren Weg vorschlagen:

1. Es wird nur gelesen. Wenn draußen niemand etwas erfasst, sondern alle nur nachsehen, reicht eine für das Telefon gebaute Weboberfläche. Was eine Progressive Web App dabei leisten kann und wo sie aufhört, steht im Lexikon.
2. Der Prozess ist noch nicht entschieden. Wenn im Haus umstritten ist, wer welchen Schritt bestätigt, wird die mobile Oberfläche zur Bühne dieses Streits. Dann gehört der Schritt zuerst in die Leistungsbeschreibung und erst danach in Code.
3. Der Betrieb ist offline. Funklöcher im Lager oder auf der Baustelle sind lösbar, aber nicht nebenbei. Der Teil, der dabei regelmäßig unterschätzt wird, ist nicht die Oberfläche, sondern die Auflösung von Konflikten: Zwei Leute ändern denselben Datensatz, beide waren offline, und das System muss entscheiden, welche Änderung zählt. Diese Regel ist Fachlichkeit, keine Technik – wir schreiben sie vor dem Bauen auf und lassen sie bestätigen.

Die Veröffentlichung in den Stores ist ebenfalls ein eigener Arbeitsblock mit eigenen Regeln des Betreibers, nicht ein Häkchen am Ende. Wer ihn in der Planung vergisst, hat eine fertige Anwendung und keinen Weg zu den Telefonen der eigenen Leute.

Zweiter Kanal zur Fachanwendung: wie wir vorgehen

Wir beginnen nicht mit Entwürfen, sondern mit dem bestehenden System: Welche Schnittstellen gibt es, welche Rollen kennt es, welche Vorgänge sind abgeschlossen und welche halbfertig. Daraus entsteht eine Liste der Handgriffe, die nach draußen sollen, und für jeden Handgriff ein prüfbares Kriterium. Diese Liste ist der Umfang, und sie steht im Angebot, bevor jemand anfängt.

Gebaut wird dann gegen dasselbe Repository und in demselben Releasezyklus wie der Rest. Was das im Einzelnen bedeutet und wie wir es vertraglich fassen, steht auf der Seite App-Entwicklung als zweiter Kanal. Geliefert wird in Teilen: erst ein Handgriff, der im Betrieb steht, dann der nächste. Fachliche Anweisungen laufen über unsere Projektleitung; mit vollständiger Bezahlung gehen die Nutzungsrechte am eigens erstellten Code auf den Auftraggeber über.

Am Ende zählt eine einzige Eigenschaft: Der zusätzliche Weg darf das führende System nicht in Frage stellen. Es bleibt die eine Quelle, die Ihre Leute im Haus kennen und pflegen. Alles, was draußen erfasst wird, landet dort – geprüft, mit denselben Rechten, in derselben Sprache der Fachlichkeit. Wird diese Eigenschaft aufgegeben, entsteht kein Kanal mehr, sondern ein zweites System, das irgendwann jemand abgleichen muss.