Bakıda təchizatçı portalının hazırlanması satınalma komandasının e-poçt, messencer və fərqli cədvəllərdə idarə etdiyi vendor məlumatlarını vahid, nəzarət olunan sistemə toplamaq deməkdir. Düzgün qurulan portal təchizatçı qeydiyyatı, uyğunluq sənədləri, sorğulara (RFQ) cavablar, təsdiq mərhələləri və satınalma sifarişi statusları üçün əməliyyat sisteminin mənbəyinə çevrilir.
Bu, müştərilərin sifariş, hesab-faktura və dəstək məlumatına baxdığı B2B müştəri portalından fərqlidir. Təchizatçı portalı şirkətə mal və ya xidmət təqdim edən tərəflərin kvalifikasiyası, komersiya təklifləri, müqaviləyə bağlı sənədləri və satınalma qərarları üzərində nəzarət yaradır. Buna görə əsas obyektlər “müştəri sifarişi” deyil, vendor profili, sənəd, RFQ, təklif, təsdiq və satınalma sifarişidir.
Portalın həll etməli olduğu əsas əməliyyat problemi
Bir çox şirkətdə yeni vendorun əlavə edilməsi e-poçtla göndərilən sənədlər, müxtəlif şöbələrdən gələn qeyri-rəsmi razılıqlar və sonradan tapılması çətin olan fayllarla başlayır. Nəticədə satınalma əməkdaşı vendorun aktiv olub-olmadığını, vergi və bank məlumatının hansı versiyasının təsdiqləndiyini və ya sertifikatın qüvvədə qalıb-qalmadığını ayrıca yoxlamalı olur.
Portal həmin prosesi vəziyyətləri dəqiq müəyyən edilmiş iş axınına çevirir: qaralama → təqdim edildi → ilkin yoxlama → düzəliş tələb olunur → təsdiqləndi və ya rədd edildi → aktiv / dayandırılmış. Hər status dəyişikliyi istifadəçi, vaxt, səbəb və mümkün olduqda əvvəlki/yeni dəyərlə saxlanmalıdır. Bu yanaşma “kim təsdiq verdi?” sualına şifahi cavab yox, axtarıla bilən audit qeydi verir.
Supplier onboarding: qeydiyyatdan aktivləşməyə qədər
Onboarding forması hər vendor üçün eyni uzunluqda olmamalıdır. Məsələn, avadanlıq təchizatçısı üçün keyfiyyət sertifikatları və çatdırılma imkanları vacib ola bilər; peşəkar xidmət göstərən şirkət üçün isə müqavilə məlumatı, məsul şəxs və məxfilik sənədləri daha önəmlidir. Portal kateqoriya, hüquqi şəxs növü, müqavilə dəyəri və ya risk səviyyəsinə görə dinamik suallar göstərə bilər.
Minimum vendor profili
- hüquqi və kommersiya adı, VÖEN və qeydiyyat məlumatları;
- kateqoriyalar, təqdim olunan məhsul və ya xidmətlər;
- əsas və alternativ əlaqə şəxsləri;
- ünvan, bank rekvizitləri və ödəniş üçün zəruri məlumatlar;
- tələb olunan sənədlər, sənəd statusu və bitmə tarixi;
- risk, bloklama və aktivlik statusu;
- qeydiyyat və sonrakı düzəlişlərin tarixçəsi.
Bank rekvizitinin dəyişdirilməsi kimi həssas dəyişikliklər adi profil redaktəsi olmamalıdır. Sistem dəyişiklik sorğusu yaratmalı, təsdiq edən şəxsi ayırmalı və əvvəlki dəyəri audit tarixçəsində qoruyub saxlamalıdır. Bu cür qaydalar üçün interfeys və status məntiqi əvvəlcədən hazırlanmalıdır; UI/UX və məhsul dizaynı mərhələsi formaların həddindən artıq uzun olmamasına, amma nəzarət tələblərinin itirilməməsinə kömək edir.
Sənəd və sertifikat müddətlərini idarə etmək
Supplier document management portal fayl anbarı ilə məhdudlaşmır. Hər sənəd növü üçün sahiblik, tələb olunma qaydası, versiya, verilmə tarixi, bitmə tarixi, yoxlama statusu və təsdiq qeydi olmalıdır. “Sənəd yüklənib” statusu “sənəd etibarlıdır” demək deyil.
Praktik qayda belədir: portal sənəd növünə görə bitmə tarixi tələb edir, vendorun vaxtında yenilənmə yükləməsi üçün xatırlatma yaradır, müddəti bitmiş sənədi qırmızı statusla göstərir və lazım gəldikdə vendoru yeni RFQ-lardan avtomatik kənarlaşdırır. Lakin avtomatik bloklama biznes qaydası ilə idarə edilməlidir: bəzi sənədlər yalnız xəbərdarlıq, digərləri isə əməliyyat məhdudiyyəti tələb edə bilər.
Fayl yükləmə hissəsində icazə verilən formatlar, ölçü limiti, təhlükəsizlik yoxlaması, faylların tətbiqin açıq qovluğundan kənarda saxlanması və sənədə səlahiyyətli giriş nəzərdə tutulmalıdır. OWASP yükləmələrdə uzantı, məzmun tipi və fayl imzasının yoxlanmasını birlikdə nəzərdən keçirməyi, faylları ayrıca və ya məhdud girişli yerdə saxlamağı tövsiyə edir.
RFQ və təklif müqayisəsi: e-poçtdan idarə olunan prosesə
RFQ modulu satınalma əməkdaşına seçilmiş vendor qrupuna eyni sorğunu göndərməyə, cavab üçün son tarix təyin etməyə və təklifləri müqayisə edilə bilən strukturda toplamağa imkan verir. Vendor yalnız özünə açılmış RFQ-ları görməli; digər təchizatçıların qiymətini, əlavələrini və ya iştirakını görməməlidir.
Yaxşı RFQ axınının elementləri
- Satınalma komandası ehtiyac sətirlərini, miqdarı, çatdırılma yerini, valyutanı və son tarixi yaradır.
- Sistem uyğun, aktiv və sənədləri etibarlı vendorları seçir.
- Vendor qiymət, çatdırılma müddəti, etibarlılıq dövrü, şərhlər və əlavələri təqdim edir.
- Son tarixdən sonra satınalma komandası normallaşdırılmış müqayisə ekranında təklifləri qiymətləndirir.
- Seçim və ya istisna təsdiq axınına keçir; yekun qərar audit jurnalına yazılır.
Burada “qiymət” tək meyar olmaya bilər. Müqayisə ekranı çatdırılma vaxtı, minimum sifariş həcmi, texniki uyğunluq, sənəd statusu və əvvəlcədən təyin edilmiş qiymətləndirmə meyarlarını da göstərə bilər. Kommersiya qiymətləndirməsi ilə texniki qiymətləndirmə ayrı rollara verilirsə, portal bu ayrılığı məlumat səviyyəsində də tətbiq etməlidir.
Təsdiq axınları və səlahiyyət modeli
Vendor approval workflow software üçün yalnız “təsdiq et” düyməsi kifayət deyil. Qayda mühərriki məsələn kateqoriya, məbləğ həddi, hüquqi şəxs, risk etiketi və istisna növünə görə ardıcıl və ya paralel təsdiqçilər təyin etməlidir. Təsdiqçi məzmunu dəyişə, yalnız qərar verə və ya əlavə məlumat istəyə bilər; bu səlahiyyətlər ayrıca müəyyən edilməlidir.
Tipik rollar vendor istifadəçisi, vendor administratoru, satınalma mütəxəssisi, kateqoriya meneceri, uyğunluq yoxlayanı, maliyyə yoxlayanı, təsdiqçi və sistem administratorudur. Giriş hüququ “rol var, deməli hər şeyi görür” prinsipi ilə deyil, rol + şirkət + vendor + əməliyyat əsasında yoxlanmalıdır. OWASP ən az səlahiyyət prinsipini və buraxılışlar dəyişdikcə giriş qaydalarının test edilməsini tövsiyə edir.
ERP inteqrasiyası: nəyi portal idarə etməlidir?
Portal və ERP arasında inteqrasiya dəyər yaradır, lakin əvvəlcə hər məlumatın sahibini müəyyən etmək lazımdır. Məsələn, ERP adətən təsdiqlənmiş vendor master məlumatı, maliyyə statusu, satınalma sifarişi və mal qəbulu üçün sistem mənbəyidir. Portal isə onboarding qaralamaları, sənəd yoxlaması, RFQ iştirakçılığı, daxili təsdiqlər və vendorun öz məlumat yeniləmə sorğuları üçün iş sahəsi ola bilər.
İnteqrasiya dizaynında aşağıdakılar açıq yazılmalıdır: hansı sistem vendor ID yaradır, hansı statuslar sinxronlaşır, dəyişiklik uğursuz olarsa nə baş verir, təkrarlanan mesaj necə zərərsiz emal olunur və əməkdaş hansı ekranda istisnanı həll edir. Bu suallar veb platformaların hazırlanması və texniki dəstək və konsaltinq işinin başlanğıcında inteqrasiya xəritəsinə çevrilməlidir.
Audit və təhlükəsizlik yoxlama siyahısı
- Hər təqdimetmə, düzəliş, təsdiq, rədd və bloklama üçün dəyişdirilə bilməyən hadisə qeydi.
- Vendorlar arasında ciddi məlumat izolyasiyası və server tərəfdə icazə yoxlaması.
- Həssas rekvizit dəyişiklikləri üçün əlavə təsdiq və bildiriş.
- Sənədin versiyası, yoxlayan şəxs, qərar səbəbi və bitmə tarixinin saxlanması.
- RFQ son tarixi, düzəliş pəncərəsi və təklifin hansı versiyasının qərara daxil olduğunun qeydi.
- İnteqrasiya xətaları üçün təkrar emal növbəsi və əməliyyat monitorinqi.
- Audit jurnalına girişin də ayrıca qeydə alınması və saxlama müddətinin müəyyən edilməsi.
Audit jurnalı təkcə uyğunluq üçün deyil, əməliyyat mübahisələrinin araşdırılması üçün də vacibdir. NIST logların yaradılması, ötürülməsi, saxlanması, əlçatanlığı və ləğvi üzrə planlı idarəetməni vurğulayır; portalda bu yanaşma qərarların və kritik dəyişikliklərin izini qorumaq deməkdir.
POLADO ilə layihəni necə başlamaq olar?
Ən yaxşı ilk mərhələ bütün ERP-ni əvəz etməyə çalışmaq deyil. Vendor onboarding, məcburi sənədlər, müddət xatırlatmaları, RFQ cavabları və bir və ya iki əsas təsdiq axınını əhatə edən mərhələli platforma daha ölçülə bilən başlanğıcdır. Sonra ERP sinxronizasiyası, vendor performansı, mobil bildirişlər və uyğun hallarda sənəd məlumatının idarə olunan çıxarılması əlavə oluna bilər.
POLADO, veb platformaların hazırlanması çərçivəsində proses xəritəsini, rol modelini, portal UX-ni, inteqrasiya sərhədlərini və buraxılış planını birlikdə formalaşdıra bilər. Təchizatçı əməliyyatlarınız hələ e-poçt və cədvəllərə bölünübsə, konsultasiya üçün müraciət edin: əvvəlcə hansı məlumatın sistem mənbəyi olacağını, hansı qərarların insan təsdiqi tələb etdiyini və ilkin versiyanın real əməliyyat yükünü azaltmalı olduğunu dəqiqləşdirək.