Wie Mittelständler Entwicklungspartner für Apps auswählen

Softwareprojekte im Mittelstand scheitern selten an der Technik. Sie scheitern daran, dass der Auftraggeber nicht beschreiben kann, was die Anwendung leisten soll, und der Entwickler nicht fragt. Für Betriebe, die zum ersten Mal eine eigene App entwickeln lassen, ist deshalb die Wahl des Partners weniger eine Frage der Programmiersprache als eine der Arbeitsweise.

Welche Arten von Entwicklungsdienstleistern gibt es?

Am Markt treten drei Typen auf: Agenturen mit eigenem Entwicklungsteam, Vermittler, die Projekte an freie Entwickler weitergeben, und Softwarehäuser mit fertigem Produkt, das angepasst wird. Die Bezeichnungen überschneiden sich, die Verantwortung nicht.

Eine Agentur mit eigenem Team trägt die Umsetzung selbst und bleibt nach dem Start ansprechbar. Ein Vermittler bündelt Kapazität, hat aber keinen direkten Zugriff auf die Qualität, weil die Arbeit außer Haus stattfindet. Ein Softwarehaus mit Standardprodukt liefert schneller, bindet den Betrieb dafür an die Grenzen des Produkts.

Welcher Typ passt, hängt an der Frage, ob eine Anwendung einen Ablauf abbilden soll, den es so nur in diesem Betrieb gibt. Wo das zutrifft, scheidet die Standardlösung aus, und die Verantwortung für die Umsetzung muss bei einer Stelle liegen.

Damit rückt der Standort des Teams in den Blick.

Welche Rolle spielt der Standort des Entwicklungsteams?

Der Standort wirkt an drei Stellen: bei der Abstimmung, beim Datenschutz und bei der Gewährleistung. Alle drei werden in der Angebotsphase unterschätzt und in der Umsetzung teuer.

Abstimmung bedeutet in der Praxis Rückfragen. Ein Entwicklungsteam, das denselben Arbeitstag hat und dieselbe Sprache spricht, klärt eine offene Frage in Minuten, während ein verteiltes Team sie in den nächsten Tagesablauf schiebt. Bei Anwendungen, die Betriebsabläufe abbilden, summiert sich das.

Der Datenschutz betrifft die Verarbeitung personenbezogener Daten nach der Datenschutz-Grundverordnung. Werden Daten auf Servern außerhalb der Europäischen Union verarbeitet, sind zusätzliche Vereinbarungen nötig, und die Nachweispflicht trägt der Betrieb als Verantwortlicher, nicht der Dienstleister. Deutsches Hosting vereinfacht diese Kette erheblich.

Ein Beispiel für diesen Zuschnitt ist die BlueBranch GmbH aus Fürth, die mit einem Team von sieben Personen im eigenen Haus arbeitet und Anwendungen für Handwerk, Finanzdienstleistung, Recruiting, Kommunen und Gesundheitswesen entwickelt.

Was ein solches Team braucht, um loszulegen, steht meist noch aus.

Was gehört in ein Lastenheft für eine App?

In ein Lastenheft gehören vier Teile: der Zweck der Anwendung, die Nutzergruppen, die Abläufe und die Schnittstellen zu bestehenden Systemen. Alles Weitere ergibt sich daraus.

Der Zweck ist die Frage, welches Problem die Anwendung löst, und er lässt sich in zwei Sätzen formulieren. Die Nutzergruppen bestimmen die Rechte und die Oberfläche, weil ein Monteur im Außendienst andere Ansichten braucht als die Disposition. Die Abläufe beschreiben, was in welcher Reihenfolge geschieht, und sind der Teil, den nur der Betrieb liefern kann.

Die Schnittstellen entscheiden über Aufwand und Folgekosten. Eine Anwendung, die Auftragsdaten aus der vorhandenen Warenwirtschaft zieht, braucht eine Schnittstelle, deren Verfügbarkeit vor Projektbeginn geklärt sein muss. Fehlt sie, entsteht eine Doppelerfassung, und die Anwendung verliert ihren Nutzen innerhalb weniger Wochen.

Steht das Lastenheft, folgt die Entscheidung über die technische Richtung.

Worin unterscheiden sich native Apps, Web-Apps und plattformübergreifende Lösungen?

Die drei Wege unterscheiden sich darin, wie nah die Anwendung am Betriebssystem des Geräts arbeitet.

Native Entwicklung ist dort angezeigt, wo Kamera, Standort, Bluetooth oder Hintergrundprozesse eine zentrale Rolle spielen. Eine Web-Anwendung genügt, wenn die Anwendung vor allem Daten anzeigt und erfasst und ohnehin eine Verbindung voraussetzt.

Plattformübergreifende Rahmen haben sich dazwischen etabliert und decken den größten Teil betrieblicher Anwendungen ab. Sie verkürzen die Entwicklungszeit, binden den Betrieb aber an die Weiterentwicklung des Rahmens, was bei langen Laufzeiten mitzudenken ist.

Unabhängig vom Weg entsteht nach der Veröffentlichung eine dauerhafte Aufgabe.

Welche laufenden Kosten entstehen nach der Veröffentlichung?

Nach der Veröffentlichung entstehen Kosten für Betrieb, Pflege und Anpassung. Sie werden in der Planung regelmäßig vergessen, weil sie im Angebot für die Erstellung nicht auftauchen.

Der Betrieb umfasst Server, Datenbank und Überwachung. Die Pflege betrifft die regelmäßigen Anpassungen an neue Versionen der Betriebssysteme, die in jährlichem Takt erscheinen und ohne Reaktion zum Ausschluss aus den App-Stores führen können. Die Anpassung schließlich folgt aus dem Betrieb selbst, weil jede Anwendung nach einigen Monaten Nutzung Änderungswünsche erzeugt.

Für die Kalkulation hat sich bewährt, diese Posten als jährlichen Anteil der Erstellungskosten anzusetzen und vertraglich zu regeln, wer sie trägt und in welcher Reaktionszeit. Wie stark Anwendungen Abläufe verändern, sobald sie laufen, zeigt der Blick auf die Optimierung betrieblicher Abläufe über Apps.

Damit stellt sich die Frage nach dem richtigen Einstiegszeitpunkt.

Wann lohnt sich für einen Mittelständler eine eigene Anwendung?

Eine eigene Anwendung lohnt sich, wenn ein wiederkehrender Ablauf heute über Papier, Tabellen oder Telefonate läuft und die Zahl der Vorgänge so hoch ist, dass die Erfassung spürbar Zeit kostet. Dann steht die Entwicklung nicht gegen ein anderes Produkt, sondern gegen die Kosten der heutigen Lösung.

Erfüllt sein müssen dafür zwei Voraussetzungen. Der Ablauf muss stabil sein, denn eine Anwendung bildet ab, was feststeht, und nicht, was sich gerade ändert. Und im Betrieb muss eine Person benannt sein, die fachlich entscheidet, sonst verlagert sich jede Detailfrage in die Geschäftsführung und das Projekt bleibt liegen.

Nicht sinnvoll ist eine Eigenentwicklung dort, wo ein Standardprodukt den Ablauf bereits abdeckt und nur die Gewohnheit dagegen spricht. Die Prüfung dieser Frage gehört vor das Lastenheft, nicht danach, und sie ist die einzige Stelle im Projekt, an der eine Absage den Betrieb mehr Geld spart als jede Verhandlung über den Stundensatz.