Kapitel 1: Soll-Konzept vs. Lösungskonzept

Lernziele

Den fundamentalen Unterschied zwischen Soll- und Lösungskonzept verstehen
Beide Konzepttypen in der Praxis korrekt anwenden
Typische Fehler bei der Konzeption vermeiden

Einleitung: Warum die Unterscheidung entscheidend ist

In der IT-Beratung ist die präzise Terminologie nicht nur eine akademische Übung – sie bestimmt die Erwartungshaltung des Kunden und den Erfolg des Projekts. Ein häufiger Fehler ist, den Kunden zu früh mit technischen Details zu überfrachten, bevor das fachliche Zielbild geklärt ist. Dies führt zu Missverständnissen, teuren Neuentwicklungen und unzufriedenen Stakeholdern.

Praxis-Beispiel

Ein Kunde möchte ein neues CRM-System einführen. Wenn der Berater sofort mit "Wir sollten Salesforce oder Dynamics 365 evaluieren" beginnt, überspringt er das Soll-Konzept. Richtig wäre: "Lassen Sie uns zunächst klären, welche Vertriebsprozesse Sie verbessern möchten und wie Ihre Kundenbeziehungen idealerweise gestaltet sein sollen."

Das Soll-Konzept: Das fachliche Zielbild

Das Soll-Konzept beschreibt den gewünschten Endzustand aus fachlicher Sicht. Es ist technologieoffen und konzentriert sich auf Geschäftsprozesse, Anforderungen und Ziele.

Kernmerkmale

Merkmal	Beschreibung
Fokus	Fachliche Anforderungen, Geschäftsprozesse
Technologie	Offen – noch keine Festlegung
Adressaten	Management, Fachbereichsleiter, Anwender
Detaillierungsgrad	Grob bis fein, je nach Phase
Ziel	Einigung über das "Was" und "Warum"

Bestandteile eines Soll-Konzepts

Ausgangssituation und Analyse
Bestandsaufnahme der aktuellen Prozesse
Identifikation von Schwachstellen und Verbesserungspotenzial
Ist-Analyse der bestehenden IT-Landschaft
Ziele und Anforderungskatalog
Strategische Ziele (z. B. Zeitersparnis 20%, Qualitätssteigerung)
Operative Anforderungen (z. B. Automatisierung, Integration)
Nicht-funktionale Anforderungen (z. B. Verfügbarkeit, Datenschutz)
Prozessmodellierung
Soll-Prozesse in BPMN oder ähnlicher Notation
Rollen und Verantwortlichkeiten definieren
Schnittstellen zwischen Prozessen identifizieren

Häufiger Fehler

Oft werden im Soll-Konzept bereits erste technische Details wie Datenbankstruktur oder Programmiersprache diskutiert. Dies führt zu einer vorzeitigen Fixierung und verhindert innovative Lösungsansätze.

Ein Beispiel-Prozess aus dem Soll-Konzept

flowchart TD
    A[Bestellung eingehen] --> B{Prüfung auf Lagerbestand}
    B -->|Ja| C[Lagerabgang buchen]
    B -->|Nein| D[Lieferantenbestellung]
    D --> E[Warenannahme]
    E --> C
    C --> F[Rechnung erstellen]
    F --> G[Kunde informieren]

Das Lösungskonzept: Der technische Bauplan

Das Lösungskonzept ist die konkrete Antwort auf das Soll-Konzept. Hier wird die Technologie festgelegt. Es dient als verbindliche Arbeitsgrundlage für Entwickler und IT-Spezialisten.

Kernmerkmale

Merkmal	Beschreibung
Fokus	Technische Umsetzung, Architektur
Technologie	Konkrete Festlegung (Produkte, Frameworks)
Adressaten	Architekten, Entwickler, Systemadministratoren
Detaillierungsgrad	Technisch detailliert
Ziel	Verbindlicher Bauplan für die Umsetzung

Bestandteile eines Lösungskonzepts

Architekturübersicht
Schichtenmodell (z. B. 3-Tier, Microservices)
Technologiestack (z. B. Java Spring Boot, PostgreSQL, React)
Integrationskonzept (APIs, Messaging, ETL)
Datenmodell
Datenbankschema
Entity-Relationship-Diagramm
Datenfluss zwischen Komponenten
Sicherheitskonzept
Authentifizierung und Autorisierung
Verschlüsselung (at rest, in transit)
Sicherheitsarchitektur (Firewall, WAF, DDoS-Schutz)
Betriebskonzept
Deployment-Strategie
Monitoring und Alerting
Backup und Recovery

Lösungskonzept-Auszug

Architektur: - Frontend: React 18 mit TypeScript - Backend: Java 17, Spring Boot 3.0 - Datenbank: PostgreSQL 15 (Hauptdatenbank) + Redis 7 (Caching) - API: REST mit OpenAPI-Spezifikation - Hosting: AWS EKS (Kubernetes), RDS, ElastiCache

Architektur-Diagramm aus dem Lösungskonzept

graph TB
    subgraph "Frontend Layer"
        FE[React Frontend]
    end
    subgraph "API Gateway"
        GW[API Gateway / Load Balancer]
    end
    subgraph "Backend Services"
        S1[Order Service]
        S2[Inventory Service]
        S3[Customer Service]
    end
    subgraph "Data Layer"
        DB1[(PostgreSQL<br/>Order DB)]
        DB2[(PostgreSQL<br/>Inventory DB)]
        CACHE[Redis<br/>Cache]
    end
    FE -->|HTTPS| GW
    GW --> S1
    GW --> S2
    GW --> S3
    S1 --> DB1
    S2 --> DB2
    S1 --> CACHE
    S2 --> CACHE

Der Entwicklungsprozess vom Soll- zum Lösungskonzept

Die Konzeption folgt einer logischen Abfolge mit Feedback-Schleifen:

gantt
    title Entwicklungsprozess: Soll- zu Lösungskonzept
    dateFormat  YYYY-MM-DD
    section Phase 1
    Ist-Analyse          :a1, 2026-01-01, 7d
    Anforderungserhebung :a2, after a1, 10d
    section Phase 2
    Soll-Konzept erstellen  :b1, after a2, 14d
    Soll-Konzept abstimmen   :b2, after b1, 7d
    section Phase 3
    Lösungsoptionen evaluieren :c1, after b2, 10d
    Technologie-Entscheidung   :c2, after c1, 5d
    section Phase 4
    Lösungskonzept erstellen :d1, after c2, 14d
    Lösungskonzept validieren :d2, after d1, 7d

Iterative Validierung

Der Prozess ist nicht linear – er erfordert Feedback-Schleifen:

Rückkopplung vom Lösungskonzept zum Soll-Konzept
Technische Machbarkeit wird erst im Lösungskonzept geprüft
Wenn technische Limitationen auftreten, müssen Soll-Anforderungen angepasst werden
Rückkopplung vom Kunden zum Konzept
Der Kunde prüft das Soll-Konzept auf fachliche Richtigkeit
Feedback führt zu Änderungen in beiden Konzepten

Praxistipp

Verwenden Sie Prototypen und Proof of Concepts (PoC), um die Lücke zwischen Soll- und Lösungskonzept zu überbrücken. Ein PoC kann zeigen, ob eine technische Lösung machbar ist, bevor das Lösungskonzept finalisiert wird.

Typische Fehler und deren Vermeidung

Fehler	Auswirkung	Vermeidung
Technik-Fixierung im Soll-Konzept	Innovation wird blockiert	Strikte Trennung der Rollen (Business vs. IT)
Soll-Konzept zu vage	Lösungskonzept muss häufig überarbeitet	Detaillierte Anforderungsspezifikationen erstellen
Lösungskonzept ohne Soll-Abgleich	Löst das falsche Problem	Regelmäßige Reviews mit Fachabteilung
Ein Konzept für beide Zwecke	Verwirrung bei Adressaten	Zwei getrennte Dokumente mit klarer Trennung

Zusammenfassung

Das Soll-Konzept definiert das "Was" – die fachlichen Anforderungen und Ziele aus Sicht des Business. Es ist technologieoffen und richtet sich an Management und Fachbereiche.

Das Lösungskonzept definiert das "Wie" – die technische Realisierung mit konkreter Technologiewahl. Es ist technologiefixiert und richtet sich an Entwickler und IT-Fachkräfte.

Ein erfolgreicher IT-Berater beherrscht beide Konzepttypen, weiß, wann welches Dokument erstellt wird, und kann die Lücke zwischen Fachlichkeit und Technologie professionell überbrücken.

Nächstes Kapitel: Technische Handlungsfelder