Wenn digitalisiert oder eine bestehende digitale Lösung modernisiert wird, dann möchte man in diesem Zuge gleich die Prozesse durchleuchten und optimieren. Doch dazu benötigt man eine ausgefeilte Strategie, denn sonst läuft man Gefahr, das System zu verkomplizieren. Und damit erreicht man das Gegenteil von dem, was man möchte.
Die erste Version eines Systems vermeidet dieses Komplexitätsproblem oft noch. Aber gerade die zweite Version eines Systems hat in unserer Branche den Ruf, viel zu kompliziert zu sein. Oft sprechen Architekten vom Second System Effect. Doch dieser entsteht oft genau dann, wenn das Unternehmen eine Prozessoptimierung und -anpassung angeht. Wie kann man dieses Problem überwinden, Prozesse optimieren und trotzdem schlanke Systeme bauen?
Wie kann man überhaupt optimieren?
Möchte man einen Papierprozess digitalisieren, überträgt man ihn in den allermeisten Fällen eins-zu-eins in die digitale Welt. „Wie denn auch sonst?“, könnte man einwenden. Aber: Digitalisierung bietet meist auch einiges an Vereinfachungspotenzial. Sie könnten sich zum Beispiel fragen:
- Können bei einem digitalisierten Prozess ganze Abteilungen übersprungen werden, da manuelle Schritte voll- oder halbautomatisch erfolgen? Beispiele wären automatische Rechnungs-Eingangsstempel oder das Erfassen von Bankkonto-Buchungen und die automatische Zuordnung zu Rechnungen.
- Können unstrukturierte Daten strukturiert und trotzdem benutzerfreundlich abgefragt werden? Sie stehen dadurch zum einen zur statistischen Analyse bereit. Zum anderen helfen sie bei der Fehlervermeidung und bei Plausibilitätsprüfungen. Bei einem unserer Kunden etwa vereinfachen wir das Bestellungsmanagement gerade, indem wir Zweier- oder Dreier-Blisterverpackungen automatisch als solche kennzeichnen. Wir lassen dann nur Bestellungen ganzer Blister zu.
- Können Daten in weiteren Formaten, wie etwa CSV, JSON, oder als API exportiert werden? Das ermöglicht Interaktion mit anderen digitalen Systemen.
- Können unübersichtliche Formulare in UI-Muster wie zum Beispiel einen Wizard transformiert werden? Das trägt zu einem organisierten Arbeitsablauf bei.
- Können alle Vorgänge wenn gewünscht lückenlos erfasst werden? (Audit-Trail)
- Können Large Language Models die strukturierten Daten als fertigen Fließtext formulieren oder in Form eines Chatbots in einem intuitiven Dialog bereitstellen?
Es gibt noch viel mehr Möglichkeiten, und diese dienen nur zur Inspiration. Aber Sie sehen schon, dass ein erstmals digitales System oder auch ein neues System, das ein altes ablöst, viel Potenzial zur Optimierung und Neuordnung von Prozessen bietet.
Laut aktuellen Studien reduzieren vollständig digitalisierte Prozesse die Prozesskosten um 30–60%. Dabei nicht eingerechnet sind jedoch noch weitere Einsparungen, die sich durch Optimierungen und Vereinfachungen ergeben, wie sie bei AVANT ICONIC Standard sind. Diese digitalen Lösungen haben zudem den entscheidenden Vorteil, dass sie problemlos skalierbar sind – egal ob 10 oder 10.000 Bestellungen pro Tag verarbeitet werden müssen. Unsere Systeme sind daher so konzipiert, dass sie nahtlos mit Ihren Anforderungen mitwachsen. In zwei Fallstudien zeigen wir Ihnen unser konkretes Vorgehen.
Anforderungserhebung – und was fehlt
In der Softwarebranche ist leider des öfteren zu beobachten, dass genau die beschriebene Prozessoptimierung nicht von Anfang an mitgedacht wird. Oder es fehlt an Konsequenz, und es entstehen Insellösungen.
Drei Methoden sind in der modernen Softwareentwicklung gängig, um Anforderungen zu erheben. Das heißt, um zu wissen, was die Software überhaupt tun und können soll:
- Die klassische Anforderungsanalyse. Hier wird zu Anfang zusammen mit dem Kunden ein Lastenheft erstellt, in dem alle Anforderungen gesammelt werden. Das Gegenstück dazu, das Pflichtenheft, dient dann zur Planung der System- und Software-Architektur. Wenn nicht nur das Lastenheft, sondern auch das Pflichtenheft schon vor Projektbeginn erstellt werden, wird das auch als Wasserfall-Prozess bezeichnet.
- Strukturierte Analysemethoden aus dem agilen und Domain-Driven-Design (DDD) -Umfeld: Hier erstellt man mit diversen Techniken (Event Storming, Context Mapping) eine gemeinsame Sprache (Ubiquitous Language). Diese ist für jede Art von Kommunikation (mit Kunden, mit Entwicklern untereinander, im Code, etc.) einzusetzen, jedoch nur innerhalb eines jeweiligen Kontextes (Bounded Context). In aller Regel erfolgt die Erstellugn der gemeinsamen Sprache mit Kunden zusammen, jedoch nicht zwingenderweise mit den Endnutzern der Software. Endergebnis ist ein sogenanntes Domänenmodell, das, wenn man so will, sowohl als Lasten- als auch als Pflichtenheft dient, denn es legt sowohl fest, was die Software tun soll, als auch große Teile der Code-Architektur.
- UX (User Experience)-Forschung: Hier werden genau die späteren Endnutzer mit wissenschaftlichen Methoden befragt, es werden Hypothesen aufgestellt, überprüft, Prototypen entworfen sowie verworfen, und so weiter. Das Resultat ist ein ausführlicher Bericht sowie in der Regel auch ein fertiger Entwurf der Software-Benutzeroberfläche. In der Praxis erfolgt dies eher als Teil eines Wasserfall-Prozesses. Denn UX-Forschung nimmt viel Zeit in Anspruch und passt nicht immer in die dynamische Zeitplanung, die unter anderem agile Prozesse einfordern. Auch nimmt es viel Zeit in Anspruch, diesen Prozess erneut zu durchlaufen, wenn sich die Benutzeroberfläche ändern muss. Unterstützung bei der Formulierung von Code wie bei DDD oder beim Pflichtenheft ist hier auch noch nicht enthalten. Doch die Vorteile dieser Methode liegen trotzdem auf der Hand: Man weiß zuverlässig, was der Endbenutzer braucht, und was nicht. Man vermeidet so teure Fehler.
Terminologiemanagement – Der „Missing Link“
Selbstverständlich kann man diese Ansätze auch kombinieren oder mischen. Auffällig für uns zumindest ist, dass eine weitere wichtige Technik, die im Übersetzungsgewerbe und auch zunehmend im Maschinenbau bekannt ist, das Terminologiemanagement (TM), in der Softwarewelt noch kaum eingesetzt wird.
Terminologiemanagement wäre aber prädestiniert dafür, eine Art Brücke zwischen dem etwas vagen, aber gleichzeitig manchmal dogmatischen DDD und dem extrem wissenschaftlichen UX herzustellen. Bei TM dürfen sich Kontexte überlappen, und auch Synonyme haben ihren Platz, wobei trotzdem jeder Begriff eine kanonische Form hat, die in Zukunft zu verwenden ist. Und auch Begriffe, die eventuell nur für Entwickler oder Buchhalter Sinn ergeben, dürfen mit fachlichen Begriffen aus anderen Bereichen verknüpft werden und müssen nicht abteilungs- oder kontextspezifisch isoliert sein.
So sind Zusammenhänge leichter aufzufinden, die aufzeigen können, wo Prozessoptimierungen sinnvoll sind.
Industriestandards und Normen – Mangelware?
Methoden wie die klassische Anforderungsanalyse, aber auch strukturierte Ansätze wie Domain Driven Design (DDD) kranken oft daran, dass sich die Entwicklungsagentur zwar in die bestehenden Unternehmensprozesse hineindenkt, diese jedoch wie beschrieben eins-zu-eins umsetzt. Eric Evans, der Begründer von DDD, spricht davon, dass meist drei oder vier Anläufe notwendig sind, bevor ein elegantes Domänenmodell vorliegt. Damit ist aber zunächst einmal der Status Quo abgebildet. Denn die Fachdomäne nutzt nun einmal eine ältere digitale Lösung oder auch Papier, und die Einschränkungen, die dadurch entstehen, werden Teil des Domänenmodells!
Hier wäre theoretisch die klassische Anforderungserhebung, praktiziert im Zusammenhang mit Wasserfall und/oder UX-Forschung, sogar überlegen. Denn der Kunde könnte aktiv werden und gleich eine vereinfachte Lösung vorschlagen. Mit technisch sehr versierten Kunden oder mit einer umfangreichen UX-Beratung kann dies funktionieren, der Regelfall ist aber auch hier eher die Eins-zu-eins-Umsetzung.
Ein Standard für die Softwarebranche, der es ermöglich, Prozessoptimierung und Domänenmodellierung sowie Software- und Systemarchitektur zu kombinieren, fehlt leider noch komplett. Dabei würde ein solcher Standard dazu beitragen, dass Digitalisierung an sich erschwinglicher wird und sich so schneller amortisiert.
Zwei Phasen – Mehrarbeit für alle Seiten?
Da so ein Standard noch fehlt, wird die Arbeit in der Praxis eher zeitlich aufgeteilt. Im typischen Fall gibt es zwei Phasen bei einem Digitalisierungsprojekt: Die initiale Konzeptions- und Entwicklungsphase und die Anpassungsphase, wo das nunmehr digitalisierte System an die praktischen Anforderungen und Prozessoptimierungen angeglichen wird. Unserer Erfahrung nach dauert die zweite Phase meist länger als die erste. Denn bei Nutzung von DDD etwa muss das Entwicklungsteam das Domänen- und auch oft das Datenmodell immer wieder an die neuen Anforderungen angleichen.
Oft wird hier Event Sourcing, eine Technik ebenso aus dem DDD-Umfeld, als Lösung ins Feld geführt. Dabei handelt es sich um eine Methode, wie das Programm Daten aus einer Simulation der Vergangenheit, die aus sogenannten Domänenereignissen besteht, rekonstruiert. Doch das ist hier auch kein Allheilmittel, denn auch Domänenereignisse wechseln nicht selten ihr Format, wenn mehr an der Prozessoptimierung gefeilt wird.
Beim klassischen Wasserfall-Prozess mit Anforderungserhebung gibt es ebenfalls einen erhöhten Änderungsaufwand, wenn Flexibilität bei der Architektur nicht mitgedacht wird.
In der ersten Phase eines Projekts stellt man sich oft alles sehr einfach vor, in der zweiten kompensiert man gern in die andere Richtung. Man verkompliziert das Domänen- oder Datenmodell, da man befürchtet, sonst nicht alle Eventualitäten berücksichtigen zu können. Dieser Effekt ist umso stärker, wenn vorher schon ein digitales System vorhanden war, das man zunehmend als viel zu eingeschränkt erlebt. Genau das ist der Second System Effect.
Wie geht es besser?
Wir müssen betonen, dass es ganz ohne Anpassungen und teilweise Neuentwicklungen nicht geht. Im laufenden Produktiveinsatz kommen regelmäßig neue Automatisierungs- und Funktionsanforderungen ans Licht. Wir sind jedoch überzeugt, dass folgendes eine gute Digitalisierungslösung ausmacht:
- Effizienzsteigerung von Beginn an: Die erste Version einer Digitalisierungslösung muss den Prozessaufwand im Vergleich zur vorigen Lösung senken und nicht sogar erhöhen. Passende UI-Muster können das sicherstellen. So setzen wir beständige Verbesserung, auch bekannt als Continuous Improvement, um.
- Ganzheitliche Betrachtung abteilungsübergreifender Workflows: Diese müssen Auftraggeber und Entwicklungsunternehmen frühzeitig erkennen und benennen. Ein Fehler wäre es, diese vorschnell in künstlich isolierte „Bounded Contexts“ zu verlagern.
- Flexible Systemarchitektur für nachhaltige Weiterentwicklung: Auch weitreichende Änderungen sind leicht zu implementieren. Und das, ohne entweder umfangreiche Architekturänderungen oder Quick-and-dirty-Code nach sich zu ziehen. Letzterer ist sonst besonders tückisch, da er dazu führt, dass zuerst die Entwicklung flott vorangeht, dann aber immer mehr im Sande verläuft.
Um das umsetzen zu können, haben wir selbst und zusammen mit unseren Partnern Techniken und Methoden entwickelt, die sowohl flexibel, als auch strukturiert sind. Wir sind überzeugt, dass die Softwarebranche selbst noch viel brachliegendes Potenzial zur Prozessoptimierung hat.
Eines unserer Ziele ist es, die Stärken von UX-Forschung, DDD, Terminologiemanagement und Lean-Ansätzen zu kombinieren, um Software erstellen zu können, die der Geschäftswelt unserer Kunden wie angegossen passt. Gehen wir gemeinsam den Weg zu mehr Softwarequalität und mehr Digitalisierungs-Effizienz.
Im nächsten Teil der Serie erwartet Sie ein technischer Deep-Dive. Dort lernen Sie, wie Sie die nötige Flexibilität im Domänen- und Prozessmodell technisch sicherstellen. Auch auf die durchaus komplexe Frage der Organisationspsychologie werden wir in dieser Serie noch zu sprechen kommen. Bis zum nächsten Mal!