Bakıda anbar uçotu proqramının hazırlanması o zaman məntiqli investisiyaya çevrilir ki, satış, anbar və filial əməkdaşları eyni stok rəqəminə etibar edə bilmirlər. Problem adətən “Excel-dən istifadə edirik” faktı deyil. Problem odur ki, satış POS-dan ayrıca ixrac edilir, filiallar stok istəklərini mesajla göndərir, qəbul sənədləri gec daxil edilir və düzəlişlərin səbəbi sonradan bilinmir. Belə şəraitdə rəhbərlikdə bir rəqəm, mağazada başqa rəqəm, faktiki anbarda isə üçüncü rəqəm yaranır.

Düzgün qurulmuş sistem tam ERP-ni əvəz etməyə çalışmır. O, sizin real stok qaydalarınız üçün etibarlı əməliyyat qatıdır: hansı məhsul haradadır, hansı miqdar satış üçün əlçatandır, hansı miqdar rezerv olunub, hansı köçürmə yoldadır və hər dəyişiklik kim tərəfindən nə səbəblə edilib. POLADO belə məhsulları veb platformaların hazırlanması xidməti çərçivəsində biznesin mövcud əməliyyatlarına uyğun layihələndirir.

Nə vaxt xüsusi anbar idarəetmə sistemi lazımdır?

Kiçik məhsul kataloqu və bir satış nöqtəsi üçün müntəzəm inventarlaşdırılmış cədvəl kifayət edə bilər. Lakin aşağıdakı hallar təkrarlanırsa, cədvəl artıq sistem deyil, gecikmiş məlumat mənbəyidir:

  • Bir məhsul bir neçə filialda, anbarda və ya konsiqnasiya nöqtəsində saxlanılır.
  • Satış komandası məhsulu müştəri üçün ayırır, lakin həmin rezerv stok qalığında görünmür.
  • Filiallar arası köçürmə göndəriş və qəbul kimi iki ayrı mərhələdən keçməlidir.
  • POS satışı, onlayn sifariş və topdan sifariş eyni SKU üçün rəqabət aparır.
  • Geri qaytarma, zədələnmə, sayım fərqi və vaxtı keçmiş məhsul üçün nəzarətli düzəliş lazımdır.
  • İnsanlar “son fayl hansıdır?” və ya “bu rəqəmi kim dəyişib?” suallarını tez-tez verir.

Bu siqnalların hər biri təkcə interfeys problemi deyil, stok vəziyyətinin düzgün modelləşdirilməsi problemidir. Sistem yalnız cari qalıq sahəsini redaktə etdirməməlidir. O, qəbul, satış, rezerv, köçürmə, qaytarma və düzəliş kimi hərəkətlərdən qalıqları hesablamalı və həmin hərəkətlərin tarixçəsini saxlamalıdır.

Etibarlı stok rəqəmi necə formalaşır?

İstifadəçilərin ekranda bir neçə fərqli göstərici görməsi normaldır. Əsas məsələ onların açıq tərifə malik olmasıdır:

  • Faktiki stok: konkret məkanda fiziki olaraq mövcud miqdar.
  • Rezerv stok: təsdiqlənmiş satış sifarişi və ya başqa qayda üçün ayrılmış miqdar.
  • Yolda olan stok: mənbə filialdan çıxmış, amma təyinat məntəqəsində hələ qəbul edilməmiş miqdar.
  • Satışa açıq stok: biznes qaydalarından sonra yeni sifariş üçün istifadə oluna bilən miqdar.

Məsələn, mərkəzi anbarda 40 ədəd məhsul ola bilər. Onun 10 ədədi təsdiqlənmiş sifarişlərə rezerv edilib, 8 ədədi isə digər filiala göndərilib, lakin hələ qəbul edilməyib. Bu halda satış komandasının 40 deyil, öz qaydalarınıza görə hesablanmış satışa açıq miqdarı görməsi vacibdir. Bu qayda məhsul kateqoriyasına, kanalına və ya prioritet müştərilərə görə dəyişə bilər; ona görə də onu başlanğıcda dəqiqləşdirmək lazımdır.

Praktik minimum scope: platformada hansı modullar olmalıdır?

1. Məhsul kataloqu və məkan strukturu

Kataloqda SKU, barkod, məhsul adı, vahid, variant, kateqoriya, minimum stok həddi və zərurət olduqda lot, seriya nömrəsi və son istifadə tarixi saxlanıla bilər. Məkan modeli də əvvəlcədən aydınlaşdırılmalıdır: mərkəzi anbar, mağaza, filial, rəf, karantin zonası və ya yolda olan stok ayrıca izlənəcəkmi? GS1 standartları məkanların unikal identifikasiyasının logistika və izlənəbilənlik üçün əhəmiyyətini vurğulayır; daxili sisteminizdə də sabit məkan identifikatorları bu səbəbdən faydalıdır.

2. Rollar və təsdiq qaydaları

Anbar əməkdaşı qəbul edə, filial meneceri köçürmə tələb edə, satış meneceri rezerv yarada, maliyyə əməkdaşı isə yalnız hesabat görə bilər. Həssas əməliyyatlar üçün əlavə təsdiq tələb oluna bilər: mənfi stok yaradan hərəkət, böyük miqdarlı silinmə, geriyə tarixli düzəliş və ya bağlanmış dövrə dəyişiklik. Rol əsaslı ekranlar istifadəçini lazımsız funksiyalarla yükləmir və nəzarəti gücləndirir. Bu işin başlanğıcında UI/UX və məhsul dizaynı ilə rol və ssenariləri xəritələmək sonradan bahalı yenidənqurmanı azaldır.

3. Qəbul, köçürmə, satış sifarişi və rezerv

Satınalma qəbulu sadəcə “stok artır” düyməsi olmamalıdır. Platforma sifariş olunan, qəbul edilən və fərqli qəbul edilən miqdarları ayırmalıdır. Filial köçürməsi isə ən azı göndəriş və qəbul hadisələrinə bölünməlidir. Beləliklə, mal göndərən məkandan çıxanda yolda olan stoka keçir, təyinat məntəqəsi qəbul etdikdə isə oranın faktiki qalığına daxil olur. Müasir anbar sistemlərində transfer sifarişinin yolda olan miqdarı izləməsi bu modelin praktik dəyərini göstərir.

Satış sifarişi mərhələləri də şirkətinizin reallığına uyğun olmalıdır: qaralama, təsdiqlənmiş, qismən təmin edilmiş, yığıma hazır, göndərilmiş, ləğv edilmiş və qaytarılmış. Rezervin nə vaxt yarandığı xüsusilə vacibdir. Bəzi bizneslər sifariş təsdiqlənən kimi, digərləri isə ödəniş və ya menecer təsdiqi gəldikdən sonra rezerv edir. Hamı üçün bir “standart” cavab yoxdur.

4. Stok düzəlişləri və audit tarixçəsi

Sayım fərqi və zədələnmə real əməliyyat hadisələridir; onları gizlətmək düzgün deyil. Sistem düzəliş üçün səbəb kodu, qeyd, sənəd əlavəsi, icra edən şəxs və təsdiqləyən şəxs tələb edə bilər. Audit tarixçəsində yalnız yeni qalıq deyil, əvvəlki və yeni miqdar, tarix, istifadəçi və bağlı sənəd görünməlidir. OWASP da əməliyyat və audit izlərinin ayrıca məqsədlər daşıdığını, ardıcıl və araşdırıla bilən tarixçənin vacib olduğunu qeyd edir.

İnteqrasiyaların sərhədini əvvəlcədən müəyyən edin

Xüsusi inventory platforması adətən mövcud POS, mühasibat proqramı, e-ticarət saytı və ya kuryer xidməti ilə birlikdə işləyir. Burada ilk sual “inteqrasiya mümkündürmü?” deyil, “hansı sistem hansı məlumatın əsas sahibidir?” olmalıdır.

  • POS: satış, qaytarma və bəzən mağaza üzrə stok hərəkətlərinin mənbəyi ola bilər.
  • Mühasibat: hesab-faktura, maliyyə dövrləri, maya dəyəri və vergi məlumatının əsas sistemi ola bilər.
  • Inventory platforması: əməliyyat stokunun, rezervlərin, transferlərin və anbar istisnalarının əsas mənbəsi ola bilər.
  • E-ticarət: mövcudluq məlumatını alır və sifarişləri geri ötürür.

İnteqrasiya üçün API yoxdursa, ilkin mərhələdə nəzarətli CSV importu və exportu daha etibarlı keçid ola bilər. Amma importun təkrarlanması, eyni satışın iki dəfə düşməsi, məhsul kodlarının uyğunlaşdırılması, uğursuz sətrlərin görünməsi və yenidən emal qaydaları ayrıca dizayn edilməlidir. “Faylı yüklədik” inteqrasiya müqaviləsi deyil.

Layihədən əvvəl verilməli olan discovery sualları

  1. Stok hansı məkanlarda saxlanılır və bu məkanlar arasında hansı hərəkətlər mümkündür?
  2. Hansı hadisə stokun sahibini, fiziki yerini və ya satışa açıq miqdarını dəyişir?
  3. Rezerv hansı mərhələdə yaranır, nə vaxt açılır və qismən təmin edilən sifariş necə davranır?
  4. Mənfi stok mümkündürmü? Mümkündürsə, kim və hansı səbəblə bunu edə bilər?
  5. Sayım fərqini kim daxil edir, kim təsdiqləyir və hansı sənəd saxlanılır?
  6. POS və mühasibatla hansı məlumat hansı tezlikdə sinxronlaşmalıdır?
  7. İnternet zəif olduqda mağaza əməliyyatları necə davam etməlidir?

Bu sualların cavabı olmadan uzun funksiya siyahısı almaq risklidir. Əvvəlcə bir neçə yüksək həcmli proses seçmək daha düzgündür: məsələn, mal qəbulu, filial köçürməsi, satış rezervi və sayım düzəlişi. Sonra həmin proseslər üçün statuslar, səlahiyyətlər, istisnalar və hesabatlar dəqiqləşdirilir.

POLADO ilə nəyi planlamaq olar?

POLADO komandası inventar platformasını sadəcə idarəetmə paneli kimi deyil, əməliyyat qaydaları və inteqrasiya sərhədləri olan məhsul kimi planlamağa kömək edir. İş adətən mövcud faylların, POS exportlarının, stok sənədlərinin və real istifadəçi addımlarının təhlili ilə başlayır. Sonra məlumat modeli, əsas ekranlar, API və import qaydaları, audit tələbləri və mərhələli buraxılış planı hazırlanır. Platforma istifadəyə verildikdən sonra monitorinq, təhlükəsiz yeniləmələr və davamlı inkişaf üçün texniki dəstək və konsaltinq də nəzərdən keçirilə bilər.

Əgər filiallar stok rəqəmlərini mesajlaşma ilə uzlaşdırır, rezervlər görünmür və köçürmələrin harada qaldığını araşdırmaq üçün bir neçə fayl açmaq lazımdırsa, konsultasiya üçün POLADO ilə əlaqə saxlayın. Məqsəd sizə lazımsız ERP satmaq deyil; real stok axınlarınız üçün ölçülü, izlənə bilən və inkişaf etdirilə bilən veb platformanın scope-unu müəyyən etməkdir.