Systemlösungen konzipieren

Bevor man auch nur einen Server kauft, eine VM startet oder einen Container deployt, kommt eine viel wichtigere Phase: die Konzeption. Hier wird festgelegt, was eigentlich gebaut werden soll, warum, für wen und in welchem Rahmen. Wer diese Phase übergeht und gleich in die Umsetzung springt, baut die Lösung am Bedarf vorbei – ein Lieblings-IHK-Aufgabentyp ist dann das Szenario „Kunde unzufrieden mit Ergebnis, was hätte besser gemacht werden müssen?". Die Antwort lautet immer: saubere Konzeption am Anfang. Diese Lektion zeigt dir die fünf Phasen des Konzeptions-Prozesses und die wichtigsten Werkzeuge: Anforderungsanalyse, Lasten-/Pflichtenheft, Lösungsvarianten und Bewertungsmatrix.

1) Die fünf Konzeptionsphasen

Eine vollständige Konzeption durchläuft fünf Phasen in fester Reihenfolge. Jede Phase liefert konkrete Ergebnisse, auf denen die nächste aufbaut. Klick durch:

Konzeptionsphasen – Klick eine Phase

Anforderungsanalyse

Was braucht der Kunde wirklich? Workshops, Interviews, Beobachtung.

Ist-Analyse

Was steht bereits? Inventar bestehender Systeme, Verträge, Prozesse.

Soll-Konzept

Wie soll der Zielzustand aussehen? Lastenheft formulieren.

Lösungsvarianten

Mindestens 2–3 Alternativen erarbeiten, technisch und wirtschaftlich.

Bewertung & Entscheidung

Nutzwertanalyse, Empfehlung, Freigabe durch Auftraggeber.

Die Phasen sind iterativ: Manchmal zeigt die Ist-Analyse, dass die Anforderungen unvollständig waren – dann geht es zurück zu Phase 1. Erst wenn Phase 5 abgeschlossen und vom Auftraggeber freigegeben ist, beginnt die Umsetzung. Wer hier abkürzt, riskiert ein Projekt, das in der Mitte komplett umgeplant werden muss. Mehr in Projektauftrag, Phasen und Meilensteine.

2) Funktionale vs. nicht-funktionale Anforderungen

Ein häufiger Stolperstein in der IHK-Prüfung: der Unterschied zwischen funktionalen und nicht-funktionalen Anforderungen. Beide gehören in jedes ordentliche Lastenheft – aber sie beschreiben unterschiedliche Aspekte:

Typ	Frage	Beispiele
Funktionale Anforderung	Was soll das System tun?	„System soll Rechnungen als PDF exportieren", „Login mit Benutzername und Passwort"
Nicht-funktional (Qualitätsanforderung)	Wie soll das System sein?	„Antwortzeit < 500 ms bei 100 parallelen Nutzern", „99,9 % Verfügbarkeit", „DSGVO-konform"

Nicht-funktionale Anforderungen sind oft die schwierigeren. „System soll schnell sein" ist keine messbare Anforderung – „System soll Rechnungs-PDFs in unter 2 Sekunden erzeugen, bei 50 gleichzeitigen Nutzern" schon. Die Norm ISO 25010 definiert acht Qualitätsmerkmale, die typische nicht-funktionale Anforderungen abdecken: Funktionalität, Effizienz, Kompatibilität, Benutzbarkeit, Zuverlässigkeit, Sicherheit, Wartbarkeit, Portabilität. Mehr in Was ist Qualität? ISO 25010.

3) Lastenheft und Pflichtenheft – das wichtigste Duo

Das Lasten- und das Pflichtenheft sind die zentralen Dokumente jeder Systemkonzeption. Sie werden oft verwechselt, sind aber grundverschieden:

Lastenheft vs. Pflichtenheft

Lastenheft

Vom Auftraggeber → Beschreibt das WAS

Beschreibt Ziele und Anforderungen aus Kundensicht
„Wir brauchen ein System, das X kann"
Funktionale + nicht-funktionale Anforderungen
Mengengerüst, Termine, Rahmen
Lässt offen, WIE die Lösung aussieht
Basis für Ausschreibung / Angebotsvergleich

Pflichtenheft

Vom Auftragnehmer → Beschreibt das WIE

Antwort auf das Lastenheft
„So werden wir das umsetzen"
Konkrete technische Lösung
Architektur, Komponenten, Schnittstellen
Test- und Abnahmekriterien
Verbindlich – wird Vertragsbestandteil

Eselbrücke: Lastenheft = vom Auftraggeber (der die Lasten trägt), Pflichtenheft = vom Auftragnehmer (der die Pflicht hat, es umzusetzen). In agilen Projekten werden beide Dokumente oft durch User Stories und Product-Backlog ersetzt – das Grundkonzept (Was vom Kunden, Wie vom Team) bleibt aber gleich. Mehr in Lastenheft & Pflichtenheft.

4) Lösungsvarianten erarbeiten

Eine häufige Schwäche schlechter Konzepte: Es wird nur eine Lösung präsentiert. Damit nimmt man dem Auftraggeber die Wahl und der Lösungsraum bleibt ungeprüft. Beste Praxis: mindestens drei Varianten, jede mit klaren Eigenschaften:

Variante A – „Minimum Viable": Kleinste, schnellste, günstigste Lösung. Erfüllt die Kernanforderungen, verzichtet auf alles Nicht-Essentielle.
Variante B – „Standard": Solide Lösung mit allen Anforderungen plus übliche Best Practices (Monitoring, Backup, Hochverfügbarkeit).
Variante C – „Premium / Future-Proof": Anspruchsvolle Lösung, die auch zukünftige Anforderungen abdeckt. Skalierbar, modern, teurer.

Beispiel: Ein Mittelständler braucht ein neues ERP-System. Variante A wäre „eigene SQL-Datenbank auf vorhandenem Server, simple Web-Oberfläche". Variante B wäre „Microsoft Dynamics 365 als SaaS". Variante C wäre „SAP S/4HANA on-prem oder bei einem Hoster". Jede Variante hat unterschiedliche Kosten, Risiken und langfristige Implikationen – die der Auftraggeber dann bewusst abwägen kann.

5) Bewertungsmatrix – Live-Beispiel

Wenn die Varianten stehen, müssen sie bewertet werden. Klassisches Werkzeug: die Nutzwertanalyse mit gewichteten Kriterien. Probier es interaktiv mit drei Beispiel-Varianten für ein ERP-Projekt:

Nutzwertanalyse – Bewertung Live

Kriterium	Gewicht (%)	A: Eigenbau	B: SaaS	C: SAP
Anschaffungskosten	25	9	7	2
Funktionsumfang	20	4	7	10
Implementierungsdauer	15	6	9	3
Zukunftssicherheit	20	3	7	9
Datenschutz (DSGVO)	20	8	6	9

Die Methode: Jedes Kriterium bekommt eine Gewichtung (Summe = 100). Jede Variante wird pro Kriterium von 1–10 bewertet. Endpunkte = Σ (Gewicht × Bewertung) / 100. Wichtig: Die Bewertung muss begründet sein – nicht aus dem Bauch heraus. Bei harten Zahlen (Kosten, Dauer) hilft Recherche, bei weichen (Zukunftssicherheit, Akzeptanz) Experten-Einschätzung. Mehr in Nutzwertanalyse.

6) Stakeholder einbinden – wer entscheidet mit?

Eine technisch perfekte Lösung scheitert oft daran, dass die falschen Leute eingebunden waren – oder zu spät. Wichtige Stakeholder-Gruppen, die in der Konzeption mitreden müssen:

Auftraggeber / Geschäftsführung: Entscheidet über Budget und Strategie. Will klare Empfehlung mit Begründung, keine technischen Details.
Fachabteilungen / Endanwender: Wissen, was im Alltag funktionieren muss. Wer sie nicht fragt, baut am Bedarf vorbei.
IT-Operations: Müssen die Lösung später betreiben. Haben gewichtige Einwände zu Monitoring, Backup, Patch-Management.
Betriebsrat: Bei mitbestimmungspflichtigen Themen (Mitarbeiterüberwachung, Datenschutz) zwingend zu beteiligen.
Datenschutzbeauftragter: Pflicht bei jeder Verarbeitung personenbezogener Daten – siehe DSB & VVT.
IT-Sicherheit: Prüft Konzept gegen Sicherheitsanforderungen und BSI-Grundschutz.
Einkauf: Zuständig für Vertragsverhandlungen, Lizenzen, Lieferanten.

Wichtig: Frühzeitig einbinden. Wer den Betriebsrat erst kurz vor Rollout informiert, hat den Rollout um Monate verzögert. Wer den DSB erst nach Vertragsabschluss konsultiert, muss möglicherweise alles neu verhandeln. Mehr in Beratungsgespräch strukturieren.

7) Konzept-Dokumentation – das schriftliche Ergebnis

Am Ende der Konzeption steht ein Dokument, das alle Entscheidungen nachvollziehbar festhält. Es ist Grundlage für die Umsetzung und für spätere Change-Diskussionen. Übliche Struktur:

Management Summary: Eine Seite, die das Wichtigste enthält – für die Geschäftsführung.
Ausgangssituation: Warum wurde das Projekt angestoßen? Welche Probleme soll es lösen?
Anforderungen: Funktional und nicht-funktional, priorisiert nach „muss / soll / kann".
Ist-Zustand: Was steht bereits, welche Abhängigkeiten gibt es?
Lösungsvarianten: Alle untersuchten Optionen, mit Vor-/Nachteilen.
Bewertung und Empfehlung: Nutzwertanalyse, klare Empfehlung mit Begründung.
Grobplanung: Phasen, Meilensteine, Aufwandsschätzung, Risiken.
Wirtschaftlichkeit: Kosten, Nutzen, ROI, TCO.
Anhänge: Detail-Diagramme, Quellen, Kalkulationen.

Dieses Dokument wird formell vom Auftraggeber freigegeben („Konzept-Approval"). Erst dann beginnt die Umsetzung. Wer das überspringt, riskiert Streit über „Aber wir wollten doch eigentlich…" Monate später. Mehr zur Doku in Warum IT-Dokumentation? und Aufbau der Projektdokumentation.

Zusammenfassung

Die Konzeption einer Systemlösung folgt fünf Phasen: Anforderungsanalyse → Ist-Analyse → Soll-Konzept → Lösungsvarianten → Bewertung & Entscheidung. Anforderungen werden in funktionale (was das System tut) und nicht-funktionale (wie es sein soll, z. B. Performance, Sicherheit, Verfügbarkeit) unterteilt. Zentrale Dokumente: Lastenheft vom Auftraggeber (das WAS), Pflichtenheft vom Auftragnehmer (das WIE) – Pflichtenheft wird Vertragsbestandteil. Mindestens 2–3 Lösungsvarianten erarbeiten, mit Nutzwertanalyse bewerten (gewichtete Kriterien × Bewertung). Wichtige Stakeholder früh einbinden: Geschäftsführung, Endanwender, IT-Ops, Betriebsrat, DSB, IT-Sicherheit, Einkauf. Ergebnis: ein Konzept-Dokument als Grundlage und formell freigegebene Basis für die Umsetzung. Wer diese Phase abkürzt, baut die falsche Lösung – und das ist deutlich teurer als die Konzeptionsarbeit.