Warum gute Software Branchenwissen braucht:
Fachexpertise als Fundament der Entwicklung

Eine Bestellung, die es nicht geben dürfte

Ein Handelsunternehmen verkauft Produkte, die auf Kundenwunsch bedruckt oder graviert werden. Der Web-Konfigurator, vor zwei Jahren von einem technisch soliden Team gebaut, führt die Veredelungsverfahren als Aufpreisliste: Häkchen setzen, Aufpreis addiert sich, Bestellung abschicken. Die Software stürzt nie ab, rechnet korrekt und sieht ordentlich aus.

Im Fach gelten allerdings Regeln, die in keiner Aufpreisliste stehen. Eine Gravur braucht einen Materialuntergrund, der sie trägt. Ein Verfahren erlaubt vier Farben, ein anderes an derselben Stelle nur eine. Die nutzbare Druckfläche hängt von Position und Krümmung des Produkts ab.

Vollständig ausschließen lässt sich eine nicht produzierbare Bestellung durch keine Software – Materialien, Motive und Grenzfälle sind dafür zu vielfältig, und die abschließende fachliche Prüfung bleibt in dieser Branche ein fester Arbeitsschritt. Der Unterschied liegt darin, was bei dieser Prüfung ankommt: Ein fachkundig gebautes Regelwerk fängt die bekannten Ausschlüsse schon vor der Bestellung ab und lässt nur die echten Grenzfälle durch. Dieser Konfigurator kennt keine einzige der Abhängigkeiten und reicht jede Kombination ungefiltert weiter.

Die Folgen trägt der Innendienst. Jede Bestellung muss von Hand geprüft werden, jede zweite wird telefonisch geklärt und korrigiert; die Auftragsbestätigung verzögert sich, und jede Klärungsschleife kostet Marge. Auf dem Papier hat das Unternehmen einen Konfigurator. Im Alltag hat es eine zusätzliche Fehlerquelle mit angeschlossener Handarbeit.

Der blinde Fleck: was im Lastenheft nie steht

Ein Lastenheft beschreibt die Anforderungen an eine Software aus Sicht des Auftraggebers: was das System können soll, für wen und unter welchen Bedingungen. Als Vertragsgrundlage ist es unverzichtbar. Als alleinige Wissensquelle für die Entwicklung scheitert es an drei Mechanismen, die sich in Anforderungsworkshops regelmäßig wiederholen.

Erstens nennen Fachleute ihre Ausnahmen nicht, weil sie ihnen selbstverständlich sind. Dass eine Nachbestellung mit geänderter Veredelung anders kalkuliert wird als der Erstauftrag, erwähnt niemand – aus Sicht der Fachabteilung ist das Alltag und keiner Erwähnung wert. Zweitens beschreiben Befragte Prozesse, wie sie gedacht sind, und lassen weg, wie sie tatsächlich laufen: mit der Nebenliste in der Tabellenkalkulation, dem Zuruf über den Flur, dem Zettel am Bildschirmrand. Drittens kennt kaum jemand die Kosten der eigenen Behelfe, weil sie nie gemessen wurden.

Der Philosoph Michael Polanyi hat für dieses Phänomen den Begriff des impliziten Wissens geprägt: Menschen wissen mehr, als sie in Worte fassen können („The Tacit Dimension", 1966). Die Organisationsforscher Ikujirō Nonaka und Hirotaka Takeuchi haben gezeigt, dass sich dieses Wissen vor allem über gemeinsame Erfahrung überträgt und nur zu einem kleinen Teil über Dokumente („The Knowledge-Creating Company", 1995). Für Software-Projekte heißt das: Der wertvollste Teil des Fachwissens erreicht ein externes Entwicklungsteam über Interviews und Dokumente gerade nicht.

Wie eng die Grenzen eines Anforderungsdokuments bereits bei überschaubaren Web-Projekten verlaufen, zeigt der Beitrag zum Aufbau eines belastbaren Website-Briefings – bei Unternehmenssoftware mit über Jahre gewachsenen Prozessen vervielfacht sich der Effekt.

Fallstudie: der Regiebericht, der am Fahrzeuglager scheitert

Der folgende Fall ist typisiert, sein Muster stammt aus dem Bau- und Ausbauhandwerk. Ein Sanitär- und Heizungsbetrieb aus dem Raum Hildesheim führt eine mobile Erfassung für Regieberichte ein: Monteure dokumentieren Arbeitszeit und Material direkt auf der Baustelle, die Rechnung entsteht ohne Zettelwirtschaft. In der Vorführung wirkt alles schlüssig.

Nach drei Monaten stimmen weder Lagerbestand noch Fakturierung. Die Ursache liegt in einer fehlenden Unterscheidung im Datenmodell: Das System kennt als Quelle jeder Materialentnahme nur das Hauptlager und bucht dort zum Zeitpunkt des Einsatzes ab. Das Fahrzeuglager des Monteurs existiert im Modell nicht – dabei wurde es Wochen vorher aus dem Hauptlager befüllt und dort bereits ausgebucht. Erfasst der Monteur ein Absperrventil vom Fahrzeug, zieht das System es ein zweites Mal vom Bestand ab; lässt er die Buchung deshalb weg, fehlt die Position später auf der Rechnung. Die Monteure wählen im Alltag den Weg, der keine sichtbaren Bestandsfehler erzeugt – und erzeugen damit unfakturierte Entnahmen.

Dazu kommt die fehlende Vorgangsart: Ein Einsatz im Gewährleistungsfall darf keine Regie-Rechnung auslösen, dieselbe Arbeit im Kundenauftrag muss es. Ohne dieses Merkmal entscheidet die Erinnerung des Innendienstes darüber, welcher Bericht fakturiert wird – mit Fehlern in beide Richtungen.

Was das kostet, lässt sich ohne Studie beziffern, mit den Zahlen des eigenen Betriebs: die Materialpositionen je Monat, die in keiner Rechnung auftauchen, multipliziert mit ihrem durchschnittlichen Verkaufswert – dazu die Stunden, die Buchhaltung und Lagerleitung mit dem Abgleich der Differenzen verbringen. Ein fachkundiges Team hätte das Fahrzeuglager als eigenen Bestandskreis und die Vorgangsart als Pflichtmerkmal angelegt, weil es den Unterschied aus eigener Praxis kennt. Nachträglich eingebaut, verlangte dieselbe Korrektur eine Nacherfassung der Altdaten.

Was Fachexpertise im Code konkret verändert

Branchenkenntnis wirkt an vier Stellen einer Software, und sie wirkt dort unterschiedlich tief. Die Reihenfolge der folgenden Abschnitte entspricht der Reihenfolge, in der sich Fehler später korrigieren lassen – von kaum bis vergleichsweise leicht.

Datenmodell: Was ein eigenes Objekt wird

Ein Datenmodell legt fest, welche Begriffe des Fachgebiets in der Software eigenständige Objekte werden und welche nur Eigenschaften anderer Objekte sind. Ob eine Veredelung ein eigenes Objekt mit Regeln, Preisen und Verträglichkeiten ist oder ein Textfeld am Artikel, entscheidet über alles, was später darauf aufbaut: Auswertung, Automatisierung, Konfigurator. Diese Entscheidung fällt in den ersten Wochen eines Projekts und lässt sich im laufenden Betrieb kaum noch revidieren, weil jede Änderung sämtliche Altdaten betrifft.

Regelwerk: Grenzen mit fachlicher Begründung

Das Regelwerk umfasst Gültigkeits-, Preis- und Ausschlussregeln, deren Begründung im Fach liegt und in keinem Handbuch der Softwaretechnik. Dass ein Verfahren eine Mindestauflage hat, dass ein Aufpreis je Farbe nur bei mehrfarbigen Verfahren anfällt, dass zwei Optionen einander ausschließen – solche Regeln kann nur formulieren, wer das Fach kennt. Ein fachfremdes Team baut, was im Lastenheft steht, und das ist nach dem vorigen Kapitel der kleinere Teil.

Oberfläche: die Reihenfolge des echten Arbeitsablaufs

Eine gute Eingabemaske folgt dem Ablauf am Arbeitsplatz: Die Felder stehen in der Reihenfolge, in der die Information beim Telefonat oder am Tresen tatsächlich anfällt, häufige Werte sind vorbelegt, und die Hände bleiben auf der Tastatur. DIN EN ISO 9241-110 fasst die zugrunde liegenden Interaktionsprinzipien – unter anderem Aufgabenangemessenheit und Erwartungskonformität – normativ zusammen (Ausgabe 2020). Die Norm benennt die Prinzipien; welche Reihenfolge und welche Standardwerte im konkreten Fach richtig sind, weiß nur, wer den Arbeitsplatz kennt.

Sonderfälle: der Alltag jenseits des Idealvorgangs

Teillieferung, Storno nach Produktionsfreigabe, Nachbestellung mit abweichender Charge: Sonderfälle machen in vielen Betrieben einen spürbaren Teil der Vorgänge aus und einen Großteil der Supportfälle. Software, die nur den Idealvorgang abbildet, zwingt genau diese Fälle in Behelfe außerhalb des Systems. Wer die Branche kennt, kennt die Sonderfälle vorab und modelliert sie mit.

Über den Wert einer Software entscheiden die ersten beiden Ebenen; Oberfläche und Sonderfallbehandlung machen diesen Wert im Tagesgeschäft verfügbar. Ein ansprechendes Frontend über einem fachlich falschen Datenmodell verschiebt die Probleme lediglich dorthin, wo sie teurer werden.

Vierzehn Software-Gattungen, in denen Fachwissen den Unterschied macht

Der folgende Katalog ordnet die Programmarten, die in Handels-, Fertigungs- und Dienstleistungsbetrieben auf Fachwissen angewiesen sind – jeweils mit dem Punkt, an dem Branchenkenntnis über die Qualität entscheidet. Er reicht von Systemen, die als fachneutral gelten (CMS, CRM, Warenwirtschaft), bis zur Branchen-Spezialsoftware. Viele Beispiele stammen aus dem Umfeld veredelbarer Produkte; das Muster überträgt sich auf andere Branchen.

1. Warenwirtschaft und ERP-Kern: Führt Artikel, Bestände, Aufträge und Belege in einem System zusammen. Der Stolperstein liegt im Artikelstamm: Ob Varianten, Maße und Veredelungen als eigene Datenobjekte oder als Freitext geführt werden, entscheidet darüber, ob spätere Auswertungen und Automatisierungen überhaupt möglich sind.
2. Kalkulations-Engine: Errechnet Verkaufspreise aus Einkauf, Staffeln, Einrichte- und Klischeekosten, Fremdwährungen sowie Fracht- und Zollanteilen. Fachlich heikel ist die Mischkalkulation: Einmalige Rüstkosten verhalten sich anders als stückabhängige Kosten, und wer beides in einem Aufschlagssatz verrührt, kalkuliert kleine Auflagen zu billig und große zu teuer.
3. Produktinformationssystem (PIM): Pflegt beschreibende Daten zentral – Druckflächen, Farbräume, Toleranzen, Pflichtangaben, Übersetzungen. Ohne Fachkenntnis wird die Druckfläche als einfaches Maßfeld angelegt; tatsächlich hängt sie von Verfahren und Position am Produkt ab und braucht eine eigene Struktur je Kombination.
4. Angebots- und Auftragsverwaltung: Steuert den Weg von der Anfrage über Muster- und Freigabeprozesse bis zum Auftrag. Der fachliche Kern ist der Freigabeschritt: Zwischen Angebot und Produktion liegt in vielen Branchen ein Korrekturabzug, den der Kunde bestätigen muss – fehlt dieser Status im System, laufen Freigaben per E-Mail am System vorbei.
5. Kundenbeziehungs-System (CRM): Führt Kontakte, Vorgänge und Verkaufschancen zusammen und hält die Historie jeder Kundenbeziehung. Der Stolperstein liegt im Beziehungsmodell: Zentrale und Niederlassungen, Einkäufer, Anwender und Rechnungsempfänger, dazu branchentypische Kauf-Rhythmen – ein generisches Kontaktmodell ohne diese Struktur drängt den Vertrieb zurück in Freitextnotizen, die sich weder auswerten noch übergeben lassen.
6. Produkt- und Veredelungskonfigurator: Lässt Kunden im Web ein Produkt mit Optionen zusammenstellen und zeigt den Preis live. Er ist nur so gut wie das Regelwerk dahinter: Bekannte Ausschlüsse müssen vor der Bestellung greifen, erkennbare Grenzfälle als solche markiert an die fachliche Prüfung gehen – ein Konfigurator ohne dieses Regelwerk verlagert die gesamte Prüfarbeit in den Innendienst.
7. Content-Management-System (CMS): Verwaltet die Inhalte des Web-Auftritts. Auch hier entscheidet Fachkenntnis: Ob Referenzprojekte, Produktdaten oder Standorte als strukturierte Inhaltstypen mit Pflichtfeldern angelegt werden oder als freie Textseiten, bestimmt, ob sich Inhalte später filtern, mehrsprachig pflegen und maschinenlesbar ausgeben lassen. Welche Inhaltstypen ein Betrieb wirklich braucht, verrät nur das Fach.
8. Druckdaten- und Layoutprüfung: Prüft angelieferte Dateien auf Vektorpflicht, Mindestgrößen, Farbanzahl und Beschnitt. Fachwissen entscheidet hier über die Prüfregeln selbst: Welche Mindestlinienstärke ein Verfahren verträgt, steht in keiner allgemeinen Programmbibliothek.
9. Beschaffung und Lieferantenanbindung: Importiert Kataloge und Preislisten, fragt Verfügbarkeiten ab und steuert das Streckengeschäft. Stolperstein sind die Datenstrukturen der Lieferseite: Wer die üblichen Formate der Branche kennt, baut Importe, die auch Preisänderungen und Sortimentswechsel überstehen.
10. Dokumentenautomatisierung: Erzeugt Auftragsbestätigungen, Freigabeprotokolle und Lieferscheine und prüft Eingangsrechnungen. Anspruchsvoll ist die Rechnungsprüfung bei mehrstufigen Aufträgen: Teillieferungen, nachträgliche Zuschläge und Fremdleistungen müssen dem richtigen Vorgang zugeordnet werden.
11. Logistik- und Versandsteuerung: Plant Teillieferungen, das Routing über externe Veredeler und die Sendungsverfolgung. Der Sonderfall Fremdveredelung – Ware geht erst zum Dienstleister, dann zum Kunden – sprengt jedes Versandmodul, das nur den Weg vom Lager zum Kunden kennt.
12. Auswertung und Berichtswesen (BI): Macht aus Bewegungsdaten Entscheidungsgrundlagen. Fachwissen zeigt sich in der Wahl der Kennzahl: Der Deckungsbeitrag je Auftrag verrät mehr über die Ertragskraft als der Umsatz je Kunde, setzt aber voraus, dass Einrichtekosten und Fremdleistungen dem Auftrag sauber zugebucht wurden.
13. KI-Bausteine: Klassifizieren eingehende Anfragen, ordnen Produkte aus Freitext zu, extrahieren Beleg- und Rechnungsdaten und erzeugen Produkttexte. Ihr Nutzen steht und fällt mit fachkundig strukturierten Daten: Ein Modell, dem Veredelungsverfahren als Kategorie fehlen, kann Anfragen dazu nicht zuverlässig zuordnen.
14. Schnittstellen und Betrieb: Verbindet das System mit Buchhaltung, Zahlungs- und Versanddienstleistern und regelt Rollen, Rechte und Mandanten. Die fachliche Zuordnung ist der anspruchsvolle Teil – etwa welche Belegart auf welches Konto läuft und welche Rolle welche Preise sehen darf.

Sechs Anpassungstiefen: von der Einstellung bis zur Eigenentwicklung

Zwischen „Standardsoftware einführen" und „Software selbst entwickeln" liegen mehrere Zwischenstufen, die in Entscheidungsprozessen häufig vermengt werden. Die folgende Staffelung ordnet sie nach Eingriffstiefe – jeweils mit Nutzen, Grenze und dem typischen Fehlkauf.

1. Konfiguration über Stammdaten: Einstellungen, die das System vorsieht – Nummernkreise, Steuersätze, Textbausteine. Nutzen: schnell, risikoarm, updatefest. Grenze: Es lässt sich nur abbilden, was der Hersteller vorgedacht hat. Typischer Fehlkauf: ein System, dessen Vorführung nur mit Idealdaten lief und dessen Einstellungen den eigenen Prozess doch nicht erreichen.
2. Zusatzfelder und Listenansichten: Eigene Felder an Artikel, Kunde oder Auftrag plus angepasste Übersichten. Nutzen: Das Vokabular des Betriebs hält Einzug ins System. Grenze: Zusatzfelder speichern, aber sie prüfen nichts und lösen nichts aus. Typischer Fehlkauf: hundert Zusatzfelder als Ersatz für ein fehlendes Datenmodell.
3. Workflow- und Statusmodelle: Eigene Statusketten, Freigabewege, Wiedervorlagen. Nutzen: Der Prozess des Hauses wird verbindlich. Grenze: Die Objekte, zwischen denen der Workflow läuft, bleiben die des Herstellers. Typischer Fehlkauf: Freigabeketten, die im Alltag per Zuruf übersprungen werden, weil sie den realen Ablauf nicht treffen.
4. Eigene Regel- und Preislogik: Gültigkeits-, Ausschluss- und Preisregeln nach eigenen fachlichen Kriterien. Nutzen: Hier beginnt der eigentliche Wettbewerbsvorteil, weil das System Branchenregeln durchsetzt. Grenze: Komplexe Regelwerke brauchen eine benannte Pflegeverantwortung. Typischer Fehlkauf: Regeln, die niemand im Haus versteht, weil ein externer Berater sie einmalig hinterlegt hat.
5. Plugin- und Modulentwicklung im Standardsystem: Programmierte Erweiterungen innerhalb der Architektur eines Standardsystems. Nutzen: Individuallogik bei erhaltener Update-Fähigkeit. Grenze: Die Architektur des Standards setzt den Rahmen; was quer dazu liegt, wird teuer. Typischer Fehlkauf: ein Standard, der durch Dutzende Erweiterungen faktisch zur ungewarteten Eigenentwicklung geworden ist.
6. Eigenes Datenmodell, Eigenentwicklung: Die Software entsteht um die Fachlichkeit des Betriebs herum. Nutzen: Objekte, Regeln und Masken folgen vollständig dem eigenen Geschäft. Grenze: Die Verantwortung für Betrieb, Sicherheit und Weiterentwicklung liegt im Haus oder beim beauftragten Partner. Typischer Fehlkauf: Eigenentwicklung für Prozesse, die es in gleicher Form in jedem Standard gibt.

Schnittstellen verlaufen quer zu allen sechs Stufen: Ob Buchhaltungsexport, Zahlungsanbindung oder Lieferantendaten – jede Stufe braucht sie, und die fachliche Zuordnungslogik ist dabei regelmäßig aufwendiger als die technische Verbindung.

Wann Standard genügt und wann Eigenentwicklung trägt

Für die Wahl der Stufe haben sich vier Kriterien bewährt, die sich ohne technisches Vorwissen beantworten lassen:

• Anteil branchenspezifischer Regeln: Bestimmen Sonderregeln das Tagesgeschäft, trägt der Standard nur mit hohem Anpassungsaufwand.
• Zahl der Arbeitsplätze: Je mehr Menschen denselben Vorgang täglich ausführen, desto stärker zahlt sich jede eingesparte Eingabe aus.
• Halbwertszeit der Prozesse: Stabile Abläufe rechtfertigen tiefe Anpassung; Prozesse im Umbruch sprechen für lose Konfiguration.
• Abhängigkeit vom Anbieter: Wer Kernprozesse auf fremde Produkt-Roadmaps baut, sollte die Kosten eines Ausstiegs kennen.

Wo der eigene Betrieb auf dieser Staffelung steht, gehört zur digitalen Standortbestimmung – verwandt mit der Frage, die der Beitrag zum KI-Reifegrad des eigenen Betriebs für den KI-Einsatz beantwortet.

Das Usability-Argument in Zahlen

Gebrauchstauglichkeit bezeichnet nach DIN EN ISO 9241-11 das Ausmaß, in dem ein System von bestimmten Benutzern in einem bestimmten Nutzungskontext effektiv, effizient und zufriedenstellend verwendet werden kann (Ausgabe 2018). Für die Software-Entscheidung eines Geschäftsführers ist daran vor allem eines wichtig: Alle drei Größen lassen sich im eigenen Betrieb messen, ohne Labor und ohne Dienstleister. Fünf Kennzahlen reichen dafür aus.

Bearbeitungszeit je Vorgang. Stoppen Sie den häufigsten Vorgang – etwa eine Auftragserfassung – vom ersten Klick bis zum Abschluss, gemittelt über mehrere Mitarbeiter und Tage. Multipliziert mit der Zahl der Vorgänge je Monat ergibt sich die monatliche Systemzeit; jede Minute, die eine fachgerechte Maske einspart, skaliert über alle Arbeitsplätze.

Klick- und Feldanzahl je Standardvorgang. Zählen Sie, wie viele Eingaben und Wechsel zwischen Maus und Tastatur ein Vorgang verlangt. Jedes Feld, das ein fachlich sinnvoller Standardwert vorbelegen könnte, und jeder Maskenwechsel, der dem realen Ablauf widerspricht, taucht in dieser Zahl auf.

Einarbeitungsdauer. Messen Sie die Zeit, bis ein neuer Mitarbeiter den Standardvorgang ohne Hilfe fehlerfrei ausführt. Software, deren Masken dem Arbeitsablauf folgen, verkürzt diese Spanne spürbar – ein Effekt, der bei jeder Neueinstellung und jeder Vertretung erneut anfällt.

Korrekturquote. Ermitteln Sie den Anteil der Vorgänge, die nachträglich korrigiert werden: Stornos, Gutschriften, manuelle Nacharbeit. Die Quote steht in den eigenen Belegen und ist die direkteste Messgröße für ein fehlendes Regelwerk – jede Kombination, die das System zu Unrecht zulässt, wird hier sichtbar.

Fluchtquote. Schätzen Sie den Anteil der Arbeit, der das System verlässt: Nebenrechnungen in der Tabellenkalkulation, Absprachen per Zuruf, Notizen auf Papier. Wo Nebenlisten entstehen, fehlt dem System eine fachliche Struktur – die Fluchtquote zeigt, wo genau.

Auf branchenweite Prozentwerte zu Fehlerkosten und Nacharbeit verzichtet dieser Beitrag bewusst, weil öffentlich verfügbare Zahlen dazu selten methodisch belastbar auf den Einzelbetrieb übertragbar sind. Die fünf Rechenwege liefern mit den eigenen Werten ein genaueres Bild als jede Durchschnittszahl – und sie machen einen späteren Systemvergleich überhaupt erst möglich. DIN EN ISO 9241-110 benennt mit Erwartungskonformität und Robustheit gegen Benutzungsfehler zwei Prinzipien, an denen fachkundige Software genau diese Kennzahlen verbessert.

Drei Branchen, ein Muster

Ein Maschinenbauer aus Salzgitter führt einen Produktkonfigurator ein, der aus der Auswahl des Kunden automatisch Stücklisten erzeugt. Das fachliche Detail, an dem das Projekt beinahe scheitert: Konstruktionsänderungen. Der Konfigurator griff auf Stücklisten ohne Freigabestand zu und ließ Varianten zu, deren Baugruppen längst durch geänderte Revisionen ersetzt waren. Erst als der Freigabestand als eigenes Merkmal ins Datenmodell kam, wurden aus Konfigurationen verlässliche Fertigungsunterlagen.

Eine Schreinerei übernimmt eine Zuschnittoptimierung, die den Plattenverschnitt rechnerisch minimiert. Die Software rechnete korrekt und lieferte trotzdem unbrauchbare Pläne, weil sie Teile frei drehte, um die Platte besser auszunutzen – die Maserungsrichtung kannte sie nicht. Bei furnierten und dekorbeschichteten Platten müssen Sichtteile der Maserung folgen; eine um 90 Grad gedrehte Front spart Verschnitt und wird trotzdem zum Reklamationsfall. Ein Optimierungsalgorithmus ohne dieses eine fachliche Merkmal optimiert am Ziel vorbei.

Ein Lohnfertiger dokumentiert jede Charge am Wareneingang – das verlangt der Kunde, das prüft das Audit. Die Software verlor die Charge jedoch, sobald Material gemischt oder geteilt wurde, weil das Datenmodell keine Chargen-Beziehungen über Verarbeitungsschritte hinweg kannte. Im Reklamationsfall ließ sich deshalb nicht eingrenzen, welche ausgelieferten Teile betroffen waren; gesperrt wurde statt einer Charge eine ganze Wochenproduktion.

Eine Beobachtung zur Herkunft solcher Programme sei ausdrücklich als These gekennzeichnet, weil sie sich ohne Nennung einzelner Firmenhistorien nicht belegen lässt: Ein erheblicher Teil der Branchensoftware im deutschen Mittelstand geht auf Praktiker zurück, die zunächst für den eigenen Betrieb programmierten und deren Werkzeug erst danach zum Produkt wurde. Träfe das zu, wiederholte sich die Kernaussage dieses Beitrags in der Entstehungsgeschichte ganzer Softwaregattungen.

Der reale Fall: ein Handelshaus baut seine Verkaufssoftware selbst

Nach acht Kapiteln typisierter Fälle ein realer. Pro-Discount, ein Handelshaus im Werbeartikelmarkt, arbeitet seit 1999 in dieser Branche – mit allem, was oben abstrakt beschrieben wurde, als Tagesgeschäft: Veredelungsverfahren mit Verträglichkeitsregeln, Staffelpreise mit Einrichtekosten, Musterprozesse, Nachbestellungen mit geänderten Anforderungen. Die Verkaufssoftware für mehrere Arbeitsplätze entsteht derzeit neu, entwickelt von ProXWorks®, der digitalen Unit desselben Hauses, einschließlich einer KI-Anbindung an die eigenen Kunden- und Verkaufsdaten.

Für die These dieses Beitrags ist die Konstellation aufschlussreich, weil die Übersetzungsverluste aus dem zweiten Kapitel entfallen. Die Personen, die seit Jahrzehnten Reklamationen, Kalkulationen und Sonderfälle bearbeiten, und die Personen, die das Datenmodell entwerfen, sitzen im selben Haus. Ein Begriff wie Klischeekosten muss niemandem erklärt werden, und der Sonderfall einer Nachbestellung mit gewechseltem Veredelungsverfahren ist als konkreter Reklamationsfall im Haus erinnerlich, lange bevor ihn jemand in eine Anforderungsliste schreiben müsste.

Drei Entscheidungen im System zeigen, wie dieses Fachwissen konkret einfließt. Die Veredelung ist eine eigene Entität mit hinterlegten Verträglichkeiten zu Material, Farbanzahl und Druckfläche – die bekannten Unverträglichkeiten aus dem ersten Kapitel werden damit vor der Bestellung abgefangen, und die abschließende fachliche Prüfung konzentriert sich auf die Grenzfälle, für die sie gedacht ist. Die Kalkulation führt Einrichte- und Klischeekosten als auflagenabhängige Blöcke getrennt von den stückabhängigen Kosten, damit Staffelpreise über alle Mengen tragfähig bleiben. Und die Nachbestellung ist ein eigener Vorgangstyp, der Erstauftrag, Druckdaten und abweichende Veredelung als Bezug mitführt, statt als neuer Auftrag ohne Vorgeschichte zu beginnen.

Dass Fachleute heute generell näher an die Umsetzung eigener Software rücken, beschreibt unser Beitrag über den Domänen-Experten als Operator seiner Werkzeuge. Der hier beschriebene Weg ist die organisatorische Variante desselben Prinzips: Fachwissen und Entwicklung unter einem Dach.

Was das für Ihre nächste Software-Entscheidung heißt

Aus den vorigen Kapiteln lässt sich ein Prüfrahmen ableiten, der ohne technisches Vorwissen anwendbar ist. Er zielt auf die fachliche Tiefe eines Anbieters – auf die Eigenschaft also, die in Präsentationen selten sichtbar wird und in Referenzlisten gar nicht.

1. Sonderfall statt Referenz: „Beschreiben Sie, wie Ihr System eine Teillieferung mit Nachberechnung abbildet." Die Antwort lässt sich nicht auswendig lernen – Referenzlogos schon.
2. Datenmodell erklären lassen: „Welche Begriffe unserer Branche werden bei Ihnen eigene Objekte, welche nur Felder – und warum?"
3. Ausschlussregeln: „Wie verhindert das System eine Kombination, die sich bei uns nicht produzieren oder liefern lässt?"
4. Live-Vorführung des Alltagsvorgangs: „Zeigen Sie unseren häufigsten Vorgang mit unseren Beispieldaten – und zählen Sie die Eingabeschritte mit."
5. Storno nach Freigabe: „Was geschieht mit einem Auftrag, der nach der Produktionsfreigabe storniert wird?"
6. Standardwerte: „Welche Werte belegt die Eingabemaske vor, und woher stammen sie?"
7. Regel-Pflege: „Wie kommt eine neue fachliche Regel später ins System – durch Konfiguration im eigenen Haus oder durch Beauftragung?"
8. Selbsteinschätzung: „Woran merken Sie, dass Sie eine Branche noch nicht gut genug verstehen – und was tun Sie dann?"

Fehlende fachliche Tiefe zeigt sich im Angebot meist an denselben Anzeichen:

• Die Vorführung läuft ausschließlich mit Idealdaten, ohne einen einzigen Sonderfall
• Auf Prozessfragen folgen Funktionslisten statt beschriebener Abläufe
• Das Datenmodell wird als internes Detail bezeichnet und nicht gezeigt
• Branchenbegriffe werden gemieden oder falsch verwendet
• Jede Lücke heißt „das konfigurieren wir in der Einführung"

Zwei Einwände gegen die These dieses Beitrags verdienen eine ernsthafte Antwort. Der erste ist die Betriebsblindheit: Wer nur die eigene Praxis kennt, baut auch deren Umwege nach, und ein Blick von außen deckt auf, was intern für ein Naturgesetz gehalten wird. Der Einwand trifft zu – er spricht für Teams, die Fachkenntnis mit externer Methodik verbinden, und gegen Nachlässigkeit bei der Prozessprüfung, aber an keiner Stelle für Fachfremdheit.

Der zweite Einwand betrifft Personenabhängigkeit und Wartungsaufwand bei Eigenentwicklung. Auch er ist berechtigt: Wer eigene Software betreibt, braucht Dokumentation, Vertretungsregeln und ein belastbares Betriebsmodell, sonst hängt das System an einzelnen Köpfen. Und für Standardprozesse – Buchhaltung, Lohnabrechnung, E-Mail – bleibt etablierte Standardsoftware die richtige Wahl, weil dort keine branchenspezifische Regel einen Vorsprung erzeugt.

Die aussagekräftigste Referenz eines Software-Anbieters steht in keiner Logo-Leiste: Sie zeigt sich in dem Moment, in dem er Ihren Sonderfall beschreibt, bevor Sie ihn erklärt haben.