| 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.