زد شب : من 0 إلى +100 ألف شحنة (حول المنتج والتقنية)

English version: Here

في أبريل الماضي، زد شب وصل لـ 100 ألف شحنة مكتملة.
لذلك رأينا أنه حان الوقت المناسب لمشاركة تجربتنا في بناء وإطلاق منتج جديد وفريد من نوعه.

زد شب هو حل للشحن نعمل فيه مع العشرات من شركات الشحن لتوفير مجموعة موحدة من مستويات الشحن والتوصيل بأسعار موحدة، ليكون على التاجر المستخدم لزد شب فقط التعامل مع زد شب، بحيث سيقوم بالتعاقد مع زد شب فقط لكن سيحصل على الخدمات والتغطية لأكثر من 15 شركة توصيل دفعة واحدة. و مايجعل نموذج زد شب فريد من نوعه هو أننا في واجهة إدارة العمليات، فسيختار نظامنا بذكاء شركة الشحن الأنسب ويتولى فريقنا محاسبة التاجر مباشرة بدون الحاجة للرجوع لأي شركة شحن.

في هذه التدوينة سنقوم بسرد قصة زد شب ومسار تحولها من كونها فكرة وخدمة من الجيد العمل عليها خلال السنوات القادمة إلى كونها حاجة علينا إطلاقها خلال أشهر قليلة في زد، وسنناقش فيها كلاً من التحديات المتعلقة بالمنتج والتقنية التي واجهتنا وكان علينا التعامل معها والقرارات التي اتخذناها لتخطيها.

ما الخطأ؟

إلى يناير 2020، كانت السوق اللوجيستية مقسمة بين شركات الشحن الناشئة التي تعاني في تشغيل عملياتها وبين شركات الشحن العريقة والكبيرة التي لم تتكيف مع التجارة الإلكترونية. الإشكال كان بإن الشركات الناشئة لم تتمكن من تقديم جودة خدمة ثابتة ولا تغطية كافية، كما أن الشركات الكبيرة لم تكن تقدم أسعار مناسبة ومنافسة أو حتى إنها لم تكن ترغب بالتعامل مع المتاجر الصغيرة. بالإضافة إلى كل ذلك تسببت جائحة كورونا بالمزيد والمزيد من المشاكل؛ التي أدت إلى عجز الشركات الكبيرة والناشئة من التعامل مع الارتفاع المفاجئ والكبير للطلب والتغييرات المستمرة باللوائح والتنظيمات الصحية. الأمر الذي تسبب بدوره بحدوث موجة عارمة من الإحباط للتجار و لعملائهم النهائيين.

كيف يمكننا أن نطلق المنتج بسرعة؟

نظراً لظروف الجائحة، كنا نعلم بأن علينا أن نطلق المنتج بأسرع وقت ممكن لنحصل على التغذية الراجعة بسرعة ونعيد العمل والتحسين على النموذج الأصلي.

فكان أول تساؤل تقني بديهي طُرح : " هل علينا شراء نظام تقني جاهز أم علينا بناء نظام تقني خاص بنا؟ ". كنا نعلم أن أكثر جزء سيستغرق ويستهلك وقت وجهد في البناء هو الربط مع شركات الشحن؛ كما كنا نخطط للإطلاق مع عشر شركات توصيل على الأقل وهذا يعني أن علينا الربط مع نظام كل شركة على حدة ( يمكنك تخيل مدى الفوضى في المستندات وعدم التناسق في هذه الأنظمة الخارجية ).

لحسن الحظ كان جزء ربط الشركات هذا هو أكثر جزء وجدنا فيه حلول تقنية جاهزة يمكن استخدامها وتحقق ما قد نحتاجه.

في الجانب الأخر؛ بعد أن قمنا بفحص وتقييم الحلول المتاحة، وجدنا أن أغلبهم لا يلبون متطلباتنا التشغيلية مثل إجرائاتنا المحاسبية المختلفة و كذلك كون فريقنا سيكون بالواجهة لإدارة العمليات. على عكس معظم مزودي الحلول المتاحة. كنا نعلم أيضاً أن كثير من هذه المتطلبات ستتغير بعد أن نقوم بضبط النموذج وفي حال الاعتماد على طرف خارجي قد لا يكون النهج الأكثر كفائة من ناحية الوقت والجودة.

لذا، هل علينا أن نقوم ببناء نظامنا الخاص ؟ الإجابة هي نعم ولا. اتفقنا على شراء نظام لربط شركات التوصيل و تشغيله بداخل نظامنا الخاص الذي يقوم بمعالجة جميع الأمور الأخرى من : حساب الأسعار وتوجيه الشحنات وتتبعها وحجز أوقات استلامها.

سمح لنا هذا النهج بإطلاق المنتج بسرعه وبناء فقط ماهو مطلوب ونحتاجه في الوقت الحالي. و كجزء من هدفنا ببناء نظام خفيف الوزن ومستقل؛ قمنا ببنائه بشكل مستقل عن نظام زد الأساسي.

.المسخدمة في زد MySQL و PHP / Laravel على خلاف Postgresql مع Django و Python استخدمنا

وقد سمح لنا ذلك باستخدام مجموعة واسعة من المكتبات والأدوات الناضجة مفتوحة المصدر المتوفرة في منظومة والتي بدورها أدت إلى تسريع تقدمنا بالبناءPython .

التجريب

يقترن عدم اليقين والغموض بشكل متلاصق مع مرحلة إطلاق أي منتج. فمن المستحيل أن تعرف إن كانت افتراضاتك عن السوق وسلوك العملاء صحيحةً تماماً ونؤمن بشدة بهذا المبدأ. لذلك نهجنا هو عدم الاستغراق في الافتراض كثيراً؛ فعليه بدأنا بأبسط الافتراضات لاختبار السوق ومن ثم متابعة البناء عليها. كان الأساس في الخدمة التي سنقدمها هو مفهوم " مستويات الخدمة " حيث قمنا بتقسيم الوجهات حسب سرعة التوصيل (وبالتالي تقسيم شركات الشحن أيضاً). بدأنا بأربع مستويات خدمة، أطلقنا عليها تسميات مباشرة هي مستوى 1 (تسليم في نفس اليوم) و (مستوى 2) تسليم في اليوم التالي) و مستوى 3 (تسليم خلال 3 إلى 5 أيام عمل) و مستوى 4 (تسليم خلال 5 إلى 7 أيام عمل). ولنضمن تقديم الخدمة بجودة ممتازة وثابتة اقتصرنا على إطلاق الخدمة بالبداية للتجار في مدينة واحدة فقط (الرياض). مع العلم أن المستوى الأول لم يكن متاحاً في الأشهر القليلة الأولى (سنشرح هذه النقطة بالتفصيل في القسم التالي)، هذا الإطلاق المحدود سمح لنا بالتركيز أكثر على التحقق من صحة فرضياتنا وتقديم خدمة مناسبة لعملائنا.

بعد أسابيع قليلة من الإطلاق بدأت المشاكل التقنية بالظهور أبرزها بدأ نظام الطرف الخارجي الذي قمنا بشرائه بالتعطل لقيامهم بعمل تغييرات فيه مما أدى لتعطل نظامنا كذلك نظراً لأننا نعتمد عليهم بمعرفة ما إذا كانت مدينة العميل النهائي مخدومة أم لا، وبعد أيام قليلة أيضاً ظهرت عدة مشاكل في طباعة بوليصات الشحن. فبناءً على كل ذلك أدركنا أنه لا يمكن أن نعتمد على أي طرف خارجي في معالجة الخصائص الأساسية وهي استقبال الشحنات و إصدار بوليصات الشحن و لذلك قررنا استبدال وإعادة بناء الأجزاء المستخدمة من نظام الطرف الخارجي بشكل تدريجي. من منظور أنظمة زد الأساسية لم يتغير أي شيء خلال عملية إعادة البناء لأننا كنا نقوم بتشغيله بداخل نظامنا؛ لذلك لم يلاحظ مستخدمين زد شب أي تغيير خلالها باستثناء زيادة الاستقرار لاحقاً.

إطلاق زد شب الآن (مستوى الخدمة 1)

من التصور الأولي لفكرة زد شب كنا نعلم أنه علينا إطلاق خدمة توصيل عند الطلب. لكن لم نقم بإطلاقها كجزء من العرض والإطلاق الأولي لزد شب بسبب اختلافها جوهرياً عن باقي مستويات الخدمة. عمليات التشغيل للتوصيل تتطلب أن يكون كل شيء فورياً، فلا يمكن الانتظار إلى أن يتم جدولة موعد الاستلام أو تجميع واستلام عدد كافي من الطلبات للتوصيل، بالإضافة لعدم معرفتنا الكافية بالعمليات التشغيلية لأتمتتها.

وانطلاقاً من مبدأنا المتمثل باختيار مايتم بناؤه بعناية والاهتمام بكيفية بنائه؛ أطلقنا مستوى الخدمة الآن بنموذج تشغيلي للعمليات شبه يدوي؛ فمبجرد دخول الطلبات لنظامنا تولى فريق العمليات المشترك بين شركة التوصيل التجريبية وفريق زد شب مسؤولية إرسال الطلبات ومتابعتها. أعطانا هذا التشغيل اليدوي نظرة ممتازة حول العمليات والمشكلات التي تحتاج إلى الأتمتة وبناءً على هذه المعرفة قمنا ببناء وأتمتة جميع العمليات وإضافة المزيد من شركات التوصيل للمستوى؛ والنقطة الأهم من ذلك إن هذه التجربة عرفتنا على مستوى الجودة والتوقعات التي ننتظرها من شركات التوصيل لمستوى الخدمة هذا.

إطلاق مستويات خدمة التسليم للفرع

بعد ثلاثة أشهر من الإطلاق اكتشفنا نوع جديد من التجار هم التجار الذين لديهم عدد طلبات قليل أو متوسط بالإضافة إلى حساسية عالية للسعر. هؤلاء التجار ليس لديهم إشكال في تسليم الشحنات لفروع شركات الشحن بدلاً من أن تستلمها شركات الشحن منهم عن طريق مندوبيها. و من ناحية شركة الشحن لديها الاستعداد بأن تقوم بتخفيض كبير بأسعار الشحن لو تم اختصار الرحلة ولم يعد عليها الذهاب للاستلام.

بناءً على شخصية ومتطلبات التاجر هذا قمنا بإطلاق مستويات خدمة التسليم للفرع، مع ثلاث شركات شحن رئيسة في السعودية: سمسا وأرامكس و البريد السعودي (سُبل) مما أدى إلى تقليل التكلفة بشكل كبير وزيادة التغطية للمدن بشكل واسع وسريع. فلم نعد مقيدين بتعقيدات جدولة استلام الشحنات وعوضاً عن ذلك أصبح أينما وجد فرع لأي من شركات الشحن هذه يمكن لزد شب الشحن مباشرة من هناك.

التوسع

التوسع يمكن تقسيمه إلى قسمين : التوسع في العمليات التشغيلية والتوسع التقني.

ويشمل الأول التوسع في تغطية المدن والمناطق مع المحافظة على ثبات جودة الخدمة . كذلك إضافة المزيد من شركات الشحن مع التأكد من تطبيقهم لمعايير التشغيل القياسية. أما الثاني فيشمل دعم التوسع التشغيلي من خلال ربط شركات التوصيل الجديدة والمساعدة في تقييم وتحديد شركات التوصيل الغير ملتزمة بتطبيق المعايير من خلال تحليل سرعة الاستلام والتسليم وغيرها من المقاييس. التوسع التقني هنا يتضمن المفهوم الشائع للتوسع وهو الحفاظ على النظام قائماً مع نمو البيانات والاستخدام.

لتوسيع عمليات ربط شركات الشحن قمنا في نظامنا ببناء نموذج ربط متعدد الأشكال، بحيث لا يدرك الكود البرمجي الأساسي الخصائص المحددة لشركة شحن. فكل ماعليه أن يعرفه؛ على سبيل المثال

أن شركة شحن معينة في استدعاء

create_shipment

ستقوم بإرجاع رقم تتبع للشحنة مثل :

class CourierX(Driver):
    def create_shipment(
        self,
        consignor,
        consignee,
        reference_number,
        weight,
    ) -> str:
    	pass

def assign_shipment(
  shipment: Shipment,
  courier: Driver,
):
	tracking_number = courier.create_shipment(
    shipment.merchant,
    shipment.customer,
    shipment.reference_number,
    shipment.weight,
  )
  ...

ومن خلال هذه الطريقة يمكن إخفاء الكثير من التعقيد والاختلافات في عمليات الربط والتكامل وتقديم واجهة موحدة. فقد رأينا الكثير من الجنون في الواجهات البرمجية لأنظمة شركات الشحن؛ سواء كانت واجهات قديمة أو غير متناسقة أو كلاهما. ومن الأمثلة عليها: كان لدى واحد من شركات الشحن أكثر من 30 قيمة يجب إرسالها مع العلم أنه فقط عشرة منهم التي لها احتياج فعلي والباقي قيم ثابتة لايتم استخدامها أبداً ولكن يجب أن نرسلها دائماً مع كل طلب. والبعض الآخر من شركات الشحن فكان التحقق من المدخلات لديهم سيء جداً فعندما يتم إرسال طلب غير صحيح ستحصل على خطاً خادم داخلي بدلاً من طلب غير صحيح مع رسائل خطأ توضح الخلل في المدخلات.

أحد الطرق التي نتبعها لضمان الاستقرار مع التوسع هي دفع شركات الشحن التي تعمل معنا لاعتماد وتطبيق معايير التشغيل القياسية الخاصة بنا كإجراء وتنظيم أساسي والتوصية باستخدام نظام جاهز لإدارة عملياتهم بدلاً من تطوير نظام بأنفسهم؛ وهذه النقطة الأخيرة مهمة لأنهم لو قاموا ببناء نظام وتطويره بأنفسهم فهذا يعني أن علينا الربط مع نظامهم الخاص والتحقق وتصحيح الأخطاء الخاصة بهم على حدة وهذا يعني تأخير إطلاقهم معنا.

أما اذا استخدموا نظاماً جاهزاً فلن يضطروا لإعادة اختراع العجلة ومعرفة كيفية ضبط وتكييف عملياتهم المتغيرة باستمرار وفقاً للمتطلبات التقنية وإصلاح المشكلات المتعلقة بواجهة برمجة التطبيقات وغير ذلك من المشاكل.

أخيراً من خلال المزج بين هذه الممارسات قمنا بربط أكثر من 15 شركة شحن بشكل مباشر مع نظامنا والتخلص من نظام الطرف الخارجي خلال شهرين عمل.

ماذا بعد؟ المئة ألف الثانية ومابعدها

نؤمن أن هذا كله مجرد غيض من فيض لما يمكن أن يحققه نموذج زد شب ونعمل حالياً على التوسع في عمليات التشغيل لمستويات الخدمة لتغطي لنقاط استلام جديدة وكذلك التوصيل لنقاط جديدة بما ذلك الدولية.

في وقت نشر هذه التدوينة (أغسطس 2021) زد شب عالجت أكثر من 200 ألف شحنة. سنستمر في الاستثمار في تحسين تجربة الميل الأول (الاستلام) للتجار وشركات الشحن؛ و منها تحسين خوارزميتنا المعنية بالإسناد للشحنات بشكل يقلل من عدد الرحلات اللازمة لشركات الشحن لاستلامها. بالإضافة إلى أننا سنعمل على زيادة مساحة التغطية للاستلام في الميل الأول لنمكن المزيد من التجار من الحصول على تجربة زد شب الكاملة.