بناء تطبيق لطلبات صيانة الأجهزة

عالج ضياع القرار لا شكل بطاقة الطلب

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

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

افصل الجهاز عن طلب إصلاحه

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

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

اربط الموافقة بنسخة محددة من التشخيص والعرض

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

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

صمم المسار الذي يتوقف ولا ينجح فقط

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

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

أظهر لكل شخص ما يحتاجه فقط

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

رقم الطلب وسيلة مرجعية، لا دليلًا كافيًا وحده للسماح برؤية بيانات صاحبه. اختبر الوصول من حساب مختلف. ولأخطاء النموذج، اكتب «أدخل نوع الجهاز» بجانب الحقل، وأبقِ المعلومات الصحيحة؛ إرشادات W3C تدعم رسالة خطأ محددة مرتبطة بالحقل وإرشادًا للتصحيح.

جرّب النسخة الأولى بوصف واضح

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

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

الوصف القابل للنسخ

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

قائمة الفحص

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

أسئلة شائعة

المصادر

• OWASP — Authorization Cheat Sheet — فحص إذن قراءة وتعديل الموارد (تاريخ التحقق: 2026-09-20)
• W3C WAI — User Notification — ربط خطأ النموذج بالحقل وإيضاح تصحيحه (تاريخ التحقق: 2026-09-20)