Zum Inhalt

8. Wissensquiz

Kapitel Übersicht

Kapitel 8/8 Bearbeitungszeit: ~15 Min Modul 10: Planung II

🎯 Quiz-Anleitung

Testen Sie Ihr Wissen aus diesem Modul mit 12 interaktiven Fragen. Klicken Sie auf die Fragen, um die Lösungen anzuzeigen.

📦 Abschnitt 1: Beschaffungsmanagement

Frage 1: Phasen des Beschaffungsprozesses

Ordnen Sie die folgenden Phasen des Beschaffungsprozesses in der korrekten Reihenfolge zu: 1. Marktanalyse 2. Vertragsverhandlung 3. Bedarfsermittlung 4. Vertragsmanagement 5. Lieferantensuche

Lösung: Die korrekte Reihenfolge ist: 3 → 1 → 5 → 2 → 4

  1. Bedarfsermittlung: Was wird genau benötigt?
  2. Marktanalyse: Welche Anbieter gibt es?
  3. Lieferantensuche: Auswahl des besten Anbieters
  4. Vertragsverhandlung: Bedingungen festlegen
  5. Vertragsmanagement: Überwachung und Steuerung
Frage 2: Qualitätsmerkmale der Leistungsbeschreibung

Eine Leistungsbeschreibung in der IT-Beschaffung muss drei zentrale Eigenschaften erfüllen, um vergleichbare Angebote zu gewährleisten. Nennen Sie diese drei Eigenschaften und erläutern Sie kurz deren Bedeutung.

Lösung: Die drei Eigenschaften sind:

  1. Eindeutig: Alle Bieter müssen die Anforderungen im gleichen Sinne verstehen. Keine vagen Formulierungen wie "gute Performance", sondern konkrete Kennzahlen (z.B. "Antwortzeit < 2 Sekunden").

  2. Erschöpfend: Alle relevanten Leistungen müssen enthalten sein. Fehlende Anforderungen führen später zu teuren Change Requests oder Nachträgen.

  3. Herstellerneutral: Keine bevorzugung oder Ausschließlich bestimmter Hersteller (z.B. "muss Oracle-Datenbank sein"). Dies ist Voraussetzung für einen fairen Wettbewerb gemäß Vergaberecht.

Frage 3: Vertragsformen und Risikoverteilung

Ordnen Sie die folgenden Vertragsformen der korrekten Risikoverteilung zu:

Vertragsform Risikoverteilung
Festpreis ?
Time & Material ?
Managed Service ?
Mischform ?

Lösung:

Vertragsform Risikoverteilung
Festpreis Risiko beim Auftragnehmer (Aufwandrisiko)
Time & Material Risiko beim Auftraggeber (Aufwandsrisiko)
Managed Service Risiko beim Auftragnehmer (Verfügbarkeitsrisiko)
Mischform Geteiltes Risiko (z.B. Basispreis + variabler Anteil)

Hinweis: Bei Festpreis entsteht das Risiko für den Auftragnehmer, wenn der Aufwand höher als kalkuliert ist. Bei Time & Material trägt der Auftraggeber das Risiko, da er für jeden gearbeiteten Aufwand zahlt.

🤔 Abschnitt 2: Make-or-Buy-Entscheidungen

Frage 4: Make-or-Buy-Kriterien

Ein Unternehmen steht vor der Entscheidung, ein Monitoring-Tool selbst zu entwickeln (Make) oder ein SaaS-Produkt zu lizensieren (Buy). Welche Kriterien sollten in eine Make-or-Buy-Analyse einbezogen werden? Nennen Sie mindestens vier.

Lösung: Relevante Kriterien sind:

  1. Kostenvergleich: Entwicklungskosten + Wartung (Make) vs. Lizenzgebühren (Buy). Auch Total Cost of Ownership (TCO) über 3-5 Jahre betrachten.

  2. Strategische Relevanz: Ist Monitoring ein Kernprozess mit strategischer Bedeutung (eher Make) oder eine Commodity-Funktion (eher Buy)?

  3. Time-to-Market: Wie schnell wird die Lösung benötigt? Eigenentwicklung dauert typischerweise 6-12 Monate, SaaS ist sofort verfügbar.

  4. Ressourcenverfügbarkeit: Verfügbar sind: Entwickler mit Monitoring-Erfahrung? Kapazitäten für langfristige Wartung?

  5. Flexibilität/Anpassbarkeit: SaaS ist standardisiert, Eigenentwicklung kann exakt auf Bedürfnisse zugeschnitten werden.

  6. Vendor-Lock-in: Wie stark wird man vom SaaS-Anbieter abhängig? Migrationspfade möglich?

Frage 5: Kosten-Unterscheidung

Unterscheiden Sie zwischen CAPEX (Capital Expenditure) und OPEX (Operating Expenditure) und ordnen Sie die folgenden Kostenpositionen zu:

a) Lizenzgebühr für ERP-Software (Einmalzahlung) b) Monatliche Cloud-Infrastruktur-Kosten c) Hardware-Einkauf (Server) d) Wartungsvertrag für Software

Lösung:

CAPEX (Investitionskosten): Einmalige oder langfristige Investitionen, die aktiviert und abgeschrieben werden. - a) Lizenzgebühr für ERP-Software (Einmalzahlung) - c) Hardware-Einkauf (Server)

OPEX (Betriebskosten): Laufende Ausgaben für den Betrieb. - b) Monatliche Cloud-Infrastruktur-Kosten - d) Wartungsvertrag für Software

Wirtschaftlicher Aspekt: OPEX (Cloud/SaaS) verbessert Cashflow und ist oft steuerlich sofort absetzbar. CAPEX bindet Kapital, aber bietet langfristige Besitzrechte.

📋 Abschnitt 3: Leistungsbeschreibung und Kriterien

Frage 6: A- und B-Kriterien

Bei der IT-Beschaffung werden A-Kriterien und B-Kriterien unterschieden. Erläutern Sie den Unterschied und geben Sie je ein Beispiel für ein CRM-Projekt.

Lösung:

A-Kriterien (Muss-Kriterien): - Nicht erfüllt = Ausschluss vom Verfahren (K.O.-Kriterium) - Binary: Entweder erfüllt oder nicht erfüllt - Beispiel CRM: "Die Lösung muss DSGVO-konform sein" oder "Die Lösung muss eine deutsche Oberfläche haben"

B-Kriterien (Bewertungskriterien): - Werden punktebasiert bewertet (z.B. 1-10 Punkte) - Fließende Skala für Vergleichbarkeit - Beispiel CRM: "Benutzerfreundlichkeit", "Integrationsfähigkeit", "Mobile App", "Preis-Leistungs-Verhältnis"

Häufiger Fehler

Widersprüche zwischen A-Kriterien und Leistungsbeschreibung sind rechtlich riskant und führen häufig zu Reklamationen und Nachträgen.

Frage 7: Leistungsbeschreibung vs. Kriterienkatalog

Was ist das Problem, wenn zwischen der Leistungsbeschreibung und dem Kriterienkatalog Widersprüche bestehen? Nennen Sie ein konkretes Beispiel.

Lösung: Das Problem ist Rechtssicherheit und Transparenz. Widersprüche führen zu Auslegungsproblemen, Nachträgen und potenziellen Rechtsstreitigkeiten.

Beispiel: - Leistungsbeschreibung: "Das System muss 99,9% Verfügbarkeit aufweisen" - Kriterienkatalog (B-Kriterium): "Verfügbarkeit von 99,5% erhält 5 Punkte, 99,9% erhält 10 Punkte"

Ein Bieter könnte argumentieren: "Ich habe das Kriterium erfüllt (5 Punkte), obwohl die Leistungsbeschreibung 99,9% fordert." Dies schafft Auslegungsspielraum für teure Change Requests.

🤝 Abschnitt 4: Lieferantenmanagement und SLA

Frage 8: Lieferantenbewertungsmethoden

Welche Methode eignet sich am besten, um verschiedene IT-Dienstleister objektiv zu vergleichen, wenn Kriterien wie "Innovationsfähigkeit", "Preis", "Referenzen" und "Service-Level" gewichtet werden sollen? Erläutern Sie das Vorgehen.

Lösung: Die Nutzwertanalyse (Scoring-Modell) ist die Methode der Wahl.

Vorgehen:

  1. Kriterien definieren: Relevante Kriterien festlegen (z.B. Preis, Funktionalität, Referenzen, Innovation, Service)

  2. Gewichtung zuweisen: Jedes Kriterium erhält eine Gewichtung (Summe = 100%)

  3. Preis: 25%
  4. Funktionalität: 30%
  5. Referenzen: 20%
  6. Innovation: 15%

  7. Service: 10%

  8. Bewertung: Jeder Anbieter wird pro Kriterium mit Punkten bewertet (z.B. 1-10)

  9. Berechnung: Gewichtung × Punkte = Punktwert pro Kriterium

  10. Gesamtwertung: Summe aller Punktwerte = Gesamtscore

Vorteil: Transparente, dokumentierte Entscheidung, die im Ernstfall vor Gericht oder intern standhält.

Frage 9: SLA-Komponenten

Ein Service Level Agreement (SLA) für eine Cloud-Datenbank soll abgeschlossen werden. Welche wesentlichen Komponenten muss das SLA enthalten?

Lösung: Ein professionelles SLA enthält mindestens:

  1. Service-Level-Indikatoren (SLIs): Messbare Kennzahlen
  2. Verfügbarkeit (z.B. 99,9%)
  3. Antwortzeit (z.B. < 100ms)

  4. Datendurchsatz (z.B. 10.000 req/min)

  5. Service-Level-Ziele (SLOs): Zielpunkte für die SLIs

  6. Monatliche Verfügbarkeit ≥ 99,9%

  7. 95te Perzentil der Antwortzeit < 100ms

  8. Konsequenzen bei Nichteinhaltung (SLA Breach):

  9. Gutschriften (z.B. 10% der monatlichen Gebühr bei 99,5-99,9% Verfügbarkeit)
  10. Service-Credits

  11. Vertragsstrafen (in begrenztem Umfang)

  12. Berichtswesen und Monitoring:

  13. Wie werden die Kennzahlen gemessen?
  14. Werden Dashboards zur Verfügung gestellt?

  15. In welchem Zeitraum werden Reports geliefert?

  16. Exclusions: Was ist nicht im SLA abgedeckt (z.B. Wartungsfenster, Force Majeure)?

🔄 Abschnitt 5: Claim vs. Change Management

Frage 10: Claim Management vs. Change Management

Ein IT-Projektpartner fordert zusätzliche Kosten für die Anpassung einer Schnittstelle, die ursprünglich nicht im Vertrag spezifiziert war. Handelt es sich hier um Change Management oder Claim Management? Begründen Sie Ihre Antwort.

Lösung: Dies ist ein klassischer Change Request im Rahmen des Change Management.

Begründung: - Die ursprüngliche Leistungsbeschreibung hat diese Anpassung nicht vorgesehen. - Es handelt sich um eine Änderung des Vertragsinhalts (Scope), nicht um eine Forderung aus einer Vertragsverletzung. - Der Kunde will etwas anderes als ursprünglich vereinbart, was eine Anpassung des Vertrags erfordert.

Claim Management wäre hingegen relevant, wenn: - Der Auftragnehmer gegen eine Vertragsklausel verstoßen hat (z.B. verspätete Lieferung) - Der Auftragnehmer Schadensersatz fordert, weil der Kunde eine Vertragspflicht verletzt hat (z.B. fehlende Mitwirkung) - Ansprüche aus bereits geschlossenen Verträgen durchgesetzt werden

Praxis-Hinweis

Viele Projekte verwenden "Change Request" als Sammelbegriff für alle Änderungen, auch wenn es rechtlich um Claim Management geht. Wichtig ist die korrekte Dokumentation und das Einhalten definierter Prozesse.

Frage 11: Claim Management Ziele

Was sind die zwei Hauptziele des Claim Managements in IT-Projekten?

Lösung: Die zwei Hauptziele sind:

  1. Durchsetzung eigener Ansprüche: Identifikation und Durchsetzung von Forderungen gegenüber dem Vertragspartner (z.B. Schadensersatz bei Verzug, Gutschriften bei Nichteinhaltung von SLAs)

  2. Abwehr unberechtigter Forderungen: Analyse und Abwehr von Ansprüchen des Vertragspartners (z.B. Ablehnung von Nachforderungen bei zweideutiger Leistungsbeschreibung)

Das übergeordnete Ziel ist die Transformation ungesicherter Ansprüche in rechtlich gesicherte Forderungen (oder die Abwehr unberechtigter Forderungen), um Budget und Zeitplan zu schützen.

🐟 Abschnitt 6: Ishikawa-Diagramm

Frage 12: Ishikawa 8M-Methode

Ein IT-Projekt leidet unter massiven Performance-Problemen bei einer neuen E-Commerce-Plattform. Ordnen Sie die folgenden Ursachen den korrekten 8M-Kategorien zu:

Ursachen: a) Entwickler unzureichend in Performance-Optimierung geschult b) Server-Hardware unzureichend dimensioniert c) CSV-Exporte mit 100.000+ Datensätzen d) Kein Performance-Testing im CI/CD-Pipeline e) Kein Monitoring für Datenbank-Abfragen f) Marktspitzen nicht antizipiert g) Budget-Cuts für Infrastruktur-Upgrade h) Kein Budget für Performance-Tools

Lösung:

Ursache 8M-Kategorie
a) Entwickler unzureichend in Performance-Optimierung geschult Mensch
b) Server-Hardware unzureichend dimensioniert Maschine
c) CSV-Exporte mit 100.000+ Datensätzen Material (Daten/Last)
d) Kein Performance-Testing im CI/CD-Pipeline Methode
e) Kein Monitoring für Datenbank-Abfragen Messung
f) Marktspitzen nicht antizipiert Mitwelt (Markt)
g) Budget-Cuts für Infrastruktur-Upgrade Management
h) Kein Budget für Performance-Tools Money (Geld)

Erkenntnis: Performance-Probleme sind selten monokausal. Die Ishikawa-Analyse zeigt, dass hier strukturelle Probleme (Management, Money), technische Defizite (Maschine, Methode) und fehlendes Know-how (Mensch) zusammenwirken.

Frage 13: Kombination Ishikawa + 5-Why

Sie haben mit dem Ishikawa-Diagramm folgende Hauptursache für ein Problem identifiziert: "Kein Performance-Testing im CI/CD-Pipeline". Führen Sie eine 5-Why-Analyse durch, um die tiefere Ursache zu finden.

Lösung: Eine mögliche 5-Why-Kette:

Warum kein Performance-Testing? - Because: Es wurde nie priorisiert und implementiert.

Warum nicht priorisiert? - Because: Das Projektteam war auf Funktionalität fokussiert.

Warum nur auf Funktionalität? - Because: Die Projektziele wurden vom Management definiert, ohne Performance-Anforderungen.

Warum keine Performance-Anforderungen in den Zielen? - Because: Der Projektmanager hatte keine Erfahrung mit Performance-Risiken bei ähnlichen Projekten.

Warum keine Erfahrung? - Because: Es gibt kein Knowledge-Sharing-System für Lessons Learned im Unternehmen.

Root Cause: Fehlendes Wissensmanagement und Erfahrungsaustausch im Unternehmen.

Wert der Kombination

Das Ishikawa-Diagramm identifiziert die symptomatische Ursache, die 5-Why-Analyse deckt die strukturelle Wurzel auf. Ohne die Kombination würden Sie nur das Symptom (kein Testing) behandeln, nicht das Ursachenproblem (fehlendes Wissensmanagement).

📊 Quiz-Ergebnis

Sie haben das Quiz abgeschlossen!

Punktbereich Bewertung
11-12 Punkte 🏆 Exzellent – Sie haben das Modul vollständig verstanden
8-10 Punkte ✅ Gut – Solides Wissen, geringe Lücken
6-7 Punkte ⚠️ Akzeptabel – Wiederholung empfohlen
< 6 Punkte ❌ Verbesserungsbedarf – Modul erneut durcharbeiten

🎯 Abschluss-Checkliste

Überprüfen Sie, ob Sie die folgenden Kernkonzepte verstanden haben:

✅ Beschaffungsprozess
  ✅ 5 Phasen von der Bedarfsermittlung bis zum Vertragsmanagement
  ✅ EVB-IT als rechtssichere Basis

✅ Make-or-Buy
  ✅ Strategische Kriterien (Kosten, Kernprozess, Time-to-Market)
  ✅ CAPEX vs. OPEX-Unterscheidung

✅ Leistungsbeschreibung
  ✅ Eindeutig, erschöpfend, herstellerneutral
  ✅ A-Kriterien vs. B-Kriterien

✅ Lieferantenmanagement
  ✅ Nutzwertanalyse zur objektiven Bewertung
  ✅ SLA-Komponenten (SLI, SLO, Konsequenzen)

✅ Claim vs. Change Management
  ✅ Change = Änderung des Scopes
  ✅ Claim = Durchsetzung/Abwehr von Forderungen

✅ Ishikawa-Diagramm
  ✅ 8M-Kategorien (Mensch, Maschine, Material, Methode, Messung, Mitwelt, Management, Money)
  ✅ Kombination mit 5-Why und Pareto-Analyse

🚀 Weiterführende Ressourcen

  • ITIL V4 - Supplier Management: https://www.axelos.com/itil
  • EVB-IT Dokumentation: https://www.cosmit.de/evb-it/
  • Kaoru Ishikawa - Guide to Quality Control: Klassiker zur Ursachenanalyse
  • 5-Why-Methode: Toyota Production System

🎓 Nächstes Modul

Herzlichen Glückwunsch zum Abschluss von Modul 10: Planung II!

Im nächsten Modul erfahren Sie mehr über Modul 11: Risiko- und Qualitätsmanagement.

Modul-Übersicht

Das nächste Modul behandelt: - Risikomanagement-Methoden (FMEA, Risikomatrix) - Qualitätsmanagement (ISO 9001, Six Sigma) - Testmanagement und Teststrategien - Stakeholder-Management

Viel Erfolg beim weiterführenden Lernen! 🎓