Es gibt einen Moment, den die meisten E-Commerce-Betreiber im zweiten oder dritten Jahr erreichen. Das Lager läuft. Die Bestellungen gehen raus. Das Werkzeug, das Sie bis hierher gebracht hat, ob Tabellenkalkulation, günstiges Inventar-Skript oder allgemeiner SaaS-Tarif, ist unbemerkt vom System zum Engpass geworden. Jemand im Lager pflegt nebenher eine eigene Tabelle für Retouren, und jemand anderes führt eine separate Liste, welcher Lieferant tatsächlich am schnellsten liefert. Die Software sagt das eine. Die Regale sagen etwas anderes.
Meist stellt sich genau dann die Frage: Kaufen Sie noch ein Standardtool, oder entwickeln Sie eine Lagerverwaltungs-App, die wirklich zu Ihrer Arbeitsweise passt?
Wir entwickeln diese Art von Software seit 18 Jahren für operative Unternehmen, für mehr als 1.000 Firmen. Die ehrliche Antwort lautet: Es hängt von einer kleinen Zahl konkreter Faktoren ab, nicht davon, wie groß Sie sind oder wie viel Sie ausgeben. Dieser Artikel zeigt, welche Faktoren das sind, was eine echte Entwicklung umfasst, was sie kostet und wie Sie entscheiden, ohne ein Jahr lang auf die harte Tour zu lernen.
Was ein echtes Lagersystem tatsächlich umfasst
Bevor auch nur eine Inventarfunktion entsteht, braucht ein echtes Lagersystem ein Fundament. Das heißt: Authentifizierung, rollenbasierte Berechtigungen, ein Grundgerüst für das Admin-Dashboard und eine Datenbankarchitektur, die die Beziehungen tragen kann, die Sie bald brauchen werden. Wer darf Bestände korrigieren? Wer darf eine Erstattung freigeben? Wer darf nur scannen und Wareneingänge buchen? Die meisten Standardtools legen diese Rollen fest vorgegeben an oder überspringen dieses Fundament ganz. Das geht so lange gut, bis Ihre Lagerleitung, Ihre Kundenservice-Leitung und Ihre Buchhaltung unterschiedliche Sichten auf denselben Datensatz brauchen.
Der eigentliche Punkt ist: Bei Lagersoftware geht es nicht wirklich ums Zählen. Zählen ist der einfache Teil. Die eigentliche Arbeit besteht darin, Datensätze zu verknüpfen. Ein Kundenanliegen hängt an einer Bestellung, die an einer Retourengenehmigung hängt, die an einem eingehenden Paket hängt, das wiederum an einer SKU hängt, die an einem Lieferanten hängt, der zu einem bestimmten Preis mit einer bestimmten Lieferzeit geliefert hat. Diese Kette ist das System, und alles andere ist nur eine Ansicht darauf.
Wenn diese Kette nicht in der Software abgebildet ist, bauen Menschen sie von Hand nach. Die Software wird zu dem Ort, an dem die Bestandszahlen liegen, während die Tabellen zu dem Ort werden, an dem das Geschäft tatsächlich läuft.
Eine individuelle Bestandsverwaltungs-App beginnt am anderen Ende. Sie definieren zuerst die Beziehungen und bauen dann die Ansichten, die sie sichtbar machen. Diese Reihenfolge klingt akademisch, bis Sie versuchen, Retouren in ein System einzubauen, das nie dafür ausgelegt war, zu wissen, was eine Bestellung ist.
Was für Standardsoftware spricht
Ein Template-Skript oder ein Abo-Tool bringt Ihrem Team in Tagen statt Monaten ein funktionierendes Dashboard. Keine Entwicklungskosten vorab, keine Abstimmungsrunden zum Umfang, kein Warten auf den ersten Meilenstein. Wenn Sie erst testen, ob ein Lagerbetrieb überhaupt tragfähig ist, ist diese Geschwindigkeit viel wert. $25,000 für individuelle Software auszugeben, um 300 SKUs zu verwalten, die Sie im nächsten Quartal vielleicht auslisten, ist ein schlechtes Geschäft, und das sagen wir Ihnen, bevor wir Ihnen ein Angebot machen.
Standardsoftware funktioniert unter einer bestimmten Bedingung wirklich gut: bei einem einzigen Lager.
Die Probleme beginnen an den Rändern. Die meiste vorgefertigte Lagerverwaltungssoftware für E-Commerce wurde nicht auf Live-Bestelldaten aus Shopify, RMA-Abläufe oder lieferantenspezifische Lieferzeiten ausgelegt.
Was für eine individuelle Entwicklung spricht
Bei einer individuellen Lösung geht es nicht um schönere Oberflächen. Es geht um drei konkrete strukturelle Probleme, die Standardtools durchweg nicht abbilden können. Trifft keines davon auf Sie zu, kaufen Sie. Treffen zwei oder drei zu, sieht die Rechnung schnell anders aus.
Bestellungen, Problemfälle und Retouren in einem System verbinden
Ein Kunde meldet per E-Mail einen beschädigten Artikel. Dieser Fall muss sich bis zur ursprünglichen Bestellung zurückverfolgen lassen, eine Retourengenehmigung erzeugen, ein Etikett erstellen, das eingehende Paket verfolgen, das Prüfergebnis festhalten, die Erstattung an den Kunden auslösen und eine Reklamation beim Lieferanten anstoßen, falls der Schaden vorher entstanden ist. Das ist ein Ereignis mit sieben Folgen für drei Beteiligte.
Generische Inventartools bilden diese Kette überhaupt nicht ab. Sie bilden ausgehenden und zurückkommenden Bestand ab. Alles dazwischen landet im Support-Postfach.
Ein sauber gebautes RMA- und Retourenmanagement-System hält all das in einem Datensatz zusammen. Sie öffnen eine Bestellung und sehen jeden dazu gemeldeten Fall, den Retourenstatus, die Zustandsbewertung beim Wareneingang und ob das Geld an den Kunden zurückging, vom Lieferanten zurückkam oder beides. Das ist keine nette Zusatzfunktion fürs Reporting. Es ist der Unterschied zwischen dem Wissen um Ihre echte Marge und dem Raten.
Ein individuelles RMA- und Retourenmanagement-System macht beide Hälften dieser Transaktion auf derselben Ansicht sichtbar. Meist ist das der Moment, in dem jemand feststellt, wie viel das Unternehmen bisher stillschweigend geschluckt hat.
Die physische Realität eines Lagers abbilden
Standardsoftware geht davon aus, dass alles, was an Ihrer Rampe ankommt, erwartet wird. Echte Lager wissen es besser.
Kartons kommen ohne Bestellung an. Kunden schicken Artikel ohne RMA-Nummer zurück. Ihr System braucht einen Ort, an dem ein Paket als "nicht zugeordnet" liegen kann: fotografiert, mit eindeutiger Paketnummer versehen, mit Ankunftszeit und Versanddienstleister erfasst, bis jemand es einer Bestellung, einer Retoure oder einer Einkaufsbestellung zuordnet.
Dieser Zuordnungsschritt braucht Belege: Fotos vom Versandetikett, vom Außenkarton und vom Inhalt, angehängt an den Paketdatensatz. Wenn ein Lieferant drei Wochen später eine Minderlieferung bestreitet, ist dieses Foto das Argument. Wenn ein Kunde behauptet, zwei Artikel zurückgeschickt zu haben, Sie aber nur einen erhalten haben, klärt dieses Foto die Sache. Die meiste Inventarsoftware kennt kein Paket, das existiert, bevor es zugeordnet wurde, also behelfen sich Lager mit einer Handykamera, einem geteilten Ordner und dem Gedächtnis eines Mitarbeiters.
Der Etikettendruck ist die andere physische Einschränkung. Die Software muss mit den Thermodruckern funktionieren, die bereits an den Packtischen festgeschraubt sind: mit genau diesen Modellen, genau diesen Etikettengrößen und genau den Eigenheiten ihrer Treiber. Standardtools unterstützen oft nur eine kurze Liste an Hardware und erwarten, dass Sie sich danach richten. Wenn Sie sechs Packplätze betreiben und ein Ersatzdrucker eine Entscheidung über $400 ist, wird Software, die neue Geräte erzwingt, teurer, als es auf der Preisseite aussieht.
Nicht zugeordnete und abweichende Sendungen kosten Lager pro Woche die meisten Stunden. In Standardsoftware ist das fast nie eine Funktion, denn es ist ein Problem, das sich erst zeigt, wenn man selbst an einer Rampe gearbeitet hat. Genau deshalb baut es niemand in ein Produkt ein, das für alle gedacht ist.
Lieferanten über eine einfache Kontaktliste hinaus verwalten
Sobald Ihr Sortiment ein paar hundert Artikel überschreitet, sind Lieferanten keine Kontakte mehr, sondern ein Preissystem.
Sie brauchen mehrere Lieferanten pro Produkt, weil einer günstiger und einer schneller ist und Sie je nach Lagerbestand wechseln. Sie brauchen lieferantenspezifische SKUs, weil deren Artikelnummer nicht Ihre Artikelnummer ist und die Zuordnung irgendwo anders liegen muss als im Kopf eines Einkäufers. Sie brauchen auch historische Kosten, denn der Preis, den Sie im März gezahlt haben, zählt, wenn Sie im September die Marge inklusive Einstandskosten für Ware berechnen, die noch im Lager liegt. Und Sie brauchen Lieferzeiten, die sich pro Produkt überschreiben lassen, denn die angegebenen 14 Tage des Lieferanten stimmen für die meisten Artikel und sind reine Fiktion für die drei, die er direkt aus Übersee versendet.
Standardtools behandeln Lieferanten als flache Kontaktliste mit Name, E-Mail und vielleicht einer Standard-Lieferzeit. Das ist ein Adressbuch, keine Software zur Verfolgung von Lieferzeiten. Es kann Ihnen nicht sagen, bei welchem Lieferanten Sie heute nachbestellen sollten, angesichts des aktuellen Bestands, des aktuellen Preises und der tatsächlichen bisherigen Lieferleistung, und genau das ist die einzige Frage, die eine Einkaufsentscheidung je stellt.
Gute Software zur Verfolgung von Lieferzeiten erfasst, was versprochen wurde und was tatsächlich ankam, und nutzt dann die Differenz. Nach sechs Monaten bestellen Sie nicht mehr nach den Versprechen der Lieferanten nach, sondern nach ihrem tatsächlichen Verhalten. Für Unternehmen, die nennenswertes Umlaufkapital im Bestand gebunden haben, rechtfertigt allein diese Umstellung meist schon die Entwicklung.
Warum Template-Skripte für die Lagerarbeit nicht ausreichen
Marktplatz-Skripte sind bewusst für ein allgemeines Publikum gebaut. Das ist ihr Geschäftsmodell, und es funktioniert gut bei einfachen Produkten: einem schlichten Verzeichnis, einem unkomplizierten Buchungsablauf, einer Kleinanzeigen-Website. Lagerbetriebe passen schlecht zu diesem Modell, weil fast alles, worauf es ankommt, betriebsspezifisch ist.
RMA-Status sind ein gutes Beispiel. Ihr Retourenablauf könnte lauten: angefragt, genehmigt, Etikett versendet, eingegangen, geprüft, wieder eingelagert oder entsorgt, erstattet. Bei einem anderen Unternehmen sind es vier Schritte. Bei einem dritten gehört eine Reparaturschleife dazu. Ein Template kann nicht alle davon mitliefern, also liefert es keinen mit, und Sie müssen Ihren Ablauf nach dem Kauf nachträglich anflanschen.
Dasselbe gilt für die Paketannahme, Lieferzeiten von Lieferanten und die Synchronisierung von Bestellungen über mehrere Shops.
Hier aber die ehrliche Version: Ein günstiges Skript ist kein verschwendetes Geld, wenn Ihr Betrieb wirklich einfach ist. Wenn Sie eine Bestandsliste, eine Nachbestellwarnung und einen Barcode-Scan brauchen, kaufen Sie das Skript und setzen Sie das gesparte Budget anderswo ein. Teuer wird das Skript genau dann, wenn das Retourenvolumen wächst, wenn ein zweiter Lieferant hinzukommt oder wenn Sie eine echte Shopify-Anbindung für das Lager brauchen, die Daten in beide Richtungen überträgt.
Die Entscheidung lautet nicht abstrakt Template gegen Individualentwicklung. Es geht darum, ob die Komplexität, die Sie heute haben, auch die Komplexität ist, die Sie in 18 Monaten haben werden.
Zeitplan einer individuellen Entwicklung und Kosten einer Lager-App
Komplexe operative Software wird in Meilensteinen gebaut, und der erste ist nie eine Lagerfunktion.
Meilenstein eins ist das Fundament der Plattform: Authentifizierung, rollenbasierte Berechtigungen, das Grundgerüst der Admin-Oberfläche und die Datenbankarchitektur, auf der alles andere aufbaut. Das ist unspektakulär, und es ist genau der Meilenstein, der entscheidet, ob die Meilensteine drei bis sechs reibungslos oder mühsam verlaufen. Ein Kunde bat uns einmal, ihn zu überspringen und mit dem Inventar zu beginnen. Wir haben es nicht getan, und als das Retourenmodul sechs Wochen später vier verschiedene Berechtigungsstufen brauchte, war der Grund offensichtlich.
Danach sieht eine typische Abfolge so aus: Integration von Bestellungen und Problemfällen, einschließlich der Shopify-Anbindung für das Lager, die Live-Bestelldaten abruft. Dann Retouren und das RMA- und Retourenmanagement-System. Dann Inventar, Lagerplätze und die Bestandssynchronisierung über mehrere Lager. Dann Lieferanten, Kosten und Lieferzeiten. Jede Phase wird als funktionierendes, prüfbares Ergebnis geliefert. Sie loggen sich ein, klicken sich durch und sagen uns, was nicht stimmt, bevor die nächste Phase beginnt. So behält ein Gründer ohne technischen Hintergrund die Kontrolle über ein technisches Projekt: nicht durch das Lesen von Code, sondern indem er das Produkt alle paar Wochen selbst nutzt.
Zu den Entwicklungskosten einer Lager-App: Bei Appkodes beginnen erste Versionen ab $8,000, wobei der Umfang vor Beginn jeder Arbeit als Festpreis mit festem Launch-Termin vereinbart wird. Das ist dieselbe Struktur, die wir für eine Liefer-App oder eine Plattform zur Fernüberwachung von Patienten nutzen, und es gibt sie, weil unberechenbare Rechnungen das sind, was Gründer an individueller Software am meisten fürchten.
Was den Betrag bewegt, sind Module, nicht Stunden. Ein Bestandssystem für ein einzelnes Lager mit grundlegender Bestellsynchronisierung liegt am unteren Ende der Spanne. Kommen ein vollständiges RMA- und Retourenmanagement-System, eine Shopify-Anbindung für mehrere Shops, Software zur Verfolgung von Lieferzeiten und eine Paketannahme mit Fotobelegen hinzu, steigen die Entwicklungskosten der Lager-App entsprechend. Jedes davon ist ein echtes Teilsystem mit eigenem Datenmodell und eigenen Ansichten.
Wir kalkulieren sie einzeln, damit Sie sehen, was jedes kostet, und diejenigen zurückstellen können, die warten können. Unsere Leitfäden zur App-Entwicklung zeigen, wie dieses Gespräch über den Umfang in der Praxis abläuft.
So entscheiden Sie: eine praktische Checkliste
Prüfen Sie Ihren Betrieb anhand dieser Punkte. Die Antworten sind meist klarer, als die Debatte vermuten lässt.
Kaufen Sie Standardsoftware, wenn: Sie Bestände an einem einzigen Standort führen, mit ein oder zwei Lieferanten zu stabilen Konditionen arbeiten, Retouren eher gelegentlich als systematisch vorkommen und Ihr Bestellvolumen keine Echtzeit-Synchronisierung mit einer Verkaufsplattform erfordert. Ein Template oder ein SaaS-Abo deckt das ab, und individuelle Software wäre überdimensioniert.
Entwickeln Sie individuell, wenn: Sie mehr als einen Standort betreiben und eine Bestandssynchronisierung über mehrere Lager brauchen, die die Realität abbildet statt des Exports von gestern Abend. Oder wenn Sie Retouren in großer Zahl bearbeiten und den Überblick über Lieferantenreklamationen verlieren. Oder wenn Sie mehrere Shopify-Shops betreiben, die ohne Überverkauf auf einen gemeinsamen Bestand zugreifen müssen. Oder wenn Ihre Kommissionierregeln, Ihre Zustandsbewertung oder Ihre Compliance-Anforderungen, etwa Kühlkette, Chargen- und Mindesthaltbarkeitsverfolgung oder Rückverfolgbarkeit per Seriennummer, in keinem Produkt, das Sie getestet haben, als Option existieren.
Noch ein Test, und er funktioniert bei jedem Anbieter, auch bei uns. Fragen Sie nicht, ob eine Funktion existiert. Fragen Sie stattdessen, wie sie abgebildet ist. Wie unterscheidet sich in Ihren Daten eine Erstattung an den Kunden von einer Erstattung durch den Lieferanten? Was passiert mit einem Paket, das ohne Papiere ankommt? Wo liegt die produktbezogene Anpassung der Lieferzeit? Anbieter mit echter Lagererfahrung antworten mit Details. Anbieter ohne sie antworten mit Funktionsnamen.
Wenn Sie noch klären, was Sie überhaupt bauen wollen, behandelt unser Leitfaden zur Erstellung einer App für Ihr Unternehmen die Grundlagen. Derselbe Meilenstein-Ansatz, den wir für Apps für Immobilienentwicklung nutzen, lässt sich direkt auf operative Software wie diese übertragen.
Bereit, den Umfang Ihres Lagersystems festzulegen? Erzählen Sie uns, wie Ihr Betrieb wirklich funktioniert, mit Retouren, Lieferanten, Shops und allem Drum und Dran, und wir melden uns mit einem Umfang Modul für Modul und einem Festpreis. Angebot anfordern, vereinbart vor dem Start.
Häufige Fragen
Lohnt sich eine individuelle Lager-App im Vergleich zu einem günstigen Skript?
Für eine einfache Bestandsführung mit einem Lieferanten und einem Standort reicht ein Skript, und Sie sollten eines kaufen. Entscheidend ist, wo Ihr Betrieb in 18 Monaten stehen wird, nicht wo er heute steht.
Kann ein Gründer ohne technischen Hintergrund die Entwicklung eines individuellen Lagersystems steuern?
Ja, und die meisten unserer Kunden im Lagerbereich sind Praktiker aus dem operativen Geschäft, keine Entwickler. Die Struktur übernimmt die Arbeit: ein Festpreis und ein fester Launch-Termin, vereinbart bevor irgendetwas beginnt, danach Meilenstein-Lieferungen, in die Sie sich einloggen und die Sie testen können. Sie prüfen funktionierende Features, keine Spezifikationen. Wenn die Retouren-Ansicht nicht dazu passt, wie Ihr Team Retouren tatsächlich bearbeitet, sagen Sie das an diesem Meilenstein und nicht erst beim Launch.
Bleiben die Kosten im Rahmen des ursprünglichen Angebots?
Wir vereinbaren vor Arbeitsbeginn einen Festpreis und einen festen Launch-Termin, sodass Umfang und Kosten von Anfang an feststehen. Der Vorbehalt, offen gesagt: Die Kosten hängen davon ab, wie viele Module Sie aufnehmen. Wer nach der Festlegung des Umfangs ein Lieferantenmanagement-System oder eine Shopify-Anbindung für mehrere Shops ergänzt, ändert den Umfang, und diesen Teil würden wir neu kalkulieren, statt ihn stillschweigend zu übernehmen. Nichts kommt auf Ihre Rechnung, ohne dass Sie vorher zugestimmt haben.
Wie lange dauert eine solche Entwicklung?
Der Zeitplan hängt vollständig vom Umfang ab. Zur Orientierung: Wir haben vergleichbare operative Apps, darunter eine Plattform für Medikamentenlieferung mit Bestellung, Disposition und Admin-Werkzeugen, in rund 30 Tagen gelauncht. Ein Lagersystem mit vier oder fünf Modulen dauert in der Regel länger, und wir nennen Ihnen den konkreten Termin als Teil des Angebots statt einer Schätzung, die Sie später anpassen müssten.
Arun Andiselvam
LinkedInIch bin Gründer und habe fünf Marken aufgebaut. Die erste, ein SEO-Werkzeug, habe ich für einen sechsstelligen Betrag verkauft, und heute leite ich Appkodes und entwickle individuelle Mobile- und Web-Apps für Gründer und Unternehmen. Jede davon habe ich vom ersten Tag an selbst finanziert.
