«CRM neçəyə başa gəlir?» sualının dəqiq cavabı sistemin adından çıxmır. Eyni müştəri kartı bir şirkətdə sadə əlaqə dəftəri, digərində bir neçə filial, müqavilə və sənəd axınının başlanğıcı ola bilər. Qiyməti ekranların sayı ilə müqayisə etmək bu fərqi gizlədir. Təkliflərin müqayisəsi üçün əvvəlcə görüləcək işin sərhədləri eyni olmalıdır.
Bu məqalədə konkret məbləğ və bazar ortalaması verilmir. Təsdiqlənmiş eyni əhatəli təkliflər olmadan belə rəqəmlər yanlış gözlənti yaradar. Məqsəd CRM hazırlanması üzrə qiymət sorğusunu daha aydın hazırlamaqdır.
Birinci amil: neçə iş axını var?
Müştəri məlumatının saxlanılması bir işdir; müraciətin təklifə, müqaviləyə, icraya və ödəniş qeydinə çevrilməsi isə bir neçə əlaqəli qaydadır. Hər mərhələdə hansı məlumatın tələb edildiyi, kimin dəyişiklik edə biləcəyi və səhv addımın necə geri qaytarılacağı müəyyən olunmalıdır.
İzahat üçün nümunə: xidmət şirkəti ilk versiyada yalnız müraciət və təklif axınını istəyə bilər. Sonradan planlama, icraçı təyinatı və sənəd təsdiqi də lazım olarsa, bu artıq yeni əhatədir. Başlanğıcdan bütün mümkün ehtimalları daxil etmək əvəzinə mərhələləri prioritetləşdirmək daha nəzarət olunan büdcə yaradır.
Məlumat modeli və mövcud qeydlər
Müştəri, sifariş, əlaqə şəxsı, məhsul və filial arasındakı əlaqələr xərclərə təsir edir. Məsələn, bir müştərinin çoxsaylı ünvan və müqavilələrinin olması sadə siyahıdan fərqlidir. Eyni məlumatın müxtəlif cədvəllərdə təkrarlanması köçürmə işinə də əlavə təmizləmə gətirir.
Excel-dən CRM-ə keçid zamanı boş sahələr, fərqli tarix formatları və təkrarlanan telefonlar müəyyənləşdirilməlidir. Bu iş ayrıca qiymətləndirilmirsə, sonradan «bütün məlumatlar niyə düzgün görünmür?» sualı yaranır. İdxalın uğuru yalnız faylın sistemə daxil olması ilə ölçülmür.
İnteqrasiyalar niyə ayrıca qiymətləndirilir?
Sayt, ödəniş xidməti, mühasibat proqramı və ya mesajlaşma platforması ilə əlaqə üçün sadəcə «API var» demək kifayət deyil. Qarşı tərəfin sənədləri, səlahiyyətləri, limitləri, test mühiti və səhv cavabları öyrənilməlidir. Bəzən xarici xidmətin dəyişməsi əlavə iş yaradır.
- Hansı məlumatın hansı istiqamətə göndəriləcəyi.
- Əsas məlumat mənbəyinin hansı sistem olması.
- Bağlantı kəsiləndə işin necə davam etməsi.
- Təkrar sorğunun eyni əməliyyatı iki dəfə yaratmaması.
- Səhv və nəticələrin kim tərəfindən izlənilməsi.
Bu məsələlər API inteqrasiyası bələdçisində ayrıca izah olunur. İnkişaf büdcəsini qiymətləndirərkən üçüncü tərəf abunələri və istifadə xərcləri də proqramlaşdırma işindən ayrılmalıdır.
Rollar, filiallar və hesabatlar
Bir administratorlu sistemlə müxtəlif filial və rolları olan tətbiqin sınaq həcmi eyni deyil. Satış əməkdaşının yalnız öz müştərilərini görməsi, rəhbərin filial üzrə hesabat alması və maliyyə qeydlərinin ayrıca qorunması fərqli qaydalardır. Bu qaydalar ekranda olduğu qədər serverdə də yoxlanılmalıdır.
Hesabatın «olması» da tək tələb deyil. Hansı tarixə əsaslandığı, ləğv edilmiş sifarişlərin hesablanması və filtrin nəticəni necə dəyişdirdiyi razılaşdırılmalıdır. Bir düzgün hesabat çox sayda qeyri-müəyyən rəqəmdən daha faydalıdır.
Təklif müqayisəsi üçün siyahı
- İlk versiyaya daxil olan iş axınlarını yazın.
- Hər rol üçün əsas əməliyyatları müəyyənləşdirin.
- Mövcud məlumatdan anonim nümunə hazırlayın.
- İnteqrasiyaların adını və sənədini göstərin.
- Qəbul ssenarilərini və təhvil materiallarını dəqiqləşdirin.
- Dəstək, sonrakı dəyişiklik və xarici xərcləri ayırın.
İş əhatəsi dəyişəndə qiymət müzakirəsi aparılır?
İlkin təklifdə bir filial və bir sifariş axını razılaşdırıldığını düşünün. Sonra başqa filialın ayrıca icazələri və əvvəlki cədvəllərdən tarixçənin gətirilməsi istənilir. Bu, şərti nümunədir: yeni tələb ilkin ekranın kiçik düzəlişi kimi görünə bilər, amma məlumat, sınaq və təlim hissəsini genişləndirir.
Belə vəziyyətdə əvvəl «nə dəyişir?» sualını yazın. İcazə qaydası, idxal, hesabat və qəbul nümunələrinin hansına təsir olduğu göstərilsin. Sonra dəyişiklik cari mərhələdə, yoxsa növbəti versiyada görüləcək, müəyyənləşdirilsin. Şifahi razılaşma əvəzinə təsir siyahısı həm büdcəni, həm gözləntiləri aydın saxlayır.
- Əlavə funksiyanın iş məqsədini təsvir edin.
- Mövcud məlumat və istifadəçilərə təsirini müəyyənləşdirin.
- Yeni qəbul ssenarisini yazın.
- Təlim və dəstəkdə dəyişən hissəni göstərin.
Qiymət müqayisəsində ayrı-ayrı təkliflərin eyni qəbul nəticəsini əhatə etdiyini yoxlayın. Daha qısa funksiya siyahısı bəzən daha az iş deməkdir, bəzən isə daha aydın yazılmış təklifdir.
Tez verilən suallar
Daha ucuz ilkin versiya qurmaq olarmı?
Bəli, əhatəni əsas iş axınına endirməklə başlamaq olar. Amma vacib məlumat bütövlüyü və giriş nəzarətini sonraya saxlamaq qənaət kimi qiymətləndirilməməlidir.
Hazır CRM həmişə daha sərfəlidirmi?
Başlanğıc xərc aşağı ola bilər, lakin istifadəçi lisenziyaları, uyğunlaşdırma və məlumat köçürülməsi də müqayisəyə daxil edilməlidir. Hazır və fərdi CRM seçimi bu qərarın çərçivəsini izah edir.
Real iş nümunəsi ilə müzakirə
Logistex layihəsi CV-də sifariş, marşrut, maliyyə və yanacaq uçotu istiqamətləri ilə qeyd olunur. Bu nümunə modul adlarından sonra konkret qaydaların niyə lazım olduğunu göstərən müzakirə nöqtəsidir; başqa biznes üçün eyni qiymət və nəticə çıxarmağa əsas vermir.
