05. Verantwortlichkeiten

Lernziele

Nach diesem Kapitel können Sie: - Das AKV-Prinzip (Aufgaben, Kompetenzen, Verantwortung) anwenden - Die RACI-Matrix für Verantwortlichkeitszuordnung erstellen - Organisationsstrukturen für IT-Projekte gestalten - Typische Organisationsfehler identifizieren und vermeiden - Klare Verantwortungsstrukturen für Management-Entscheidungen definieren

Lesezeit

ca. 15-20 Minuten

1. Einführung: Warum Verantwortlichkeiten entscheidend sind

Unklare Zuständigkeiten sind ein Hauptgrund für das Scheitern von IT-Projekten. In der Praxis führen diffuse Verantwortlichkeiten zu Verzögerungen, Konflikten und letztlich zum Projekterfolg.

flowchart TD
    A[Unklare Verantwortlichkeiten] --> B[Verwirrung und Konflikte]
    A --> C[Verzögerungen und Wartezeiten]
    A --> D[Fehlentscheidungen]

    B --> E[Projektversagen]
    C --> E
    D --> E

    F[Klare Verantwortlichkeiten] --> G[Effiziente Entscheidungen]
    F --> H[Schnelle Problemlösung]
    F --> I[Verantwortungsbewusstes Handeln]

    G --> J[Projekterfolg]
    H --> J
    I --> J

    style E fill:#ffe1e1
    style J fill:#e1ffe1

1.1 Die Rolle des IT-Beraters bei Verantwortlichkeiten

Der IT-Berater ist oft derjenige, der: - Verantwortlichkeitsstrukturen analysiert und bewertet - RACI-Matrizen erstellt - Organisationslücken identifiziert - Empfehlungen für Rollen und Verantwortlichkeiten gibt

2. Das AKV-Prinzip

2.1 Grundkonzept

Das AKV-Prinzip fordert die Kongruenz (Deckungsgleichheit) von: - Aufgabe (Task) - Kompetenz (Authority) - Verantwortung (Responsibility)

graph TD
    A[AKV-Prinzip] --> B[Aufgabe: Was muss getan werden?]
    A --> C[Kompetenz: Welche Befugnisse hat die Person?]
    A --> D[Verantwortung: Wer muss für das Ergebnis gerade stehen?]

    B --> E{Kongruenz?}
    C --> E
    D --> E

    E -->|Ja| F[Effektive und effiziente Arbeit]
    E -->|Nein| G[Strukturelles Problem]

    G --> G1[K < V: Person verantwortlich, aber keine Befugnisse]
    G --> G2[V < A: Person hat Befugnisse, aber keine Verantwortung]
    G --> G3[A < K: Person hat Befugnisse, aber keine klare Aufgabe]

    G1 --> H[Handlungsunfähigkeit, Frustration]
    G2 --> I[Willkürliches Handeln, Kontrollverlust]
    G3 --> J[Missbrauch von Macht, Ineffizienz]

    style F fill:#e1ffe1
    style G fill:#ffe1e1

2.2 Die drei Konstellationen des AKV-Missverhältnisses

Konstellation	Beschreibung	Konsequenzen	Beispiel
K < V	Kompetenz kleiner als Verantwortung	Person verantwortlich, aber keine Entscheidungsmacht	Projektmanager für Budget, aber keine Genehmigungsbefugnis
V < A	Verantwortung kleiner als Aufgabe	Person hat Aufgaben, aber keine klare Verantwortung	Entwickler implementiert Features, aber nicht verantwortlich für Qualität
A < K	Aufgabe kleiner als Kompetenz	Person hat mehr Befugnisse als Aufgaben	Manager mit Entscheidungsbefugnis, aber keine klaren Aufgaben

2.3 Deep Dive: K < V (Kompetenz kleiner als Verantwortung)

Dies ist die häufigste Problemkonstellation in IT-Projekten.

Beispiel: Ein Projektleiter ist für das Einhalten des Budgets verantwortlich (V), hat aber keine Befugnis, Ressourcen zuzuweisen oder Budget freizugeben (K).

Konsequenzen: - Handlungsunfähigkeit: Der Projektleiter kann nicht reagieren, wenn Budget-Engpässe entstehen - Frustration: Der Projektleiter wird für Ergebnisse zur Rechenschaft gezogen, die er nicht steuern kann - Konflikte: Konflikte mit anderen Managern, die über Budget- und Ressourcenentscheidungen treffen

Lösungsansätze: 1. Kompetenzen erweitern: Dem Projektleiter Budget- und Personalentscheidungsbefugnisse geben 2. Verantwortung anpassen: Die Budgetverantwortung auf einen Finanzmanager übertragen 3. Klarstellung: Delegation und Eskalationswege dokumentieren

2.4 Deep Dive: V < A (Verantwortung kleiner als Aufgabe)

Beispiel: Ein Entwickler hat die Aufgabe, komplexe Features zu implementieren (A), ist aber nicht für die Qualität oder Fehlerbehebung verantwortlich (V).

Konsequenzen: - Qualitätsprobleme: Der Entwickler implementiert Features, aber keine Sorge um Qualitätstests - Fehlende Eigenverantwortung: Kein persönliches Commitment für Qualität - "Nicht mein Job"-Mentalität: Grenzenüberschreitung und Konflikte

Lösungsansätze: 1. Verantwortung erweitern: Qualitätsverantwortung in Entwickler-Rolle integrieren 2. Aufgaben anpassen: Klare Definition, dass Qualitätstests Aufgabe des Testers sind 3. Teamverantwortung: Teamverantwortung für Qualität statt individueller Verantwortung

2.5 Checkliste: AKV-Check für Rollen

Für jede Rolle in einem IT-Projekt sollten Sie prüfen:

Rolle	Aufgaben (A)	Kompetenzen (K)	Verantwortung (V)	Kongruenz?
Projektleiter	Projekt steuern, Ressourcen managen	Budget- und Personalentscheidungen	Projekterfolg, Termineinhaltung	K < V? → Problem
Entwickler	Code implementieren, Tests schreiben	Code-Schreibzugriff, Review-Rechte	Code-Qualität, Feature-Funktionalität	✓
Architekt	Architektur entwerfen, Entscheidungen treffen	Technologieentscheidungen, Standards definieren	Architektur-Qualität, Skalierbarkeit	✓
Tester	Tests ausführen, Fehler melden	Test-Umgebung, Test-Tools	Testabdeckung, Bug-Reporting	✓
Product Owner	Anforderungen definieren, Priorisieren	Sprint-Ziele definieren, Acceptance Criteria	Produkt-Erfolg, Stakeholder-Zufriedenheit	✓

3. Die RACI-Matrix

3.1 Grundkonzept

Die RACI-Matrix ist ein Standard zur prozessualen Zuordnung von Verantwortlichkeiten.

Rolle	Bedeutung	Erläuterung
R (Responsible)	Ausführender / Durchführender	Die Person, die die Arbeit tatsächlich ausführt ("Macher")
A (Accountable)	Rechenschaftspflichtiger	Die Person, die für das Ergebnis verantwortlich ist und der Rechenschaft schuldet ("Kopf")
C (Consulted)	Beratend	Experten, die beratend mitwirken, aber nicht Entscheidungsbefugt haben
I (Informed)	Informiert	Personen, die über Ergebnisse informiert werden müssen

Wichtige Regeln: - Jede Aufgabe muss genau ein A haben (nicht mehrere) - Eine Aufgabe kann mehrere R haben (mehrere Ausführende) - C und I können beliebig viele sein

3.2 RACI-Beispiel: Einführung eines CRM-Systems

Aufgaben und Rollen:

Aufgabe	C-Level	CFO	CIO	Projektleiter	Entwickler	Tester	Produktmanager	Sales-Director
Projekt genehmigen	A	C	C	R	-	-	C	C
Budget bereitstellen	-	A	C	C	-	-	-	-
Anforderungen definieren	-	-	-	C	-	-	A	C
Architektur entwerfen	-	-	A	C	R	-	C	I
Software implementieren	-	-	-	C	R	-	-	-
Tests ausführen	-	-	-	C	-	R	C	-
User-Acceptance	-	-	-	-	-	-	A	C
Go-Live Entscheidung	A	C	C	C	-	-	R	I

Legende: - A = Accountable (Rechenschaftspflichtig, genau 1 pro Aufgabe) - R = Responsible (Ausführend) - C = Consulted (Beratend) - I = Informed (Informiert)

3.3 Typische Fehler bei der RACI-Matrix

Fehler	Beschreibung	Konsequenz	Vermeidung
Mehrere As für eine Aufgabe	Zwei oder mehr Personen sind Accountable	Verantwortungsdiffusion, "Niemand ist verantwortlich"	Jede Aufgabe muss genau ein A haben
Kein A für eine Aufgabe	Niemand ist rechenschaftspflichtig	Fehlende klare Verantwortung	Sicherstellen, dass jede Aufgabe ein A hat
Alle R, kein A	Mehrere Ausführende, aber keine klare Verantwortung	Konflikte, unklare Entscheidungswege	A definieren
Zu viele C	Zu viele Personen werden beratend einbezogen	Verzögerungen, Over-Engineering	Nur echte Experten als C
Keine I	Keine Information der relevanten Stakeholder	Überraschungen, Konflikte	Alle betroffenen Personen als I

3.4 RACI vs. AKV

Aspekt	AKV-Prinzip	RACI-Matrix
Fokus	Rollen-Ebene (dauerhaft)	Aufgaben-Ebene (prozessspezifisch)
Anwendung	Organisationsstruktur	Projektmanagement, Prozesse
Ziel	Kongruenz von Aufgaben, Kompetenzen, Verantwortung	Klare Zuordnung von Verantwortlichkeiten
Komplementarität	Definiert Rollen und Befugnisse	Definiert Verantwortlichkeiten für Aufgaben

Beispiel:

AKV für die Rolle "Projektleiter": - Aufgabe: Projekt steuern, Ressourcen managen - Kompetenz: Budget- und Personalentscheidungen - Verantwortung: Projekterfolg

RACI für die Aufgabe "Projektplan erstellen": - A: Projektleiter - R: Projektleiter, Architekt, Entwickler - C: Stakeholder, Produktmanager - I: C-Level

4. Organisationsstrukturen für IT-Projekte

4.1 Funktionale Organisation

graph TD
    A[CEO] --> B[IT-Abteilung]
    A --> C[Marketing]
    A --> D[Vertrieb]

    B --> B1[Entwicklung]
    B --> B2[Operations]
    B --> B3[Security]

    B1 --> P[Projektteam<br/>aus verschiedenen Abteilungen]
    C --> P
    D --> P

Merkmale: - Stabile Struktur, klare Hierarchien - Fachliche Expertise stark ausgeprägt - Weniger Flexibilität bei Projektarbeit

Vor- und Nachteile:

Vorteile	Nachteile
Klare Karrierepfade	Silo-Denken
Hohe Fachexpertise	Langsame Entscheidungen
Skalierbar	Weniger flexibel

4.2 Projektorganisation

graph TD
    A[CEO] --> P1[Projektleiter 1<br/>CRM-Einführung]
    A --> P2[Projektleiter 2<br/>ERP-Migration]

    P1 --> T11[Team A<br/>Entwicklung]
    P1 --> T12[Team B<br/>Testing]
    P1 --> T13[Team C<br/>Operations]

    P2 --> T21[Team D<br/>Entwicklung]
    P2 --> T22[Team E<br/>Migration]

Merkmale: - Projektzentrierte Struktur - Projektleiter hat volle Autorität - Hohe Flexibilität

Vor- und Nachteile:

Vorteile	Nachteile
Schnelle Entscheidungen	Keine fachliche Heimat nach Projektende
Klare Verantwortlichkeiten	Weniger fachlicher Austausch zwischen Projekten
Fokus auf Projektziele	Risiko von "Not-invented-here"-Syndrom

4.3 Matrix-Organisation

graph LR
    subgraph Projekt
        P[Projektleiter]
    end

    subgraph Funktional
        L[Leitung Entwicklung]
    end

    P --> E[Entwickler]
    L --> E

    style P fill:#ffe1e1
    style L fill:#e1ffe1
    style E fill:#fff4e1

Merkmale: - Kombination aus funktionaler und projektbezogener Struktur - Zwei Vorgesetzte (Projektleiter und fachlicher Vorgesetzter) - Komplex, aber flexibel

Vor- und Nachteile:

Vorteile	Nachteile
Beste beide Welten	Komplex
Fachliche Expertise bleibt erhalten	Konflikt zwischen Projekt- und Fachzielen
Flexibilität	Machtgefüge unklar

4.4 Organisation für Management-Entscheidungen

Für strategische Entscheidungen sollte ein Projektsteuerausguss (Steering Committee) eingerichtet werden.

Typische Struktur:

Rolle	Verantwortung	Häufigkeit
C-Level (CEO, CFO, CIO)	Strategische Entscheidungen, Budget-Freigabe	Monatlich
Projektleiter	Projektstatus, Risiken, Entscheidungsbedarf	Monatlich
Fachbereichsleiter	Fachliche Anforderungen, Prioritäten	Monatlich
Produktmanager	Anforderungen, Marktbedürfnisse	Monatlich
Architekt	Technologieentscheidungen, Architektur-Review	Bei Bedarf

Entscheidungsprozess:

flowchart TD
    A[Entscheidungsbedarf] --> B[Vorbereitung durch Projektleiter]
    B --> C[Steering Committee Meeting]
    C --> D{Entscheidung?}
    D -->|Ja| E[Entscheidung dokumentieren]
    D -->|Nein| F[Analytie und Vertiefung]
    F --> C
    E --> G[Umsetzung durch Projektteam]

5. Praktische Beispiele

5.1 Beispiel 1: Software-Entwicklungsteam

Team-Struktur:

Rolle	Aufgaben	Kompetenzen	Verantwortung
Tech Lead	Technische Leitung, Code-Review	Technologieentscheidungen, Merge-Berechtigung	Architektur-Qualität, Team-Coaching
Senior Developer	Features implementieren, Mentoring	Code-Schreibzugriff, Review-Rechte	Code-Qualität, Feature-Funktionalität
Developer	Features implementieren	Code-Schreibzugriff	Code-Qualität (auf Teilebene)
QA Engineer	Tests ausführen, Bugs melden	Test-Umgebung, Bug-Tracking	Testabdeckung, Bug-Dokumentation

RACI-Matrix für Sprint:

Aufgabe	Tech Lead	Senior Dev	Developer	QA
Sprint Planning	A	R	R	C
Backlog Refinement	A	C	C	C
Development	C	R	R	-
Code Review	R	R	C	-
Testing	-	-	-	A
Sprint Review	A	R	R	R
Retrospective	A	R	R	R

5.2 Beispiel 2: Cloud-Migrationsprojekt

Organisationsstruktur:

graph TD
    A[Steering Committee<br/>CEO, CFO, CIO] --> B[Program Manager]
    B --> C[Projektleiter Migration]
    B --> D[Projektleiter Sicherheit]
    B --> E[Projektleiter Testing]

    C --> C1[Cloud-Architekten]
    C --> C2[DevOps-Engineer]
    C --> C3[Data-Engineer]

    D --> D1[Security-Architekt]
    D --> D2[Compliance-Officer]

    E --> E1[QA-Engineer]
    E --> E2[Performance-Tester]

RACI-Matrix für Cloud-Migration:

Aufgabe	Program Manager	Projektleiter Migration	Cloud-Architekt	Security-Architekt	QA
Migrationsstrategie definieren	A	C	R	C	-
Cloud-Architektur entwerfen	-	C	A	C	I
Security-Konzept erstellen	-	C	C	A	-
Migration durchführen	-	A	R	C	-
Tests ausführen	-	C	I	I	A
Go-Live Entscheidung	A	R	C	C	C

Schlüsselbegriffe

Begriff	Definition
AKV-Prinzip	Kongruenz von Aufgaben (A), Kompetenzen (K) und Verantwortung (V)
RACI-Matrix	Verantwortlichkeitszuordnung mit Responsible (R), Accountable (A), Consulted (C), Informed (I)
Kongruenz	Deckungsgleichheit von Aufgaben, Kompetenzen und Verantwortung
Verantwortungsdiffusion	Unklare Verantwortung durch mehrere accountable Personen
Steering Committee	Projektsteuerausguss für strategische Entscheidungen
Matrix-Organisation	Organisationsform mit funktionaler und projektbezogener Struktur
Silo-Denken	Isolierte Arbeitsweise ohne Zusammenarbeit zwischen Abteilungen
Machtgefüge	Verteilung von Macht und Entscheidungsbefugnissen in einer Organisation

Verständnisfragen

Frage 1: AKV-Prinzip

Ein Projektleiter ist für das Einhalten des Projektbudgets verantwortlich, hat aber keine Entscheidungsbefugnis für Budget- oder Personalentscheidungen. Analysieren Sie diese Situation nach dem AKV-Prinzip und geben Sie Lösungsvorschläge.

Lösung: AKV-Analyse:

Element	Beschreibung

**Ergebnis:** **K < V** (Kompetenz kleiner als Verantwortung)

**Konsequenzen:**
- **Handlungsunfähigkeit**: Der Projektleiter kann Budget-Engpässe nicht beheben, da er keine Entscheidungsbefugnis hat
- **Frustration**: Der Projektleiter wird für Ergebnisse zur Rechenschaft gezogen, die er nicht steuern kann
- **Konflikte**: Konflikte mit C-Level oder Department-Managern, die die Entscheidungen treffen
- **Risiko**: Budgetüberschreitungen oder Projekterfolg gefährdet

**Lösungsansätze:**

**Lösung 1: Kompetenzen erweitern (Empfohlen)**
- Dem Projektleiter Budget- und Personalentscheidungsbefugnis innerhalb definierter Grenzen geben
- Zum Beispiel: Entscheidungsfreiheit für bis zu 10% des Gesamtbudgets ohne weitere Genehmigung
- Budget-Freigabe-Prozess für größere Beträge dokumentieren

**Lösung 2: Verantwortung anpassen**
- Die Budgetverantwortung auf einen Finanzmanager oder C-Level übertragen
- Der Projektleiter ist dann nur für Zeitplanung und Ressourcenplanung verantwortlich, nicht für Budget-Freigabe

**Lösung 3: Klarstellung und Eskalation**
- Klare Dokumentation von Verantwortlichkeiten und Eskalationswegen
- Bei Budget-Engpässen: Eskalation an C-Level mit klarem Prozess
- Verantwortung für Budget-Planung (Schätzung) vs. Budget-Freigabe (Genehmigung) trennen

**Empfehlung:**
Lösung 1 ist die beste Option, da sie die Handlungsfähigkeit des Projektleiters sicherstellt und die Entscheidungswege verkürzt. Dies ist besonders wichtig in agilen Projekten, in denen schnelle Entscheidungen notwendig sind.

Frage 2: RACI-Matrix

In einem Projekt wird für die Aufgabe "Genehmigung des Architekturkonzepts" sowohl der CTO als auch der CIO als Accountable (A) in der RACI-Matrix eingetragen. Warum ist dies methodisch falsch und wie sollte es korrigiert werden?

Lösung: Methodischer Fehler:

Die RACI-Matrix erfordert, dass jede Aufgabe genau ein A (Accountable) hat. Das ist eine grundlegende Regel des RACI-Standards.

Probleme bei mehreren Accountables:

Problem	Beschreibung

**Korrekturmöglichkeiten:**

**Option 1: Klärung der Hierarchie**
- **A (Accountable)**: CTO (als technologischer Vorgesetzter)
- **R (Responsible)**: CIO (für Umsetzung und Operations)
- **C (Consulted)**: C-Level-Team
- **I (Informed)**: Architekt, Entwickler

**Begründung:** Der CTO ist für technologische Entscheidungen verantwortlich, der CIO für die Umsetzung und den Betrieb.

**Option 2: Aufgabenaufteilung**
- Aufgabe 1: "Technologie-Entscheidung" → A: CTO
- Aufgabe 2: "Budget-Freigabe" → A: CIO
- Aufgabe 3: "Genehmigung des Gesamtkonzepts" → A: CEO

**Begründung:** Die Gesamtaufgabe wird in Unter-Aufgaben aufgeteilt, für die jeweils ein Accountable existiert.

**Option 3: Escalation-Decision-Making**
- **A (Accountable)**: CEO (als letztes Entscheidungsgremium)
- **R (Responsible)**: CTO, CIO (für Empfehlung)
- **C (Consulted)**: Architekt, Fachbereichsleiter
- **I (Informed)**: Projektteam

**Begründung:** Bei strategisch kritischen Entscheidungen wird der CEO zum Accountable.

**Empfehlung:**

Für die Architektur-Entscheidung empfiehlt sich **Option 1**, da:
- Der CTO die fachliche Kompetenz für Architektur-Entscheidungen hat
- Der CIO für Umsetzung und Operations verantwortlich ist
- Die Hierarchie klar und verständlich ist

**Korrigierte RACI-Matrix:**

| Aufgabe | CEO | CTO | CIO | Architekt |
|---------|-----|-----|-----|-----------|

| Architektur-Entscheidung | - | A | R | R | | Budget-Freigabe | - | C | A | - | | Implementierung | - | C | A | R | | Go-Live Entscheidung | A | R | R | - |

**Lektion:**
Die RACI-Matrix muss mit strikter Einhaltung der Regel "Genau ein Accountable pro Aufgabe" erstellt werden. Dies ist eine grundlegende Methode, um Verantwortungsdiffusion zu vermeiden.

Frage 3: Organisationsstruktur

Ein mittelständisches Unternehmen möchte ein großes Digitalisierungsprojekt (Einführung eines ERP-Systems, CRM-System und Customer Portal) durchführen. Welche Organisationsstruktur (funktional, projektbezogen, matrix) empfehlen Sie und warum?

Lösung: Empfehlung: Matrix-Organisation mit Projektsteuerausguss (Steering Committee)

Begründung:

1. Projekttypus: - Großes, komplexes Projekt mit mehreren Teilsystemen - Hohe strategische Bedeutung für das Unternehmen - Dauer: 12-24 Monate - Beteiligung mehrerer Fachbereiche (IT, Vertrieb, Einkauf, Finanzwesen)

2. Vor- und Nachteile der Organisationsformen:

Organisationsform	Vor- & Nachteile	Eignung für dieses Projekt

| Funktionale Organisation | + Fachliche Expertise
+ Klare Hierarchien
- Silo-Denken
- Weniger flexibel | Nicht geeignet: Silo-Denken würde die Integration der Systeme behindern | | Projektbezogene Organisation | + Schnelle Entscheidungen
+ Klare Verantwortlichkeiten
- Keine fachliche Heimat nach Projektende
- Weniger fachlicher Austausch | Nicht ideal: Das Projekt ist zu lang und komplex für eine reine Projektorganisation. Die Gefahr von "Not-invented-here"-Syndrom ist hoch. | | Matrix-Organisation | + Beste beide Welten
+ Fachliche Expertise bleibt erhalten
+ Flexibel
- Komplex
- Konflikte zwischen Projekt- und Fachzielen | Ideal: Kombiniert die Vorteile von funktionaler und projektbezogener Struktur. |

**3. Empfohlene Matrix-Organisation:**

```mermaid
graph TD
    A[Steering Committee<br/>CEO, CFO, CIO, Vertriebsleiter, Einkaufsleiter] --> B[Program Manager<br/>Gesamtverantwortung für Digitalisierung]

    B --> C1[Projektleiter ERP]
    B --> C2[Projektleiter CRM]
    B --> C3[Projektleiter Customer Portal]

    subgraph Funktional
        D1[IT-Entwicklung]
        D2[Operations]
        D3[Security]
        D4[QA]
    end

    C1 --> D1
    C2 --> D1
    C3 --> D1
    C1 --> D2
    C2 --> D2
    C3 --> D2
```

**4. RACI-Matrix für Entscheidungen:**

| Aufgabe | Program Manager | Projektleiter ERP | Projektleiter CRM | Projektleiter Portal | Steering Committee |
|---------|----------------|-------------------|-------------------|---------------------|--------------------|
| **Strategie definieren** | R | C | C | C | **A** |
| **Budget genehmigen** | C | C | C | C | **A** |
| **Technologie-Auswahl** | C | R | R | R | **A** |
| **Projektsteuerung** | A | R | R | R | C |
| **Go-Live ERP** | C | **A** | I | I | C |
| **Go-Live CRM** | C | I | **A** | I | C |
| **Go-Live Portal** | C | I | I | **A** | C |

**5. Vorteile dieser Struktur:**

| Vorteil | Begründung |
|---------|------------|

| Strategische Ausrichtung | Steering Committee sichert Abstimmung mit Unternehmensstrategie | | Klare Verantwortlichkeiten | Program Manager für Gesamtkoordination, Projektleiter für Teilsysteme | | Fachliche Expertise | Fachabteilungen (IT, Vertrieb, Einkauf) sind eingebunden | | Flexibilität | Projektleiter können schnell auf Änderungen reagieren | | Integration | Gemeinsame Ziele fördern Zusammenarbeit zwischen Teilsystemen |

**6. Mitigationsstrategien für Nachteile:**

| Nachteil | Mitigation |
|----------|------------|

**Zusammenfassend:**

Für dieses große Digitalisierungsprojekt ist eine Matrix-Organisation mit einem Projektsteuerausguss (Steering Committee) die beste Wahl. Diese Struktur kombiniert die Vorteile von funktionaler Expertise und projektbezogener Fokus, ermöglicht schnelle Entscheidungen und stellt sicher, dass das Projekt strategisch ausgerichtet ist. Die Komplexität wird durch klare Verantwortlichkeiten (RACI) und einen Program Manager gemildert.