Soll-Konzept und Lösungsansätze

Das Soll-Konzept ist das Kapitel, in dem du aus den Befunden der Ist-Analyse eine konkrete Lösung ableitest. Es ist das Herzstück deiner fachlichen Bewertung: Prüfende erkennen hier sofort, ob du methodisch denken kannst – nicht nur ausführen, sondern abwägen, vergleichen, begründen. Aus diesem Kapitel speist sich die 30 % Bewertung „fachliche Lösung" und ein Großteil der 20 % „Methodik".

Diese Lektion zeigt dir, wie du Lösungs­alternativen sammelst, wie du sie mit der Nutzwert-Analyse systematisch vergleichst, wie du die Architektur des Soll-Zustands darstellst und wie du jede Anforderung aus der Ist-Analyse sauber im Soll-Konzept abdeckst. Das Soll-Konzept ist meist 1,5–2 Seiten lang.

1) Was in das Soll-Konzept gehört

Im Soll-Konzept geht es um was die Lösung sein soll – noch nicht um die konkrete Umsetzung (das ist das nächste Kapitel). Drei Inhalts­blöcke sind Standard:

• Lösungs­alternativen: typisch 2–4 Varianten, die das Problem auf unterschiedliche Weise lösen würden
• Bewertung der Varianten: methodisches Abwägen (Vorteile, Nachteile, Kriterien­vergleich, ggf. Nutzwert-Analyse)
• Entscheidung für eine Variante: begründet, nachvollziehbar, mit klarer Empfehlung
• Zielarchitektur: Skizze und Beschreibung der gewählten Lösung – Komponenten, Schnitt­stellen, Datenfluss
• Anforderungs­erfüllung: Nachweis, dass alle Anforderungen aus der Ist-Analyse vom Soll-Konzept abgedeckt sind

2) Lösungs­alternativen sammeln

Der erste Schritt ist das offene Sammeln möglicher Lösungen. Bei IT-Projekten gibt es fast immer mehrere realistische Optionen – „nur eine offensichtliche Lösung" ist meist ein Zeichen für zu enge Sicht. Drei klassische Achsen, an denen du Alternativen ablesen kannst:

• Make vs. Buy: selber entwickeln/aufbauen vs. fertige Lösung kaufen
• On-Premise vs. Cloud: lokal betreiben vs. extern
• Standard vs. individuell: bekannte Standardlösung vs. maßgeschneiderte Speziallösung

Für ein Backup-Beispiel könnten typische Alternativen sein: (A) kommerzielles Backup-Tool On-Premise (z. B. Veeam), (B) Open-Source-Lösung On-Premise (z. B. Bacula), (C) Cloud-Backup als SaaS (z. B. Backblaze, AWS Backup). Drei Varianten reichen meist – zwei wirken oft etwas dünn, vier oder mehr sind übertrieben.

3) Varianten kurz und klar beschreiben

Jede Variante bekommt einen kurzen Absatz: was wäre der Kerngedanke, was die Vor- und Nachteile? Diese Beschreibung muss noch keine Bewertung enthalten – nur Fakten. Beispiel-Darstellung:

4) Nutzwert-Analyse zur systematischen Bewertung

Die Nutzwert-Analyse ist ein bewährtes Werkzeug, um Varianten objektiv zu vergleichen. Sie funktioniert in vier Schritten:

1. Bewertungs­kriterien festlegen – 4–6 Kriterien sind typisch (z. B. Kosten, Aufwand, Sicherheit, Flexibilität)
2. Gewichtung pro Kriterium (Summe = 100 %). Wichtige Kriterien bekommen mehr Gewicht
3. Punkte pro Variante (z. B. 1–5 oder 1–10) für jedes Kriterium
4. Gewichtete Summe pro Variante berechnen – höchster Wert „gewinnt"

Die Nutzwert-Analyse ist nicht magisch – das Ergebnis hängt stark von Gewichten und Bewertungen ab. Aber sie zwingt zum sauberen Denken und ist ein klassisches IHK-anerkanntes Werkzeug. In der Doku zeigt sie methodisches Vorgehen.

5) Entscheidung begründen

Nach der Analyse folgt die Entscheidung. Sie sollte zwei Eigenschaften haben: (1) klar – kein „mal sehen", sondern eine eindeutige Wahl. (2) begründet – nicht nur „weil der Score am höchsten ist", sondern mit echten inhaltlichen Argumenten.

Beispiel-Formulierung: „Die Nutzwert-Analyse ergibt für Variante A (Veeam On-Premise) den höchsten Score (4,25 von 5,0). Maßgeblich sind die hohe DSGVO-Konformität durch On-Premise-Hosting, die Restore-Zuverlässigkeit als kritischer Aspekt der Datensicherheit, sowie der akzeptable laufende Aufwand. Variante C (Cloud) erzielt zwar bei der Skalierbarkeit den höchsten Wert, fällt aber bei DSGVO und laufenden Kosten zurück. Variante B (Bacula) scheitert primär am hohen Eigen­aufwand, der mit einer dreiköpfigen IT-Mannschaft nicht tragfähig ist. Die Entscheidung fällt auf Variante A."

6) Ist vs. Soll: die Diff-Tabelle

Eine wirkungs­volle Darstellung ist die direkte Gegenüberstellung Ist vs. Soll. Sie zeigt in einem Blick, was sich ändern wird – und ist eine sehr beliebte Visualisierung in IHK-Dokus:

7) Zielarchitektur visualisieren

Eine grafische Darstellung der gewählten Lösung ist Pflicht­programm. Sie zeigt die Komponenten und ihre Beziehungen. Bei IT-Projekten typisch: ein Schichten- oder Komponenten-Diagramm:

Eine gute Architektur­skizze hat klare Komponenten, klare Verbindungen mit Pfeilrichtungen und kurze Beschriftungen. Komplexität nur, wo nötig – ein 30-Komponenten-Diagramm verwirrt mehr als eine 5-Komponenten-Übersicht klar erläutert.

8) Erfüllungs­matrix Anforderungen

Ein eleganter Abschluss des Soll-Konzepts: eine Matrix, die zeigt, dass alle Anforderungen aus der Ist-Analyse durch das Soll-Konzept abgedeckt sind. Das ist „closing the loop" – Prüfende lieben das.

9) Abgrenzung – was bleibt außen vor

Ein oft vergessener, aber sehr wertvoller Abschnitt: die bewusste Abgrenzung. Was wird im Projekt nicht umgesetzt, obwohl es vielleicht naheliegen würde? Klare Abgrenzung verhindert „Scope-Creep" und zeigt Projekt-Verständnis.

Beispiele für saubere Abgrenzung:

• „Die Migration der historischen Backups (älter als 2 Jahre) ist nicht Bestandteil dieses Projekts."
• „Die Backup-Strategie für Endgeräte (Laptops, mobile Geräte) bleibt aus Umfangsgründen ausgeklammert."
• „Eine Disaster-Recovery-Übung mit kompletter Wiederherstellung an einem zweiten Standort wird in einem Folgeprojekt durchgeführt."

Mit so einer Abgrenzung machst du klar: du weißt, dass es noch mehr zu tun gäbe – aber du fokussierst dich auf das machbare 35-h-Projekt.

10) Häufige Fehler im Soll-Konzept

• Nur eine Lösung präsentiert: ohne Alternativen wirkt es unmethodisch. Mindestens 2, besser 3 Varianten zeigen
• Scheinalternativen: Variante B und C offensichtlich schlechter, nur damit A „gewinnt". Prüfende durchschauen das
• Bewertungs­kriterien ohne Gewichtung: alle Kriterien gleich wichtig – wirkt naiv. Begründen, warum z. B. DSGVO oder Kosten mehr Gewicht haben
• Nutzwert-Punkte unbegründet: warum bekommt Variante A für „Kosten" 3 Punkte und nicht 4? Im Text kurz erklären
• Kein Ist-Soll-Vergleich: man muss raten, was sich ändert. Heilung: explizite Diff-Tabelle
• Architektur­skizze fehlt: nur Text – Prüfende stellen sich die Lösung schwer vor. Heilung: ein Mockup als Bild
• Anforderungen nicht durchgereicht: Anforderungen aus der Ist-Analyse tauchen im Soll nicht wieder auf. Heilung: Erfüllungs­matrix
• Detail­tiefe wie in der Realisierung: Konfigurations­beispiele, Code, Befehle gehören erst in die Umsetzung. Hier nur die Konzept-Ebene
• Keine Abgrenzung: das Projekt wirkt grenzenlos. Heilung: explizite Abgrenzungs-Sätze

11) Methodische Argumentations­kette

Der rote Faden, der ein gutes Soll-Konzept ausmacht, lässt sich in vier Schritten skizzieren:

Wer diesen Faden durchhält, hat ein Soll-Konzept, das Prüfende als schlüssig bewerten – und das ist 50 % der fachlichen Bewertung. Jedes „warum" sollte im Soll-Konzept beantwortet werden. „Warum diese Lösung?" → Nutzwert-Analyse. „Warum diese Kriterien?" → Anforderungen aus Ist. „Warum diese Gewichtung?" → Auftraggeber-Prioritäten, Rahmenbedingungen.

12) Beispiel-Eröffnung Soll-Konzept

Wieder ein Beispieltext, der den Ton trifft:

„Auf Basis der in Kapitel 3 ermittelten Probleme (P1–P4) und der daraus abgeleiteten Anforderungen (F1–F5, N1–N5) werden drei Lösungs­varianten gegen­einander abgewogen: (A) ein kommerzielles Backup-Produkt auf eigenem Backup-Server (Veeam Backup & Replication), (B) eine Open-Source-Lösung (Bacula), (C) eine reine Cloud-Backup-Lösung. Die Bewertung erfolgt über eine Nutzwert-Analyse mit sechs Kriterien, gewichtet nach Vorgaben der IT-Leitung. Die Ergebnisse werden im Anschluss begründet und die gewählte Architektur skizziert. Abschließend wird gezeigt, wie alle Anforderungen der Ist-Analyse durch das gewählte Soll-Konzept abgedeckt werden."

An diesem Beispiel siehst du: in 4 Sätzen ist die ganze Kapitel­logik klar. Was kommt? Drei Varianten, Nutzwert-Analyse, Begründung, Architektur, Erfüllungs­nachweis. Der Prüfer weiß, was ihn erwartet – und kann sich auf die Details freuen.

Zusammenfassung

Das Soll-Konzept ist 1,5–2 Seiten lang und das Herzstück der fachlichen Bewertung. Inhaltsblöcke: Lösungs­alternativen (typisch 2–4), Variantenbeschreibung mit Vor-/Nachteilen, Nutzwert-Analyse mit Kriterien und Gewichtung, begründete Entscheidung, Ist-Soll-Diff, Zielarchitektur als Skizze, Erfüllungsmatrix der Anforderungen und Abgrenzung dessen, was außen vor bleibt. Argumentations­kette: Problem → Anforderung → Varianten → Auswahl → Architektur → Erfüllungs­nachweis. Häufige Fehler: nur eine Lösung, Scheinalternativen, ungewichtete Kriterien, fehlende Begründung, kein Diagramm, keine Abgrenzung, zu viel Detail (gehört in Realisierung). Tipp: bei jeder Entscheidung „Was wäre wenn anders?" gegenfragen, das schärft die Begründung.