في الإنتاج

بُنيت في الإنتاج، لا في عرض تقديمي.

كل ما في هذه الصفحة يعمل اليوم، وبحجم حقيقي، داخل عملية دفع عند الاستلام حيّة. المنصّة لم تُصمَّم في المجرّد ثم تُباع — بل بُنيت داخل العمل نفسه، وكل وحدة فيها استحقّت مكانها برفع شيء عن مكتب أحدهم.

الظروف التي بُنيت لها

دفع عند الاستلام بحجم كبير، حيث السؤال الأول عن الطلب ليس هل قُدِّم، بل هل سيُقبَل عند الباب. عدة متاجر خلف مستودع واحد. وكتالوج ينمو كل أسبوع. وفريق يتضاعف في الموسم ويعمل بالعربية والإنجليزية. هذه ظروف قاسية، ولهذا فالمنصّة متينة حيث يهمّ لا عريضة وضحلة.

طلبًا مرّ عبر النظام
0+
مشتريًا يُقيَّم باستمرار
0+
على مخزون واحد موحّد
متعدّد المتاجر
من قاعدة شيفرة واحدة
iOS · Android · ويب

المشكلة

أين تضيع عمليةٌ كهذه يومها.

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

وفي سوق يدفع عند الاستلام، هذا ليس مجرد قلّة كفاءة. جزء معتبر من كل دفعة يعود، وتكلفته حقيقية، والمعلومة اللازمة للتنبؤ بأيّ جزء موجودة أصلًا في البيانات — لكن في مكان لا يستطيع أحد التصرّف منه.

  • عدة متاجر تبيع مستودعًا واحدًا، تُسوّى الفروق يدويًا — غالبًا بعد بيع بضاعة غير متوفرة
  • طلبات دفع عند الاستلام تُرفض عند الباب، دون وسيلة للتنبؤ بأيّها
  • روتين التجهيز اليومي محفوظ كاملًا في رأس شخص واحد
  • أرقام الطلبات يُعاد كتابتها من شاشة إلى جدول إلى رسالة إلى بند مصروف
  • تراكم من الطلبات غير المجهَّزة لا أحد مستعد لحذفه
  • منتجات جديدة تُصوَّر وتُكتب بالكامل يدويًا، كل أسبوع

ما الذي تفعله

ستة أشياء لا يفعلها أي حلّ جاهز.

  1. تقييم قبول، محسوب من سجلّ التسليم

    لكل مشترٍ: نسبة طلباته المستقرّة التي وصلت فعلًا — مع دمج الحسابات المكرّرة التي تعود في الحقيقة إلى شخص واحد خلف رقم هاتف وعنوان. ويُحدَّث لحظة حدوث أي شيء للطلب، وقد عمل باستمرار عبر أكثر من 30,000 طلب و19,000 مشترٍ.

  2. قواعد يكتبها المالك، لا المبرمج

    حين يتحقق هذا، احتجز الطلب وافعل ذاك. تقييم دون حدّ، أو مشترٍ جديد فعلًا، أو قيمة تتجاوز حدًا، أو أربعة طلبات من رقم واحد خلال عشر دقائق، أو اسم هو في الحقيقة رقم هاتف. يُكتب على الشاشة بيد من لاحظ المشكلة، دون انتظار أي شيء.

  3. مخزون واحد موحّد خلف كل متجر

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

  4. الروتين اليومي، كبرنامج

    اطبع الطلبات المعتمدة، وجمّع من قائمة مرتّبة حسب المنتج، وابنِ كشف التسليم لشركة الشحن، واستلم المرتجعات، وأعد المخزون إلى الرف — بترتيب العملية نفسها لا بترتيبنا. وقاعدة الطلب المتقادم تُحيل التراكم المهجور إلى التقاعد بهدوء، دون أن يضطر أحد لحذف شيء.

  5. صور تدخل، صفحات منتجات تخرج

    صور المورّد — غالبًا ما وصل عبر واتساب — تتحوّل إلى معارض مكتملة بأسلوب العلامة ونصوص بصوت المتجر، مصنَّفة ومُنشأة كمسودات في المتجر. سبعة عشر قالب أسلوب، مقاسة من الكتالوج نفسه لا مخمَّنة. والإنفاق محدود شهريًا، والعمل نفسه لا يُدفع عنه مرتين، وشخص يعتمد كل ما يُولَّد.

  6. الفريق كله، والهاتف في جيبه

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

ما الذي تغيّره

ما الذي يتغيّر فعلًا.

الخلاصة الصادقة أن العملية تتوقف عن فقدان المعلومات. الحقائق التي كان يُعاد كتابتها بين أربعة أماكن تُدخَل مرة واحدة، والقرارات التي كانت تعتمد على تذكّر أحدهم تتخذها قواعد كتبها أحدهم.

والتقييم هو الجزء الأوضح فارقًا: الطلب الذي سيُرفض عند الباب يُعلَّم قبل أن يُجمَّع، بدل أن يُكتشف بعد أسبوع حين يعود الطرد.

ما تعلّمناه

ثلاثة أشياء نبنيها الآن على نحو مختلف.

قرّر ما هو إعداد من اليوم الأول، لا في الشهر السادس

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

ابنِ الوحدات المملّة قبل الذكية

الوحدات التي توفّر أكبر قدر من الوقت هي المملّة — المصروفات، والحضور، والروتين اليومي. فالممتع في البناء والثمين في الامتلاك محوران مختلفان، وواحد منهما فقط يخصّ من يدفع. ونحن نرتّب العمل الآن حسب الثاني.

كتابة قاعدة نتيجة التسليم في اليوم الأول

حالة التسليم تُقرأ من المتجر، لا من شركة الشحن أبدًا. هذا القرار وحده يمنع فئة كاملة من الخلاف بين نظامين، وهو الآن الوضع الافتراضي في المنصّة لا شيء يستنتجه كل بناء من جديد.

ما الذي نبيعه فعلًا.

ليست قائمة الميزات. المنصّة مصاغة حول الطريقة التي تحبّ بها العملية أن تُدار أصلًا، وكل قاعدة عمل فيها تُسلَّم إلى المالك بوصفها إعدادًا. هذا هو المنتج — والوحدات ليست إلا الدليل على قدرتنا على بنائه.

هل هذا هو الجزء الذي تحتاجه؟

أسرع طريقة لمعرفة ذلك أن تخبرنا كم يكلّفك هذا الجزء من عملياتك اليوم — من أشخاص ومن أخطاء.

لنبدأ الحديث