Transcript

Narine Brsikyan: Hallo und herzlich Willkommen zur neuen Podcast-Folge Business Transformation mit SAP S/4HANA. Mein Name ist Narine Brsikyan und heute, da möchte ich über ein Thema sprechen, das für viele vielleicht dann eine unangenehme oder unbequeme Pflicht ist, und zwar die Testmigration bei SAP S/4HANA. Die Umstellung auf SAP S/4HANA ist ja für Kunden ein umfangreiches Projekt, das rechtzeitig geplant und vorbereitet werden muss, was natürlich auch mit sehr vielen Vorteilen und Chancen verbunden ist, aber auch mit gewissen Risiken, die erkannt und behoben werden müssen. Und ein Aspekt davon ist eben die Datenmigration und darüber möchte ich heute mit dir, Peter, sprechen. Und vielleicht magst du dich einmal kurz vorstellen, auch zu deinen fachlichen Background, und dann können wir weiterschauen.

Peter Echter: Hallo Narine. Danke für die Einladung.

Narine Brsikyan: Gern.

Peter Echter: Freut mich, dass wir da über das Thema sprechen. Dadurch, was du eben gesagt hast, es ist umfangreich, werden wir uns nur einen kleinen Aspekt herausgreifen für heute. Zu meiner Person, seit 1. April bin ich neu bei der mgm cp, war vorher 14 Jahre lang zuständig bei einem großen deutschen Energieversorger für dessen SAP-Sub-Finanzsysteme. Diese Systeme insgesamt haben ungefähr, ja, hier um die sechshundert Gesellschaften des Energieversorgers bedient und dadurch, dass der Konzern immer wieder Firmen gekauft, verkauft hat, kann ich auf knapp 14 Jahre, ja, Migrationserfahrung zurückblicken im SAP-Bereich und diese Erfahrung möchte ich natürlich jetzt gewinnbringend bei der mgm mit vielen Kollegen einsetzen.

Narine Brsikyan: Ja, sehr schön. Deswegen habe ich auch dich ausgesucht, und wir wollen ja über Datenmigration sprechen und vielleicht einmal zu Beginn, kannst du uns vielleicht einmal abholen, in welchem Stadium wir uns im Projekt befinden, bevor die Datenmigration startet?

Peter Echter: Ja. Lasse mich das einmal kurz ausführen. Wir werden uns heute den Aspekt des Testens ein bisschen herauspicken und das einmal näher beleuchten. Dann stellt sich hier die Frage, wann kommt das Testen dran? Von der Phasenlogik her wird es vielen sagen, dass das eher in der Phase nach der Analyse und nach dem Abschluss der Komponentenbauten, also der Build-Phase, erst drankommt. Es gibt ja auch unterschiedliche Testarten. Zu den unterschiedlichen Testarten gehören beispielsweise einzelne Unit-Tests. Die haben mit der Testmigration nichts zu tun. Man probiert einfach nur aus, ob das Zielsystem und auch das Kontrollsystem quasi so funktionieren, wie man sich das vorstellt, und so implementiert worden sind. Im Vorfeld vor der ersten Testmigration gibt es auch noch unterschiedliche technische Systemtests. Diese Systemtests sind dann immer unter Ausschluss der Fachabteilungen. Da sind die Techniker am Werke praktisch in ihrer Werkstatt. Das erste Mal, wo Fachabteilungen eben hier so richtig stark dann mit dem Testsystem oder dem neuen System konfrontiert werden, ist der sogenannte Benutzerakzeptanztest. Man drückt ja heute viel in Englisch aus. In Englisch ist es dann der UAT oder der User Acceptance Test oder das User Acceptance Testing. Hinarbeiten tun wir eigentlich alle immer auf die Live-Migration, aber wir sprechen heute nicht von der Live-Migration, sondern wir werden uns in dem Projekttestsystem herumtreiben. In der Live-Migration, da wird dann darauf hingearbeitet, dass es bei einer Produktionsmigration ganz zum Schluss zur Produktionsfreigabe kommt und die Produktionsfreigabe, da ist in der Regel dann immer ein Operational Readiness Test vorgeschaltet, der sogenannte ORT. Aber den werden wir uns heute nicht ansehen. Wir werden uns voll auf den Benutzerakzeptanztest oder den UAT konzentrieren.

Narine Brsikyan: Ja, und dabei, kann ich mir vorstellen, dass auch weil das ist ja auch ziemlich, also sind sehr viele Prozesse, viele Durchgänge, die man macht, ne? Und da kann ich mir vorstellen, dass es eben auch für die Beteiligten Herausforderungen mit sich bringt, ja? Und vielleicht kannst du uns dazu etwas erzählen?

Peter Echter: Also die Herausforderungen im Gesamtprojekt sind ja mannigfaltig, aber schauen wir bloß einmal auf die erste Testmigration und auf das Testen selbst, ja? Wen haben wir denn da als Beteiligte, ja? Beteiligte haben wir einerseits die Fachabteilungen, die letztendlich ja auch die Testfälle schreiben sollen und auch aus den Testfällen sich ja bestimmte Ergebnisse erwarten. Die Fachabteilungen selbst sind ja dadurch, dass wir ja schon eine gewissen Projektzeit hinter uns gebracht haben, durch, ja, Anfragen und Teilnahmen an Diskussionen in der Analysephase schon einmal beteiligt gewesen und haben dann auch festgestellt, macht Arbeit, das ganze Projekt und meine eigentliche Tagesarbeit bleibt immer wieder liegen. Und jetzt kommen die ja auch noch daher und wollen testen und brauchen dann auch noch meinen Input und meine Mitarbeiter. Also Testen für Fachabteilungen, das ist fast wie ein rotes Tuch. Die sehen das als lästig, als Störung und als ungeliebte Pflicht an.

Narine Brsikyan: Hätte ich eine Zwischenfrage. Wer gehört zu den Fachabteilungen?

Peter Echter: Ja, zu den Fachabteilungen, wir werden uns hier einmal ein bisschen bei den Finanzsystemen umsehen. Da gibt es einerseits die Finanzabteilung. Das ist in der Regel die Debitoren- und Kreditorenbuchhaltung in der Finanzabteilung. Und dann gibt es die Hauptbuchhaltung, und die müssen sich darum kümmern, dass sozusagen alle Ausgaben und alle Einnahmen auf den entsprechenden Sachbuchkonten gebucht werden, dass ein Monatsabschluss, ein Finanzmonatsabschluss gemacht wird, dass ja letztendlich bis zum Jahresende auch eine Bilanz erstellt werden können. Dann, was viele auch kennen, ist die sogenannte Einkaufabteilung oder das Procurement. Die haben zu gewährleisten, dass für die Firma dann, was benötigt wird, diese Bestellungen losgetreten werden. Die machen die Verhandlungen mit den Lieferanten, sorgen dafür, dass das Material oder die Services, die man benötigt, auch bestellt werden können und tragen dafür Sorge, dass das an den sogenannten Bedarfsträger dann auch ankommen wird. Letztendlich haben diese dann auch zwar das Interesse, dass das verbucht wird, aber so genau schauen die da nicht hin wie die Finanzabteilung. Was man dann oft auch hat, das ist eine Vertriebsabteilung oder eine Serviceabteilung, die letztendlich Lösungen oder Services an einen Endkunden verkaufen. Die müssen einerseits bestellen. Die müssen auch andererseits schauen, dass die Services sozusagen erbracht werden, und haben natürlich eminentes Interesse daran, dass der Endkunde auch bezahlt, also sprich die Faktura ist in deren Interesse, was ja dann wiederum die Finanzabteilung betrifft, ja? Und dann gibt es noch vielfältige andere Abteilungen, aber das würde jetzt, glaube ich, den kompletten Rahmen unseres Podcasts für heute sprengen. Da können wir ein anderes Mal daraufschauen.

Narine Brsikyan: Greife ich darauf zurück.

Peter Echter: Da bin ich mir sicher. Wir waren ja gerade bei den Herausforderungen und sozusagen haben gestreift, welche wesentlichen Fachabteilungen sind denn beim Testen in einer Testmigration beteiligt. Dann will ich auch die anderen Akteure noch ein bisschen vorstellen. Einerseits haben wir dann noch die technischen Umsetzer. Wir sprechen fachlich eigentlich von Migrateuren, die anhand der Vorgaben der Fachabteilungen sozusagen das Feldschlüssel-Mapping umsetzten. Feldschlüssel-Mapping heißt letztendlich, was waren die Werte von verschiedenen Sachen im alten System und auf welche Werte im neuen System werden diese dann bei einer Datenmigration umgesetzt? Die Migrateure haben dann auch andere sogenannte Mapping-Regeln zu den Feldschlüsseln, die sie von den Fachabteilungen erhalten, und setzten das Migrationswochenende, also kommende Wochenende, dann um und verlassen sich darauf, dass das, was sie sozusagen als Regeln oder Schlüsselwerte alt-neu in den Händen halten, dass das auch technisch umgesetzt wird. Und als letzten Wichtigen schauen wir einmal auf einen weiteren Akteur, damit das Ganze ein bisschen geordnet und auch dementsprechend in der ausreichenden Qualität abläuft, macht das durchaus Sinn, extra für die Testmigrationen und auch letztendlich für die Live-Migration einen dedizierten Testmanager oder Testmanagerin zu haben. Wird oft auch als Testkoordinator oder Testteilprojektleiter beziehungsweise Teilprojektleiterin bezeichnet. Das sind im Wesentlichen die drei großen Gruppen der Akteure, die miteinander harmonieren müssen, um hier eine erfolgreiche Testmigration an den Tag zu legen.

Narine Brsikyan: Ja, vielleicht kannst du dazu die situative Perspektive der drei Fachabteilungen beschreiben? Das wäre auch ganz interessant.

Peter Echter: Ja, gern. Mache ich gern. Ja, dann picken wir uns doch als erstes einmal die Fachabteilungen heraus. In welcher Situation befinden sie sich und was ist deren Befinden, sage ich einmal, weil die sind ja nicht immer kompatibel zueinander, einerseits die Fachabteilungen untereinander als auch dann ihr Verhältnis eben zu den Datenmigrateuren oder zum Testmanager. Aber wir richten den Blick jetzt auf die Fachabteilungen, ja? Aus welcher Startposition kommen sie? Sie sind gestresst, weil es gibt quasi dann demnächst ein neues System. Das alte System kenne sie aus dem FF und können sozusagen blind buchen, bestellen oder was auch immer, ja? Sie werden da jetzt konfrontiert mit der ersten Testmigration, das erste Mal zu testen, eines neuen Systems. Das heißt, viele Funktionen im neuen System sind ihnen nicht unbedingt bekannt. Meist ist es ja auch so, dass dann Schulungen erst viel später angeboten werden oder dass es spezielle Schulungen eben für die Key- und Testuser bereits im Vorfeld gegeben hat. Aber das ist dann meistens nur ein einzelner Termin und wenn jetzt gerade eine wichtige Person oder eine erfahrene Fachabteilungsperson nicht an der Schulung teilgenommen hat, dann sind die neuen Funktionen einfach nicht so bekannt und dadurch herrscht Unsicherheit. Dann gibt es oft auch hier irgendwie Projektdruck. Projektdruck in der Hinsicht, dass die Zeiten immer knapp bemessen sind und knapp bemessene Zeiten bedeuten gleichzeitig, dass die Fachabteilungsmitarbeiter, die sogenannten Keyuser, innerhalb kürzester Zeit ihre Testfälle beschreiben müssen und auch innerhalb kurzer Zeit sozusagen zu Testen müssen und auch die Fehler dokumentieren müssen. Und das hat eben in der Vergangenheit für die Fachabteilungsmitarbeiter mit großer Erfahrung schon einfach die Erkenntnis reifen lassen, das Testen ist immer lästig und eigentlich eine total unbequeme Pflicht.

Narine Brsikyan: Und ohne geht es nicht, ne?

Peter Echter: Ohne geht es nicht, ja. Aber was ist dann die Folge? Also Testfälle werden dann ganz oberflächlich und auch mit Lücken beschrieben, einfach damit man die Testfälle abgeben kann. Wir hatten ja ganz kurz vorhin das Beispiel mit den Fachabteilungen, welche unterschiedlichen gibt es? Hier nehme ich jetzt noch einmal Anlauf und versetze mich da in die Einkaufsabteilung, ja? Die Einkaufsabteilung hat hier das Interesse, dass hier eine Bestellung fristgerecht beim richtigen Adressaten ankommt. Ob jetzt die Bestellung ganz genau richtig auf dem richtigen Sachbuchkonto gebucht worden ist, lasse es mich diplomatisch ausdrücken, ist der Einkaufsabteilung sekundär wichtig. Lasse es mich so ausdrücken. Dagegen in der Finanzabteilung ist es äußerst wichtig, also primär wichtig. Das heißt also, die Schwerpunkte in den unterschiedlichen Abteilungen für einen Testfall sind unterschiedlich. Gut, was wir dann mit konfrontiert werden, ist einfach, wenn hier das Daten-Mapping nicht sauber ist, dann kann es durchaus sein, dass eine Bestellung in der Einkaufsabteilung hier richtig ausgeführt worden ist und auch sozusagen beim Richtigen landet. Allerdings kann das dann sein, dass das falsche Sachbuchkonto ist, was dann eben der Finanzabteilung nicht gefällt. Und der Finanzabteilung fällt das dann eben bei der Testung der ersten Testmigration auf, dass das hier ein falsches Sachbuchkonto gibt. Und das ist der Einkaufsabteilung nicht ganz so wichtig.

Narine Brsikyan: Das heißt aber dann, dann muss man eben, wenn man diese Fehlermeldung hat oder eben ein falsches Sachbuchkonto, muss man wieder neu machen oder wie funktioniert das dann?

Peter Echter: Also letztendlich ist es dann so, die Finanzabteilung sollte eigentlich die Einkaufsabteilung informieren: „Ich beziehe mich auf die Bestellung XYZ. Kannst du einmal schauen? Hätte eigentlich auf DEM Sachbuchkonto landen müssen, die Verbuchung, ist aber dort nicht angekommen, sondern ist ganz seltsamerweise auf ein ganz seltsames Konto gegangen“, ja? Und das heißt, die beiden müssen miteinander reden und müssen das dann nachvollziehen. Und einer von den beiden muss dann irgendwie ein Mapping, also ein Feldschlüssel-Mapping, ändern, weil meist ist hier der Fehler oder das Feldschlüssel-Mapping war für diese Konstellation nicht vollständig. Und einfach gemeinsam darauf schauen, gemeinsam miteinander reden, gemeinsam sozusagen die Fehlerstrecke verfolgen und das Mapping einfach umstellen. Und dann sollte es für das nächste Mal funktionieren. Gut, dann bleiben wir auch gleich bei der Finanzabteilung. Bei der Finanzabteilung ist es auch des Öfteren der Fall, dass für aperiodische Tätigkeiten. Jetzt wirst du gleich fragen, was sind denn aperiodische Tätigkeiten?

Narine Brsikyan: Ja, genau. Was sind denn aperiodische Testfälle? Das wäre vielleicht die Zuhörerinnen und Zuhörer unter uns und unter anderem mir ist das nicht ganz klar. Das kannst du vielleicht einmal beschreiben.

Peter Echter: Ja. Gut, wenn du, sage ich einmal, ein Debitorenbuchhalter bist in der Finanzabteilung oder ein Kreditorenbuchhalter, dann hast du meistens auch mit Hauptbuchhaltern zu tun. Und die Hauptbuchhalter, die haben die Aufgabe, den Blick auf das große Ganze zu richten, und die sind dann auch in der Pflicht, sage ich, für die Firma, einen Monatsabschluss, einen Quartalsabschluss oder einen Jahresabschluss für das Finanz-Reporting zu machen. Letztendlich für das Finanz-Reporting interessiert sich immer das Finanzamt, also das Steuerwesen, und unter anderem, ja, Jahresabschlüsse sind auch durch Wirtschaftsprüfer freizuzeichnen und sind auch, ja, eben die Grundlage für die Bilanzen, die man einmal jährlich erstellen muss. Das heißt, es gibt einfach Tätigkeiten, die man auch in Testfälle verpacken muss für die Testmigration. Das heißt, man probiert dann auch einen Monatsabschluss aperiodisch im Testsystem zu erstellen, genauso wie einen Quartalsabschluss oder einen Jahresabschluss. Und wenn man für diese aperiodischen Tätigkeiten keine Testfälle hat, dann testet man das ja auch nicht, ja? Und die böse Überraschung kommt vielleicht ein Vierteljahr nach der Produktionsaufnahme. Wenn man das bis dahin nicht getestet hat, dann kann das eine ganz böse Überraschung geben dann in der Produktion. Macht natürlich keiner. Spätestens bei weiteren Testmigrationen fällt das auf, dass man keine aperiodischen Testfälle hat. Aber je früher man das berücksichtigt, also gleich bei der ersten Testmigration, desto besser ist es. Man hat ja dadurch länger Zeit, sozusagen jene fehlerfrei herzustellen. Gut, ja, was hat die Fachabteilung dann oft noch an Problemen? Dass man vielleicht auf Druck eines Auftraggebers oder eines Steuerungsgremiums den Projektplan zusammenstreichen muss, weil man in Verzug geraten ist. Da wird ja dann auch ganz gern mit der Gießkanne alles gekürzt. Das heißt, wenn ich für das Testen und Bugfixing und wieder Testen nicht mindestens drei Wochen Zeit habe, dann wird es äußerst schwierig, das in der kurzen Zeit zu leisten. Beim Testen sind ja oft zwanzig bis vierzig Keyuser aus den unterschiedlichsten Abteilungen beteiligt bei einem SAP-S/4-System und man kann sich ja durchaus vorstellen, dass vielleicht der eine Keyuser oder der andere Keyuser krankheitsbedingt vielleicht nicht immer verfügbar ist oder anderweitig nicht verfügbar ist. Das bedeutet, der Testfall bleibt einfach so lange liegen, wird nicht bearbeitet, weil meistens kein Zweiter da ist, der die gleiche Expertise und die gleichen Erfahrungen aufweist wie derjenige, der jetzt gerade schmerzhaft fehlt. Ja, weitere Probleme, mit denen Fachabteilungen kämpfen, ja, durch hohen Arbeitsanfall. Auf dem Papier sind sie freigestellt für das Projekt, aber nichtsdestotrotz kommt deren Chef oder deren Chefin immer wieder einmal mit einer Sonderaufgabe, die zeitlich unbedingt gleich gemacht werden muss, und man schiebt dann das Testen immer weiter in die Zukunft und geht das Testen dann anhand der Planzeitphase ziemlich am Schluss an und hat dadurch natürlich viel Stress und hat hohen zeitlichen Druck. Und die Qualität des Testens bleibt dann manchmal auf der Strecke.

Narine Brsikyan: Ja, was wäre da dazu die optimale Lösung? Oder hättest du da aus der Erfahrung heraus einen Tipp, wie man das eben, ja, einfach besser lösen könnte?

Peter Echter: Ja, also ganz wichtig ist, wir werden uns später auch noch den Testmanager anschauen oder den Teilprojektleiter, dass der eine vertrauensvolle Basis zu seinen Testern aufbaut und auch den Testern ganz klar sagt: „Wenn ihr sozusagen immer wieder Linieneinschläge habt, die euch vom Testen abhaltet, gebt mir so schnell wie möglich Bescheid.“ Und dann wird hier das Projekt auf das Linienmanagement einwirken, dass so etwas nicht noch einmal vorkommt und es wird auch dann den Abteilungsleitern erklärt, wie wichtig eigentlich jetzt die Testphase ist und dass auch die ganzen Fachabteilungen später davon profitieren werden, weil jeder unentdeckte Fehler, der sozusagen im System beim Going-Live mit drinnen ist, der wird hier ganz hohe Aufwände in der Produktion dann nach dem Projekt erzeugen. Das heißt, die Zeit, die man jetzt im Vorfeld investiert, das ist eine gut investierte Zeit und im besten Fall und in den meisten Fällen ist es ja dann auch so, wenn ausreichend getestet wird, dass man nahezu mit einem fehlerfreien System live geht und dadurch das nicht vorkommt. Gut, weitere Probleme, die hier Fachabteilungen haben, insbesondere bei großen Organisationen, die hier in der Aufbau- und Ablauforganisation sehr groß aufgestellt sind und sehr tief verschachtelt sind / Das heißt, jeder hat hier in solchen Organisationen zwar einen tiefen Blick in seinem kleinen Spezialgebiet, aber das Übergreifende fehlt einfach. Und das Übergreifende sich anzueignen oder mit den Kolleginnen und Kollegen zu sprechen dann, das ist ein wesentlicher Faktor, weil, wenn wir uns zum Beispiel eine Bestellung anschauen, letztendlich bei dem Beispiel zu bleiben, was wir vorhin hatten, wenn das auf dem falschen Sachbuchkonto landet, dann muss auf jeden Fall, sage ich einmal, der Einkäufer für diesen Service mit dem Debitoren- und Kreditorenbuchhalter reden, ja, und sich miteinander abstimmen, wie konnte es dazu kommen, dass eben ein falsches Sachbuchkonto da in der Testbestellung da verbucht worden ist? Das heißt, auch die Tester untereinander müssen einen hohen Kommunikationsaufwand betreiben. Und wie es oft ist im Leben, mit manchen versteht man sich sehr gut und mit anderen nicht ganz so gut, ja? Und mit anderen, da kommt das Menschliche wieder zum Tragen, wo man sich nicht so gut versteht, redet man ja leider nicht so gern, ja? Gut, das ist aber dann, wir kommen später darauf, hier auch eine Aufgabe des Testmanagers, das zu erkennen und da einfach dagegenzusteuern, ja? Da ist es manchmal dann einfacher, in kleinen Gruppen miteinander zu sprechen als bilatertal eins zu eins. Gut, und eine weitere Hürde, die wir haben in den Testmigrationen, wie gesagt, das sind ja Projektsysteme und keine produktiven Systeme, und dadurch kann man es einfach aus zeitlichen und Kostengründen gar nicht schaffen, dann alle technischen Umsysteme, sogenannte Systeme, die entweder von dem SAP-System Daten empfangen, die verarbeitet worden sind, oder an das Hauptsystem auch Daten liefern, das das Hauptsystem zum Buchen braucht. Da gibt es teilweise über zweihundert technische Systemschnittstellen in mittleren Sub-ERP-Systemen, egal R3 oder S4, die eben daran beteiligt sind als Datenlieferant oder Datenempfänger. Wenn die natürlich in den Projektsystemen nicht angebunden sind, dann können ja die Daten nicht zugeliefert werden oder das Sub-System kann die Daten nicht an das empfangende System weitergeben. Das heißt, ich muss bei der Testfallbeschreibung schon wissen, okay, welche technischen Schnittstellen habe ich denn im Projektsystem angebunden? Und wenn ich weiß, okay, diese Systemschnittstelle ist nicht da, dann hat das Auswirkungen eben auf einen Testfall. Um das besser verständlich zu machen, machen wir auch ein Beispiel. Meistens ist es so, dass hier, ja, in unserem Fall bei der cp, wir reisen viel, dass hier über Sub-Concours sozusagen die Reisen gebucht werden, und in großen Organisationen ist eben dann das Sub-Concours-System mit dem Finanzsystem verbunden und die Abrechnungen und Verbuchungen der Reisemittel erfolgt dann direkt im SAP-System. Wenn ich das im Projektsystem nicht angebunden habe, dann kann ich ja auch nicht mit den Daten rechnen, wo eben dann zum Beispiel Mitarbeiter, die Reisen gebucht haben, mir letztendlich die Buchungsdaten wieder zurückgespiegelt bekommen, ja? Funktioniert einfach nicht. Schnittstelle fehlt. Daten fehlen auch, und das kann ich auch im Testfall beschreiben.

Narine Brsikyan: Okay. Ja, das war jetzt ein super Überblick. Vielleicht hättest du ja noch die zwei weiteren Akteure, die du kurz einmal beschreiben möchtest?

Peter Echter: Okay, gern mache ich das. Letztendlich wird es nicht ganz so ausführlich werden, wie jetzt zu den Fachabteilungen. Wen haben wir ja denn noch als Akteure? Lasse uns zuerst einmal auf die Datenmigrateure, also auf die technischen Umsetzer, schauen. Aus deren Sicht können die nur gemeldete Fehler beheben, weil von den weiteren Fehlern, die ja sozusagen im Testfall dann nicht dokumentiert sind, wissen sie nichts. Es ist eine triviale Weisheit, aber letztendlich ist es des Öfteren die Erfahrung gewesen, dass eine Fachabteilung sozusagen einen Fehler hineinschreibt, aber dann erwartet, dass im Testfall vier Fehler behoben werden, ja? Das können die Datenmigrateure nicht, weil sie wissen ja von den restlichen drei Fehlern nichts. Dann die technischen Umsetzer versuchen ja dann aufgrund der Fehler gleich mit dem Bugfixing anzufangen. Je später sie dann in der zeitlichen Phase sozusagen von den Fehlern Kenntnis erhalten, desto später können Sie auch mit dem Bugfixing anfangen. Da sind wir wieder bei dem Thema, sozusagen eine Abhängigkeit, wenn hier ein Tester sehr spät mit dem Test anfängt, das schlägt sich dann im Bugfixing bei den Migrateuren wieder nieder. Dann des Öfteren ist es ja auch so, es sind ja auch neben vielen Fachabteilungen viele technische Umsetzer im Projekt beteiligt. Und es gibt Personen, die kommunizieren hervorragend und sind extrovertiert. Und dann gibt es eben Personen, die sind sehr introvertiert. Letztendlich muss der Testmanager auch darauf schauen und auch sich die Mimik immer wieder ansehen der technischen Umsetzer, weil manchmal sind eben dann Umsetzer dabei, die trauen sich nicht zu fragen, wenn sie irgendetwas nicht verstanden haben. In erster Linie sollten sie immer den Testmanager fragen, aber nichtsdestotrotz auch keine Scheu zu haben, auf den Keyuser in der Fachabteilung zugehen und sagen: „Sie haben das so und so beschrieben, ich verstehe es einfach nicht. Wo ist denn der Fehler? Können Sie mir das zeigen?“ Das hilft dann oft beiden dann, ja? Aber setzt dann natürlich auch voraus, dass Migrateure nicht so platt ist, einfach nachzufragen und nicht einfach etwas selbst zu interpretieren. Selbst zu interpretieren ist die schlechteste Lösung. Geht eigentlich immer schief. Gut, wo dann Migrateure des Öfteren auch zu kämpfen haben, sie sind dann ganz stolz im Bugfixing, haben während der Testphase sogar den Bug gefixt, möchten dann natürlich auch wissen, wie sieht es in dem Testfall aus. Besteht der Fehler noch oder besteht der Fehler nicht? Und wenn dann in der Fachabteilung gesagt wird: „Hm, ich habe jetzt überhaupt keine Zeit zum Re-Test. Also danke für das Bugfixing, aber ich werde einfach jetzt nicht testen, weil ich keine Zeit habe“, oder aus irgendwelchen anderen Gründen, dann demotiviert das natürlich den technischen Umsetzer, den Migrateur, ja? Und was bei den Migrateuren ja auch wichtig ist, ist eigentlich auf der Kommunikationsseite. Die Fachabteilungen können nicht die Schwere des Fehlers einschätzen. Das heißt, wenn ich für das Bugfixing innerhalb des Planzeitraums von zwei, drei Wochen nicht fertig werde, diesen Fehler zu fixen, weil es ganz viele Abhängigkeiten hat, das heißt, ich muss ganz, ganz viel sozusagen an verschiedenen Stellschrauben mit dem Fehler dann beheben, ja, dann brauche ich eine valide Zeitschätzung des technischen Umsetzers und muss auch letztendlich vom technischen Umsetzer, also vom Migrateur, hier ganz klar die Rückmeldung haben, wir schaffen das während der ersten Testmigration nicht. Aber der Umsetzer muss dann auch ganz zuverlässig einen Folgetermin mitteilen, wie es denn aussieht, ab wann dann der Fehler gefixt ist. Gut, das war hier so ein kleiner Streifzug, zwar nicht so ausführlich wie bei den Fachabteilungen, aus der Sicht der Migrateure oder der technischen Umsetzer, auf was man da schauen muss. Und ich würde vorschlagen, letztendlich schauen wir uns noch den Testmanager an, mit welchen Herausforderungen der Testmanager kämpft und auch letztendlich, sage ich einmal, was an Erwartungen an ihn geknüpft sind.

Narine Brsikyan: Noch einmal die Rückfrage, wie eng die Zusammenarbeit mit den Fachabteilungen und mit dem Testmanager ist.

Peter Echter: Die Fachabteilungen arbeiten eng mit dem Testmanager zusammen, und der Testmanager arbeitet auch eng mit den technischen Umsetzern zusammen. Also der hat hier eine Steuerungs- und Bindegliedfunktion und wird letztendlich dann auch die Testfälle im Gesamten verwalten, das zusammen in einem Testplan zusammenfassen, und macht gegenüber der Projektleitung auch das Test-Voll-Reporting, sodass die Auftraggeber und die Projektleitung auch weiß, wo stehen wir denn gerade beim Testen. Und wie viele Fehler haben wir denn? Wie viele schwere Fehler haben wir? Wie viele mittlere Fehler haben wir? Und wie viele leichte Fehler haben wir? Und letztendlich auch eine zeitliche Roadmap der Geschäftsführung dann immer wieder zu aktualisieren, wann sind denn welche Fehler behoben. Das ist das, was sehr von Interesse ist aller. Gut, aber in welcher Situation finden wir oft das Testmanagement in Projekten und dann davon abhängig natürlich, was sind eigentlich die Herausforderungen für so einen Testmanager? Oft ist es so in den Projekten, dass hier die Gesamtprojektleiter und dessen Aktivitäten und Aufgaben ein wenig unterschätzt und dadurch es oft so ist, dass in der zeitlichen Projektplanung der Auftrag des Testmanagers zu spät eingeplant wird. Wenn das der Fall ist, dann kommt der Testmanager ganz schön ins Schwimmen, weil als einer seiner ersten Aufgaben ist es, sozusagen die Fachexperten aus den Fachabteilungen zu identifizieren und diese onzuboarden, ebenfalls dann zum Migrationsteam, also der technischen Umsetzung, den Datenmigrateuren, hier eine gute Beziehung aufzubauen. Er muss ja letztendlich auch den Testplan erstellen. Der Testplan besteht aus ganz vielen Testfällen zusammengefasst. Das ist ja auch eine Aufgabe, die er sehr schnell angehen muss. Und er sollte auch ein guter Kommunikator sein, um hier sozusagen alle Beteiligten immer wieder einzufangen und auch eine Transparenz unter allen Testern aus den Fachabteilungen herzustellen. Dadurch ist hier einerseits eine Methode der daily Stand-Ups aus der agilen Projektwelt sehr hilfreich. Andererseits muss er auch in der Lage sein, oder muss sie auch in der Lage sein, dann dementsprechend, was wir vorhin kurz angesprochen haben, zu erkennen, wer ist ein introvertiert, wer ist ein extrovertierter technischer Datenumsetzer und da sich um diese quasi speziellen introvertierten Kandidaten sich bemühen und immer wieder diese Einzelgespräche zu den introvertierten Kandidaten zu finden nach dem Motto, hast du verstanden, was die Fachabteilung will? Hast du dieses, hast du jenes und so weiter und so fort, weil von sich aus introvertierte Projektmitarbeiter ja nicht ganz so viel von sich preisgeben und am liebsten in Ruhe dahinarbeiten, ja? Gut, letztendlich ist hier ein guter Testmanager immer derjenige, der sehr viel fragt, der sehr viel kommuniziert und der sehr viel festhält, einerseits über die Fachabteilungen, andererseits auch über die Datenmigrateure. Und er muss trefflich verstehen, sage ich einmal, in der Geschäftssprache der Fachabteilungen mit den Fachabteilungen zu sprechen und in der technischen Sprache mit den technischen Umsetzern zu sprechen. Das wäre jetzt, sage ich einmal, eine Kurzbeschreibung für einen idealen Testmanager oder eine ideale Testmanagerin in einem Projekt. An die Projektleiter, bitte einfach möglichst frühzeitig einen Testmanager an Bord zu holen und hier ausreichend Zeit auch für das Testen eben in der Planung als auch in der Durchführung zu gewähren.

Narine Brsikyan: Ja, Dankeschön. Und du hast uns wirklich einen sehr guten Überblick über die unterschiedlichen, wichtigen Faktoren, die innerhalb einer Datenmigration wichtig sind, gegeben und ich hoffe, das ist einigen Zuhörerinnen und Zuhörern klarer geworden. Ja, und vielleicht können wir zum Abschluss, ja, eine Art Resümee ziehen, was die wichtigsten Punkte sind, um erfolgreich die Datenmigration dann durchzuführen.

Peter Echter: Das mache ich gern. Das ist ja auch ein Anliegen von mir, dass man hier einfach den Blick schärft. Gut, als Resümee, über was wir heute gesprochen haben, könnten wir eigentlich ziehen Punkt 1, auf jeden Fall im Projekt das Testen erst nehmen und nicht auf die leichte Schulter nehmen. Das kann man auch den Fachabteilungen gleich von Anfang an kommunizieren. Ja, aus der Sicht des Projektleiters, ja, zusammen mit dem Auftraggeber, einfach die Testvorbereitungen und die zeitliche Testplanung möglichst frühzeitig anfangen zu lassen. Man kann viel im Vorfeld vorbereiten. Man sollte, wenn man hier die Kräfte hat, auch das möglichst frühzeitig anfangen. Dann, ganz wichtig, da kommt eigentlich der Auftraggeber immer wieder in den Vordergrund, ist, dass er in seine Fachabteilungen eben trägt, dass das Testen unheimlich wichtig ist. Es ist keine Pflicht. Und das, was wir kurz vorher angesprochen haben, jeder unentdeckte Fehler nach dem Going-Live, das ist eigentlich fast dann nur noch mit Blut, Schweiß und Tränen zu korrigieren, und diesen harten Weg sollte man sich einfach ersparen. Das muss auch beim Auftraggeber durchdringen. Dann, was ganz wichtig auch ist, man spricht immer dahin vom Testen. Beim Testen werden ja auch viele Fehler gefunden. Jeder Fehler heißt auch, dass der Fehler gefixt werden muss. Und genau hierfür ist auch in der Projektplanung ein Mehraufwand da einfach mit einzuplanen, dass es nicht bloß die Testmigrationen in dem Zeitraum selbst gibt und nach diesen Zeiträumen geht ja das Bugfixing weiter. Und das ist ein Mehraufwand, der muss einfach mit eingeplant werden. Gut, dann hatten wir ja ganz kurz angesprochen auch, dass hier des Öfteren in Projekten es so ist, dass man in den Verzug kommt und natürlich gern mit der Gießkanne einfach alle Phasen ein wenig, ja, kürzt. Und da sollte man beim Testen die Finger davon lassen, ja? Eine ganz große Empfehlung, weil, wenn man hier Zeiten einkürzt, das heißt letztendlich, man testet viel weniger. Man testet auch einige Sachen nicht. Und wie gerade eben erwähnt, jeder unentdeckte Fehler beim Going-Live tut doppelt und dreifach weh, deswegen hier zeitliches Kürzen da, wo es sinnvoll ist, aber nicht bei den Testphasen. Ja, das wäre jetzt meine Zusammenfassung aus den letzten Jahren der Migrationsprojekte, in denen ich dann eben beteiligt war oder diese selbst geleitet habe.

Narine Brsikyan: Peter, vielen Dank, dass du dein langjähriges Wissen mit uns geteilt hast, und ich hoffe wirklich, ja, dass viele Zuhörerinnen und Zuhörer sich eben einige Schlüsse daraus ziehen können, vielleicht etwas mitnehmen können. Ansonsten kann man dich ja auch ansprechen, ne? Du bist ja auch auf LinkedIn zu finden. Auf jeden Fall vielen herzlichen Dank und, ja, auf bis bald.

Peter Echter: Narine, es war mir eine Freude. Gern kann ich kontaktiert werden. Peter Echter. Man findet mich im Addressbook Outlook. Man findet meine Telefonnummer, einfach durchklingeln oder mir eine Mail schicken und ich helfe gern.

Narine Brsikyan: Ja, super. Dankeschön.

Peter Echter: Dann vielen Dank. Dann bis zum nächsten Mal.

Narine Brsikyan: Ja, danke. Tschüss.