Für Managed Service Provider ist Dokumentation nicht nur „nice-to-have“ – sie ist das Produkt. Mit Trupeer können Sie Stunden beim Erstellen von MSP-Dokumentationen sparen, indem Sie mit kostenlosen MSP-Dokumentationsvorlagen starten, sie mit Ihren Brand-Richtlinien anpassen und die Kundendokumentation in Video-Übersichten umwandeln, die jeder Techniker nutzen kann.

Was ist MSP-Dokumentation, und was macht sie anders?

MSP-Dokumentation ist alles, was ein Managed Service Provider aufschreibt, um die Technologie anderer Organisationen zu betreiben: Asset-Register, Netzwerkdiagramme, Zugangsdaten, Runbooks, Eskalationspfade, kundenspezifische Besonderheiten sowie die Berichte und Reviews, die der Kunde sieht.

Zwei Dinge machen sie strukturell anders als interne IT-Dokumentation – und fast jede Vorlage ignoriert beides.

Sie dokumentieren Umgebungen, die Sie nicht besitzen. Der Kunde hat einen Anspruch auf einen Teil dessen, was Sie schreiben, und keinen Anspruch auf den Rest – und diese Linie ist geschäftlich, vertraglich und am Tag des Beziehungsendes entscheidend.

Und Sie dokumentieren dasselbe Verfahren gleichzeitig für viele Umgebungen. Ein internes Team schreibt ein einziges Backup-Restore-Runbook. Ein MSP schreibt eines und muss es dann über dreißig oder vierzig Umgebungen hinweg aktuell halten, die sich in Details unterscheiden, an die sich niemand vollständig erinnert.

Das zweite Problem ist das, das die Marge eines MSP still und leise auffrisst – und hier beginnt diese Seite. Für die Version mit einer einzelnen Umgebung deckt unsere IT-Dokumentationsvorlage den allgemeinen Fall ab.

Warum vierzig Kopien eines Runbooks das eigentliche Problem sind

Fast jeder MSP startet auf die gleiche Weise. Erstellen Sie ein gutes Set an Runbooks. Onboarden Sie einen Kunden. Kopieren Sie die Runbooks in den Ordner oder den Bereich dieses Kunden, damit der Ingenieur, der das Ticket bearbeitet, alles an einem Ort hat. Wiederholen.

Das ist ein nachvollziehbarer Instinkt – und er führt zu einer langsamen Katastrophe. Nach vier Jahren mit dreißig oder so Kunden haben Sie weit über tausend Dokumente, von denen die meisten nahezu Duplikate sind, und es gibt keine Möglichkeit zu erkennen, welche Kopie aktuell ist.

Der Fehler liegt nicht darin, dass die Dokumente schlecht sind. Jede Kopie war korrekt, als sie erstellt wurde. Der Fehler ist, dass Verbesserungen am Verfahren jetzt dreißigmal angewendet werden müssen – und sie werden fünf- oder zehnmal angewendet, bevor jemand auf etwas Dringendes „gezogen“ wird.

Was Ingenieure als Nächstes tun, ist der teure Teil. Sobald ein Techniker zweimal von einem Runbook „verbrannt“ wurde, das nicht zur Umgebung passte, hört er auf, Runbooks zu lesen. Er arbeitet stattdessen von ersten Prinzipien aus – langsamer, weniger konsistent und in Ihrem Reporting komplett unsichtbar, weil das Ticket trotzdem geschlossen wird.

Daher muss eine MSP-Dokumentationsstruktur das Standard-Update an einem Ort ermöglichen. Alles Folgende ergibt sich daraus.

So passen Sie diese Vorlage in Trupeer an

Schritt 1: Öffnen Sie den Bereich „Vorlagen“

Gehen Sie im Hauptmenü zum Bereich „Vorlagen“.

Schritt 2: Wählen und öffnen Sie eine Vorlage

Klicken Sie auf eine beliebige Vorlage, mit der Sie arbeiten möchten, um sie zu öffnen.

Schritt 3: Ansicht der Vorlage erweitern

Falls nötig, erweitern Sie die Vorlagenansicht, um das vollständige Layout und die Details klar zu sehen.

Schritt 4: Vorlage bearbeiten

Klicken Sie auf „Bearbeiten“, um mit der Änderung der ausgewählten Vorlage zu beginnen.

Im Editor können Sie:

• Neue Abschnitte hinzufügen

• Formatierungsregeln definieren oder aktualisieren

• Ein Logo hinzufügen und Position sowie zugehörige Einstellungen anpassen

Schritt 5: Speichern Sie Ihre angepasste Vorlage

Nachdem Sie alle notwendigen Änderungen vorgenommen haben, klicken Sie auf „Speichern“, um die aktualisierte Vorlage als Ihre eigene zu speichern.

Schritt 6: Vorschau ansehen und Vorlage feinjustieren

Wenn Sie sehen möchten, wie Ihre angepasste Vorlage aussieht, öffnen Sie die Vorschau.

Ausgehend vom Vorschau-Bildschirm können Sie bei Bedarf weiterhin direkt Anpassungen vornehmen – damit die Vorlage genau so erscheint, wie Sie es möchten.

Mit MSP-Dokumentationsvorlagen können Sie:

• Stunden beim Schreiben sparen: Überspringen Sie die leere Seite – mit Strukturen, die für MSP-Operations gebaut sind.

• MTTR reduzieren: Klare Dokumentation hilft jedem Tech-Support, schnell für jeden Kunden.

• Im Brand bleiben: Nutzen Sie Ihr Logo, Ihre Schriftarten und Farben mit Trupeer's Brand Kit.

• Techniker schneller onboarden: Neue Techniker kommen mit klaren, video-basierten Dokumentationen schnell in die Spur.

• Audit-ready bleiben: Integrierte Abschnitte unterstützen SOC 2, ISO 27001 und Kunden-Audits.

• Globale Teams erreichen: Übersetzen Sie MSP-Dokumente mit einem Klick in 65+ Sprachen.

Gute MSP-Dokumentation ist das, was ein Managed-Services-Geschäft skalierbar macht. Nutzen Sie diese Vorlagen, um jeden Kunden, jedes System und jedes Verfahren klar und konsistent zu erfassen.

Dokumentieren Sie den Standard einmal, erfassen Sie nur die Abweichung

Eine Standard-Bibliothek. Eine Kopie jedes Dokuments. Versioniert, in Ihrem Besitz und der einzige Ort, an dem die Methode existiert.

Dann pro Kunde ein kurzes Dokument, das festhält, wo sich dieser Kunde vom Standard unterscheidet – und nichts weiter. Keine Kopie des Runbooks mit Änderungen. Eine Liste der Ausnahmen.

Das Abweichungsregister des Kunden ist der ganze Trick. Wenn der Kunde ein anderes Backup-Produkt nutzt, ist das eine Zeile. Wenn seine Firewall ein anderer Anbieter ist, ist das eine Zeile. Wenn sein Finanzdirektor jede Arbeit außerhalb der Geschäftszeiten genehmigen muss, ist das eine Zeile. Alles, was nicht im Register steht, ist per Definition Standard – das bedeutet, dass ein Ingenieur zwei Dokumente liest, statt in einem Ordner zu suchen und darauf zu hoffen, dass die Kopie darin aktuell ist.

Die Register bleiben klein. In der Praxis sitzt ein reifer Kunde irgendwo zwischen acht und zwanzig Zeilen, und das Schreiben eines Registers bringt meist drei oder vier Abweichungen zutage, die niemand irgendwo dokumentiert hatte.

Es gibt einen zweiten Vorteil, der später sichtbar wird. Eine kurze Liste von allem, was an einem Kunden nicht standardmäßig ist, ist ein sehr gutes Vertriebs- und Margendokument. Abweichungen sind dort, wo Ihre Zeit hingeht.

Das Abweichungsregister des Kunden und was darin steht

Eine Zeile pro Abweichung, fünf Felder.

Was abweicht. Im Vergleich zum Standard formuliert, also „Backup ist Datto statt unseres Standard-Veeam“ statt „nutzt Datto“.

Welches Standarddokument es betrifft. Die Referenz, damit ein Ingenieur, der das Runbook liest, hierhin verwiesen werden kann.

Warum. Kundenpräferenz, übernommen von einem früheren Anbieter, eine Compliance-Anforderung, eine technische Einschränkung. Dieses Feld bestimmt, ob die Abweichung es wert ist, entfernt zu werden.

Seit wann, und wann geprüft. Ein Datum. Abweichungen, die beim Onboarding übernommen werden, bleiben oft jahrelang bestehen, weil niemand sie erneut überprüft.

Aufwand oder Risiko. Ein kurzer Hinweis darauf, was es Sie kostet. So wird das Register nicht nur zu einem technischen, sondern auch zu einem kaufmännischen Dokument.

Fügen Sie eine Kopfzeile hinzu, die den Kunden benennt, die Version der Standard-Bibliothek, gegen die dieses Register erstellt wurde, sowie den Account Owner. Überprüfen Sie die Register vierteljährlich. Abweichungen ohne Grund und ohne Kosten sind Kandidaten für eine Standardisierung – und das ist in der Regel die Dokumentationsarbeit mit der höchsten Rendite, die ein MSP leisten kann.

Welche Dokumente ein MSP tatsächlich braucht, nach Kategorie

Die meisten MSPs sind stark in den ersten und fünften Zeilen und schwach in der dritten – und genau das ist umgekehrt, denn die dritte Zeile macht die zweite Zeile überhaupt erst nutzbar.

Zwei davon haben eigene Vorlagen, die sich direkt lohnen. Die Zugangsdaten und das Lizenzinventar haben ihren natürlichen Platz in unserem application and credentials register, und die Runbooks selbst folgen der Struktur in unserer IT SOP-Vorlage.

Kostenlose MSP-Dokumentationsvorlagen: die Standard-Bibliothek zum Aufbau

Kopieren Sie von hier. Das ist die minimale Standard-Bibliothek – und sie ist kleiner als die meisten MSPs erwarten.

Onboarding-Pack. Discovery-Checkliste, Site-Audit, Asset-Erfassung, Zugangsdaten-Erfassung, initiale Befüllung des Abweichungsregisters, Review des ersten Monats. Ein Dokument, einmal pro Kunde ausführen.

Runbooks, jeweils eins pro wiederkehrender Aufgabe. Backup-Restore, Benutzer erstellen und deaktivieren, Mailbox-Restore, Endpoint neu aufbauen, Passwort zurücksetzen, VPN-Zugriff, Drucker bereitstellen, Zertifikat erneuern, Patch-Ausnahme. Starten Sie mit den zehn Aufgaben, die die meisten Tickets erzeugen, statt zu versuchen, alles abzudecken.

Eskalation und Bereitschaft. Wie ein Ticket eskaliert, wen man in jeder Stufe kontaktiert, was als Notfall gilt, und die Regel zur Autorisierung außerhalb der Geschäftszeiten.

Incident und Änderung. Ein Format für Post-Incident-Reviews sowie ein Format für „Method of procedure“ für geplante Änderungen an der Kundeninfrastruktur.

Kundenseitige Berichte. Monatsbericht, Quartals-Business-Review und ein Output für den Site-Audit. Feste Struktur, Kundendaten werden ausgefüllt.

Offboarding-Pack. Was der Kunde erhält, was Sie behalten, in welchem Format, bis wann. Vor dem Bedarf erstellen.

Vorlage für das Abweichungsregister. Die fünf Felder oben.

Kopieren Sie hierher. Zehn bis fünfzehn Runbooks plus sechs „standing documents“ ergeben eine funktionierende Bibliothek. Der Instinkt, zuerst vierzig Runbooks zu schreiben, ist der Grund, warum die meisten MSP-Dokumentationsprojekte im zweiten Monat ins Stocken geraten.

Interne und externe MSP-Dokumentation – und wer was besitzt

Die Unterscheidung, die die meisten Guides ziehen, ist intern versus kundenseitig, was hilfreich ist, um den Ton festzulegen. Die wichtigere Unterscheidung ist jedoch das Eigentum – und das wird beim Offboarding real.

Grundsätzlich – und das variiert je nach Vertrag und Rechtsraum – gilt: Die Daten des Kunden sind die Daten des Kunden: Asset-Register, die seine Geräte beschreiben, seine Netzwerk-Topologie, seine Zugangsdaten, seine Lizenzberechtigungen, seine Konfiguration. Sie halten sie als Service Provider, statt sie zu besitzen.

Ihre Methode gehört Ihnen: die Standard-Runbooks, die Bericht-Formate, Ihre Build-Standards, Ihr Preismodell, Ihre internen Prozeduren. Wenn ein Kunde geht, hat er keinen Anspruch auf Ihre Runbook-Bibliothek.

Das Abweichungsregister sitzt unangenehm dazwischen – weshalb es sich lohnt, es in Ihrem Vertrag ausdrücklich zu benennen. Es beschreibt die Umgebung des Kunden, was für „deren“ spricht, aber es wird gegen Ihre Standards geschrieben, was für eine redigierte Version spricht.

Klärn Sie das schriftlich im Service Agreement, statt es am Austrittspunkt zu verhandeln. Diese Seite ist keine Rechtsberatung, und die Position unterscheidet sich je nach Vertrag und Rechtsraum – lassen Sie daher von Ihrem Anwalt die Dokumentations-Eigentums- und Rückgabeklauseln prüfen. Einmal machen kostet eine Stunde. Das während des Offboardings zu tun, kostet deutlich mehr, wie unten.

Der MSP mit 1.360 Dokumenten und neun veralteten Runbooks

Thornbury IT betrieb Managed Services für vierunddreißig Kunden mit zweiundzwanzig Mitarbeitenden, davon neun Ingenieure. Bei jedem Onboarding kopierten sie ihr Runbook-Set in den Bereich des neuen Kunden – was im vierten Jahr ungefähr vierzig Dokumente pro Kunde bedeutete und insgesamt etwa eintausenddreihundertsechzig.

Das Problem wurde während eines Incidents sichtbar. Ein Ingenieur arbeitete ein fehlgeschlagenes Backup für einen Kunden ab, nachdem er das Restore-Runbook dieses Kunden genutzt hatte, das eine Veeam-Job-Namenskonvention referenzierte. Der Kunde war bereits vierzehn Monate zuvor auf ein anderes Backup-Produkt umgestiegen. Das Standard-Runbook war aktualisiert worden. Die Kopie im Ordner dieses Kunden war es nicht.

Danach prüften sie die Restore-Runbooks von zwölf Kunden. Neun unterschieden sich vom aktuellen Standard, und fünf dieser neun Unterschiede waren einfach veraltet statt bewusst.

Die messbaren Kosten lagen in der Bearbeitungszeit. Die durchschnittliche Bearbeitungszeit in Tier 2 lag im gesamten Unternehmen bei siebenundvierzig Minuten. Für die Kunden, deren Runbooks veraltet waren, waren es einundsiebzig Minuten, weil die Ingenieure auf diesen Accounts aufgehört hatten, der Dokumentation zu vertrauen, und sie jedes Mal neu ausarbeiteten.

Separat hatte ein Kunde im dritten Jahr gekündigt und um seine Dokumentation gebeten. Thornbury schickte den Ordner des Kunden, der dessen eigene Standard-Runbooks enthielt, gemischt mit dem Asset-Register und den Zugangsdaten des Kunden. Niemand hatte jemals eine klare Linie gezogen. Der Streit darüber, wozu der Kunde berechtigt war, dauerte sechs Wochen und bezog die Anwälte beider Firmen ein.

Der Wiederaufbau dauerte einen Monat mit der Zeit einer einzigen Person. Eine Standard-Bibliothek, eine Kopie, versioniert. Pro Kunde nur ein Abweichungsregister. Die durchschnittliche Registerlänge lag bei elf Zeilen.

Eintausenddreihundertsechzig Dokumente wurden zu vierzig Standarddokumenten und vierunddreißig Registern, also insgesamt vierundsiebzig. Die Bearbeitungszeit in Tier 2 konvergierte auf vierundvierzig Minuten über alle Accounts hinweg. Und das Offboarding-Pack wurde ab dann im Vertrag definiert: Der Kunde erhält das Asset-Register, die Zugangsdaten, die Diagramme und sein Abweichungsregister, und Thornbury behält die Standard-Bibliothek.

Gibt es kostenlose MSP-Dokumentationsvorlagen auf GitHub?

Ja, und sie lohnen sich – mit realistischen Erwartungen.

Was Sie dort finden werden, sind Community-Repositories von Runbook-Sammlungen, PowerShell-Skriptbibliotheken mit eingebetteter Dokumentation, markdown-basierte Dokumentations-Frameworks und gelegentlich eine vollständige Dokumentationsstruktur, die ein MSP als Recruiting- oder Marketingmaßnahme veröffentlicht. Wenn Sie nach MSP-Runbooks oder IT-Dokumentation neben markdown oder docs-as-code suchen, wird der Großteil davon auftauchen.

Was in diesen Repositories wirklich nützlich ist, ist Struktur und Abdeckung: Eine Liste der Runbooks, die ein kompetenter MSP pflegt, ist eine gute Checkliste für Ihre eigene. Was selten nützlich ist, ist der Inhalt, denn Runbooks sind spezifisch für einen Tool-Stack – und eine Restore-Prozedur für das Backup-Produkt und RMM eines anderen ist näher an einem ausgearbeiteten Beispiel als an einer Vorlage.

Zwei Hinweise. Prüfen Sie die Lizenz, bevor Sie irgendetwas in eine kommerzielle Dokumentationsbibliothek übernehmen, da permissive Lizenzen zwar häufig sind, aber nicht universell. Und passen Sie niemals ein Repository an, das echte Kundenkennungen, Netzwerkdetails oder etwas enthält, das wie Zugangsdaten aussieht – das taucht in öffentlichen Repos zwar öfter auf, als es sollte, aber Sie sollten es nicht übernehmen.

Der Ansatz „docs-as-code“ selbst, also markdown in der Versionsverwaltung, ist für einen MSP eine legitime Option und löst das Problem der Einzelkopie elegant. Seine Schwäche ist, dass Ingenieure unter Zeitdruck nicht in ein Repository committen – daher ist die Akzeptanz meist der begrenzende Faktor, nicht das Tooling.

MSP-Dokumentationssoftware und das Vendor-Lock-in-Problem

Die Dokumentationsplattformen, die sich an MSPs richten, sind gut in den Dingen, die man selbst nur schwer aufbauen kann: strukturierte Beziehungen zwischen Assets, Integration mit Ihrem RMM und PSA, die Handhabung von Zugangsdaten mit Audit-Trail sowie die Trennung pro Kunde mit Berechtigungen.

Der Trade-off ist, dass Ihre Dokumentation durch deren Datenmodell geformt wird – und das Herausbekommen in einer nutzbaren Form ist häufig schlechter, als der Verkaufsprozess vermuten lässt. Ein Export bedeutet meist eine Reihe von Datensätzen statt der lesbaren Dokumente, die Ihre Ingenieure tatsächlich verwenden.

Bevor Sie sich festlegen, lohnt sich die Frage nach zwei Punkten. Können Sie alles exportieren – einschließlich Beziehungen und Anhängen – in einem Format, das auch dann noch nutzbar wäre, wenn Sie nie ein weiteres Produkt gekauft hätten. Und können Sie ein einzelnes Standarddokument pflegen, das für alle Kunden gilt, oder erzwingt das Modell eine Kopie pro Kunde, wodurch genau das Problem dieser Seite wieder eingeführt wird.

Diese zweite Frage schließt mehr Produkte aus, als Sie erwarten würden. Wenn eine Plattform Kopien pro Kunde erzwingt, halten Sie die Standard-Bibliothek außerhalb davon – in etwas Schlichterem – und nutzen Sie die Plattform für die Kundenumgebungsdaten, also genau für das, wofür sie wirklich gut ist. Unser knowledge base template deckt das Strukturieren dieser Standard-Bibliothek ab, unabhängig davon, wo sie am Ende lebt.

Was passiert mit der Dokumentation, wenn ein Kunde geht?

Offboarding ist der Moment, in dem die Qualität der Dokumentation sichtbar wird – meist bei Menschen, die ohnehin schon unzufrieden sind.

Definieren Sie das Pack im Vertrag. Eine sinnvolle Position ist, dass der Kunde sein Asset-Register, seine Netzwerkdiagramme, sein Lizenzinventar, die sicher übertragenen Zugangsdaten, sein Abweichungsregister sowie alle Dokumentationen erhält, für die er bezahlt hat, als Deliverable. Sie behalten Ihre Standard-Runbooks, Bericht-Formate und internen Prozeduren.

Legen Sie einen Zeitraum und ein Format in derselben Klausel fest, denn „die Dokumentation wird bereitgestellt“ ist der Punkt, an dem Streit beginnt. Dreißig Tage und ein festgelegtes Format sind normal.

Führen Sie die Übergabe der Zugangsdaten über einen ordentlichen Prozess durch – nicht über eine Tabelle – und dokumentieren Sie, was übertragen wurde und wann, da diese Aufzeichnung beide Parteien schützt, falls später etwas zugegriffen wird.

Wenn der Abgang eine Übergabe an einen anderen Anbieter ist und nicht „in-house“, ist ein strukturiertes Handover deutlich günstiger als ein Dokumenten-Dump – und unser knowledge transfer SOP erklärt, wie man das durchführt.

Kann ich MSP-Dokumentationsvorlagen als PDF bekommen?

PDF ist für zwei davon richtig und für den Rest falsch.

Richtig für kundenseitige Dokumente: den Monatsbericht, das Quartals-Review, den Site-Audit-Output. Das sind Momentaufnahmen, und sie einzufrieren ist korrekt – außerdem sollten sie Ihre Brand tragen.

Falsch für Runbooks, das Abweichungsregister und das Asset-Register – alles, was sich ändert und was durchsuchbar sein muss. Eine PDF-Runbook-Bibliothek ist eine langsamere Version des Problems im ausgearbeiteten Beispiel oben, weil ein PDF einem Leser nicht sagen kann, dass es veraltet ist.

Für die Standard-Bibliothek nutzen Sie das, wonach Ihre Ingenieure unter Druck tatsächlich suchen, und behalten Sie eine Kopie. Für Kunden-Deliverables erzeugen Sie das PDF aus dieser Quelle, statt eine separate Version zu pflegen.

So halten Sie die Standard-Bibliothek für jeden Kunden aktuell

Die gesamte Struktur hängt davon ab, dass die Standard-Bibliothek wirklich gepflegt wird – und der Grund, warum sie das normalerweise nicht ist, lautet: Das Aktualisieren eines Runbooks bedeutet, dass jemand Schritte per Screenshot macht, zuschneidet und neu schreibt – für ein Tool, das man bereits bedienen kann.

Trupeer AI entfernt den Großteil davon. Ein Ingenieur führt die Aufgabe einmal vor der Kamera aus, und das Ergebnis ist ein formatiertes Runbook mit den Schritten und Screens, die bereits an Ort und Stelle sind – bereit zum Review, statt neu geschrieben zu werden. Ein Refresh von zehn Runbooks wird zu einem Tag statt zu einem Quartal.

Dokumentieren Sie es. Branden Sie es. Übersetzen Sie es. Trupeer it.

Für kundenseitiges Material ist Branding geschäftlich wichtig – und brand kits sorgen dafür, dass der Bericht und der Guide, die der Kunde erhält, so aussehen, als kämen sie von Ihnen und nicht aus einer Vorlage. Documentation und technical documentation halten die Standard-Bibliothek und die Aufzeichnungen der Kundenumgebung zusammen, und der SOP creator deckt die Runbooks selbst ab. Setup-Anleitungen finden Sie im document template setup guide.

Häufig gestellte Fragen

Gibt es kostenlose MSP-Dokumentationsvorlagen als PDF?

Die Strukturen auf dieser Seite sind kostenlos zum Kopieren, und die sinnvolle Aufteilung ist, Runbooks und Register in etwas durchsuchbar zu halten, während kundenseitige Berichte als PDF exportiert werden. Es gibt keinen gesperrten Download und kein Formular. Wenn Sie ein PDF der Standard-Bibliothek als Referenz möchten, erstellen Sie es aus Ihrer Live-Kopie, statt es separat zu pflegen.

Was sind die besten kostenlosen MSP-Dokumentationsvorlagen?

Das beste Set ist das kleinste, das Sie aktuell halten werden: zehn bis fünfzehn Runbooks, die Ihre höchsten Ticket-Volumen abdecken, ein Onboarding-Pack, ein Eskalationsdokument, ein Format für das Abweichungsregister sowie drei kundenseitige Bericht-Formate. Beurteilen Sie jede Vorlagenbibliothek danach, ob sie den Standard von der Ausnahme pro Kunde trennt – denn das ist der Teil, der bestimmt, ob sie bei dreißig Kunden überlebt.

Wo sollte ein MSP seine Dokumentation aufbewahren?

Daten zur Kundenumgebung gehören in eine Plattform, die sich in Ihr RMM und PSA integriert und Zugangsdaten korrekt verwaltet. Die Standard-Bibliothek gehört dorthin, wo Ingenieure sie am schnellsten durchsuchen – möglicherweise dieselbe Plattform oder etwas Schlichteres. Die entscheidende Frage ist, ob die Plattform es Ihnen erlaubt, ein Dokument zu pflegen, das für alle Kunden gilt.

Wie viel Dokumentation sollte ein neuer Kunde beim Onboarding erhalten?

Keine Ihrer Standard-Bibliothek und alle eigenen Daten zur Umgebung. In der Praxis ist das Onboarding-Deliverable, das ein Kunde am meisten schätzt, das Asset-Register, das Netzwerkdiagramm und eine einfache Zusammenfassung dessen, was Sie gefunden haben und was Sie empfehlen. Runbooks beim Onboarding zu senden ist ein häufiger Instinkt – und er gibt Ihre Methode ohne kaufmännischen Gegenwert preis.

Besitzt der Kunde die Dokumentation, die wir über seine Systeme schreiben?

Meistens ja für deren Daten, meistens nein für Ihre Methode – und die Grenze sollte in das Service Agreement geschrieben werden, statt am Austritt verhandelt zu werden. Asset-Register, Diagramme, Zugangsdaten und Konfiguration beschreiben deren Eigentum. Ihre Standard-Runbooks und Bericht-Formate sind Ihr geistiges Eigentum. Lassen Sie die Klausel von Ihrem eigenen Anwalt prüfen, denn die Position variiert je nach Vertrag und Rechtsraum.

Wie stellen wir sicher, dass Ingenieure die Dokumentation nicht überspringen?

Machen Sie zuerst die Standard-Bibliothek vertrauenswürdig. Ingenieure überspringen Dokumentation, weil sie schon einmal falsch war – nicht weil sie das Lesen nicht mögen. Lösen Sie das Problem der Einzelkopie, bringen Sie die Bearbeitungszeiten zur Konvergenz, und das Verhalten ändert sich von selbst. Nur bei Ticket-Schluss Dokumentations-Updates zu verlangen funktioniert erst, wenn die Bibliothek es wert ist, aktualisiert zu werden.