Leistungsbeschreibung für Service-Software: den Servicefall prüfbar beschreiben

Die Leistungsbeschreibung ist der Teil eines Werkvertrags, der festlegt, welches Ergebnis geschuldet ist und woran es gemessen wird. Bei Software rund um ein technisches Produkt beschreibt sie Nutzerrollen, Serviceabläufe, Produktdaten und Schnittstellen so genau, dass Auftraggeber und Auftragnehmer denselben Satz auf dieselbe Weise verstehen.

Leistungsbeschreibung: Begriff und Rolle im Vertrag

Im Werkvertrag schuldet der Unternehmer einen Erfolg. Welcher Erfolg das ist, ergibt sich nicht aus dem Vertragsmuster, sondern aus der Anlage, die das Werk beschreibt. Sie ist Maßstab an drei Stellen: bei der Kalkulation des Angebots, bei der Abnahme und bei der Frage, ob ein späterer Befund ein Mangel ist oder ein neuer Wunsch.

Fehlt eine Eigenschaft in der Anlage, schuldet der Unternehmer nach dem Gesetz nur, was sich für die vertraglich vorausgesetzte oder die gewöhnliche Verwendung eignet. Für eine Service-App ist das Gewöhnliche aber kaum bestimmbar: Ob Techniker ohne Netz arbeiten müssen, weil in Maschinenhallen und Kellern kein Empfang ist, weiß nur der Hersteller.

Entlang eines Servicefalls beschreiben statt Funktionen aufzählen

Funktionslisten wie „Suche nach Ersatzteilen“ oder „Push-Nachrichten“ lassen offen, wie die Teile zusammenwirken. Tragfähiger ist es, einen typischen Fall vom ersten bis zum letzten Schritt durchzugehen:

1. Ein Endkunde meldet eine Störung und gibt die Seriennummer seiner Anlage an.
2. Der Innendienst sieht Baujahr, Variante und frühere Einsätze und plant einen Techniker ein.
3. Der Techniker öffnet vor Ort das passende Kapitel des Handbuchs und bestellt ein Teil aus der Stückliste genau dieser Variante.
4. Nach dem Einsatz entsteht ein Servicebericht, den der Endkunde bestätigt und der im ERP zur Rechnung wird.

Jeder Schritt wird zu einem Absatz: wer handelt, welche Daten er sieht, was das System daraufhin tut. Sonderfälle erhalten eigene Sätze, etwa wenn das Teil nicht lieferbar ist, die Seriennummer im System fehlt oder der Techniker offline arbeitet.

Rollen, Produktdaten und Grenzen des Umfangs

Neben dem Ablauf braucht das Dokument drei Verzeichnisse:

• Nutzerrollen. Innendienst, Servicetechniker, Händler, Endkunde, jeweils mit dem, was die Rolle sehen und ändern darf. Händler sehen häufig nur Geräte ihres Gebiets, Endkunden nur die eigenen.
• Datengrundlage. Woher Stücklisten, Explosionszeichnungen, Handbücher und Gerätehistorien kommen, in welchem Format sie vorliegen und wer sie pflegt. Für einen digitalen Ersatzteilkatalog ist dieser Punkt der größte Kostentreiber.
• Abgrenzung. Was ausdrücklich nicht dazugehört: Das ERP bleibt führend für Preise und Bestände, Übersetzungen der Handbücher liefert der Hersteller, ältere Baureihen ohne digitale Stückliste bleiben außen vor.

Die Abgrenzung wird am häufigsten vergessen, und gerade sie verhindert spätere Nachträge.

Von der Leistungsbeschreibung zum Prüffall der Abnahme

Ein Satz taugt, wenn sich aus ihm ein Prüffall ableiten lässt, den Hersteller und Auftragnehmer unabhängig voneinander gleich bewerten. „Die App ist benutzerfreundlich“ scheitert daran. „Ein Techniker findet über die Seriennummer das Handbuchkapitel zur gemeldeten Störung, auch ohne Netzverbindung“ besteht.

Für KI-Bausteine gilt dasselbe mit anderer Messgröße: Ein Assistent, der Fragen zu Handbüchern beantwortet, wird an einer vorab vereinbarten Sammlung echter Servicefragen geprüft, mit festgelegter Schwelle und mit der Regel, dass er ohne Fundstelle im Dokument keine Antwort gibt. Wie die Prüfung selbst abläuft und welche Folgen sie hat, erklärt der Beitrag zur Abnahme.

Typische Lücken bei Service-Software

• Varianten fehlen. Beschrieben ist das Standardgerät, im Feld stehen viele Ausführungen mit abweichenden Stücklisten.
• Offline-Betrieb bleibt unerwähnt, obwohl Einsätze in Hallen ohne Empfang stattfinden.
• Datenqualität wird unterstellt. Stammdaten gelten als vollständig, bis der Katalog leere Seiten zeigt.
• Schnittstellen bleiben vage. „Anbindung an das ERP“ steht im Text, aber nicht, welche Daten in welche Richtung fließen und welches System bei widersprüchlichen Angaben gilt.
• Mitwirkung fehlt. Wer Testgeräte, Handbücher und fachliche Entscheidungen liefert, steht nirgends.
• Personenbezogene Daten tauchen auf, etwa Namen von Endkunden und Standorte von Technikern, ohne dass geklärt ist, wer sie in wessen Auftrag verarbeitet.

So setzen wir die Beschreibung mit Service und Innendienst auf

Wir schreiben die Anlage nicht am Schreibtisch, sondern gehen mit Serviceleitung und Innendienst einige abgeschlossene Servicefälle Schritt für Schritt durch. Daraus entstehen Ablauf, Rollen, Datengrundlage und Abgrenzung; die Abnahmekriterien stehen im Angebot, bevor die Arbeit beginnt. Verarbeiten wir dabei personenbezogene Daten im Auftrag des Herstellers, schließen wir einen Auftragsverarbeitungsvertrag. Wie aus der Beschreibung ein Portal oder eine App wird, zeigt die Seite Softwareentwicklung.