Bakıda sənəd idarəetmə proqramının hazırlanması yalnız faylları bir qovluqda toplamaq demək deyil. Məqsəd hər sənəd üçün etibarlı mənbə yaratmaqdır: hansı nüsxə qüvvədədir, kim sahibidir, kim baxa və ya dəyişə bilər, hansı təsdiq mərhələsindədir, hansı qərar verilib və sənəd nə vaxta qədər saxlanmalıdır.
Bu ehtiyac adətən eyni müqavilənin e-poçtda, shared drive-da və WhatsApp-da müxtəlif versiyalarının dövr etməsi ilə başlayır. Problemi sadəcə daha çox qovluq və ya yeni bulud yaddaşı ilə həll etmək mümkün olmur. Təşkilata sənədin özü ilə yanaşı onun biznes kontekstini — kontrakt, təchizatçı, layihə, filial, məsul şəxs, status, təsdiq və saxlanma qaydasını — idarə edən veb platforma lazımdır.
Sənəd platforması nəyi həll etməlidir?
Fərdi sistem aşağıdakı suallara bir ekran və yoxlanıla bilən tarixçə ilə cavab verməlidir:
- Bu sənədin hazırkı rəsmi versiyası hansıdır?
- Sənədin biznes sahibi və proses üzrə məsul şəxsi kimdir?
- Kim oxuya, yükləyə, paylaşa, redaktə edə və ya təsdiqləyə bilər?
- Təsdiq kimdə gözləyir və gecikmə nə vaxt yaranıb?
- Əvvəlki versiyada nə dəyişib, kim dəyişib və səbəb nə olub?
- Müqavilənin bitməsi, lisenziyanın yenilənməsi və ya arxiv müddətinin çatması üçün hansı xəbərdarlıq verilməlidir?
Bu yanaşma klassik fayl anbarından fərqlidir. Fayl anbarı sənədi saxlayır; sənəd idarəetmə sistemi isə sənədin həyat dövrünü idarə edir. Belə platforma adətən veb platformaların hazırlanması xidməti çərçivəsində layihələndirilir: informasiya arxitekturası, istifadəçi rolları, iş axınları, inteqrasiya sərhədləri və təhlükəsizlik tələbləri birlikdə müəyyən olunur.
Hansı sənədlər üçün istifadə olunur?
Platforma bütün faylları eyni qaydada idarə etməməlidir. Sənəd növləri fərqli metadata, giriş və təsdiq qaydaları tələb edir. Məsələn:
- müqavilələr, əlavələr, məxfilik sazişləri və hüquqi rəylər;
- satınalma sorğuları, kommersiya təklifləri, sifarişlər və təhvil-təslim aktları;
- korporativ siyasətlər, prosedurlar, təlimatlar və forma şablonları;
- texniki spesifikasiyalar, layihə sənədləri, keyfiyyət sertifikatları və uyğunluq materialları;
- idarəetmə qərarları, protokollar, səlahiyyət sənədləri və daxili yazışmalar.
Məsələn, müqavilə kartında qarşı tərəf, müqavilə nömrəsi, qüvvəyə minmə və bitmə tarixləri, məbləğ, hüquqi şəxs, məsul şəxs, status və əlaqəli ERP sifarişi saxlanıla bilər. Daxili prosedur üçün isə şöbə, sənəd sahibi, qüvvəyə minmə tarixi, növbəti nəzərdən keçirmə tarixi və oxunma təsdiqi daha vacibdir.
Metadata: axtarışı və konteksti fayl adından ayırın
“Final_v7_son_yeni.pdf” kimi fayl adları prosesin etibarlı modeli deyil. Sistem sənəd növünə görə strukturlaşdırılmış sahələr təqdim etməlidir. Məcburi və seçimli sahələr ayrıca təyin olunur, siyahı dəyərləri idarə edilir və eyni məlumatın müxtəlif formada yazılması azaldılır.
Yaxşı sənəd kartı üçün minimum sahələr
- unikal sənəd ID-si və sənəd növü;
- başlıq, biznes sahibi, yaradıcı və məsul şöbə;
- müştəri, təchizatçı, layihə, filial və ya müqavilə ilə əlaqə;
- məxfilik səviyyəsi və giriş qrupu;
- həyat dövrü statusu;
- qüvvəyə minmə, bitmə, nəzərdən keçirmə və saxlanma tarixləri;
- axtarılan etiketlər və əlaqəli sənədlər.
Metadata yalnız filtr üçün deyil. O, xəbərdarlıqların, avtomatik marşrutlaşdırmanın, hesabatların və ERP/CRM linklərinin əsasını yaradır. UX mərhələsində bu sahələri formaya yığmaq yox, istifadəçinin qərar verdiyi anda lazım olan məlumatı göstərmək vacibdir. Bu səbəbdən UI/UX və məhsul dizaynı sənəd layihəsinin erkən mərhələsində dəyər yaradır.
Versiya nəzarəti: “son fayl” əvəzinə idarə olunan reviziya
Yeni fayl yüklənəndə sistem onu əvvəlki faylın üstünə səssiz yazmamalıdır. Hər dəyişiklik ayrıca versiya olmalıdır: versiya nömrəsi, yaradılma vaxtı, müəllif, dəyişiklik qeydi və mümkünsə müqayisə üçün təsvir saxlanılır. Təsdiqlənmiş versiya “qüvvədə” kimi işarələnir; əvvəlki versiyalar isə silinmədən köhnəlmiş statusuna keçir.
Praktik qayda budur: istifadəçilər adi rejimdə yalnız qüvvədə olan sənədi görür, səlahiyyətli şəxslər isə tarixçəni açır. Qaralama üzərində paralel iş tələb olunursa, check-in/check-out, redaktə kilidi və ya idarə olunan birgə redaktə qaydası seçilir. Sadə fayl yükləmə mexanizmi eyni sənədin iki ayrı “rəsmi” nüsxəsini yaratmamalıdır.
Təsdiq axını statusdan daha çoxdur
Document approval workflow software üçün “təsdiqləndi” düyməsi kifayət etmir. Axın sənəd növünə, məbləğə, risk səviyyəsinə, şöbəyə və ya hüquqi şəxsə görə dəyişə bilər. Tipik vəziyyətlər bunlardır: qaralama, yoxlamada, düzəliş tələb olunur, hüquqi baxışda, maliyyə baxışında, təsdiqləndi, dərc edildi, qüvvədən düşdü və arxivləndi.
Hər keçid üçün sistem kimə tapşırıq yaradıldığını, son tarixi, qərarı, şərhi və səlahiyyət əsasında verilən əvəzetmə qərarını qeyd etməlidir. Rədd edilən sənəd yeni versiya yaradılmadan “təsdiqlənmiş” vəziyyətinə qayıtmamalıdır. Məsələn, müqavilə mətni dəyişibsə, əvvəlki hüquqi təsdiq avtomatik olaraq yeni fayla tətbiq edilməməlidir.
Yaxşı iş axını təkcə sənədi bir nəfərdən digərinə göndərmir; qərarın hansı versiyaya, hansı səlahiyyətlə və hansı şərtlə verildiyini qoruyur.
Giriş hüquqları: rol, obyekt və əməliyyat səviyyəsində nəzarət
Təhlükəsiz biznes sənəd portalında “admin” və “user” rolları adətən yetərli deyil. Giriş modeli üç suala cavab verməlidir: istifadəçi hansı sənəd sinfinə daxil ola bilər, konkret hansı obyektə çıxışı var və həmin obyekt üzərində nə edə bilər?
- Rol əsaslı giriş: hüquqşünas, maliyyə mütəxəssisi, layihə meneceri, rəhbər, xarici tərəf.
- Obyekt səviyyəli giriş: yalnız öz layihəsi, filialı, müqaviləsi və ya təchizatçısı ilə bağlı sənədlər.
- Əməliyyat icazələri: baxmaq, yükləmək, çap etmək, redaktə etmək, yeni versiya yaratmaq, təsdiqləmək, paylaşmaq və silmək.
- Həssaslıq qaydaları: məxfi sənədlər üçün əlavə təsdiq, yükləmə qadağası, su nişanı və ya vaxtı bitən xarici keçid.
Giriş yoxlaması yalnız interfeysdə deyil, API və yükləmə endpoint-lərində də tətbiq olunmalıdır. Sessiya, autentifikasiya, səlahiyyət və audit dizaynı üçün ayrıca təhlükəsizlik yoxlaması layihənin vacib hissəsidir; buraya texniki dəstək və konsaltinq mərhələsində təhlükəsizlik, monitorinq və buraxılış prosesinin qiymətləndirilməsi də daxil edilə bilər.
Audit jurnalı və saxlanma qaydaları
Audit jurnalı fəaliyyət hesabatı deyil. O, sonradan araşdırıla bilən hadisə ardıcıllığıdır: sənədin yaradılması, görünməsi, yüklənməsi, versiya əlavə edilməsi, metadata dəyişikliyi, giriş icazəsinin verilməsi və ləğvi, təsdiq qərarı, paylaşım keçidinin yaradılması, arxiv və silinmə. Hadisədə actor, vaxt, obyekt ID-si, əməliyyat, əvvəlki və yeni status, mümkün olduqda isə səbəb saxlanmalıdır.
Audit qeydləri dəyişdirilə bilən biznes cədvəlindən ayrı qorunmalıdır. Həssas məzmun, parol, token və lazımsız şəxsi məlumat loglara yazılmamalıdır. NIST logların yaradılması, ötürülməsi, saxlanması, onlara giriş və utilizasiyasını vahid idarəetmə mövzusu kimi təsvir edir; OWASP isə tətbiq səviyyəsində təhlükəsizlik hadisələrinin qeydini, giriş məhdudiyyətini və log bütövlüyünün qorunmasını tövsiyə edir.
Saxlanma siyasəti isə “hər şeyi həmişəlik saxlayın” demək deyil. Hər sənəd kateqoriyası üçün saxlama müddəti, hüquqi və əməliyyat sahibi, arxiv davranışı, silinmənin təsdiqi və hüquqi mübahisə zamanı silinməni dayandıran hold mexanizmi aydınlaşdırılmalıdır. Qanuni müddətlər təşkilatın fəaliyyəti və yurisdiksiyasından asılı olduğuna görə, platforma qaydanı icra etməli, qaydanın özünü isə hüquq və uyğunluq komandası təsdiqləməlidir.
ERP və CRM inteqrasiyası: iki həqiqət mənbəyi yaratmayın
Sənəd sistemi ERP və CRM-i əvəz etməyə çalışmamalıdır. Məsələn, müştəri və satış imkanının sahibi CRM-də, sifariş və ödəniş statusu ERP-də, müqavilənin faylları və təsdiq tarixçəsi isə sənəd platformasında qala bilər. Sistemlər arasında sabit ID-lər, keçidlər, hadisələr və yalnız lazım olan metadata sinxronlaşdırılmalıdır.
İnteqrasiya dizaynında ilk sual “məlumatı necə köçürək?” deyil, “hansı sistem hansı məlumatın sahibi olaraq qalır?” olmalıdır. Bu, dublikat müştəri kartlarını, ziddiyyətli statusları və köhnəlmiş sənəd keçidlərini azaldır.
Miqrasiya sərhədi: hər köhnə faylı dərhal təmizləməyə çalışmayın
İlk buraxılışın məqsədi bütün tarixi diski mükəmməl kataloqlaşdırmaq deyil. Əvvəl aktiv müqavilələr, qüvvədə olan siyasətlər, açıq layihələr və tez-tez istifadə edilən sənəd növləri seçilir. Köhnə arxiv ayrıca read-only sahəyə indekslənə, sonradan mərhələli təmizlənə və ya yalnız sorğu əsasında miqrasiya edilə bilər.
Başlamazdan əvvəl qərar siyahısı
- Ən kritik 3–5 sənəd növünü və onların sahibini seçin.
- Hər növ üçün metadata, statuslar və təsdiq qaydasını yazın.
- Giriş matrisini: kim, hansı sənədə, hansı əməliyyat üçün daxil olur — təsdiqləyin.
- Qüvvədə olan versiya, arxiv və silinmə anlayışlarını fərqləndirin.
- ERP/CRM-də qalacaq sahələri və inteqrasiya hadisələrini müəyyən edin.
- Miqrasiya üçün aktiv məlumat sərhədini və köhnə arxiv qaydasını seçin.
POLADO bu tip platformanı hazır “drive” klonu kimi deyil, konkret sənəd növləri, qərar səlahiyyətləri və mövcud sistemlər ətrafında qurur. Əgər komandada son təsdiqli faylı, məsul şəxsi və qərar tarixçəsini tapmaq çətindirsə, veb platforma xidməti üzrə konsultasiya ilə proses xəritəsini, MVP sərhədini və təhlükəsizlik modelini birlikdə müəyyənləşdirmək mümkündür.