SaaS platforması bir proqramı bir neçə müştərinin xidmət kimi istifadə etməsinə əsaslanan məhsul modeli ola bilər. Texniki baxımdan adi daxili proqramdan fərqli suallar yaranır: hansı təşkilatın məlumatıdır, istifadəçi hansı təşkilata daxildir, xidmət planı nəyi dəyişir və bir müştərinin əməliyyatı digərinə təsir edə bilərmi?
İlk qərar proqramlaşdırma dili yox, məhsulun həll etdiyi konkret işdir. Eyni ümumi sahədə olmaq bütün müştərilərin eyni qaydaları paylaşması demək deyil. CRM-in təyinatı və seçilmiş iş axını aydınlaşmadan böyük platformaya başlamaq məhsul əhatəsini qeyri-müəyyən saxlayır.
Müştəri təşkilatı məlumat modelinin hissəsidir
İstifadəçi hesabı ilə müştəri təşkilatı ayrı obyektlər ola bilər. Bir şəxs bir neçə təşkilatda fərqli rol daşıya bilər. Proqram hər əməliyyatda hansı təşkilat kontekstində işlədiyini bilməlidir. Bu məlumatın yalnız ekranda seçilmiş menyuya bağlı qalması kifayət deyil.
İzahlı nümunə: mühasib iki şirkət üçün işləyir. Bu şərti ssenaridə bir şirkətə aid müştəri axtarışı digərinin nəticələrini gətirməməlidir. Eyni tələb hesabat, sənəd, bildiriş və ixrac üçün də keçərlidir. Təşkilat sərhədi yalnız məlumat siyahısının filtri deyil.
İlk versiyanın əhatəsini seçin
Bir platformada hər biznesin bütün işini həll etməyə çalışmaq məhsulu başa düşməyi çətinləşdirir. Bir aydın axın seçin: məsələn, müraciətin qeydiyyatı və məsul təyinatı. Müxtəlif müştərilər üçün həmin axının ortaq və dəyişən hissələrini ayırın.
- Hər müştərinin istifadə etdiyi əsas funksiya.
- Təşkilat üzrə dəyişə bilən parametrlər.
- Yalnız ayrıca razılaşma ilə verilən fərdiləşdirmə.
- Platformanın ilk versiyasına daxil olmayan işlər.
Parametr ilə ayrıca kod fərqi vacibdir. Hər müştəri üçün ayrıca kod nüsxəsi yaradılırsa, yeniləmə və dəstək işi sürətlə mürəkkəbləşə bilər. Bu qərarın nəticəsi əvvəl qiymətləndirilməlidir.
Plan və icazəni qarışdırmayın
Xidmət planı funksiyanın mövcudluğunu müəyyən edə bilər; rol isə həmin təşkilatda istifadəçinin nə edə biləcəyini göstərir. Geniş planı olan təşkilatın hər əməkdaşı avtomatik administrator olmamalıdır. İki qayda ayrı qiymətləndirilməlidir.
Abunə vəziyyəti dəyişəndə məlumatın oxunması, ixracı və yeni əməliyyatların davranışı razılaşdırılmalıdır. Bu məqalə kommersiya qiyməti və müqavilə şərti təyin etmir. Məqsəd qərarın texniki nəticəsini görünən etməkdir: istifadəçi xidmət vəziyyətini aydın başa düşməlidir.
Qoşulma və ilk istifadə
Yeni müştərinin ilk boş ekranı məhsulun vacib hissəsidir. Təşkilatın yaradılması, ilkin rol, ilk müştəri və ya məhsul qeydi kimi addımlar müəyyən edilməlidir. Nümunə məlumat istifadə olunursa, onun real əməliyyatla qarışmaması aydın göstərilməlidir.
Köhnə sistemdən gələn məlumat da məhsul axınına təsir edir. Bir təşkilatın idxal səhvi başqa müştərinin işini dayandırmamalıdır. Ümumi qaydalar miqrasiya planında verilən sınaq və qəbul yanaşması ilə tamamlanır.
İnteqrasiya və sərhədlər
Müştərinin xarici xidmət açarı və bağlantısı təşkilata aid saxlanılmalıdır. Bir müştərinin tokeninin başqasının sorğusunda istifadə olunması ciddi səhvdir. Məxfi dəyərlər ekran və jurnallarda açıq göstərilməməlidir. İnkişaf zamanı həqiqi məlumat əvəzinə nəzarətli sınaq dəsti seçmək faydalıdır.
API inteqrasiyaları üçün limit, təkrar cəhd və səhv göstərilməsi planlaşdırılır. Bir xarici xidmətin gecikməsi bütün platformanın əsas işini avtomatik dayandırmalı deyil; uyğun davranış konkret tələblə müəyyən edilir.
Yeniləmə və dəstək davamlı işdir
SaaS məhsulunda yayımdan sonra bir çox müştəri eyni versiyanın yenilənməsindən təsirlənə bilər. Dəyişikliklərin sınağı, məlumat çevrilməsi və geri dönüş planı lazımdır. Hər yeniləmənin istifadəçiyə görünən dəyişiklik yaratması məcburi deyil, amma dəstək komandası təsir dairəsini bilməlidir.
Ehtiyat nüsxə və bərpa zamanı da sərhəd sualı var: bütün platforma yoxsa bir müştərinin məlumatı bərpa olunacaq? Bu, kiçik texniki detal deyil. Texniki dəstək planında məsuliyyət və yoxlama üsulu göstərilməlidir.
Nümunə: yeni təşkilatın ilk günü
Yeni müştəri platformaya qoşulanda onun boş məlumat məkanı, ilkin administratoru və ilk iş nümunəsi lazımdır. Bu şərti ssenaridə demo məlumatı yalnız təqdimat üçündürsə, real əməliyyatla qarışmamalıdır. Dəvət edilmiş əməkdaşın hansı təşkilata və rola daxil olduğu aydın görünməlidir.
Qoşulma səhv gedəndə yarımçıq təşkilatın vəziyyəti saxlanmalı və istifadəçiyə anlaşılan davam yolu verilməlidir. İstifadəçi eyni addımı təkrar etdikdə ikinci lazımsız təşkilatın yaranması ayrı problem yarada bilər. Buna görə təkrar və bərpa ssenarisi ilk təcrübənin də hissəsidir.
- Boş təşkilatın ilk ekranını yoxlayın.
- Dəvətin doğru təşkilata bağlandığını təsdiqləyin.
- Demo və real məlumatın ayrıldığını müqayisə edin.
- Yarımçıq qoşulmadan davam etməyi sınayın.
Bu sınaq qiymət planından əvvəl məhsulun istifadəyə nə qədər aydın başladığını göstərir. İnsan ilk işi görə bilmirsə, uzun funksiya siyahısı təcrübəni özü düzəltmir.
Tez verilən suallar
SaaS həmişə çox böyük komanda tələb edirmi?
Əhatə və xidmət tələbindən asılıdır. Kiçik başlanğıc mümkündür, amma çoxmüştərili məlumat ayrılığı ilk versiyada da əsas qaydadır.
Bütün müştərilər eyni bazada olmalıdırmı?
Bu arxitektura qərarıdır. Əsas meyar ayrılığın, əməliyyatın və bərpanın tələblərə uyğunluğudur.
Anbarex və Finex CV-də SaaS biznes platformaları kimi qeyd olunur. Öz məhsulunuz üçün biznes platforması hazırlanması çərçivəsində əvvəl bir əsas istifadə ssenarisini dəqiqləşdirin.
