التحول الرقمي مسألة تصميم خدمة، لا مسألة تقنية

يتعثر التحول الرقمي حين يُدار كبرنامج تقني: نختار منصة، وننقل النماذج إلى الإنترنت، ونعدّ الأنظمة التي أُطلقت. ويبقى العميل أمام التحويلات نفسها، والمستندات نفسها، والانتظار نفسه، لكن على شاشة هذه المرة. البديل أن تتعامل معه كمسألة تصميم خدمة (Service Design): أعد تصميم ما يريد الشخص إنجازه من أوله إلى آخره، بواجهته وكواليسه، ثم قرر ما الذي تحتاج التقنية أن تفعله.

الاعتقاد كما يقوله أصحابه

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

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

فالميل إلى البدء بالتقنية مفهوم. المشكلة فيما يتركه خارج الصورة.

لماذا يسقط في الممارسة

يرقمن الإجراء لا النتيجة

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

الخدمة تعبر الإدارات، والبرنامج لا يعبرها

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

لاحظ ملفن كونواي (Melvin Conway) عام 1968 أن المؤسسات تميل إلى إنتاج تصاميم تعكس بنية التواصل داخلها. والخدمات الرقمية تثبت ملاحظته كل يوم: إن كانت ثلاث إدارات لا تتحدث مع بعضها، فستجد في البوابة ثلاثة أقسام لا يتحدث بعضها مع بعض أيضاً.

لا أحد يصمم الكواليس

ما يراه العميل على الشاشة هو الواجهة. ووراءها الموظفون والسياسات والموافقات والأنظمة التي تصنع النتيجة فعلاً. وصفت لين شوستاك (G. Lynn Shostack) مخطط الخدمة (Service Blueprint) أول مرة عام 1982، ثم عرضته على جمهور أوسع في مقال نشرته هارفارد بزنس ريفيو عام 1984 لتجعل هذا الجزء الخفي مرئياً. ومعظم برامج التحول تصمم الواجهة بعناية وتترك الكواليس كما هي، فتكون النتيجة تطبيقاً أنيقاً فوق إجراء ما زال يحتاج توقيع مدير على ورقة.

يُقاس النجاح بالإطلاق لا بالتغيير

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

ما الذي ينجح بدلاً من ذلك

اجعل الخدمة، لا النظام، وحدة التحول. وهذا يعني عملياً خمس عادات:

1. سمِّ النتيجة التي يريدها الشخص. ليس "تقديم طلب" بل "أن أفتح محلي". اكتبها بلغة العميل. هذا يرسم حدود العمل، وغالباً ما تكون أوسع من إدارة واحدة.
2. ارسم الخدمة كاملة كما تعمل اليوم. استخدم خريطة التجربة لترى الخدمة من جهة العميل، ثم مخطط الخدمة لترى الكواليس: من يلمس المعاملة، وماذا يتحقق منه، وعلى ماذا ينتظر. امشِ في الخدمة بنفسك، ولا ترسمها من دليل الإجراءات.
3. اسأل عن كل خطوة قبل أن ترقمنها. لكل مستند وموافقة وحقل: لماذا هو هنا؟ من يستخدمه؟ ماذا يحدث لو حذفناه؟ تعديل السياسة والإجراء هو عادة أرخص تحسين وأكبره، ولا يحتاج سطراً من البرمجة.
4. اختبر الخدمة الجديدة قبل أن تبني النظام. شغّل الرحلة المعاد تصميمها يدوياً لأسابيع مع مجموعة صغيرة، وهذا اختبار الكونسيرج، أو ضع واجهة بسيطة فوق موظفين ينجزون العمل يدوياً في الخلف، وهذا اختبار ساحر أوز. ستعرف ما الذي تحتاج التقنية أن تفعله فعلاً، وهو غالباً أقل مما في كراسة المواصفات.
5. اجعل للخدمة مالكاً واحداً. عيّن مالكاً للخدمة له صلاحية تعبر الإدارات المعنية، وقِس الخدمة بما يحصل عليه العميل: الوقت حتى النتيجة، وعدد الخطوات، ومرات التواصل المتكرر، ونسبة الانسحاب.

عندها تعود التقنية إلى مكانها الصحيح: وسيلة لتقديم الخدمة المعاد تصميمها على نطاق واسع، لا إعادة التصميم نفسها.

مثال

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

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

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

افعل ولا تفعل

افعل

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

لا تفعل

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

أسئلة يطرحها الناس

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

هل ما زلنا نحتاج خارطة طريق تقنية؟ نعم، لكنها تأتي بعد إعادة تصميم الخدمة لا قبلها. حين تعرف كيف يجب أن تعمل الخدمة، تصف الخارطة ما يجب أن تفعله الأنظمة لدعمها. وكثير من الجهات تكتشف أن القائمة صارت أقصر.

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

إلى أين بعد ذلك

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