كان لدى البنك رحلة استحواذ رقمية قائمة في الإمارات، وأراد الرحلة نفسها في مصر. تراجعت الإدارة عن ذلك مبكرًا (مصر تحتاج شيئًا مبنيًا لمصر)، واستُعين بي لتنفيذه.
ما بدأ كقرار لغوي اتضح أنه قرار معماري. الرحلة الإماراتية تُغلق التحقق من الهوية داخل التطبيق: بطاقة هوية بشريحة NFC، وUAE Pass، وliveness check، وتعرّف اتحادي على الوجه، ورخص تجارية يمكن التحقق منها مقابل سجل حي.
مصر لا تملك أيًّا من ذلك. لا توجد واجهة تحقق متاحة للبنوك على الرقم القومي، ولا يمكن التحقق من السجل التجاري إلكترونيًا، والبنك المركزي يشترط معاينة المستندات الأصلية شخصيًا وتوقيع كل شريك مؤهَّل بخط اليد.
لذلك لم يكن ممكنًا أن تنتهي الرحلة حيث تنتهي الرحلة الإماراتية. ترجمة الشاشات كانت ستنتج نموذجًا يجمع البيانات ثم يتوقف.
صمّمتُ ستة أنظمة مترابطة تحمل الطلب إلى أبعد نقطة يسمح بها الرقمي، ثم تسلّمه إلى إنسان عن قصد، وكل مستند مُلتقط، وكل فحص مُنفَّذ، ولا شيء يحتاج إعادة إدخال.
4 الفصل
دوري
المصمم الوحيد. صمّمت الأنظمة الستة كلها من الصفر: رحلة العميل، ونظام مراجعة الطلبات داخل البنك (Application Workflow)، وبوابة العميل (Customer Portal)، والتحقق النهائي (Fulfilment) ونموذج فتح الحساب (AOF)، وطبقة الإشعارات.
قدتُ ورشة رسم الرحلة التي حدّدت ما يحدث فعليًا حين تفتح شركة حسابًا في مصر. واقترحتُ نموذج الخدمة الذي ينتقل فيه موظف البنك إلى العميل بجهاز لوحي بدلًا من انتقال العميل إلى الفرع. واقترحتُ بوابة العميل كنظام قائم بذاته، وصمّمتُ المعمار الذي يربط الأنظمة الستة.
عملتُ مع Product Owner، وProxy Product Owner، وProduct Manager، ومع فرق الـ Compliance والـ Governance وفتح الحسابات والمعمار التقني. فريق الهندسة وأصحاب القرار كانوا معي في دبي؛ وفريق الأعمال المصري وProduct Owner وفريق تجربة العملاء (CX) في القاهرة.
في فرع مصري، يبدو فتح حساب لشركة هكذا: يخسر العميل يومًا. يأخذ رقمًا، وينتظر، ثم يصل إلى الموظف ويقول إنه يريد فتح حساب. يطلب الموظف السجل التجاري والبطاقة الضريبية — وغالبًا يكون العميل قد أحضر الأوراق الخطأ، فيعود في يوم آخر. ثم يمر الموظف على نشاط الشركة، وشركائها، ومورديها ومستورديها، وحجم التعاملات السنوي المتوقع. ثم يأتي القسم التنظيمي: FATCA، والعقوبات، والأشخاص المعرّضون سياسيًا (PEP).
وهنا الجزء الأهم.
يطرح الموظف تلك الأسئلة التنظيمية شفاهةً، بعربية بسيطة، ويجيب عنها نيابةً عن العميل. هل تتعامل مع هذه الدول؟ هل لديك أقارب في السياسة؟ هل تحمل إقامة أمريكية أو تدفع ضرائب لأمريكا؟ يقول العميل لا، لا، لا. يملأ الموظف النموذج. يوقّع العميل — غالبًا دون أن يقرأ.
وإذا كان للشركة شركاء متعددون، فإما أن يحضروا جميعًا إلى الفرع بمستنداتهم الأصلية للتوقيع بخط اليد، وإما أن ينتقل مدير العلاقة إلى مقر الشركة. وفي الحالتين، يوم آخر. ثم يراجع فريق الـ Governance كل شيء، ويُدخله يدويًا في Flex، نظام البنوك الأساسي. كل حقل كُتب بالحبر يُكتب مرة ثانية بيد إنسان.
من أسبوعين إلى شهر، وأحيانًا أطول.
الرحلة الرقمية تُزيل الموظف. وهذه هي مشكلة التصميم بأكملها — وهي ليست توفيرًا. كان الموظف يؤدي عملًا غير مرئي: يفسّر، ويحكم على ما هو مطلوب، ويضمن أن يخرج النموذج مكتملًا. وكل مشكلة واجهتها في هذه الرحلة تعود إلى ذلك الغائب.
القرار
معركة اللغة
ما اقترحته أولًا: العربية أولًا. إذا كنّا نبني لمصر لا نترجم لها، فيجب أن تكون العربية هي المرجع، والإنجليزية هي المشتقة.
رُفض. ليس لدليل، بل لأسباب تتعلق بمن يعتمد التصميم. كان أصحاب القرار في دبي وغير مصريين، ولم يكونوا قادرين على قراءة ما يُطلب منهم اعتماده. لا نفهم العربية. ابنوها بالإنجليزية، نعتمدها، والعربية في المرحلة الثانية.
ما اقترحته ثانيًا: تبديل اللغة في أي موضع داخل الرحلة. إذا لم تكن العربية هي الأصل، فليكن للعميل أن يمد يده إليها في أي لحظة.
رُفض أيضًا، وهذه المرة كان الاعتراض حقيقيًا. إجابات الحقول الحرة كان لا بد من مطابقتها عبر لغتين — عميل يجيب بالعربية والنظام يتوقع الإنجليزية. تطوير مفرط مقابل عائد محدود، وكان المعماريون محقين.
إلى أين ذهبت بدلًا من ذلك. توقفت عن المطالبة بالرحلة كلها، وبحثت عن الموضع الوحيد الذي لا ينطبق عليه الاعتراض التقني.
وهو لا ينطبق على القسم التنظيمي. إجابات FATCA مطلوبة بالإنجليزية مهما كانت لغة الواجهة — فالنموذج يذهب إلى جهة أجنبية، بكلمات العميل نفسه لا بترجمة. وأغلب القسم نعم/لا، وهو يُترجم دون لبس. أي أنه في الخطوة التي يحمل فيها الفهم أثرًا قانونيًا بالضبط، لم تكن هناك مشكلة مطابقة أصلًا.
قدمتُ حجتين في الغرفة. الأولى معرفة بالسوق: المصريون الذين يديرون أعمالهم بالإنجليزية يعودون إلى العربية عند ماكينة الصراف وعند شباك البنك — اللحظات التي يكون فيها المال والأثر القانوني على المحك. والثانية أعادت صياغة السؤال بالكامل. هذا ليس تفضيلًا لغويًا. هذا قابلية وصول واستخدام وموافقة مستنيرة — من حق العميل أن يقرأ، بلغته، ما هو مقبل على التوقيع عليه. في الفرع كان إنسان يوفر ذلك. إزالة الإنسان لا تُزيل الالتزام.
تلك الحجة كسبت. يستطيع العميل التبديل بين العربية والإنجليزية داخل القسم التنظيمي دون أن يفقد موضعه — وفي الاتجاهين، وهذا يهم للمقيم الأجنبي الذي يتعامل بالعربية اليومية لكنه يريد أسئلة العقوبات بالإنجليزية.
ثم وافقني الاختبار. نصف المشاركين بدأوا بالإنجليزية، وتحوّل جلهم إلى العربية عند تلك الخطوة تحديدًا. وأُبلغت بالسلوك نفسه بعد الإطلاق المحدود.
وخسرتُ العربية أولًا نهائيًا — وأظن اليوم أن ذلك كان صوابًا. ما صدر هو اختيار لغة في الشاشة الأولى يسري على الطلب كله. وهو يحاكي ما يحدث فعلًا في الفرع: تدخل فتطلب من يتحدث العربية، أو من يتحدث الإنجليزية. وبوابة العميل هي الاستثناء، عن قصد — فهي محادثة مفتوحة لا نموذج مُهيكل، فأي اللغتين تعمل، وموظفو البنك يتعاملون مع الاثنتين.
النتيجة · طلب كان يستغرق من أسبوعين إلى شهر أصبح يُقدّم في نحو خمس عشرة دقيقة — مقيسة عبر عشر جلسات اختبار.
والأهم: البيانات التي يُدخلها العميل هي البيانات التي تصل إلى Flex. لا أحد يعيد كتابتها. وهذه الخاصية وحدها هي ما يحوّل التفعيل من طابور إلى مستوى خدمة.
هذه هي الرحلة التي لا تعرضها أغلب ملفات الأعمال، لأن أحدًا خارج البنك لا يراها.
في النظام الورقي، كان الطلب يصل في صورة ملف. يقرأه فريق الـ Governance ويفحصه، ثم يُدخل بياناته يدويًا في نظام Flex. أما فحص الأسماء (eName screening) فكان يجري في نظام منفصل تمامًا يُخرج تقريرًا بصيغة PDF. والتفويضات (Mandates) كانت تُبنى في نظام ثالث.
وأي شيء غير واضح — مستند غير مقروء، أو صفحة ناقصة، أو سؤال عن أحد الشركاء — كان يخرج من العملية كلها ويتحول إلى مكالمة هاتفية أو رسالة بريد إلى مدير العلاقة.
بمعنى آخر: كان العمل موزعًا على ثلاثة أنظمة، ومعه محادثة لا تُسجَّل في أي مكان. وكل انتقال بين نظام وآخر كان فرصة لضياع الوقت دون أن يُكتب شيء يوضح أين ذهب.
الأدوار: الوحدة المسؤولة اسمها Account Opening Unit، وبداخلها دوران. الأول Governance، ويراجع الطلب ومستنداته وتفويضاته ويتخذ القرار النهائي. والثاني Compliance، ويعمل على نتائج فحص الأسماء.
والأهم أن من يُدخل البيانات ويقيّمها (الـ maker) ليس هو من يوافق عليها (الـ checker) — شخصان مختلفان. وهذا الفصل تحديدًا هو ما سمح لبقية التصميم أن يكون بهذه السرعة، كما سيتضح لاحقًا.
القرار
ضمّ الأنظمة المنفصلة إلى الداخل
نظامان انتقلا إلى داخل نظام مراجعة الطلبات بدل أن يبقيا بجواره: فحص الأسماء، وإنشاء التفويضات.
والغرض من الدمج ليس تقليل عدد الأنظمة في حد ذاته، بل أن الموظف لم يعد يضطر إلى مغادرة الشاشة التي يعمل عليها. صار التقييم والدليل والقرار في مكان واحد، فاختفت الرحلات المتكررة بين الأنظمة التي كانت تلتهم وقت الإنجاز.
أما أنظمة البنك الأخرى — كالتحقيق الأعمق في شبهات الاحتيال، أو التحقق من مسألة امتثال معينة — فقد بقيت خارجًا عن قصد، لأنها ليست جزءًا من المسار الطبيعي لأي طلب، بل استثناء يحدث أحيانًا.
القرار
جعل الاستثناء (Exception) كيانًا له دورة حياة
هذا هو القرار الذي أعتز به أكثر من غيره في هذا الفصل.
في النظام الورقي، كان الاستفسار مجرد مقاطعة: يتصل الموظف ويسأل، ثم ينتهي الأمر دون أثر.
في هذا النظام، صار الاستثناء سجلًا له بنية واضحة: سبب مصنَّف من قائمة محددة، والمرحلة التي رُفع عندها، وحالته (معلّق أو تم الرد)، ومن كتبه، ووقت كتابته. والأهم من ذلك كله: الملف المحدد الذي يشير إليه.
ولماذا هذه الدقة مهمة؟ خذ هذا المثال: يرفع العميل بطاقة الشريك الثاني، فيأتي وجه البطاقة واضحًا بينما ظهرها غير مقروء. قرأ الـ OCR الوجه واستخرج منه البيانات، وأكّدها العميل بنفسه. لكن الظهر لا يصلح للتحقق.
هنا لا يقول النظام «المستند مرفوض» ثم يترك العميل يخمّن. بل يُنشئ طلبًا موجَّهًا لوجه واحد من مستند واحد يخص شريكًا محددًا بالاسم. وحين يرفع العميل الصورة الجديدة، تحل محل القديمة في موضعها بالضبط، وتنتقل القديمة إلى الأرشيف. ولذلك حين يذهب موظف التحقق الميداني لاحقًا، لا يرى إلا النسخة الصالحة.
والخلاصة: بغير هذا التصنيف الدقيق، لن يعرف النظام أي ملف يستبدل بأي ملف. فتصنيف الاستثناء ليس بيانات تُجمع للتقارير — بل هو ما يحدد أي ملف بالضبط سيتم استبداله.
وهذا ما يربط الأنظمة الثلاثة معًا: الاستثناءات وطلبات التوضيح تظهر كلها في بوابة العميل (Customer Portal) في صورة سؤال يجيب عنه. أي أن المكالمة الهاتفية التي لم تكن تُسجَّل صارت قناة لها سجل كامل.
القرار
إظهار مخارج القرار الخمسة
القرار في هذا النظام له خمسة مخارج: الموافقة، والرفض، وطلب توضيح من العميل، والإحالة إلى Compliance، والإحالة إلى فريق الاحتيال (Fraud).
وهذه المخارج الخمسة كانت موجودة أصلًا في العملية الورقية. لم أخترعها. ما فعلته أنني حوّلتها من ممارسات متفرقة إلى أفعال صريحة في النظام، لكل منها أسباب مصنَّفة تُختار من قائمة.
والإحالة تستحق توضيحًا دقيقًا، لأنها تُفهم خطأ عادةً. عند الإحالة، الطلب لا ينتقل من مكانه إطلاقًا — يبقى حيث هو في النظام. المتغير الوحيد أن موظفًا متخصصًا بصلاحيات مختلفة صار قادرًا على فتحه. وهو وحده الذي يستطيع أن يسجّل مثلًا أن هذا الشخص ليس خطر احتيال، بعد أن يتحقق من أنظمة أخرى لا يراها هذا النظام أصلًا.
النتيجة · زمن الإنجاز الذي يعيشه العميل — من ٢٤ ساعة إلى ثلاثة أيام — ليس وعدًا مكتوبًا على شاشته، بل نتيجة مباشرة لبنية هذا النظام: لا شيء يُعاد إدخاله يدويًا، ولا شيء يغادر النظام إلى نظام آخر، وكل سؤال مفتوح له قناة وسجل.
والنظام يقيس نفسه بنفسه. مستوى الخطورة وزمن الإنجاز وحالة الطلب معروضة على اللوحة الرئيسية، وسجل التدقيق يوقّت كل انتقال بين الوحدات بالثانية. أي أن مستوى الخدمة مرصود بالأرقام لا مُدَّعى — وهذا وحده ما يجعله مستوى خدمة حقيقيًا.
هذا الفصل هو الوجه الآخر للفصل السابق. الاستثناء (Exception) يُرفع داخل نظام مراجعة الطلبات بيد موظف البنك، ثم يصل إلى هنا ليراه العميل ويرد عليه.
في النظام الورقي، كان هذا التبادل مكالمة هاتفية. يجد فريق الـ Governance شيئًا غير واضح، فيتصل بمدير العلاقة، فيتصل مدير العلاقة بالعميل. وثلاث مشكلات في هذا الترتيب: لا شيء منه يُسجَّل، وجودة الشرح تعتمد كليًا على من أجرى المكالمة، والعميل نفسه لا يعلم أصلًا أن شيئًا من هذا يحدث.
الرحلة الرقمية أزالت تلك المكالمة. لكنها أزالت معها شيئًا آخر: قدرة العميل على أن يسأل «أين وصل طلبي؟» ففي الفرع هناك إنسان يُسأل. أما على الشاشة فلا أحد — ما لم يُبنَ ذلك عمدًا.
فالبوابة إذن ليست صفحة حالة. هي القناة التي حلت محل المكالمة الهاتفية، إضافة إلى أنها الإجابة عن سؤال لم يعد لدى العميل وسيلة أخرى لطرحه.
القرار
لا حساب للعميل، بل رقم طلب
لا تسجيل، ولا كلمة مرور. لا شيء على العميل أن ينشئه أو يتذكره أو يخشى فقدانه.
يعود العميل برقم طلبه، أو بنفس البريد الإلكتروني ورقم المحمول اللذين بدأ بهما، ثم يتحقق برمز OTP. وبعدها يقرر النظام وجهته تلقائيًا:
أي أن هناك مدخلًا واحدًا وحالة خلفه. ولا يُطلب من العميل أن يعرف الفرق بين «أكمل طلبي» و«أتابع طلبي» — النظام يعرف أين هو ويأخذه إلى هناك.
وهذا القرار هو ما جعل العودة ممكنة أصلًا. في الاختبار، توقف سبعة من عشرة مشاركين وعادوا في جلسة لاحقة. استطاعوا ذلك لأن ما يُعرّف العميل هو الطلب نفسه، لا حساب عليه أن يحافظ عليه. أي أن خاصية الحفظ والاستئناف ليست ميزة أضفناها فوق الرحلة، بل نتيجة طبيعية لهذا القرار في بنيتها.
وتفصيلتان مقصودتان: رقم الطلب مكرر في أكثر من صفحة خلال الرحلة، لأنه يجب أن يصل إلى العميل قبل أن يعرف أنه سيحتاجه. واختيار اللغة متاح قبل الدخول، لا بعده.
القرار
الاستفسار محادثة، لا رفض
شاشة واحدة بثلاثة تبويبات: نظرة عامة على الطلب، واستفسارات معلّقة، واستفسارات تم الرد عليها. والأعداد ظاهرة على التبويبات نفسها، فيعرف العميل إن كان شيء ينتظره قبل أن ينقر أي شيء.
وشريط الحالة يمتد بطول العملية كلها: التقديم، فحص المستندات، المراجعة، توليد رقم الحساب، التحقق الميداني، التفعيل — بتواريخ حقيقية على المراحل المكتملة. أي أن العميل يرى الطريق كاملًا، بما فيه ما لم يحدث بعد. وحيث ينتظره إجراء، يظهر فوقه شريط تنبيه بمدخل مباشر إليه.
وكل استفسار في صورة تذكرة: رقم، ووقت، وحالة، والطلب مكتوبًا بلغة يفهمها العميل، ومعايير القبول، ومنطقة رفع، وحقل رد نصي حر.
وثلاثة أمور في هذه التذكرة تستحق الوقوف:
١ · صياغة السؤال يولّدها النظام من نوع الاستثناء، ولا يكتبها الموظف. حين يرفع فريق الـ Governance استثناءً على البطاقة الضريبية، يصل العميل نفس نص السؤال الذي رآه حين طُلب منه هذا المستند أول مرة في الرحلة. بمعنى أن العميل لا يواجه مصطلحات جديدة لم يرها من قبل حين يحاول تصحيح شيء. أما التفاصيل التي يكتبها الموظف بحرية فتُضاف بعد النص الثابت لا بدلًا منه. وهذا هو الفرق بين قناة جودتها مضمونة ومكالمة هاتفية جودتها رهن بمن أجراها.
٢ · معايير القبول يوفرها النظام، مرتبطة بنوع المستند. ما الذي يجعل البطاقة الضريبية مقبولة؟ هذا ليس شيئًا على الموظف أن يتذكر كتابته في كل مرة. وهذا رد مباشر على فشل حقيقي وقع في رحلة العميل: سجلات تجارية رُفعت بصفحتها الأولى فقط، لأن أحدًا لم يخبر العميل كيف يبدو المستند «المكتمل» قبل أن يحاول رفعه.
٣ · وحيث لا يوجد مستند، يبقى الاستفسار قائمًا. فهناك أنواع تطلب شرحًا لا ملفًا — طبيعة النشاط، أو هل المشترون مساهمون في الشركة، أو لماذا لا يوجد موردون. وهذه تُجاب نصًا مباشرة.
القرار
معنى حالة «تم الرد»
تنتقل التذكرة من «مطلوب إجراء» إلى «تم الرد» حين يُرسل العميل رده — لا حين يقبله البنك.
وهذا متعمد. فلو كانت الحالة تتبع المراجعة الداخلية للبنك، لظل عميل أدى كل ما طُلب منه يرى «مطلوب إجراء» أمامه، دون أن يعرف: هل أخطأ ويجب أن يعيد المحاولة، أم أنه انتهى وعليه أن ينتظر؟ فالحالة هنا تجيب عن السؤال الوحيد الذي يملك العميل التصرف حياله: هل ينتظرني شيء الآن؟
فإن جاء الرد غير كافٍ — بطاقة رُفع وجهها دون ظهرها مثلًا — تعود التذكرة نفسها إلى «مطلوب إجراء» بسؤال متابعة. ولا يُفتح استثناء جديد. أي أن السؤال الواحد يظل واحدًا مهما تعددت جولات الرد عليه، فيرى العميل محادثة متصلة بدل قائمة إخفاقات تتراكم أمامه.
والسجل نفسه معروض بطريقتين مختلفتين. العميل يرى محادثة، والموظف يرى جدولًا — هو سجل الاستثناءات في الفصل السابق. نفس البيانات بكثافتين متعاكستين، لأن العميل لديه طلب واحد ويحتاج أن يفهم قصته، والموظف يمسح عشرات الطلبات يوميًا ويحتاج كثافة تسمح بالفرز السريع.
النتيجة · لم تظهر مشكلات في البوابة أو في رسائل البريد — لا خلال الاختبار ولا خلال الإطلاق المحدود. تتبّع الحالة كان مفهومًا، والإشعارات وصلت.
وهذه نتيجة حقيقية ومحدودة في آن واحد. فمصر ما زالت في إطلاق محدود، وقناة كهذه يختبرها الحجم الكبير، والعملاء الذين لا يفتحون بريدهم أصلًا، والاستفسارات التي تحتاج أربع جولات لا جولة واحدة. ولم يحدث أي من ذلك بعد.
والذي يمكن قوله أضيق من ذلك وأجدر بالقول: المكالمة الهاتفية التي لم تكن تُسجَّل صارت قناة لها سجل كامل، والعميل توقف عن الانتظار دون أن يعرف شيئًا عما يجري.
هنا يصطدم التصميم كله بحدّه الأقصى.
فمصر لا تملك هوية رقمية يستطيع البنك التحقق منها إلكترونيًا. والبنك المركزي يشترط معاينة المستندات الأصلية شخصيًا، وتوقيع كل شريك مؤهل بالحبر. ولدى مشرق ستة فروع فقط في البلد كله مؤهلة لإجراء هذا التحقق.
بمعنى أن هذه الرحلة كانت ستنتهي بلقاء بشري في كل الأحوال، ولا مفر من ذلك. والسؤال الوحيد المطروح كان: من ينتقل إلى الآخر، وماذا يحمل معه.
قرر البنك إنشاء فريق تحقق ميداني مخصص. وهذا قرار أعمال اتخذته الإدارة، لا اقتراحًا مني. أما الذي صممته أنا فهو العمل نفسه: كيف يؤديه هذا الفريق.
والوظيفة تغير شكلها بالكامل. في النموذج القديم، كان مدير العلاقة يزور الشركة ويأخذ بطاقات الشركاء ويصورها بنفسه — أي أنه كان يجمع البيانات. أما اليوم فقد رفع العميل تلك الصور بنفسه أثناء الرحلة الرقمية، فصار عمل الموظف أن يمسك المستند الأصلي بجوار النسخة المرفوعة على النظام ويؤكد تطابقهما. أي أن الدور انتقل من جمع البيانات إلى التحقق منها — وهذه وظيفة مختلفة تمامًا، بأدوات مختلفة وإيقاع مختلف.
وانتقل موظفون حاليون إلى هذا الفريق، وجرى توظيف جدد، لأن الحجم متوقع أن يرتفع: من لم يكن يستطيع الوصول إلى فرع صار يستطيع التقديم من أي مكان — وعلى أحدهم أن يذهب إليه.
القرار
رمز التحقق يثبت أن اللقاء حدث
الموظف واقف أمام العميل وجهًا لوجه. فهوية العميل ليست محل شك أصلًا.
لكن شيئًا آخر كان محل شك: قد يسجّل الموظف أن الزيارة تمت دون أن يذهب إليها فعلًا. وسلسلة الامتثال خلف الحساب كلها تقف على صحة ذلك التسجيل.
لذلك يبدأ التحقق بإرسال رمز OTP إلى رقم محمول العميل المسجل، لا إلى محمول الموظف. يقرأه العميل بصوته، ويُدخله الموظف، فيُفتح الطلب.
أي أن الأداة نفسها المستخدمة في كل موضع آخر من الرحلة تؤدي هنا وظيفة مختلفة تمامًا: ليست تحققًا من هوية العميل، بل إثباتًا بأن الموظف قابله فعلًا في ذلك الوقت وذلك المكان.
ولو سُئلت ما معنى التصميم في بيئة منظَّمة، لأشرت إلى هذه القطعة أولًا. فهي لا تحمي البنك من العميل — بل تحمي سجل الامتثال لدى البنك من احتمال أن يختصر أحد موظفيه الطريق.
القرار
لوحتان مختلفتان، لأن للفريق الميداني تسلسلًا إداريًا
الموظف الميداني يرى مواعيده وزياراته المكتملة فقط. أما قائد الفريق فيرى طابوره، والمكتمل، وطوابير الفرق الأخرى، ومعها زر إعادة إسناد على كل بطاقة.
وإعادة الإسناد موجودة لسببين، كلاهما جاء من الواقع الميداني لا من الهيكل التنظيمي:
١ · قد يغيب الموظف ويغيب مسؤوله في الوقت نفسه. الموظف المسنَد إليه الطلب غائب، وقائد فريقه غائب أيضًا. وبغير طريق يعبر هذه الفجوة، يبقى حساب تمت الموافقة عليه ينتظر شخصًا غير موجود. لذلك يستطيع قائد فريق آخر أن يسحب الطلب إلى فريقه. والصلاحية عابرة للفرق عن قصد، لأن المشكلة التي تحلها عابرة للفرق أيضًا.
٢ · التقسيم الإداري للمحافظات لا يعكس المسافات الفعلية. فالمهندسين تتبع الجيزة إداريًا، لكنها أقرب فعليًا إلى فرق القاهرة. لذلك يسمح النظام لفريق القاهرة بخدمتها. أي أن العمل يتبع الخريطة الحقيقية لا الهيكل الإداري.
وكل بطاقة تحمل مصيرها — مكتملة، أو فاشلة، أو مرفوضة، أو ناجحة — ومعها مكان حدوثها: في مقر العميل أو في فرع مشرق.
القرار
زر واحد صار قائمة، لأن الزيارات تفشل
في النسخة الأولى (MVP-1) كان هناك إجراء واحد فقط: «المتابعة إلى التحقق». وهو يفترض ضمنًا أن الزيارة تنجح دائمًا.
والزيارات لا تنجح دائمًا. العملاء لا يحضرون أحيانًا، والعناوين تكون خاطئة، والمواعيد يُطلب تأجيلها. ومع زر واحد فقط، كان كل ذلك ينهار إلى طلب واقف بلا سبب مسجل يفسر توقفه.
فصار الزر «اتخذ إجراء»، ويفتح قائمة: التواصل مع العميل · المتابعة إلى التحقق · طلب إعادة الجدولة · العميل لم يحضر · رفض · إرجاع إلى الـ Governance بمهلة يومين. ويستطيع الموظف الاتصال من داخل التطبيق — مكالمة عادية على شريحة الجهاز — وتسجيل ملاحظات المكالمة بعدها.
ونتج عن ذلك أمران، والثاني هو الأهم:
١ · رُفعت المسؤولية عن الموظف. فالطلب المتأخر صار يحمل سبب تأخره معه. الموظف أدى واجبه؛ والعميل لم يحضر.
٢ · وصار زمن الإنجاز قابلًا للتفسير. لم يعد الأمر «استغرق تسعة أيام» فحسب، بل «استغرق تسعة أيام لأن العميل لم يحضر مرة وأجّل الموعد مرتين». وسجل التدقيق يحفظ كل حالة بسبب مكتوب.
وهذا هو المبدأ نفسه من فصل نظام المراجعة، لكن مطبقًا على الزمن بدل الحكم: النظام لا يمنع الفشل، لكنه يسجّل سببه بحيث تستطيع الإدارة أن تتصرف حياله. فالإدارة تستطيع التعامل مع «العميل لم يحضر ثلاث مرات»، ولا تستطيع التعامل مع «الطلب متأخر» فقط.
النتيجة · يصبح الحساب فعّالًا حين توافق الـ Governance، ويصبح قابلًا للتعامل فقط حين تُعاين الأصول ويوقّع كل مالك مؤهل. وهذا الفصل هو المسافة بين هاتين الكلمتين. وإغلاق تلك المسافة هو ما يجعل رقم الـ ٢٤ ساعة إلى ٣ أيام مستوى خدمة حقيقيًا، لا ادعاءً عن سجل في قاعدة بيانات.
ولم يحاول التصميم إزالة الإنسان من هذه الخطوة. فالتنظيم المصري يضع إنسانًا هناك، ولا توجد واجهة تستطيع أن تجادل في ذلك. والذي فعله التصميم هو ضمان أنه حين يصل ذلك الإنسان، يكون كل ما يمكن إنجازه دونه قد أُنجز بالفعل — المستندات ملتقطة، والبيانات محققة، والنموذج مولَّد، ولا شيء متبقٍ يُجمع ولا شيء يُعاد إدخاله.
الموظف يصل ليؤكد، لا ليجمع. وهذا هو المقصد كله من الأنظمة الستة التي تعمل خلفه.