Der Kunde wollte einen Webshop. Wir haben weiter gedacht.

Auf einen Blick

• Ausgangslage: Ein Pharmahersteller wünschte sich einen eigenen kleinen Webshop, der ihn warnt, bevor ein Artikel im Lager knapp wird.
• Lösung: Statt eines vollständigen Webshops haben wir einen schlanken, von Beginn an mandantenfähigen eService gebaut, der Bestände mehrfach täglich abgleicht und bei Unterschreitung automatisch warnt.
• Ergebnis: Der Dienst läuft produktiv im Live-Betrieb und ist vorbereitet, weitere Mandanten ohne nennenswerten Mehraufwand aufzunehmen.

Die Ausgangslage

Ein Pharmahersteller lagert sein Handelssortiment bei einem GDP-zertifizierten Logistik-Dienstleister. Sein Anliegen ist einfach und ernst zugleich: Kein Artikel soll unbemerkt unter eine kritische Menge fallen. Eine Out-of-Stock-Situation kostet Lieferfähigkeit, und die Nachproduktion eines Arzneimittels braucht Vorlauf, den man nur hat, wenn man die Lücke früh genug sieht.

Der Kunde kam mit einer konkreten Vorstellung: ein eigener kleiner Webshop, der genau eine Aufgabe erfüllt, die Bestandswarnung. Diese Idee fiel nicht vom Himmel. In den geschlossenen Bestellportalen, die wir für diesen Dienstleister und seine Mandanten seit Jahren betreiben, ist eine automatische Bestandswarnung ein bewährtes, viel genutztes Modul. Der Kunde kannte das Feature aus dem Alltag und wollte es isoliert haben.

Unser Ansatz

Ein vollständiger Webshop für eine einzige Warnfunktion wäre Overhead gewesen: Einrichtung, Stammdatenpflege und Abhängigkeiten, die der Zweck nicht rechtfertigt. Davon haben wir abgeraten. Stattdessen haben wir einen dedizierten, abgeschlossenen eService auf aktueller Symfony-Basis vorgeschlagen. Eine Aufgabe, sauber gelöst, einfach zu betreiben.

Eine zweite Entscheidung ging über den Auftrag hinaus: Wir haben den Dienst von Beginn an mandantenfähig angelegt, obwohl nur ein Kunde danach gefragt hatte. Der Grund kam aus der Erfahrung, nicht aus dem Lastenheft. Was in jedem Bestellportal als Modul steckt und überall genutzt wird, ist kein Einzelfall, sondern ein wiederkehrender Bedarf. Ein solcher Bedarf lohnt sich als eigenständiger, wiederverwendbarer Dienst.

Auch technisch haben wir den pragmatischen Weg gewählt. Die zunächst vermutete Schnittstelle stellte sich als nicht nötig heraus: Die Bestandsdaten lagen bereits als Standard-Lagerreport vor, der mehrfach täglich als Datei bereitsteht. Kein neuer Datenkanal, keine zusätzliche Last beim Dienstleister. Wir haben verbunden, was schon da war.

Die Lösung

• Mehrfach täglicher Bestandsabgleich. Der Dienst liest den Lagerreport automatisch ein und hält die Artikelstämme synchron, ohne manuelle Pflege.
• Präzise Bestandslogik. Gewarnt wird nur auf die tatsächlich frei verfügbare Menge. Reservierte, gesperrte und Quarantäne-Bestände werden korrekt getrennt und zur Einordnung mit ausgewiesen, damit eine Warnung nicht in die Irre führt.
• Schwellen je Artikel. Meldebestand und Empfänger sind pro Artikel pflegbar; eine Unterschreitung löst automatisch eine E-Mail-Warnung aus.
• Selbstpflegende Stammdaten. Neue Artikel kommen mit dem Import, entfallene verschwinden automatisch. Das Backend bleibt sauber, ohne dass jemand aufräumen muss.
• Saubere Mandantentrennung. Jeder Mandant sieht ausschließlich seine eigenen Artikel und Empfänger.

Die Wendung

Aus einer Funktion, die der Kunde isoliert haben wollte, ist ein eigenständiges Asset geworden, ein Dienst, der nicht für einen Mandanten gedacht ist, sondern für viele tragfähig bleibt.

Weil wir die Branche und die Bestellportale dieses Dienstleisters über Jahre kennen, haben wir den Hebel gesehen, bevor er ausgesprochen war: Dieselbe Bestandswarnung, die praktisch jeder Lagerkunde irgendwann braucht, lässt sich als zentraler Dienst anbieten und wird so vom internen Feature zum Mehrwert, den der Logistik-Dienstleister seinen eigenen Kunden machen kann. Wir haben dazu nicht nur die Technik geliefert, sondern einen fundierten, zeitgemäßen Plan, wie sich aus diesem neuen Asset wiederkehrender Wert erschließen lässt, damit es sich schnell trägt und danach etwas einbringt.

Das ist die Rolle, die wir hier ausfüllen: extern, aber mit dem Blick eines eigenen Mitarbeiters, der Entwicklung, Strategie und Projektmanagement zusammendenkt und Geschäftsentscheidungen antizipiert, statt nur abzuarbeiten.

Das Ergebnis

• Produktiv im Live-Betrieb, in echten Tests mit realen Beständen bestätigt, nicht in einem Dummy-Setup.
• Robuste Detaillogik aus echten Anforderungen, etwa der korrekte Umgang mit gelöschten Artikeln und das erwartungskonforme Verhalten beim Anpassen von Schwellen.
• Vorbereitet, weitere Mandanten ohne nennenswerten Mehraufwand aufzunehmen. Die Grundlage für die Skalierung steht.
• Läuft auf der bereits vorhandenen Lager-Schnittstelle, ohne zusätzlichen Datenkanal.

Was diese Geschichte zeigt

Der schnellste Weg, eine Aufgabe abzuhaken, ist selten der beste. Wer die Systeme und das Geschäft eines Kunden über Jahre kennt, kann den richtigen Schnitt machen: nicht den gewünschten Webshop, sondern den Dienst, der genau zwischen Lagersystem und Mandant die Lücke füllt, die sonst offen bleibt, und der sich vervielfältigen lässt.

Dieselbe Denkweise, mit der wir im E-Commerce Sortimente und Bestände steuern, trägt auch im regulierten Pharma-Umfeld. Eine Arbeitsweise, zwei Welten.

Dieses Weiterdenken vor dem Bauen ist kein Zufall, sondern Methode - nachzulesen unter Beratung & Architektur für die Pharma-Logistik.