Multientitäten whaaaaat?
Könnt ihr euch noch an die Geschichten erinnern, dass die Erde eine Scheibe war und Christoph Columbus allem Zweifel zu Trotz gegen Westen segelnd Indien neu entdeckte? Nicht? Ok ja, zugegebenermaßen, das ist jenseits der Generation Y schon etwas lange her, dass dieses Thema im Geschichtsunterricht behandelt wurde. Ich will es trotzdem aufgreifen und den Vergleich mit unserer Expansion nach Deutschland wagen.
Wir drehen die Zeit zurück und schreiben das Jahr 2021 als die Nicewelt noch buchstäblich eine Scheibe war, alle Produkte aus dem Zentrallager in Saaz versendet wurden und jeder Shop nur eine Firma kannte. Zu dieser Zeit haben wir den Entschluss gefasst, das Segel zu setzen und in Ulm ein neues Warenlager für den Versand zu etablieren, was naturgemäß eine enorme Herausforderung für die Nicepeople und unsere Software bedeutete.
Wo soll ich also anfangen? Beginnen wir einfach mit der am offensichtlichsten erscheinenden Frage: Aus welchem Warenlager soll welche Bestellung versendet werden und wo hinterlegen wir das bei der Bestellung? Wir haben uns dazu entschlossen in der Datenbank eine neue Tabelle mit dem Namen “Company” anzulegen und diese mit allen möglichen Tabellen, wie eben auch jener für die Bestellung zu verknüpfen. Hierbei sei gesagt, dass der Name Company im weiteren Verlauf des Projektes und bis heute nicht die optimalste Entscheidung war und tatkräftig zur allgemeinen Verwirrung beigetragen hat. Denn wie sich schnell herausstellte, können wir neben den tatsächlichen Firmen auch verschiedene von Firmen abgeleitete Mandanten, also Online-Filialen, Stores, Kommittenten bis hin zu Warenlagern abbilden, was uns zu dem Begriff der Multientitäten gebracht hat. Technisch gesehen hinterlegen wir also nicht das Warenlager selbst bei der Bestellung, sondern eine vom Warenlager Ulm abgeleitete, mit der Firma Niceshops verheiratete Online-Filiale.
Hier haben wir den Begriff der BusinessCaseCapableEntities eingeführt, um all jene Entitäten hervorzuheben, mit denen sogenannte Geschäftsfälle, wie es zum Beispiel Verkäufe sind, durchgeführt werden können. Da die Spannung gerade am Höhepunkt ist, möchte ich euch natürlich nicht vorenthalten, wie wir Bestellungen dem Warenlager in Ulm zuordnen. Grundsätzlich haben wir uns der Einfachheit halber dazu entschlossen, nur vollständig lagernde Bestellungen für den Zielmarkt Deutschland aus Ulm zu versenden und damit die Finance Prozesse nicht noch komplizierter werden, werden auch keine Firmenbestellungen von dort versendet. Trifft diese Regel nicht zu, wird automatisch das Warenlager Saaz für den Versand ausgewählt. Das ist sie also, die Zauberformel, die wir liebevoll in ein Policy System gebündelt und für weitere Standorte und Anforderungen vorbereitet haben.
Damit diese Statemachine aus zufällig anmutend aneinander gereihten Nullen und Einsen funktioniert, muss nun also ein Lagerstand dem Warenlager Ulm zugeordnet werden. Hierfür haben wir den Tabellen für die Eingangslieferungen, dem Lagerplatz selbst und der Verknüpfung von Produkt und Lagerplatz eine Company zugeordnet. Nur so war es uns möglich, im gesamten Prozess innerhalb des Warenlagers den Eigentümer zu definieren und Warenanlieferungen für einen expliziten Standort anzulegen.
Dies führt uns aber auch schon zum nächsten Problem. Denn keiner wusste, wie viel von welchem Produkt in Deutschland idealerweise lagern sollte, um mit so wenig unterschiedlichen SKUs so viele Bestellungen wie möglich abzuwickeln. In erster Linie wurden Topseller, die oft alleine in Bestellungen vorkamen, manuell herausgesucht und direkt aus dem Zentrallager nach Ulm geschickt. Da dies aber nur mäßig sinnvoll war und wir uns aber in den ersten Sprints auf den Versand konzentriert haben, war dies die beste Möglichkeit, alle Prozesse in Ulm zu testen. Das tatsächliche Problem galt es aber jetzt zu lösen, denn wie es schon in der Antike erkannt wurde, gab es entweder zuerst die Henne oder das Ei. Wie befüllt man automatisiert ein Warenlager ohne historische Daten für Verkäufe aus einem Warenlager? Wie ihr euch schon denken könnt, gar nicht! Durch einen Trick konnten wir aber zumindest einen Startwert definieren. Wir haben einfach die Annahme getroffen, dass der gesamte Deutsche Markt aus Ulm bedient wird und haben die Unschärfe ignoriert, dass nur vollständig lagernde Bestellungen aus Ulm versendet werden. Tendenziell wird hierdurch zwar zu viel auf Lager gelegt, aber es sollte sich spätestens in ein paar Wochen die tatsächliche Statistik dem kalkulatorischen Wert annähern und ein Umstellen auf die tatsächliche Statistik möglich sein.
Darüber hinaus hatte der erste MVP noch keinerlei Änderungen im Online Shop beinhaltet, hier wurde einfach beim Bestellabschluss die Berechnung für den Warenort durchgeführt und die Bestellung ohne die Kund:innen zu informieren aus Ulm versendet. Dies war dahingehend kein Problem, da die Lieferzeit durch die verlängerte Cutoff-Zeit des Lieferdienstes am Standort Ulm nur besser werden konnte. Im weiteren Projektverlauf haben wir dann einen zweiten Lieferdienst auf das Warenlager umgestellt. In diesem Zusammenhang wurde die Entscheidung, aus welchem Warenlager die Bestellung versendet wird, im Checkout implementiert und es konnten basierend auf dem Absendewarenlager die richtigen Lieferdienste, Deadlines und Lieferzeiten ausgegeben werden. Somit waren die Logistikprozesse vom Lagerein- bis Lagerausgang erweitert und alle Anforderungen für den Onlineshop umgesetzt. Naja Fast, technisch gesehen war alles okay, aber rechtlich musste noch eine Kleinigkeit für den lieben Fiskus umgesetzt werden. Habt ihr schon mal etwas von innergemeinschaftlicher Verbringung gehört? Nicht? Das ist definitiv eine Bildungslücke. Scherz beiseite, das ist nur eines von vielen Beispielen, das bei diesem Unterfangen auf die Finance zugekommen ist. Hierbei handelt es sich, wie der Name schon sagt, um eine Warenumlagerung im gleichen Unternehmen, aber einem anderen Land innerhalb der EU. Dieser und viele weitere Geschäftsfälle mussten aufgezeichnet und der Buchhaltung übermittelt werden. Darüber hinaus musste jeder Beleg, der in unserem System nun ausgestellt wird, fix einer unveränderlichen Revision der Firmen-Konfiguration zugeordnet werden. Diese Revisionen werden automatisch bei Änderungen an der Konfiguration erstellt und halten Informationen über die dem Geschäftsfall zugrundeliegende Firmen.
In diesem Projekt oder Epic, wie wir es in unserer Sprache nennen, haben wir die Software gleich in vielerlei Hinsicht verbessert und auf die Anforderungen in der Zukunft vorbereitet. Quasi im Vorbeigehen haben wir das Problem für unser Fulfillment gelöst, bei dem wir für mehrere Mandanten in einem Backend die Logistik abwickeln. Darüber hinaus ist auch die Abtrennung der einzelnen Stores nun viel sauberer über die eigenen Entitäten für das Warenlager und die Kostenstelle abgebildet. Wäre das noch nicht genug, haben wir auch die Kommissionsabrechnung im niceshops Universum revolutioniert und den Grundstein für das Loslösen des Warenlagermodules aus dem ERP System gelegt. Projekttechnisch war dies eines der herausforderndsten Änderungen der vergangenen Jahre, insgesamt waren 3 Teams in 2 Sprints, also insgesamt ein Monat, parallel damit beschäftigt, das MVP für den Versand aus dem Boden zu stampfen. Nach dieser Umstellung wurden die Prozesse im Live Betrieb analysiert und Verbesserungen vorgenommen. Erst ein halbes Jahr und weitere 3 Sprints später wurde anschließend das Bestellwesen für die Waren und die Statistiken der Artikel für die Warenlager erweitert und das Produkt konnte vollumfänglich in einen Testbetrieb starten.
Stay Nice!
