Unser Lagerhaus mit der Größe von zwei roten Quadraten und einer Höhe von 5 Etagen ist das ganze Jahr über geöffnet und schläft nie - 24/7 364 Tage im Jahr (der einzige freie Tag ist der 1. Januar). Wir haben mehr als 8.000.000 Waren gelagert und gewartet, jeden Tag wechseln mehr als 300 Betreiber. Sie arbeiten mit Waren aus aller Welt und sammeln Bestellungen für Benutzer aus vier Ländern: Russland, Ukraine, Weißrussland und Kasachstan. In einem solchen Ausmaß erfordert das Geschäft eine einwandfreie Automatisierung.
Unter dem Strich werde ich, Pasha Finkelstein - Teamleiter für die Entwicklung und Automatisierung des Lagers - Ihnen sagen, was eine Open Source-Lösung wachsen kann, wenn Sie ein gutes Entwicklungsteam und eine ganz bestimmte Geschäftsaufgabe hinzufügen.
Grundlegende Logik
Drei Hauptprozesse eines Lagers: Annahme von Waren, Lagerung und Versand. Der vereinfachte Zyklus unseres Lagers sieht folgendermaßen aus: primäre Identifizierung, Qualitätskontrolle, Platzierung, Auswahl und Reservierung für eine Bestellung, Suche, Sortierung, Verpackung, Übergabe an einen Lieferservice. Wenn der Kunde das Produkt zurückgibt, wiederholt sich der Zyklus. Jede an diesen Prozessen beteiligte physische Einheit verfügt über eine eigene Informationsdarstellung, z. B. LKW, Produkt, Schrankzelle, Paket, Verpackungsmaterial, Container usw. Alle wesentlichen Bewegungen und Änderungen des Warenstatus werden in Buchhaltungssysteme übersetzt und absolut jede Aktion mit den Waren innerhalb des Lagers wird protokolliert.
WMS (Warehouse Management System) steuert den Lebenszyklus jedes Produkts im Lager vom Moment des Eintreffens des LKW mit den Waren des Lieferanten im Lager bis zum Versand der Waren an den Kunden.
Die Besonderheiten der Modeautomation
Unser Unternehmen ist im Bereich Mode und Lifestyle tätig, was bestimmte Aufgaben im Lager aufwirft: Das Produkt kann zerbrechlich (Brille, Uhren), nicht standardmäßig groß (Winterstiefel oder Schmuck), hochwertig (in Spezialverpackung) sein - oder andere spezifische Eigenschaften aufweisen, die Das Lager muss berücksichtigen. Daher ist es unmöglich, den Einsatz von Handarbeit in Lagerbereichen vollständig aufzugeben.
Alle anderen Prozesse sind automatisiert - Warenannahme, Übergabe an den Versandbereich, Sortieren, Verpacken und Versandvorbereitung. Jeder dieser Prozesse erfordert spezielle Ausrüstung und einen Betriebsprozess. Magie entsteht, wenn all diese Prozesse „zusammenhalten“ und dank unserer Systeme zusammenarbeiten.
Jedes Versehen in der Lagerautomatisierung - sei es eine Schnittstelle, die zu Bedienungsfehlern, einem nicht optimalen Prozess usw. beiträgt. - Dies ist eine Verzögerung beim Versand, die Ausfallzeit des gesamten Komplexes, enorme Verluste. Darüber hinaus schaffen wir mit jedem Fehler ein negatives Kundenerlebnis. Daher ist es uns wichtig, dass das Lager wie eine Uhr funktioniert.
Open Source und der Weg zur eigenen Entwicklung
In der Eröffnungsphase haben wir ein externes Lager genutzt. Mit dem Volumenwachstum begannen wir zu verstehen, dass wir die volle Kontrolle über betriebliche Prozesse und eine hohe Änderungsrate dieser Prozesse benötigen, und beschlossen daher, auf unser eigenes Lager und unsere eigene Entwicklung umzusteigen.
Die Hauptfrage, mit der wir uns dann konfrontiert sahen, war die Ausarbeitung der operativen Prozesse in allen Details. Bis dahin, wohin und wie Mitarbeiter gehen, wie viele Scans sie durchführen usw. Bereits bei diesen Prozessen musste WMS bereitgestellt werden, das die operativen Aktivitäten verwaltet und den Routinebetrieb automatisiert.
Zunächst nahmen sie eine Open-Source-Lösung in Java und beschlossen dann, ein eigenes Entwicklungsteam zusammenzustellen, zumal es bereits eine geeignete Grundlage gibt. Wir haben die Funktionalität erweitert und dann den Kern des Systems übernommen: Wir haben das Erbe beseitigt und einen fetten Kunden, haben Refactoring durchgeführt und neue Services zur Unterstützung von Betriebsprozessen entwickelt.
Automatisierungsstufen
Die wichtigsten Änderungen wurden von den „Wellen“ zusammen mit der Umstrukturierung der Prozesse selbst durchgeführt.
Bis heute hat er neun Modernisierungsphasen durchlaufen, und wir planen nicht, darauf einzugehen.
- In der ersten und zweiten Phase haben wir den Versand von Bestellungen automatisiert - wir haben Förderbänder hinzugefügt, Logik zum Sortieren von Waren, automatisiertes Sortieren von Bestellungen nach Paletten.
- In der dritten und vierten Phase haben wir uns auf die Akzeptanzprozesse konzentriert: Wir haben gelernt, wie die Warenströme nach verschiedenen Arten und Lagerzonen getrennt werden können.
- In der fünften Phase wurden automatisierte Aufzüge zwischen den Stockwerken hinzugefügt - so begannen die Arbeiten im Lagerbereich.
- Die sechste Phase war die kritischste, als wir die Akzeptanz- und Versandzonen schlossen und die gesamte Automatisierung durchliefen.
- In der siebten und achten Phase haben wir die Prozesse in der Akzeptanzzone geändert und neue Zonen, Aufzüge und Förderer hinzugefügt: Wir haben die vorhandene Automatisierung skaliert.
- In der neunten Phase wurde das Lager um ein neues Gebäude erweitert und in das bestehende Automatisierungssystem integriert.
Implementierung
Unsere Kerntechnologien: Java, Postgres, Wildfly, Redis, ActiveMQ.
WMS ist in Java 8 geschrieben. Vor nicht allzu langer Zeit haben wir behoben, dass das letzte Modul, das den Übergang zu Java 11 verhinderte, in naher Zukunft aktualisiert wird.
Ein direkt im Warehouse installiertes Server-Rack ist für WMS reserviert. Dies gibt uns viel mehr Vertrauen, dass WMS auch dann funktioniert, wenn der Strom und / oder das Internet ausgeschaltet sind. Das einzige, was darunter leiden wird, ist, dass Nachrichten an das Buchhaltungssystem mit einer Verzögerung kommen. WildFly wird als Anwendungsserver verwendet, obwohl es noch nicht die neueste Version ist. Eine Migration zu letzterem ist ebenfalls geplant. Alles wurde bereits für den Umzug geschrieben, es ist jedoch noch nicht gelungen, Funktions- und Lasttests durchzuführen, und vor dem neuen Jahr ist die Last relativ hoch. Ein bewährter ActiveMQ wird ebenfalls verwendet.
Die Daten, die wir in PostgreSQL speichern. Die Hauptessenz in unserem System ist offensichtlich ein Produkt. Manchmal finden Lagermitarbeiter Problemumgehungen, um ihre Arbeit zu vereinfachen. Beispielsweise scannen sie denselben Barcode 50 Mal, und das Produkt selbst wird einfach von Hand geworfen, ohne zu scannen, ohne auf Details, Jeans oder T-Shirts einzugehen. Daher haben wir Etiketten eingegeben, die eine bestimmte Einheit identifizieren Waren, die es in der Infrastruktur unterstützen. Informationen zu diesen Einheiten werden in einer 2-Terabyte-PostgreSQL-Datenbank gespeichert.
Der größte Teil des Ortes wird nicht einmal von Waren besetzt, sondern von einer Prüfung der Handlungen der Lagerarbeiter. Als geschäftskritisches System muss das Lager wissen, warum etwas im System angezeigt wurde oder verschwunden ist. Wir können keine nicht nachverfolgbaren Änderungen zulassen. Im Moment denken wir darüber nach, diesen Teil der Datenbank in eine separate Entität in MongoDB zu integrieren.
Workstations für Lagermitarbeiter sind Thin Web-Clients. Irgendwann zu Beginn der Automatisierung funktionierte dies alles nach dem Prinzip eines Thick Clients, was insbesondere bei großen Releases, die Änderungen an der Benutzeroberfläche beinhalteten, zu gewissen Schwierigkeiten führte: Etwa 150 Workstations mussten manuell aktualisiert werden. Dies und die Tatsache, dass wir nicht ohne Ausfallzeiten veröffentlichen konnten, setzten uns Grenzen - wir konnten nicht mehr als zweimal pro Woche am frühen Morgen, wenn die Nachtschicht endet, bereitstellen, was nicht als praktischer Zeitplan bezeichnet werden kann. Jetzt haben wir WMS ins Web übertragen und bis Ende des Jahres werden wir fette Kunden vollständig aufgeben, was uns die Änderungen an der Benutzeroberfläche erheblich vereinfachen wird. Das Web und das in einer der Phasen hinzugefügte Clustering beseitigen Einschränkungen hinsichtlich der Häufigkeit und des Zeitpunkts von Veröffentlichungen. Jetzt erfahren Benutzer nur dann etwas über Veröffentlichungen, wenn ein Fehler aufgetreten ist.
Es gibt auch eine interessante "Exotik" in unserem Lager. Zum Beispiel das in
Technoradar erwähnte Haskell, auf das das Back-End der Visualisierung des Artikelsortierers geschrieben ist (dies ist eine solche Maschine, die Waren aus einer Verpackung zusammensetzen und dem Montagebetreiber übergeben kann). Es gibt ein rein rechnerisches Problem, das bequem in einem funktionalen Stil gelöst werden kann. Natürlich wird niemand Haskell für Großprojekte verwenden.
Ein weiteres Element des Lagers, das wir im
Artikel über Technoradar erwähnt haben, ist eine selbstgeschriebene
Zustandsmaschine , die die richtige Abfolge von Aktionen für jedes Produkt „überwacht“. Es entwickelte sich wie das gesamte System iterativ und begann mit einer Reihe einfacher Einschränkungen. Jetzt ist es eine sehr praktische Sache, die tief in unser System integriert ist. Wir hoffen, dass wir es in naher Zukunft als
Open Source veröffentlichen können - vielleicht ist es nicht nur für uns nützlich.
Automatisierungsausrüstung
Was für eine Automatisierung ohne Ausrüstung! Das gesamte Lager ist in ein ganzes Netzwerk von Förderbändern eingebunden.
Der oben erwähnte Artikelsortierer funktioniert bereits in der Versandphase, sodass Sie Zehntausende von Wareneinheiten aus dem Lager für bestimmte Bestellungen auslegen können. Zu einer Zeit ersparte der Sortierer unseren Bedienern die Notwendigkeit, mit einem Wagen durch das Lager zu fahren, um die erforderlichen Waren abzuholen. Bestellungen werden aufgeteilt, jeder Bediener holt Waren nur von seiner Etage ab (was Zeit beim Umzug spart), und der Sortierer sorgt dafür, dass Waren aus verschiedenen Etagen automatisch in die richtigen Bestellungen gelangen. Eine vierfache Änderung des Betriebsprozesses beschleunigte die Montage des Auftrags und reduzierte die Anzahl der Fehler erheblich.
Alle automatisierten Geräte werden von unserem Partner bereitgestellt. Für die Verwaltung bestimmter Einheiten verfügen sie über ein eigenes System, das sich im Server-Rack neben unserem WMS befindet. Die Integration zwischen den Systemen erfolgt über ein Protokoll auf hoher Ebene - wir kommunizieren über SOAP. Von unseren betrieblichen Prozessen innerhalb von WMS wenden wir uns ihrem System zu, wenn wir beispielsweise einen Container mit Waren von Punkt A nach Punkt B bewegen müssen. Aus Sicht unseres Systems sieht all diese Automatisierung trotz ihrer tatsächlichen internen Komplexität recht einfach aus.
Natürlich hat diese scheinbare Einfachheit nicht sofort funktioniert. In den ersten Phasen der Automatisierung hatten wir ein „gegenseitiges Schleifen“ von Technologien. Sobald der Förderer unsere Waren buchstäblich verbrannt hatte - die Geschwindigkeit des Förderbandes war zu hoch, "kaute" er die Waren und brannte ab, was die Montage anderer Bestellungen blockierte. Die vielleicht schwierigste Geschichte ereignete sich zu Beginn der Automatisierung, als wir die erste Phase starteten. Gestern war das Lager komplett manuell und heute, nach dem Umschalten des Schalters, sollte es automatisch werden. Aber nichts hat funktioniert: Aufgrund eines Fehlers bei der Integration des Systems wurden die Nachrichten des jeweils anderen falsch interpretiert, was zu mehreren Tagen Lagerausfall und Millionen von Verlusten für uns führte.
Jetzt ist der Partner in unserem Lager anwesend, plant, Geräte für eine neue Automatisierungsrunde mit uns zu vereinbaren, und hilft beim Testen neuer Blöcke.
Team und Scrumban
Die Entwicklung dieses gesamten Systems erfolgt nun in einem Team von 12 Personen. In einer der letzten Phasen des Höhepunkts der Modernisierung, in der separat automatisierte Prozesse zu einem Ganzen zusammengefasst werden sollten, nahmen allein bis zu 20 Entwickler teil (diese Phase erforderte 132 Personenmonate und umfasste mehr als 1.500 Commits). Aber als große Transformationen enden, entschieden sich einige Leute, Go oder Python zu lernen und wechselten zu anderen Entwicklungsteams.
Im Team haben wir „klassische“ Projektmanager, die die Funktionen eines Produkts und eines Projekts aus der IT kombinieren (durchschnittlich eine PM für 5-6 Personen). Zu seinen Aufgaben gehört die Kommunikation mit unserem Hauptkunden - einem Lager, das von seinem Direktor vertreten wird, und der Abteilung für die Entwicklung operativer Prozesse. Unsererseits sind wir mehr besorgt über die technische Modernisierung - Auswahl des richtigen Stacks, Updates usw. - Und die Leute vom Lager denken darüber nach, die Prozesse zu optimieren.
Manchmal widmen wir uns selbst der Forschung und Entwicklung vor Ort. Im wahrsten Sinne des Wortes kommen wir ins Lager, kommunizieren mit leitenden Schichten, mit normalen Bedienern und klären, welche Probleme sie haben, was bequem und unpraktisch für die Arbeit ist. Mit anderen Worten, wir führen User Experience Research durch.
Dank dieses Ansatzes haben wir beispielsweise die Schnittstelle des Arbeitsplatzes eines Mitarbeiters verändert, der die Warenannahme durchführt. Anfänglich war es eine komplexe Unternehmensschnittstelle mit vielen Feldern, Schaltflächen und Abkürzungen anstelle von Texterklärungen. Wir haben jedoch versucht, sowohl den Prozess als auch das Design zu optimieren, um es der Google-Hauptsuchseite ähnlicher zu machen - nicht so schön, aber sehr funktional. Je einfacher die Benutzeroberfläche und je weniger Optionen der Bediener hat, wo er klicken und was er scannen muss, desto weniger Fehler (und die Zeit, die erforderlich ist, um sie zu beheben).
Und das gesammelte Wissen über die Optimierung von Details überholt uns jetzt in den unerwartetsten Momenten: Sobald unser Team in der Institution war und in einem Moment fast alle Teilnehmer die Abfolge der Aktionen des Kassierers betrachteten. Nach ungefähr 40 Sekunden äußerte ein Kollege die allgemeine Idee: "Nicht sehr optimal, Sie können es vereinfachen."
Obwohl die Beziehung zwischen den Rollen im Team ziemlich klassisch ist, haben wir einen Scrumban für die Entwicklungsmethodik gewählt.
Wir haben viel mit Methoden experimentiert, während die Eingabedaten nicht dem Standard entsprachen. Zum Beispiel hatten wir eher seltene Veröffentlichungen. Die oben erwähnte Beschränkung auf zwei Releases pro Woche wirkte sich auf die Prozesse aus, aber tatsächlich haben wir viel seltener eingesetzt - durchschnittlich alle zwei Wochen. Darüber hinaus verfügten wir über eine Hardware für die Lagerautomatisierung, die von einem externen Unternehmen für sauberen Wasserfall entwickelt wird. Alle Änderungen werden zwei Jahre im Voraus mit allen erforderlichen Unterlagen geplant. Wir selbst konnten ihrem Beispiel jedoch nicht folgen: Wir mussten regelmäßig einige Änderungen am System vornehmen, und es war sinnlos, den Kunden zu zwingen, für jeden eine detaillierte Aufgabe zu schreiben.
Scrumban ist also ein Kompromiss, der alle glücklich gemacht hat. Wir verwenden einen iterativen Prozess, aber Sprint ist die Veröffentlichung für uns. Einmal im Monat treffen wir uns mit dem Kunden und planen die Veröffentlichung: Wir besprechen, welche und welche Woche wir einführen. Innerhalb des Sprints wird Kanban implementiert - mit einem Rückstand an Aufgaben, Fortschritten usw. Dieser Prozess ändert sich zwar allmählich - zum Beispiel haben wir kein Kanban-Board. Sobald ein Entwickler seine Aufgabe beendet hat, erhält er den nächsten aus dem Pool gemäß den Plänen für die nächste Version und den Kompetenzen des Entwicklers.
Wir mögen diesen Ansatz. Es bietet die erforderliche Flexibilität innerhalb von Iterationen und gibt dem Geschäftskunden die Vorhersehbarkeit der Daten, bis zu denen bestimmte Commits implementiert werden. Und es ist für uns nicht so wichtig, wie diese Methode heißt. Die Hauptsache ist, dass alles funktioniert.
Nicht wie alle anderen - am Beispiel von Inventar und Überwachung
Bei der Entwicklung von Betriebsprozessen haben wir von den Anforderungen unserer Branche ausgegangen, daher haben wir einige individuelle Merkmale.
Ein gutes Beispiel ist ein Inventar. Laut Gesetz muss es einmal im Jahr im Lager durchgeführt werden, aber unsere Geschäftsanforderungen bestimmen eine genauere Überwachung des Lagerbestands. Erstens möchten wir relevante Informationen über die Verfügbarkeit von Waren auf der Website wiedergeben, und zweitens benötigen unsere B2B-Partner, Modemarken, dieselben relevanten Informationen. Daher findet täglich an 364 Tagen im Jahr eine Bestandsaufnahme Regal für Regal im gesamten 5-stöckigen Komplex mehrerer Gebäude statt. Und dieser Prozess wird von unserem WMS voll unterstützt - es wäre schwierig, eine solche Lösung zu implementieren.
Jetzt wird das Inventar im nächsten Update aktualisiert, um die Effizienz dieses Prozesses zu erhöhen.
Ein weiteres Beispiel für unsere eigene Entwicklung ist die Überwachung. Es wird über einen Webclient implementiert und ermöglicht es Ihnen, sehr interessante Metriken anzuzeigen und zu verfolgen. Darüber hinaus ist uns eine visuelle Darstellung dieser Metriken wichtig. In der Tat ist die Überwachung ein Lagerhaus, das in einem einfachen Zeitplan dargestellt ist, in dem wir klar erkennen, an welchen Orten alles gut funktioniert und wo Probleme beobachtet werden (bis zu einem bestimmten Bediener). Vor allem können wir mit dieser Ansicht verstehen, warum diese Probleme auftreten.
KPI Warehouse Workers und Redis
Die Einführung neuer Technologien, Updates, Refactoring - alles ist großartig. Da unser WMS jedoch im realen Geschäft funktioniert, müssen wir hier nicht nur diese Probleme lösen. Ein Teil unserer Arbeit ist der Schutz vor internen "Hackern" - einfallsreichen Lagermitarbeitern, die neue Wege erfinden, um KPI unter Umgehung der Aufgabe durchzuführen.
Vor nicht allzu langer Zeit mussten wir beispielsweise Redis zum Stapel hinzufügen, um zu verhindern, dass sich Benutzer von mehreren Arbeitsstationen gleichzeitig beim System anmelden und ein Sitzungszeitlimit implementieren. Tatsache ist, dass Lagerarbeiter erkannt haben, dass es viel rentabler ist, unter demselben Login zu arbeiten und einen Bonus für das Überschreiten des KPI zu erhalten, als ihre eigene Produktivität zu steigern.
Da die Lösung des Geschäftsproblems Änderungen an verschiedenen Stellen des Systems erforderte, war dies aus technischer Sicht eine sehr interessante Herausforderung.
Die Überraschungen des Lagermitarbeiters endeten nicht dort. Fast unmittelbar nach der Veröffentlichung der Sitzung stürzte PostgreSQL ab. Wir suchten mehrere Tage lang nach den Gründen für den unerwarteten Abbau der Basis, bis wir feststellten, dass es sich wiederum um Einfallsreichtum handelte. Ein Mädchen ging oft rauchen. Als sie den Arbeitsplatz verließ, wurde sie aus der Sitzung ausgeschlossen. Um sich erneut anzumelden, musste die leitende Schicht gefunden und sein Abzeichen gescannt werden. Sie reduzierte ihre Streifzüge durch das Lagerhaus, riss einfach den Barcode aus einem der Wagen und befestigte den Scannerknopf mit Klebeband, um diesen Barcode ständig zu scannen. Und dies könnte lange Zeit unbemerkt bleiben, wenn der Barcode nicht aus dem Einkaufswagen stammt, der 800 Wareneinheiten enthält. Bei jedem Scan wurde eine große SQL-Abfrage generiert, um die Waren zu validieren, wodurch die Datenbank mit einem solchen "internen DDoS" "getötet" wurde. Ich musste mich um die Beschränkungen der Anzahl der Scans pro Zeiteinheit und der Anzahl der Waren im Warenkorb kümmern.
Es gibt bereits ziemlich viele solcher Geschichten, und wir sind ständig mit neuen konfrontiert. Darüber hinaus muss sich das System jedes Mal an neue Bedingungen anpassen. In solchen Situationen kann man sich nicht nur auf administrative Methoden beschränken - was einmal passiert ist, kann sehr gut wiederholt werden.
Wohin gehen wir als nächstes?
Prozessoptimierung und Lagerautomatisierung scheinen unmöglich zu sein. Es dauert 5 Jahre in der Firma, und wie ich oben sagte, werden wir auch nach Stufe 9 nicht aufhören. Das Unternehmen expandiert sowohl im B2C- als auch im B2B-Bereich weiter. In naher Zukunft planen wir ein weiteres großes Projekt: Die Eröffnung eines weiteren Lagers erfordert entweder eine umfassende Umschreibung des vorhandenen Systems oder die Erstellung eines ähnlichen Systems von Grund auf an einem neuen Ort. Und dies ist eine neue interessante Herausforderung an der Schnittstelle von Geschäft, physischen Einrichtungen, betrieblichen Prozessen und technischen Lösungen.