تجربة المستخدم للمؤسسات: كيف تطور الأنظمة القديمة دون الإضرار بمسار العمل
تحديث استراتيجيات تجربة المستخدم
تحديث الأنظمة القديمة، تجربة المستخدم للمنشآت، إعادة تصميم البرمجيات القديمة، تحديث تجربة المستخدم، التحول الرقمي للشركات، تجربة المستخدم للتطبيقات القديمة، التحول الرقمي للشركات السعودية
لماذا تفشل مشاريع تجربة المستخدم (UX) في المؤسسات الكبرى؟
السيناريو يتكرر دائماً وبشكل محبط؛ نظام صُمم عام 2011 ليخدم 200 مستخدم، واليوم يخدم 2000 مستخدم. توافق الإدارة على مشروع "تحديث" يُعرّف تقنياً بأنه إعادة كتابة الشيفرة البرمجية مع لمسة تجديد للتصميم الخارجي. في هذه الأثناء، لا أحد يكلف نفسه عناء التحدث مع فريق مركز الاتصال الذي يحفظ إحدى عشرة طريقة بديلة لتسيير العمل. يُطلق النظام الجديد، فتتعطل تلك الحلول البديلة، وتتراجع الإنتاجية بشكل حاد. وخلال ستة أشهر، يجد العمل نفسه أمام نظامين: النظام الرسمي الجديد، والنظام القديم غير الرسمي الذي يعمل في الخفاء عبر ملفات إكسل مفرغة.
الفشل هنا ليس في المظهر البصري أبداً، بل في افتراض أن العملية الموثقة على الورق هي ذاتها العملية الحقيقية التي تحدث على أرض الواقع.
من أين أبدأ عملية تحديث الأنظمة القديمة؟
ابدأ بالملاحظة والتعايش لا بالتخطيط المسبق. اجلس مع الأشخاص الذين يستخدمون النظام يومياً ليوم كامل قبل البدء بأي أعمال تصميم. راقب حلولهم البديلة: ملفات إكسل الخاصة، الملاحظات اللاصقة على الشاشات، والمعلومات المتوارثة من قبيل "يجب أن تنقر هنا مرتين ليعمل النظام". كل حل بديل يبتكره الموظف هو في الحقيقة وثيقة متطلبات واحتياجات أغفل المشروع الأصلي جمعها. هذه المرحلة من العمل الميداني تستغرق من أسبوع إلى أسبوعين، وغالباً ما تغير نطاق العمل بأكمله لاحقاً.
ما هي استراتيجية الانتقال الأكثر أماناً؟
نعتمد أسلوب "الخنق التدريجي" (Strangler pattern) مطبقاً على تجربة المستخدم: صمم الواجهة الجديدة حول مسار عمل واحد فقط، ودعها تعمل جنباً إلى جنب مع النظام القديم، واترك للمستخدمين حرية الانتقال عندما يلمسون بأنفسهم أن الطريقة الجديدة أسرع بالفعل. ثم انتقل إلى مسار العمل التالي. المستخدم الذي ينتقل باختياره يتحول إلى مدافع عن النظام الجديد، أما من يُجبر بقرار إداري فسيتحول إلى معرقل له، وبأسباب وجيهة جداً.
قد يبدو التشغيل المتوازي مكلفاً في البداية، لكن البديل - وهو الانتقال المفاجئ والصارم - سيكلفك أكثر بكثير؛ حيث تظهر التكاليف الخفية في الربع السنوي التالي للإطلاق على شكل دورات إعادة تدريب، وأخطاء فادحة، وحلول بديلة صامتة.
كيف أقيس مدى نجاح عملية التحديث؟
من خلال ثلاثة معايير أساسية تُقاس قبل إجراء أي تغيير لتحديد خط الأساس: الوقت المستغرق لإنجاز المهام في أكثر خمسة مسارات عمل تكراراً، معدل الخطأ في كل مسار عمل، ووقت تدريب الموظف الجديد. أي تحديث لا يحسن هذه الأرقام هو مجرد ديكور مكلف. لقد رأينا مشاريع لإعادة تصميم مسارات العمل في مؤسسات كبرى قلصت وقت إنجاز المهام بمقدار الثلث، ببساطة عن طريق إزالة حقول لا يستخدمها أحد وخيارات افتراضية لا يفهمها أحد. وهذه النجاحات لا قيمة لها إن لم تقم بقياس الوضع السابق أولاً.
كيف أقنع المستخدمين المقاومين للتغيير بتبني النظام الجديد؟
في الواقع، لن تحتاج إلى إقناعهم إن أشركتهم منذ البداية. المستخدمون الأكثر مهارة وتمرساً على النظام القديم هم الفئة الأكثر تشكيلاً للخطورة على المشروع، وهم في الوقت ذاته المختبرون الأكثر قيمة لك؛ لأنهم يعرفون خفايا النظام وعيوبه بدقة. أشرك ثلاثة منهم في عملية التصميم كمستشارين مدفوعي الأجر. عندما ينجح النظام الجديد في تلبية أصعب مسارات العمل لديهم، سيتحولون إلى أكبر المدافعين عنه. وإن فشل، فستكتشف ذلك قبل الإطلاق الرسمي، وهذا هو المطلوب تماماً.
إن رسائل إدارة التغيير ليست بأهمية هذه القاعدة الذهبية: لا تلغِ ميزة أو وظيفة أبداً دون أن تحدد وتسمي بديلها. المستخدمون يتقبلون الجديد دائماً، لكنهم لا يغفرون أبداً فقدان الميزات التي اعتادوا عليها.
ما علاقة إمكانية الوصول (Accessibility) بالأنظمة القديمة؟
العلاقة وثيقة جداً وحتمية مع مرور الوقت. تشهد مشاريع التحديث الحكومي والمؤسسي في منطقة الخليج العربي تركيزاً متزايداً على متطلبات معايير WCAG 2.2 كشرط أساسي في وثائق المشتريات والمعايير الرقمية الوطنية. بناء إمكانية الوصول ضمن مرحلة إعادة التصميم يكلف جزءاً بسيطاً مقارنة بتعديلها لاحقاً تحت ضغط العقود. نتعامل في خدمة التحديث لدينا مع هذا الأمر كمعيار افتراضي أساسي، وليس كمرحلة ثانوية.
كم تستغرق عملية التحديث؟
بكل صراحة: يوضع أول مسار عمل محسّن بين أيدي المستخدمين خلال شهرين إلى ثلاثة أشهر، ويتم الانتقال الكامل خلال فترة تتراوح بين ستة إلى ثمانية عشر شهراً بناءً على حجم النظام. أي عرض يعدك باستبدال نظام مؤسسي كامل خلال ثمانية أسابيع يقدم لك عرضاً تجريبياً (Demo) لا عملية انتقال حقيقية.
ابدأ بمسار عمل واحد
إذا كنت تدير نظاماً قديماً يتحمله موظفوك بدلاً من أن يستخدموه بحب، فإن المدخل للتغيير يكمن في اختيار مسار العمل الأكثر صعوبة وإزعاجاً لهم، ودعنا نحدثه لك بالشكل الصحيح. تواصل معنا لتنفيذ مشروع تجريبي محدد النطاق: دراسة ميدانية مع مستخدميك الحقيقيين، مسار عمل معاد تصميمه بالكامل، ومقاس بدقة مقارنة بالنظام القديم. إن لم يثبت المشروع التجريبي جدواه، فستكون قد وفرت على نفسك الكثير من التكاليف.
نموذج مجاني لتدقيق تجربة المستخدم (UX)
تدقيقك القادم لتجربة المستخدم، جاهز ومنظم
حمل نفس النموذج الذي أستخدمه مع عملائي لتدقيق تجربة المستخدم: قائمة مراجعة استكشافية، تقييم مدى خطورة المشكلات، وهيكل تقرير جاهز للمشاركة فوراً.
