Individualsoftware oder Standardprodukt? Ein Entscheidungsrahmen, der Dein Budget nicht verbrennt

Alle paar Jahre steht ein Unternehmen an derselben Gabelung: Das Tabellenchaos ist unerträglich geworden, das Standardprodukt passt „fast“, und jemand sagt: „Warum bauen wir nicht einfach unser eigenes?“ Beide Richtungen haben Friedhöfe. Standard-Einführungen, die nie zur Arbeitsweise der Firma passten; Individual-Projekte, die zwei Jahre dauerten und die Hälfte des Versprochenen lieferten. Der Rahmen unten ist, wie wir es schriftlich ausdiskutieren, bevor ein Dirham fließt.

Wann das Standardprodukt gewinnt

Kauf das Produkt, wenn der Prozess, den es abdeckt, nicht das ist, was Dich unterscheidet: Buchhaltung, Gehälter, E-Mail, Personalakten. Das sind Commodity-Prozesse, das Paket ist billiger, schneller ausgerollt und wird von jemandem gewartet, der Tausende Kunden hat. Der Fehler ist nicht, Commodity-Software zu kaufen; der Fehler ist, Deine differenzierenden Prozesse dafür zu verbiegen.

Wann Individual sich lohnt

Bau, wenn der Prozess Dein Vorsprung ist: wie Du kalkulierst, wie Du Produktion einplanst, wie Du Kunden bedienst, wie es Wettbewerber nicht tun. Individualsoftware ist dort keine Ausgabe, sie ist der Mechanismus, der den Vorteil wiederholbar und skalierbar macht. Der andere klare Fall: wenn Abtippen zwischen Systemen täglich Stunden frisst. Integrationssoftware ist unglamourös und bezahlt sich mit beschämender Geschwindigkeit selbst.

Der hybride Weg für die meisten

Behalt den Standardkern (ERP, Buchhaltung) und bau die dünne Individualschicht drumherum: das Angebotsportal auf dem ERP, die Kunden-App, die daraus liest, das Dashboard, das ihn mit dem Webshop verbindet. Du bekommst die Herstellerwartung für den Commodity-Teil und Deinen eigenen Vorteil auf der Schicht, die zählt, ohne Zwei-Jahres-Megaprojekt.

Die vier Fragen vor der Entscheidung

Ist dieser Prozess Differenzierung oder Commodity? Was kostet das Standardprodukt über fünf Jahre, Lizenzen und erzwungene Upgrades inklusive? Was kostet der Individual-Build über dieselben fünf Jahre, Wartung inklusive, nicht nur der Baupreis? Und wem gehört der Code, wenn wir uns vom Entwickler trennen? (Wenn die Antwort auf die letzte nicht „uns, schriftlich“ lautet: geh.)

Woran Builds wirklich scheitern

Selten an der Technik. Sie scheitern an nie aufgeschriebenem Umfang, an einem fixen Termin, der auf eine unfixierte Wunschliste trifft, und an übersprungener Discovery, um „Zeit zu sparen“. Die Abhilfe ist langweilig und funktioniert: eine bezahlte Discovery-Phase, die die Architektur und ein schriftliches Angebot für Release eins liefert, mit Umfang und kommerziellen Bedingungen darin. Klein genug, um in Monaten zu shippen, echt genug, um den Wert zu beweisen. Wer Dir eine große Zahl für einen großen Build ohne Discovery nennt, rät mit Deinem Geld.