Software-Applikationen sind im Digital Business immer stärker der Motor und entscheidender Faktor für den Erfolg eines Unternehmens oder einer Organisation. Ein triftiger Grund für eine zweiteilige Roundtable-Nachlese.
Im ersten Teil: Trotz dieser allgemeinen Erkenntnis ist es für viele User nach wie vor nur mäßig spannend, diesen Motor für ihr Business auch selbst zu schmieren und „hochzutunen“. Vor allem das Testen und Sich-Einbringen bei der Entwicklung oder Migration einer Anwendung wird oft als mühselig und als lästige Pflicht empfunden, die sie vor allem etwas kostet – und zwar ihre Zeit. Was sind die Strategien und Hebel, um die User dafür ins Boot zu holen und sie davon zu überzeugen, dass sie dafür auch einen Nutzen bekommen?
Dazu baten wir gemeinsam mit unserem Co-Host OBJENTIS Software Integration eine hochkarätige Runde von Digital Executives aus verschiedensten Branchen zum Erfahrungs-, Gedanken- und Ideenaustausch. Am runden Tisch diskutierten: Dominik Achleitner (NÖM AG), Alexander Brandl (Zürich Versicherungs-AG), Drazen Djukic (Wienerberger AG), Leo Hintersteiner (WALTER Group), Gerald Lippert (UNIQA Insurance Group), Clemens Prerovsky (APA IT GmbH), Stefan Simek (OBJENTIS Software Integration), Sabine Stortenbeek (OBJENTIS Software Integration), Susanne Tischmann (ÖAMTC), Roland Tscheinig (OBJENTIS Software Integration) und Thomas Zapf (VERBUND).
Moderiert wurde die Diskussion von Michael Dvorak, Herausgeber DIGBIZ LEADER Media & CIO GUIDE/CDO GUIDE, fotografiert wurde sie von Heidi Pein.
„Eine der größten Entwicklungen bei uns war das User Acceptance Testing, mit dem wir begonnen haben, als wir ab 2016 auf eine Plattformstrategie umgeschwenkt sind.“
„Eine der größten Entwicklungen bei uns war das User Acceptance Testing, mit dem wir begonnen haben, als wir ab 2016 auf eine Plattformstrategie umgeschwenkt sind.“
In die haben wir nach und nach unsere gesamte Produktlandschaft integriert. Gestartet haben wir mit den Tests dort, wo wir neue Themen angegriffen haben, zum Beispiel im Bereich Medienbeobachtung und PR-Dienstleistungen. Zugleich haben wir auch ein UX/UI-Team neu aufgebaut – das lieferte dann die eigentliche Basis für das UA-Testen. Am Anfang haben sich da schon viele gefragt: Was machen die jetzt genau und worüber reden die mit unseren Leuten? Uns ging es nämlich nicht darum, die Leute Funktionalitäten auszuprobieren zu lassen, sondern darum, dass sie uns erklären, wie sie arbeiten.
Dann wurde aber bald klar, wie viel Potenzial da drinnen steckt und wie wertvoll genau dieses Feedback ist. Seitdem wird jede UI-Änderung, die wir auf der Plattform brauchen, strukturiert durchgetestet. In Folge haben dann auch unsere eigene UI-Library geschrieben – mit sämtlichen Bausteinen, die wir brauchen, damit wir nicht zum 20. Mal einen Kalender testen müssen. Damit sind wir mittlerweile sehr erfolgreich unterwegs und konnten auch die Geschäftsführung überzeugen.
Schliessen„Die User im Business haben weder die Zeit, sich umfangreiche Manuals durchzulesen, noch das Verständnis dafür, warum sie das tun sollen.“
„Die User im Business haben weder die Zeit, sich umfangreiche Manuals durchzulesen, noch das Verständnis dafür, warum sie das tun sollen.“
Die meisten sehen einfach: Ich muss mich an ein neues System gewöhnen und habe durch das Testen auch noch eine Doppelbelastung. Deshalb braucht es an der Schnittstelle die richtigen Leute wie Projektmanager, die sie begleiten und ihnen erklären, worum es dabei eigentlich geht, warum es wichtig ist, dass sie mitmachen und warum es zum Beispiel wichtig ist, Testfälle zu formulieren, auch wenn sie vielleicht ohnehin wissen, was sie zu testen haben. Weil man die Testfälle braucht, um beim Testmanagement nicht im Blindflug unterwegs zu sein. Und vor allem gilt es auch aufzuzeigen, welche Vorteile die Fachbereiche durch das Testen bekommen, zum Beispiel, dass sie sich auch wirkungsvoller mit ihren Anforderungen einbringen können, wenn sie sich mit dem System jetzt aktiv auseinandersetzen.
Gleichzeitig ist es sehr wichtig, dass die Projektmanager an der Schnittstelle zu den Fachbereichen den Usern dort auch deutlich zeigen, dass man sie beim Testen so weit wie möglich unterstützt und ihnen dabei, zum Beispiel durch den Einsatz von KI beim Erstellen der Testfälle, möglichst viel an repetitiven Tätigkeiten abnimmt.
Schliessen„Natürlich setzen wir auch beim Testen zunehmend auf Automatisierung – allerdings derzeit noch nicht flächendeckend, sondern gezielt unter dem Kosten-Nutzen-Aspekt.“
„Natürlich setzen wir auch beim Testen zunehmend auf Automatisierung – allerdings derzeit noch nicht flächendeckend, sondern gezielt unter dem Kosten-Nutzen-Aspekt.“
Bei einer Standard-Software-Einführung in einem kleinen Geschäftsfeld von uns – zum Beispiel in einem CONTAINEX-Werk – mit 50 Usern und fünf Teilprozessen sind kleine Teams von Key Usern, die am Customzing arbeiten, bislang zumeist die wirtschaftlich effizientere Lösung als großangelegte Testautomatisierungsprojekte und -Tools. Mit dem Nachteil, dass es für ein paar Leute nicht allzu spannend ist, zu testen und dass man sie immer wieder daran erinnern muss, dabei auch an Sonderfälle zu denken.
Allerdings geht der Trend hier auch für uns in die Richtung Automatisierung: Zum einen entwickeln sich insbesondere durch den Einsatz von KI laufend neue Möglichkeiten, und zum anderen wird der Spagat zwischen hochindustrialisierten Prozessen und traditionellen Test-Setups zunehmend zu einer Herausforderung.
Schliessen„Wir haben ein gutes Automation Framework aufgebaut, aber am Ende kommt man dennoch nicht ganz ohne User aus. Deshalb holen wir die von Anfang an mit hinein – und zwar nicht zu viele und nicht zu wenige.“
„Wir haben ein gutes Automation Framework aufgebaut, aber am Ende kommt man dennoch nicht ganz ohne User aus. Deshalb holen wir die von Anfang an mit hinein – und zwar nicht zu viele und nicht zu wenige.“
Klar ist: Sie müssen uns sagen, was sie haben wollen, aber sie können nicht gleich von Beginn weg alles wissen, was sie brauchen. Gerade deshalb gehen wir zunehmend in die Richtung, dass die User uns für ihre Anforderungen vor allem ihre Prozesse erklären und nicht, wo auf dem Bildschirm ein Button sein soll.
Unsere Szenarien sind zum Teil auch für das Testen sehr herausfordernd, weil da unterschiedlichste Komponenten zusammenspielen. Von Software bis zur Hardware inklusive Router im Auto, Drucker und Bankomatkassa umfasst das sozusagen den ganzen Bauchladen, den unsere Pannenfahrer:innen dabeihaben müssen, um von der Pannenhilfe bis zum Abschluss einer neuen Mitgliedschaft sämtliche Services vor Ort abdecken zu können. Wir betreiben auch viel Aufklärungsarbeit, um zu vermitteln, dass wir uns bemühen, diese Komplexität hinter der Anwendung möglichst userfreundlich zur Verfügung zu stellen. Trotzdem lässt sich nicht verhindern, dass die erste Frage beim Testen noch immer manchmal lautet: „Warum ist dieser Button nicht mehr an der Stelle, an der er immer war?“ Der Wunsch, Gewohntes zu behalten, ist nach wie vor stark ausgeprägt – das merkt man auch beim Testen deutlich
Schliessen„Bei User Acceptance Tests bringen die Kolleg:innen aus den Fachbereichen einerseits sehr viel Wissen ein, das ansonsten nirgends wirklich dokumentiert ist. Andererseits können sie dabei auch selbst viel über die neuen Anwendungen lernen.“
„Bei User Acceptance Tests bringen die Kolleg:innen aus den Fachbereichen einerseits sehr viel Wissen ein, das ansonsten nirgends wirklich dokumentiert ist. Andererseits können sie dabei auch selbst viel über die neuen Anwendungen lernen.“
Deshalb möchte ich die User aus den Fachbereichen beim Testen nicht aus der Verantwortung entlassen, obwohl auch wir dabei zunehmend KI einsetzen. Einen der härtesten Tests beim Entwickeln stellen vermutlich die Leute aus der Buchhaltung dar. Die haben so viel implizites Wissen in ihren Köpfen, dass sie auf den ersten Blick erkennen, dass irgendwo etwas nicht stimmt und zum Beispiel ein Konto falsch abgeleitet wurde, auch wenn die Developer und Business Analysts auch noch so gewissenhaft getestet haben. Deshalb ist es so wichtig, dass man die Kolleg:innen an Bord holt und dass sie ihre Tests auch aufzeichnen und replizieren und so ihr Wissen weitergeben.
Das heißt, Testen bedeutet für alle Beteiligten – auch für Anwender:innen aus den Fachbereichen – nicht nur eine lästige Pflicht, sondern verschafft auch Erkenntnisgewinn und Nutzen. Das klarzumachen, ist sehr wichtig, weil das Business natürlich zunächst einmal vorrangig den Aufwand sieht, der durch das Testen entsteht. Diesen Nutzen muss man allerdings auch mit dem entsprechenden organisatorischen Setup transportieren. Wenn ich beispielsweise als IT mitten im Jahresabschluss einen Release machen will, dann werde ich mir schwertun, den Nutzen klarzumachen.
Schliessen„Man muss als IT-Organisation generell und auch beim Testen immer wieder hinterfragen, ob man die Dinge zu sehr durch die eigene Brille sieht – letztlich geht es nämlich immer um die Bedürfnisse der jeweiligen Business Unit und der Leute dort.“
„Man muss als IT-Organisation generell und auch beim Testen immer wieder hinterfragen, ob man die Dinge zu sehr durch die eigene Brille sieht – letztlich geht es nämlich immer um die Bedürfnisse der jeweiligen Business Unit und der Leute dort.“
Die IT neigt ja noch immer teilweise dazu, den Anwender:innen und den Fachbereichen eher technokratisch erklären zu wollen, wie ihre Systeme und Abläufe am besten auszuschauen hätten. Für eine echte End2End-Betrachtung ist es aber notwendig, sich in die Business-Perspektive hineinzuversetzen. Das ist natürlich eine Herausforderung und die ist umso größer, je unterschiedlicher die verschiedenen Fachbereiche und damit auch die User selbst agieren und ticken – so wie das zum Beispiel bei uns der Fall ist.
Ein gut bewährtes Modell der Zusammenarbeit konnten wir mit übergreifenden Produktteams erreichen, also Teams, die über Abteilungsgrenzen hinweg gebildet werden und ein Produkt, eine IT-Lösung für das Business gemeinsam betreuen. Der TestmanagerIn im Team ist hier unmitttelbar mit dem Business abgestimmt. Das Team arbeitet dabei genauso an der Automatisierung von Testfällen, wie an manuellen Tests.
Schliessen„Die User aus den Fachbereichen einzubinden, ist der Knackpunkt schlechthin für jedes Testing-Projekt – wenn das Business im Lead ist, läuft das Projekt, wenn nicht, wird es sehr schwierig.“
„Die User aus den Fachbereichen einzubinden, ist der Knackpunkt schlechthin für jedes Testing-Projekt – wenn das Business im Lead ist, läuft das Projekt, wenn nicht, wird es sehr schwierig.“
Natürlich lässt sich argumentieren, dass es im Eigeninteresse der User in den Fachbereichen liegt, eine Anwendung, mit der sie arbeiten, auch selbst zu testen, weil sie ja etwaige Fehler selbst ausbaden müssen. Das alleine reicht aber nicht. Wenn man dem Fachbereich und den Anwender:innen die Sinnhaftigkeit der Qualitätssicherung beim Testen nicht nahebringen kann, dann schafft das von Beginn weg Frustration. Und dann wird das fertige Produkt auch nur sehr schwer die nötige User Akzeptanz erreichen.
Es ist auch wichtig, möglichst alle User auf einem bestimmten Qualitätslevel einzubinden. Wenn einige akribisch testen und viele andere gar kein Feedback liefern, geht das auf Kosten der Messbarkeit und Aussagekraft.
Schliessen„Mit einem besseren Verständnis für die Test Cases steigt auch die User Akzeptanz in den Fachbereichen.“
„Mit einem besseren Verständnis für die Test Cases steigt auch die User Akzeptanz in den Fachbereichen.“
In Bereichen, in denen agil gearbeitet wird, findet der Kontakt mit dem Fachbereich einfach viel häufiger statt als bei einem Releasewechsel eines Systems, den man nur alle paar Jahre durchführt. Je kürzer die Zyklen sind, desto kleiner wird der Gap natürlich auch beim Testen, weil die Test Cases und damit auch der Aufwand für das Business viel kleiner werden.
Wir setzen dabei auf eine Kombination aus Product Owner, die in der IT sitzen, und Business Owner. Die Business Owner sind dafür zuständig, die Requirements aus den Märkten einzuholen und zu priorisieren und an die Product Owner weiterzugeben. Dieses Duo funktioniert bei uns in den meisten Teilen ziemlich gut.
Schliessen„Was uns hier vor allem bei den User Acceptance Tests stark geholfen hat, ist 100%ige Transparenz: Wir wollen unseren Usern ganz bewusst eine realistische Roadmap liefern.“
„Was uns hier vor allem bei den User Acceptance Tests stark geholfen hat, ist 100%ige Transparenz: Wir wollen unseren Usern ganz bewusst eine realistische Roadmap liefern.“
Beim unserem Geschäft in Österreich liegt der Schwerpunkt auf langen Vertragslaufzeiten – im Schadenunfallsgeschäft sind das regulär zumindest 10 Jahre, bei Lebensversicherungsverträgen sind das sogar 40 oder 50 Jahre – und es ist unüblich während dieser Laufzeit die Bedingungen zu ändern. Bei Microinsurance-Produkten sehen wir aktuell dagegen noch kein signifikantes Geschäftswachstum. Auf dieser Basis richten wir auch unsere Strategie beim Testen auf.
Gerade bei der Mainframe-Ablöse in der Finanzbranche wurden in der Vergangenheit oft unrealistisch hohe Erwartungen geweckt. Eine Backend-Migration ist nicht in drei Jahren erledigt – dafür muss eine Vielzahl an verschiedensten Kernprozessen umgestellt werden. Deshalb liefern wir die Releases iterativ aus und holen die Fachbereiche beim Testen bewusst erst dann an Bord, wenn wir glauben, die nötige Qualität bieten zu können. Damit schlagen wir nicht einen komplett agilen Weg ein, der es ermöglicht, den Fachbereichen stabile Prototypen weiterzugeben und nicht zu schnell jeden kleinen technischen Erfolg zu verkaufen … um dann vielleicht das Feedback zu bekommen: Das geht so nicht.
Schliessen„Die größte generelle Herausforderung beim Entwickeln und Testen einer Software-Lösung ist es, die Leute mitzunehmen.“
„Die größte generelle Herausforderung beim Entwickeln und Testen einer Software-Lösung ist es, die Leute mitzunehmen.“
Hier nach wie vor mit Lasten- und Pflichtenheft zu arbeiten, ist zum Scheitern verurteilt, weil beim einen die Leute oft irgendetwas hineinschreiben, und weil sie das andere häufig nicht wirklich verstehen. Ein Konzept, das bei uns beim Testen sehr gut funktioniert, ist das der User Stories.
Wir haben das Testen auch in Quality Gates integriert – das nimmt den reinen Schulungscharakter weg und macht klar, dass sie sich selbst aktiv einbringen müssen, damit die Anwendungen und Werkzeuge, mit denen sie arbeiten, auch funktionieren – und dazu gehört es eben auch, wenn nötig beim Testen beispielweise immer wieder die gleichen Daten anlegen. Das funktioniert vor allem bei kleineren Projekten sehr gut. Man braucht allerdings auch immer gute Master Projektmanager, die die Leute in ihren konkreten Arbeitsszenarien abholen.
Schliessen„Es gibt zwischen den individuellen User-Szenarien große Unterschiede bei den jeweiligen Themen und auch den Reifegraden der einzelnen Fachbereiche – das muss ich auch beim Testen berücksichtigen.“
„Es gibt zwischen den individuellen User-Szenarien große Unterschiede bei den jeweiligen Themen und auch den Reifegraden der einzelnen Fachbereiche – das muss ich auch beim Testen berücksichtigen.“
Wenn ich eine ganz neue Applikation bekomme, ist das Testen für die User generell einmal ein spannenderes Thema als eine Migration auf eine neue Version eines bestehenden Systems. Durch eine Migration ändert sich für den Fachbereich häufig nicht so wahnsinnig viel – man hat danach fast die gleiche Funktionalität zur Verfügung. Umso wichtiger ist es durch entsprechendes Testen sicherzustellen, dass genau das reibungslos klappt, und darüber hinaus vor allem den konkreten Mehrwert, der durch die Migration für die User bei ihrer Arbeit entsteht, zu vermitteln – und dazu sind User Stories auch aus unserer Erfahrung heraus ein sehr gutes Mittel.
Ähnliche Unterschiede gibt es zwischen den einzelnen Fachbereichen: Es gibt Abteilungen, die sagen, dass sie wissen, wie ihre Abläufe, beispielsweise im Fall einer Verrechnungsabteilung ihre Billing-Prozesse, funktionieren, und dass sie auch genau wissen, was sie diesbezüglich testen müssen. Und es gibt andere Fachabteilungen, die gar nicht wissen, wie sie einen Testfall formulieren sollen. Deshalb gilt es sehr individuell ans Testen heranzugehen, um die Leute wirklich bei ihrer Arbeit und beim Nutzen, der daraus für sie entsteht, abzuholen.
Schliessen