أنظمة إدارة الطلبات – قصتي مع إحداها!

الزمان: شهر مارس من عام 2022 ميلادي.

المكان: مكتب التجارة الإلكترونية بشركة آدم الطبية.

الحدث: جلسة عصف ذهني لتطوير نمط العمل على موقع آدم أون لاين.

قد يبدو لك الأمر بسيطاً لو شرحته لك الآن لكن صدقني الأمر كان كل شيء إلا كونه بسيط – لقد أُوكلت إلي مهمة تطوير موقع ادم اون لاين وقد كانت مهمة صعبة جداً في الحقيقة فأنا وحدي كان يقع على عاتقي إدارة كافة نواحي عمل الموقع – تصميم رحلة المستخدم عليه – تذليل العقبات أمام الشراء – تحسين واجهة المستخدم وتجربة الاستخدام – تحسين العمل على شاشات الجوالات – حل المشكلات البرمجية وقبل ذلك اكتشافها ابتداءاً وتحسين جودة البيانات (الداتا) المدخلة عليه على اختلاف أشكالها وأنواعها سواءاً كانت نصية أو مرئية وأخيراً الخروج بنمط عمل نستطيع أن نبني عليه لنتوسع. كان ذلك كثيراً جداً حتى لهو كثير أن أحكية في منشور واحد ولكني سوف أشارككم اليوم قصتي مع أول نظام إدارة طلبات أو Order Management System تعاملت معه وهو النظام الذي أشرفت على بناءه وصممته بشكل شخصي.

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

خططت كل شيء في كتيب صغير من كتيبات آدم لا زلت أحتفظ به حوالي 69 صفحة من الأفكار في كل صفحة ما بين عشرة إلى اثنتي عشرة فكرة.

دونتها جميعاً بخط يدي ففي وقتها كنت مؤمناً أن التدوين اليدوي سيساعدني للخروج بأفضل أفكار ممكنة.

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

كان اسم ذلك الكتاب باللغة الانجليزية:

.Ethereum: Complete Guide To Understanding Ethereum, Blockchain, Smart Contracts, ICOs, and Decentralized Apps

أعلم أن الاسم طويل ومرهق ولكن صدقني أنا اختصرته عليك أصلاً فهو أطول من ذلك أيضاً.

المهم كنت قد قرأت هذا الكتاب لاهتمامي بتقنية ال Block Chain وفكرة العملات الرقمية بشكل عام إلا أنني خرجت منه مؤمناً إيماناً تاماً بأهمية فكرة اللامركزية في العمليات أو ما يعرف اصطلاحاً بال Operational Decentralization.

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

عندها أدركت بأني لابد أن أربط المنتجات على الموقع بأرصدة حقيقية – ولكن أي أرصدة؟ هل أربطها بأرصدة المستودع وأنتهي من هذا الأمر برمته؟

نعم كانت فكرة لها بريقها – فقد كان المستودع مركزياً وبه معظم الأصناف المطلوبه – ولكن فكرة اللامركزية عادت تراودني بقوة أكثر من الأول.

لم لا نستفيد من توزيع صيدلياتنا الجغرافي؟

ولم لا نستفيد من مناديب الصيدليات الذين يعملون بتوصيل طلبات العملاء عبر الواتس اب في الأون لاين أيضاً؟

ولم لا نستفيد من تنوع المنتجات بتنوع المجتمع الذي تتواجد به الصيدلية؟

ولم لا نستفيد من تواجد صيدلي يشرف على صرف الطلبات والإشراف على الوصفات وبالتبعية العامل الخاص به لتجهيز الطلب بأسرع ما يمكن؟

كان ذلك هو الحلم بالتأكيد ولكنه كان أشبه بحلم صعب المنال.

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

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

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

ولكن أتت هنا نظرة مديري التي أعتبرها أحياناً نظرة عملية وأكثر انتاجية مني – والتي إلم أتعلم منه سواها فتكفي – وهي أنه لا يلزم الوصول للكمال لإتمام العمل – لو وصلنا إلى حل يعطينا 60% فقط من كفاءة المنتج المثالي فهو يكفي للبدء.

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

شرعت في العمل والتصميم والتخطيط – أول شيء أدركته بعد جلسات العصف الذهني تلك أنني بحاجة إلى نظام ما يقوم بتوزيع الطلبات على الفروع وأعطيته اسم داخلي في الشركة وسميته Adam Dispatcher – لم أكن وقتها على دراية فعلية بماهية أنظمة إدارة الطلبات أو ما يعرف اصطلاحاً بال Order Management Systems. ولكن ساقني حدسي إلى أن هذا هو الطريق الصحيح لتطوير العمل – طبعاً عرفت فيما بعد أن ما قمت به ليس جديداً على البشرية وأنه متعارف عليه وبأنه هناك أنظمة أخرى لإدارة عمليات التوصيل وأساطيل السيارات مثل أوتو على سبيل المثال والتي عملنا معها فيما بعد. ولكن ما أنا فخور به حقاً هو تفتق ذهني عن الوصول لمثل هكذا حل دون سابق معرفة لي به أو تدريب لي عليه.

فقد كان Adam Dispatcher بحق هو أول نظام إدارة وتوزيع طلبات احتككت به – وقد كان من تصميمي بالكامل.

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

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

وهو اختصار لاختصار آخر هو SSSP والأخير اختصار لاسم المحرك الفعلي وهو Stocks Status Sync Protocol. 

وهذا ما يبدو عليه أول ملف الشفرة المصدرية لهذا المحرك العظيم:

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

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

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

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

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

وسواء كنت تعمل على هذا النظام أو أنك حالياً عميل لآدم وتستفيد من مثل هكذا نظام فصدقني سوف تسعد بتلك التجربة.

وقد بنيته وراعيت في بنيته الأساسية التطور المستقبلي – فهو نظام راسخ قابل للتعديل في أي وقت بضغطة زر واحدة ليعطي أفضل النتائج الممكنة في مختلف الظروف.

وأنت ما رأيك في اللامركزية وفي أنظمة توزيع الطلبات عموماً؟ يسعدني تلقي تعليقاتكم.