Organigramm

Über Organigramme

Ein Organigramm (Organisationsdiagramm) bildet die formale Berichtsstruktur einer Organisation ab — wer wen leitet, welche Teams unter welchen Führungskräften sitzen und wo offene Stellen und externe Berater eingeordnet sind. HR-Teams greifen bei der Personalplanung darauf zurück; Gründer verwenden sie vor Vorstandstreffen; Betriebsleiter verteilen sie bei Umstrukturierungen. Anders als ein generisches Flussdiagramm behandelt ein Organigramm Personen (und Positionen) als primäre Entitäten, wobei die Hierarchie durch Einrückung oder explizite Kanten kodiert wird.

Schematex folgt allgemeinen Organigramm-Konventionen mit Erweiterungen für offene/unbesetzte Stellen, Matrix-(gestrichelte Linie-)Berichterstattung und Assistenzbeziehungen. Es gibt keinen einzigen ISO-Standard für Organigramme; die hier implementierten Konventionen stammen aus der HR-Praxis und den Normen der Softwarebranche. Den maßgeblichen akademischen Hintergrund finden Sie bei Fayol (1916) und dem Wikipedia-Artikel über Organigramme.

1. Ihr erstes Organigramm

Das kleinste sinnvolle Organigramm: eine dreistufige Hierarchie mit einer offenen Stelle.

Vier Regeln decken 80 % der Anwendungsfälle ab:

1. Mit dem Schlüsselwort orgchart beginnen, optional gefolgt von einem zitierten Titel.
2. Jede Person ist ein Knoten — id: "Name" | "Titel" | "Abteilung" [Eigenschaften]. Das | trennt Name-, Titel- und Abteilungsfelder.
3. Einrückung bestimmt die Hierarchie — jede zusätzliche zwei (oder mehr) Leerzeichen verschieben einen Knoten eine Ebene tiefer unter den nächsthöheren weniger eingerückten Knoten darüber.
4. Offene Stellen mit open id: oder draft id:, externe Berater mit advisor id: deklarieren.

Kommentare müssen mit # in einer eigenen Zeile beginnen (inline nachgestelltes // wird ebenfalls entfernt).

2. Knoten

Eine Knotenzeile hat die Form [kind] id: fields [props]. Die id muss [A-Za-z][A-Za-z0-9_-]* entsprechen.

2.1 Felder (durch Pipe getrennt)

Der Teil nach dem : und vor dem optionalen [props]-Block wird durch | geteilt:

alice: "Alice Zhang"                                # nur Name
alice: "Alice Zhang" | "VP Engineering"             # Name + Titel
alice: "Alice Zhang" | "VP Eng" | "Platform"        # Name + Titel + Abteilung
alice: "Alice Zhang" | "VP Eng" | "Platform" | "x@co.com"  # + Info-Zeile

2.2 Knotenarten

Das optionale Art-Schlüsselwort vor der ID ändert das Rendering des Knotens:

2.3 Knoteneigenschaften

Eigenschaften kommen in [Schlüssel: Wert, …] am Ende einer Knotenzeile.

Rollen-Icons — der role:-Wert wird zu einem Anzeige-Icon aufgelöst. Akzeptierte Schlüsselwörter (Groß-/Kleinschreibung ignoriert):

3. Hierarchie

Die Hierarchie wird durch Einrückung ausgedrückt — das häufigste Muster. Jeder Knoten wird zum Kind des nächsthöheren Knotens darüber, der einen kleineren Einzug hat. Tabs werden als zwei Leerzeichen behandelt.

ceo: "CEO"
  cto: "CTO"           # Kind von ceo (Einzug 2)
    eng: "Engineer"    # Kind von cto (Einzug 4)
  cfo: "CFO"           # Kind von ceo (Einzug 2, gleiche Ebene wie cto)

Alternativ kann die Eigenschaft reports: verwendet werden, um ein Elternteil unabhängig von der Einrückung explizit zu setzen:

orgchart "Flat file"
ceo: "CEO"
cto: "CTO" [reports: ceo]
eng: "Engineer" [reports: cto]

4. Kanten

Es gibt zwei Arten von Kanten. Die meisten Berichtslinien entstehen automatisch aus der Einrückungshierarchie. Sie können sie auch explizit schreiben — oder Matrix-(gestrichelte) Linien hinzufügen.

Explizite Kanten erfordern, dass beide Knoten-IDs bereits deklariert sind. Eine explizit erstellte report-Kante wird nicht dupliziert, wenn dieselbe Beziehung bereits durch Einrückung impliziert wird.

Kanten-Beschriftungen werden unterstützt:

pm1 -.-> design [label: "product partnership"]

5. Konfiguration

config:-Zeilen passen Layout und Ausrichtung an. Jede kommt auf eine eigene Zeile.

Layout-Hinweise:

• tree — standardmäßiger hierarchischer Baum mit verzweigenden Verbindungen. Am besten für die meisten Organigramme.
• list / directory / compact — kompakte eingerückte Verzeichnisansicht. Gut für große Personallisten, bei denen die Baumverzweigung unhandlich wird.

Baum-Layout (Standard) — Avatar-Karten mit verzweigenden Verbindungen und abteilungsbasierter Farbkodierung. Am besten für Teams bis ca. 30 Personen.

Listen-Layout — kompakte Verzeichniszeilen mit Einzugsführungen. Am besten für große Teams, bei denen die Baumverzweigung unhandlich wird.

6. Bezeichnungen & Kommentare

• Titel: orgchart "Acme Corp" — nur in der ersten Zeile.
• Namensfeld: erstes durch Pipe getrenntes Feld nach dem Doppelpunkt; kann mit ("Alice Zhang") oder ohne (Alice) Anführungszeichen sein.
• Titel-/Abteilungsfelder: zweites und drittes durch Pipe getrennte Felder.
• Info-Zeile: viertes durch Pipe getrenntes Feld, oder über note:, email:, phone: oder location:-Eigenschaften gesetzt. Der erste gefundene Wert gewinnt.
• Kommentare: # am Anfang einer Zeile (nach führendem Leerzeichen). Inline-// wird ebenfalls entfernt.

7. Reservierte Wörter & Escaping

Am Zeilenanfang reserviert: orgchart (Header), config:, role, open, draft, tbh, advisor, external.

Reservierte Operator-Token — vermeiden Sie diese Sequenzen in IDs: ->, .->

ID-Regeln: muss [A-Za-z][A-Za-z0-9_-]* entsprechen. Namen mit Leerzeichen kommen in das zitierte Namensfeld, nicht in die ID.

Zeichenketten mit Leerzeichen in Eigenschaftswerten (z. B. department: "Platform Eng") müssen doppelt in Anführungszeichen stehen.

8. Häufige Fehler

9. Grammatik (EBNF)

document       = header (blank | comment | config | edge | node)*

header         = "orgchart" ( WS quoted-string )? NEWLINE
quoted-string  = '"' any-char-but-quote* '"'

config         = "config" WS ":" WS key WS "=" WS value NEWLINE
key            = "direction" | "layout"

node           = INDENT* kind? id ":" WS fields ( "[" node-attrs "]" )? NEWLINE
kind           = "role" | "open" | "draft" | "tbh" | "advisor" | "external" | "person"
fields         = field ( "|" field )*
field          = quoted-string | unquoted-text
node-attrs     = node-attr ("," node-attr)*
node-attr      = "role:" role-keyword
               | "icon:" role-keyword
               | "department:" text
               | "status:" ( "new" | "leaving" | "on-leave" )
               | "avatar-color:" quoted-hex
               | "gender:" ( "male" | "female" )
               | "note:" text
               | "email:" text
               | "phone:" text
               | "location:" text
               | "assistant-of:" id
               | "matrix:" id-list
               | "reports:" id
               | bare-flag

bare-flag      = "open" | "draft" | "tbh" | "external"

edge           = id WS edge-op WS id ( "[" edge-attrs "]" )? NEWLINE
edge-op        = "->" | ".->"  // -.-> for matrix
edge-attrs     = "label:" quoted-string

id             = [A-Za-z] [A-Za-z0-9_-]*
comment        = ( "#" | "//" ) any NEWLINE

Maßgebliche Quelle: src/diagrams/orgchart/parser.ts. Falls dies vom Parser abweicht, gewinnt der Parser — bitte öffnen Sie ein Issue.

10. Roadmap

Geplant — noch nicht parsebar. Verwenden Sie diese heute nicht in generiertem DSL; der Parser wird sie ablehnen oder ignorieren.

• assistant-of: visuelles Rendering — die Eigenschaft wird geparst und im AST gespeichert, aber der Renderer zeichnet noch nicht den Assistenten-Ellenbogen-Verbinder.
• Config coloring — abteilungsbasierte Farbthemen (coloring: department).
• Config compact-Größenstufen — explizite Karten-Größensteuerung (size: small | medium | large).
• span:-Knotenbreite — Aufspannen eines Knotens über mehrere Geschwisterspalten im Baum-Layout.
• Foto / Avatar-URL — avatar: "https://…", um ein echtes Profilfoto anzuzeigen.
• Export in HRIS-Formate — strukturierte JSON/CSV-Ausgabe neben dem SVG.

Verfolgen Sie die GitHub-Issues, wenn Sie eines davon früher benötigen.

Verwandte Beispiele

Sofort einsetzbare Szenarien aus der Beispielgalerie: