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 zweiten Teil: Das Potenzial der Business-Anwendungen in die Praxis umzusetzen und in Produktivität zu verwandeln, ist oft alles andere als einfach. Häufig prallen da verschiedene Welten aufeinander – und das in mehrfacher Hinsicht. Zum einen erfordern Mainframe- und DevOps-Szenarien auch beim Testen völlig unterschiedliche Herangehensweisen. Zum anderen gehen die Sichtweisen in der IT und im Business, was denn Agilität tatsächlich bedeutet, was der Zweck eines Prototyps ist, oder was denn ein MVP können muss, mitunter deutlich auseinander. Ein Gap, der jetzt allerdings nicht zuletzt dank KI kleiner werden könnte.

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), 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.


„Es gibt auch beim Testen nicht die eine generelle Organisation und Vorgangsweise, die für alle unterschiedlichen Ansätze und Reifegrade und alle unterschiedlichen Märkte mit unterschiedlichen Zielgruppen die richtige ist.“

Gerald Lippert

CDAO I Head of Group Data & IT UNIQA Insurance Group AG

„Es gibt auch beim Testen nicht die eine generelle Organisation und Vorgangsweise, die für alle unterschiedlichen Ansätze und Reifegrade und alle unterschiedlichen Märkte mit unterschiedlichen Zielgruppen die richtige ist.“

Gerald Lippert

CDAO I Head of Group Data & IT UNIQA Insurance Group AG
Weiterlesen

Ein Paradebeispiel für Österreich und gerade für den Banken- und Versicherungssektor ist die Ablöse des Mainframe, der flächendeckend in fast schon tektonischen Geschwindigkeiten abläuft. Gleichzeitig gibt es den Trend in Richtung Microinsurance, auch wenn der sich in Österreich noch nicht allzu stark niederschlägt. Wir haben beispielsweise im Konzern ein Projekt in Südosteuropa, gemeinsam mit einem asiatischen Softwareanbieter, der auf digitalen Vertrieb spezialisiert ist.

Das sind komplett unterschiedliche Welten, die da aufeinanderprallen: Auf der einen Seite braucht es zehn Jahre oder mehr, um ein Backend zu erneuern, auf der anderen Seite haben wir es mit Einführungszeiten von drei bis sechs Monaten zu tun. Das bedeutet natürlich auch ganz unterschiedliche Herangehensweisen an das Testen. Die Backend-Ablöse ist ein Marathon, bei dem man sich sehr gut überlegen muss, wann man sich den Fachbereich für das Testen an Bord holt. Wenn ein Microinsurance-Produkt dagegen in ein paar Monaten marktreif sein muss, muss es gemeinsam mit dem Business entwickelt werden und muss jede Änderung im User Interface vom Fachbereich sofort getestet werden.

Schliessen

„KI wird zu einem echten Game Changer – mit ihrer Hilfe kann ich die Fachbereiche beim Testen spürbar entlasten und ihnen konkreten Nutzen liefern.“

Roland Tscheinig

CEO OBJENTIS Software Integration

„KI wird zu einem echten Game Changer – mit ihrer Hilfe kann ich die Fachbereiche beim Testen spürbar entlasten und ihnen konkreten Nutzen liefern.“

Roland Tscheinig

CEO OBJENTIS Software Integration
Weiterlesen

Vor allem kann ich mit Unterstützung von KI die Durchführung des Testens für das Business viel schneller, effizienter und komfortabler gestalten. Dinge wie Large Language Models bieten hochinteressante Möglichkeiten, um erstklassige Testfälle zu erstellen, indem ich sie mit allen möglichen Dokumenten wie User Stories, Requirements, User-Dokumentationen und Pflichtenheften füttere. Ich kann mit KI Testdaten erzeugen und brauche niemanden mehr, der oder die sie dazu reinklopft, und ich brauche keine komplexe Dokumentation mehr, um eine Applikation zu verstehen.

Das heißt, ich kann den Fachbereich genau von jenen repetitiven Tätigkeiten entlasten, die zu Fragen führen wie: Warum muss ich zehnmal die gleichen Daten neu anlegen? Warum muss ich wieder Automationsfälle schreiben, wenn jemand anderer schon Requirements, Pflichtenhefte und User Stories erstellt hat, wenn also aus dem Fachbereich ohnehin schon alles gesagt ist? Das kann man den Usern ja kaum wirklich verständlich machen.

Schliessen

„Ich glaube, dass es heute beim Testen noch dringenden Aufholbedarf und viel Potenzial gibt, um es intelligenter zu gestalten.“

Dominik Achleitner

Head of IT NÖM AG

„Ich glaube, dass es heute beim Testen noch dringenden Aufholbedarf und viel Potenzial gibt, um es intelligenter zu gestalten.“

Dominik Achleitner

Head of IT NÖM AG
Weiterlesen

Ich habe mich schon vor zehn Jahren mit neuen Standards beim Testen beschäftigt, tatsächlich hat sich seit damals meiner Erfahrung nach aber nicht wirklich grundsätzlich viel verändert. Viele praktizieren heute nach wie vor so eine Art exploratives Testen nach dem Motto: Dann klick ich einmal dahin.

Ich habe das selbst einmal in einem Eye Tracking Labor der FH Burgenland erlebt. Es war sehr spannend, dort zu sehen, wohin die User beim Testen schauen, was sie tatsächlich nutzen und was dabei alles nicht kongruent läuft.

Schliessen

„Wir hatten auch bei der Auswahl und Zusammenstellung der Testgruppen einen Lernprozess.“

Susanne Tischmann

Leiterin Technologie CTO & CIO ÖAMTC

„Wir hatten auch bei der Auswahl und Zusammenstellung der Testgruppen einen Lernprozess.“

Susanne Tischmann

Leiterin Technologie CTO & CIO ÖAMTC
Weiterlesen

Bei unserem Mitgliederverwaltungssystem haben wir etwa gesehen, dass es nicht viel Sinn macht, die Kolleg:innen im Backoffice testen zu lassen, sobald man zum Beispiel 80 Prozent der Standardaufgaben fertiggestellt hat, auch wenn sie extrem viel an Wissen einbringen können. Ihre Tätigkeit findet nämlich erst ganz am Ende der Prozesskette statt und besteht zu einem Großteil aus unterschiedlichsten Sonderfällen, die vorne am Frontend nicht erledigt worden sind.

Deshalb ist es sinnvoller, diese Kolleg:innen erst dann in das Testen einzubinden, wenn es um all diese Ausnahmen geht, und wenn man sie dort abholen kann, wo sie mit ihrer Arbeit einsetzen.

Schliessen

„Heute arbeiten wir in der Entwicklung schon sehr industrialisiert – es hat allerdings einige Jahre gedauert, dieses Setup zu etablieren.“

Leo Hintersteiner

CIO WALTER Group

„Heute arbeiten wir in der Entwicklung schon sehr industrialisiert – es hat allerdings einige Jahre gedauert, dieses Setup zu etablieren.“

Leo Hintersteiner

CIO WALTER Group
Weiterlesen

Wir haben bei LKW WALTER vor sieben oder acht Jahren begonnen, auf agile Entwicklung umzustellen und leben sie mittlerweile wirklich durchgängig. Wir lösen dabei auch viele Legacy-Themen ab und bauen sie als Greenfield komplett neu, um sie End2End zu digitalisieren und zu automatisieren. Wir haben heute 60 bis 70 Entwickler:innen, die Code produzieren und deployen problemlos bis zu 20 Mal in der Woche. Und wir haben für jedes Thema Product Owner aus dem Business und Business Analysts, die bei der Produktentwicklung mitarbeiten und auch als Requirement Engineers agieren und dabei helfen, User Stories zu schreiben und Abnahmekriterien zu definieren.

Die Leute in den Fachbereichen zum Beispiel dazu zu bringen, wirklich zu priorisieren und zwar nicht nur alles mit Prio 1, war allerdings nicht einfach und ging nicht von heute auf morgen. Die User mussten auch lernen, damit umzugehen, dass sie nicht mehr einfach auf die Schnelle in der Entwicklung anrufen und ihre Vorstellungen einwerfen konnten.

Schliessen

„Der emotionale Faktor spielt bei Testprojekten oft eine ganz entscheidende Rolle.“

Sabine Stortenbeek

Senior Consultant OBJENTIS Software Integration

„Der emotionale Faktor spielt bei Testprojekten oft eine ganz entscheidende Rolle.“

Sabine Stortenbeek

Senior Consultant OBJENTIS Software Integration
Weiterlesen

Häufig gibt es bei einem Projekt einzelne Personen, die komplett auf Widerstand schalten und diesen Widerstand löst man nicht allein mit Testkonzepten und mit Automatisierung auf – dafür braucht es genauso Soft Skills und Kommunikation.

Ein wichtiger Schlüssel ist dabei eben die Rolle der Projektmanager – unabhängig davon, ob sich diese Rolle im jeweiligen Unternehmen genauso bezeichnet und ob die von jemandem intern eingenommen wird, oder ob sie ein externer Partner übernimmt, so wie wir das zum Beispiel oft machen. Entscheidend ist, dass diese Funktion die Schnittstelle zwischen dem Business, also den Fachbereichen, und der IT bildet und dazu die Sprache beider Seiten versteht und spricht und die Leute aus diesen beiden Bereichen wirklich mitnimmt. Und das geht am besten in Kleingruppen. Wir stellen das bei unseren Kundenprojekten immer wieder fest: Man kann das beste Testkonzept und noch so sauber aufgesetzte Prozesse und Handbücher haben – wenn der Fachbereich nicht mit an Bord ist und mitspielt, wird es nicht wirklich funktionieren.

Schliessen

„Wenn man über Agilität redet, meinen die IT und die Fachbereiche zum Teil damit völlig unterschiedliche Dinge.“

Clemens Prerovsky

Geschäftsführer APA-IT Informations Technologie GmbH

„Wenn man über Agilität redet, meinen die IT und die Fachbereiche zum Teil damit völlig unterschiedliche Dinge.“

Clemens Prerovsky

Geschäftsführer APA-IT Informations Technologie GmbH
Weiterlesen

Niemand in einem Fachbereich hat wirklich darauf gewartet, dass die IT agiles Arbeiten, Entwickeln oder Testen ausruft – im Gegenteil. Viele haben gedacht, das bedeutet, dass sie sich jetzt nicht mehr auf Planungen verlassen können, und der größte Schmerz der Kolleg:innen war, als sie realisiert haben, dass sie plötzlich intensiv als Teil des Projekts eingefordert waren, damit die IT die entsprechenden Applikationen bauen kann. Da war die Reaktion zunächst einmal: „Das ist für uns extrem mühsam, wenn wir da so tief mit drinnen sind – die Anwendungen zu bauen und zu testen, ob sie funktionieren, ist Eure Sache.“

Hier das neue Setup zu etablieren, in dem alle verstehen, dass sie ein Teil davon sein müssen, war schon harte Arbeit. Letztendlich sehen und erleben jedoch heute alle diese neue Stufe der Qualität und des Nutzens, die mit diesem Ansatz möglich sind.

Schliessen

„In vielen Bereichen würde es ohne Agilität und DevOps gar nicht funktionieren – da ist es eine absolute Grundvoraussetzung für das jeweilige Business, dass die Software-Entwicklung und der Fachbereich eng abgestimmt agieren.“

Thomas Zapf

Director Digital, Information Security, IT and Telecom VERBUND

„In vielen Bereichen würde es ohne Agilität und DevOps gar nicht funktionieren – da ist es eine absolute Grundvoraussetzung für das jeweilige Business, dass die Software-Entwicklung und der Fachbereich eng abgestimmt agieren.“

Thomas Zapf

Director Digital, Information Security, IT and Telecom VERBUND
Weiterlesen

Da ist es notwendig, dass die Herausforderungen des Business zur gemeinsamen Aufgabe werden und dass die Entwickler und der jeweilige Fachbereich – am besten koordiniert durch Product Owner und eventuell agil in Sprints – gemeinsam an Lösungen arbeiten. Und dass sie dabei die jeweils wichtigsten Produkt-Features zuerst umsetzen und gleichzeitig die Testautomatisierung ausbauen. Alle zwei Jahre ein Pflichtenheft zu schreiben und dann zu versuchen, es umzusetzen und großangelegt zu testen, ist da nicht machbar.

Gleichzeitig gibt es insbesondere für einen Energieversorger Bereiche und Themen, in denen auch und gerade beim Testen Null-Fehler-Toleranz herrscht. Wenn daran hängt, ob es auch nur den kleinsten Stromausfall gibt, kann man sich einfach nicht leisten, mit einem Produkt rauszugehen, das nicht absolut fehlerfrei funktioniert.

Schliessen

„Wir forcieren seit ein paar Jahren den Bau von Prototypen und Proofs of Concept, die aber extrem schnell und billig machbar sein müssen.“

Leo Hintersteiner

CIO WALTER Group

„Wir forcieren seit ein paar Jahren den Bau von Prototypen und Proofs of Concept, die aber extrem schnell und billig machbar sein müssen.“

Leo Hintersteiner

CIO WALTER Group
Weiterlesen

Das beginnt damit, dass ein paar Leute quick und dirty einen Code schreiben, ohne zu testen, um mit einem Click Dummy überhaupt einmal auszuprobieren: Ist die Idee es wert, sie weiter auszubauen? Und wenn das der Fall ist und das Ganze die nötige Reife erreicht hat, geht es auf die normale Software-Entwicklungsebene, wo wir dann beispielsweise auch die User Stories schreiben. Wenn wir einen ersten Prototyp bauen, haben wir allerdings manchmal das Problem, dass dann ein Bereich diesen Prototyp gleich weiter ausbauen möchte. Dann muss man allerdings klar Stopp sagen – weil ein Prototyp dazu da ist, weggeschmissen zu werden – so wie es zum Beispiel in der Automotive-Industrie selbstverständlich ist.

Mit dem Thema MVP beschäftigen wir uns heute ganz gezielt in einem kleinen Team und haben dabei das Glück, dass viele unserer 190 Abteilungen sehr ähnliche Abläufe haben. Vor diesem Hintergrund tut man sich leichter, einen Product Owner zu finden, der mit ein oder zwei kleinen Abteilungen die Pionierrolle übernimmt und zunächst einmal ein MVP mit erarbeitet, bevor wir das für alle User freischalten. Dadurch haben wir auch keinen echten Bedarf an großangelegten User Accepting Tests.

Schliessen

„Bei der agilen Produktentwicklung ist das Verständnis für Test Cases und ist damit auch die User-Akzeptanz viel besser als in Wasserfall-Szenarien.“

Drazen Djukic

Head of Digital Business Solutions, Corporate IT Wienerberger AG

„Bei der agilen Produktentwicklung ist das Verständnis für Test Cases und ist damit auch die User-Akzeptanz viel besser als in Wasserfall-Szenarien.“

Drazen Djukic

Head of Digital Business Solutions, Corporate IT Wienerberger AG
Weiterlesen

Bei MVPs gibt es allerdings manchmal die Problematik, dass die Fachbereiche da möglichst viel hineinpacken möchten und sich damit vieles verzögert. Ein Grund dafür ist die Befürchtung, dass sie nach Abschluss eines Projekts vielleicht zu lange warten müssen, bis all ihre anderen Anforderungen integriert werden.

Wir steuern dem entgegen, indem wir ein fixes Team für das jeweilige Produkt etablieren, das für das Business dauerhaft Ansprechpartner bleibt – und damit auch sozusagen personifizierter Garant dafür ist, dass auch um nach dem Go Live des MVP die zusätzlichen Features integriert werden.

Schliessen

„Eine Herausforderung ist, dass immer wieder ein MVP gewünscht ist, weil man Kunden rasch etwas präsentieren möchte.“

Clemens Prerovsky

Geschäftsführer APA-IT Informations Technologie GmbH

„Eine Herausforderung ist, dass immer wieder ein MVP gewünscht ist, weil man Kunden rasch etwas präsentieren möchte.“

Clemens Prerovsky

Geschäftsführer APA-IT Informations Technologie GmbH
Weiterlesen

Bei genauerer Nachfrage stellt sich allerdings heraus, dass man sich darunter ein vollumfängliches Produkt mit sämtlichen Features vorstellt, weil das, was die APA an Ihre Kunden rausgibt, absolut Feature-komplett sein und fehlerfrei funktionieren muss. Das ist Anspruch und Kulturmerkmal der APA – aber nicht die Idee des MVPs.

Diese Lücke macht das Ganze sehr schwierig, weil es eine Phase nach dem Prototyp gibt, in der man das Feedback der Kunden braucht.

Schliessen

„Wir beobachten, dass die junge Generation an Mitarbeiter:innen ein ganz anderes Verständnis zum Beispiel für das Thema MVP mitbringt.“

Alexander Brandl

Head of IT Service Creation Zürich Versicherungs-AG

„Wir beobachten, dass die junge Generation an Mitarbeiter:innen ein ganz anderes Verständnis zum Beispiel für das Thema MVP mitbringt.“

Alexander Brandl

Head of IT Service Creation Zürich Versicherungs-AG
Weiterlesen

Viele junge Mitarbeiter:innen im Business zeigen ein viel größeres Commitment für die Bedeutung der IT und bringen sich dementsprechend auch viel aktiver bei den Demands und beim Testen ein.

Für die ist es ganz selbstverständlich, wenn beim Testen ein Software-Produkt nicht vom ersten Tag an völlig fehlerfrei funktioniert.

Schliessen

„Man muss sich von dem Gedanken lösen, dass ein MVP gleich an die Kund:innen rausgehen muss.“

Susanne Tischmann

Leiterin Technologie CTO & CIO ÖAMTC

„Man muss sich von dem Gedanken lösen, dass ein MVP gleich an die Kund:innen rausgehen muss.“

Susanne Tischmann

Leiterin Technologie CTO & CIO ÖAMTC
Weiterlesen

Wir haben zum Beispiel eine Gruppe von 15.000 Mitgliedern, die zunächst quasi intern einen Click Dummy erhalten – insbesondere, wenn es um Web-Services geht, die wir dann sehr breit zur Verfügung stellen. Dabei muss man noch keine Schnittstellen anbinden, muss noch nicht austesten, ob die die APIs alle sauber laufen und erspart man sich sehr viel an Kosten.

Die User verstehen das auch und liefern uns valide Rückmeldungen, ob der Prozess für sie passt oder nicht. Um dann aber tatsächlich in der Breite an Kund:innen rauszugehen, braucht es mehr als einen Prototyp – dazu muss man schon ein echtes Produkt schnitzen.

Schliessen

„Wenn man am Business vorbei galoppiert und dessen jeweiligen Bedürfnisse nicht berücksichtigt, wird man nicht die nötige Akzeptanz erzielen – weder für die gesamte IT, noch für die Anwendung, die man gerade baut und testet.“

Thomas Zapf

Director Digital, Information Security, IT and Telecom VERBUND

„Wenn man am Business vorbei galoppiert und dessen jeweiligen Bedürfnisse nicht berücksichtigt, wird man nicht die nötige Akzeptanz erzielen – weder für die gesamte IT, noch für die Anwendung, die man gerade baut und testet.“

Thomas Zapf

Director Digital, Information Security, IT and Telecom VERBUND
Weiterlesen

Wir haben zum Beispiel eine Business-Einheit, die sich selbst praktisch als Software-Firma definiert und auch die entsprechende Agilität einbringt – mehr kann man als IT und als Digitalisierungsverantwortlicher kaum erreichen.

In anderen Bereichen gibt es extreme Langläufer-Themen und Projekte, die über Jahre oder auch Jahrzehnte laufen. Das ist für die Digitalisierung oft eine ziemliche Herausforderung und zwar nicht nur technologisch, weil wir ja in einem extrem technologiegetriebenen Umfeld agieren, sondern vor allem, weil man hier auf ein komplett anderes Verständnis trifft. Da gibt es dann mitunter großen Diskussionsbedarf zwischen Business und IT, und da muss man als IT auch sehr sorgfältig überlegen, welche Schritte man wann setzt.

Wenn man die IT-Systemlandschaft entsprechend der Technologiestrategie entwickeln möchte und wenn sich Governance zur gewinnbringenden Technologiestrategie wandeln soll, ist das gegenseitige Vertrauen zwischen Business und den IT-Architects erforderlich. Und um das zu schaffen, braucht es auf der IT-Seite reichlich Hands-On-Mentalität.

Schliessen