Apps für Außendienst und Kundenportale

Viele Anfragen zur App-Entwicklung beschreiben bei genauerem Hinsehen einen Fall für den Browser. Die Mitarbeiter sitzen im Büro oder im Fahrzeug mit stabilem Empfang, greifen auf dieselben Daten zu wie am Desktop und brauchen weder Barcodescanner noch Push-Nachricht auf dem Sperrbildschirm. Dann kostet eine App mehr, als sie einbringt: zwei Codebasen statt einer, eine Store-Freigabe bei jedem Update, dazu Nutzer, die auf einer alten Version sitzen bleiben, weil sie das Update nicht installieren.

Wir sagen Ihnen das im Erstgespräch, auch wenn ein App-Projekt für uns das größere Budget wäre. Ein responsives Portal im Browser lässt sich schneller bauen und in Minuten aktualisieren. Das Preisband weiter unten gilt für App-Projekte; ein vergleichbares Portal liegt regelmäßig darunter.

Wann sich der Aufwand trägt

• Die Arbeit findet dort statt, wo kein Netz ist: Keller, Tiefgaragen, Hallen mit Stahlbeton, ländliche Baustellen, Kühlräume. Der Nutzer muss weiterarbeiten können und die Daten später übertragen.
• Das Gerät selbst ist Teil des Arbeitsschritts: Kamera für Schadensdokumentation, Barcode- und QR-Scanner im Lager, NFC für Anlagenkennzeichnung, GPS für Nachweise, Unterschrift auf dem Display.
• Die App muss aktiv auf den Nutzer zugehen, wenn sie geschlossen ist: Push bei neuem Auftrag, bei Störmeldung, bei Fristablauf. Der Browser kann das auf iOS nur eingeschränkt.

Trifft keiner dieser Punkte zu, bleibt als Argument oft nur das Icon auf dem Startbildschirm. Dafür genügt eine Progressive Web App, die sich installieren lässt, ohne dass ein Store dazwischensteht.

Die Entscheidung wird häufig als Technologiefrage geführt. Sie hängt an zwei praktischen Punkten: wie tief die App ins Betriebssystem greift und wie viele Codebasen Sie über Jahre pflegen wollen.

Für Wartungs-, Außendienst- und Lagerapps fällt die Wahl bei uns meist auf Cross-Platform, weil sich damit eine Fachlogik für beide Plattformen halten lässt. Der Preis dafür: Bei größeren iOS- oder Android-Versionssprüngen kann das Framework Anpassungen brauchen, bevor Ihre App wieder durch den Store geht. Das ist laufender Aufwand, den Sie von Anfang an einplanen müssen.

Eine PWA kann auf iOS Push-Nachrichten nur senden, wenn der Nutzer sie vorher über den Teilen-Dialog zum Home-Bildschirm hinzugefügt hat. In der Praxis tut das ein Teil der Belegschaft nicht. Wenn Push für Ihren Prozess tragend ist, ist die PWA die falsche Wahl.

Eine App, die nur mit Verbindung arbeitet, ist ein Formular mit hübscher Oberfläche. Eine App, die ohne Verbindung arbeitet, ist eine verteilte Datenbank. Dazwischen liegt der größte Kostensprung im ganzen Projekt, und er entsteht beim Zusammenführen der Daten, nicht beim Speichern auf dem Gerät.

Die Fragen, die vor der Kalkulation beantwortet sein müssen

• Was passiert, wenn zwei Techniker denselben Auftrag offline bearbeiten und beide synchronisieren? Gewinnt der spätere Zeitstempel, der Bearbeiter mit höherer Rolle, oder muss ein Mensch entscheiden?
• Welche Daten müssen auf dem Gerät liegen, bevor der Nutzer losfährt? Der gesamte Anlagenbestand oder nur die Objekte der heutigen Tour? Der Unterschied entscheidet über Ladezeit und Speicherbedarf.
• Was ist der Zustand nach einem Abbruch mitten in der Synchronisation? Halbe Aufträge sind schlimmer als gar keine.
• Wie lange darf ein Gerät offline bleiben, bevor die lokalen Daten als veraltet gelten und gesperrt werden?
• Wo liegen Fotos und Unterschriften bis zur Übertragung, und was passiert mit ihnen, wenn das Gerät verloren geht?

Wir klären diese Punkte in der Analysephase und schreiben die Konfliktregeln ins Feinkonzept, bevor eine Zeile Code entsteht. Die ehrliche Einschränkung: Kein Synchronisationsmodell löst jeden Konflikt automatisch richtig. Für den Rest bauen wir eine Ansicht, in der ein Disponent die Kollisionen sieht und entscheidet. Wer Ihnen vollautomatische Konfliktauflösung ohne Rückfrage verspricht, hat entweder Ihren Prozess nicht verstanden oder verschiebt das Problem in den Betrieb.

Bei mexxenergie haben wir eine verwandte Aufgabe serverseitig gelöst: Die Migration lief im laufenden Betrieb, mit Abgleichszahlen vor und nach jedem Lauf, damit zu jedem Zeitpunkt nachweisbar blieb, welche Datensätze übernommen wurden. Für Gerätesynchronisation gilt derselbe Anspruch, jeder Übertragungsversuch wird protokolliert und ist im Nachhinein zählbar.

• Projekt mexxenergie

Wartungs- und Technikerapps

Auftragsliste für den Tag, Anlagenhistorie am Gerät, Checklisten nach Wartungsplan, Fotodokumentation, Materialverbrauch, Unterschrift des Kunden auf dem Display, Bericht als PDF direkt aus dem Termin. Der Nutzen entsteht weniger im Feld als danach: Der Auftrag ist beim Verlassen des Objekts abgeschlossen und wartet nicht bis zum Abend im Büro.

Außendienst

Kundenakte mit letzten Bestellungen und offenen Posten, Besuchsberichte, Angebotserfassung vor Ort, Tourenplanung. Die eigentliche Arbeit liegt hier fast immer in der Anbindung an ERP oder CRM. Wie wir Bestandssysteme anbinden, steht unter Schnittstellen.

Lager und Kommissionierung

Scannen von Artikel und Lagerplatz, Kommissionierlisten, Wareneingang, Inventur. Hier lohnt eine Vorabprüfung der Hardware: Der Kamerascanner eines Standard-Smartphones ist langsamer als ein dedizierter Handheld-Scanner. Bei hohen Pickzahlen pro Schicht gibt dieser Unterschied den Ausschlag, und dann ist die Gerätewahl wichtiger als die App.

Mitarbeiter-Apps

Zeiterfassung, Urlaubsanträge, Schichtpläne, Dokumente, interne Meldungen. Sobald Standortdaten oder Durchlaufzeiten erfasst werden, ist der Betriebsrat nach § 87 Abs. 1 Nr. 6 BetrVG zu beteiligen. Der Punkt kann den Zeitplan um Wochen verschieben. Klären Sie ihn vor dem Projektstart.

Kundenportale als PWA

Zählerstände melden, Verträge und Rechnungen einsehen, Störungen melden, Termine buchen. Für diese Fälle ist die PWA meist die bessere Wahl als eine Store-App: Ihre Kunden installieren selten etwas für einen Vorgang, den sie dreimal im Jahr haben. Ein Link, der im Browser sofort funktioniert, wird genutzt. Mehr dazu unter Kundenportal-Software.

• Schnittstellen zu ERP, CRM und Bestandssystemen
• Kundenportal-Software
• Mieterportal für die Wohnungswirtschaft

Zwischen fertiger App und installierbarer App liegen bei Apple und Google Prüfverfahren, die Sie nicht steuern können. Die Erstveröffentlichung ist dabei der kritische Punkt, spätere Updates laufen in der Regel schneller durch.

• Entwicklerkonten laufen auf Ihren Namen, nicht auf unseren. Bei Apple erfordert das eine Organisationsprüfung mit D-U-N-S-Nummer; falls Ihr Unternehmen noch keine hat, beantragen Sie sie früh, denn die Vergabe liegt außerhalb des Projektzeitplans.
• Apple prüft jede Einreichung manuell. Ablehnungen sind normal und meist formal begründet: fehlende Demo-Zugangsdaten für den Prüfer, unklare Datenschutzangaben, ein Login ohne Testkonto. Jede Runde kostet Kalendertage.
• Sammelt Ihre App Daten, brauchen beide Stores ausgefüllte Datenschutzangaben, die zu Ihrer Datenschutzerklärung passen. Widersprüche fallen in der Prüfung auf.
• Reine Mitarbeiter-Apps müssen nicht in den öffentlichen Store. Apple Business Manager und Managed Google Play verteilen intern, ohne öffentliche Sichtbarkeit. Das spart die Prüfung auf Apple-Seite nicht vollständig, vereinfacht aber Rollout und Gerätebindung.
• Eine PWA umgeht das Verfahren vollständig. Sie veröffentlichen ein Update, und beim nächsten Aufruf ist es da.

Planen Sie für die Erstfreigabe im Apple App Store Puffer ein und legen Sie den Go-live nicht auf einen festen Stichtag, an dem eine Messe oder eine Kampagne hängt. Wir haben auf die Prüfdauer keinen Einfluss und versprechen deshalb kein Datum, das wir nicht halten können.

1. Analyse und Feinkonzept, 1 bis 3 Wochen. Anwendungsfälle, Offlineverhalten, Konfliktregeln, Schnittstellen, Geräteauswahl.
2. Entwicklung in Zwei-Wochen-Takten, 6 bis 20 Wochen. Nach jedem Takt eine installierbare Testversion auf Ihren eigenen Geräten.
3. Datenmigration und Tests, 2 bis 4 Wochen. Feldtest mit echten Nutzern an echten Orten, einschließlich der Keller ohne Empfang.
4. Go-live und Schulung, 1 bis 2 Wochen. Store-Einreichung oder interne Verteilung, Einweisung der Nutzer.
5. Betreuung, laufend. OS-Updates, Framework-Aktualisierungen, Store-Richtlinienänderungen, Fehlerbehebung.

Der Feldtest in Schritt 3 ist bei Apps nicht verhandelbar. Eine Offlinelogik, die im Büro-WLAN mit abgeschaltetem Funk sauber läuft, verhält sich anders, wenn das Gerät am Rand des Empfangsbereichs alle paar Sekunden die Verbindung wechselt. Genau dort entstehen die Fehler, die später teuer werden.

Für den Betrieb rechnen Sie mit 12 bis 18 Prozent der Projektsumme pro Jahr. Bei Apps liegt der Anteil eher am oberen Rand, weil Apple und Google ihre Anforderungen jährlich anpassen und eine App, die zwei Jahre unangetastet bleibt, irgendwann aus dem Store fliegt oder auf neuen Geräten nicht mehr startet.

Die Spanne erklärt sich fast vollständig über zwei Faktoren: Offlinefähigkeit mit Synchronisation und die Zahl der anzubindenden Bestandssysteme. Eine reine Anzeige-App ohne Offlinebetrieb liegt am unteren Rand, eine Technikerapp mit vollem Offlinebetrieb, Fotodokumentation und ERP-Anbindung am oberen. Details zur Kalkulation stehen unter App-Entwicklung Kosten.

• Was eine App kostet, im Detail
• Ablauf und Kosten
• Festpreis oder Abrechnung nach Aufwand

Der Quellcode gehört Ihnen ab Tag eins, einschließlich Buildkonfiguration, Signaturprozess und Dokumentation der Schnittstellen. Die Entwicklerkonten bei Apple und Google laufen auf Ihr Unternehmen, wir arbeiten als eingeladene Nutzer darin. Wenn Sie den Dienstleister wechseln, entziehen Sie uns den Zugang und die App bleibt Ihre.

Entwickelt wird von festangestellten Entwicklern in St. Leon-Rot. Kein Offshoring, keine weitergereichten Freelancer-Ketten. Sie haben einen benannten Ansprechpartner, der Ihren Prozess kennt und nach dem Go-live noch da ist. Das Backend liegt in Deutschland oder der EU.

• Vertrauen und Sicherheit
• Entwicklung in Deutschland
• Das Team

Woran erkenne ich vor dem Projekt, ob eine PWA reicht?

Muss die Anwendung länger als ein paar Minuten ohne Verbindung Daten erfassen? Muss sie den Nutzer per Push erreichen, während sie geschlossen ist, auch auf dem iPhone? Braucht sie Hardware jenseits von Kamera und Standort, etwa NFC oder gekoppelte Bluetooth-Geräte? Ein Ja an einer dieser Stellen spricht gegen die PWA. Bleibt es überall bei Nein, ist sie in der Regel die günstigere und schneller wartbare Lösung.

Warum wird Offlinefähigkeit so viel teurer?

Sobald zwei Geräte denselben Datensatz unabhängig verändern können, braucht jede Entität eine Regel dafür, welche Version gewinnt, dazu eine Änderungshistorie, ein Protokoll fehlgeschlagener Übertragungen und eine Oberfläche für die Fälle, die niemand automatisch entscheiden kann. Diese Regeln hängen an Ihrem Prozess, sie lassen sich nicht als Bibliothek einbinden.

Wie lange dauert die Store-Freigabe?

Wir nennen bewusst keine Zahl, weil sie sich nach Auslastung und Richtlinienänderungen bei Apple und Google verschiebt und wir darauf keinen Einfluss haben. Verlässlich ist nur: Die Erstveröffentlichung dauert länger als jedes spätere Update, und Ablehnungen aus formalen Gründen sind häufig. Planen Sie den Go-live deshalb ohne harten Stichtag, oder verteilen Sie intern über Apple Business Manager und Managed Google Play.

Können wir mit einer PWA starten und später eine native App bauen?

Ja, wenn das Backend von Anfang an eine eigenständige Schnittstelle ist, die jede Oberfläche gleich nutzt. Dann liegt die Fachlogik serverseitig und bleibt beim Umstieg erhalten. Die Einschränkung: Die Oberfläche entsteht neu. Rechnen Sie nicht damit, dass ein wesentlicher Teil des PWA-Frontends wiederverwendet wird.

Was passiert, wenn Apple oder Google die Richtlinien ändern?

Das gehört in die Betriebsbetreuung. Änderungen an Mindest-SDK-Versionen, Datenschutzangaben oder Berechtigungsmodellen kommen jährlich und betreffen jede App im Store. Ohne laufende Pflege verschwindet eine App nach einigen Jahren aus dem Store oder startet auf neuen Geräten nicht mehr. Wer eine App einmal bauen und dann liegen lassen will, sollte das vorher wissen.

Brauchen wir für eine Mitarbeiter-App den Betriebsrat?

Wenn die App zur Überwachung von Verhalten oder Leistung geeignet ist, ist der Betriebsrat nach § 87 Abs. 1 Nr. 6 BetrVG mitbestimmungspflichtig. Geeignet zu sein genügt, eine tatsächliche Auswertungsabsicht ist nicht nötig. Zeiterfassung, Standortdaten und Auftragsdurchlaufzeiten fallen regelmäßig darunter. Wir sind keine Rechtsberatung und ersetzen die arbeitsrechtliche Prüfung nicht, planen den Punkt aber im Projektablauf mit ein, weil er sonst kurz vor dem Rollout auffällt.

Wer hat Zugriff auf die App-Daten?

Das Backend läuft in Deutschland oder der EU auf einer Infrastruktur, die Ihnen zugeordnet ist. Für den Betrieb schließen wir eine Auftragsverarbeitung nach Art. 28 DSGVO. Zugriff unserer Entwickler auf Produktivdaten beschränken wir auf benannte Personen und dokumentierte Anlässe, etwa Fehleranalyse. Wo ein solcher Zugriff im Support unvermeidbar ist, sagen wir Ihnen das vorher.

Bringen Sie ins erste Gespräch mit, wo Ihre Leute arbeiten, was sie heute auf Papier festhalten und an welcher Stelle die Verbindung abreißt. Daraus lässt sich in einem Termin klären, ob Sie eine App brauchen oder ein Portal, und woran die Kalkulation hängen wird. Wenn das Ergebnis lautet, dass eine App der falsche Weg ist, sagen wir das.

• Apps und Shops im Überblick
• Individualsoftware
• Projekte
• Kontakt