BetriebsIT Praxiswissen
Business-App entwickeln: vom Ablauf zur Anwendung
Wann sich eine eigene Business-App lohnt: Standardsoftware vergleichen, Prototyp testen, Schnittstellen planen und Entwicklung mit klaren Abnahmekriterien beauftragen.
Wann lohnt sich eine eigene Anwendung?
Eine individuelle App kommt infrage, wenn Ihr Team Informationen mehrfach erfasst, Kunden ständig nach dem Status fragen oder ein wichtiger Ablauf zwischen Tabellen, E-Mails und mehreren Programmen hängen bleibt. Entscheidend ist ein konkreter Engpass. „Wir brauchen eine App“ beschreibt zunächst nur eine Lösungsform.
Notieren Sie einen wiederkehrenden Vorgang vom Auslöser bis zum Abschluss: Wer macht was, welche Information fehlt, wo entsteht Wartezeit? Vergleichen Sie danach drei Wege: vorhandene Software besser nutzen, Systeme miteinander verbinden oder eine eigene Anwendung entwickeln. Eine Standardlösung kann bei üblichen Aufgaben den geringeren Betriebsaufwand haben. Individualsoftware sollte eine nachvollziehbare Lücke schließen.
Web-App, PWA oder mobile App?
Für Projektlisten, Freigaben und Kundenportale kann eine responsive Web-App im Browser ausreichen. Eine PWA kann zusätzliche Funktionen wie eine Installation anbieten. Welche Funktionen verfügbar sind, hängt von Geräten und Browsern ab; die Grundlagen beschreibt web.dev in der unten verlinkten Dokumentation.
Wenn Außendienstmitarbeiter ohne Verbindung arbeiten müssen, reicht ein mobil angepasstes Layout nicht. Festzulegen sind lokal verfügbare Daten, Schutz verlorener Geräte und der Umgang mit widersprüchlichen Änderungen nach dem erneuten Verbinden. Kamera, Push-Mitteilungen, Hintergrundaufgaben und App-Store-Veröffentlichung werden ausdrücklich in den Umfang aufgenommen und auf den vorgesehenen Geräten geprüft.
Mit einem prüfbaren Prototyp starten
Für die erste Version wählen wir gemeinsam einen vollständigen Arbeitsablauf. Beispiel, kein Kundenfall: Ein Handwerksbetrieb möchte Aufträge zuweisen, Fotos zuordnen und erledigte Arbeiten freigeben. Der Prototyp zeigt die Sicht der Disposition, des ausführenden Teams und des Kunden. Eine spätere Lagerverwaltung bleibt zunächst außerhalb dieser Version.
Beim Test erhält eine Person eine konkrete Aufgabe, etwa einen Auftrag mit fehlendem Foto zurückzugeben. Beobachtet wird, ob sie den nächsten Schritt selbst findet. Aus Rückmeldungen werden Entscheidungen: notwendige Funktionen, offene Fragen und spätere Wünsche. Erst daraus entsteht ein belastbarer Entwicklungsumfang.
Daten, Rechte und Schnittstellen vorab klären
Für jede Anbindung werden verantwortliches System, benötigte Daten, Zugangsrechte, verfügbare Schnittstelle und externe Gebühren dokumentiert. Ein Export aus Excel ist etwas anderes als eine laufende Synchronisation mit einem ERP. Dubletten, fehlende Felder und der Ausfall eines Fremdsystems brauchen eigene Regeln.
Kunden dürfen nur ihre eigenen Vorgänge sehen. Interne Rollen erhalten die Rechte, die ihre Aufgabe erfordert. Mit personenbezogenen Daten werden Zweck, Rechtsgrundlage, Löschung und Schutzmaßnahmen abgestimmt; hierfür bietet der EDPB eine allgemeine Grundlage. Eine Anmeldung allein ist noch kein vollständiges Berechtigungskonzept.
Kosten, Übergabe und Weiterentwicklung vereinbaren
Ein Angebot sollte Konzept, Umsetzung, Datenübernahme, Einführung und laufenden Betrieb getrennt beschreiben. Der Aufwand steigt insbesondere mit zusätzlichen Rollen, Schnittstellen, Sonderfällen, Offline-Funktionen und Anforderungen an Verfügbarkeit. Deshalb nennen wir für individuelle Apps keinen pauschalen Entwicklungspreis ohne geklärten Umfang.
Vereinbaren Sie vor dem Start, welche Nutzungsrechte, Quellcode-Bestandteile, Zugänge und Dokumentation übergeben werden. Ebenso wichtig sind Hosting, Datensicherung, Wartung und die Zuständigkeit bei Störungen. Für eine Erweiterung werden Nutzen und Aufwand erneut bewertet. Erfolg bedeutet zunächst, dass die vereinbarten Aufgaben im Alltag nachweisbar funktionieren; erwartete Zeitersparnisse werden anschließend mit realen Vorgängen geprüft.
Woran Sie das Ergebnis prüfen können
- Ein vollständiger Vorgang funktioniert mit allen vereinbarten Rollen.
- Fremde Kundendaten bleiben unzugänglich; Rechteentzug wird getestet.
- Doppeltes Absenden und ein Schnittstellenausfall erzeugen keine unbemerkten doppelten Aufträge.
- Datenexport, Wiederherstellung, Dokumentation und Betriebsverantwortung sind vereinbart.
- Der vereinbarte Kernablauf ist auf den vorgesehenen Geräten und bei den vereinbarten Verbindungsbedingungen getestet.
Häufige Fragen vor dem Start
Braucht meine Anwendung einen Eintrag im App Store?
Nicht zwingend. Für Portale, Projektstände und Freigaben kann eine Web-App reichen. Store-Veröffentlichung und native Gerätefunktionen werden dann eingeplant, wenn die vereinbarten Aufgaben sie erfordern.
Was muss ich vor einem ersten Gespräch vorbereiten?
Beschreiben Sie einen vollständigen Vorgang, die beteiligten Rollen und die vorhandenen Programme. Beispieldokumente ohne vertrauliche Kundendaten und eine Liste der heutigen Warte- oder Doppelerfassungsstellen helfen bei der Einordnung.
Was wird nach dem Prototyp entschieden?
Welche Aufgaben zur ersten Version gehören, welche Schnittstellen geprüft werden müssen und was später folgt. Der Prototyp ist eine Entscheidungsgrundlage; Entwicklung, Betrieb und Abnahme erhalten einen eigenen vereinbarten Umfang.
Offizielle Quellen und Vertiefung
Die Empfehlungen dieses Ratgebers wurden mit diesen offiziellen Materialien abgeglichen. Herstellerangaben gelten jeweils für die dort genannten Produkte und Tarife.
PWAs ergänzen Webanwendungen um Funktionen wie Installation; die Unterstützung hängt von Plattform und Browser ab.
Offizielle Quelle öffnen EDPBEDPB: Datenschutzgrundlagen für kleine UnternehmenDer EDPB erläutert Zweckbindung, Rechtsgrundlagen und Schutz personenbezogener Daten für kleine Unternehmen.
Offizielle Quelle öffnen Microsoft LearnMicrosoft Learn: Fehlerbehandlung in Power AutomateDie Power-Automate-Dokumentation erklärt Fehlerpfade, begrenzte Wiederholungen und die Protokollierung fehlgeschlagener Abläufe.
Offizielle Quelle öffnen
