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