Ein Sonderangebot liegt fertig auf dem Tisch. Der Vertrieb wartet trotzdem: Die Technik muss eine Variante prüfen, die Geschäftsleitung einen Rabatt freigeben. Welche Kalkulation gerade gilt, steht in einer E-Mail. Genau so lässt sich Individualsoftware greifbar erklären: als Anwendung, die einen bestimmten Arbeitsablauf zusammenhält, statt noch eine weitere Datei hinzuzufügen.
Die folgenden sieben Beispiele sind bewusst konstruierte Geschäftssituationen, keine dokumentierten OnLouis-Kundenprojekte. Sie zeigen jeweils das Problem, einen möglichen Lösungsumfang und den Punkt, an dem wir zuerst vorhandene Software prüfen würden. Eine eigene Anwendung ist schließlich nur dann hilfreich, wenn sie einen besseren Ablauf ermöglicht.
Was ist Individualsoftware – an einem einfachen Beispiel?
Individualsoftware wird für die Anforderungen eines bestimmten Unternehmens oder Arbeitsablaufs entwickelt. Sie muss kein komplettes Unternehmenssystem sein. Auch ein Angebotskonfigurator, ein Kundenportal oder eine eigens entwickelte Verbindung zwischen zwei Programmen kann dazugehören. Die grundsätzliche Abgrenzung erklärt unsere Definition von Individualsoftware. Entscheidend ist hier nicht das Etikett, sondern was die Lösung im Alltag übernimmt.
1. Ein Angebotskonfigurator, der unmögliche Varianten erkennt
Ein Hersteller verkauft Anlagen mit unterschiedlichen Maßen, Materialien und Zusatzmodulen. Der Vertrieb kalkuliert mit einer Tabelle. Erst nach der Angebotserstellung fällt auf: Der gewählte Antrieb passt nicht zur gewünschten Ausführung. Jetzt müssen Technik und Vertrieb nacharbeiten, obwohl die Kundin bereits auf eine Zusage wartet.
Ein individueller Konfigurator könnte die Auswahl schon während der Eingabe prüfen. Er zeigt nur zulässige Kombinationen, berechnet die vorgesehenen Zuschläge und legt ungewöhnliche Varianten der Technik vor. Zu jedem Angebot speichert er die verwendete Regel- und Preisversion. So lässt sich später erklären, wie ein älteres Angebot zustande kam.
Für die erste Version würden wir eine Produktfamilie wählen, nicht das gesamte Sortiment. Der Test wäre konkret: Wie viele Angebote müssen nach der technischen Prüfung noch korrigiert werden? Lässt sich die Variantenlogik bereits im vorhandenen Vertriebssystem konfigurieren, wäre das zuerst zu erproben. Ein eigener Konfigurator braucht eine belegbare Lücke, nicht nur eine schönere Oberfläche.
2. Eine Freigabe-Anwendung, die Änderungen nicht übersieht
Das Angebot ist technisch möglich, enthält aber einen ungewöhnlichen Rabatt. Eine Führungskraft stimmt per E-Mail zu. Anschließend ändert jemand die Menge. Gilt die Freigabe noch? In diesem Beispiel liegt das Problem nicht in der Kalkulation, sondern darin, dass eine Entscheidung zu einer bestimmten Angebotsversion gehört.
Die Anwendung könnte die freizugebende Version festhalten und bei relevanten Änderungen eine erneute Prüfung verlangen. Sie benennt die zuständige Person, berücksichtigt Vertretungen und zeigt den Grund einer Ablehnung direkt am Vorgang. Das bestehende Warenwirtschaftssystem bleibt für den späteren Auftrag zuständig.
Ein Ablauf mit einer einzigen, unveränderlichen Zustimmung ist allerdings noch kein Grund für eine Eigenentwicklung. Hier würden wir die Freigabefunktionen vorhandener Werkzeuge testen. Erst wenn Produktdaten, Margenregeln und mehrere Fachprüfungen zusammenkommen, lohnt sich ein genauerer Vergleich. Unser Beitrag zu automatisierten Freigabeprozessen vertieft diese Entscheidung.
3. Ein Kundenportal für Lieferstatus und Dokumente
Ein Geschäftskunde fragt nach dem Lieferschein einer Teillieferung. Der Innendienst sucht im Warenwirtschaftssystem, exportiert das Dokument und verschickt es. Am nächsten Tag benötigt eine andere Niederlassung desselben Kunden dieselbe Auskunft. Ein Portal könnte den passenden Lieferstatus und die zugehörigen Dokumente direkt bereitstellen.
Die eigentliche Entwicklungsaufgabe wäre dabei nicht der Download-Knopf: Wer darf die Aufträge welcher Niederlassung sehen? Darf ein zentraler Einkäufer alle Standorte verwalten? Muss ein ausgeschiedener Mitarbeiter sofort den Zugriff verlieren? Die Sicherheitsorganisation OWASP empfiehlt, Berechtigungen bei jeder Anfrage zu prüfen – ein erfolgreicher Login allein genügt nicht. Das erläutert ihr Leitfaden zur Zugriffskontrolle.
Als ersten Umfang würden wir einen häufigen Anlass auswählen, etwa fehlende Lieferdokumente. Bietet die bestehende Software bereits ein geeignetes Kundenmodul, sollte es mit diesen konkreten Zugriffsregeln getestet werden. Ob ein zusätzliches Portal den Service wirklich entlastet, lässt sich danach besser beurteilen als anhand einer langen Wunschliste. Dazu passt unsere Entscheidungshilfe für Kundenportale.
4. Eine Einsatzplanung, die mehr als freie Termine kennt
Ein Servicebetrieb muss eine Anlage warten. Die verfügbare Technikerin besitzt die passende Qualifikation, aber das benötigte Messgerät ist bereits einem anderen Einsatz zugeteilt. Der Kunde lässt außerdem nur ein enges Zeitfenster zu. Ein einfacher Kalendereintrag würde diesen Konflikt nicht lösen.
Eine eigene Planungshilfe könnte Personal, Geräte, Teile und Kundentermine gemeinsam betrachten. Sie müsste nicht gleich automatisch perfekte Touren berechnen. Ein brauchbarer erster Schritt wäre, unzulässige Zuordnungen sichtbar zu machen und der Disposition geeignete Alternativen vorzuschlagen.
Gerade hier wäre pauschale Werbung für Individualsoftware falsch: Standardprodukte können bereits nach Fähigkeiten, Verfügbarkeit und Standort planen. Microsoft beschreibt das beispielsweise für den Planungsassistenten von Dynamics 365 Field Service. Die Frage wäre deshalb, welche Ihrer zusätzlichen Regeln tatsächlich fehlen und ob eine Erweiterung statt eines Neubaus genügt.
5. Eine Schnittstelle, die Bestellungen nicht doppelt anlegt
Eine Bestellung soll vom Shop ins ERP gelangen, also in das System für Aufträge und Warenwirtschaft. Die Übertragung endet mit einer Zeitüberschreitung. Niemand weiß, ob der Auftrag angekommen ist. Wird er einfach erneut gesendet, droht im ungünstigen Fall ein doppelter Eintrag.
Genau diese Möglichkeit beschreibt Microsoft im Architekturmuster für Wiederholungsversuche: Ein Dienst kann einen Auftrag verarbeiten, obwohl seine Antwort nicht mehr ankommt. Für unser Beispiel wäre deshalb eine eindeutige Bestellkennung nötig, die beim erneuten Versuch wiedererkannt wird. Wie das umgesetzt wird, hängt auch von den Möglichkeiten des empfangenden Systems ab.
Die individuelle Lösung könnte zusätzlich unvollständige Bestellungen in einer Prüfliste sammeln und den Bearbeitungsstand anzeigen. Dafür braucht es nicht unbedingt eine große neue Oberfläche. Reicht ein vorhandener Connector einschließlich Fehlerbehandlung und Zuordnung der Daten aus, würden wir ihn bevorzugen. Die grundsätzliche Planung erläutern wir unter API-Schnittstellen planen.
6. Eine Reklamations-App, die aus einem Foto einen bearbeitbaren Fall macht
Im Wareneingang wird eine beschädigte Lieferung entdeckt. Ein Foto geht an den Einkauf, eine Notiz an die Schichtleitung. Später fehlt die Verbindung zur Bestellung. Die Reklamation ist irgendwo dokumentiert, aber niemand kann sagen, ob die Ware gesperrt, Ersatz bestellt oder der Lieferant informiert wurde.
Eine passende Anwendung würde das Foto mit Lieferung und Artikel verbinden. Der Einkauf klärt den Ersatz, das Lager sieht den vorgesehenen Umgang mit der Ware, und eine verantwortliche Person schließt den Fall ab. Für die erste Version wäre die Wareneingangsreklamation genug; ein vollständiges Qualitätsmanagementsystem müsste daraus nicht werden.
Nachträgliche Korrekturen sollten dort nachvollziehbar sein, wo sie eine Entscheidung verändern: beispielsweise eine zunächst erteilte Freigabe. Welche Änderungen dafür festgehalten werden sollten, beschreibt unser Beitrag zum Änderungsprotokoll in interner Software. Ein solches Protokoll ersetzt jedoch keine Prüfung konkreter Nachweisanforderungen. Eine vorhandene Fachlösung wäre zuerst zu prüfen, wenn sie den gesamten Reklamationsablauf bereits abdeckt.
7. Eine Arbeitsübersicht, aus der direkt gehandelt werden kann
Eine Auftragsleiterin sieht auf einem Dashboard, dass Lieferungen verspätet sind. Für die Bearbeitung wechselt sie jedoch zwischen Warenwirtschaft, Tickets und E-Mails. Die Zahl ist sichtbar, der nächste Schritt bleibt Sucharbeit.
Eine individuelle Arbeitsübersicht könnte zu jedem kritischen Auftrag den fehlenden Schritt, die zuständige Person und die letzte Rückmeldung zusammenführen. Die Auftragsleiterin weist eine Klärung zu oder öffnet den passenden Vorgang im Quellsystem. Bei veralteten Daten zeigt die Oberfläche ausdrücklich den letzten erfolgreichen Abgleich statt einen scheinbar aktuellen Status.
Für reine Kennzahlen würden wir zuerst ein vorhandenes Auswertungswerkzeug nutzen. Eigene Software wäre hier interessant, wenn die Bearbeitung über mehrere Systeme hinweg den Aufwand verursacht. Auch Erweiterungen vorhandener Werkzeuge gehören in den Vergleich; ein selbst gebautes Dashboard ist nicht automatisch nützlicher.
Wie Sie prüfen, welches Beispiel zu Ihrem Betrieb passt
Nehmen Sie einen konkreten, anonymisierten Vorgang und lassen Sie ihn von den beteiligten Mitarbeitenden erklären. Notieren Sie nicht zuerst Funktionen, sondern die Stellen, an denen jemand warten, suchen, übertragen oder nachfragen muss. Eine nützliche Beschreibung lautet etwa: „Nach einer Preisänderung wird die Freigabe erneut benötigt“ – nicht: „Wir brauchen einen modernen Workflow“.
Diesen Vorgang sollten Sie mit einer Standardlösung und einem möglichen individuellen Entwurf durchspielen. Nehmen Sie einen Normalfall, einen Fehlerfall und eine nachträgliche Änderung. Entscheidend ist, welcher Ansatz alle drei nachvollziehbar löst. Wenn Regeln oder Zuständigkeiten dabei noch strittig sind, hilft zunächst die fachliche Klärung vor der Entwicklung.
Nicht nur die Entwicklung, sondern den Betrieb vergleichen
Für die Entscheidung würden wir auf beiden Seiten dieselben Kostenpositionen erfassen: Einführung, Datenübernahme, Anbindungen, Schulung, laufenden Betrieb und spätere Änderungen. Bei Standardsoftware gehören benötigte Lizenzen und Erweiterungen dazu. Bei Individualsoftware müssen Wartung und technische Betreuung ebenfalls eingeplant werden. Ein Vergleich von Lizenzkosten mit reinen Entwicklungskosten würde unterschiedliche Leistungen gegenüberstellen.
Legen Sie außerdem fest, woran der erste nutzbare Stand gemessen wird: weniger Rückfragen zu Lieferdokumenten, weniger doppelt angelegte Aufträge oder weniger Angebote mit nachträglichen Korrekturen. Erfassen Sie den Ausgangszustand, bevor Sie einen Zeitgewinn versprechen. Ob sich das Vorhaben lohnt, lässt sich nicht allein aus seinem Softwaretyp ableiten.
Der sinnvollste Start ist ein vollständiger kleiner Ablauf
Für das Sonderangebot vom Anfang hieße das: eine Angebotsversion erfassen, fachlich prüfen, freigeben und an die Warenwirtschaft übergeben – einschließlich einer Änderung nach der Freigabe. Das wäre ein brauchbarer erster Umfang. Sieben angefangene Module wären es nicht.
OnLouis entwickelt Webplattformen, Kundenportale und interne Anwendungen und verbindet sie mit vorhandenen Systemen. Auf unserer Seite zur individuellen Softwareentwicklung finden Sie das Vorgehen von der Prozessanalyse bis zum Betrieb. Für ein erstes Gespräch ist ein konkreter problematischer Vorgang hilfreicher als eine möglichst lange Funktionsliste.
Welcher Vorgang kostet Ihr Team unnötig Arbeit?
Beschreiben Sie einen konkreten Ablauf und die beteiligten Systeme. Wir besprechen, ob eine Anpassung, eine Schnittstelle oder eine eigene Anwendung dafür sinnvoll ist.
Ablauf besprechen