Biznes sistemi axtararkən «anbar proqramı», «CRM» və «ERP» adları tez-tez yanaşı görünür. Bir məhsul bu istiqamətlərin bir neçəsini birləşdirə bilər, amma adın özü sizin işiniz üçün lazım olan funksiyaları təsdiqləmir. Düzgün seçim üçün idarə etdiyiniz məlumatı və qərar verdiyiniz prosesi ayırmaq faydalıdır.
CRM-in mərkəzində münasibət və satış axını var
CRM anlayışı müştəri və potensial müştəri ilə bağlı işin təşkilini əhatə edir. Müraciətin mənbəyi, məsul əməkdaş, danışıq nəticəsi və növbəti addım əsas məlumatlar ola bilər. Konkret CRM-in hansı modullara malik olması məhsul və layihədən asılıdır.
Əgər problem «müraciət kimdə qaldı?» və ya «müştəriyə nə cavab verildi?» sualları ilə bağlıdırsa, münasibət və status axınına diqqət vermək lazımdır. Sadəcə məhsul qalığı bu sualların cavabını vermir.
Anbar proqramı malın hərəkətini izləyir
Anbar istiqamətində əsas mövzu məhsulun daxil olması, çıxması, yerinin və qalığının uçotudur. Məhsul kodu, ölçü vahidi, anbar və hərəkətin səbəbi kimi məlumatlar əhəmiyyət qazanır. Eyni məhsul müxtəlif yerlərdə və fərqli vəziyyətlərdə ola bilər.
Satış, qaytarma, transfer və inventarizasiya ayrıca əməliyyatlardır. Qalıq hesabının necə yarandığını izah edə bilmək yalnız yekun rəqəmi görməkdən daha faydalıdır. Yeni sistemə keçərkən başlanğıc qalıq və məhsul identifikatorları diqqətlə hazırlanmalıdır.
ERP əlaqəli əməliyyatları birləşdirir
ERP daha geniş şirkət proseslərini əlaqələndirən yanaşmadır. Satınalma, anbar, satış, maliyyə və insan resursları kimi istiqamətlər bir layihədə birlikdə nəzərdə tutula bilər. Bunun üçün bölmələrin məlumatları və səlahiyyətləri arasında qayda lazımdır.
«ERP alırıq» demək bütün proseslərin avtomatik uyğunlaşacağı mənasına gəlmir. Hansı modulların əhatə olunduğu və onların bir-birinə necə təsir etdiyi müqavilədə və texniki tapşırıqda aydın göstərilməlidir.
Bir sifarişlə fərqi görün
Təsəvvür edin ki, müştəri məhsul sifariş edib. CRM tərəfində müraciət, əlaqə və məsul şəxs izlənə bilər. Anbar tərəfində məhsulun mövcudluğu, rezervasiyası və çıxışı əsasdır. Maliyyə tərəfi ödənişlə bağlı qaydaları aparır. Bu məlumatların birlikdə işləməsi tələb olunursa, sistemlərarası əlaqə və ya daha geniş ümumi həll planlaşdırılır.
Burada hansı sistemin əsas mənbə olması vacibdir. Məhsul qiymətini iki yerdə ayrı-ayrılıqda dəyişmək uyğunsuzluq yarada bilər. Eyni müştəri üçün təkrar qeyd yaranmaması və statusların uyğunluğu da əvvəlcədən düşünülür.
Öz ehtiyacınızı necə təsvir etməli?
- Hazırda nəyi ayrıca cədvəldə və ya mesajlaşmada saxlayırsınız?
- Hansı səhv və gecikmə gündəlik işi çətinləşdirir?
- Məlumatı kim daxil edir, kim təsdiqləyir və kim yalnız görür?
- Hansı hesabat əsasında qərar verilir?
- Mövcud sayt, kassa və ya mühasibat sistemi qalacaqmı?
Bu suallar funksiyaların sərhədini aydınlaşdırır. Bütün şirkəti bir mərhələdə dəyişmək əvəzinə əvvəlcə ən vacib əməliyyatı təşkil etmək mümkündür. Sonrakı genişlənmə üçün məlumat modelini də düşünmək lazımdır.
Portfoliodan başlanğıc nöqtələri
Anbarex, Finex və Nəqliyyat CRM müxtəlif biznes mövzularına aid nümunələrdir. Layihə səhifələrində təsdiqlənmiş məlumat və açıq təqdimat göstərilir; məhsulun adı əsasında görünməyən funksiyalar barədə nəticə çıxarmaq olmaz.
Məlumat lüğəti hazırlamaq nə verir?
Şöbələr eyni sözdən fərqli mənada istifadə edə bilər. Satış üçün «sifariş tamamlandı» müştərinin razılaşması, anbar üçün məhsulun çıxması, maliyyə üçün ödənişin bağlanması ola bilər. Bu anlayışları bir statusda birləşdirmək hesabatı anlaşılmaz edə bilər. Hər prosesin statusunu və əlaqəsini ayrıca izah edin.
Sadə məlumat lüğətində obyekt, əsas identifikator, məsul şəxs və dəyişmə qaydası yazılır. Məhsul üçün kodun kim tərəfindən yaradıldığı, müştəri üçün təkrarın necə müəyyənləşdirildiyi, sifariş üçün hansı nömrənin əsas olduğu görünməlidir. Bu sənəd həm hazır məhsulu yoxlamağa, həm də fərdi hazırlığa kömək edir.
Başlanğıc qalıq və sonrakı hərəkət
Anbar keçidində yalnız «indi nə qədər var?» sualını cavablandırmaq kifayət etmir. Ölçü vahidi, anbar yeri və tarix də əhəmiyyətli ola bilər. Yeni sistemə köçürülən başlanğıc məlumatdan sonra hansı əməliyyatların harada qeyd ediləcəyi dəqiq seçilməlidir. Paralel uçot aparılırsa, təsdiq qaydası yazılsın.
İnventarizasiya nəticəsi ilə əməliyyat səhvini eyni cür düzəltmək hər biznesdə uyğun olmaya bilər. Düzəlişin səbəbi, onu təsdiqləyən şəxs və hesabatda görünüşü razılaşdırılır. Bu qaydalar proqramın adından asılı olmayaraq məlumatın izahını yaxşılaşdırır.
Sistemin sərhədini göstərən nümunə sənəd
Bir sifariş, bir mal hərəkəti və bir hesabat nümunəsini birlikdə hazırlayın. Hər birində hansı məlumatın digərində istifadə olunduğunu işarələyin. Sonra məlumatın əl ilə daxil edildiyi və ya avtomatik ötürüldüyü addımları ayırın. Bu xəritə inteqrasiyaya ehtiyacı daha aydın göstərəcək.
Sənədi texniki tapşırığın bir hissəsinə çevirə bilərsiniz. İlk versiya həmin əlaqələrin ən vacibini həll etdikdə, sonrakı modul qərarları daha konkret iş nümunəsinə əsaslanar.
Kiçik biznesə bütöv ERP lazımdırmı?
Qərarı şirkətin ölçüsündən çox real proses və əlaqələrə görə verin. Bir iş axınının idarəsi kifayət edirsə, ilkin sərhədi ona uyğun seçmək olar. Məlumatın digər sistemlərlə necə uyğun qalacağı isə həmin ilk mərhələdə də nəzərə alınmalıdır.
Öz iş axınınız üçün CRM və ERP hazırlanması üzrə ilkin müzakirə edə bilərsiniz. Məlumatın bir neçə sistem arasında keçməsi lazımdırsa, API inteqrasiyası ayrıca planlaşdırılır. Uyğun sistemin adı real ehtiyaclar müəyyənləşdikdən sonra daha mənalı olur.
