OAllgemein

Operating Model (Target Operating Model, TOM)

Zielbild für Organisation, Prozesse, Rollen und Tools im Betrieb.

Ein Operating Model (auch Target Operating Model, TOM) ist das Zielbild dafür, wie ein Unternehmen im Alltag arbeitet: welche Prozesse wie ablaufen, wer wofür verantwortlich ist, welche Rollen und Fähigkeiten gebraucht werden und welche Systeme/Tools das Ganze unterstützen. Es übersetzt Strategie in eine konkrete, betreibbare Organisation – besonders wichtig bei Digitalisierung und IT-Veränderungen.

Was bedeutet „Target Operating Model (TOM)“?

„Target“ heißt: der angestrebte, zukünftige Zustand. Ein TOM beschreibt also nicht nur, wie es heute läuft, sondern wie es in 6–24 Monaten laufen soll, damit Ziele wie Skalierung, bessere Kundenprozesse, mehr Automatisierung oder höhere IT-Sicherheit tatsächlich erreichbar werden.

Wie funktioniert ein Operating Model in der Praxis?

Ein TOM wird meist als Set klarer Bausteine definiert, die zusammenpassen müssen. Typische Schritte sind:

  • 1) Ziele & Leitplanken festlegen: z. B. „Kundenanfragen in 24h beantworten“, „Standardprozesse automatisieren“, „Cloud-first, aber DSGVO-konform“.
  • 2) Kernprozesse designen: End-to-End (z. B. Lead → Angebot → Auftrag → Abrechnung → Support) statt Abteilungs-Silos.
  • 3) Rollen & Verantwortlichkeiten definieren: z. B. Process Owner, System Owner, Data Owner, IT-Security-Verantwortliche; inkl. RACI (Responsible/Accountable/Consulted/Informed).
  • 4) Organisation & Zusammenarbeit beschreiben: z. B. zentraler vs. dezentraler IT-Support, Governance-Gremien, Entscheidungswege.
  • 5) Tool- & Datenlandschaft ausrichten: Welche Systeme sind „System of Record“, wie fließen Daten, welche Integrationen sind nötig (inkl. Automatisierung).

Warum ist ein Operating Model für kleine Unternehmen wichtig?

Viele Digitalisierungsprojekte scheitern nicht an der Software, sondern daran, dass Prozesse, Rollen und Entscheidungen nicht mitwachsen. Ein TOM schafft Klarheit: Wer entscheidet über Tool-Auswahl? Wer pflegt Stammdaten? Wie wird Support organisiert? So vermeiden Sie Insellösungen, Schatten-IT und teure Reibungsverluste.

Beispiele (typisch für Digitalisierung)

  • Einführung eines CRM: TOM legt fest, wie Leads qualifiziert werden, wer Datenqualität verantwortet und welche Reports verbindlich sind.
  • KI im Kundensupport: TOM definiert, welche Anfragen automatisiert werden, wo Human-in-the-Loop greift und welche Regeln zu Datenschutz gelten (siehe Datenschutz (DSGVO/GDPR) & KI).
  • Automatisierte Workflows: Wenn Sie z. B. Automatisierung (Automation) oder Tools wie n8n nutzen, muss klar sein, wer Workflows baut, testet, überwacht und Änderungen freigibt.

Was gehört typischerweise in ein TOM (Bausteine)?

  • Prozesse: End-to-End Prozesslandkarte, Standards, Ausnahmen, KPIs.
  • Organisation: Teams, Schnittstellen, Entscheidungswege, Eskalationen.
  • Rollen & Skills: Verantwortlichkeiten, Kapazitäten, benötigte Kompetenzen.
  • Technologie & Tools: Applikationslandkarte, Integrationen, Betrieb/Support.
  • Daten & Governance: Datenverantwortung, Zugriffsrechte, Qualitätsregeln.
  • Service Management: Support-Modell, SLAs/SLOs (siehe SLA & SLO (Service Level Objectives)).

Was kostet ein Operating Model?

Die Kosten hängen stark von Umfang und Reifegrad ab. Für kleine Unternehmen reicht oft ein pragmatisches TOM als „Lean Blueprint“ (Workshops + Dokumentation + Umsetzungsplan) – teurer wird es, wenn parallel Prozesse neu designt, Systeme integriert und Rollen neu aufgebaut werden. Wichtig: Ein TOM ist kein Papierprojekt, sondern sollte direkt in Roadmap, Verantwortlichkeiten und KPIs münden.