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

هذه هي الرحلة التي لا تعرضها أغلب ملفات الأعمال، لأن أحدًا خارج البنك لا يراها.

في النظام الورقي، كان الطلب يصل في صورة ملف. يقرأه فريق الـ Governance ويفحصه، ثم يُدخل بياناته يدويًا في نظام Flex. أما فحص الأسماء (eName screening) فكان يجري في نظام منفصل تمامًا يُخرج تقريرًا بصيغة PDF. والتفويضات (Mandates) كانت تُبنى في نظام ثالث.

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

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

الأدوار: الوحدة المسؤولة اسمها Account Opening Unit، وبداخلها دوران. الأول Governance، ويراجع الطلب ومستنداته وتفويضاته ويتخذ القرار النهائي. والثاني Compliance، ويعمل على نتائج فحص الأسماء.

والأهم أن من يُدخل البيانات ويقيّمها (الـ maker) ليس هو من يوافق عليها (الـ checker) — شخصان مختلفان. وهذا الفصل تحديدًا هو ما سمح لبقية التصميم أن يكون بهذه السرعة، كما سيتضح لاحقًا.

Name screening. Results grouped by conclusion — exact match, no violation, discounted, potential, no conclusion — for every individual and company on the application. A row expands to the evidence behind it: the matched name, the service hit ID, the risk category, and the reason. Previously this arrived as a PDF: readable, but not actionable. Here the judgement happens in the same place as the evidence.

The exception trail. Every query ever raised on an application, with its reason, stage, status, author and timestamp. Not a log of failures — a record of the conversation the bank used to have by phone.

The audit log, and the application timeline beside it. The log records which unit held the application, when it was assigned, when it was picked up, when it was released, and how long it took — to the second. The timeline shows what actually changed, field by field, old value to new, alongside when the customer was asked something and when they answered.

The decision. Five outcomes, each opening a set of structured reasons plus free comment. Where exceptions are still unresolved, they are surfaced above the decision area — the officer sees what is outstanding before choosing, not after.

All interface work is shown as designed. Names, figures and identifiers are sample values; the production visual skin is under NDA.

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

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

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

٣ · الترتيب الإجباري كان مصممًا للـ maker، وكان يعطّل الـ checker. في النسخة الأولى كان لا بد من إنهاء كل قسم بالترتيب قبل فتح ما يليه. وهذا مناسب تمامًا لمن يُدخل البيانات ويقيّمها للمرة الأولى. لكنه يعطّل من يراجع، لأن طبيعة عمله أن يقفز بين الأقسام ويقارن بينها. لذلك استبدلنا الترتيب الإجباري بحرية التنقل بين الأقسام.

وهذه هي المرة الثانية التي يواجهني فيها الدرس نفسه. في رحلة العميل صممت تنقلًا حرًا ثم تنازلت عنه بسبب قيد تقني، فأعاده الاحتياج الحقيقي لاحقًا. وهنا فُرض الترتيب من البداية فكسره الواقع. أي أن الترتيب الإجباري مناسب لمن يُدخل البيانات، ومعطِّل لمن يراجعها — تعلمت ذلك من الاتجاهين.

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

وبالإضافة إلى ذلك: كان تصنيف الاستثناءات في النسخة الأولى أخشن من أن يدعم الاستبدال الموجَّه الذي وصفته أعلاه، كما أعدت بناء أعمال قابلية الوصول والاستخدام (Accessibility) بالكامل في النسخة الحالية.

الإشارة الأولى كانت أن زمن الإنجاز (TAT) مرتفع. لم تكن شكوى من أحد، بل رقمًا لاحظناه.

فبدأت التحقيق: جلست مع الموظفين، وراقبتهم وهم يعملون. وهنا المنهج أهم من الحكاية نفسها:

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

وما أظهره السلوك: موظف يتعامل مع نتائج فحص الأسماء صفًا صفًا، في تقرير قد يمتد إلى عشرات النتائج للطلب الواحد. فاقترحت إضافة خانات اختيار متعددة (checkboxes) مع إجراء مجمّع (bulk action) يُطبَّق على المحدد دفعة واحدة.

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

لا يوجد في النظام حاجز يمنع موظفًا من تعليم نتيجة تعليمًا خاطئًا. وهذا موقف متعمد، لا ثغرة نسيناها.

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

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

زمن الإنجاز الذي يعيشه العميل — من ٢٤ ساعة إلى ثلاثة أيام — ليس وعدًا مكتوبًا على شاشته، بل نتيجة مباشرة لبنية هذا النظام: لا شيء يُعاد إدخاله يدويًا، ولا شيء يغادر النظام إلى نظام آخر، وكل سؤال مفتوح له قناة وسجل.

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

Next chapter: Customer Portal & Notifications — the same application, seen by the person waiting.