بانک و خدمات مالی

داده هست؛ پاسخ نیست

یک بانک متوسط ده‌ها سامانهٔ عملیاتی و هزاران جدول داده در اختیار دارد. با این حال وقتی مدیری می‌پرسد علت رشد معوقات یک استان چیست، پاسخ از دل داده بیرون نمی‌آید؛ از دل یک صف بیرون می‌آید.

مسیر همه‌جا یکسان است. پرسش مطرح می‌شود. درخواست در ادارهٔ فناوری یا واحد اطلاعات مدیریت ثبت می‌گردد. دو تا سه روز در نوبت بررسی و اولویت‌بندی می‌ماند. گزارش روز پنجم یا هفتم تحویل می‌شود — در خوش‌بینانه‌ترین حالت، و به شرط آنکه به همان پرسشی که پرسیده شده پاسخ داده باشد.

سه چیز این وضع را نگه می‌دارد. داشبورد از پیش تعریف‌شده تنها به پرسش‌هایی پاسخ می‌دهد که کسی قبلاً به آن‌ها فکر کرده است. رئیس شعبه، کارشناس اعتبارات و مدیر بازاریابی امکان طرح مستقیم پرسش را ندارند و همواره به واسطهٔ فنی نیازمندند. و تا گزارش برسد، پنجرهٔ تصمیم بسته شده و داده به سند بایگانی بدل شده است، نه ابزار مدیریت.

مسئله «نبودِ داده» نیست؛ مسئله نرخ گردش پرسش و پاسخ است.

هزینهٔ صف

چهار هزینه، که هیچ‌کدام سرفصل ندارند:

• فرصت‌های جذب منابع که در زمان مناسب شناسایی نمی‌شوند.
• ریسک اعتباری که با تأخیر تشخیص داده می‌شود؛ معوقه هنگامی مشاهده می‌گردد که ایجاد شده است.
• ریزش مشتریان ارزشمند که تنها پس از خروج منابع آشکار می‌شود.
• ظرفیت کارشناسان داده که به‌جای تحلیل، صرف تولید گزارش‌های تکراری می‌گردد.

اما بزرگ‌ترین هزینه از این چهار ظریف‌تر است. هر پاسخ حدود سه پرسش تازه پدید می‌آورد و هر پرسش تازه بار دیگر از ابتدای همان صف آغاز می‌شود. نتیجه آن است که بررسی زود متوقف می‌شود. «سودآوری این شعب چه روندی داشته؟» پرسیده می‌شود. «از سمت درآمد بوده یا بهای تجهیز منابع؟» گاهی پرسیده می‌شود. «آیا این شعب ویژگی مشترکی دارند؟» — همان جایی که پاسخ واقعی آنجاست — معمولاً هرگز پرسیده نمی‌شود، چون با هفته‌ای یک گام کسی به آن نمی‌رسد.

کاری که تغییر می‌کند

بخش دشوار تحلیل، اجرای کوئری نیست؛ طرح پرسش درست است.

«چرا سودآوری شعب استان کاهش یافته است؟»

این پرسش یک پاسخ ندارد، چون سه انتخاب ناگفته در خود دارد: کدام بازهٔ زمانی، سود عملیاتی یا خالص، و مقایسه با سال گذشته یا با بودجهٔ مصوب. پس سامانه همان کاری را می‌کند که یک تحلیل‌گر خوب می‌کند — می‌پرسد، دامنه را روشن می‌کند و پیش از آغاز آن را برای تأیید ارائه می‌دهد. سپس محورهای بررسی را پیشنهاد می‌دهد: ترکیب درآمد، بهای تجهیز منابع، کیفیت پرتفوی. هیچ بررسی‌ای بدون تأیید دامنه آغاز نمی‌شود.

برای پرسش‌هایی که پاسخشان یک عدد نیست، یک اجرای پژوهشی یک ارکستریتور و ناوگانی از کارگرها — بین سه تا بیست عدد در هر اجرا — را روانه می‌کند که هم‌زمان محورهای متفاوت را روی منابع مربوط دنبال می‌کنند و در پایان یک گزارش مستند با ارقام پشتیبان تحویل می‌دهند.

دو ویژگی در محیط بانکی از هر دوی این‌ها مهم‌ترند. کاربرِ دارای مجوز عین کوئری اجراشده را می‌بیند، پس یافته را می‌توان راستی‌آزمایی کرد نه اینکه به آن اعتماد کرد. و اگر داده برای پاسخ کافی نباشد، سامانه صریحاً همین را اعلام می‌کند و پاسخ حدسی نمی‌سازد. در بانک، پاسخ نادرست از نبود پاسخ زیان‌بارتر است؛ و یک قطع‌کنندهٔ مدار در لایهٔ داده همین را تضمین می‌کند: هشت خطای پیاپی به خطای صریح می‌انجامد، نه به پاسخی ساختگی. عددی هم که در نمودار می‌نشیند از اجرای کد روی مجموعهٔ نتیجه می‌آید، نه از مدلی که حساب را داخل جمله می‌نویسد.

به چه چیزی وصل می‌شود

هیچ مهاجرت داده‌ای در کار نیست و هیچ نسخه‌ای از داده جای دیگر کپی نمی‌شود. داده در همان محل باقی می‌ماند و تنها خوانده می‌شود. یک لایهٔ آداپتور، سی موتور پایگاه‌داده را پشت یک واسط واحد پوشش می‌دهد — Oracle، SQL Server، Db2، PostgreSQL، MySQL، ClickHouse، Snowflake، MongoDB، Elasticsearch و بقیه — و همین است که ساختن یک پاسخ از دل چند سامانه را اصلاً ممکن می‌کند.

اتصال با کاربر فقط‌خواندنی برقرار می‌شود؛ کاربری که واحد امنیت بانک خود می‌سازد و کنترل می‌کند. هر پرس‌وجو داخل تراکنشی فقط‌خواندنی و زمان‌دار با سقف تعداد سطر اجرا می‌گردد. مهم‌ترین گام استقرار هم نصب نیست؛ مستندسازی ساختار داده است: دستیار مستندسازی برای هر جدول و ستون توضیح پیشنهاد می‌دهد و کارشناس بانک ویرایش و تأیید می‌کند. همان‌جاست که «مانده مؤثر» به ستونی که بانک از آن مراد می‌کند گره می‌خورد، و همان گام تعیین می‌کند که پاسخ‌ها با گزارش‌های رسمی بانک هم‌راستا باشند یا نباشند.

کجا انتخاب درستی نیست

• اگر پرسش‌ها ثابت‌اند، گزارش بسازید. پرسش معلومی که هر روز صبح چهل نفر می‌پرسند، داشبورد است؛ و داشبورد ارزان‌تر و قابل‌پیش‌بینی‌تر است.
• اگر انبار داده مستند نیست، اول بودجهٔ مستندسازی را بگذارید. رایج‌ترین دلیل ناامیدی در این استقرارها همین است. هیچ مدل زبانی اسکیمایی را که کسی نمی‌تواند توضیحش دهد ترمیم نمی‌کند.
• اگر بانک بر سر تعریف شاخص توافق ندارد، اختلاف بر سر تعریف است و هیچ ابزاری آن را فیصله نمی‌دهد. معمولاً همان هفتهٔ اول بیرون می‌زند، که دست‌کم مفید است.
• اگر به نوشتن نیاز دارید — تأیید، اصلاح، گردش کار — این لایهٔ درستی نیست. فقط‌خواندنی یک تصمیم طراحی است، نه محدودیتی که قصد رفعش را داشته باشیم.
• اگر انبار داده یا نسخهٔ همانندی وجود ندارد، آن پروژه مقدم است. ما در اجرای کوئری تحلیلی روی سامانهٔ متمرکز زنده همراهی نمی‌کنیم.
• امروز در دو سازمان مستقر است. نوپا، با مهندسی عمیق — و ترجیح می‌دهیم پیش از اولین جلسه بدانید.