Softwareprojekt ohne Fachkonzept? Ein unterschätztes Risiko

In vielen Unternehmen beginnt ein Softwareprojekt mit einer Idee: Ein Prozess soll automatisiert werden, ein System abgelöst, eine Abteilung besser vernetzt. Die Idee wird zum Projekt, Angebote werden eingeholt, ein Dienstleister ausgewählt. Monate später stellt sich heraus: Die Software tut nicht, was sie soll. Nicht weil die Technik versagt hätte, sondern weil von Anfang an unklar war, was sie eigentlich leisten sollte.

Das Muster wiederholt sich branchenübergreifend. Die Ursache liegt selten in mangelnder technischer Kompetenz. Sie liegt in einem fehlenden oder unzureichenden Software Fachkonzept.

Warum entsteht diese Lücke?

Die Lücke zwischen Idee und funktionierender Software entsteht nicht aus Nachlässigkeit. Sie hat systemische Ursachen.

Technik erscheint greifbarer als Fachlichkeit. Wenn ein Dienstleister Frameworks, Programmiersprachen und Architekturen präsentiert, wirkt das konkret. Die Frage, welche Geschäftsregeln die Software abbilden soll, wirkt dagegen abstrakt. Also wird sie oft übersprungen oder nur oberflächlich behandelt.

Fachliches Wissen ist im Unternehmen verteilt. Wer einen Prozess täglich ausführt, kennt Details, die nirgends dokumentiert sind. Wer ihn verantwortet, sieht andere Aspekte. Wer ihn steuert, hat wieder eine andere Perspektive. Dieses Wissen zu bündeln und zu strukturieren erfordert Zeit und Methodik.

Projekte stehen unter Zeitdruck. Die Erwartung, schnell sichtbare Ergebnisse zu liefern, führt dazu, dass die Konzeptphase verkürzt wird. Die Logik scheint nachvollziehbar: Je früher wir anfangen zu entwickeln, desto früher sind wir fertig. Diese Rechnung geht selten auf.

Dienstleister profitieren nicht von langen Konzeptphasen. Ein Angebot für Softwareentwicklung lässt sich leichter verkaufen als eines für Konzeptarbeit. Manche Dienstleister beginnen daher lieber mit der Entwicklung und klären fachliche Fragen unterwegs. Das Risiko trägt der Auftraggeber.

Typische Missverständnisse beim Software Fachkonzept

Rund um das Thema Fachkonzept für Software existieren Annahmen, die Projekte in Schieflage bringen können.

"Der Dienstleister wird schon wissen, was wir brauchen." Ein externer Dienstleister kann technische Expertise einbringen. Er kann nicht wissen, wie Ihr Unternehmen funktioniert, welche Ausnahmen es gibt, welche Prozesse politisch sensibel sind. Dieses Wissen existiert nur bei Ihnen.

"Wir haben ja ein Lastenheft." Ein Lastenheft listet Anforderungen auf. Ein Fachkonzept erklärt, warum diese Anforderungen bestehen, wie sie zusammenhängen und was passiert, wenn sie nicht erfüllt werden. Die Liste allein ersetzt nicht das Verständnis.

"Agile Entwicklung macht Konzepte überflüssig." Agile Methoden erlauben Anpassungen während der Entwicklung. Sie ersetzen nicht die Klärung, was das System leisten soll. Auch in agilen Projekten braucht es ein fachliches Zielbild. Sonst iteriert man ohne Richtung.

"Das Konzept ergibt sich aus der Technik." Technologie ist ein Mittel, kein Ziel. Ob ein System auf einer bestimmten Plattform läuft oder eine bestimmte Datenbank nutzt, sagt nichts darüber aus, welche Geschäftsprobleme es löst. Die Technik folgt der Fachlichkeit, nicht umgekehrt.

Fachkonzept und technisches Konzept: Eine notwendige Abgrenzung

Die Verwechslung von Fachkonzept und technischem Konzept führt regelmäßig zu Missverständnissen zwischen Auftraggeber und Dienstleister.

Ein Fachkonzept beschreibt die Welt aus Sicht des Unternehmens. Es beantwortet Fragen wie: Welche Prozesse soll die Software unterstützen? Welche Nutzergruppen gibt es und was sind ihre Aufgaben? Nach welchen Regeln werden Entscheidungen getroffen? Welche Daten sind relevant und wie hängen sie zusammen? Welche Schnittstellen zu bestehenden Systemen sind nötig?

Ein technisches Konzept übersetzt diese Anforderungen in technische Lösungen. Es beantwortet Fragen wie: Welche Architektur ist geeignet? Welche Technologien kommen zum Einsatz? Wie werden Daten gespeichert und verarbeitet? Wie wird Sicherheit gewährleistet?

Die Reihenfolge ist nicht verhandelbar: Ohne Fachkonzept fehlt dem technischen Konzept die Grundlage. Ein noch so ausgefeiltes technisches Konzept nützt wenig, wenn es die falschen Probleme löst.

Für ein tragfähiges Software Konzept im KMU-Umfeld gilt das besonders. Kleinere Unternehmen haben weniger Spielraum für Korrekturen. Eine solide fachliche Basis ist hier keine Option, sondern Voraussetzung.

Die Rolle des Fachkonzepts im Projektverlauf

Ein Fachkonzept ist kein Dokument, das einmal erstellt und dann abgelegt wird. Es erfüllt während des gesamten Projekts mehrere Funktionen.

Vor Projektbeginn dient es als Entscheidungsgrundlage. Auf Basis des Fachkonzepts lässt sich realistisch einschätzen, welcher Aufwand zu erwarten ist, ob eine Eigenentwicklung sinnvoll ist oder eine Standardlösung, welche Risiken bestehen.

Bei der Anbieterauswahl macht es Angebote vergleichbar. Wenn alle Anbieter auf Basis desselben Fachkonzepts kalkulieren, werden Unterschiede in Preis und Ansatz transparent. Ohne gemeinsame Grundlage vergleichen Sie Äpfel mit Birnen.

Während der Entwicklung ist es der Referenzpunkt für alle Beteiligten. Wenn Fragen auftauchen, liefert das Fachkonzept Antworten. Wenn Änderungswünsche entstehen, lässt sich prüfen, ob sie zum ursprünglichen Ziel passen oder den Scope erweitern.

Bei der Abnahme definiert es, was geliefert werden sollte. Die Frage, ob die Software fertig ist, lässt sich nur beantworten, wenn klar ist, was sie können sollte.

Woran Sie erkennen, dass ein Fachkonzept fehlt

Einige Warnsignale deuten darauf hin, dass ein Projekt ohne ausreichende fachliche Grundlage gestartet wurde.

Das Projekt hat begonnen, aber grundlegende Fragen sind noch offen. Welche Nutzergruppen gibt es? Wie sieht der Standardprozess aus? Was passiert in Ausnahmefällen? Wenn diese Fragen erst während der Entwicklung geklärt werden, ist das ein Zeichen für ein fehlendes Fachkonzept.

Die Kommunikation mit dem Dienstleister dreht sich überwiegend um Technik. Wenn Gespräche von Frameworks, APIs und Datenbanken dominiert werden, aber kaum von Geschäftsprozessen und Nutzeranforderungen, fehlt möglicherweise die fachliche Basis.

Änderungswünsche häufen sich kurz nach Entwicklungsbeginn. Häufige frühe Änderungen deuten darauf hin, dass das Zielbild nicht klar genug war. Spätere Änderungen können neue Erkenntnisse widerspiegeln. Frühe Änderungen deuten auf Versäumnisse in der Konzeptphase.

Das fertige System wird von den Nutzern nicht angenommen. Wenn eine technisch einwandfreie Software im Alltag nicht genutzt wird, liegt das selten an der Technik. Oft wurden die tatsächlichen Arbeitsweisen und Bedürfnisse der Nutzer nicht ausreichend verstanden und abgebildet.

Handlungsempfehlungen

Wenn Sie ein Softwareprojekt planen oder bereits gestartet haben, können folgende Schritte helfen.

Klären Sie den fachlichen Kern, bevor Sie über Technik sprechen. Investieren Sie Zeit in die Frage, was die Software leisten soll und warum. Diese Investition zahlt sich mehrfach zurück.

Binden Sie die richtigen Personen ein. Ein Fachkonzept entsteht nicht am Schreibtisch einer einzelnen Person. Es braucht das Wissen derer, die die Prozesse kennen, verantworten und nutzen werden.

Trennen Sie Konzepterstellung und Umsetzung. Wenn derselbe Dienstleister das Konzept erstellt und die Umsetzung anbietet, besteht ein Interessenkonflikt. Ein unabhängiges Fachkonzept gehört Ihnen und macht Sie frei in der Wahl des Umsetzungspartners.

Behandeln Sie das Fachkonzept als lebendes Dokument. Erkenntnisse aus der Entwicklung können Anpassungen nötig machen. Das Konzept sollte diese Änderungen dokumentiert aufnehmen, damit es als Referenz nutzbar bleibt.

Scheuen Sie nicht die vermeintlichen Mehrkosten. Ein gutes Fachkonzept kostet Zeit und Geld. Ein fehlendes Fachkonzept kostet mehr.

Fazit

Ein Softwareprojekt ohne Fachkonzept gleicht einer Baustelle ohne Bauplan. Die Handwerker mögen kompetent sein, das Material hochwertig, die Maschinen modern. Wenn niemand weiß, was am Ende stehen soll, wird das Ergebnis nicht zufriedenstellen.

Das Fachkonzept ist keine bürokratische Hürde und kein Luxus für Großprojekte. Es ist die Grundlage dafür, dass technische Kompetenz überhaupt wirksam werden kann. Ohne fachliches Zielbild kann Technik keine Probleme lösen.

Die gute Nachricht: Dieses Risiko lässt sich vermeiden. Nicht durch mehr Technik, nicht durch schnelleres Entwickeln, sondern durch Klarheit vor dem Start.