Data governance hər data aktivinin sahibinin kim olduğunu, onun nə demək olduğunu, haradan gəldiyini və kimin istifadə edə biləcəyini müəyyən edən əməliyyat modelidir. O, siyasət sənədi, departament və ya proqram təminatı alışı deyil — hərçənd işləyən proqram hər üçünü istehsal edir.

Tərif ona görə vacibdir ki, uğursuzluq nümunəsi həmişə eynidir. Təşkilat idarəetmə arxitekturası yazır, komitə təyin edir, kataloq alır — və iki ildən sonra hələ də dörd müştəri cədvəlindən hansının səlahiyyətli olduğunu deyə bilmir. Bütün artefaktlar yerindədir. Əməliyyat modeli isə yoxdur.

Təşkilatınızda idarəetmənin mövcud olub-olmadığını yoxlamağın ən sadə yolu: ən vacib on data aktivini götürün və hər biri üçün soruşun — kim cavabdehdir, nə deməkdir, haradan gəlib, kim istifadə edə bilər. Cavablar üçün iclas lazımdırsa, sizdə proqram yox, arxitektura var.

İşləyən proqramın cavab verdiyi dörd sual

Dövriyyədə olan hər idarəetmə arxitekturası — DAMA-DMBOK, DCAM, müxtəlif vendor modelləri — eyni dörd sualın bu və ya digər düzülüşünə parçalanır. Düzülüşlər fərqlənir, suallar yox.

Sahibi kimdir? Departament yox, adı olan konkret insan. "Bu düzgündürmü?" sualını verə biləcəyiniz və cavaba görə cavabdeh olan adam. Komandaya verilmiş sahiblik heç kimə verilməmiş sahiblikdir — sahib kimi departament yazan inventarların heç bir müşahidə olunan davranış dəyişikliyi yaratmamasının səbəbi budur.

Nə deməkdir? Aktiv müştəri üçün risk, marketinq və tənzimləyici hesabatlığın eyni cür işlətdiyi bir tərif. Hər biri öz yerində əsaslandırıla bilən üç tərif yox. Bu, biznes lüğətidir və idarəetmənin texniki məşğuliyyət olmaqdan çıxdığı yer məhz buradır.

Haradan gəlib? Mənbə sistemindən hesabatdakı rəqəmə qədər tam yol, sütun-sütun. Bu, data lineage-dir və tənzimlənən institutda bütün proqramın ən müdafiə oluna bilən qazancıdır.

Kim və nə üçün istifadə edə bilər? Datanın həssaslığına bağlanmış giriş qaydaları — 2019-cu ildə kiminsə açdığı tiketə yox. Bu, təsnifat tələb edir, təsnifat isə hər sütunun içində nə olduğunu bilməyi — yəni təhlükəsizlik problemindən əvvəl kataloq problemidir.

Arxitekturanın faydalı forması

Arxitekturalar adətən piramida və ya on iki bölməli çarx kimi çəkilir. Həqiqətən mövcud olmalı olan şey daha dardır və hər biri altındakından asılı olan beş qat kimi təsvir edilə bilər.

İnventar. Hansı sistemlər var, içində nə var, onlara kim toxunur. Bu qatdan yuxarıda heç nə mümkün deyil, və proqramların məhz bu qatı atlamasının səbəbi onun cazibədar olmaması və insanlarla danışmağı tələb etməsidir. Hansı datanın mövcud olduğunu heç kim bilmədən yazılmış idarəetmə siyasəti xəyali təşkilat haqqında sənəddir.

Metadata. Hər aktiv haqqında texniki, biznes və əməliyyat faktları — sxemlər, təriflər, sahiblər, təzəlik, istifadə. Mümkün olan hər yerdə avtomatik toplanır. Üç növün nə olduğu və onları qarışdırmağın niyə problem yaratdığı metadata idarəetməsi yazısındadır.

Semantika. Fiziki sütunlara bağlanmış razılaşdırılmış təriflər. Lüğət qatı. İki departamentin illərdir eyni sözü fərqli işlətdiyini kəşf etdiyi və kiminsə qərar verməli olduğu yer buradır.

Nəzarət. Təsnifat, giriş qaydaları, keyfiyyət qaydaları, saxlama müddətləri. Sənədlərdə təsvir edilən yox, sistemlər tərəfindən tətbiq olunan siyasətlər. Yalnız siyasət PDF-ində mövcud olan qayda tövsiyədir.

Cavabdehlik. Adı olan sahiblər, real vaxt ayrılmış steward-lar, mübahisəni həll etmək səlahiyyəti olan forum və eskalasiya yolu. Digər dörd qatı davranışa çevirən qat budur.

Uğursuz olan proqramlar adətən dördüncü və beşinci qatı birinci qurur, çünki idarəetməyə oxşayan onlardır. Birinci və ikinci qat isə onları həqiqətə çevirən şeydir.

Rollar və hər birinin əslində nə etdiyi

Vəzifə adları təşkilatdan təşkilata dəyişir. Funksiyalar dəyişmir və əhəmiyyət daşıyan yalnız dörddür.

Data owner bir data sahəsinə — müştəri, məhsul, maliyyə — görə cavabdehdir. Adətən texnoloq deyil, yüksək səviyyəli biznes adamıdır. Datanın nə demək olduğuna, kimin istifadə edə biləcəyinə və hansı keyfiyyət səviyyəsinin tələb olunduğuna o qərar verir. Adı aktivin yanında görünür və ona görə cavab verir. Rol tam ştatlı deyil və heç vaxt elə təqdim edilməməlidir.

Data steward gündəlik işi görür: tərifləri saxlayır, keyfiyyət problemlərini həll edir, sahə haqqında suallara cavab verir, kataloqu dürüst saxlayır. Proqramın canlı olub-olmadığını məhz bu rol müəyyən edir. Ona həftədə təxminən iki saat, tərif mübahisəsini həll etmək səlahiyyəti və bunu iş saatından sonra görülən iş yox, real iş sayan rəhbər lazımdır.

Data custodian texniki roldur — DBA, platforma mühəndisi — datanı saxlayan sistemlərə cavabdehdir və owner-in müəyyən etdiyi nəzarətləri tətbiq edir. Custodian siyasət qərarı vermir, onu icra edir. Custodian-ı owner ilə qarışdırmaq ən çox rast gəlinən struktur səhvidir və "idarəetmə İT layihəsidir" uğursuzluğunu yaradır.

Governance lead proqramı aparır: əhatə, ardıcıllıq, forum, rəhbərliyə hesabat. Bir nəfər, komitə yox. Onun işi qərar vermək deyil — qərarların verilməsini təmin etməkdir.

Bunların üstündə idarəetmə forumu dayanır — altı-səkkiz nəfər, iki həftədə bir toplanan, mübahisəni həll etmək səlahiyyəti olan. Rüblük toplanıb hər şeyi yuxarı ötürən iyirmi nəfərlik komitə yox — o struktur qərar əvəzinə protokol istehsal edir.

Bütün mexanizm qərar hüquqlarındadır

Yuxarıdakıların hamısı bir şey olmadan cansızdır: kimsə mübahisəni bitirə bilməlidir.

Xarakterik idarəetmə tıxacı budur — eyni terminin bir-birinə zidd, amma hər ikisi əsaslandırıla bilən təriflərinə sahib iki departament, hər birinin öz biznes əsası var, heç birinin digərini ləğv etmək səlahiyyəti yoxdur. Adı olan qərarverici və sənədləşdirilmiş proses olmadan bu, illərlə həll olunmamış qalır və təşkilat səssizcə hər iki tərifi paralel saxlayır — idarəetmənin düzəltməli olduğu vəziyyət isə elə budur.

Qərar hüquqlarını real edən üç şey var. Birincisi, qərarverici hər sahə üçün əvvəlcədən adla təyin olunur — mübahisə gələndən sonra seçilmir. İkincisi, prosesin son tarixi var: foruma çatan tərif mübahisəsi həmin iclasda həll olunur və ya eskalasiya edilir, heç vaxt sonraya keçirilmir. Üçüncüsü, hər qərar əsaslandırması ilə birlikdə jurnala yazılır, çünki eyni mübahisə on səkkiz aydan sonra yeni adamlarla qayıdacaq və onun sıfırdan yenidən açılmasının qarşısını alan yeganə şey həmin jurnaldır.

Qərar jurnalını aparmaq ucuzdur və governance lead-lərin "kaş daha tez başlayaydım" dediyi artefakt həmişə odur.

Proqramın real olub-olmadığını necə bilmək olar

İdarəetmə metrikləri mənasızlığa meyllidir: kataloqlaşdırılmış aktivlərin sayı, müəyyən edilmiş terminlərin sayı, təsnif edilmiş sütunların faizi. Bunların hamısını Excel-i olan bir təcrübəçi maksimuma çatdıra bilər və heç biri nəyinsə dəyişdiyini göstərmir.

İzlənməyə dəyən ölçülər davranış ölçüləridir.

İnsanlar qurmazdan əvvəl kataloqa baxırmı? Axtarış həcmi və unikal istifadəçi sayı, zaman üzrə izlənən. Heç kimin açmadığı dolu kataloq — daha bahalı cədvəldir.

Tərif mübahisəsi nə qədər vaxta həll olunur? Qaldırılandan jurnala yazılana qədər. Bu göstərici artırsa, forum səlahiyyətini itirib.

Tənzimləyici rəqəmi hazırlıqsız, tələb olunan anda uçdan-uca izləyə bilirsinizmi? Nəzarət altındakı institutda ən vacib test budur və cavabı ikilidir.

Bu rübdə neçə təkrar iş oldu? İki komandanın eyni metriki müstəqil qurması — idarəetmənin olmamasının birbaşa xərcidir və sayıla bilər.

Kritik aktivlərin neçə faizinin son doxsan gündə sualı cavablandırmış adlı sahibi var? Heç vaxt istifadə olunmamış sahiblik kağız üzərindəki sahiblikdir.

İdarəetmə təşkilati olaraq harada oturmalıdır

Təkrarlanan struktur sualı, və onun müdafiə oluna bilən cavabı var.

Tamamilə İT-nin içində yerləşən idarəetmə proqnozlaşdırıla bilən şəkildə uğursuz olur: tərifləri onları verməyə biznes konteksti çatmayan adamlar verir, biznes nəticəni saymır, proqram səssizcə sönür. İT kataloqu tətbiq edə bilər. Aktiv müştərinin nə demək olduğuna qərar verə bilməz.

Tamamilə biznes funksiyasının içində — adətən risk və ya uyğunluq — yerləşən idarəetmə yaxşı siyasət və heç bir tətbiq istehsal edir, çünki metadata toplama və lineage qurmaq kimi texniki iş heç vaxt çatdırılma backlog-una qarşı prioritetləşdirilmir.

İşləyən quruluş budur: biznesə məxsus funksiya plus ayrılmış texniki dəstək — governance lead biznesə hesabat verir (çox vaxt CFO, COO və ya CRO), steward-lar biznes adamlarıdır, kiçik daimi texniki komanda isə platformaya və toplamaya sahiblik edir. Hesabat xətti təriflərin sahibliyindən az əhəmiyyət daşıyır, təriflərin sahibliyi isə mütləq onları işlədən adamlarda olmalıdır.

AI ilə əlaqə

Son üç ildə idarəetmənin biznes əsaslandırması dəyişib və bunun səbəbini açıq demək lazımdır.

On il boyunca əksər təşkilatda idarəetmə uyğunluq məşğuliyyəti idi. Sonra təşkilatlar öz datalarının üstünə dil modelləri qoymağa başladılar. McKinsey-in 2026 üçün State of AI araşdırması göstərir ki, təşkilatların 88%-i ən azı bir biznes funksiyasında AI-dan müntəzəm istifadə edir, lakin yalnız 39%-i müəssisə səviyyəsində hər hansı EBIT təsiri bildirir; Gartner isə agentic AI layihələrinin 40%-dən çoxunun 2027-ci ilin sonuna qədər ləğv ediləcəyini gözləyir — xərclər, aydın olmayan dəyər və yetərsiz risk nəzarəti səbəbindən.

Mənimsəmə ilə təsir arasındakı bu boşluq əksər institutda idarəetmə boşluğudur. İdarə olunmayan dataya yönəldilmiş axtarış sistemi əminliklə səhv cavablar qaytarır və layihə rəfə qoyulur. AI sistemi oxuduğu datadan daha etibarlı ola bilməz və altındakı aktivlərdən daha sıx idarə oluna bilməz. Bu arqument indi yalnız uyğunluq arqumentinin maliyyələşdirə bilmədiyi proqramları maliyyələşdirir.

Modelin öz tərəfindəki müvafiq intizam AI governance-dir — əlaqəli, lakin ayrı problem.

Əsas məqamlar

  • Data governance siyasət qovluğu deyil, əməliyyat modelidir. Test arxitektura sənədinin mövcudluğu deyil — on adlı aktivin sahibi, tərifi, lineage-i və giriş qaydaları var, ya yox.
  • Aşağıdan yuxarı beş qat: inventar, metadata, semantika, nəzarət, cavabdehlik. Uğursuz olan proqramlar yuxarıdakı ikini birinci qurur.
  • Dörd rol: owner (cavabdeh, biznes), steward (gündəlik iş, biznes), custodian (texniki icra), lead (proqramı aparır). Custodian-ı owner ilə qarışdırmaq "İT layihəsi" uğursuzluğunu yaradır.
  • Mexanizm qərar hüquqlarıdır. Adlı qərarverici, son tarix və qərar jurnalı eyni mübahisənin illərlə təkrarlanmasının qarşısını alan şeydir.
  • Sətir sayını yox, davranışı ölçün: kataloq istifadəsi, mübahisənin həll müddəti, tənzimləyici rəqəmi tələb anında izləmə bacarığı.
  • AI əsaslandırması artıq uyğunluq əsaslandırmasından güclüdür, çünki AI-ı pilot ilə istehsalat arasında saxlayan şey idarə olunmayan datadır.

Tənzimlənən təşkilatlarda idarəetmə proqramlarının platforma qatı olaraq OvalEdge tətbiq edirik. Ardıcıllıq üçün data governance proqramının qurulması, yerli tənzimləyici mənzərə üçün isə Azərbaycanda data idarəetməsi yazısına baxın.