Individualsoftware: sechs Beispiele

Wer nach Beispielen für Individualsoftware sucht, findet Fallstudien. Sie folgen alle demselben Bauplan: Ausgangslage schwierig, Lösung elegant, Kunde zufrieden. Was fehlt, ist der Teil, der bei der eigenen Entscheidung weiterhilft — was die Anwendung ersetzt hat, woran es fast gescheitert wäre und was sie bewusst nicht kann.

Individualsoftware im Mittelstand ist selten ein großes System. Sie ist meist eine schmale Anwendung, die einen einzelnen Ablauf vollständig abdeckt und sich über Schnittstellen an die vorhandene Standardsoftware hängt. Die folgenden sechs Beispiele haben das gemeinsam: Keines davon hat ein bestehendes System abgelöst.

Vier der Beispiele stammen aus der Arbeit mit mittelständischen Betrieben in Hamburg und Umgebung und sind anonymisiert. Zwei sind Anwendungen, die wir selbst betreiben — dort können wir die Details offenlegen.

Ein Hinweis vorab, weil er in Ratgebern gern untergeht: Keine dieser individuellen Softwarelösungen ist aus dem Wunsch nach Digitalisierung entstanden. Jede hat einen Ablauf ersetzt, der jemanden regelmäßig Zeit gekostet hat. Das ist die einzige Konzeption, die im Mittelstand zuverlässig trägt.

Woran Sie erkennen, ob ein Beispiel auf Ihre Branche übertragbar ist

Beispiele für Individualsoftware haben ein Grundproblem: Sie stammen aus einem anderen Unternehmen. Bevor Sie eines davon auf sich beziehen, prüfen Sie drei Dinge.

Ist der Ablauf standardisiert oder eigen? Wenn Ihr Wettbewerber denselben Ablauf hat, gibt es dafür wahrscheinlich ein Produkt. Eine maßgeschneiderte Lösung lohnt dort, wo die Branche uneinheitlich arbeitet — und im Mittelstand ist das häufiger der Fall, als die Software-Hersteller behaupten.

Wie viele Systeme sind beteiligt? Beispiele mit einer einzigen Datenquelle sind leicht übertragbar. Sobald zwei oder drei Systeme zusammenspielen müssen, entscheidet nicht der Anwendungsfall über den Zeitaufwand, sondern die Frage, wie gut sich diese Systeme anbinden lassen.

Wer benutzt es täglich? Software, die eine Fachabteilung benutzt, muss deren Workflows abbilden. Software, die alle benutzen, muss so einfach sein, dass sie niemand erklärt bekommt. Der Entwicklungsprozess sieht in beiden Fällen anders aus.

Beispiel 1: Angebote aus der eigenen Auftragshistorie

Ausgangslage: Ein Großhändler mit rund vierzig Beschäftigten. Angebote entstanden in Word, auf Grundlage eines alten Angebots, das jemand als Vorlage öffnete. Preise wurden aus der Warenwirtschaft abgeschrieben, Konditionen aus dem Gedächtnis ergänzt. Zwei Mitarbeiter machten das gut, ein dritter machte es anders.

Gebaut wurde: Eine Anwendung, die Positionen aus der Warenwirtschaft zieht, die letzten Angebote an denselben Kunden danebenlegt und daraus einen Entwurf erzeugt. Freigegeben wird von Hand.

Das Schwierige daran war nicht die Erzeugung des Dokuments, sondern die Frage, welcher Preis gilt. In den Stammdaten standen drei Preisebenen, von denen zwei seit Jahren gepflegt wurden und eine nicht. Diese Unklarheit musste jemand entscheiden, bevor eine Zeile Code Sinn ergab. Das ist der Regelfall: Individualsoftware macht Uneindeutigkeiten sichtbar, die vorher jemand still im Kopf aufgelöst hat.

Was sie nicht kann: Verhandeln. Rabatte über der hinterlegten Grenze bleiben eine Entscheidung, die ein Mensch trifft und begründet.

Warum keine Standardsoftware: Ein Angebotswerkzeug hätte es gegeben. Es hätte die Preisfindung aber nach seiner eigenen Logik abgebildet, nicht nach der des Auftraggebers — und genau diese Logik ist hier der Wettbewerbsvorteil.

Beispiel 2: Belege einlesen statt abtippen

Ausgangslage: Monatliche Auswertungen, Kontoauszüge und Lieferantenrechnungen kamen als PDF. Die Zahlen daraus landeten in einer Tabelle — von Hand, jeden Monat, mit den üblichen Zahlendrehern.

Gebaut wurde: Eine Importstrecke, die das PDF einliest, die Werte gegen die im Dokument enthaltenen Summen prüft und jede übernommene Zahl zur Fundstelle im Original zurückverfolgbar macht. Was nicht sauber durchläuft, landet in einer Prüfliste statt im Ergebnis.

Das Schwierige daran sind nicht die Dokumente, die sich gleichen, sondern die drei Sorten PDF, die es tatsächlich gibt — und die Tatsache, dass ein Absender das Layout ändert, ohne es anzukündigen. Wir haben dazu einen eigenen Beitrag geschrieben: PDF-Import als Datenquelle.

Was sie nicht kann: Ohne Pflege auskommen. In jedem Angebot für so eine Strecke steht eine Position für die laufende Anpassung der Importregeln. Sie kostet wenig und entscheidet darüber, ob das System nach zwei Jahren noch brauchbar ist.

Beispiel 3: Abgleich zwischen zwei Systemen, die sich widersprechen

Ausgangslage: Kundendaten standen im ERP und im CRM. Beide Systeme galten als führend, je nachdem, wen man fragte. Adressänderungen wurden in einem gepflegt, Ansprechpartner im anderen, und einmal im Quartal fiel jemandem auf, dass die Rechnung an eine alte Anschrift ging.

Gebaut wurde: Keine dritte Datenbank — das war der erste Vorschlag und der falsche. Stattdessen ein Abgleich, der beide Bestände täglich vergleicht und nur die Fälle meldet, in denen sie sich widersprechen. Zwölf Datensätze am ersten Tag, danach selten mehr als zwei pro Woche.

Das Schwierige daran war die organisatorische Frage, nicht die technische: Wer entscheidet im Konfliktfall? Diese Festlegung hat länger gedauert als die Entwicklung.

Was sie nicht kann: Automatisch zusammenführen. Das wurde erwogen und verworfen. Ein stiller Abgleich, der die falsche Version durchsetzt, ist schlimmer als ein sichtbarer Widerspruch.

Beispiel 4: Einsatzplanung, die auf dem Handy funktioniert

Ausgangslage: Ein technischer Dienstleister plante Einsätze in Excel und verteilte sie per Telefon. Rückmeldungen kamen als Foto per Messenger. Die Abrechnung entstand daraus zwei Wochen später, aus dem Gedächtnis.

Gebaut wurde: Eine schlanke Weboberfläche für Disposition und Rückmeldung — mit dem Anspruch, dass sie im Auto auf einem Telefon bedienbar sein muss, bei schlechter Verbindung. Die Daten laufen in die vorhandene Warenwirtschaft zurück.

Das Schwierige daran: Standardlösungen für Einsatzplanung gab es durchaus. Sie hätten 100 Prozent des Bedarfs abgedeckt und 400 Prozent des Funktionsumfangs mitgebracht — samt Schulungsaufwand für Leute, die keine Software mögen. Die Entscheidung fiel gegen den Standard, weil die Oberfläche so einfach bleiben musste, dass man sie nicht erklären muss. Gerechnet hat sich das auch: Die Lizenzkosten für vierzig mobile Zugänge hätten die Entwicklung innerhalb von drei Jahren überstiegen.

Was sie nicht kann: Schichtplanung nach Tarifregeln. Das wurde bewusst ausgelassen — es ist reguliert, ändert sich mit der Gesetzeslage und gehört deshalb in Standardsoftware.

Beispiel 5: Ein Veröffentlichungssystem für sieben Websites

Ab hier wird es konkret, weil es unsere eigenen Systeme sind.

Ausgangslage: Sieben Websites, jede mit Redaktionsplan. Vorher lief das über ein Redaktionssystem mit Datenbank, Benutzerverwaltung und Automatisierungen — und mit einem Fehler, der monatelang unbemerkt blieb: Ein abgelaufener Zugang sorgte dafür, dass wochenlang nichts mehr veröffentlicht wurde. Von außen sah das aus, als sei gerade nichts geplant.

Gebaut wurde: Das Redaktionssystem ist abgeschaltet. Beiträge sind Dateien im Versionsverwaltungssystem mit einem Veröffentlichungsdatum im Kopf. Ein Lauf auf dem eigenen Server baut jede Nacht die Seiten, deren Datum erreicht ist, und stellt sie online. Dazu ein zweites, unabhängiges Programm, das jeden Morgen prüft, ob das auch wirklich passiert ist — und nur dann eine Nachricht schickt, wenn etwas fehlt.

Das Schwierige daran war eine Erkenntnis aus einem Beinahe-Unfall: Ein Bau kann erfolgreich melden und trotzdem nichts erzeugt haben. Seither hat der Vorgang eine Sperre, die einen Bau mit zu wenigen Seiten abbricht, statt eine leere Website hochzuladen. Diese eine Zeile ist der wichtigste Teil des ganzen Systems.

Was daraus zu lernen ist: Der Ersatz eines Standardprodukts durch eigene Software war hier nicht die teurere, sondern die günstigere Variante — weil der tatsächliche Bedarf ein Bruchteil dessen war, was das Produkt konnte.

Beispiel 6: Fehlermeldungen ohne eigene Datenbank

Ausgangslage: Anwender sollten Fehler melden können, ohne ein Entwicklerwerkzeug bedienen zu müssen. Der naheliegende Weg wäre eine eigene Anwendung mit Datenbank, Anmeldung und Rechteverwaltung gewesen.

Gebaut wurde: Eine Oberfläche, die als Datenhaltung schlicht die Vorgangsverwaltung nutzt, in der die Entwicklung ohnehin stattfindet. Es gibt keine zweite Datenbank, keinen Abgleich und nichts, was auseinanderlaufen könnte. Eine Adresse in der Oberfläche entspricht genau einem Vorgang im Entwicklungssystem.

Das Schwierige daran war, dieser Lösung zu trauen. Sie sieht nach einer Abkürzung aus. Sie ist aber die einzige Variante, bei der Meldung und Bearbeitung niemals unterschiedliche Stände haben — und sie hat die Wartungslast einer Anwendung eingespart, die es nie geben musste.

Was diese Beispiele für Individualsoftware gemeinsam haben

Keines hat ein bestehendes System abgelöst. In allen Fällen blieb die vorhandene Standardsoftware führend, und die neue Anwendung hat sich über Schnittstellen daran gehängt.

In vier von sechs Fällen war die schwierigste Frage keine technische. Welcher Preis gilt, wer im Konflikt entscheidet, was ein gültiger Beleg ist — das sind Festlegungen, die im Unternehmen getroffen werden müssen. Software kann sie sichtbar machen, aber nicht ersetzen.

Vier von sechs wären mit Standardsoftware teurer geworden — nicht bei der Anschaffung, sondern über die Nutzungsdauer, weil Lizenzen pro Kopf und Monat abgerechnet werden und eine individuell entwickelte Anwendung nicht.

In jedem Fall war der erste Entwurf zu groß. Die brauchbare Version war jedes Mal die kleinere: ein Ablauf statt eines Systems, eine Prüfliste statt einer Vollautomatik, eine Meldung statt einer stillen Korrektur. Wer agil vorgeht, merkt das nach vier Wochen und nicht nach dem Abnahmetermin.

Und alle sechs sind erweiterbar geblieben. Das ist kein Zufall, sondern Folge des Zuschnitts: Wer eine Anwendung um einen Ablauf herum baut statt um einen Funktionsumfang, kann den nächsten Ablauf daneben hängen. Effizient wird Individualsoftware selten durch das erste Release — sondern dadurch, dass das zweite drei Wochen später kommen kann.

Was eine solche Anwendung an Zeit kostet

Die ehrlichste Antwort auf die Frage nach dem Aufwand ist eine Spanne, und sie ist enger, als die Ratgeber vermuten lassen. Anwendungen dieses Zuschnitts — ein Ablauf, ein bis drei Schnittstellen, eine überschaubare Zahl an Bildschirmmasken — liegen erfahrungsgemäß zwischen zwanzig und achtzig Personentagen für die erste benutzbare Version.

Der größere Teil der Investition steckt danach: in der Erweiterung um den zweiten und dritten Ablauf, in der Pflege der Schnittstellen und darin, dass die Software mit dem Geschäft mitwächst. Genau deshalb rechnen wir nicht in Projekten ab, sondern in einer monatlichen Pauschale — die Softwareentwicklung hört bei diesen Anwendungen nicht auf, sie wird nur ruhiger.

Wie sich diese Zahlen im Detail zusammensetzen, steht in Was Softwareentwicklung kostet.

Kurz gefasst

Individualsoftware im Mittelstand sieht selten aus wie in den Fallstudien. Sie ist meist eine schmale, flexibel erweiterbare Anwendung für einen einzelnen Ablauf, die neben der vorhandenen Standardsoftware läuft — und deren schwierigster Teil eine Entscheidung ist, die das Unternehmen selbst treffen muss.

Wann sich das lohnt und wovon der Aufwand abhängt, steht unter Individualsoftware entwickeln lassen. Die Abwägung gegenüber fertigen Produkten haben wir in Standardsoftware oder Individualsoftware durchgerechnet.