Pilotphase vor dem Softwarekauf:
echte Vorgänge vor der Unterschrift

Eine Vorführung zeigt die Abläufe, die der Anbieter vorbereitet hat

Eine Produktvorführung ist die Präsentation einer Software durch den Anbieter, meist an einem Demonstrationsbestand mit gepflegten Beispieldaten. Die gezeigten Abläufe sind ausgewählt und eingeübt. Sie belegen, dass die Software diese Abläufe beherrscht. Wie sie mit dem Bestand und den Ausnahmen eines bestimmten Betriebs umgeht, bleibt dabei offen.

Die Ausnahmen liegen im Tagesgeschäft: ein Kunde mit drei Lieferadressen und einer abweichenden Rechnungsanschrift, ein Artikel, der im Einkauf in Kartons und im Verkauf in Stück geführt wird, ein Auftrag, der in Teillieferungen abgerechnet wird. Im Demonstrationsbestand kommen solche Fälle selten vor. Im eigenen Betrieb gehören sie zum Alltag, und an ihnen zeigt sich, ob die Software die Arbeit abbildet oder ob neben ihr wieder Tabellen und Notizzettel geführt werden.

Referenzen anderer Kunden und ausgefüllte Anforderungskataloge beschreiben die Software aus der Sicht Dritter oder aus der Sicht des Herstellers. Die Pilotphase ergänzt die Sicht des eigenen Betriebs: eigene Fälle, eigene Daten, eigene Leute. Sie setzt voraus, dass die Grundsatzfrage zwischen fertigem Produkt und eigener Entwicklung geklärt ist, die Individualsoftware oder Standardsoftware an fünf Kriterien ordnet, und dass zwei oder drei Angebote in der engeren Wahl stehen.

Die Pilotphase erprobt die Software vor dem Vertragsschluss im eigenen Betrieb

Die Pilotphase vor dem Softwarekauf ist ein schriftlich vereinbarter, befristeter Probebetrieb, in dem der Betrieb eine angebotene Software unter seinen eigenen Bedingungen nutzt, bevor er sich zu Kauf oder Abonnement verpflichtet. Von einem frei zugänglichen Testzugang unterscheidet sie sich in drei Merkmalen: Sie läuft mit Daten aus dem eigenen Bestand, sie folgt einem schriftlichen Prüfplan, und an ihrem Ende steht eine dokumentierte Entscheidung.

Der Prüfplan ist das Dokument, das vor dem Start festhält, welche Vorgänge geprüft werden, wer daran arbeitet, wie lange der Versuch läuft und welches Ergebnis für einen Kauf erreicht sein muss. Seine Grundlage ist das Lastenheft, die Beschreibung dessen, was die Software im Betrieb leisten soll; der Wiki-Eintrag zum Lastenheft erklärt den Begriff, und wie es aus dem Wissen der Fachabteilung entsteht, zeigt Das Lastenheft aus dem Betrieb heraus. Ohne Lastenheft fehlt der Maßstab, und die Auswertung bleibt eine Sammlung persönlicher Eindrücke.

Das Vorgehen ähnelt einem KI-Pilotprojekt, wie es der Wiki-Eintrag zum KI-Pilotprojekt beschreibt: enger Zuschnitt, feste Laufzeit, vorab bestimmte Messgrößen. Beim Softwarekauf ist der Gegenstand ein fertiges Produkt eines fremden Herstellers, und die Entscheidung am Ende bindet den Betrieb über Jahre an Vertrag, Datenformat und Anbieter. Die Erprobung vorab verschafft ihm die Kenntnis, die er für diese Bindung braucht.

Die Testfälle stammen aus abgeschlossenen Vorgängen der letzten Monate

Ein Testfall ist ein konkreter Vorgang, den die Software im Pilot vollständig durchlaufen muss, vom auslösenden Ereignis bis zum Ergebnis: eine Anfrage bis zum Angebot, ein Auftrag bis zur Rechnung, eine Reklamation bis zur Gutschrift. Die Testfälle werden aus den Unterlagen bereits erledigter Vorgänge gezogen, weil deren richtiges Ergebnis feststeht. Der Betrieb vergleicht dann, ob die Software zum selben Preis, zur selben Steuer und zum selben Liefertermin kommt, und erspart sich die Debatte darüber, wie das Ergebnis hätte aussehen sollen.

Die Auswahl umfasst drei Gruppen. Die erste bilden die Standardfälle, die den größten Teil der täglichen Arbeit ausmachen. Die zweite bilden die bekannten Sonderfälle wie Teillieferungen, Sonderpreise, abweichende Zahlungsbedingungen, Rücksendungen und Gutschriften. Die dritte bilden die Fälle, die im heutigen System Schwierigkeiten bereiten und den Anstoß für den Wechsel gegeben haben. Wie viele Vorgänge je Gruppe durchlaufen werden, bestimmt der Betrieb nach der Vielfalt seines Geschäfts und schreibt es in den Prüfplan.

Der Anbieter erhält die Testfälle vor dem Start. Er richtet ein, was die Software für diese Fälle braucht, und der Betrieb erfährt früh, welche Fälle sich nur mit Anpassungen abbilden lassen. Jede Anpassung, die ein Testfall erfordert, kommt mit geschätztem Aufwand und Zuständigkeit auf eine Liste. Diese Liste geht später in das Angebot ein und zeigt, wie weit sich der Betrieb vom Standard des Produkts entfernt.

Ein Auszug der eigenen Stammdaten zeigt, ob das Datenmodell passt

Stammdaten sind die Grunddaten eines Betriebs, die sich selten ändern und auf die jeder Vorgang zugreift: Kunden, Lieferanten, Artikel, Preise und Konditionen. Der Wiki-Eintrag zu Stammdaten führt die Arten einzeln aus. Im Pilot arbeitet die Software mit einem Auszug aus dem eigenen Bestand, weil erst daran sichtbar wird, ob ihr Datenmodell die Struktur des Betriebs aufnehmen kann. Das Datenmodell ist die Ordnung, in der eine Software ihre Daten ablegt und verknüpft: welche Felder ein Kunde hat, wie viele Adressen und Ansprechpartner er führen kann und wie ein Preis an Artikel, Kunde und Menge gebunden wird.

Ein Auszug reicht aus, solange er die Vielfalt des Bestands enthält: Kunden mit mehreren Liefer- und Rechnungsadressen, Artikel mit Varianten und unterschiedlichen Mengeneinheiten, kundenbezogene Preise und Mengenstaffeln. Fehlt in der Software ein Feld, das der Betrieb heute pflegt, gibt es drei Auswege: Das Feld wird ergänzt, die Angabe entfällt, oder sie wandert in ein Freitextfeld, aus dem sie sich nicht mehr auswerten lässt. Welcher Ausweg gilt, wird vor dem Kauf entschieden.

Das Einspielen des Auszugs ist zugleich eine Probe der späteren Datenübernahme. Es zeigt, in welchem Format die Software Daten annimmt, welche Bereinigung vorher nötig ist und wie viel Handarbeit das Zuordnen der Felder kostet. Die vollständige Übernahme mit Probelauf und Abnahme behandelt Datenübernahme beim Systemwechsel. Gelangen personenbezogene Daten von Kunden oder Beschäftigten in die Umgebung des Anbieters, verarbeitet er sie im Auftrag des Betriebs; vor der Übertragung ist dafür ein Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO zu schließen.

Die späteren Nutzer bearbeiten die Testfälle selbst

Die Testfälle bearbeiten die Mitarbeitenden, die nach dem Kauf täglich mit der Software arbeiten: aus dem Vertriebsinnendienst, der Auftragsbearbeitung, dem Lager und der Buchhaltung. Sie kennen die Sonderfälle aus eigener Arbeit, sie bemerken zusätzliche Klicks und fehlende Tastenkürzel, und sie wissen, an welcher Stelle des Ablaufs welche Angabe gebraucht wird. Eine Geschäftsführung, die die Software in einer Präsentation sieht, bekommt diese Einzelheiten nicht zu Gesicht.

Für die Pilotphase werden die Beteiligten in einem Umfang freigestellt, den der Prüfplan nennt. Ist neben dem Tagesgeschäft keine Zeit eingeplant, bleibt der Versuch bei den einfachen Fällen stehen, weil die schwierigen Zeit kosten und genau diese Zeit fehlt. Die Freistellung ist damit eine Voraussetzung für ein aussagekräftiges Ergebnis.

Jede beteiligte Person führt ein kurzes Protokoll: welcher Testfall, was gelang, wo es stockte, wie lange es dauerte. Am Ende fragt ein einheitlicher Rückmeldebogen dieselben Punkte bei allen ab, damit sich die Rückmeldungen nebeneinanderlegen lassen. Die Schulung durch den Anbieter beschränkt sich im Pilot auf eine Einführung. Wie schnell sich die Nutzer danach allein zurechtfinden, gehört selbst zu den Befunden.

Der längste geprüfte Ablauf bestimmt die Dauer

Die Dauer einer Pilotphase ergibt sich aus dem längsten Ablauf, der geprüft werden soll. Werden Angebote und Aufträge erprobt, die in wenigen Tagen erledigt sind, genügt ein kurzer Zeitraum. Gehören Monatsabschluss, Sammelrechnung oder Mahnlauf zum Prüfumfang, muss der Pilot einen vollständigen Kalendermonat umfassen, weil diese Vorgänge erst zum Monatsende anfallen. Saisonale Spitzen lassen sich im Pilot nicht abwarten; sie werden nachgestellt, indem an einem Tag so viele Testfälle eingespielt werden, wie an einem Spitzentag eingehen.

Das Enddatum wird vor dem Start vereinbart. Eine Verlängerung ist zulässig, wenn sie begründet ist und ein neues Enddatum erhält. Ohne festes Ende geht ein Pilot schleichend in den Echtbetrieb über: Die Beteiligten gewöhnen sich an die Oberfläche, in der Software sammeln sich Daten an, und der Kauf ergibt sich aus der Gewohnheit, bevor jemand die Messwerte geprüft hat.

Fünf Messgrößen bilden das Ergebnis der Pilotphase ab

Eine Messgröße ist ein vor dem Start festgelegter Wert, an dem der Pilot gemessen wird, verbunden mit einer Schwelle, ab der das Ergebnis als erreicht zählt. Fünf Messgrößen decken die Fragen ab, die vor einem Softwarekauf offen sind.

1. Abdeckung der Testfälle: der Anteil der Testfälle, die die Software ohne Umweg außerhalb des Systems vollständig abbildet, getrennt nach Standardfällen, Sonderfällen und Problemfällen.
2. Übereinstimmung der Ergebnisse: der Anteil der Testfälle, bei denen Preis, Steuer, Summe und Termin mit dem abgeschlossenen Originalvorgang übereinstimmen.
3. Bearbeitungszeit je Testfall: die aktive Arbeitszeit der Nutzer für einen Vorgang in der neuen Software, verglichen mit demselben Vorgang im heutigen Ablauf.
4. Anpassungsbedarf: Zahl und Umfang der Änderungen, die die Testfälle erfordern, jeweils mit der Angabe, ob sie im Standard einstellbar sind oder programmiert werden müssen.
5. Urteil der Nutzer: die Auswertung des einheitlichen Rückmeldebogens, ob die Beteiligten ihre tägliche Arbeit mit der Software erledigen können und an welchen Stellen sie Hilfe brauchten.

Für jede Messgröße nennt der Prüfplan eine Schwelle, deren Höhe der Betrieb nach seinen Abläufen festlegt. Bei Preisen und Rechnungen wird Übereinstimmung in jedem Testfall verlangt, weil ein falscher Betrag unmittelbar beim Kunden ankommt. Bei der Bearbeitungszeit genügt der Nachweis, dass der neue Ablauf den heutigen nicht verlängert. Den Ausgangswert dafür erhebt der Betrieb am heutigen Ablauf.

Neben den fünf Messgrößen beobachtet der Betrieb, wie der Anbieter während des Pilots auf Fragen und Fehlermeldungen antwortet. Die Betreuung im Pilot gibt einen Vorgeschmack auf die Betreuung im laufenden Vertrag, und eine Fehlermeldung, die tagelang unbeantwortet bleibt, gehört als Befund ins Protokoll.

Abbruchkriterien stehen fest, bevor der erste Testfall läuft

Ein Abbruchkriterium ist ein Befund, bei dem die Pilotphase vor dem Enddatum endet, weil die Software für den Betrieb ausscheidet. Es wird vor dem Start festgelegt, solange die Beteiligten unbefangen urteilen. Nach einigen Wochen mit der Software fällt ein Abbruch schwerer: Zeit ist investiert, Abläufe sind eingeübt, und der Anbieter hat sich bemüht. Ein vorab vereinbartes Kriterium entlastet die Entscheidung von diesen Rücksichten.

• Ein Standardfall lässt sich nur über einen Umweg außerhalb der Software erledigen.
• Die Software berechnet Preis, Steuer oder Summe eines Testfalls falsch, und der Anbieter behebt die Ursache nicht bis zum vereinbarten Termin.
• Eine im Lastenheft als zwingend gekennzeichnete Anforderung ist nur mit einer Programmierung erfüllbar, die der Hersteller nicht als Teil des Produkts weiterpflegt.
• Die Daten lassen sich nicht vollständig und in einem offenen, dokumentierten Format aus der Software exportieren.
• Der Anbieter beantwortet Fehlermeldungen im Pilot nicht innerhalb der vereinbarten Frist.

Auch ein Abbruch liefert ein Ergebnis. Er kostet die Zeit der Pilotphase und bewahrt den Betrieb vor einem Vertrag, dessen Mängel sich sonst erst im Echtbetrieb gezeigt hätten, zu einem Zeitpunkt, an dem ein Wechsel ein Vielfaches an Aufwand verursacht.

Eine benannte Person aus dem Betrieb führt die Pilotphase

Die Pilotphase braucht auf Seiten des Betriebs eine Leitung, die den Prüfplan verantwortet, die Testfälle verteilt, die Protokolle einsammelt und am Ende die Auswertung vorlegt. Diese Person kommt aus dem Fachbereich, der die Software am stärksten nutzen wird, und darf die Arbeitszeit der Beteiligten einplanen. Sie ist zugleich die feste Ansprechperson für den Anbieter, sodass Rückfragen und Fehlermeldungen über einen einzigen Weg laufen.

Der Anbieter benennt seinerseits eine Ansprechperson und richtet die Pilotumgebung ein. Testfälle bearbeitet er nicht, und die Ergebnisse bewertet er nicht. Übernähme er die Durchführung, zeigten wieder seine Leute, was die Software kann, und die Pilotphase würde zur verlängerten Vorführung.

Über den Kauf entscheidet die Geschäftsführung auf Grundlage der Auswertung. Die Leitung der Pilotphase legt ihr dafür eine Zusammenfassung vor: die Messwerte je Messgröße im Vergleich zur Schwelle, die offenen Mängel mit der Stellungnahme des Anbieters und die Liste der nötigen Anpassungen.

Die Pilotvereinbarung regelt Ausstieg und Datenrückgabe

Die Pilotvereinbarung ist ein eigener Vertrag über den Probebetrieb, getrennt vom späteren Kauf- oder Nutzungsvertrag. Sie hält fest, was der Pilot umfasst, wie lange er läuft und welche Leistungen der Anbieter dafür erbringt. Für den Betrieb zählen darin vor allem zwei Zusagen: Der Pilot verpflichtet nicht zum Kauf, und die Daten, die während des Pilots in die Software gelangen, bleiben in seiner Verfügung. Sechs Regelungen setzen diese Zusagen um.

1. Ende ohne Kaufpflicht: Die Pilotphase endet zum vereinbarten Datum, ohne automatische Verlängerung und ohne Übergang in einen Nutzungsvertrag.
2. Vorzeitiger Ausstieg: Der Betrieb kann den Pilot vor dem Enddatum beenden, sobald ein vereinbartes Abbruchkriterium eintritt.
3. Herausgabe der Daten: Der Anbieter stellt alle im Pilot erfassten und eingespielten Daten auf Anforderung binnen einer festgelegten Frist in einem offenen, dokumentierten Format bereit.
4. Löschung: Nach der Herausgabe löscht der Anbieter die Daten aus der Pilotumgebung und bestätigt die Löschung schriftlich, einschließlich der Frist, nach der auch Sicherungskopien bereinigt sind.
5. Auftragsverarbeitung: Für personenbezogene Daten gilt ein Vertrag zur Auftragsverarbeitung, der vor dem ersten Import unterschrieben ist.
6. Übernahme der Einrichtung: Einstellungen und Anpassungen aus dem Pilot fließen bei einem Kauf in die Einrichtung des Echtsystems ein und werden dort weiterverwendet.

Die Regelungen zu Ausstieg und Datenherausgabe gehören in derselben Form in den späteren Hauptvertrag. Der Pilot erlaubt, sie einmal auszuprobieren: Zum Ende fordert der Betrieb den Export an und prüft, ob die Daten vollständig, lesbar und ohne Werkzeug des Anbieters weiterzuverwenden sind. Dieselbe Prüfung wird fällig, wenn der Betrieb die Software Jahre später verlässt. Wie sich die Abhängigkeit von Hersteller und Dienstleister auf mehreren Ebenen aufbaut, beschreibt der Wiki-Eintrag zur Anbieterbindung. Die Formulierung der Klauseln im Einzelnen ist Aufgabe der rechtlichen Beratung des Betriebs.

Fünf Fehler entwerten eine Pilotphase

Fünf Fehler nehmen einer Pilotphase ihre Aussagekraft, gleich welche Software geprüft wird.

Die ersten drei Fehler verzerren den Befund, die letzten zwei schwächen die Position des Betriebs nach dem Pilot.