Eine Software-Investition vor der Geschäftsleitung begründen

Warum gute Argumente in der Sitzung verpuffen

Du sitzt näher am Problem als alle anderen im Raum. Du siehst die Mitarbeiterin, die jeden Morgen zwanzig Minuten lang Daten von einem System ins andere abtippt. Du kennst den Auftrag, der verloren ging, weil die Offerte drei Tage zu spät rausging. Für dich ist sonnenklar, dass eine eigene Software das lösen würde. In der Sitzung der Geschäftsleitung kommt diese Klarheit trotzdem oft nicht an. Dort sitzen Leute, die das Tagesgeschäft nicht im Detail kennen und jeden Franken gegen andere Investitionen abwägen müssen.

Das liegt selten daran, dass deine Idee schlecht wäre. Die Geschäftsleitung kann sie nur nicht beurteilen, solange sie als Bauchgefühl daherkommt. Was im Sitzungszimmer zählt, ist ein Business Case: eine nachvollziehbare Rechnung, die zeigt, was das Problem heute kostet, was die Lösung kostet und welches Risiko dahintersteckt. Den baust du dir in diesem Artikel zusammen, Schritt für Schritt, von den versteckten Kosten des Status quo bis zur Frage, wie ein Festpreis das Risiko für die Geschäftsleitung kalkulierbar macht.

Die Kosten des ungelösten Problems sichtbar machen

Der häufigste Fehler: mit der Lösung anfangen. Du erzählst von der Software, ihren Funktionen, dem Anbieter. Damit liegt die ganze Beweislast auf der Ausgabe, und das Problem, das sie löst, bleibt unsichtbar. Dreh es um. Fang bei den Kosten an, die dein Betrieb schon heute trägt, ohne dass jemand eine Rechnung dafür bekommt.

Diese Kosten stecken an drei Stellen. Da ist zuerst die verlorene Zeit. Jede manuelle Tätigkeit, die eine Software übernehmen könnte, frisst Arbeitsstunden. Zwanzig Minuten Abtippen pro Tag klingen nach nichts. Über ein Jahr und mehrere Mitarbeitende werden daraus Wochen, die für Arbeit draufgehen, die niemand bezahlt sehen will. Rechne nicht mit Fantasiezahlen, sondern beobachte echte Abläufe: Wie oft passiert die Tätigkeit, wie lange dauert sie, wie viele Leute machen sie. Daraus ergibt sich eine belegbare Bandbreite, und die überzeugt mehr als eine glatte Einzelzahl.

Dann die Fehler. Wo von Hand übertragen, kopiert und nachgepflegt wird, schleichen sich Fehler ein. Eine falsche Zahl in der Offerte. Ein vergessener Posten auf der Rechnung. Eine Lieferung an die falsche Adresse. Jeder Fehler kostet Zeit für die Korrektur, manchmal Geld für die Wiedergutmachung, im schlimmsten Fall das Vertrauen eines Kunden. Sammle konkrete Fälle aus den letzten Monaten. Drei nachvollziehbare Beispiele wirken in der Sitzung stärker als jede Prozentangabe.

Am teuersten und am leichtesten zu übersehen ist das entgangene Geschäft. Aufträge, die ihr nicht annehmen konntet, weil die Kapazität von Routinearbeit aufgefressen wurde. Kunden, die absprangen, weil eure Reaktion zu lange dauerte. Wachstum, das ausblieb, weil jeder neue Kunde denselben manuellen Mehraufwand bedeutet hätte. Solche Kosten tauchen in keiner Buchhaltung auf, und genau deshalb musst du sie aussprechen. Oft sind sie das stärkste Argument, weil sie zeigen: Das Problem wächst mit dem Betrieb mit.

Die Lösungskosten seriös kalkulieren

Steht die Problemseite, kommt die Investition dazu. Hier verlierst du Glaubwürdigkeit, sobald du zu optimistisch rechnest. Die Geschäftsleitung hat schon Projekte gesehen, die das Budget gesprengt haben, und sie wird genau an dieser Stelle nachhaken. Nenne darum nicht nur den Preis für die Entwicklung, sondern die Rechnung über die ganze Lebensdauer.

Vier Posten gehören dazu. Die Entwicklung ist der einmalige Aufwand, bis die Software läuft. Der Betrieb sind die laufenden Kosten danach: Hosting, Wartung, Updates, Sicherheit. Software ist kein Möbelstück, das man einmal kauft und dann stehen lässt, sie braucht Pflege. Die Einführung umfasst die Zeit, die dein Team braucht, um umzustellen und die neue Software zu lernen. Und die Anpassung deckt ab, dass sich Anforderungen verschieben, sobald die Software im Einsatz ist und ihr seht, was wirklich gebraucht wird.

Legst du diese vier Posten offen auf den Tisch, wirkt deine Rechnung nicht teurer, sondern seriöser. Du zeigst, dass du die Folgekosten mitgedacht hast, und nimmst der Geschäftsleitung den Einwand vorweg, nach dem Projekt kämen noch Überraschungen. Wie sich diese Posten im Detail zusammensetzen und welche Bandbreiten realistisch sind, haben wir in was kostet ein MVP auseinandergenommen.

Die entscheidende Gegenüberstellung ist dann einfach. Auf der einen Seite die Kosten des Problems, Jahr für Jahr, solange nichts passiert. Auf der anderen Seite die Investition, die einmalig gross und danach klein ist. Eine eigene Software lohnt sich, wenn die jährlichen Problemkosten die Lösung in einem überschaubaren Zeitraum wieder einspielen. Die Logik im Detail, samt der Frage, ab welcher Betriebsgrösse sich der Eigenbau gegenüber Standardsoftware rechnet, findest du in lohnt sich eigenes SaaS für KMU.

Die drei Einwände, bevor sie kommen

Ein guter Business Case beantwortet die Fragen, die in der Sitzung sowieso gestellt werden, schon im Vortrag. Drei davon kommen fast immer.

Was, wenn das Projekt entgleist? Jeder am Tisch kennt eine Software, die teurer und später wurde als versprochen oder nie richtig funktionierte. Die Sorge ist berechtigt, und du nimmst sie nicht weg, indem du sie übergehst. Du nimmst sie weg, indem du zeigst, wie ihr das Risiko klein haltet. Dazu gleich mehr. Warum solche Projekte überhaupt scheitern und woran man die Warnzeichen früh erkennt, steht in warum SaaS-Projekte scheitern.

Warum nicht Standardsoftware von der Stange? Eine faire Frage, und die Antwort lautet nicht automatisch Eigenbau. Deckt ein fertiges Produkt euren Ablauf gut genug ab, ist es fast immer die günstigere Wahl. Eigene Software lohnt sich dort, wo euer Ablauf der Grund für euren Vorsprung ist und kein Standardprodukt ihn abbildet, ohne dass ihr euch verbiegt. Sag das so. Es zeigt, dass du nicht aus Prinzip selbst bauen willst, sondern weil es hier passt. Den Vergleich der Wege, vom Selberbauen über die Agentur bis zum Produktstudio, findest du in selbst bauen vs Agentur vs No-Code vs Produktstudio.

Wer kümmert sich danach darum? Software, die niemand betreut, wird zur Last. Die Geschäftsleitung will wissen, dass ihr nach dem Launch nicht alleine dasteht. Hier hilft ein Partner, der nicht nur baut, sondern auch betreibt. Wir bei Wertstifter entwickeln nicht bloss Software für Kunden, wir betreiben auch eigene Produkte wie Wortfreunde und Reazon im Tagesgeschäft. Wir wissen also aus eigenem Betrieb, was eine Software über Jahre am Laufen hält, nicht nur, wie man sie startet. Genau diese Verbindung aus Bauen und Betreiben steckt hinter unserer Individualsoftware für KMU.

Risiko in Phasen zerlegen

Der grösste Hebel gegen die Angst vor dem Entgleisen: das Projekt nicht als einen grossen Sprung planen, sondern als Folge kleiner Schritte. Ein Vorhaben, das achtzehn Monate läuft und erst am Ende ein Ergebnis zeigt, ist ein Risiko, das keine Geschäftsleitung gern eingeht. Ein Vorhaben, das nach wenigen Wochen die erste nutzbare Version liefert, ist beherrschbar.

Das Prinzip: mit dem Kern anfangen. Ihr baut zuerst den Teil, der den grössten Schmerz löst, und bringt ihn in den echten Einsatz. Erst wenn der läuft und Wert liefert, kommt der nächste Teil dazu. Jede Phase ist für sich abgeschlossen und nützlich. Das bringt zwei Dinge. Ihr seht früh, ob die Richtung stimmt, und könnt korrigieren, solange es noch billig ist. Und die Geschäftsleitung muss nicht das ganze Budget auf einmal freigeben, sondern entscheidet von Phase zu Phase, mit dem Ergebnis der letzten Phase in der Hand.

Dieses Vorgehen ist nicht nur ein Sicherheitsnetz, es macht auch bessere Software. Anforderungen, die am Reissbrett richtig schienen, entpuppen sich im echten Einsatz oft als falsch. Wer in kleinen Schritten liefert, merkt das früh und baut das Richtige, statt monatelang am Bedarf vorbei zu entwickeln. Wie sich ein erster nutzbarer Kern sinnvoll zuschneiden lässt, zeigen die besten Wege, ein MVP zu bauen.

Der Festpreis als Sicherheit für die Geschäftsleitung

Die letzte Sorge ist die offene Rechnung. Ein Projekt nach Aufwand abzurechnen heisst, einen Blankoscheck zu unterschreiben, dessen Endbetrag niemand kennt. Genau diese Unsicherheit blockiert eine Zusage in der Sitzung.

Ein Festpreis pro Phase löst das. Statt eines unbegrenzten Stundenbudgets gibt es einen klar definierten Umfang zu einem klar definierten Preis. Vor dem Start jeder Phase weiss die Geschäftsleitung genau, was sie kostet und was am Ende dabei herauskommt. Das Risiko, dass der Aufwand davonläuft, trägt damit der Anbieter, nicht ihr. Ein starkes Argument, weil es die Investition von einer offenen Frage in eine kalkulierbare Position verwandelt.

Festpreis und Phasen greifen ineinander. Weil jede Phase einen abgegrenzten Umfang hat, lässt sie sich überhaupt erst zum Festpreis anbieten. Und weil der Preis feststeht, kann die Geschäftsleitung nach jeder Phase frei entscheiden, ob sie weitergeht. Sie bindet sich nie an mehr, als sie schon gesehen hat. Diese Kombination aus kleinen Schritten und festen Preisen pro Schritt verwandelt eine Software-Investition von einem Wagnis in eine geplante, beherrschbare Entscheidung.

So gehst du in die Sitzung

Leg die Teile zusammen, und du hast keine Bitte um Geld mehr, sondern eine Rechnung. Du zeigst, was das Problem den Betrieb heute kostet, in Zeit, Fehlern und entgangenem Geschäft. Du stellst die Kosten der Lösung daneben, offen und mit allen Folgekosten. Du nimmst die drei grossen Einwände vorweg, statt zu warten, bis sie kommen. Und du machst das Risiko klein, indem du das Projekt in Phasen mit Festpreis zerlegst, über die von Schritt zu Schritt entschieden wird.

Es geht nicht darum, die Geschäftsleitung zu überreden. Es geht darum, ihr eine Entscheidung zu ermöglichen, die sie mit gutem Gewissen mittragen kann, auch ohne den Code je zu sehen. Ist dein Business Case so gebaut, hat sie alles, was sie dafür braucht. Und du hast aus einem Bauchgefühl ein Argument gemacht, das in der Sprache spricht, die im Sitzungszimmer zählt.