Leitfaden: Dokumentationen / Anleitungen erstellen

Gültig für:	Alle Anleitungen im Unternehmen, unabhängig vom betroffenen System (z. B. ERP, CRM, sonstige Fachanwendungen)
Zielgruppe dieses Dokuments:	Alle Mitarbeitenden, die Anleitungen verfassen
Version:	1.0

1. Zweck und Grundprinzip

Jede Anleitung im Wiki muss so geschrieben sein, dass eine Person ohne jegliche Vorkenntnisse den beschriebenen Ablauf allein anhand der Anleitung durchführen kann – ohne Rückfragen stellen zu müssen.

Daraus ergeben sich drei feste Grundregeln, die für jede Anleitung gelten:

Ein Schritt = ein Screenshot. Jeder einzelne Arbeitsschritt bekommt einen eigenen Screenshot.
Screenshot zuerst, Text darunter. Der Screenshot zu einem Schritt steht immer oberhalb der dazugehörigen Textbeschreibung – nie umgekehrt, nie daneben.
Nichts voraussetzen. Begriffe, Menüpfade und Feldnamen werden exakt so benannt wie im jeweiligen System angezeigt – nicht umschrieben oder abgekürzt.

2. Aufbau einer Anleitung (inhaltliche Struktur)

Jede Anleitung folgt derselben Gliederung. Das erleichtert das Lesen (Wiedererkennung) und stellt sicher, dass nichts vergessen wird.

#	Abschnitt	Inhalt
1	Titel	Klar, prozessorientiert, siehe Namenskonvention in Kapitel 6
2	Kurzbeschreibung / Ziel	1–2 Sätze: Was wird am Ende erreicht?
3	Voraussetzungen	Benötigte Berechtigungen/Rollen, Module, ggf. vorherige Anleitungen, die abgeschlossen sein müssen
4	Geltungsbereich	Für welche Abteilung/welchen Prozess gilt das? Ausnahmen?
5	Schritt-für-Schritt-Anleitung	Kernstück – siehe Kapitel 3
6	Sonderfälle / Hinweise	Häufige Fehler, Abweichungen, was tun bei Problem X
7	Ansprechpartner	Wer beantwortet Fragen zu diesem Ablauf?
8	Änderungshistorie	Datum, Autor, was wurde geändert (siehe Kapitel 7)

Vorlage zum Kopieren

# [Prozessname]

## Ziel
[1–2 Sätze]

## Voraussetzungen
- Berechtigung: …
- Modul: …

## Geltungsbereich
[…]

## Schritt-für-Schritt-Anleitung
### Schritt 1: [Kurzbezeichnung]
[Screenshot]
[Textbeschreibung]

### Schritt 2: [Kurzbezeichnung]
[Screenshot]
[Textbeschreibung]

## Hinweise / Sonderfälle
[…]

## Ansprechpartner
[Name/Abteilung]

## Änderungshistorie
| Datum | Autor | Änderung |
|-------|-------|----------|

3. Die Schritt-für-Schritt-Anleitung im Detail

Für jeden Schritt gilt derselbe Aufbau:

Überschrift des Schritts (z. B. „Schritt 3: Auftragskopf anlegen“)
Screenshot des relevanten Bildschirmausschnitts
Direkt darunter: Textbeschreibung zu genau diesem Screenshot

Wichtig: Ein Screenshot darf nur das zeigen, worüber der direkt darunterstehende Text spricht. Zeigt ein Screenshot mehrere Felder, aber der Text erklärt nur eines davon, ist das falsch aufgeteilt – dann entweder den Screenshot beschneiden oder den Schritt in zwei Schritte aufteilen.

Formulierung des Textes

Imperativ, aktive Sprache: „Klicken Sie auf …“, nicht „Man klickt auf …“ oder „Es sollte geklickt werden…“
Kurze Sätze, ein Gedanke pro Satz.
Feldnamen, Buttons und Menüpunkte exakt wie im System, fett markiert: Klicken Sie auf Neuer Auftrag.
Werte/Beispieleingaben in Anführungszeichen: Tragen Sie im Feld Auftragsart den Wert „STD“ ein.
Erklären Sie bei jedem Feld auch warum/was das bewirkt, wenn es nicht selbsterklärend ist – nicht nur „was einzutragen ist“.
Bei Auswahlmöglichkeiten (Dropdown, Checkbox) immer angeben, welche Option in welchem Fall zu wählen ist.

4. Screenshots: Format- und Bearbeitungsvorgaben

Tool: ShareX oder Greenshot (beide sind Standard und dürfen frei verwendet werden).

4.1 Bildausschnitt

Nur den relevanten Bereich des Bildschirms erfassen – nicht den ganzen Monitor, wenn nicht nötig.
Genug Kontext mitnehmen, damit der Nutzer sich orientieren kann (z. B. Reitername, Fensterüberschrift), aber nichts Überflüssiges.
Einheitliche Breite anstreben, damit alle Screenshots im Wiki gleich groß wirken (Richtwert: max. 900–1000 px Breite; Anwendungsfenster ggf. vorher passend skalieren).

4.2 Markierungen (Pfeile, Rahmen, Nummerierungen)

Damit Markierungen im gesamten Wiki einheitlich aussehen, gelten feste Farben und Formen:

Element	Verwendung	Darstellung
Roter Rahmen (Rechteck)	Hebt das Feld/den Bereich hervor, um den es im Text geht	Rot, Linienstärke 2–3 px, keine Füllung
Rote nummerierte Kreise	Wenn in einem Screenshot mehrere Klicks in Reihenfolge markiert werden müssen (z. B. bei einer kurzen Sequenz)	Rot gefüllt, weiße Zahl
Roter Pfeil	Zeigt auf einen Button/ein Icon	Rot, deutlich sichtbar
Schwarzer Balken (Schwärzung)	Verdeckt sensible/personenbezogene Daten (Kundennamen, Preise, Adressen)	Vollflächig schwarz, keine Unschärfe

→ Verboten: wechselnde Farben, Freihand-Kritzeleien, Text direkt ins Bild schreiben (Text gehört in den Wiki-Text, nicht ins Bild).

4.3 Sensible Daten

Test-/Echtdaten mit Kundenbezug, Preisen oder Personendaten werden immer geschwärzt, auch in internen Anleitungen.
Wenn möglich, mit Testdaten/Testmandant arbeiten statt mit Echtdaten.

4.4 Dateiformat und Benennung

Format: PNG (keine JPG-Kompressionsartefakte bei Text/UI-Screenshots).
Dateiname nach Schema: [system]_[prozess]_schritt-[nr].png
Beispiel: erp_auftragsanlage_schritt-03.png
Screenshots werden in der WordPress-Mediathek in einem Ordner/mit Tag je Prozess abgelegt, damit sie wiederauffindbar sind (falls die Mediathek-Struktur das zulässt, sonst zumindest konsequente Benennung).

5. Umsetzung in WordPress (Block-Editor)

Damit alle Anleitungen gleich aussehen, wird für jeden Schritt dieselbe Blockkombination verwendet:

Bild-Block (Screenshot einfügen, keine Bildunterschrift/Caption verwenden)
Direkt darunter ein Absatz-Block mit der Textbeschreibung
Für die Schritt-Überschrift einen Überschrift-Block (Ebene „Überschrift 3“) vor dem Bild

Nicht verwenden: Spalten-Blöcke mit Bild/Text nebeneinander – das widerspricht der Vorgabe „Screenshot oben, Text darunter“ und funktioniert auf schmalen Bildschirmen schlecht.

Kategorien/Tags: Jede Anleitung erhält mindestens die Kategorie des betroffenen Systems/Moduls (z. B. „ERP – Auftragsbearbeitung“ oder „CRM – Kontaktverwaltung“) und ggf. weitere Tags, damit die Suche im Wiki funktioniert.

Verlinkung: Wird in einem Schritt auf eine andere bestehende Anleitung verwiesen (z. B. „siehe Anleitung zur Artikelanlage“), wird das als Link auf die entsprechende Wiki-Seite eingefügt, nicht nur als Text erwähnt.

6. Namenskonvention für Titel

Schema: [System] – [Prozess in Substantivform]

Beispiele:

„ERP – Kundenauftrag anlegen“
„CRM – Kontakt anlegen“
„Intranet – Urlaubsantrag stellen“

Keine Fragen als Titel („Wie lege ich einen Auftrag an?“), keine internen Abkürzungen ohne Erklärung.

7. Versionierung, Review und Aktualität

Jede Anleitung enthält am Ende die Tabelle Änderungshistorie (Datum, Autor, kurze Beschreibung der Änderung).
Vor Veröffentlichung prüft eine zweite Person (nicht der Autor) die Anleitung anhand der Checkliste in Kapitel 8.
Ändert sich ein Prozess im jeweiligen System, muss die betroffene Anleitung zeitnah aktualisiert werden – veraltete Screenshots sind schlimmer als keine Anleitung, weil sie falsches Vertrauen erzeugen.

8. Checkliste vor Veröffentlichung

[ ] Titel folgt der Namenskonvention
[ ] Ziel/Kurzbeschreibung vorhanden
[ ] Voraussetzungen vollständig genannt
[ ] Jeder Schritt hat genau einen Screenshot mit Text darunter
[ ] Screenshots zeigen nur das, was im Text erklärt wird
[ ] Markierungen folgen der Farb-/Formkonvention (Kapitel 4.2)
[ ] Sensible Daten geschwärzt
[ ] Feldnamen/Buttons exakt wie im System benannt und fett hervorgehoben
[ ] Kein Fachjargon ohne Erklärung
[ ] Kategorie/Tags vergeben
[ ] Von einer zweiten Person gegengelesen
[ ] Änderungshistorie ausgefüllt

9. Beispiel (Muster-Ausschnitt)

So sieht ein korrekt aufgebauter Schritt in der fertigen Anleitung aus:

Schritt 2: Auftragsart auswählen

[Screenshot: Ausschnitt der Eingabemaske „Auftragskopf“, Feld „Auftragsart“ rot umrandet]

Wählen Sie im Feld Auftragsart den Eintrag „STD“ aus der Dropdown-Liste aus. Diese Einstellung legt fest, dass der Auftrag im Standard-Fertigungsprozess bearbeitet wird. Für Sonderfertigungen wählen Sie stattdessen „SON“ – sprechen Sie sich im Zweifel mit der Auftragsplanung ab.

Dieses Dokument ist selbst Teil des Wikis und wird nach demselben Verfahren (Kapitel 7) gepflegt.