لدينا مستودع ، حجم اثنين من المربعات الحمراء وارتفاع 5 طوابق ، مفتوح على مدار السنة ولا ينام أبدا - 24/7 364 يوما في السنة (اليوم الوحيد هو عطلة 1 يناير). لقد قمنا بتخزين وصيانة أكثر من 8،000،000 سلعة ، كل يوم يتغير أكثر من 300 مشغل. إنهم يعملون مع البضائع القادمة من جميع أنحاء العالم ويقومون بجمع الطلبات للمستخدمين من أربع دول: روسيا وأوكرانيا وروسيا البيضاء وكازاخستان. على هذا النطاق ، يتطلب العمل أتمتة لا تشوبها شائبة.
تحت الخفض ، سوف أخبركم باشا فينكلشتاين - قائد فريق تطوير وأتمتة المستودع - بما يمكن أن ينموه الحل المفتوح المصدر إذا قمت بتضمين فريق تطوير جيد ومهمة تجارية محددة للغاية فيه.
المنطق الأساسي
ثلاث عمليات رئيسية لأي مستودع: قبول البضائع وتخزينها وشحنها. تبدو الدورة المبسطة لمستودعاتنا كما يلي: التعريف الأساسي ، ومراقبة الجودة ، والتنسيب ، والاختيار والحجز لطلب ، والبحث ، والفرز ، والتغليف ، ونقل إلى خدمة التوصيل. عندما يعيد العميل المنتج ، تتكرر الدورة. كل كيان مادي مشارك في هذه العمليات له تمثيل إعلامي خاص به ، على سبيل المثال: شاحنة ، منتج ، خلية خزانة ، طرد ، مواد تعبئة ، حاوية ، إلخ. تتم ترجمة جميع الحركات والتغيرات المهمة في حالة البضاعة إلى أنظمة محاسبية ، ويتم تسجيل أي إجراء على الإطلاق داخل البضاعة داخل المستودع.
يتحكم نظام إدارة المستودعات (WMS) في دورة حياة كل منتج في المستودع ، من اللحظة التي تصل فيها الشاحنة مع بضاعة المورد إلى المستودع حتى يتم شحن البضاعة إلى العميل.
تفاصيل أتمتة الموضة
تعمل شركتنا في مجال الموضة ونمط الحياة ، والتي تفرض مهام معينة في المستودع: يمكن أن يكون المنتج هشًا (النظارات والساعات) أو الحجم غير القياسي (أحذية الشتاء أو المجوهرات) أو العلاوة (في عبوات خاصة) - أو يمتلك خصائص محددة أخرى يجب النظر في المستودع. لذلك ، من المستحيل التخلي تمامًا عن استخدام العمل اليدوي في مناطق التخزين.
جميع العمليات الأخرى تلقائية - قبول البضائع ونقلها إلى منطقة الشحن والفرز والتعبئة والتحضير للشحن. كل هذه العمليات تتطلب معدات خاصة وعملية تشغيلية. يحدث السحر عندما تلتصق جميع هذه العمليات مع بعضها البعض وتبدأ في العمل سويًا - بفضل أنظمتنا.
أي رقابة على أتمتة المستودعات - سواء كانت واجهة تساهم في أخطاء المشغل ، أو العملية غير المثلى ، إلخ. - هذا تأخير في الشحن ، تعطل المجمع بأكمله ، خسائر فادحة. بالإضافة إلى ذلك ، مع كل خطأ نقوم بإنشاء تجربة سلبية للعملاء. لذلك ، من المهم بالنسبة لنا أن يعمل المستودع مثل الساعة.
المصدر المفتوح والطريق إلى التنمية الخاصة
في مرحلة الافتتاح ، استخدمنا مستودعًا خارجيًا. مع نمو وحدات التخزين ، بدأنا نفهم أننا نحتاج إلى تحكم كامل في العمليات التشغيلية ومعدل تغير كبير في هذه العمليات ، لذلك قررنا المضي قدمًا نحو مستودعاتنا وتطويرنا.
كان السؤال الرئيسي الذي واجهنا بعد ذلك هو وضع العمليات التشغيلية بكل التفاصيل. حتى أين وكيف يذهب الموظفون ، وعدد عمليات المسح التي يقومون بها ، إلخ. وبالفعل في هذه العمليات ، كان من الضروري نشر WMS ، التي تدير الأنشطة التشغيلية وأتمتة العمليات الروتينية.
للبدء ، اتخذوا حلاً مفتوح المصدر في Java ، ثم قرروا تجميع فريق التطوير الخاص بهم ، خاصة وأن هناك بالفعل أساسًا مناسبًا. لقد قمنا بزيادة وظائفنا ، ثم استحوذنا على جوهر النظام: تخلصنا من الإرث وعميل سمين ، ونفذنا عمليات إعادة بناء وتطوير خدمات جديدة لدعم عمليات التشغيل.
مراحل الأتمتة
تم إجراء التغييرات الرئيسية بواسطة "الأمواج" ، إلى جانب إعادة هيكلة العمليات نفسها.
لقد مر حتى الآن بتسع مراحل من التحديث ، ونحن لا نخطط للتفكير في ذلك.
- في المرحلتين الأولى والثانية ، قمنا بأتمتة عمليات شحن الطلبيات - لقد أضفنا ناقلات ، ومنطقًا لفرز البضائع ، والفرز الآلي للأوامر بواسطة المنصات.
- في المرحلتين الثالثة والرابعة ، ركزنا على عمليات القبول: تعلمنا كيفية فصل تدفقات البضائع الواردة حسب الأنواع المختلفة ومناطق التخزين.
- أضافت المرحلة الخامسة المصاعد الآلية بين الطوابق - هكذا بدأ العمل في منطقة التخزين.
- كانت المرحلة السادسة هي الأكثر أهمية عندما أغلقنا مناطق القبول والشحن ، مع تنفيذ كل الأتمتة.
- في المرحلتين السابعة والثامنة ، قمنا بإجراء تغييرات على العمليات في منطقة القبول وإضافة مناطق جديدة والمصاعد والناقلات: قمنا بتوسيع الأتمتة الحالية.
- في المرحلة التاسعة ، أضافوا مبنىً جديدًا إلى المستودع ودمجوه مع نظام التشغيل الآلي الحالي.
التنفيذ
التقنيات الأساسية لدينا: Java و Postgres و Wildfly و Redis و ActiveMQ.
WMS مكتوب بلغة Java 8. ولكن منذ وقت ليس ببعيد ، تم إصلاح آخر وحدة ، والتي حالت دون الانتقال إلى Java 11 ، وسيتم تحديثها في المستقبل القريب.
رف الخادم المثبت مباشرة في المستودع مخصص لنظام WMS. هذا يعطينا المزيد من الثقة في أن WMS ستعمل حتى إذا كانت الكهرباء و / أو الإنترنت متوقفة. الشيء الوحيد الذي سيعاني هو أن الرسائل إلى نظام المحاسبة سوف تأتي مع تأخير. يستخدم WildFly كخادم تطبيق ، على الرغم من أنه ليس أحدث إصدار حتى الآن. الهجرة إلى الأخير هي أيضا في الخطط. تم بالفعل كتابة كل شيء من أجل هذه الخطوة ، لكن لم نتمكن بعد من إجراء اختبارات وظيفية واختبار الحمل ، وقبل العام الجديد ، كان الحمل مرتفعًا نسبيًا. يستخدم ActiveMQ ثبت أيضا.
البيانات التي نخزنها في PostgreSQL. من الواضح أن الجوهر الرئيسي في نظامنا هو منتج. في بعض الأحيان ، يتوصل موظفو المستودعات إلى حلول لتبسيط عملهم ، على سبيل المثال ، يقومون بمسح نفس الرمز الشريطي 50 مرة ، ويتم طرح المنتج نفسه يدويًا دون مسح ، دون الدخول في التفاصيل ، هذا جينز أو تي شيرت ، لذلك أدخلنا ملصقات تحدد وحدة محددة البضائع ، ودعمها في البنية التحتية. يتم تخزين المعلومات حول هذه الوحدات في قاعدة بيانات PostgreSQL ثنائية تيرابايت.
معظم الأماكن هناك لا تشغلها حتى البضائع ، ولكن عن طريق مراجعة تصرفات عمال المستودعات. نظرًا لكون المستودع نظامًا مهمًا للأعمال ، فيجب عليه معرفة سبب ظهور شيء ما في النظام أو اختفائه - لا يمكننا السماح بإجراء تغييرات غير متتبعة. الآن نفكر في أخذ هذا الجزء من قاعدة البيانات في كيان منفصل في MongoDB.
محطات عمل موظفي المستودعات هي عملاء ويب رقيق. في مكان ما في بداية التشغيل الآلي ، كان كل هذا يعمل وفقًا لمبدأ العميل الكثيف ، مما أدى إلى بعض الصعوبات ، على وجه الخصوص ، مع الإصدارات الكبيرة ، والتي تضمنت تغييرات في الواجهة: تم تحديث حوالي 150 محطة عمل يدويًا. هذا وحقيقة أننا لا نستطيع أن نطلق سراحنا دون أن تحدد أوقات التوقف عن العمل - لا يمكننا نشر أكثر من مرتين في الأسبوع ، في الصباح الباكر ، عندما ينتهي النوبة الليلية ، والتي لا يمكن أن تسمى جدولًا مناسبًا. لقد قمنا الآن بنقل WMS إلى الويب وبحلول نهاية العام ، سنتخلى عن العملاء البدينين تمامًا ، مما سيؤدي إلى تبسيط تغييرات واجهة المستخدم إلى حد كبير. تتم إزالة الويب والتكتلات المضافة في إحدى المراحل من القيود المفروضة على تكرار ووقت الإصدارات - الآن سيتعرف المستخدمون على الإصدارات فقط إذا حدث خطأ ما.
هناك أيضا "غريبة" مثيرة للاهتمام في مستودعاتنا. على سبيل المثال ، تم ذكر Haskell في
Technoradar ، حيث تتم كتابة الواجهة الخلفية لتصور أداة فرز العناصر (هذه هي الآلة التي يمكنها تكوين البضائع من حزمة واحدة معًا وإعطائها لمشغل التجميع). هناك مشكلة حسابية بحتة ، والتي يتم حلها بشكل مريح بأسلوب وظيفي. بطبيعة الحال ، لن يستخدم أي شخص Haskell لأي مشاريع كبيرة الحجم.
عنصر آخر من المستودعات التي ذكرناها في
مقالة حول Technoradar هو آلة
الحالة المكتوبة ذاتيا التي "تراقب" التسلسل الصحيح للإجراءات مع كل منتج. مثل النظام بأكمله ، تم تطويره بشكل متكرر ، بدءًا بمجموعة بسيطة من القيود. الآن أصبح الأمر مناسبًا جدًا ، مدمجًا بعمق في نظامنا. نأمل أن نضعها
مفتوحة المصدر في المستقبل القريب - ربما لن يكون مفيدًا لنا فقط.
معدات التشغيل الآلي
ما الأتمتة دون معدات! المستودع بأكمله متشابك في شبكة كاملة من الناقلات.
يعمل فارز العناصر المذكور أعلاه في مرحلة الشحن ، مما يتيح لك وضع عشرات الآلاف من وحدات البضائع التي تم جمعها من المخزون لأوامر محددة. في وقت واحد ، وفر فارز المشغلين لدينا من الحاجة إلى السفر مع عربة حول المستودع لجمع البضائع اللازمة. يتم تقسيم الطلبات ، ويقوم كل مشغل بجمع البضائع من طابقه فقط (مما يوفر الوقت في الحركة) ، ويضمن الفرز وصول البضائع من الطوابق المختلفة إلى الطلبات الصحيحة تلقائيًا. أدى تغيير العملية التشغيلية بمقدار 4 مرات إلى تسريع عملية تجميع الطلب وتقليل عدد الأخطاء بشكل كبير.
يتم توفير جميع المعدات الآلية من قبل شريكنا. لإدارة وحدات معينة لديهم نظامهم الخاص ، والذي يقع في رف الخادم بجانب WMS لدينا. بين الأنظمة ، يتم تكوين التكامل على بروتوكول رفيع المستوى - نتواصل عبر SOAP. من عملياتنا التشغيلية داخل WMS ، ننتقل إلى نظامهم عندما نحتاج ، على سبيل المثال ، إلى نقل حاوية مع البضائع من النقطة A إلى النقطة B. وهذا هو ، من وجهة نظر نظامنا ، تبدو كل هذه الأتمتة بسيطة للغاية ، على الرغم من تعقيدها الداخلي الحقيقي.
بالطبع ، هذه البساطة الظاهرة لم تنجح على الفور. في المراحل الأولى من التشغيل الآلي ، كان لدينا "طحن متبادل" للتقنيات. بمجرد أن يقوم الناقل بحرق بضائعنا حرفيًا - كانت سرعة حزام النقل عالية جدًا ، فقد "مضغ" البضائع وأحرقها ، مما أدى إلى منع تجميع الطلبات الأخرى. ربما حدث أصعب قصة في بداية التشغيل الآلي ، عندما أطلقنا المرحلة الأولى. بالأمس ، كان المستودع يدويًا بالكامل ، واليوم ، بعد تبديل المفتاح ، يجب أن يصبح تلقائيًا. لكن لم ينجح أي شيء: نظرًا لحدوث خطأ في تكامل النظام ، فُسرت رسائل بعضنا البعض بشكل غير صحيح ، مما أدى إلى عدة أيام من توقف المستودعات وملايين من الخسائر بالنسبة لنا.
الآن الشريك موجود في مستودعاتنا ، يخطط لترتيب المعدات معنا عندما يتعلق الأمر بجولة جديدة من الأتمتة ، يساعد على اختبار كتل جديدة.
فريق و scrumban
يشارك الآن تطوير هذا النظام بأكمله في فريق من 12 شخصًا. في واحدة من المراحل الأخيرة من ذروة التحديث ، عندما تم دمج العمليات الآلية بشكل منفصل في شيء كامل ، شارك ما يصل إلى 20 مطورًا بمفردهم (احتاجت هذه المرحلة إلى 132 شهرًا شخصًا وشملت أكثر من 1500 التزام). ولكن مع انتهاء التحولات واسعة النطاق ، قرر بعض الأشخاص تعلم Go أو Python وانتقلوا إلى فرق التطوير الأخرى.
في الفريق ، لدينا مدراء مشروعين "كلاسيكيين" يجمعون بين وظائف منتج ومشروع من تقنية المعلومات (في المتوسط ، مساء واحد لكل 5-6 أشخاص). تشمل مهامه التواصل مع عملائنا الرئيسيين - مستودع يمثله مديره وقسم تطوير العمليات التشغيلية. من جانبنا ، نحن مهتمون أكثر بالتحديث الفني - اختيار المكدس الصحيح والتحديثات وما إلى ذلك. - ويفكر الرجال من المستودع في تحسين العمليات.
أحيانًا نكرس أنفسنا وقتًا للبحث والتطوير في هذا المجال. بالمعنى الحرفي ، نأتي إلى المستودع ، ونتواصل مع نوبات العمل الرئيسية ، مع المشغلين العاديين ، ونوضح المشكلات التي لديهم ، وما هو مناسب وغير مريح للعمل معهم. بمعنى آخر ، نجري بحثًا عن تجربة المستخدم.
بفضل هذا النهج ، على سبيل المثال ، قمنا بتحويل واجهة مكان العمل للموظف الذي يقوم بقبول البضائع. في البداية ، كانت واجهة معقدة للمؤسسة تحتوي على العديد من الحقول والأزرار والمختصرات بدلاً من التفسيرات النصية. لكننا حاولنا تحسين العملية ، وكذلك التصميم ، مما جعلها أكثر تشابهًا مع صفحة بحث Google الرئيسية - ليست جميلة ، ولكنها عملية للغاية. كلما كانت الواجهة أبسط وخيارات أقل لدى المشغل ، وأين ينقر وماذا يجب مسحه ، تقل الأخطاء (والوقت اللازم لإصلاحها).
والمعرفة المتراكمة حول تحسين التفاصيل تتفوق علينا الآن في أكثر اللحظات غير المتوقعة: بمجرد أن كان فريقنا في المؤسسة وفي لحظة واحدة ، قام جميع المشاركين تقريبًا بفحص تسلسل تصرفات أمين الصندوق. بعد حوالي 40 ثانية ، عبر أحد الزملاء عن الفكرة العامة: "ليس على النحو الأمثل ، يمكنك تبسيطها".
على الرغم من أن العلاقة بين الأدوار في الفريق كلاسيكية تمامًا ، فقد اخترنا أداة مسح للمنهجية التطويرية.
لقد جربنا الكثير مع المنهجيات ، بينما كانت بيانات "الإدخال" غير قياسية. على سبيل المثال ، كان لدينا إصدارات نادرة إلى حد ما. كان التقييد المذكور أعلاه لإصدارين في الأسبوع يعمل من جانب العمليات ، لكن في الواقع قمنا بنشر عدد أقل كثيرًا - في المتوسط مرة واحدة كل أسبوعين. بالإضافة إلى ذلك ، كان لدينا أجهزة أتمتة المستودعات ، التي يتم تطويرها من قبل شركة خارجية لتنظيف الشلال ، حيث يتم جدولة جميع التغييرات قبل عامين مع جميع الوثائق اللازمة. ومع ذلك ، لم نتمكن من اتباع مثالنا: لقد احتجنا إلى إجراء بعض التغييرات على النظام بشكل منتظم ، وإجبار العميل على كتابة مهمة مفصلة لكل منها كان بلا معنى.
سكرومان هو الحل الوسط الذي جعل الجميع سعداء. نستخدم عملية تكرارية ، لكن العدو هو الإصدار بالنسبة لنا. مرة واحدة في الشهر نلتقي مع العميل ونقوم بالتخطيط للإصدار: نناقش ما وننشر الأسبوع. داخل العدو ، يتم تطبيق kanban - مع تراكم المهام والتقدم وما إلى ذلك. صحيح ، هذه العملية تتغير تدريجيا - على سبيل المثال ، ليس لدينا لوحة kanban. فقط عندما ينتهي أحد المطورين من مهمته ، يتم إعطاؤه التالي من المجموعة وفقًا لخطط الإصدار التالي وكفاءات المطور.
نحن نحب هذا النهج. يوفر المرونة اللازمة ضمن التكرارات ، ويمنح العميل التجاري إمكانية التنبؤ بالتواريخ التي سيتم بها تنفيذ بعض الالتزامات. وليس من المهم بالنسبة لنا ما تسمى هذه المنهجية. الشيء الرئيسي هو أن كل شيء يعمل.
ليس مثل أي شخص آخر - استخدام المخزون والرصد كمثال
تطوير العمليات التشغيلية ، بدأنا من احتياجات صناعتنا ، وبالتالي ، لدينا عدد قليل من الميزات الفردية.
مثال جيد هو جرد. وفقًا للقانون ، يجب أن يتم تنفيذه في المستودع مرة واحدة سنويًا ، ولكن متطلبات العمل الخاصة بنا تحدد مراقبة أوثق للمخزون. أولاً ، نريد أن نعكس المعلومات ذات الصلة بشأن توفر البضائع على الموقع ، وثانياً ، يحتاج شركاؤنا B2B ، والعلامات التجارية للأزياء إلى نفس المعلومات ذات الصلة. لذلك ، يتم إجراء جرد يوميًا ، 364 يومًا في السنة ، بعد الجرف في المجمع المكون من 5 طوابق في العديد من المباني. وهذه العملية مدعومة بالكامل من قبل WMS لدينا - سيكون من الصعب تنفيذ مثل هذا الحل.
جرد الآن في عملية التحديث القادم لزيادة كفاءة هذه العملية.
مثال آخر لتطويرنا هو الرصد. يتم تنفيذه من خلال عميل ويب ويسمح لك بعرض وتتبع مقاييس مثيرة للاهتمام للغاية. علاوة على ذلك ، يمثل التمثيل المرئي لهذه المقاييس أهمية بالنسبة لنا. في الواقع ، تمثل المراقبة مستودعًا مبينًا في جدول زمني بسيط ، حيث نرى بوضوح الأماكن التي يعمل فيها كل شيء بشكل جيد وحيث تتم ملاحظة المشكلات (حتى مشغل معين). الأهم من ذلك ، مع هذا الرأي ، يمكننا أن نفهم لماذا تنشأ هذه المشاكل.
عمال المستودعات KPI و Redis
إدخال التقنيات الجديدة والتحديثات وإعادة البناء - كل هذا رائع. لكن نظام WMS الخاص بنا يعمل في أعمال حقيقية ، لذلك علينا حل هذه المشاكل ليس فقط. جزء من عملنا هو الحماية من "المتسللين" الداخليين - العاملين في المستودعات الحيلة الذين يخترعون طرقًا جديدة لأداء KPI لتجاوز المهمة.
على سبيل المثال ، منذ وقت ليس ببعيد ، اضطررنا إلى إضافة Redis إلى المكدس لمنع المستخدمين من تسجيل الدخول إلى النظام من عدة محطات عمل في نفس الوقت وتنفيذ مهلة للجلسة. والحقيقة هي أن عمال المستودعات أدركوا أن العمل تحت نفس تسجيل الدخول والحصول على مكافأة لتجاوز KPI هو أكثر ربحية من زيادة إنتاجيتهم.
نظرًا لأن حل مشكلة الأعمال يتطلب تغييرات في أماكن مختلفة من النظام ، فمن وجهة نظر فنية ، كان هذا يمثل تحديا مثيرا للاهتمام.
المفاجآت من موظفي المستودع لم تنته عند هذا الحد. بعد إطلاق الجلسة تقريبًا ، بدأ PostgreSQL في التعطل. بحثنا عن أسباب التدهور غير المتوقع للقاعدة لعدة أيام ، حتى وجدنا أن الأمر ، مرة أخرى ، كان الحيلة. فتاة واحدة غالبا ما ذهبت إلى التدخين. عندما غادرت مكان العمل ، خرجت من الجلسة ، ولكي تتمكن من تسجيل الدخول مرة أخرى ، كان من الضروري العثور على نوبة كبار ومسح شارتته. بتقليل تجولها حول المستودع ، قامت ببساطة بتمزيق الرمز الشريطي من إحدى العربات وثبّت زر الماسحة الضوئية بالشريط ، مما جعله يمسح الرمز الشريطي باستمرار. وقد يمر هذا دون أن يلاحظه أحد لفترة طويلة إذا لم يكن الباركود من العربة التي تحتوي على 800 وحدة من البضائع. مع كل عملية مسح ، تم إنشاء استعلام SQL ضخم للتحقق من صحة البضائع ، والتي "قتلت" قاعدة البيانات باستخدام "DDoS داخلي". اضطررت إلى الاهتمام بالقيود المفروضة على عدد عمليات الفحص لكل وحدة زمنية وعدد السلع الموجودة في العربة.
هناك بالفعل الكثير من هذه القصص ، ونحن نواجه باستمرار قصصًا جديدة. علاوة على ذلك ، يجب أن يتكيف النظام مع الظروف الجديدة في كل مرة. في مثل هذه الحالات ، لا يمكن للمرء أن يقتصر على الأساليب الإدارية فقط - ما حدث مرة واحدة يمكن تكراره جيدًا.
أين نحن ذاهبون بعد ذلك؟
عملية التحسين وأتمتة المستودعات ، على ما يبدو ، من المستحيل إكمالها. تستمر لمدة 5 سنوات في الشركة ، وكما قلت أعلاه ، حتى بعد المرحلة 9 لن نتوقف. تواصل الشركة التوسع في كل من B2C و B2B ، لذلك في المستقبل القريب نخطط لمشروع كبير آخر - فتح مستودع آخر ، وهذا يتطلب إما إعادة كتابة واسعة النطاق للنظام الحالي ، أو إنشاء نظام مماثل من نقطة الصفر في مكان جديد. وهذا تحد جديد مثير للاهتمام عند تقاطع الأعمال والمرافق المادية والعمليات التشغيلية والحلول التقنية.