Das Wichtigste in Kürze
- Abnahme heißt nicht, dass etwas funktioniert, sondern dass jemand anderes es weiterbetreiben kann. Das sind zwei verschiedene Prüfungen.
- Sechs Artefakte tragen den Betrieb: Inventar-Diff, HLD/LLD, Konfigurationsvorlagen, Testbericht, Change-Log und Abnahmeprotokoll.
- Das wichtigste Kriterium ist nicht Vollständigkeit, sondern Wiederverwendbarkeit: Ein PDF beschreibt den Zustand, eine Vorlage erzeugt ihn erneut.
- Wer diese Artefakte im Angebot nicht findet, sollte vor der Beauftragung danach fragen — nachträglich entstehen sie selten.
Die Abnahme eines Netzprojekts ist in vielen Fällen ein gemeinsamer Blick auf einen funktionierenden Zustand: Die Standorte sind verbunden, das WLAN trägt, die Anwendung antwortet. Danach wird unterschrieben. Was dabei nicht geprüft wird, ist die eigentliche Frage — ob jemand ohne den Erbauer weiterarbeiten kann.
Zwei Prüfungen, nicht eine
Die erste Prüfung ist funktional: Tut es, was es soll? Sie ist notwendig, aber leicht zu bestehen — am Tag der Übergabe steht alles frisch konfiguriert und aufmerksam beobachtet da.
Die zweite Prüfung ist betrieblich: Kann jemand anderes das übernehmen, verstehen und verändern? Sie wird selten gestellt, entscheidet aber über die Kosten der nächsten fünf Jahre. Ein Netz, das nur sein Erbauer ändern kann, ist kein fertiges Projekt, sondern ein laufender Vertrag.
Die sechs Artefakte
Wir führen jeden Change über dieselben sechs Stufen, und jede hinterlässt genau ein Artefakt, das Bestand hat. Das ist keine Formalie: Diese sechs Dokumente sind zusammen die Antwort auf die zweite Prüfung.
Inventar-Diff
Der Ist-Zustand, aus Geräten, Controllern und APIs erhoben und der vorhandenen Dokumentation gegenübergestellt. Der Wert liegt in der Differenz: Sie zeigt, worüber vorher falsche Annahmen bestanden.
HLD und LLD
Zielarchitektur und Detaildesign — was gebaut wird und warum so. Das LLD beantwortet später die Frage, die im Betrieb am häufigsten gestellt wird: Warum ist das hier eigentlich so gelöst?
Konfigurationsvorlagen
Die Zielkonfiguration als Vorlage aus strukturierten Daten, nicht als abgetippte Gerätekonfiguration. Nur die Vorlage lässt sich für den nächsten Standort wiederverwenden; der fertige Text nicht.
Testbericht
Automatisierte Prüfungen von Routing, Nachbarschaften, VPN, Redundanz und Erreichbarkeit — vor und nach dem Change. Der Bericht ist die Freigabegrundlage und später der Vergleichsmaßstab, wenn etwas anders ist als früher.
Change-Log
Was wurde wann von wem geändert, mit Freigabe und Rückfallweg. Im Störungsfall ist das die erste Frage überhaupt — und ohne Protokoll die teuerste.
Abnahmeprotokoll
Was übergeben wurde, was geprüft wurde, was ausdrücklich offen bleibt. Der letzte Punkt ist der wertvollste: Eine benannte offene Position ist Betriebswissen, eine verschwiegene ist eine Falle.
Das Kriterium heißt wiederverwendbar, nicht vollständig
Ein umfangreiches Dokumentationspaket ist noch keine gute Übergabe. Der Unterschied liegt darin, ob ein Artefakt den Zustand beschreibt oder ihn erzeugt. Ein PDF mit Screenshots der Konfiguration beschreibt; eine versionierte Vorlage mit den zugehörigen Daten erzeugt. Beim nächsten Standort ist das der Unterschied zwischen einem Tag und einer Woche.
Drei Fragen prüfen das schnell und ohne technische Tiefe:
- Können wir aus dem Gelieferten einen weiteren Standort bauen, ohne Sie zu fragen? Wenn nein, haben Sie eine Beschreibung, keine Vorlage.
- Liegen die Artefakte in unseren Werkzeugen? Repository, Wiki, Ticketsystem — nicht als Anhang in einer E-Mail und nicht auf einem Portal des Dienstleisters.
- Ist der Testlauf wiederholbar? Ein Testbericht, dessen Prüfungen sich nicht erneut ausführen lassen, belegt einen Tag, nicht einen Zustand.
Vor der Beauftragung fragen, nicht bei der Abnahme
Artefakte entstehen während der Arbeit oder gar nicht. Wer sie erst bei der Abnahme verlangt, bekommt sie nachträglich erzeugt — und nachträglich erzeugte Dokumentation beschreibt, was jemand erinnert, nicht was gebaut wurde.
Vier Punkte gehören deshalb in die Anfrage: welche Artefakte geliefert werden, in welcher Form, in wessen Werkzeugen sie liegen und wem sie gehören. Die Antworten sind kurz und unterscheiden Anbieter deutlicher als Stundensätze.
Für Systemhäuser, die Kapazität zukaufen, ist dieser Punkt der wichtigste überhaupt — er entscheidet, ob der nächste Change wieder ein Zukauf sein muss. Mehr dazu im Beitrag über White-Label-Zusammenarbeit. Wie wir die sechs Stufen fahren, beschreibt unsere Seite zu Network Automation.
Warum offene Punkte ins Protokoll gehören
Kein Projekt endet ohne Reste: ein Gerät, das erst im nächsten Quartal getauscht wird, eine Ausnahme, die aus fachlichen Gründen bestehen bleibt, eine Funktion, die auf eine Softwareversion wartet. Der Reflex, das im Abnahmeprotokoll wegzulassen, ist verständlich und falsch.
Eine benannte offene Position mit Datum und Verantwortlichem ist Betriebswissen — sie taucht bei der nächsten Störung als Erklärung auf statt als Überraschung. Eine verschwiegene wird irgendwann gefunden, und dann steht nicht die Ausnahme in Frage, sondern die Übergabe insgesamt.