Es gibt viele gute Argumente für Software und technische Lösungen. In einer Welt, in der mittlerweile wie selbstverständlich versucht wird, möglichst viel zu automatisieren und zu digitalisieren, ist es zu Beginn von Projekten, Anfragen und Anforderungen dennoch oder gerade deswegen sinnvoll, einen Schritt früher anzusetzen und den Raum auch für Lösungen außerhalb dieses Standarduniversums aufzumachen.

Denn manchmal ist vielleicht NO SOFTWARE die bessere Lösung?

Nehmen wir an, wir haben eine Kundendatenbank, die in ein neues System überführt werden soll. Ein gängiges Vorgehen wäre vermutlich, eine Schnittstelle zu bauen, die dann einmalig die Daten migriert. Die Anforderungen hinsichtlich Sicherheit sind hoch, denn es handelt sich um sensible Daten. Es gibt eine Menge Fragestellungen zu klären, wie z. B. mit Altdaten umgegangen werden soll, die nicht den „neuen“ Vorgaben entsprechen. Denn Datenqualität soll eines der Ziele des Projekts sein. Nach einem halben Jahr Analyse und Entwicklung kann es dann endlich los gehen mit der Migration der Daten. Kann man so machen, aber geht es vielleicht auch anders?

Um wie viele Datensätze geht es denn? 500, 1.000, 10.000, 1 Million?

Nehmen wir an, es geht um 16.000 Kundendatensätze in einem mittelständischen Unternehmen. Eine Mitarbeiterin schafft ca. 20 Neuanlagen in einer Stunde, d. h. 160 Neuanlagen am Tag über eine Anwendung, die ohnehin für die Nutzenden des Kundenverwaltungssystems entwickelt werden muss. Haben wir z. B. 10 Mitarbeiter, die 10 Tage nichts anderes machen oder 20, die 10 Tage lang die Hälfte ihrer Arbeitszeit darauf verwenden, dann wären nach zwei Wochen die Daten im neuen System. Natürlich ist die Verfügbarkeit der Mitarbeitenden mit in die Betrachtung einzubeziehen sowie die Konsequenzen, wenn ihre eigentliche Tätigkeit eine Zeit lang liegen bleibt. Die Datenqualität hätte der technischen Lösung einen Vorsprung gegenüber, denn offensichtliche Fehler könnten manuell direkt korrigiert werden. Selbst wenn das die tatsächliche Anzahl der Neuanlagen pro Stunde etwas reduziert. Neue Fehler über Eingaben werden minimiert durch die Validierung in der neuen Eingabemaske. Die Mitarbeiter haben gleichzeitig einen Schulungseffekt auf der neuen Anwendung. Und insgesamt schneller wäre man auch, selbst bei noch viel größeren Datenmengen. Wäre das nicht eine Überlegung wert?

Welche Faktoren in der Praxis solch pragmatische Herangehensweisen verhindern können, schauen wir uns im Folgenden etwas genauer an.

1. Weil es schon immer so war (historisch)

Wenn sich das Unternehmen schon immer in technischen Lösungen bewegt hat oder auch ein Entwicklungsteam bereit steht, welches auf neue Anforderungen zur Umsetzung wartet, dann wird in den meisten Fällen niemand mehr auf die Idee kommen, die technische Lösung an sich zu hinterfragen.

Manchmal stellen Entwickler schlaue Fragen, vor allem dann, wenn sich die Lösung als komplexer und aufwändiger gestaltet, als es vorgesehen war. Dann ist es aber meist schon zu spät, einen völlig neuen Weg zu gehen und es wird nur noch im Rahmen der Ausgestaltung der technischen Lösung justiert. Dem kann vorgebeugt werden, indem die Projektmanagement-Prozesse in der Vorbereitungsphase von Requirements Engineering begleitet werden, das die Anforderungen hinterfragt und Lösungsräume öffnet.

2. Managemententscheidung

Oft haben Entscheiderinnen in Unternehmen klare Vorstellungen davon, wie Lösungen zu gestalten sind. Das ist auch wichtig. Problematisch wird es dann, wenn sie gar nicht tief genug im Thema sind, um den Lösungsraum allein zu definieren. Multifunktionale Projektteams sollten an der Stelle einfordern, dass alle sinnvollen Optionen vor Projektstart betrachtet werden und diese auch aktiv ins Spiel bringen dürfen.

3. Markteinflüsse

Manchmal wird strategisch entschieden, dass das eigene Unternehmen genau so wie etwa der stärkste Konkurrent eine App benötigt oder irgendetwas anderes, das dem Mitbewerber vermeintlich einen Vorteil verschafft.

An dieser Stelle ist es wichtig, sich vor einer Entscheidung Fragen wie die folgenden zu stellen:

4. Die Nutzer werden nicht einbezogen

Wenn Ziele wie Automatisierung und Digitalisierung von Prozessen hoch priorisiert werden, dann wird oft ganz automatisch ein Prozess oder ein Geschäftsbereich nach dem anderen durch eine digitale Transformation geschickt.

Oft wird vergessen, die Nutzerinnen ausreichend einzubeziehen, was dazu führen kann, dass die digitale Lösung vom Kunden überhaupt nicht gewünscht, geschweige denn angenommen wird. Und im worst case sogar einen negativen Einfluss auf die Zufriedenheit hat.

Ein Beispiel hierfür könnten die Apps verschiedenster Nahverkehrsanbieter sein, bei denen man in Eile vor Abfahrt sich über mehrere Schritte hinweg durch das Ticketsystem klickt und beim Überqueren der Straße oder im Funkloch in der Unterführung der Bahngleise vor Herausforderungen steht. Hier könnten andere Lösungen viel nutzungsfreundlicher zum Ziel führen, wie es in anderen Ländern bereits erprobt wird, in denen eine Chipkarte für Vielfahrende im Verkehrsmittel eingelesen wird. Für Personen, die den Nahverkehr nicht oft benutzen, gibt es noch echte Service-Mitarbeiter vor Ort.

5. Interessenskonflikte

Interessenskonflikte stellen ein Problem dar, wenn es um die erfolgreiche Bewerkstelligung von Projekten geht, da sie einen neutralen Ansatz oft verhindern.

Wenn z. B. ein Geschäftsbereich im August noch ein IT-Restbudget von € 150.000,- hat, dann muss ein Projekt zur Umsetzung her, weil sonst das Budget im Folgejahr gekürzt würde. Anderweitig kann in starren, größeren Organisationen das Geld aber häufig gar nicht eingesetzt werden und schon ist die Entscheidung für eine Softwarelösung automatisch getroffen. Auch wenn vielleicht nach Analyse eine Veränderung des Geschäftsprozesses die viel schlauere Variante gewesen wäre.

6. Nicht alle Faktoren werden in die Entscheidung mit einbezogen

Nehmen wir an, eine Geschäftsführerin möchte eine App einführen, um sich als innovativ zu positionieren und dem Trend der Nutzung von Mobilgeräten gerecht zu werden.

Mit einer App ist es aber normalerweise nicht getan. Um den Markt ausreichend zu bedienen, sind meist eine Version für Apple iOS und Google Android von Nöten, was die erforderlichen Entwicklungskapazitäten schon mal verdoppelt. Auch die spätere Wartung und Anpassung der vorhanden Software wird noch einen nennenswerten Aufwand nach sich ziehen und das, solange es die Apps gibt. Wenn es in unserem Beispiel eine ausgefeilte, über Jahre solide entwickelte Website gäbe, die mit relativ geringem Aufwand um ein ansprechendes und responsives Design erweitert werden könnte, darf abhängig von den Anforderungen hinterfragt werden, ob die App hier im Verhältnis von Aufwand und Nutzen immer noch die bestmögliche Lösung darstellt. Natürlich kann am Ende die Entscheidung trotzdem zugunsten der App fallen. Von Bedeutung ist es, möglichst alle relevanten Faktoren mit einzubeziehen.

Wie findet man nun die bestmögliche Lösung?

TAGS