Statement of Work (SoW) für Cisco Router: Dokumentstruktur zur Streitvermeidung

Ein Statement of Work (SoW) für Cisco-Router-Projekte ist das wichtigste Dokument zur Streitvermeidung, weil es „Lieferumfang“, „Abnahme“ und „Verantwortung“ operationalisiert. Viele Konflikte entstehen nicht durch schlechte Technik, sondern durch fehlende Klarheit: Welche Sites sind enthalten? Wer liefert Providerdaten? Was genau ist „Go-Live“? Welche Tests gelten als bestanden? Was ist Out-of-Scope? Ein production-grade SoW beschreibt deshalb nicht nur Aufgaben, sondern messbare Deliverables, Acceptance Criteria, Change-Control und Rollback-Regeln. Dieser Leitfaden zeigt eine praxistaugliche SoW-Dokumentstruktur, die technische und kaufmännische Risiken reduziert.

SoW-Grundprinzip: Präzise Sprache schlägt „Best Effort“

Ein SoW sollte so geschrieben sein, dass zwei Personen nach Monaten zum gleichen Ergebnis kommen. Vermeiden Sie schwammige Formulierungen und definieren Sie Begriffe (Go-Live, Incident, Abnahme, Change Window) eindeutig.

• Begriffe definieren: Go-Live, UAT/ATP, Rollback, Business Hours, P1
• Messbarkeit: jede Leistung hat ein überprüfbares Ergebnis
• Evidence: Nachweise sind Teil der Lieferung, nicht optional
• Ownership: RACI oder klare Verantwortlichkeiten pro Aufgabe

Dokumentkopf: Parteien, Scope-Parameter und Gültigkeit

Starten Sie mit einem eindeutigen Rahmen, damit spätere Nachträge nicht den Kern verwässern. Der Dokumentkopf ist oft das erste, was Juristen und Procurement lesen.

• Parteien: Auftraggeber, Auftragnehmer, Ansprechpartner, Eskalationskontakte
• Gültigkeit: Projektname, Version, Datum, Laufzeit
• Scope-Parameter: Anzahl Geräte/Sites, Standorttypen, Regionen
• Abhängigkeiten: Provider, Wartungsfenster, Zugänge, Change-Prozesse

Projektziele und Erfolgskriterien: Was „fertig“ bedeutet

Definieren Sie Ziele als überprüfbare Kriterien. So vermeiden Sie Diskussionen über „Qualität“ ohne Messwerte.

• Connectivity: definierte Services erreichbar (Internet, VPN, Routing)
• Stabilität: keine Flaps/Loops im Abnahmefenster
• Security: Management Plane geschützt, AAA/Logging aktiv
• Operability: Monitoring integriert, Runbooks und Handover erfolgt

Scope of Work: Leistungsblöcke (In-Scope)

Gliedern Sie den Scope in Phasen, die jeweils Deliverables erzeugen. Das erhöht Planbarkeit und macht Teilabnahmen möglich.

• Assess: Requirements, Ist-Aufnahme, Risiko-/Abhängigkeitsliste
• Design: HLD/LLD, IP-Plan (falls beauftragt), Routing/VPN/Security Design
• Build: Konfig, Templates/Variablenmodell (bei Multi-Site), Staging
• Implement: Cutover-Plan, Remote/Onsite Umsetzung, Kommunikationsplan
• Validate: Pre-/Post-Checks, UAT/ATP, KPI-Nachweise
• Handover: As-Built, Backups, Runbooks, Knowledge Transfer

Out-of-Scope: Exclusions und Annahmen (Scope-Creep-Schutz)

Ein SoW ohne Exclusions ist eine Einladung zum Streit. Schreiben Sie Annahmen explizit, damit Änderungen als Change Request behandelt werden.

• Exclusions: Endgeräte, Applikationssupport, Firewall-Redesign (wenn nicht beauftragt)
• Provider: Verantwortung für Circuit-Fix und Termine klar abgrenzen
• Annahmen: Anzahl VLANs, Tunnel, Routing-Peers, Change Windows
• Varianten: Dual-ISP/LTE/VRF nur wenn explizit beauftragt

RACI/Verantwortlichkeiten: Wer liefert was?

Die häufigste Projektverzögerung entsteht durch fehlende Inputs. Legen Sie fest, wer welche Informationen und Zugänge bereitstellt und bis wann.

• Customer: Providerdaten, IP-Plan/Netze, Zugang zu Standorten, Freigaben
• Vendor: Design, Konfiguration, UAT, Evidence Pack, Dokumentation
• Gemeinsam: Cutover-Kommunikation, Change Approval, Abnahme

Deliverables: Konkrete Ergebnisliste (mit Format)

Deliverables sollten als Liste mit klaren Formaten beschrieben sein. So vermeiden Sie „Dokument“ vs. „Dokumentation“-Diskussionen.

• As-Built Report: HLD/LLD, Implementierungsstand, Versionen, IP-Plan
• Konfig-Backups: PRE/POST running und startup, Boot/Image Infos
• Runbooks: Incident Triage + Change Pre/Post + Rollback
• UAT/ATP Protokoll: Testfälle, Evidence, Pass/Fail
• Monitoring: KPI-Definitionen, Alarmkatalog, Integrationsparameter

Evidence Pack (Beispielanforderung)

Evidence Pack muss als Dateiablage geliefert werden (Timestamp + Geräte-ID) und mindestens enthalten:
show version
show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show ip route summary
show crypto ipsec sa (falls Scope)
show ip sla statistics (falls Dual-ISP)
show track (falls Dual-ISP)
show ntp status
show logging | last 100

Acceptance Criteria: Abnahmebedingungen und Testmethodik

Abnahme ist der zentrale Streitpunkt. Definieren Sie Pass/Fail Kriterien, Abnahmefenster und was bei Teilabnahme gilt (z. B. pro Site oder pro Batch).

• Abnahmeobjekt: pro Site, pro Batch oder gesamtes Projekt
• Pass: UAT bestanden, Monitoring sichtbar, Evidence geliefert
• Fail: kritischer Service down, Routing Loop/Flaps, Managementverlust
• Abnahmefenster: definierte Beobachtungszeit (z. B. 24–72h nach Go-Live)

UAT/ATP Testfälle (Template-Auszug)

• Internet: DNS + HTTPS erreichbar, Default-Route korrekt
• VPN: Tunnel up und Traffic-Counter steigen (falls Scope)
• Segmentierung: Guest→RFC1918 blockiert, Users→MGMT blockiert (falls Scope)
• Failover: Link/Path Test, Umschaltzeit dokumentiert (falls Dual-ISP)
• Logging: NTP synced, Syslog zentral sichtbar

Change Management: Change Window, Freeze und Kommunikationsplan

Für Streitvermeidung muss klar sein, wie Changes genehmigt werden und wer wann kommuniziert. Definieren Sie außerdem Freeze-Phasen, um Nebenwirkungen durch parallele Änderungen zu vermeiden.

• Change Window: Datum/Zeiten, Ansprechpartner, Bridge/Chat-Kanal
• Kommunikation: Stakeholder-Updates, Statusintervalle
• Freeze: keine parallelen Netzwerk-/Firewall-Changes im Abnahmefenster
• Dokumentation: Change-ID Pflicht in Deliverables

Rollback: Backout Trigger, Zeitbox und Zuständigkeit

Rollback ist kein „Plan B“, sondern Teil des Plans. Legen Sie fest, wann zurückgerollt wird und wer die Entscheidung trifft.

• Trigger: Internet/VPN kritisch down, Routing Loop/Flaps, Managementverlust
• Zeitbox: Rollback Reserve fest im Window, sonst wird zu spät entschieden
• Entscheidung: benannte Rollen (Change Manager, Tech Lead)
• Validierung: Nachweis, dass der alte Zustand wieder stabil ist

SLA/Support: Servicezeiten, Reaktionszeiten und Eskalation

Wenn Support enthalten ist, definieren Sie Incident-Klassen und Ziele. Trennen Sie „Response“ und „Restore“, damit Erwartungen realistisch sind.

• Servicezeiten: 24/7 oder Business Hours
• Incident-Definitionen: P1/P2/P3, Beispiele
• Reaktionszeit: bis qualifizierte Bearbeitung startet
• Restore-Ziel: Workaround/Recovery-Zeit je Priorität
• Eskalationspfad: NOC → Senior Engineer → Hersteller/Provider

Kaufmännisch: Preisstruktur, Zahlungsplan und Change Requests

Viele Streitfälle sind kaufmännisch. Legen Sie fest, wie abgerechnet wird, wann Zahlungen fällig sind und wie CRs behandelt werden.

• Preismodell: Fixpreis vs. T&M, Stundensätze, Leistungsgrenzen
• Zahlungsplan: Meilensteine (Design-Abnahme, Go-Live, Handover)
• CR-Prozess: schriftlich, mit Scope/Impact/Preis/Terminen
• Spesen/Reisen: Regeln, Genehmigung, Limits

Daten und Sicherheit: Zugänge, Geheimnisse und Datenhandling

Router-Projekte berühren sensible Daten (Keys, Passwörter, Logs). Regeln Sie Secret-Handling und Zugriffspflichten verbindlich.

• Secret-Handling: keine Klartext-Keys in Tickets/Dokumenten
• Übergabe: sichere Kanäle, Rotation nach Projekt
• Logging: Zugriff auf Logs/Rollendefinition, Retention
• Remote Access: Bastion/VPN, Whitelisting, Protokollierung

Beispiel: Mindest-CLI-Checks als Bestandteil der Abnahme

Ergänzen Sie das SoW um ein standardisiertes CLI-Evidence-Set, damit technische Abnahmen objektiv sind und nicht auf „Screenshots“ basieren.

show version
show clock
show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show ip route summary
show ip ospf neighbor
show bgp summary
show crypto ipsec sa
show ip sla statistics
show track
show ntp status
show logging | last 100
show processes cpu sorted

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.