Bakıda B2B müştəri portalının hazırlanması layihəsində əsas qərar dizayn deyil: hər məlumatın hansı sistemdə rəsmi olaraq saxlanacağını müəyyən etməkdir. Portal müştəriyə sifarişlərini, hesab-fakturalarını, müqavilələrini, balansını, xidmət sorğularını və statuslarını vahid interfeysdə göstərə bilər. Amma portal CRM, ERP və ya mühasibat sisteminin kölgə nüsxəsinə çevrilərsə, müxtəlif rəqəmlər, gecikmiş sənədlər və əl ilə düzəliş ehtiyacı yaranır.
Doğru yanaşmada portal əməliyyat qatıdır: istifadəçini tanıyır, onun şirkət və roluna uyğun məlumatı göstərir, təhlükəsiz əməliyyatları qəbul edir və hər sorğunu həmin məlumatın sahibinə yönəldir. Bu məqalə təklif istəməzdən əvvəl qərarlaşdırmalı olduğunuz arxitektura suallarını izah edir.
Əvvəlcə “system of record” xəritəsini yaradın
“System of record” müəyyən məlumat növü üzrə son və etibarlı mənbədir. Portalın öz verilənlər bazası ola bilər, lakin o, hər obyektin sahibi olmamalıdır. Tipik B2B modelində:
- CRM — lead, əlaqə şəxsləri, satış imkanları, kommersiya şərtləri və hesab meneceri;
- ERP — sifariş, məhsul qalıqları, çatdırılma, müqavilə üzrə icra və qiymət qaydaları;
- mühasibat sistemi — hesab-faktura, ödəniş, borc, kredit notu və maliyyə dövrü;
- sənəd anbarı və ya DMS — müqavilə əlavələri, aktlar, sertifikatlar və imzalanmış fayllar;
- portal — istifadəçi hesabı, təşkilat üzvlüyü, interfeys üstünlükləri, giriş tarixçəsi, bildiriş seçimləri və portalın öz workflow statusları.
Bu siyahıdan sonra hər obyekt üçün yazılı qayda yaradın: “müştəri portalda hansı məlumatı oxuya, dəyişə, yarada və ya təsdiqləyə bilər?” Məsələn, müştəri ERP-dən gələn sifarişi oxuyur, lakin çatdırılma ünvanının dəyişdirilməsi üçün portalda sorğu yaradır. Sorğu təsdiq workflow-undan sonra ERP-də tətbiq edilir. Beləliklə, portal ERP qeydini birbaşa və nəzarətsiz redaktə etmir.
Expose, synchronize, yoxsa orchestrate?
İnteqrasiya üçün eyni dərəcədə düzgün olmayan üç model var. Seçim məlumatın həssaslığı, lazım olan real-vaxtlılıq, mövcud API-lər və biznes prosesindən asılıdır.
1. Expose: məlumatı mənbədən oxuyun
Portal API vasitəsilə CRM və ya ERP-dən sorğu zamanı məlumat alır. Bu üsul sifariş statusu, cari borc və ya sənəd siyahısı kimi daim aktual olmalı məlumatlar üçün münasibdir. Üstünlüyü ikinci nüsxənin az olmasıdır. Mənfi tərəfi isə mənbə sisteminin əlçatanlığına və cavab sürətinə bağlılıqdır.
Expose modeli üçün vaxt limiti, keşləmə qaydası və mənbə sisteminin işləmədiyi halda istifadəçiyə göstəriləcək vəziyyət hazırlanmalıdır. “Məlumat yoxdur” ilə “məlumat müvəqqəti əlçatan deyil” eyni mesaj olmamalıdır.
2. Synchronize: seçilmiş nüsxəni saxlayın
Portal yalnız lazım olan sahələri öz oxuma modelinə köçürür: məsələn, son 24 ayın hesab-faktura metadatası, sifariş xülasəsi və ya sənəd indeksləri. Bu model sürətli axtarış, dashboard və mənbə sisteminə az yük üçün faydalıdır. Lakin sinxron məlumatın “son yenilənmə vaxtı” görünməli, gecikmə limiti müəyyən edilməli və yenidən emal proseduru olmalıdır.
Sinxronizasiya ikitərəfli yazışma demək deyil. Əksinə, iki sistemin eyni sifariş cəmini ayrı-ayrılıqda redaktə etməsi konflikt yaradır. Yazma əməliyyatı adətən sahib sistemə komanda kimi göndərilməlidir.
3. Orchestrate: çoxsistemli prosesi idarə edin
Orkestrasiya portalın CRM, ERP, mühasibat və sənəd xidmətləri arasında prosesi koordinasiya etməsidir. Nümunə: müştəri kommersiya təklifini qəbul edir; portal səlahiyyəti yoxlayır, CRM-də fürsəti yeniləyir, ERP-də sifariş yaratmaq üçün sorğu göndərir, sənəd xidmətindən təsdiq faylını alır və istifadəçiyə nəticəni bildirir.
Burada portalın biznes statusu ola bilər: “göndərildi”, “emal olunur”, “ERP təsdiqlədi”, “diqqət tələb olunur”. Bu statuslar sahib sistemdəki maliyyə və ya sifariş statusunu əvəz etmir; inteqrasiya prosesinin vəziyyətini aydın göstərir.
Rol əsaslı giriş: yalnız menyunu deyil, hər obyekti qoruyun
B2B hesabı bir nəfərdən ibarət olmur. Bir müştəri təşkilatında maliyyə əməkdaşı hesab-fakturaları görməli, satınalma meneceri sifariş verməli, rəhbər bütün filialları görməli, xarici auditor isə yalnız seçilmiş sənədlərə baxmalıdır. Buna görə icazə modeli ən azı istifadəçi + təşkilat + rol + obyekt sahibliyi + əməliyyat səviyyəsində hazırlanmalıdır.
Sadəcə “admin”, “user” və “manager” rolları kifayət etmir. Məsələn, “sənədi yüklə” icazəsi həmin sənədin aid olduğu müqavilə, hüquqi şəxs və filial üzrə də yoxlanmalıdır. OWASP API təhlükəsizlik tövsiyələri obyekt identifikatoru ilə işləyən hər endpoint-də obyekt-səviyyəli səlahiyyət yoxlamasını vacib sayır. Fayl metadatası, maliyyə sahələri və daxili qeydlər üçün sahə-səviyyəli filtr də tətbiq edilməlidir.
Bu iş üçün UI/UX və məhsul dizaynı mərhələsində rol matrisi və əsas istifadəçi ssenarilərini qurmaq, sonra isə veb platformanın hazırlanması zamanı həmin qaydaları API və interfeysə çevirmək daha təhlükəsizdir.
Təhlükəsiz sənəd portalı necə işləməlidir?
Sənədi sadəcə “fayl linki” kimi təqdim etməyin. Portal sənəd kataloqunda ad, növ, aid olduğu müqavilə və ya sifariş, versiya, yayımlanma tarixi, görünmə qaydası və yükləmə audit izi saxlanmalıdır. Faylın özü qorunan anbarda qala bilər; qısaömürlü yükləmə linki yalnız səlahiyyət yoxlandıqdan sonra yaradılmalıdır.
- Hər sənəd üçün təşkilat, filial və müqavilə kontekstini yoxlayın.
- Versiyaları dəyişdirilməz identifikatorla ayırın; “son versiya” qaydası aydın olsun.
- Yükləmə, paylaşma, silmə və təsdiq əməliyyatlarını audit jurnalına yazın.
- Həssas sənədlərdə yenidən autentifikasiya, MFA və sessiya vaxt limitini riskə uyğun nəzərdən keçirin.
- İstifadəçi deaktiv ediləndə onun sessiyasını və aktiv girişlərini ləğv edin.
Bu nəzarətlər həm texniki, həm də əməliyyat məsuliyyətidir. İstifadəçi interfeysində “bu sənədə niyə girişim yoxdur?” sualı üçün dəstək yönləndirməsi olmalıdır; gizli sistem məlumatı göstərilməməlidir.
İnteqrasiya xətalarını normal ssenari kimi dizayn edin
İnteqrasiya xətası istisna deyil. ERP planlı texniki işdə ola bilər, API zaman limiti verə bilər, eyni sorğu iki dəfə göndərilə bilər və ya CRM-də müştəri kartı birləşdirilə bilər. Layihə sənədində aşağıdakılar olmalıdır:
- İdentifikator xəritəsi: portal, CRM və ERP identifikatorlarının uyğunluğu və dəyişmə qaydası.
- İdempotentlik: “sifariş yarat” əmri şəbəkə təkrarı səbəbindən ikinci sifariş yaratmamalıdır.
- Təkrar cəhd siyasəti: hansı xətalar avtomatik, hansı xətalar isə insan yoxlaması ilə təkrar edilir.
- Dead-letter və istisna növbəsi: uğursuz mesaj itməməli, məsul əməkdaşa görünməlidir.
- Reconciliation: gündəlik və ya riskə uyğun intervalda portalın proses qeydləri ilə sahib sistemdəki nəticələr müqayisə edilməlidir.
- İstifadəçi mesajı: “sorğunuz qəbul edildi” yalnız əmrin qeyd edildiyini, “tamamlandı” isə nəticənin sahib sistemdə təsdiqləndiyini bildirməlidir.
Etibarlı mesajlaşma üçün transactional outbox və idempotent emal kimi nümunələr istifadə edilə bilər. Lakin seçilən texnologiyadan daha vacib məsələ: uğursuzluq zamanı biznesin kimin nə edəcəyini bilməsidir. Texniki dəstək və konsaltinq xidməti bu cür monitorinq, buraxılış və əməliyyat prosedurlarının layihələndirilməsinə kömək edə bilər.
Təklif istəməzdən əvvəl cavablandırılacaq suallar
- Portalın ilk versiyasında hansı 3–5 iş nəticəsi vacibdir: sifariş izləmə, sənəd mübadiləsi, borc görünüşü, servis sorğusu, yoxsa təkrar sifariş?
- Hər məlumat növünün sahibi hansı sistemdir və portalda onun təzələnmə hədəfi nədir?
- Mövcud sistemlərdə API, webhook, ixrac faylı və ya yalnız manual proses varmı?
- Müştəri şirkətləri, filiallar, əlaqə şəxsləri və səlahiyyətlər necə əlaqələnir?
- Hansı sənədlər hüquqi, maliyyə və ya kommersiya baxımından həssasdır?
- Müştərinin yaratdığı dəyişiklik dərhal tətbiq ediləcək, yoxsa əməkdaşın təsdiqi tələb olunacaq?
- İnteqrasiya dayananda kim xəbərdar olur, kim düzəldir və müştəri nə görür?
- Audit, məlumatın saxlanması, məlumat ixracı və hesabın bağlanması üzrə tələblər hansılardır?
Nəticə: portalı ayrıca həqiqət mənbəyi kimi deyil, idarə olunan giriş qatı kimi qurun
Yaxşı B2B portalı müştərini e-poçt, Excel və telefon zəngləri arasında gəzdirmir. O, doğru məlumatı doğru təşkilatdakı doğru şəxsə verir, əməliyyatları qaydalı şəkildə sahib sistemlərə ötürür və problem yarandıqda həm istifadəçi, həm də əməliyyat komandası üçün aydın iz yaradır.
POLADO portalı sadəcə girişli səhifə kimi deyil, inteqrasiya sərhədləri, rol modeli, sənəd təhlükəsizliyi və dayanıqlı əməliyyatlar olan məhsul kimi planlaşdırır. CRM, ERP və sənəd axınlarınızı ilkin texniki workshop-da xəritələndirmək üçün veb platformaların hazırlanması xidməti üzrə konsultasiya istəyin.