Make or Buy? Meist ist die Antwort: Extend.

Make or Buy, selbst bauen oder kaufen: So wird fast jede Softwareentscheidung im Mittelstand gestellt. Die Frage hat einen Haken. Sie kennt nur zwei Antworten, und beide kosten etwas, das in keinem Angebot steht.

Wer kauft, passt fast immer den eigenen Ablauf an das Tool an. Wer selbst baut, baut auch alles nach, was es längst gibt. Dazwischen liegt eine dritte Option, die in der Praxis am häufigsten passt: Extend. Die Standardsoftware bleibt, und der eine Ablauf, der Sie besonders macht, bekommt sein eigenes Stück Software dazu.

Buy: wo Standard richtig ist#

Buchhaltung, Lohn, E-Mail, Zeiterfassung, Dokumentenablage: Damit unterscheidet sich kein Unternehmen von seinem Wettbewerber. Kein Kunde kommt zu Ihnen, weil Ihre Lohnabrechnung besonders ist. Hier ist es richtig, sich an das Tool anzupassen. Der Anbieter verfolgt Gesetzesänderungen, pflegt die Schnittstelle zum Steuerberater und verteilt die Kosten dafür auf viele Kunden. Wer hier selbst baut, bezahlt für etwas, das es schon gibt.

Die Faustregel aus Warum Individualsoftware? gilt: Deckt ein Standard-Tool 90 Prozent Ihrer Anforderungen ab, ist es meist günstiger, die restlichen 10 Prozent anzupassen, als neu zu bauen.

Die Regel hat eine Voraussetzung, die man leicht überliest. Sie gilt, solange die 10 Prozent nicht der Grund sind, warum Kunden bei Ihnen kaufen.

Wenn Buy zu weit geht#

Nehmen Sie einen Hersteller von Sonderteilen mit 80 Mitarbeitenden. Ein erfundenes Beispiel, aber Sie kennen die Lage. Was ihn von der Konkurrenz unterscheidet, steht in keinem Prospekt: Wer anruft, hat am selben Tag eine Rückmeldung. Der Kunde weiß jederzeit, wo sein Auftrag steht, weil der Innendienst es ihm sagt. Und wenn etwas nicht in den Katalog passt, findet jemand eine Lösung.

Dann kommt das neue ERP. Gute Software, sauber eingeführt. Nur braucht jede Sonderanfertigung jetzt einen Artikelstamm, und den legt die Stammdatenstelle einmal pro Woche an. Die Rückmeldung wartet auf den Wochenlauf. Der Kunde sieht im Kundenportal einen Status, der nichts über seinen Auftrag sagt, also ruft er wieder an. Der Sonderfall, früher der Grund, warum er hier bestellt hat, ist jetzt ein Vorgang mit Wartezeit.

Zwei Jahre später läuft alles ordentlich. Der Hersteller arbeitet wie jeder andere, der dasselbe System nutzt. Genau das ist das Problem.

Die Lösung ist trotzdem nicht, das ERP abzulösen. Artikel, Buchungen und Rechnungen sind dort gut aufgehoben. Was fehlt, ist eine schmale Anwendung für die Sonderanfrage: Der Innendienst erfasst sie, klärt sie und antwortet am selben Tag, und erst wenn der Auftrag steht, legt die Anwendung den Artikel im ERP an. Das ERP bleibt, der Ablauf auch.

Drei Zeichen, dass Sie sich verbiegen#

In jedem Unternehmen gibt es den einen Ablauf, mit dem es Kunden gewinnt und hält. Ob Sie genau diesen Ablauf an ein Tool angepasst haben, zeigen drei Zeichen.

Die Liste neben dem System. Jemand pflegt eine Excel-Datei, eine Tabelle in Teams oder einen Zettel an der Wand, weil das System eine Information nicht kennt, die für Ihre Kunden zählt. Die Liste ist kein Versäumnis der Mitarbeitenden. Sie ist der Ablauf, der im Tool keinen Platz gefunden hat.

Ein neuer Satz gegenüber Kunden. „Das geht bei uns so nicht.“ Hören Sie hin, ob Ihr Team das sagt, und ob es das vor dem Tool auch gesagt hat. Wenn nicht, hat das System eine Grenze gezogen, wo vorher Ihre Stärke lag.

Der Sonderfall als Ausnahme. Früher war der Sonderfall das Argument: Bei denen geht auch, was sonst keiner macht. Heute ist er eine Ausnahme im Ticketsystem, mit eigener Kategorie und eigener Wartezeit. Wenn Ihre besten Kunden vor allem Sonderfälle bestellen, erleben sie jetzt vor allem die Wartezeit.

Wer eines davon wiedererkennt, muss das System nicht ablösen. Er weiß aber, an welcher Stelle es eine Erweiterung braucht.

Extend: Standard behalten, Ablauf dazubauen#

Extend heißt: Die Standardsoftware bleibt das System, in dem die Daten liegen. Daneben läuft ein schmales Stück eigene Software für genau den einen Ablauf. Es liest und schreibt über die offizielle Schnittstelle, sodass der Anbieter sein Produkt weiter pflegt und Sie Ihren Ablauf behalten. Zwei Beispiele aus unserer Arbeit.

Ein Shop in sieben Sprachen, ohne Übersetzungsdienst davor. Bei LOULEX lief die Übersetzung über einen Dienst, der als Schicht vor dem Shop lag, für 299 € im Monat. Shopify selbst kannte die Übersetzungen nicht. Heute bleibt Shopify das System für alle Texte. Ein eigener Bot prüft stündlich, was fehlt, übersetzt gegen ein Glossar, kontrolliert Zahlen, Platzhalter und Markenbegriffe und schreibt das Ergebnis als native Shopify-Übersetzung zurück. Nebenbei sind sechs Apps rausgeflogen, ihre Funktionen laufen jetzt im Theme.

Buchhaltung, die bleibt, wo sie ist. Unsere eigenen Rechnungen, Angebote und Zahlungserinnerungen laufen über Lexware Office. Daran ändern wir nichts, es ist Standard und soll es bleiben. Dazugebaut haben wir eine Erweiterung, über die unser eigener Assistent Belege vorbereitet und Erinnerungen vorschlägt. Freigegeben wird von Hand, gebucht wird in Lexware. Den Kern davon haben wir als Open Source veröffentlicht.

Beide Male hat niemand ein System abgelöst. Und beide Male passt sich die Software an den Ablauf an, nicht umgekehrt.

Make: wenn der Ablauf das Produkt ist#

Selbst bauen lohnt sich dort, wo es nichts gibt, das man sinnvoll erweitern könnte, weil der Ablauf selbst die Leistung ist. Diese Entscheidung haben wir für ein eigenes Unternehmen getroffen. die macher ist unsere Gründung in Metzingen: ein Ansprechpartner für Sanierung, Umbau und Ausbau, mit Betrieben aus einem festen Partnernetz. die macher berät, holt Angebote ein und hält das Projekt zusammen. Die Werkverträge laufen direkt zwischen Kunde und Betrieb.

Ein Ansprechpartner statt fünf. Kunde, Projektleitung und Betriebe sehen dasselbe Projekt, jeder seinen Teil. Hätten wir diesen Ablauf in ein gekauftes Projekttool gepresst, hätten wir genau das angepasst, wofür Kunden zu die macher kommen. Also haben wir ihn gebaut. Drei Dinge daran zeigen, was dabei anders wird.

Vom Telefon, auf der Baustelle. Ein Portal, das Handwerker nicht benutzen, ist keins. Deshalb ist der Weg für den Betrieb der kürzeste: Eintrag ins Telefon diktieren, zwei Fotos anhängen, fertig. Das Modell bringt den Text in Form, der Eintrag steht für alle Berechtigten im Projekt.

Ein Satz statt zwanzig Felder. Wer ein Haus sanieren will, weiß selten, welche Gewerke er braucht. Deshalb beginnt die Anfrage nicht mit einem Formular, sondern mit einem Satz, getippt oder gesprochen. Claude zerlegt ihn in Gewerke, das Ergebnis wandert direkt in die Anfrage. Wer keine KI will, nimmt das Formular.

Rechte, die der Arbeit folgen. Dieselbe Person kann in einem Projekt als Betrieb arbeiten und im nächsten selbst Kunde sein. Deshalb hängen Rechte an der Rolle im Projekt, nicht am Konto: Projektleitung, Kunde, Gewerk oder Beobachter. Ein Betrieb sieht nur seine eigenen Angebote, ein Beobachter liest mit, der Kunde entscheidet.

Auch hier ist nicht alles selbst gebaut. Buchhaltung, E-Mail und Kalender bleiben Standard. Gebaut ist nur, was die macher von anderen unterscheidet. Den ganzen Aufbau zeigt die Referenz zu die macher.

Die Entscheidung#

Make or Buy ist also die falsche Frage. Es sind drei.

Wo sind Sie Standard? Dort kaufen Sie, passen sich an und sind froh darüber.

Wo ist Ihr Ablauf der Vorsprung, läuft aber auf Standard? Dort erweitern Sie. Das System bleibt, der Ablauf bekommt sein eigenes Stück Software daneben.

Ist der Ablauf selbst Ihr Produkt? Dann bauen Sie, schmal und mit allem, was Standard ist, weiterhin gekauft.

Egal ob Extend oder Make: Bauen Sie nicht so, wie Software früher eingekauft wurde. Kein Lastenheft, das jeden Fall vorwegnimmt. Die erste Version geht nach Tagen an echte Leute, mit echten Daten. Was keiner anfasst, wird gestrichen. Was fehlt, zeigt sich im Gebrauch, nicht im Workshop.

Häufige Fragen#