Standardsoftware erweitern oder eine eigene Web-App entwickeln?

Wenn vorhandene Software einen wichtigen Ablauf nicht gut unterstützt, liegt die Idee einer eigenen Anwendung nahe. Sie verspricht genau die Oberfläche und Regeln, die im Alltag fehlen. Gleichzeitig übernehmen Sie damit Verantwortung, die bei einem Standardprodukt teilweise beim Anbieter liegt: Weiterentwicklung, Fehlerbehebung, technische Aktualisierung und Betrieb.

Die bessere Entscheidung ergibt sich deshalb aus dem konkreten Prozess. Eine eigene Web-App kann sinnvoll sein, wenn ein besonderer Ablauf wirklich benötigt wird. Für gut abgedeckte Standardaufgaben kann ein vorhandenes Produkt die deutlich passendere Lösung sein. Dazwischen liegen Konfiguration, Erweiterungen, Integrationen und Low-Code-Anwendungen.

Beschreiben Sie die Lücke so konkret wie möglich

„Unser System ist zu unflexibel“ ist ein nachvollziehbarer Eindruck, aber noch keine Grundlage für eine Investition. Hilfreicher ist eine beobachtbare Einschränkung: Eine Freigabe kann nicht an eine bestimmte Rolle gebunden werden. Daten müssen in drei Anwendungen nachgetragen werden. Außendienstmitarbeiter sehen unterwegs nicht die Informationen, die sie benötigen.

Trennen Sie dabei echte Anforderungen von Gewohnheiten. Ein Ablauf kann historisch entstanden sein, ohne heute noch sinnvoll zu sein. Wenn eine bewährte Standardfunktion das Ergebnis mit weniger Sonderregeln erreicht, kann eine Anpassung des Prozesses vernünftiger sein als eine technische Nachbildung jeder bisherigen Ausnahme.

Halten Sie für die wichtigsten Aufgaben fest, welches Ergebnis erreicht werden muss, wer beteiligt ist und was bei einem Fehler passieren würde. Erst danach lohnt ein Vergleich von Produkten und Lösungswegen.

Vier Wege, die Sie getrennt betrachten sollten

Bestehende Software konfigurieren

Prüfen Sie zunächst die vorhandenen Möglichkeiten: Rollen, Felder, Ansichten, Freigaben, Automatisierungen und unterstützte Erweiterungen. Vielleicht fehlt keine Software, sondern eine passende Einrichtung oder die Kenntnis einer bereits verfügbaren Funktion.

Dieser Weg ist besonders interessant, wenn die Aufgabe nah am vorgesehenen Einsatz des Produkts liegt. Die Grenze ist erreicht, wenn die Konfiguration immer neue Umgehungen benötigt oder die zentrale fachliche Regel gar nicht zuverlässig abbilden kann.

Ein vorhandenes System gezielt erweitern

Eine kleine Anwendung oder Integration kann eine Lücke schließen, während Stammdaten und Kernfunktionen im bestehenden System bleiben. Das kann etwa eine zusätzliche Erfassungsoberfläche oder die automatische Übertragung eines freigegebenen Vorgangs sein.

Dieser Weg vermeidet eine vollständige Ablösung, schafft aber eine neue Verbindung, die betrieben werden muss. API-Zugang, Änderbarkeit der benötigten Daten, Berechtigungen und Versionspflege müssen tatsächlich unterstützt sein. Ein Plugin ist nicht automatisch dauerhaft kompatibel. Die relevanten Fragen dazu erläutert der Artikel Schnittstellen zwischen Shop, Warenwirtschaft und internen Tools planen.

Low-Code als eigene Option prüfen

Low-Code kann für begrenzte interne Abläufe interessant sein, besonders wenn bereits eine passende Plattform im Unternehmen vorhanden ist. Microsoft Power Apps bietet beispielsweise Canvas-Anwendungen für individuelle Geschäftsanwendungen. Das belegt eine mögliche Werkzeugkategorie, noch nicht deren Eignung für Ihren Prozess. Microsoft: Einstieg in Canvas-Anwendungen.

Prüfen Sie vor einer Entscheidung die konkret benötigten Konnektoren, Lizenzbedingungen, Rollen, Datenmengen und Möglichkeiten zur Übernahme durch andere Personen. Die visuelle Erstellung einer Anwendung ersetzt weder ein Datenmodell noch die fachliche Verantwortung. Auch eine schnell erstellte Lösung braucht einen geregelten Umgang mit Änderungen.

Eine individuelle Web-App entwickeln

Eine eigene Anwendung kann passen, wenn ein relevanter Ablauf durch bestehende Lösungen nur mit erheblichen Kompromissen unterstützt wird. Sie ermöglicht eine gezielte Oberfläche, ein passendes Datenmodell und die ausdrücklich benötigten Regeln.

Dafür muss der Umfang begrenzt werden. „Wir bauen unser eigenes ERP“ ist eine andere Entscheidung als „Wir brauchen einen internen Freigabeprozess mit Anbindung an das vorhandene ERP“. Je klarer die fachliche Grenze, desto besser lassen sich Umsetzung, Risiken und späterer Betrieb beurteilen.

Ein Beispiel mit unterschiedlichen Ergebnissen

Angenommen, ein Unternehmen möchte Materialanforderungen aus mehreren Abteilungen verwalten. Dieses Beispiel ist bewusst hypothetisch.

Wenn das vorhandene System Anträge, Zuständigkeiten und Freigaben bereits unterstützt, kann eine saubere Einrichtung genügen. Fehlt nur eine einfache mobile Erfassung, könnte eine ergänzende Oberfläche reichen. Werden dagegen mehrere unabhängige Systeme und besondere Freigaberegeln benötigt, ist eine eigene Anwendung eine prüfenswerte Option.

In allen drei Fällen muss zunächst geklärt sein, wer Materialdaten pflegt, wann ein Antrag verbindlich wird und welches System die Bestellung auslöst. Eine individuelle Oberfläche würde diese offenen Entscheidungen nicht von selbst lösen.

Vergleichen Sie den Lebenszyklus, nicht nur das Angebot

Bei Standardsoftware sind Lizenzkosten sichtbar. Bei individueller Entwicklung steht zunächst das Umsetzungsangebot im Vordergrund. Für einen fairen Vergleich müssen beide Wege dieselben Aufgaben abdecken und denselben Betrachtungszeitraum verwenden.

Eine brauchbare Rechnung arbeitet mit Annahmen, die Sie prüfen können. Welche Personenzahl liegt den Lizenzen zugrunde? Welche Änderungen sind im Angebot enthalten? Wer leistet Support und in welchem Umfang? Welche laufenden Kosten bleiben auch dann bestehen, wenn vorerst keine neue Funktion entwickelt wird?

Eine günstigere erste Version kann über die Nutzungsdauer teurer werden. Umgekehrt ist ein hoher Anfangsaufwand nicht automatisch wirtschaftlich, nur weil später keine Lizenz pro Nutzer anfällt.

Auch Eigenentwicklung schafft Abhängigkeiten

Bei einem Standardprodukt hängen Sie unter anderem von dessen Funktionsumfang, Schnittstellen und Produktentwicklung ab. Bei individueller Software entstehen Abhängigkeiten von Codequalität, Dokumentation, Infrastruktur und den Menschen, die sie verstehen.

Fragen Sie deshalb unabhängig vom Lösungsweg nach Datenexport, Zugriffsverwaltung und Übergabefähigkeit. Bei einer Eigenentwicklung sollten Repository, Buildweg, Betriebsanleitung und die vertraglichen Nutzungsrechte geklärt sein. Bei einem Produkt sollten Sie wissen, welche Daten Sie in welchem Format herausbekommen und welche Erweiterungen an den Anbieter gebunden bleiben.

Vollständige Unabhängigkeit ist kein realistisches Ziel. Eine bewusste, handhabbare Abhängigkeit ist es eher.

Wann ich zunächst von einer eigenen Anwendung abraten würde

Eine Eigenentwicklung ist schwer zu begründen, wenn die Anforderungen noch stark schwanken, niemand den Prozess fachlich verantwortet oder kein Budget für den späteren Betrieb vorgesehen ist. Ebenso kritisch ist ein Vorhaben, das hauptsächlich bekannte Standardfunktionen nachbauen soll, ohne dass der besondere Nutzen benannt werden kann.

In solchen Situationen kann ein begrenzter Versuch mit vorhandenen Werkzeugen helfen. Dabei sollte vorher feststehen, welche Frage beantwortet werden soll. Ein Prototyp soll beispielsweise zeigen, ob die geplante Erfassung im Alltag funktioniert – nicht bereits stillschweigend zum unbetreuten Produktivsystem werden.

Wenn der Prozess heute in Tabellen lebt, beginnt die Entscheidung oft noch früher: Wann Excel für einen Geschäftsprozess nicht mehr reicht.

Eine Entscheidungsvorlage auf einer Seite

Für eine erste belastbare Abwägung reichen wenige klar formulierte Punkte: die wichtigsten Aufgaben, unverzichtbare Regeln, vorhandene Systeme, betrachtete Alternativen und der geplante Betrieb. Ergänzen Sie je Alternative die größten Unsicherheiten und die Frage, wie diese überprüft werden können.

Ein kurzer Machbarkeitstest kann sinnvoller sein als eine detaillierte Schätzung auf unsicheren Annahmen. Beispielsweise lässt sich zunächst prüfen, ob eine vorhandene API die benötigte Änderung überhaupt erlaubt. Erst danach wird die ergänzende Oberfläche geplant.

Ich unterstütze Sie dabei, den Bedarf für eine interne Web-App einzugrenzen und ihn gegen eine Erweiterung des Bestands abzuwägen. Bringen Sie den konkreten Ablauf und die heutigen Grenzen mit. Lösungsweg besprechen.