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

تصميم الخدمة الحكومية حول المستفيد، لا حول الهيكل التنظيمي
لتصمّم خدمة حكومية حول المستفيد، ابدأ من النتيجة التي يسعى إليها، ثم امشِ رحلته كاملة إلى تلك النتيجة عبر كل إدارة وجهة تشارك فيها، وأعد تصميم نقاط التسليم بينها، لأن الانتظار والتكرار والتخلّي عن الطلب تحدث هناك. بعد ذلك سمِّ شخصاً واحداً مسؤولاً عن الرحلة كلها، وقِسها من أول خطوة يخطوها المستفيد حتى حصوله على النتيجة. أما تغيير الشاشات مع بقاء نقاط التسليم كما هي، فيعطي الرحلة نفسها شكلاً جديداً فقط.
هذه المقالة هي التطبيق الحكومي لمقالة المحور: محورية العميل ممارسة لا شعار: من أين تبدأ.
لماذا تأخذ الخدمة شكل الهيكل التنظيمي؟
لاحظ المبرمج ملفن كونواي (Melvin Conway) عام 1968 أن المنظمات تصمّم أنظمة تشبه طريقة تواصلها الداخلي، وهي ملاحظة تُعرف اليوم بقانون كونواي (Conway's Law). والخدمات الحكومية مثال واضح عليها: كل إدارة تبني الجزء الذي يخصّها، بقواعدها ونموذجها الخاص، فتصل إلى المستفيد رحلة مقسّمة على الإدارات: خطوة عند كل إدارة، ورقم مرجعي جديد عند كل نافذة، والسؤال نفسه يُطرح عليه ثلاث مرات.
لا أحد يقصد هذا. لكن كل إدارة تُقاس على جزئها وحده: إدارة التراخيص تحقق مستهدفها في مدة المعالجة، وإدارة الرقابة تحقق مستهدفها، ومع ذلك ينتظر المستفيد سبعة أسابيع، لأن الانتظار يقع بين الإدارات، حيث لا يُقاس أحد.
وقد صار هذا جزءاً من المعايير الرسمية في دول عدة. ففي المملكة العربية السعودية أُنشئت هيئة الحكومة الرقمية عام 2021 بقرار من مجلس الوزراء، وهي تضع المعايير الفنية للتحول الرقمي الحكومي. وفي بريطانيا يبدأ معيار الخدمة الحكومية (Service Standard) بثلاث نقاط: فهم المستخدمين واحتياجاتهم، وحلّ المشكلة كاملة للمستخدم، وتقديم تجربة مترابطة عبر كل القنوات. راجع المعايير المعتمدة التي تنطبق على جهتك قبل أن تبدأ، واستند إليها، فهي تمنح عملك غطاءً رسمياً.
الخطوة الأولى: سمِّ الخدمة كما يسمّيها المستفيد
المستفيد لا يتعامل مع "الخدمة الإلكترونية لإدارة التراخيص التجارية". هو يفتح مقهى، أو يسجّل مولوداً، أو ينقل والده إلى دار رعاية. سمِّ الخدمة بهذه النتيجة، وسيتّسع نطاقها فوراً ليشمل كل خطوة يجب أن يمرّ بها، ومنها خطوات لا تملكها جهتك.
اكتب جملة واحدة: "يحتاج [المستفيد] إلى [نتيجة] حتى يتمكّن من [ما تتيحه له]". إن ظهر في الجملة اسم إدارة، فأعد كتابتها.
الخطوة الثانية: امشِ الرحلة بنفسك
قبل أن ترسم أي خريطة، عِش التجربة. نفّذ جولة استكشاف الخدمة (Service Safari): قدّم الطلب كما يقدّمه أي مستفيد، عبر القنوات العامة، ودون أي واسطة أو اختصار داخلي. ثم راقب مستفيدين حقيقيين باستخدام أداة الملاحظة في السياق: في مركز الخدمة، وعلى خط الاتصال، وإن أمكن في البيت وهم يعبّئون النموذج.
وتحدّث مع موظفي الصف الأول. موظف مركز الاتصال وموظف النافذة يعرفان بالضبط أين تنكسر الرحلة، لأنهم يسمعون عن ذلك كل يوم، ونادراً ما يسألهم أحد.
سجّل عند كل خطوة ثلاثة أشياء: ماذا يجب أن يُحضر المستفيد، ومع مَن يتعامل، وكم ينتظر دون أن يعرف ما يحدث لطلبه.
الخطوة الثالثة: ارسم الواجهة وما خلفها
ضع الرحلة على جدار واحد. ابدأ بـخريطة التجربة: ماذا يفعل المستفيد، وبماذا يفكّر، وبماذا يشعر، خطوة بخطوة. ثم أضف الطبقة التي تحتها بـمخطط الخدمة (Service Blueprint)، وهي أداة وصفتها لين شوستاك (G. Lynn Shostack) في الثمانينيات: أي إدارة تعمل في كل خطوة، وبأي نظام، وأين تنتقل المعاملة من فريق إلى آخر.
ضع علامة حمراء على كل نقطة تسليم. في أغلب الخدمات الحكومية تفسّر نقاط التسليم التأخير أكثر مما تفسّره أي خطوة بمفردها. وإن لم تكن متأكداً من أي الخريطتين تبدأ، فاقرأ خريطة الرحلة أم مخطط الخدمة؟ متى تستخدم كلاً منهما.
الخطوة الرابعة: ابحث عمّا يُطلب من المستفيد أن يحمله
ابحث عن اللحظات التي يتحوّل فيها المستفيد إلى ساعي بريد بين أجزاء الحكومة: يستخرج شهادة من جهة ليسلّمها لجهة أخرى، أو يُدخل بيانات تملكها الدولة أصلاً، أو يطبع نموذجاً ليمسحه ضوئياً ويرفعه من جديد. كل واحدة من هذه اللحظات قرار تصميمي اتخذته الجهة، غالباً دون أن تنتبه.
اكتبها في قائمة، واسأل عن كل بند: هل تملك الحكومة هذه المعلومة؟ هل يمكن للإدارة المستلِمة أن تحصل عليها مباشرة؟ ما اللائحة أو النظام الذي يمنع ذلك؟ بعض الإجابات تحتاج تعديل لائحة أو اتفاقية تبادل بيانات. اكتبها قرارات مطلوبة من القيادة، ولا تسقطها بصمت.
الخطوة الخامسة: اجعل للرحلة كلها مالكاً واحداً
هذه الخطوة يتجاوزها كثيرون، ولهذا تعود كثير من الخدمات المُعاد تصميمها إلى سابق عهدها. تبقى كل إدارة مسؤولة عن جزئها، لكن لا بد من شخص يملك الرحلة: مدتها من البداية إلى النهاية، ونقاط التسليم، والشكاوى التي تضيع بين الفرق.
ثبّت ذلك كتابياً بمصفوفة المسؤوليات (RACI) للرحلة: مَن ينفّذ كل مرحلة، ومَن يُحاسَب على النتيجة الكلية، ومَن يُستشار قبل أي تغيير. ويحتاج مالك الرحلة إلى مستوى إداري يسمح له بدعوة الإدارات إلى اجتماع وأن يُسمع رأيه. من دون ذلك يبقى التصميم الجديد مجرد توصية.
الخطوة السادسة: اختبر الرحلة الجديدة قبل تغيير الأنظمة
ارسم الرحلة بعد إعادة تصميمها، واختبرها مع مستفيدين حقيقيين وموظفي الصف الأول قبل أن يكتب أحد كراسة متطلبات. تمثيل الأدوار عند النافذة، أو نسخة ورقية من النموذج الجديد، أو موظف واحد يعالج دفعة صغيرة من الطلبات يدوياً وفق الإجراء الجديد، ستكشف لك في أيام ما سيكشفه بناء النظام بعد أشهر. وتفصّل مقالة اختبار التجربة قبل بنائها هذه الاختبارات.
الخطوة السابعة: قِس الرحلة لا الإدارة
أضف إلى مؤشرات الإدارات مؤشرات للرحلة: المدة من أول تواصل حتى النتيجة النهائية، ونسبة الطلبات التي تكتمل من المرة الأولى، وعدد مرات تواصل المستفيد في المعاملة الواحدة، وعدد المستندات التي يُطلب منه تقديمها. ابنها في شجرة مؤشرات الأداء لترى كل إدارة كيف يصبّ مؤشرها في الرحلة. فمؤشر الرضا وحده لن يدلّك على اللحظة التي يجب إصلاحها، وتشرح مقالة الكل يقيس الرضا ولا أحد يصلح اللحظات التي تصنعه السبب.
مثال تطبيقي
مثال توضيحي. أمانة مدينة متوسطة الحجم في المملكة تريد تقليل الشكاوى من تصاريح الفعاليات المجتمعية في الحدائق العامة. داخلياً يتوزّع العمل على أربع جهات: إدارة الحدائق، وإدارة الرخص، وإدارة الصحة العامة، إضافة إلى موافقة الدفاع المدني من خارج الأمانة.
يسمّي الفريق الخدمة "إقامة فعالية لأهل الحي في الحديقة"، ويمشي الرحلة بنفسه، ويرافق خمسة منظّمين حقيقيين. يكشف مخطط الخدمة أربع عشرة خطوة، وثلاثة أرقام مرجعية مختلفة، وموضعين يحمل فيهما المنظّم ورقة من إدارة إلى أخرى. وأطول انتظار يقع بين موافقة إدارة الحدائق وطلب موافقة الدفاع المدني، ولا أحد يملك هذه المسافة.
التصميم الجديد: طلب واحد، ورقم مرجعي واحد، وإرسال طلب الموافقة الخارجية تلقائياً بمجرد موافقة إدارة الحدائق، ومالك رحلة مُسمّى في إدارة الرخص. ويُختبر شهراً كاملاً بأن يتولّى موظف واحد ثلاثين طلباً يدوياً وفق المسار الجديد قبل أي تعديل في الأنظمة. ويصبح سجلّ هذا الموظف هو كراسة المتطلبات لفريق التقنية.
افعل ولا تفعل
افعل
- سمِّ الخدمة بالنتيجة التي يريدها المستفيد، لا باسم الإدارة التي تقدّمها.
- أدخل في الرحلة الخطوات التي تملكها جهات أخرى، حتى لو لم تستطع تغييرها الآن.
- أشرك موظفي الصف الأول في رسم الخريطة، فالأدلة عندهم.
- سجّل عوائق اللوائح وتبادل البيانات قرارات مطلوبة من القيادة.
- عيّن مالكاً للرحلة بصلاحية فعلية عبر الإدارات.
لا تفعل
- لا تبدأ بالبوابة الإلكترونية. نموذج رقمي فوق إجراء مجزّأ ينقل الطابور إلى الشاشة فقط.
- لا ترسم الرحلة من الأدلة الإجرائية وحدها. الإجراءات تصف كيف يُفترض أن تسير الخدمة، لا كيف تسير فعلاً.
- لا تعتبر العمل منتهياً يوم الإطلاق. راجع مؤشرات الرحلة شهرياً في الأشهر الستة الأولى.
- لا تُدِر المشروع من داخل إدارة واحدة ثم تنتظر من الإدارات الأخرى أن تتبنّاه.
أسئلة يطرحها الناس
ما المقصود بالخدمة الحكومية المتمحورة حول المستفيد؟ أن تُصمَّم الخدمة حول النتيجة التي يريد المستفيد الوصول إليها، وحول رحلته كاملة إليها عبر كل إدارة وجهة مشاركة، لا حول الطريقة التي تنتظم بها الجهة داخلياً.
كيف نعيد تصميم خدمة تشترك فيها أكثر من جهة حكومية؟ ارسم الرحلة كاملة، بما فيها الخطوات التي لا تملكها، وحدّد كل نقطة تسليم بين الجهات، ثم اجمع أصحاب هذه النقاط في غرفة واحدة للاتفاق على التغيير. وتعديلات تبادل البيانات واللوائح تحتاج عادة راعياً أعلى من الجهات كلها. وتتناول مقالة ابتكار المنظومة طريقة عمل الجهات على مشكلات مشتركة.
هل نبدأ بأتمتة الخدمة ورقمنتها؟ لا. أصلح الرحلة أولاً، ثم رقمِن النسخة المُصلَحة. رقمنة إجراء مجزّأ تعطي المستفيد عدد الخطوات نفسه، لكن على شاشة.
إلى أين بعد ذلك
ابدأ هذا الأسبوع بـجولة استكشاف الخدمة، ثم ارسم ما وجدته في مخطط الخدمة. وحين تتضح الرحلة الجديدة، ثبّت الملكية بمصفوفة المسؤوليات (RACI)، وحدّد مؤشرات الرحلة بـشجرة مؤشرات الأداء. وإن كنت تؤسس الفريق الذي سيتولى هذا العمل، فابدأ بمقالة بدء الابتكار في جهة حكومية: أول 90 يوماً.