Eine App kann in der Demo perfekt wirken. Aufgeräumte Screens, flüssige Animationen, vor dem Kunden im Besprechungsraum funktioniert alles. Dann geht sie in Produktion, und ein Mitarbeiter im Lager öffnet sie auf einem alten Smartphone. Die Verbindung ist instabil, und die Daten stimmen nicht mit denen des Webportals überein, das er eine Stunde später nutzt.
Eine Demo beweist, dass eine App funktioniert. Die Produktion beweist, dass sie gut konzipiert wurde.
Der eigentliche Test beginnt, wenn die App den Besprechungsraum verlässt
Eine Unternehmens-App arbeitet unter Bedingungen, die eine Demo nie zeigt. Dazu gehören instabile Netze, ältere Geräte und Daten, die konsistent mit anderen Systemen bleiben müssen, die dieselben Nutzer zur selben Zeit verwenden. Eine Unternehmens-App muss nicht gut funktionieren, wenn alles gut läuft. Sie muss weiter funktionieren, wenn nichts nach Plan läuft.
Eine Unternehmens-App steht nie für sich allein
In solchen Fällen liegt das Problem fast nie in der Oberfläche. Es liegt in der Architektur dahinter. Eine Unternehmens-App ist nicht zwangsläufig ein eigenständiges Produkt. Oft ist sie eine Schnittstelle, über die Nutzer auf ein größeres System zugreifen. Dazu gehören bestehende ERP- und CRM-Systeme, Portale und APIs. Wird sie als isoliertes Objekt entwickelt, losgelöst von diesen Systemen, funktioniert sie gut, solange sie ein Prototyp bleibt. Zum Problem wird sie, sobald die Nutzer sie täglich neben anderen Tools einsetzen. Sie erwarten dann, dass die Daten identisch sind, wo immer sie sie abrufen.
Wenn zwei Systeme zwei verschiedene Wahrheiten zeigen
Ein realer Fall aus der Pharmabranche: Eine App zeigte Daten an, die im Widerspruch zum Webportal desselben Vertriebsnetzes standen. Die beiden Plattformen griffen auf unterschiedliche Quellen zu und folgten unterschiedlichen Aktualisierungslogiken. Diese strukturelle Diskrepanz führte zu täglicher operativer Verwirrung bei allen, die sich bei ihrer Arbeit auf diese Zahlen verlassen mussten. Die Lösung bestand nicht darin, die Symptome Fall für Fall zu beheben. Stattdessen wurde die doppelte Logik beseitigt, und beide Plattformen wurden auf denselben API-Layer überführt. Dieser wurde damit zur einzigen applikativen Quelle für gemeinsam genutzte Daten.
Die Probleme, die eine Demo nicht zeigen kann
Die Schwierigkeiten, die im Produktivbetrieb auftreten, lassen sich drei Ebenen zuordnen.
Nutzungsprobleme: Geräte, Performance, Netz, Kompatibilität. Sie betreffen die konkrete Erfahrung derjenigen, die die App täglich verwenden.
Systemprobleme: Datensynchronisation, Integration, Authentifizierung, Governance. Sie betreffen die Architektur, und ein Test im Simulator allein kann sie nicht erkennen.
Kontinuitätsprobleme: Dokumentation, Verantwortlichkeiten, Wartbarkeit, Abhängigkeit vom Anbieter. Sie hängen mit dem Lebenszyklus zusammen und zeigen sich erst Monate oder Jahre nach dem Release.
Qualität wird vor dem Go-live geplant
Technologie sollte nicht der Ausgangspunkt sein. Sie ergibt sich aus den Anforderungen. Die Wahl zwischen nativ, Cross-Platform oder PWA hängt von mehreren Faktoren ab: Hardwareanforderungen, Offline-Nutzung, Performance, Distribution und Update-Frequenz. Eine technische Vorliebe sollte dabei nicht den Ausschlag geben.
Dasselbe gilt für den Datenschutz. „DSGVO by Design” bedeutet wenig, wenn es ein Slogan bleibt. In der Praxis heißt es Datenminimierung, Trennung von Zugriffsrechten, festgelegte Aufbewahrungsfristen und Verschlüsselung.
Wo landen Unternehmensdaten vorübergehend auf dem Gerät, wenn keine Verbindung besteht?
Diese Frage muss gestellt werden, bevor die erste Zeile Code geschrieben wird. Wenn die App bereits in Produktion ist, ist es zu spät.
Eine App muss auch für diejenigen wartbar sein, die sie nicht entwickelt haben
Ein Premium-Projekt muss übertragbar sein, nicht nur funktionsfähig.
Das bedeutet Tests auf realen physischen Geräten vor jedem Release, nicht nur in Simulatoren. Es bedeutet auch, zum Go-live eine vollständige technische Dokumentation zu übergeben. So kann das Team des Kunden oder ein künftiger Dienstleister das Projekt übernehmen, ohne von denjenigen abhängig zu sein, die es geschrieben haben. Keine Abhängigkeit von einer einzelnen Person, kein Wissen außerhalb der Dokumentation.
Eine Unternehmens-App bewährt sich über die Zeit
Heute betreuen wir mehr als 15 Unternehmens-Apps im Produktivbetrieb. Den Go-live betrachten wir nicht als Ende der Entwicklung. Er ist der Moment, in dem das Projekt beweisen muss, dass es für die reale Welt bereit ist. Unsere Apps werden von den Stores bereits bei der ersten Einreichung freigegeben. Das ist das Ergebnis eines Prozesses, der Anforderungen, Sicherheit, Verhalten und Compliance vor der Einreichung prüft, nicht erst nach einer Ablehnung.
Eine Unternehmens-App wird nicht bei ihrer Präsentation beurteilt. Sie wird beurteilt, wenn sie Teil der Unternehmensprozesse wird und Monate und Jahre später noch immer funktioniert. Genau dort zeigt sich der Unterschied zwischen einem ausgelieferten Produkt und einem System, das auf Dauer ausgelegt ist.
Bevor Sie den Screen gestalten, gestalten Sie das System, in dem er bestehen muss. Dort beginnt eine Unternehmens-App, die auf Dauer ausgelegt ist.