Təcrübə, yoxsa dərinlik?

Giriş: Seniorluq təqvimlə ölçülmür

Rəqəmsal transformasiya dövründə təşkilatların idarə heyətləri, məhsul rəhbərləri və İnsan Resursları departamentləri tərəfindən buraxılan strateji xətalardan biri mütəxəssisin peşəkar yetkinliyini sırf iş təcrübəsinin müddəti ilə ölçməkdir.

Biznes Analitik (Business Analyst — BA) karyerasında Junior, Mid, Senior səviyyələri çox vaxt sənayedə keçirilmiş illər, tamamlanmış layihələrin sayı və istifadə olunan alətlərlə əlaqələndirilir. Halbuki eyni texnologiyalarla beş il işləyən iki analitik tamamilə fərqli düşüncə modellərinə sahib ola bilər.

Onlardan biri verilmiş tələbi düzgün sənədləşdirə, istifadəçi ssenarilərini hazırlaya və funksionallığın gözlənilən davranışını təsvir edə bilər. Digəri isə eyni tələbin biznes qaydalarına, API müqavilələrinə, məlumatların bütövlüyünə, inteqrasiyalara, informasiya təhlükəsizliyinə, auditə, sistemin dayanıqlılığına və təşkilatın uzunmüddətli strategiyasına təsirini əvvəlcədən görə bilər.

Məhz burada əsas fərq yaranır.

Peşəkar yetkinlik yalnız nə qədər bildiyimizlə deyil, bir problemin arxasında nə qədər çox əlaqəni görə bilməyimizlə ölçülür.

Seniorluq, əlbəttə, təkcə texniki dərinlik demək deyil. O, həm də qeyri-müəyyənlik şəraitində qərarları əsaslandırmaq, alternativləri müqayisə etmək, riskləri qiymətləndirmək, maraqlı tərəfləri ortaq anlayış ətrafında birləşdirmək və biznes nəticələrinə görə məsuliyyətli düşünmək bacarığıdır.

Bu yanaşmanı konseptuallaşdırmaq üçün 4 Təbəqəli Analiz Dərinliyi Modelini təklif edirəm.

Bu model universal peşəkar sertifikasiya standartı deyil. O, biznes analitikinin düşüncə dərinliyini qiymətləndirmək, inkişaf istiqamətlərini müəyyənləşdirmək və real layihələrdə təhlilin əhatəsini genişləndirmək üçün təklif olunan konseptual çərçivədir.

I. Dörd təbəqəli analiz dərinliyi modeli

1. İnterfeys və insan-kompüter qarşılıqlı əlaqəsi

Client-Side & User Experience

Birinci təbəqə istifadəçinin sistemlə birbaşa qarşılıqlı əlaqədə olduğu sahədir. İstifadəçi düyməyə basır, məlumat daxil edir, seçim edir və sistemdən cavab gözləyir.

Bu mərhələdə analitik üçün əsas sual belədir:

İstifadəçi nə etməlidir və sistem onun hərəkətinə necə reaksiya verməlidir?

Analiz aşağıdakı məsələləri əhatə edə bilər:

• İstifadəçi ssenariləri, ekran axınları və alternativ gedişatlar.
• Sahələrin formatı, məcburiliyi və ilkin validasiya (regex) qaydaları.
• Yanlış və natamam məlumat daxil edildikdə sistemin davranışı.
• Uğurlu və uğursuz əməliyyatlar zamanı istifadəçiyə göstərilən mesajlar.
• Yüklənmə vəziyyətləri, təkrar cəhdlər və internet bağlantısının itirilməsi.
• Mobil, veb və digər platformalarda vahid istifadəçi təcrübəsi.
• Əlçatanlıq, dil seçimi və istifadəçinin müraciət prosesini yarımçıq saxlaması.

Bu təbəqə zəruridir. Lakin burada düzgün işləyən interfeys bütövlükdə düzgün işləyən sistem demək deyil.

Məsələn, istifadəçi kredit müraciəti formasına 10 000 AZN daxil edə bilər. İnterfeys məbləğin icazə verilən diapazonda olduğunu yoxlaya bilər. Ancaq bu, müştərinin həmin məbləğdə kredit almaq hüququna malik olduğunu, gəlirinin kifayət etdiyini və ya müraciətin risk baxımından qəbul edilə biləcəyini göstərmir.

Üstəlik, brauzerdə və ya mobil tətbiqdə aparılan validasiya təhlükəsizlik sərhədi deyil. Eyni kritik qaydalar arxan planda da yoxlanılmalıdır.

Beləliklə, birinci təbəqənin əhatə dairəsi istifadəçinin gördüyü ekranla məhdudlaşmır. Burada əsas məqsəd istifadəçi hərəkətini aydın, ardıcıl, anlaşılan və idarəolunan etməkdir.

Birinci təbəqənin nəticəsi: istifadəçi nə edəcəyini başa düşür, sistem isə istifadəçi hərəkətlərinə proqnozlaşdırıla bilən şəkildə cavab verir.

2. Biznes domeni, tətbiq məntiqi və inteqrasiya müqavilələri

Domain Logic, APIs & Event-Driven Architecture

İkinci təbəqədə analitik ekranın arxasındakı biznes mexanizmini anlamağa başlayır.

Müasir informasiya sistemində bir düymənin arxasında biznes qaydaları, müxtəlif servislər, xarici inteqrasiyalar, məlumat mənbələri və digər sistemlərə ötürülən əməliyyatlar dayana bilər.

Bu mərhələdə əsas sual dəyişir:

Sistem bu funksionallığı hansı biznes qaydaları əsasında, hansı komponentlərlə qarşılıqlı əlaqədə və hansı ardıcıllıqla icra etməlidir?

Biznes domeninin dərinliyi

Analitik yalnız sahələrin adını və API sorğusunun strukturunu təsvir etməməlidir. O, biznes qaydalarının mahiyyətini başa düşməlidir.

Məsələn, kredit müraciətində aşağıdakı suallar yaranır:

• Müştərinin kimliyi hansı mənbə əsasında təsdiqlənir?
• Kredit üçün uyğunluq meyarları hansılardır?
• Müştərinin gəliri və mövcud öhdəlikləri necə nəzərə alınır?
• Kredit məbləği hansı qaydalarla hesablanır?
• Hansı hallarda müraciət avtomatik rədd edilməli, hansı hallarda əlavə yoxlamaya göndərilməlidir?
• Xarici kredit bürosu cavab vermədikdə proses necə davam etməlidir?
• Eyni müraciət təkrar göndərilərsə, sistem ikinci dəfə əməliyyat yaratmalıdırmı?

Sonuncu sual xüsusilə vacibdir. Mobil tətbiqdə internet bağlantısı kəsildikdə istifadəçi düyməni bir neçə dəfə basa bilər. Sistem hər dəfə yeni müraciət yaradırsa, eyni biznes əməliyyatının təkrar icrası riski yaranır.

Burada idempotentlik (idempotency) anlayışı ortaya çıxır: eyni məntiqi sorğunun təkrar göndərilməsi nəzərdə tutulmayan əlavə nəticələrin yaranmasına səbəb olmamalıdır.

Bu, yalnız developer-in implementasiya detalı deyil. Biznes analitikinin təkrar müraciət, əməliyyatın unikallığı, statusların idarə olunması və mümkün istisnalar üzrə tələbləri müəyyənləşdirməsi vacibdir.

API müqavilələri və sistemlərarası əlaqələr

Analitik API müqavilələrində yalnız request və response sahələrini deyil, həm də sistemlər arasında razılaşdırılmış davranışı təsvir etməlidir.

Buraya daxildir:

• Sorğu və cavab strukturları.
• Məcburi və şərti sahələr.
• Biznes xətaları ilə texniki xətaların fərqləndirilməsi.
• Autentifikasiya və avtorizasiya gözləntiləri.
• Sorğuların vaxt məhdudiyyəti və təkrar cəhd qaydaları.
• Versiyalaşdırma və geriyə uyğunluq.
• Sorğunun izlənməsi üçün unikal identifikatorlar.
• Sinxron və asinxron emal ssenariləri.

Sinxron API-lər dərhal cavab tələb olunan əməliyyatlar üçün uyğundur. Asinxron yanaşma isə uzun çəkən proseslərdə və komponentləri bir-birindən ayırmaq lazım gəldikdə faydalı ola bilər. Müasir sistemlərin hamısının asinxron işləməsi zəruri deyil; seçim biznes tələblərindən və qeyri-funksional məhdudiyyətlərdən asılıdır.

Event-Driven Architecture: məlumatın hadisəyə çevrilməsi

Təsəvvür edək ki, istifadəçi kredit müraciətini göndərir. Sistem müraciəti qəbul etdikdən sonra bir neçə servisin işini gözləmədən prosesi davam etdirə bilər.

Məsələn:

1. Kredit müraciəti qeydə alınır.
2. CreditApplicationSubmitted hadisəsi yaradılır.
3. Skorinq xidməti bu hadisəni qəbul edir.
4. Digər xidmətlər zərurət olduqda fırıldaqçılıq riskini, kredit tarixçəsini və digər meyarları yoxlayır.
5. Qərar formalaşdıqda müraciətin statusu yenilənir.
6. İstifadəçi nəticə barədə məlumatlandırılır.

Hadisə-əsaslı arxitekturanın üstünlüyü sistem komponentlərinin bir-birinə həddindən artıq bağlı olmamasıdır. Hadisə bir neçə müstəqil istehlakçı tərəfindən istifadə oluna, sonrakı emal isə paralel təşkil edilə bilər. Bu yanaşmanın konseptual əsasları Apache Kafka sənədlərində və AsyncAPI materiallarında izah olunur.

Bu sahədə tez-tez qarşılaşdığımız iki texnologiya Apache Kafka və RabbitMQ-dur.

Apache Kafka hadisə axınlarının saxlanılması, müxtəlif istehlakçılara çatdırılması və məlumatların real vaxta yaxın emalı üçün geniş istifadə olunur.

RabbitMQ isə növbələr, mesajların marşrutlaşdırılması və istehlakçıların işinin idarə olunması üçün istifadə edilən mesaj brokeridir.

Bunları avtomatik olaraq bir sistemdə birlikdə tətbiq etmək lazım deyil. İki texnologiyanın birlikdə istifadəsi bəzi arxitekturalarda əsaslandırıla bilər, lakin əlavə infrastruktur, monitorinq, xəta ssenariləri və əməliyyat mürəkkəbliyi yaradır. Qərar konkret ehtiyaca əsaslanmalıdır.

BA-nın texnologiyanın daxili konfiqurasiyasını müəyyən etməsi mütləq deyil. Onun əsas vəzifəsi texnoloji seçimə təsir edən biznes və sistem tələblərini aydınlaşdırmaqdır.

Məsələn:

• Hadisə itirilməməlidirmi?
• Eyni hadisə iki dəfə emal edilərsə nə baş verməlidir?
• Hadisələrin müəyyən müştəri üzrə ardıcıllığı qorunmalıdırmı?
• İstehlakçı xidmət dayanarsa, proses necə bərpa edilməlidir?
• Uğursuz mesajlar necə ayrılmalı və təkrar emal olunmalıdır?
• Hər bir müraciətin tam icra müddəti nə qədər ola bilər?

Bu suallar texnologiyanın adından daha əhəmiyyətlidir.

Asinxron API müqavilələrinin dəqiq sənədləşdirilməsi üçün OpenAPI ilə yanaşı, hadisə və mesaj müqavilələrini təsvir edən AsyncAPI kimi spesifikasiyalardan istifadə oluna bilər.

İkinci təbəqənin nəticəsi: analitik tələbin yalnız necə göründüyünü deyil, hansı biznes qaydaları ilə və hansı sistemlərarası müqavilələr əsasında icra edildiyini anlayır.

3. Məlumatların saxlanması, dayanıqlılıq, müşahidəolunma və GRC

Persistence, Resilience, Observability & Governance

Üçüncü təbəqədə problem daha da dərinləşir.

Artıq məsələ yalnız əməliyyatın icra olunması deyil. Əsas suallar bunlardır:

Məlumat harada və hansı qaydalarla saxlanılır? Sistem xətaya necə reaksiya verir? Baş vermiş hadisəni sonradan araşdırmaq mümkündürmü? Məlumatlar tələb olunan səviyyədə qorunurmu?

Verilənlər bazası seçimi

Analitikdən DBA (Database Administrator) və ya həll arxitektoru kimi işləməsi gözlənilmir. Bununla belə, o, məlumat modelinin biznes üçün nəticələrini başa düşməlidir.

Əlaqəli verilənlər bazaları, məsələn, PostgreSQL və ya Oracle, əlaqələr, məhdudiyyətlər və tranzaksiyalar tələb edən məlumatlar üçün uyğun seçim ola bilər.

NoSQL həlləri, məsələn, MongoDB, çevik sənəd strukturları və müəyyən məlumat emalı modelləri üçün faydalı ola bilər.

Lakin bu o demək deyil ki, bütün maliyyə məlumatları avtomatik olaraq SQL-də, bütün istifadəçi davranışları isə NoSQL-də saxlanılmalıdır. Seçim məlumatların quruluşu, sorğu nümunələri, ardıcıllıq tələbləri, gözlənilən yük, əməliyyat xərcləri və sistemin idarə olunması imkanları əsasında edilir.

Analitik bu qərar üçün aşağıdakı sualları cavablandırmağa kömək etməlidir:

• Məlumat hansı biznes obyektini təmsil edir?
• Məlumatın unikallığı necə qorunmalıdır?
• Bir əməliyyatda bir neçə məlumat elementi dəyişirsə, onların hamısı uğurla dəyişməlidirmi?
• Məlumatlar arasında hansı əlaqələr mövcuddur?
• Eyni məlumatın fərqli sistemlərdə saxlanılması hansı riskləri yaradır?
• Məlumatın silinməsi, arxivləşdirilməsi və bərpası ilə bağlı hansı biznes qaydaları var?

Maliyyə əməliyyatlarında ACID prinsipləri və tranzaksiyaların bütövlüyü xüsusi əhəmiyyət daşıyır. Bununla belə, yalnız relational database seçmək sistemin avtomatik olaraq düzgün layihələndirilməsi demək deyil. Tranzaksiya sərhədləri və sistemlərarası uyğunluq ayrıca təhlil tələb edir.

Dayanıqlılıq və xəta ssenariləri

Ən yaxşı ssenari sistemin işləməsidir. Peşəkar analiz isə sistem işləmədikdə nə baş verəcəyini də müəyyən etməlidir.

Məsələn, kredit müraciəti qeydə alınıb, lakin hadisəni skorinq xidmətinə çatdıran prosesdə xəta baş verib. İstifadəçiyə müraciətin uğurla qəbul edildiyi bildirilsə də, emal başlanmayıb.

Belə halda hansı nəticə yaranır?

İstifadəçi saatlarla cavab gözləyə bilər. Əməliyyat bazasında müraciət görünə, lakin sonrakı proseslər bu müraciətdən xəbərsiz qala bilər.

Bu risklərin azaldılması üçün həll arxitekturasından asılı olaraq aşağıdakılar nəzərdən keçirilə bilər:

• Təkrar cəhd və artan gözləmə intervalı (exponential backoff).
• İdempotent emal mexanizmləri.
• Uğursuz mesajların ayrılıqda saxlanılması üçün dead-letter queue.
• Məlumat bazası ilə hadisə brokeri arasındakı uyğunsuzluğu azaltmaq üçün transactional outbox kimi yanaşmalar.
• Müraciətin statusunun və emal tarixçəsinin saxlanılması.
• Sistem bərpa olunduqdan sonra yarımçıq qalan proseslərin davam etdirilməsi.

BA bu mexanizmləri kod səviyyəsində layihələndirməyə bilər, lakin onların həll etməli olduğu biznes problemini və gözlənilən davranışı müəyyənləşdirməlidir.

Observability: sistemin vəziyyətini necə anlayırıq?

Observability anlayışı çox vaxt yalnız logların yazılması ilə eyniləşdirilir. Əslində sistemin müşahidəolunması bir-birini tamamlayan bir neçə mexanizmi əhatə edir:

• Logs: konkret hadisələrin və xətaların qeydləri.
• Metrics: sistemin və biznes prosesinin ölçülə bilən göstəriciləri.
• Traces: sorğunun müxtəlif servislərdən keçdiyi yolun izlənilməsi.

Məsələn, kredit müraciətinin niyə gecikdiyini araşdırarkən yalnız xəta mesajı kifayət etməyə bilər. Müraciətin hansı vaxtda qəbul edildiyi, hansı servisdə gözlədiyi, xarici sistemin cavab müddəti və ümumi emal müddəti də əhəmiyyətlidir.

Analitik aşağıdakı sualları verməlidir:

• Biznes əməliyyatının hər mərhələsini izləmək mümkündürmü?
• İstifadəçinin müraciət statusu ilə daxili sistemlərin emal statusu əlaqələndirilə bilirmi?
• Uğursuz əməliyyatları müəyyənləşdirmək üçün hansı göstəricilər lazımdır?
• Problem yarandıqda onun texniki səbəbini və biznes təsirini müəyyən etmək mümkündürmü?

Bu sualların cavabları sistemin istismar keyfiyyətinə birbaşa təsir göstərir.

GRC, audit və fərdi məlumatların qorunması

GRC — Governance, Risk and Compliance — idarəetmə, risklərin idarə olunması və uyğunluq yanaşmalarını birləşdirir.

Burada mühüm bir məsuliyyət sərhədi var: loglarda hansı məlumatın saxlanılması və neçə il qorunması barədə qərarı yalnız BA verməməlidir. Bu tələblər biznes ehtiyacları, informasiya təhlükəsizliyi, hüquq, uyğunluq, məlumatların idarə olunması və arxitektura üzrə məsul şəxslərlə birgə müəyyən edilməlidir.

Analitik isə həmin qərarların biznes tələblərində düzgün əks olunmasına kömək edir.

Məsələn, audit aşağıdakı suallara cavab tələb edə bilər:

• Əməliyyatı hansı istifadəçi və ya sistem başladıb?
• Əməliyyat nə vaxt baş verib?
• Hansı biznes obyektinə təsir edib?
• Əməliyyat uğurlu olub, yoxsa rədd edilib?
• Qərar hansı qayda və ya proses əsasında verilib?

Bu məqsədlər üçün həmişə şəxsi məlumatların tam şəkildə loglara yazılması lazım deyil. Əksinə, FİN, maliyyə məlumatları, autentifikasiya tokenləri, parollar və digər həssas məlumatlar loglara açıq şəkildə daxil edilməməli, zəruri hallarda maskalanmalı və ya digər qoruma üsulları tətbiq olunmalıdır.

IP ünvanı və cihaz identifikatoru da kontekstdən asılı olaraq fərdi məlumat sayılmaq riski daşıya bilər. Buna görə onların toplanması və saxlanılması konkret məqsəd, hüquqi əsas, giriş nəzarəti və saxlama müddəti əsasında müəyyən edilməlidir.

Məlumatların minimumlaşdırılması prinsipi yalnız zəruri məqsəd üçün lazım olan məlumatların toplanmasını və saxlanılmasını nəzərdə tutur. Texniki loglama üzrə əlavə istiqamətləri OWASP Logging Cheat Sheet materialında tapmaq olar.

Üçüncü təbəqənin nəticəsi: analitik sistemin yalnız işləməsini deyil, məlumatın bütövlüyünü, xətalardan sonra bərpasını, əməliyyatların izlənilməsini və tələb olunan idarəetmə qaydalarına uyğunluğunu da nəzərə alır.

4. Makroekosistem, kaskad təsirlər və biznes zəkası

Ecosystem Architecture, Customer 360 & Business Outcomes

Dördüncü təbəqədə analitik artıq funksionallığı təcrid olunmuş modul kimi deyil, təşkilatın bütöv sisteminin bir hissəsi kimi nəzərdən keçirir.

Bu səviyyədə əsas sual belədir:

Bu funksionallıq hansı sistemləri, biznes proseslərini, qərarları və ölçülə bilən nəticələri dəyişdirəcək?

Bir xidmətin nəticəsi başqa xidmət üçün giriş məlumatına çevrilə bilər. Ancaq bu əlaqələr avtomatik və nəzarətsiz yaradılmamalıdır. Hər bir inteqrasiya üçün məlumatın məqsədi, sahibi, ötürülmə qaydası, keyfiyyəti və istifadə hüquqları müəyyən edilməlidir.

Output = Input: bir əməliyyatın ekosistemə təsiri

Tutaq ki, kredit müraciəti ilə bağlı qərar formalaşıb.

Bu nəticə yalnız mobil tətbiqdə göstərilən status deyil. Biznes ehtiyacından asılı olaraq o, bir neçə prosesə təsir göstərə bilər:

• CRM sistemində müştəri ilə qarşılıqlı əlaqənin tarixçəsinin yenilənməsi.
• Müştərinin müraciətinin tamamlama və ya tərk etmə mərhələsinin analitik sistemlərə ötürülməsi.
• Əməliyyat göstəricilərinin Data Warehouse-a yazılması.
• Müştəri müraciətləri üzrə xidmət səviyyəsinin monitorinqi.
• Müştərinin müraciət prosesi ilə bağlı bildirişlər alması.
• Müvafiq şərtlər və icazələr olduqda digər uyğun məhsullar haqqında məlumatlandırma.

Burada əsas prinsip sadəcə daha çox sistemə məlumat göndərmək deyil. Əsas məqsəd həmin məlumatın hansı biznes qərarını yaxşılaşdırdığını müəyyənləşdirməkdir.

Customer 360: vahid müştəri baxışı

Customer 360 konsepsiyası müştərinin müxtəlif sistemlərdəki məlumatlarının məqsədəuyğun şəkildə birləşdirilərək vahid biznes baxışının yaradılmasını nəzərdə tutur.

Bank nümunəsində bu, müştərinin müraciətlərini, xidmətlərdən istifadə tarixçəsini, dəstəklə əlaqələrini və müvafiq maliyyə məhsulları ilə qarşılıqlı münasibətini əlaqələndirməyə kömək edə bilər.

Lakin Customer 360 bütün məlumatların hər bir sistemə ötürülməsi və hər bir əməkdaş üçün əlçatan olması demək deyil. Məlumatların məqsəd üzrə istifadəsi, giriş səlahiyyətləri, məxfilik və saxlanma qaydaları qorunmalıdır.

Eyni yanaşma marketinq proseslərinə də aiddir. Məsələn, kredit müraciətinin rədd edilməsi avtomatik olaraq müştəriyə depozit məhsulunun təklif edilməsini əsaslandırmır. Belə kommunikasiya yalnız müvafiq hüquqi əsas, müştərinin seçimləri, kommunikasiya icazələri və təşkilatın ədalətli məhsul təklifləri qaydaları çərçivəsində nəzərdən keçirilməlidir.

Senior analitikin fərqi budur ki, o, biznes imkanını görməklə yanaşı, həmin imkanın hansı risklər və şərtlər altında reallaşa biləcəyini də qiymətləndirir.

DWH, BI və biznes göstəriciləri

Sistem daxilində baş verən hadisələr biznesin inkişafı üçün faydalı analitik məlumat yarada bilər.

Məsələn, kredit müraciəti prosesinin müxtəlif mərhələlərini təhlil edərək aşağıdakı göstəriciləri müəyyənləşdirmək mümkündür:

• Müraciətin başlanmasından tamamlanmasına qədər olan çevrilmə göstəricisi (conversion rate).
• İstifadəçilərin prosesi yarımçıq saxladığı mərhələlər (drop-off).
• Müraciətin qəbulundan qərarın formalaşmasına qədər keçən müddət.
• Texniki xətaların müraciətlərin tamamlanmasına təsiri.
• Avtomatik emal və əlavə yoxlama tələb edən müraciətlərin nisbəti.
• Müxtəlif qərar mərhələlərinin keyfiyyəti və əməliyyat xərcləri.

Bu məlumatlar Data Warehouse (DWH) və Business Intelligence (BI) həlləri vasitəsilə rəhbərliyin qərarlarına dəstək verə bilər.

Ancaq analitik göstəricinin sadəcə hesablana bilməsini deyil, düzgün şərh olunmasını da təmin etməlidir. Məsələn, kredit təsdiqi faizinin yüksəlməsi özü-özlüyündə uğur göstəricisi deyil; risk, portfel keyfiyyəti, müştəri ehtiyacı və digər meyarlar da nəzərə alınmalıdır.

Dördüncü təbəqənin nəticəsi: analitik funksionallığın yalnız texniki nəticəsini deyil, digər sistemlərə, müştəri təcrübəsinə və təşkilatın biznes göstəricilərinə təsirini də görür.

II. Praktiki nümunə: mobil tətbiqdə kredit müraciəti

İndi bu modeli konkret ssenari üzərində tətbiq edək.

Ssenari: Bankın mobil tətbiqində müştəri FİN kodunu, doğum tarixini, istədiyi kredit məbləğini və müddətini daxil edir. Sistem müraciəti emal etməli, kreditə uyğunluq şərtlərini yoxlamalı və müvafiq nəticəni istifadəçiyə təqdim etməlidir.

Bu nümunədə göstərilən məbləğlər və qaydalar yalnız illüstrativdir. Real bank məhsulunda onlar təsdiqlənmiş biznes siyasətinə əsaslanmalıdır.

Birinci təbəqə: istifadəçi və interfeys

Bu təbəqədə analitik istifadəçi ssenarisini və giriş məlumatlarının yoxlanılması qaydalarını müəyyənləşdirir.

• FİN sahəsinin formatı və uzunluğu yoxlanılır.
• Məcburi sahələr boş saxlanıldıqda istifadəçiyə məlumat verilir.
• Məbləğ və müddət sahələri məhsulun müəyyən edilmiş diapazonuna uyğun yoxlanılır.
• Yanlış məlumat daxil edildikdə aydın xəta mesajı göstərilir.
• Müraciət göndərildikdə istifadəçi prosesin başladığını görür.
• Əlaqə kəsildikdə istifadəçi nəticənin naməlum qaldığını başa düşə və statusu sonradan yoxlaya bilir.

Yaş və məbləğ kimi ilkin yoxlamalar istifadəçi interfeysində aparıla bilər. Lakin yekun uyğunluq qərarı yalnız bu yoxlamalara əsaslana bilməz. Kritik qaydalar server tərəfində də tətbiq edilməli, şəxsiyyət məlumatları isə etibarlı mənbələrə əsasən yoxlanılmalıdır.

İkinci təbəqə: biznes qaydaları və asinxron emal

Analitik müəyyən edir ki, müraciətin emalı bir neçə xarici və daxili sistemdən cavab alınmasını tələb edə bilər. Bu halda asinxron model məqsədəuyğun seçim ola bilər.

Mümkün proses belədir:

1. Mobil tətbiq kredit müraciətini API-yə göndərir.
2. Sistem əsas validasiyaları aparır, müraciətə unikal identifikator verir və onun ilkin statusunu qeydə alır.
3. Müraciət emala qəbul edildikdə API 202 Accepted cavabı qaytara bilər. Bu cavab kreditin təsdiqləndiyini deyil, müraciətin emal üçün qəbul edildiyini bildirir.
4. Cavabla birlikdə applicationId və statusu yoxlamaq üçün resurs ünvanı təqdim olunur.
5. Sistem uyğun hadisəni brokerə ötürür və skorinq prosesi başlayır.
6. Müvafiq servislər lazımi yoxlamaları aparır.
7. Nəticə formalaşdıqda müraciətin statusu yenilənir və istifadəçi məlumatlandırılır.

202 Accepted cavabının standart mənası RFC 9110 sənədində müəyyən edilir: sorğu emala qəbul olunub, lakin emalın tamamlanması hələ təmin edilməyib.

Analitik burada əlavə qərarlar da verməlidir: müraciət hansı statuslardan keçə bilər, statuslar arasında hansı keçidlərə icazə verilir, eyni müraciət təkrar göndərilərsə nə baş verir və skorinq servisi cavab vermədikdə proses necə idarə olunur?

Əgər Kafka istifadə edilirsə, hadisələr uyğun topic-də yayımlana bilər. RabbitMQ isə konkret mesaj marşrutlaşdırma ehtiyaclarına uyğun alternativ və ya mövcud arxitekturanın bir hissəsi ola bilər. Hər iki texnologiyanın birlikdə tətbiqi yalnız əsaslandırılmış tələb olduqda nəzərdən keçirilməlidir.

İstifadəçi interfeysinin yenilənməsi üçün WebSocket, server-sent events (SSE) və ya müəyyən intervallarla status sorğusu göndərmək (polling) kimi variantlar müqayisə oluna bilər. Seçim real vaxt ehtiyacı, bağlantı imkanları və sistemin mürəkkəbliyindən asılıdır.

Üçüncü təbəqə: məlumatların bütövlüyü, audit və dayanıqlılıq

Bu təbəqədə analitik artıq yalnız normal ssenarini deyil, xətalı ssenariləri də modelləşdirir.

Məlumatların saxlanılması: müraciət, onun status tarixçəsi və rəsmi maliyyə əməliyyatları üçün məlumatların bütövlüyü tələbləri müəyyən edilir. Əlaqəli verilənlər bazası uyğun seçim ola bilər, lakin konkret qərar arxitektura komandasının iştirakı ilə verilməlidir.

Təkrar emal: eyni hadisə iki dəfə çatdırılarsa, kredit müraciəti və ya maliyyə əməliyyatı ikinci dəfə yaradılmamalıdır. Bu davranış müvafiq identifikatorlar və idempotent emal qaydaları ilə təmin edilməlidir.

İnteqrasiya xətaları: kredit bürosu cavab vermirsə, sistem müraciəti avtomatik rədd etməli, gözləməyə almalı, yoxsa alternativ prosesə keçirməlidir? Bu qərar texniki xəta ilə biznes qərarını fərqləndirən qaydalara əsaslanmalıdır.

Audit: müraciət statusunun dəyişdirilməsi, qərarın yaranması və istifadəçinin həyata keçirdiyi müvafiq əməliyyatlar sonradan araşdırıla biləcək şəkildə qeydə alınmalıdır.

Məxfilik: FİN, gəlir və digər həssas məlumatlar texniki loglarda lazımsız şəkildə saxlanılmamalıdır. Logların tərkibi, giriş səlahiyyətləri və saxlanma müddəti müvafiq hüquqi və təhlükəsizlik tələblərinə əsaslanmalıdır.

Müşahidəolunma: sistem müraciətin qəbulundan yekun cavaba qədər keçdiyi mərhələləri izləməyə imkan verməlidir. Bunun üçün status tarixçəsi, korrelyasiya identifikatorları, loglar, metriklər və izlərdən istifadə oluna bilər.

Beləliklə, BA texniki mexanizmlərin kodunu yazmasa da, sistemin real iş şəraitində etibarlı və yoxlanıla bilən olmasına xidmət edən tələbləri müəyyən edir.

Dördüncü təbəqə: ekosistem və biznes nəticələri

Senior analitik kredit müraciətinin nəticəsinə yalnız bir ekran mesajı kimi baxmır.

O, prosesin digər sistemlərə və biznes göstəricilərinə təsirini də qiymətləndirir.

• Müraciətin yekun statusu CRM və digər əlaqəli sistemlərdə əks etdirilir.
• Müvafiq hadisələr analitik platformaya ötürülür.
• Müraciətlərin gecikməsi və yarımçıq qalması ölçülür.
• Müştəriyə göndərilən bildirişlər onun seçimlərinə və kommunikasiya icazələrinə uyğun müəyyən edilir.
• Uyğun alternativ məhsullar yalnız müvafiq biznes siyasətləri və hüquqi şərtlər daxilində təklif oluna bilər.
• Rəhbərlik prosesin effektivliyi, xidmət səviyyəsi və risk göstəriciləri barədə məlumat əldə edir.

Kredit müraciətinin rədd edilməsi də biznes baxımından mühüm nəticədir. Lakin bu nəticə avtomatik marketinq kampaniyasına çevrilməməlidir. Müştəriyə hansı məlumatın nə vaxt və hansı əsasla təqdim ediləcəyi ayrıca biznes qaydasıdır.

Bu mərhələdə analitikin əsas bacarığı sistemlər arasında mümkün əlaqələri müəyyənləşdirmək, hər bir əlaqənin məqsədini izah etmək və biznes faydasını risklərlə birlikdə qiymətləndirməkdir.

III. Analitik yetkinliyin ölçülməsi: dörd təbəqə, dörd düşüncə miqyası

Yuxarıdakı model peşəkar inkişafı müzakirə etmək üçün faydalı çərçivə yaradır. Bununla belə, təbəqələri sərt şəkildə vəzifə adlarına bağlamaq düzgün olmazdı.

Junior analitik də müəyyən inteqrasiyanın texniki detallarını dərindən başa düşə bilər. Senior analitik isə bütün texnologiyaların mütəxəssisi olmaya bilər. Fərq onun qeyri-müəyyənliyi necə idarə etməsində, düzgün sualları verməsində, qərarların nəticələrini görməsində və müxtəlif mütəxəssislərlə effektiv işləməsində ortaya çıxır.

Bu çərçivədə inkişafı dörd istiqamətdə təsvir etmək mümkündür.

1. İcra səviyyəsində düşüncə — What?

Analitik funksionallığın nə etməli olduğunu, istifadəçinin hansı addımları atacağını və sistemdən hansı nəticəni gözlədiyini dəqiqləşdirir.

2. Proses və davranış səviyyəsində düşüncə — How?

Analitik biznes qaydalarını, sistemlərarası müqavilələri, məlumat axınlarını, istisnaları və prosesin alternativ gedişatlarını müəyyən edir.

3. Etibarlılıq və risk səviyyəsində düşüncə — What if?

Analitik sistemin dayanması, təkrar sorğular, məlumat uyğunsuzluğu, məxfilik pozuntusu və digər risklər zamanı nə baş verəcəyini araşdırır.

4. Ekosistem və nəticə səviyyəsində düşüncə — Why and what next?

Analitik funksionallığın təşkilatın digər sistemlərinə, biznes göstəricilərinə, müştəri təcrübəsinə və gələcək inkişaf imkanlarına təsirini qiymətləndirir.

Bu inkişaf xətti yalnız texniki biliklərin artması deyil. Eyni zamanda analitikin düşüncə miqyasının genişlənməsidir: bir tələbdən başlayaraq onun təsir etdiyi proseslərə, sistemlərə və biznes nəticələrinə doğru hərəkət.

IV. Senior BA hansı sualları verməlidir?

Analitik yetkinliyi müəyyənləşdirməyin ən praktik yollarından biri verilən suallara deyil, analitikin özü tərəfindən ortaya qoyulan suallara baxmaqdır.

Bu sualların hər birinə bütün layihələrdə eyni dərinlikdə cavab vermək lazım deyil. Analitikin yetkinliyi həmçinin riskə uyğun analiz dərinliyini seçmək bacarığında görünür.

Sadə bir məlumat ekranı ilə pul köçürməsini, dövlət məlumatlarının mübadiləsini və ya hüquqi nəticə yaradan əməliyyatı eyni analiz yanaşması ilə idarə etmək olmaz.

Senior yanaşma bütün detalları hər zaman ən yüksək dərinlikdə araşdırmaq deyil; hansı detalın nə qədər dərindən araşdırılmalı olduğunu düzgün müəyyən etməkdir.

V. Analitikdən gözlənilən nəticə sənədlərin sayı deyil

Bəzən BA-nın məhsuldarlığı hazırladığı sənədlərin, çəkdiyi diaqramların və ya yazdığı user story-lərin sayı ilə ölçülür. Halbuki sənədləşdirmə məqsəd deyil, anlaşmanı və düzgün icranı təmin edən vasitədir.

Dərin analiz nəticəsində ən azı aşağıdakı suallar cavablandırılmalıdır:

• Biznes problemi və gözlənilən fayda aydındırmı?
• Əsas və alternativ proseslər müəyyənləşdirilibmi?
• Biznes qaydaları və istisnalar razılaşdırılıbmı?
• Sistemlərarası API və hadisə müqavilələri aydındırmı?
• Məlumatın mənbəyi, sahibi və istifadə məqsədi müəyyən edilibmi?
• Təhlükəsizlik, məxfilik və audit tələbləri nəzərə alınıbmı?
• Uğursuz ssenarilər və bərpa mexanizmləri təhlil edilibmi?
• Qəbul meyarları test edilə bilən formada yazılıbmı?
• Funksionallığın biznes təsirini ölçmək üçün göstəricilər varmı?
• Tələblərin gələcək dəyişikliklərə təsiri başa düşülürmü?

Bu suallara verilən cavablar komandanın hazırlıq səviyyəsini daha yaxşı əks etdirir.

Eyni zamanda, Senior BA arxitektorun, developer-in, QA mütəxəssisinin və ya informasiya təhlükəsizliyi komandasının məsuliyyətini öz üzərinə götürmür. O, həmin rolların biliklərini birləşdirən biznes və sistem tələblərini formalaşdırır, qərarların razılaşdırılmasına kömək edir və həllin gözlənilən biznes ehtiyacını ödəməsini təmin edir.

Nəticə: Seniorluq görmə bucağının genişliyidir

İstifadəçi mobil tətbiqdə bir düyməyə basır. Bu, onun üçün sadəcə bir hərəkətdir.

Junior analitik bu hərəkətin düzgün işləməsini və istifadəçinin gözlədiyi nəticəni almasını təmin etməyə fokuslanır.

Daha təcrübəli analitik həmin hərəkətin arxasındakı biznes qaydalarını, API müqavilələrini, məlumat axınlarını və alternativ ssenariləri təhlil edir.

Dərin sistem düşüncəsinə sahib analitik isə bununla kifayətlənmir. O, əməliyyatın təkrar icrasını, məlumatların bütövlüyünü, servislərin dayanmasını, audit izlərini, məxfilik risklərini, digər sistemlərə təsirləri və biznes nəticələrini də nəzərə alır.

Bütün bu təbəqələr bir-birindən ayrı deyil. Onlar eyni problemin fərqli ölçüləridir.

Biznes analitikinin kod yazması və ya Kafka klasterini konfiqurasiya etməsi vacib şərt deyil. Vacib olan odur ki, o, hansı problemin həll edildiyini, seçilən yanaşmanın niyə uyğun olduğunu, hansı riskləri yaratdığını və sistemin bütövlükdə necə işləyəcəyini başa düşsün.

Buna görə də peşəkar yetkinliyin ölçülməsi zamanı yalnız “Neçə illik təcrübəniz var?” sualını vermək kifayət deyil.

Daha əhəmiyyətli sual budur:

“Sizə verilmiş bir tələbin arxasında hansı biznes qaydalarını, texnoloji asılılıqları, məlumat risklərini və ekosistem təsirlərini görə bilirsiniz?”

Çünki rəqəmsal arxitekturada həqiqi analitik dəyər təkcə tələbi düzgün yazmaqda deyil, həmin tələbin bütöv sistem üçün nə ifadə etdiyini anlamaqdadır.

Təcrübə illərlə toplanır. Dərinlik isə düzgün suallar verməklə, əlaqələri görməklə və qərarların nəticələrini anlamaqla formalaşır.

Və çox vaxt Junior ilə Senior arasındakı ən mühüm fərq məhz budur.