Tests in ERP-Projekten

Eines der wichtigsten Themen im Rahmen der Implementierung eines ERP-Systems ist ohne Zweifel das Testen. Nicht nur, weil es für jedes Unternehmen unerlässlich ist, die neue Software vor der Inbetriebnahme auf Herz und Nieren zu prüfen, sondern auch, weil es das Potenzial hat, während der Implementierungsphase unnötig Zeit der Keyuser zu verschwenden.

Falls Sie den Artikel zur Geschäftsprozessanalyse bisher nicht gelesen haben, ergibt es Sinn, dies nun zu tun, da in diesem Artikel an einigen Stellen auf ebendiese verwiesen wird.

Die unterschiedlichen „Arten“ von Tests

Funktionstest

Synonyme: Einzelfunktionstest, Unit-Test

Funktionstests sind die Tests, welche üblicherweise zuerst vom Projektteam oder den Keyusern eines ERP-Projekts „eingefordert“ werden. Hierbei geht es, wie der Name schon sagt, darum, dass bestimmte einzelne Funktionen und Abläufe des ERP-Systems separat voneinander getestet werden. Meistens sind sie dadurch gekennzeichnet, dass ein Keyuser einen Funktionstest aufgrund des geringen Umfangs allein durchführen kann. Von dieser Regel gibt es aber natürlich auch Ausnahmen, wie z. B.

• Die Anlage von Debitoren, bei der unterschiedliche Abteilungen workflowgesteuert nacheinander die entsprechenden Informationen für einen Debitor einrichten.
• Eine Individualanpassung des Anbieters, die umfangreich ist und für die Tests nicht weiter aufgesplittet werden kann

Klassischerweise geht es aber um klar abgegrenzte Bereiche, wie z. B.

• Die Ermittlung eines Liefertermins in einem gegebenen Szenario
• Die Überprüfung eines bestimmten Dispositionsergebnisses
• Die korrekte Ausführung der Kreditlimitprüfung

Die gewählten Beispiele haben alle die Gemeinsamkeit, dass ein User allein sich entsprechende Beispiele aufbauen kann (wenn auch in der Dispo die Beispiele etwas komplexer sein dürften) und es am Ende des Tests eigentlich nur zwei Möglichkeiten gibt. Entweder die getestete Funktion entspricht den Anforderungen oder eben nicht. Ein „geht so einigermaßen“ gibt es auf dieser Ebene relativ selten.

Prozesstest

Synonyme: Bereichsübergreifende Tests, Ablauftests

An der Stelle werden die Tests schon umfangreicher. Es geht darum sicherzustellen, dass aus einer Reihe erfolgreich getesteter Funktionen auch wirklich funktionierende, den Anforderungen entsprechende, Prozesse werden. Die Prozesstests sind eine Vorstufe der Geschäftsprozesstests und verlaufen normalerweise anhand des gleichen Schemas. Anhand der Geschäftsprozessliste wird ermittelt, welche Funktionsblöcke sich bereits zum Testen eignen und die jeweils verantwortlichen Keyuser spielen die Prozesse gemeinsam durch. Diese Tests sollten bereits durch realistische Stammdaten unterstützt werden, um sicherzustellen, dass die Testergebnisse valide sind und das Fehlen ebendieser Daten nicht zu großer Verunsicherung bei den Keyusern führt.

Für Ihren Projektleiter ist es in dieser Phase wichtig, die Keyuser dazu zu bringen, diese Art von Tests möglichst selbstständig durchzuführen. Es besteht immer die Gefahr, dass Keyuser bei einnehmendem Tagesgeschäft dazu tendieren, nur auf „Aufforderung“ die Tests weiter voranzubringen. Was wir als Projektleiter aber möchten, ist ja, dass die Keyuser diese Arten von Tests selbstständig angehen und Ergebnisse produzieren.

Beispiel für Prozesstests:

Wichtig ist neben der Ermittlung von sinnvollen Funktionsblöcken auch, dass die Keyuser sich genau überlegen, mit welchen Beispieldaten die Prozesse im ERP-System getestet werden müssen. Gerade bei der Einführung eines ERP-Systems passiert es in der Praxis zu oft, dass bestimmte Prozesse immer mit den gleichen Debitoren und Artikeln durchgetestet werden. Später stellt sich dann heraus, dass andere Konstellationen im System nicht funktionieren, wenn z. B. Themen wie die Chargenverfolgung oder der Export unbewusst außen vor gelassen wurden.

Geschäftsprozesstest

Synonyme: End-to-End Tests; Komplettprozesstests

Geschäftsprozesstests sind „eigentlich“ nichts anderes als Prozesstests, nur dass hier die Geschäftsprozesse von Anfang bis Ende (End-to-End) durchgetestet werden. Dabei wird für jeden Prozessschritt dokumentiert, mit welchen Daten getestet wurde und wie das entsprechende Ergebnis für diesen Prozessschritt ist. Ziel ist es, im Laufe der Tests alle Geschäftsprozesse mit unterschiedlichen Beispieldaten durchzuführen, sodass diese am Ende als erfolgreich durchgeführt angesehen werden. Gerade bei der Einführung einer ERP-Software ist es entscheidend, dass der Projektleiter Ihres Unternehmens darauf achtet, dass die Beispiele nicht zu einfach gewählt werden. Es hilft nichts, alle Tests immer nur mit einer Auftragsposition durchzuführen oder dem 08/15 Artikel, welcher ohnehin nie Probleme verursacht und immer in ausreichender Menge am Lager ist. Ich mache es meist so, dass ich zuerst versuche, das Projektteam und die Keyuser dahingehend zu motivieren, die Geschäftsprozesse selbstständig mit unterschiedlichen Beispielen zu testen.

Wenn ich merke, dass dies ungenügend oder mit zu einfachen Beispielen passiert (das merkt man normalerweise recht früh), forciere ich die Erstellung von Testszenarien für die Geschäftsprozesse, die sich aus den Anforderungen des Lastenhefts ableiten lassen. Das bedeutet konkret, dass die Keyuser für jeden Geschäftsprozess mehrere Fälle mit unterschiedlichen Datenkonstellationen erarbeiten, die alle später im Rahmen der Tests erfolgreich abgehakt werden müssen. Dies hat den Vorteil, dass sich das Projektteam im Vorfeld gezielt Gedanken darüber macht, welche unterschiedlichen Szenarien eines Geschäftsprozesses in der Realität vorkommen könnten und wie die implementierte Lösung darauf reagieren muss. Wie immer gibt es keinen „free Lunch“.

Der Nachteil der Testszenarien zu diesem Zeitpunkt ist in meinen Augen, dass es die Keyuser dazu verleiten kann, bei der Durchführung der Tests unkreativ zu sein und sich zu strikt an die Drehbücher zu halten. Ein weiterer Nachteil ist sicherlich der zusätzliche Aufwand, den Projektleitung und Keyuser während der Implementierung dadurch haben. Die Szenarien müssen erarbeitet, dokumentiert und entsprechend zu den Geschäftsprozessen abgelegt werden. Danach müssen sie innerhalb der Tests einzeln durchgespielt und wiederum dokumentiert werden. Trotzdem ist dieser Aufwand in jedem Falle zu betreiben, wenn man das Gefühl hat, dass die Tests ansonsten nicht mit der erforderlichen Detailtiefe und Sorgfalt durchgeführt werden.

Integrationstest

Synonyme: Systemtest, Echtstartest

Jetzt wird es spannend. Es wird „Echtstart gespielt“. Dazu ist es notwendig, dass das ERP-Projekt zu einem großen Teil fertig ist. Beispiele:

• Alle Prozesse sind besprochen, dokumentiert und im System eingerichtet sowie getestet
• Alle notwendigen Erweiterungen sind spezifiziert, entwickelt, eingerichtet und getestet
• Alle Reports (Ausdrucke, Auswertungen) wurden erstellt und getestet
• Alle Datenübernahmen wurden entwickelt und verifiziert
• Die Infrastruktur ist fertig eingerichtet, inkl. Drucker, Scanner und sonstigen Geräten
• Einige Enduser wurden bereits geschult und werden mit in das Projekt integriert (dies dient dazu neue Sichtweisen zu bekommen)
• Rollen und Rechte sind nahezu final eingerichtet
• Schnittstellen wurden programmiert und eingerichtet

In der Praxis läuft die Vorbereitung für einen Integrationstest folgendermaßen ab:

1. Die aktuelle GP-Liste wird kopiert und die Statusinformationen aller Prozessschritte werden gelöscht (man beginnt von vorn)
2. Es wird eine neue Datenbank erstellt, bzw. eine existierende Datenbank wird so bearbeitet, wie es auch vor dem Echtstart passieren wird
3. Alle für das Echtsystem relevanten Einrichtungen werden in die Datenbank übernommen
4. Alle Datenübernahmen werden durchgeführt
5. Für den Fall, dass Bewegungsdaten nicht migriert werden (offene Aufträge, Bestellungen, Fertigungsaufträge etc.), werden einige, vorher ausgewählte, Belege aus dem Echtsystem manuell in die neue Datenbank übertragen
6. Die Datenbank wird geprüft und für den Integrationstest freigegeben

Integrationstests (ich plane mit mindestens zwei) müssen frühzeitig für alle Beteiligten im Rahmen der ERP-Einführung fest eingeplant werden. Während die vorhergehenden Tests in den meisten Fällen durch die Keyuser selbst organisiert werden können, geht es jetzt darum, dass das Testmanagement sicherstellt, dass die Integrationstests sehr effizient durchgeführt werden. Im Durchschnitt plane ich einen Test über drei Tage, wobei die oben aufgelisteten Vorbereitungen dann bereits abgeschlossen sind und nicht mitgerechnet werden.

Es muss dafür gesorgt werden, dass die relevanten Mitarbeiter Zeit haben, dass der Anbieter die notwendige Unterstützung vor Ort an den Tagen leisten kann und etwaige weitere Dienstleister (z. B. Logistikexperten eines externen Lagerverwaltungssystems) ebenfalls, sofern notwendig, eingeplant sind. Des Weiteren dürfen auch Details wie Räumlichkeiten, technische Ausstattung und Ressourcen für die Tests der ERP-Lösung nicht vernachlässigt werden. Bei der Planung der benötigten Keyuser muss entschieden werden, ob alle Mitarbeiter immerzu am Test teilnehmen oder ob es da zeitliche Unterschiede gibt. Oftmals ist es z. B. so, dass die Benutzer aus dem Bereich Finanzbuchhaltung erst gegen Ende des Tests benötigt werden, wohingegen die Mitarbeiter aus dem Bereich Verkauf vorwiegend am Anfang ihre Daten erfassen und ihre Prozesse testen. Ich versuche eigentlich immer, dass alle Keyuser kontinuierlich an den Tests teilnehmen, und nur wenn es unbedingt notwendig ist, plane ich in einzelnen Zeitslots, um die verfügbaren Ressourcen optimal zu nutzen.

Etwas Anderes ist da die Unterstützung bereits geschulter Enduser. Diese werden meist zu bestimmten Zeiten dazugebeten, z. B. werden zusätzliche Anwender aus dem Bereich Verkauf am Anfang des Tests eingebunden, wenn eine Vielzahl von Angeboten und Aufträgen erfasst wird.

Ablauf eines Integrationstests:

1. Kurzes Testkickoff. Die Vorgehensweise wird erläutert und organisatorisches wird geklärt
2. Verteilung der Testaufgaben (die Geschäftsprozesse) an die einzelnen Benutzer-(gruppen). Hierbei arbeite ich gerne so, dass die einzelnen Geschäftsprozesse ausgedruckt und in Mappen geheftet werden. Diese Mappen werden dann verteilt. Dieses einfache Detail sorgt dafür, dass man durch die Mappen immer den Überblick behält.
3. Die Keyuser starten mit den ersten Prozessschritten und dokumentieren die Ergebnisse in den Mappen
4. Der Projektleiter aktualisiert periodisch die elektronische Version der Geschäftsprozessliste (in diesem Falle unser Testdrehbuch) und stellt sie zentral für jeden zur Verfügung
5. Sobald ein Keyuser in seinem aktuellen Testfall die ihm zugewiesenen Prozessschritte durchgeführt hat, gibt er die Mappe an den nächsten zuständigen Keyuser weiter.
6. Am Ende eines Testtages werden die Mappen eingesammelt und die Ergebnisse noch einmal zentral gesammelt. Die zentrale Datei wird aktualisiert. Das zeitliche Ende für die Keyuser sollte so gewählt werden, dass im Anschluss noch Zeit ist, das Ergebnis zwischen Projektleitung und Anbieter zu diskutieren und ggf. Anpassungen für den Plan des nächsten Tages vorzunehmen.
7. Am nächsten Tag nimmt sich jeder Keyuser wieder die Mappen, die er am Vortag hatte.
8. Zum Ende des letzten Tages wird eine Feedbackrunde durchgeführt (man kann dies natürlich auch jeden Tag durchführen). Jeder äußert sich über den Erfolg des Tests und benennt die aus seiner Sicht wichtigsten Punkte.
9. Am Ende ist es wichtig, alle Listen auf den aktuellen Stand zu bringen, sodass mit ihnen weitergearbeitet werden kann. Wenn die Tests nicht beendet wurden, können mithilfe der Geschäftsprozessliste weitere Tests geplant werden, um alle Prozesse abzuschließen. Die Liste mit offenen Punkten wird mit den problematischen Prozessschritten gefüllt. Dies sind die Punkte, die bis zum nächsten Test, oder aber dem Echtstart, abgearbeitet werden müssen.

Nach dem Test ist es die Aufgabe des Projektleiters, den Test insgesamt zusammen mit dem Anbieter zu bewerten und diese Bewertung dem Lenkungsausschuss mitzuteilen. Natürlich ist das Ergebnis auch Thema in der nächsten Lenkungsausschusssitzung.

Noch einige kurze Anmerkungen.

1. Wenn es räumlich möglich ist, versammeln sich in meinen Projekten alle Teilnehmer am Integrationstest in einem Raum. Ich halte sehr wenig davon, dass die Keyuser aufgeteilt werden, oder noch schlimmer, die Tests vom eigenem Arbeitsplatz aus durchführen.
2. Auch wenn es mit Kosten verbunden ist, würde ich die Berater des Anbieters den notwendigen Support vor Ort leisten lassen. Berater, die nicht ganz so tief im Projekt stecken, können natürlich remote dazugeholt werden.
3. Wenn möglich, würde ich dazu raten, auch für eine entsprechende Pausenverpflegung zu sorgen. Es wäre nicht der erste Integrationstests, in dem mittags beim Pausengespräch wichtige Erkenntnisse zutage treten.

Massentest

Synonyme: Performance Test

Bei diesem Test geht es darum, die Systemleistung in den unterschiedlichen Bereichen zu überprüfen und sicherzustellen, dass sie für den Echtstart und den weiteren Betrieb ausreichend ist. Letztlich ist der Ablauf relativ simpel.

1. Der Anbieter stellt eine Datenbank für den Test auf der Infrastruktur des Produktivsystems zur Verfügung
2. Falls bisher nicht vorhanden, werden entsprechende Performancediagnosetools installiert
3. Zur geplanten Startzeit fangen Anwender aus allen Bereichen an, so viele Daten wie möglich zu erfassen. Des Weiteren werden parallel die Stapelverarbeitungen ausgeführt, welche dann auch später im Echtbetrieb laufen (z. B. Dispo läuft, Kommissionierläufe, Rechnungsläufe).
4. Einige Anwender erfassen keine neuen Daten, sondern verarbeiten Daten, welche zu diesem Zwecke bereits im System angelegt wurden. Zu diesen Aufgaben gehören alle Lagerprozesse, Fertigungsbuchungen und dergleichen.

Normalerweise wird die Dauer des Tests zwischen 30 und 60 Minuten geplant. Ziel ist es in allen Bereichen etwas mehr Last zu erzeugen, als im Echtbetrieb tatsächlich zu erwarten ist.

Am Ende wird dann das Ergebnis ausgewertet. Dazu werden die einzelnen Anwender über ihre Erfahrungen befragt und die Diagnosen werden entsprechend ausgewertet. Bereiche, in denen die Performance bislang nicht zufriedenstellend war, werden in die Liste der offenen Aufgaben aufgenommen und der Anbieter wird sich mit den notwendigen Optimierungen befassen.

Eine kurze Anmerkung noch zur möglichen Automatisierung: Mittlerweile haben viele Anbieter die Möglichkeit, entsprechende Massentests zu simulieren. Ob dies einen adäquaten Ersatz für einen „manuell“ durchgeführten Massentest ist, muss sorgfältig geprüft werden. Im Zweifel würde ich immer den manuellen Test durchführen, um am Ende sicher zu sein.

Es gibt noch weitere Testarten, welche sich in der Literatur finden und die auch sicherlich im Rahmen von ERP-Projekten eine Rolle spielen. Dies wären z. B.

• User Acceptance Tests (UAT): Die Enduser testen das System darauf, ob es den Anforderungen ihrer täglichen Arbeit gerecht wird. Aus meiner Sicht findet diese Art von Test vorwiegend während der Enduserschulungen statt. Ob solche Tests noch extra geplant werden müssen, muss im Projekt entschieden werden. Man kann die Risiken, welche man mit diesen Tests begegnen will, auch reduzieren, indem man zu einem bestimmten Zeitpunkt, z. B. vor den Integrationstests, das Testteam um einige Endanwender erweitert. Diese werden vorher geschult und unterstützen dann die Tests
• Data Migration Tests: Prüfung der Datenmigration, genauer gesagt der daraus erzeugten Daten. Dies ist zwingend nach jeder Datenübernahme zu tun. Für mich haben diese Tests den Charakter eines Funktionstests, da explizit jede einzelne Funktion der Datenübernahme / der Datenmigration geprüft wird. Am Rande sei erwähnt, dass ich grundsätzlich empfehle, mit den Datenübernahmen so früh wie möglich zu beginnen, sodass echte Daten bereits früh in der Testphase zur Verfügung stehen. Damit wird sichergestellt, dass die Daten nicht nur korrekt übernommen werden, sondern dass mit ihnen dann auch entsprechend weitergearbeitet werden kann.
• Schnittstellentests / Interface-Tests: Schnittstellen und deren Prozesse sind für mich ebenfalls Funktionstests, bzw. Prozesstests. Natürlich gehört der Test von Schnittstellen ebenfalls in die Durchführung der Integrationstests.
• Backup und Recovery Tests: Ich hoffe, dies ist selbsterklärend. Vor Echtstart muss zwingend sichergestellt sein, dass sowohl Backup als auch Wiederherstellung ohne Probleme funktionieren.

Fazit zu den Teststrategien

Als Kunde sollten Sie meiner Ansicht nach schon bei der ERP-Auswahl darauf achten, dass der Anbieter eine nachvollziehbare, professionelle, Teststrategie vorweisen kann. Ausreden wie „das wird projektspezifisch geplant“ darf man an dieser Stelle auf keinen Fall gelten lassen. Natürlich ist die tatsächliche Durchführung der einzelnen Tests projektspezifisch, aber dies bedeutet nicht, dass es nicht von Anfang an einer klaren Strategie bedarf.

Fangen Sie so früh wie möglich mit den Tests an. Am besten direkt nach der ersten Schulung. Natürlich gibt es ganz am Anfang nicht so viel zu testen, aber viel wichtiger als ein dokumentiertes Ergebnis ist in dieser Phase die Arbeit der Keyuser am System. Es ist wichtig, einen Flow zu generieren, in dem die Keyuser selbstständig am System arbeiten, auch, ohne dass sie vom Projektleiter die einzelnen Testaufgaben vorgelegt bekommen. Der frühe Start der Tests soll dafür sorgen, dass der Teamgedanke, der hoffentlich von Anfang an besteht, genutzt und weiter ausgebaut wird. Aus meiner Erfahrung führt dabei die Durchführung kleiner Tests zu mehr Engagement, als der Hinweis „man solle doch nach der Schulung schon mal ein wenig am System herumspielen“.

Vermitteln Sie den Keyusern die Wichtigkeit des Testens während der ERP-Einführung. In meinen Augen muss es das Ziel fortgeschrittener Tests sein, dass die Software gezielt an ihre Grenzen gebracht wird, um Fehler frühzeitig zu identifizieren. Ich nenne dies „aktives kaputt spielen“. Als Tester versuche ich, das ERP-System so zu nutzen, dass es eben nicht funktioniert. Wichtig dabei ist nur, dass dies in einem sinnvollen Rahmen geschieht, indem ich z. B. die Daten in einer anderen Reihenfolge eingebe oder Daten verwende, die in den Testskripts nicht genannt sind.

Diese Vorgehensweise hilft Ihrem Unternehmen, Probleme aufzudecken, die sonst erst im Echtstart oder später auffallen würden. Sie ermöglicht zudem fundierte Entscheidungen über notwendige Anpassungen der Software. Je mehr Mitarbeiter während der ERP-Einführung aktiv mit dem System arbeiten, desto größer ist die Wahrscheinlichkeit, dass die Tests nicht nur streng nach Drehbuch ablaufen, sondern auch kritische Fehler identifiziert werden, die andernfalls unentdeckt bleiben könnten.