تطبيقات لوجستية بـReact Native: دروس من خمسة مشاريع

طوّرت تطبيقات جوال لخمس شركات عميلة من قطاع الخدمات اللوجستية. أربعة منها موجّهة للعملاء: تطبيقات لـBuzmavi وMitlog وCDA Lojistik وAlmark Global Lojistik تسهّل على عملاء هذه الشركات متابعة شحناتهم والتواصل. أما الخامس فداخلي: تطبيق عمليات يتتبّع دخول الشحنات وخروجها بالباركود في مستودع TCT Lojistik. أنا Berke Özyaşar؛ وفي هذا المقال جمعت الدروس العملية التي استخلصتها من هذه المشاريع. إذا كنت تفكر في تطبيق جوال لشركتك اللوجستية، فستجد هنا جزءًا مهمًا مما ينبغي أن تعرفه قبل البدء.

السؤال الأول: لمن التطبيق؟

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

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

لماذا React Native

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

لم يكن اختيار المنصة واحدًا في كل مشروع. فـBuzmavi وMitlog متاحان على App Store وGoogle Play معًا؛ وتطبيقا CDA وAlmark على Google Play. أما تطبيق المستودع فأُعدّ لأجهزة Android المستخدمة في المستودع. وعندما تُكتب قاعدة الشيفرة من البداية لتناسب المنصتين، يصبح إضافة إصدار iOS لاحقًا عملًا أصغر بكثير لا مشروعًا جديدًا.

ما يجب أن يتضمنه تطبيق العملاء

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

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

الجزء الأصعب: الربط بالنظام القائم

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

في مشروع TCT رُبط التطبيق بالبنية القائمة لدى الشركة المبنية على ASP.NET Core وSQL Server؛ وبُني فوق النظام الحالي بدلًا من تغييره. وهذا نهجي العام أيضًا: يجب ألا يتصل تطبيق الجوال بقاعدة البيانات مباشرة، بل بطبقة API تتولى المصادقة ولا تعيد إلا البيانات اللازمة. وبذلك لا يتأثر تطبيق الجوال حتى لو تغيّرت بنية قاعدة البيانات، ويُدار الأمان من نقطة واحدة.

النقاط التي أنتبه إليها في التكامل:

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

تطبيق العمليات عالم آخر

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

عملية النشر في المتاجر: خطط للحساب من البداية

في مشاريع العملاء يجب أن يتضح من البداية باسم من سيُنشر التطبيق. فـBuzmavi وMitlog منشوران على App Store بحسابات المطوّر الخاصة بالشركتين؛ فيظهر التطبيق في المتجر باسم الشركة ويبقى الحساب ملكًا لها. ويتطلب ذلك حساب Apple Developer مؤسسيًا، وقد تستغرق هذه العملية وقتًا أطول من المتوقع بسبب خطوات مثل الحصول على رقم D-U-N-S. وبدء طلب الحساب بالتزامن مع بدء التطوير هو أسهل طريقة لتجنّب تأخير موعد الإطلاق.

هناك بعض المسائل الخاصة بالتطبيقات اللوجستية في مراجعة المتاجر:

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

بعد الإطلاق

لا ينتهي تطبيق الجوال يوم إطلاقه. يُصدر نظاما iOS وAndroid إصدارات جديدة كل عام، ويحدّث Google Play متطلبات SDK المستهدف بانتظام، وReact Native نفسه يتطور بسرعة. والتطبيق الذي لم تُخطَّط صيانته قد يصبح غير قابل للتحديث خلال سنة أو سنتين. لذلك أوصي بإجراء تحديثات منتظمة للإصدارات بعد الإطلاق أيضًا؛ فهذا ضروري للأمان وللتوافق مع المتاجر معًا.

باختصار

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