Sifariş idarəetmə sistemi təkcə yeni sifarişin siyahıda görünməsi deyil. Sifarişin kimdən gəldiyi, nəyin razılaşdırıldığı, hansı hissənin icra olunduğu və hansı addımın gözlədiyi aydın olmalıdır. Bu suallara müxtəlif əməkdaşlar fərqli fayllardan cavab verirsə, işin ümumi vəziyyətini anlamaq çətinləşir.
Onlayn mağaza, xidmət şirkəti və logistika biznesində sifarişin məzmunu fərqlənir. Ona görə sifarişə bağlı biznes sistemi hazırlanarkən əvvəl real axın seçilir. Universal status siyahısı bütün prosesləri tam göstərməyə bilər.
Bir sifarişin sərhədi nədir?
Bir müştərinin bir neçə məhsulu tək sifarişdə alması, xidmət paketinə müraciət etməsi və ya bir neçə ünvan üçün daşıma istəməsi fərqli modellərdir. Sifariş kartı ilə onun sətirlərini ayırmaq lazım gələ bilər. Bir hissə icra olunanda bütün sifarişin tamamlanıb-tamamlanmadığı ayrıca qaydadır.
İzahlı nümunə: üç məhsuldan ikisi göndərilib, biri gözləyir. Bu şərti vəziyyətdə tək «göndərildi» statusu istifadəçiyə tam mənzərə vermir. Qismən icra və qalan öhdəlik ayrıca görünməlidir. Eyni məntiq xidmətin mərhələlərinə də tətbiq oluna bilər.
Yaradılma və təsdiq mərhələləri
Sifarişin daxil olması onun avtomatik qəbul edilməsi demək olmaya bilər. Məhsul mövcudluğu, xidmət əhatəsi və əlaqə məlumatı yoxlanıla bilər. İstifadəçi bu fərqi anlamalıdır: sistemdə qeyd alınıb, yoxsa işə qəbul edilib?
- Mənbə: sayt, telefon, əməkdaş və ya tərəfdaş.
- Müştəri və əlaqəli şəxs.
- Sifarişin məzmunu və razılaşdırılmış şərtlər.
- Məsul əməkdaş və növbəti addım.
- Yaradılma, təsdiq və faktiki icra tarixləri.
Rezerv və iş resursları
Məhsul sifarişində anbar qalığı, xidmət işində isə komanda və vaxt resursu əhəmiyyətli ola bilər. Rezerv sifariş təsdiqlənməmişdən əvvəl yaranırsa, onun müddəti və ləğvi düşünülməlidir. Əks halda tamamlanmayan müraciətlər mövcud resursu bağlı saxlaya bilər.
Məhsul hissəsi haqqında anbar və stok qaydalarında ayrıca izah var. Onlayn mağaza üçün satınalma və sifariş axını da həmin məlumatla uyğunlaşdırılmalıdır.
Statusların mənasını ayırın
Ödəniş, icra və sənəd vəziyyəti həmişə eyni status deyil. Sifariş ödənilmiş, amma hələ hazırlanmaqda ola bilər. Və ya xidmət bitmiş, amma təsdiq sənədi gözlənilə bilər. Hər vəziyyəti bir uzun status adı ilə birləşdirmək interfeysi və hesabatı çətinləşdirə bilər.
Hansı hadisənin hansı göstəricini dəyişdirdiyi yazılmalıdır. Əməkdaş «tamamlandı» seçəndə hansı məlumat yoxlanılır? Geri qaytarma və ləğv əvvəlki əməliyyatla necə əlaqələnir? Bunlar sadəcə dizayn qərarı deyil, işin məlumat qaydalarıdır.
Bildiriş və məsuliyyət
Müştəriyə göndərilən bildiriş real vəziyyəti ifadə etməlidir. Məlumatın qeydiyyatı ilə xidmətin icrası qarışdırılmamalıdır. Komandaya bildirişdə isə işin sahibi və növbəti addım görünməlidir. Hər dəyişiklik üçün hamıya mesaj göndərmək məsuliyyəti avtomatik yaratmır.
Bildiriş uğursuz olarsa sifarişin özünün vəziyyəti məlum qalmalıdır. Əlaqə xidməti ilə sistem əməliyyatı fərqli hadisələrdir. API və xarici xidmət ssenarilərində təkrar cəhd qaydaları ayrıca planlaşdırılır.
Axtarış və hesabat
Əməkdaş sifarişi yalnız nömrə ilə deyil, müştəri, tarix, telefon və işin məzmunu ilə də axtara bilər. Hansı sahənin axtarışa daxil olduğu məlum olmalıdır. Səlahiyyət həddi axtarış nəticəsində də qorunur.
Hesabat üçün «günün sifarişləri» ifadəsini dəqiqləşdirin: yaradılan, təsdiqlənən və ya icra olunan? Ləğv və qismən qaytarma necə sayılır? Bu sualların əvvəl cavablandırılması müxtəlif şöbələrin fərqli rəqəm görməsinin qarşısını almağa kömək edir.
Qəbul ssenariləri
- Yeni və natamam sifariş.
- Qismən icra və qalan hissə.
- Mövcud olmayan məhsul və ya resurs.
- Eyni sorğunun təkrar göndərilməsi.
- Ləğv, geri qaytarma və düzəliş.
- Əlaqə xidməti işləməyəndə bildirişin davranışı.
Nümunə: sifarişin yalnız bir hissəsi ləğv olunur
Bir sifarişdə bir neçə məhsul var və müştəri onlardan yalnız birini istəmir. Bu şərti vəziyyətdə bütün sifarişin ləğvi ilə bir sətrin ləğvi eyni nəticə vermir. Rezerv, icra və sənəd vəziyyəti hər hissə üçün razılaşdırılmış qayda ilə dəyişir.
Artıq göndərilmiş məhsulla hələ hazırlanmayan məhsulun davranışı fərqli ola bilər. Proqramçı bu fərqi status adından təxmin etməməlidir. Biznes hansı hadisənin hansı qalan öhdəliyə təsir etdiyini yazır, texniki qəbul isə həmin nümunəni yoxlayır.
- Ləğv edilmiş hissənin rezervini yoxlayın.
- Qalan məhsulların icra yolunu müqayisə edin.
- İstifadəçiyə görünən yekun vəziyyəti nəzərdən keçirin.
- Hesabatda sifarişlə sətir sayının fərqini saxlayın.
Bu sınaq faktiki maliyyə geri qaytarma qaydası təyin etmir. Məqsəd sifarişin iş vəziyyətinin düzgün saxlanmasıdır. Əlaqəli ödəniş və sənəd qaydaları səlahiyyətli tərəflə ayrıca təsdiqlənir.
Tez verilən suallar
CRM sifariş sistemini əvəz edirmi?
Bu, məhsulun əhatəsindən asılıdır. Bəzi CRM-lər əməliyyat hissəsini də saxlayır, bəzilərində ayrıca inteqrasiya tələb olunur.
Bütün statuslar müştəriyə göstərilməlidirmi?
Daxili əməliyyat məlumatı ilə müştərinin bilməli olduğu vəziyyət fərqli ola bilər. İctimai təqdimat ayrıca razılaşdırılır.
Boss Electronics onlayn satış layihəsi, 166 Cargo isə sifariş və sənəd əməliyyatları nümunəsi kimi CV-də qeyd olunur. Öz tələbinizi hazırlayarkən tətbiq və miqrasiya planını da nəzərə alın.
