Eigene Software rechnet sich erst, wenn der Unterschied das Geschäft betrifft.

Ein KMU braucht Software für einen Ablauf, der bisher in Excel, in Mails und im Kopf einer Person lag. Der Softwareanbieter zeigt sein Produkt und es passt zu 80 Prozent. Der Entwickler schaut sich den Ablauf an und sagt, er baue das genau so, wie es gebraucht wird. Beide meinen es ehrlich und beide verdienen an ihrer Empfehlung. Im Unternehmen kann niemand die beiden Wege vergleichen, weil dafür Preis, Wartung, Verträge und Betrieb zusammen auf den Tisch müssen. Wir rechnen den Vergleich hier einmal durch und nennen die drei Fälle, in denen Bauen gewinnt.

Der Vergleich beginnt bei den Kosten, die nach dem Kauf kommen.

Die Offerte des Anbieters nennt einen Preis pro Benutzer und Monat. Die Offerte des Entwicklers nennt einen Preis für den Bau. Keine der beiden Zahlen ist die, die zählt, weil beide Wege nach dem ersten Tag weitergehen. Beim Kauf kommen die Einführung dazu, die Anpassungen, damit die fehlenden 20 Prozent nicht ganz fehlen und die Zeit im Unternehmen, um die Daten zu übernehmen und die Leute einzuarbeiten. Beim Bau kommt die Wartung dazu und die ist keine Nebensache: Wir rechnen mit 15 bis 20 Prozent der Baukosten pro Jahr, weil Betriebssysteme, Bibliotheken und Schnittstellen sich ändern und jemand die Software nachziehen muss, sonst läuft sie in zwei Jahren nicht mehr sicher. Dazu kommen Hosting, Backup und die Zeit im Unternehmen für Tests und Abnahmen, die beim Bau deutlich höher ist als beim Kauf.

Drei Jahre sind der Zeitraum, über den sich das ehrlich vergleichen lässt. Kürzer verzerrt zugunsten des Kaufs, weil die Baukosten ganz am Anfang liegen. Länger ist eine Schätzung, weil sich nach drei Jahren die Anforderungen, die Preise des Anbieters und meistens auch das Unternehmen verändert haben.

Über drei Jahre gerechnet gewinnt das fertige Produkt fast immer.

Ein Rechenbeispiel für ein KMU mit 20 Mitarbeitenden, von denen 15 mit der Software arbeiten. Das fertige Produkt kostet CHF 40 pro Benutzer und Monat, also CHF 7'200 pro Jahr und CHF 21'600 über drei Jahre. Einführung, Datenübernahme und die zwei Anpassungen, ohne die es nicht geht, kosten einmalig CHF 8'000. Zusammen sind das CHF 29'600.

Die eigene Lösung kostet im Bau CHF 60'000, was für ein Werkzeug mit Benutzerverwaltung, zwei Schnittstellen und einer sauberen Oberfläche eine realistische Grössenordnung ist. Die Wartung liegt bei 15 Prozent, also CHF 9'000 pro Jahr und CHF 27'000 über drei Jahre. Hosting und Backup kosten CHF 100 pro Monat, also CHF 3'600. Zusammen sind das CHF 90'600, das Dreifache des Produkts. Die Zahlen sind ein Rechenbeispiel, keine Offerte. Die Verhältnisse dahinter stimmen aber bei den meisten Vergleichen, die wir sehen: Wer nur die beiden Offerten nebeneinander legt, sieht ein Drittel des Unterschieds und wer die Wartung vergisst, rechnet die eigene Lösung um ein Drittel zu günstig.

Bei diesem Ergebnis ist der Entscheid klar und er heisst kaufen. Das gilt für die Buchhaltung, die Zeiterfassung, das CRM, den Onlineshop und für fast alles, was in vielen Unternehmen gleich abläuft. Ein Anbieter, der dasselbe Problem für tausend Kunden löst, verteilt seine Entwicklung auf tausend Rechnungen. Das kann kein Bau für ein einzelnes Unternehmen unterbieten.

Die fehlenden 20 Prozent kosten beim Kauf nicht null.

Die Rechnung oben hat eine Lücke und sie liegt bei den 20 Prozent, die das Produkt nicht abdeckt. Diese 20 Prozent verschwinden nicht, sie werden umgangen. Neben dem Produkt entsteht wieder eine Excel Tabelle, eine Person trägt Daten doppelt ein, oder ein Ablauf wird so verbogen, dass er ins Produkt passt. Das kostet keine Lizenz, aber Zeit und Zeit lässt sich rechnen.

Im selben Beispiel brauchen drei Mitarbeitende je eine halbe Stunde am Tag für den Umweg. Das sind 1,5 Stunden pro Tag, bei 220 Arbeitstagen 330 Stunden im Jahr. Zu internen Kosten von CHF 80 pro Stunde sind das CHF 26'400 pro Jahr und CHF 79'200 über drei Jahre. Damit liegt der Kauf bei CHF 108'800 und die eigene Lösung bei CHF 90'600 und das Bild hat gedreht. Der Unterschied zwischen den beiden Rechnungen ist nicht die Software, sondern die Frage, ob der Umweg im täglichen Betrieb liegt oder im Monatsabschluss. Eine halbe Stunde am Tag für drei Leute kippt den Vergleich. Eine halbe Stunde im Monat für eine Person tut es nicht und dann bleibt kaufen richtig.

Deshalb steht in der Überschrift, dass sich eigene Software erst rechnet, wenn der Unterschied das Geschäft betrifft. Solange die fehlenden 20 Prozent eine Unannehmlichkeit sind, bezahlt man sie mit einer Excel Tabelle. Sobald sie den Betrieb bestimmen, bezahlt man sie mit Arbeitszeit und ab dann ist der Bau die günstigere Variante.

Bauen gewinnt in drei Fällen und in keinem davon geht es zuerst um den Preis.

Der erste Fall ist, dass der Ablauf das ist, womit das Unternehmen sein Geld verdient. Wenn die Kunden genau deshalb kommen, weil eine Offerte in einer Stunde statt in drei Tagen da ist oder weil ein Auftrag anders abgewickelt wird als bei allen anderen, dann bildet ein Standardprodukt diesen Unterschied nicht ab, weil es für alle anderen gebaut wurde. Wer hier kauft, gleicht sich dem Markt an und bezahlt dafür Lizenz.

Der zweite Fall ist, dass kein Produkt den Kern abdeckt. Passt das beste Produkt zu 50 Prozent statt zu 80, kostet der Weg über Anpassungen mehr als der Bau, weil Anpassungen an Standardsoftware teuer sind, beim nächsten Update des Anbieters brechen und mit jedem Jahr schwerer zu warten sind als eigener Code. Bei 80 Prozent ist eine Anpassung ein Zusatz. Bei 50 Prozent ist sie ein zweites Produkt, das auf dem ersten sitzt.

Der dritte Fall ist, dass die Abhängigkeit vom Anbieter nicht tragbar ist. Ein Produkt bestimmt, wo die Daten liegen, unter welchen Bedingungen, zu welchem Preis im nächsten Jahr und wie sie beim Wechsel wieder herauskommen. Für die Zeiterfassung ist das egal. Für die Daten, mit denen das Unternehmen arbeitet, ist es ein Entscheid der Geschäftsleitung, wie wir ihn für die KI Werkzeuge beschrieben haben und wenn dieser Entscheid gegen den Anbieter ausfällt, bleibt nur der Bau.

Trifft keiner der drei Fälle zu, ist der Bau ein teures Hobby. Trifft einer zu, rechnet er sich, auch wenn die Offerte am Anfang dreimal höher liegt.

Wer baut, kauft sich einen Betrieb dazu.

Der Entwickler liefert die Software und ab dann gehört sie dem Unternehmen, mit allem, was dazukommt. Jemand muss die Bibliotheken aktuell halten, die Sicherheitslücken schliessen, das Hosting bezahlen und den Restore geprüft haben, bevor er nötig ist. Beim Kauf erledigt das der Anbieter und genau dafür ist die Lizenz da. Beim Bau muss es jemand im Unternehmen verantworten, auch wenn er es nicht selber macht.

Drei Dinge gehören deshalb in jeden Bauvertrag, bevor er unterschrieben wird. Der Quellcode gehört dem Unternehmen, nicht dem Entwickler und liegt an einem Ort, auf den das Unternehmen Zugriff hat. Die Wartung ist mit Preis und Reaktionszeit vereinbart, nicht als Zusage im Gespräch. Und eine zweite Person oder Firma kann die Software übernehmen, weil sie dokumentiert ist und in gängiger Technik gebaut wurde, nicht in dem, was der Entwickler gerade spannend fand. Wer diese drei Punkte nicht regelt, hat nach drei Jahren eine Software, die läuft und niemanden, der sie anfassen kann.

Der Entscheid, ob gebaut, gekauft oder gelassen wird, ist die Kernaufgabe eines CTO. In einem KMU ohne diese Rolle fällt er trotzdem, meistens dort, wo die überzeugendere Offerte liegt.

Der Entscheid braucht Zahlen über drei Jahre und jemanden, der nicht mitverdient.

Der Weg zum Entscheid ist kurz, wenn man ihn in der richtigen Reihenfolge geht. Zuerst steht auf einer Seite, was gelöst sein muss, getrennt von dem, was schön wäre, weil die fehlenden 20 Prozent erst dann eine Zahl bekommen. Dann liegen für beide Wege Offerten auf dem Tisch und beide werden über drei Jahre gerechnet, mit Wartung, Hosting, Anpassungen und der Zeit im Unternehmen. Am Schluss steht die Frage, ob einer der drei Fälle zutrifft. Wer beide Zahlen hat und die Frage beantworten kann, braucht niemanden von aussen und sollte entscheiden.

Wer eine der Zahlen nicht bekommt, weil der Anbieter die Wartung nicht beziffert oder der Entwickler den Umweg im Betrieb nicht kennt, hat ein Vergleichsproblem, kein Softwareproblem. Für diesen Fall gibt es bei uns ein Format mit Pauschalpreis: Wir klären die Anforderungen, holen die Offerten für beide Wege ein, rechnen sie durch und empfehlen einen Weg, mit Begründung und Preis. Wir verdienen weder an der Lizenz noch am Bau und das ist der Grund, warum die Empfehlung etwas wert ist.