Ana səhifəBloqGöndərişlərin izlənməsi API-sinin qiymətləndirilməsi üçün metrikalar: Konsepsiyanın sübutunda ölçüləcək 8 KPI

Göndərişlərin izlənməsi API-sinin qiymətləndirilməsi üçün metrikalar: Konsepsiyanın sübutunda ölçüləcək 8 KPI

17TRACK

Göndəriş izləmə API-sinin konsepsiya sübutunu səkkiz KPI əsasında qiymətləndirin: istifadə oluna bilən izləmə əhatəliliyi, hadisələrin tamlığı, statusun dəqiqliyi, yenilənmə gecikməsi, webhook çatdırılmasının etibarlılığı, API sorğularının etibarlılığı, inteqrasiya səyi və istifadə oluna bilən izlənmiş göndərişə düşən xərc. Onları yalnız uğurlu demo sorğuları ilə deyil, faktiki göndəriş çeşidiniz və razılaşdırılmış istinad məlumatları ilə müqayisə edərək ölçün. Testə başlamazdan əvvəl qəbul meyarlarını müəyyənləşdirin ki, nəticələr aydın tətbiqə keçid, düzəliş və ya rədd qərarını dəstəkləsin.

Shipment Tracking API Evaluation Metrics 8 Kpis to Measure in

Bu təlimat sifarişlərin idarə edilməsi sistemi, anbar platforması, müştəri dəstəyi prosesi və ya izləmə təcrübəsi üçün API seçən mühəndislik rəhbərləri, logistika əməliyyatları komandaları və satınalma üzrə məsul şəxslər üçündür. Aşağıdakı düsturlar təklif olunan qiymətləndirmə üsullarıdır, dərc edilmiş sənaye meyarları deyil. Hədləriniz itkin, gecikmiş və ya yanlış izləmə məlumatlarının nəticələrini əks etdirməlidir.

İstehsal mühitini təmsil edən test hazırlayın

Konsepsiya sübutu praktiki suala cavab verməlidir: bu inteqrasiya məqbul əməliyyat xərci ilə etibarlı göndəriş məlumatı təqdim edə bilərmi? Sandbox sorğu və cavabların işlədiyini göstərə bilər, lakin canlı daşıyıcı məlumatlarının keyfiyyətini təkbaşına sübut edə bilməz.

Uyğun qeydlər hələ əlçatandırsa, tarixi göndərişləri test zamanı müşahidə olunan canlı göndərişlərlə birləşdirin. Tarixi hallar statusların şərhini və qeyri-adi marşrutları yoxlamağa kömək edir. Yenilənmə gecikmələrini və bildirişlərin çatdırılmasını ölçmək üçün canlı hallar zəruridir.

  • Göndəriş çeşidinizi təmsil edin. Əsas daşıyıcıları, mənşə və təyinat kombinasiyalarını, xidmət növlərini və uyğun olduqda sərhədlərarası təhvil-təslimləri daxil edin. Vacib seqmentləri bir orta göstəricinin içində gizlətmək əvəzinə ayrıca hesabat verin.
  • Çətin marşrutları daxil edin. Gecikmiş göndərişləri, uğursuz çatdırılma cəhdlərini, geri qaytarmaları, qeyri-müəyyən daşıyıcı identifikasiyasını və hələ fiziki skan almamış göndərişləri test edin.
  • Mənfi testləri ayırın. Yanlış izləmə nömrələri və dəstəklənməyən sorğular xətaların idarə edilməsini yoxlamaq üçün faydalıdır, lakin etibarlı göndərişlər üzrə əhatəlilik balını səssizcə azaltmamalıdır.
  • İstinad sübutlarını qoruyun. Hər qiymətləndirmədə istifadə olunan daşıyıcı məlumatlarını, vaxt möhürlərini, mənbə saat qurşağını, izləmə identifikatorlarını və API cavablarını qeyd edin. Qeydlərdə şəxsi məlumatları və giriş məlumatlarını qoruyun.
  • Məsuliyyətləri razılaşdırın. Mühəndislik texniki ölçmələrə, logistika əməliyyatları göndəriş mənalarının təsdiqinə, maliyyə və ya satınalma isə xərc modelinin təsdiqinə cavabdeh olmalıdır.

Balları toplamazdan əvvəl ümumi müşahidə müddətindən istifadə edin və istifadə oluna bilən nəticənin nə sayıldığını müəyyənləşdirin. Bir neçə tətbiqi müqayisə edirsinizsə, hər birinə eyni göndəriş kohortunu və müqayisə oluna bilən test şərtlərini verin. Nəticəyə təsir edə biləcək konfiqurasiya fərqlərini qeyd edin.

1. İstifadə oluna bilən izləmə əhatəliliyi

Sual: API biznesinizin faktiki göndərdiyi göndərişlər üçün faydalı izləmə məlumatı qaytara bilirmi?

Düstur: İstifadə oluna bilən izləmə əhatəliliyi = istifadə oluna bilən izləmə nəticəsi olan uyğun test göndərişləri ÷ bütün uyğun test göndərişləri × 100.

Uyğunluğu provayderin dəstəklənən daşıyıcılar siyahısından asılı olmayaraq müəyyənləşdirin. Məsələn, məxrəcinizə planlaşdırılan tətbiqə keçid çərçivəsindəki və izləmə məlumatına malik olması məntiqli sayılacaq qədər köhnə olan bütün etibarlı göndərişlər daxil edilə bilər. Əks halda, dəstəklənməyən göndərişlərin çıxarılması ölçmək istədiyiniz əhatəlilik boşluğunu gizlədər.

İstifadə oluna bilən nəticə uğurlu qeydiyyatdan və ya HTTP uğur cavabından daha çoxunu ifadə etməlidir. Prosesinizin tələb etdiyi minimum məlumatı, məsələn, düzgün müəyyən edilmiş daşıyıcı və mənalı göndəriş statusunu dəqiqləşdirin. Etiket yaradıldı statusu fiziki təhvil verilmədən əvvəl etibarlı ola bilər, lakin sonrakı hərəkət hadisəsinin sübutu kimi hesablanmamalıdır.

Nəticələri daşıyıcı, marşrut və xidmət üzrə bölün. Həmçinin dəstəklənməyən xidmətləri, daşıyıcının identifikasiyası xətalarını, ilkin skan edilməmiş göndərişləri və müvəqqəti əldəetmə uğursuzluqlarını fərqləndirin. Ümumi bal qəbul edilə bilən görünsə də, biznes üçün kritik marşrut istifadəyə yararsız qala bilər.

Qərar qaydası: Məcburi göndəriş seqmentlərində əhatəliliyi tətbiqə keçid şərti edin. Yüksək ümumi faiz tətbiqin tələb etdiyi xidmət göstərilməyən seqmenti kompensasiya etməməlidir.

2. Tələb olunan hadisələrin tamlığı

Sual: API əməliyyatlarınızın ehtiyac duyduğu göndəriş mərhələlərini əhatə edirmi?

Düstur: Tələb olunan hadisələrin tamlığı = uyğunlaşdırılmış tələb olunan istinad hadisələri ÷ test zamanı müşahidə edilmiş bütün tələb olunan istinad hadisələri × 100.

Saxlanılmış daşıyıcı qeydlərindən və ya razılaşdırılmış başqa həqiqət mənbəyindən istinad hadisələri toplusu yaradın. Təsvirlər, vaxt möhürləri, məkanlar və hadisə növləri üçün uyğunlaşdırma qaydalarını müəyyənləşdirin. İki təsvir eyni hadisəni ifadə edirsə, eyni mətn tələb etməyin və hər daşıyıcının eyni mərhələ ardıcıllığını dərc etməsini gözləməyin.

Bir çox komanda üçün faydalı mərhələlərə fiziki qəbul, hərəkət, çatdırılma cəhdləri, istisnalar və yekun çatdırılma daxildir. Dəqiq siyahı prosesdən asılı olmalıdır. Dəstək komandası analitika panelinə lazım olmayan çatdırılma cəhdi hadisəsinə ehtiyac duya bilər.

Xam sətirləri saymaq əvəzinə fərqli hadisələri uyğunlaşdırın. Təkrarlanan skanlar tamlığı artırmamalıdır. Əksinə, provayder tətbiqinizin ehtiyac duyduğu məlumatı itirmədən artıq hadisələri birləşdirə bilər.

Əlçatan olmayan istinad qeydlərini təsdiqlənmiş itkin hadisələrdən ayrı saxlayın. İstinad mənbəyi hadisənin mövcud olub-olmadığını müəyyən edə bilmirsə, həmin halı provayder uğursuzluğu və ya uğuru kimi deyil, həll olunmamış hal kimi işarələyin.

Qərar qaydası: Kritik mərhələləri ayrıca qiymətləndirin. İstəyə bağlı məkan yeniləməsinin itməsi müştəri tədbirinə səbəb olmalı olan uğursuz çatdırılma cəhdinin itməsi ilə eyni deyil.

3. Normallaşdırılmış status dəqiqliyi

Sual: API daşıyıcı hadisələrini düzgün əməliyyat mənasına çevirirmi?

Düstur: Status dəqiqliyi = düzgün təsnif edilmiş qiymətləndirilən status müşahidələri ÷ bütün qiymətləndirilən status müşahidələri × 100.

API çıxışını nəzərdən keçirməzdən əvvəl logistika əməliyyatları gözlənilən təsnifatları müəyyənləşdirməlidir. Dəqiq hadisə tarixçəsi belə, inteqrasiya çatdırılma cəhdini çatdırılma kimi şərh edərsə və ya geri qayıdış hərəkətini adi çıxış tranziti hesab edərsə, yanıltıcı cari status yarada bilər.

Həm ayrı-ayrı hadisə uyğunlaşdırmalarını, həm də göndəriş səviyyəsində statusu qiymətləndirin. Mübahisələri araşdırmaq üçün mümkün olduqda orijinal daşıyıcı təsvirini normallaşdırılmış dəyərlə yanaşı saxlayın.

Hansı statusların digərləri ilə səhv salındığını göstərmək üçün qarışıqlıq matrisindən istifadə edin. Yanlış çatdırıldı təsnifatlarını ayrıca hesabatlaşdırın, çünki yanlış tamamlanma siqnalı müştəri mesajlarına, dəstək proseslərinə və sonrakı sifariş emalına təsir göstərə bilər.

Açıq naməlum kateqoriyası daxil edin. Ehtiyatlı naməlum nəticə əsassız qəti statusdan daha təhlükəsiz ola bilər, lakin yenə də əməliyyatla bağlı idarəetmə qaydasına ehtiyac duyur. Dəqiqliyi süni şəkildə artırmaq üçün naməlum halları məxrəcdən çıxarmayın.

Qərar qaydası: Geri dönməz və ya müştəriyə yönəlmiş tədbirləri işə salan xətalar üçün daha sərt qəbul şərtləri müəyyənləşdirin. Bir xəta növü qeyri-mütənasib risk daşıyırsa, yalnız ümumi dəqiqlik kifayət deyil.

4. Yenilənmə gecikməsi

Sual: Yeni daşıyıcı hadisəsinin sisteminizdə istifadə oluna bilməsi nə qədər vaxt aparır?

Əsas ölçü: Müşahidə olunan yenilənmə gecikməsi = sisteminizin istifadə oluna bilən yenilənməni davamlı şəkildə qeyd etdiyi vaxt − hadisənin razılaşdırılmış istinad mənbəyində ilk dəfə müşahidə edildiyi vaxt.

Daşıyıcı hadisəsi, istinad müşahidəniz, webhook-un qəbulu və uğurlu daxili emal üçün ayrıca vaxt möhürləri qeyd edin. Bu vaxt möhürləri müxtəlif suallara cavab verir. Skanın hadisə vaxtı daşıyıcının onu dərc etdiyi andan əvvəl ola bilər; buna görə yalnız skan vaxtının çıxılması izləmə provayderinin gecikməsini ayrıca ölçmür.

İstinad yoxlamaları ölçmə qeyri-müəyyənliyi yaradır. Daşıyıcı mənbəyini müəyyən intervallarla yoxlayırsınızsa, hadisənin dəqiq dərc vaxtını deyil, onu ilk dəfə nə vaxt gördüyünüzü bilirsiniz. Bu intervalı sənədləşdirin və nəticəni dəqiq provayder emal vaxtı deyil, müşahidə olunan gecikmə kimi təsvir edin.

Nümunə bunu dəstəklədikdə, vacib seqmentlər üzrə medianı və p95 kimi quyruq persentilini bildirin. Nümunə ölçülərini də daxil edin. Sürətli median daha kiçik, lakin əməliyyat baxımından vacib göndəriş qrupuna təsir edən uzun gecikmələri gizlədə bilər.

Qərar qaydası: Gecikmə hədəflərini tədbirlə əlaqələndirin. Gündəlik hesabat prosesi ilə vaxta həssas istisna bildirişi avtomatik olaraq eyni həddi paylaşmamalıdır. İtkin yeniləmələr tamlıq hesabatında görünməyə davam etməlidir və gecikmə nəticələrindən yoxa çıxmamalıdır.

5. Webhook çatdırılmasının etibarlılığı

Sual: Çatdırılma müvəqqəti uğursuz olduqda belə, gözlənilən yeniləmələr qəbul edən tətbiqinizə çatırmı?

Düstur: Webhook çatdırılmasının etibarlılığı = razılaşdırılmış müddət ərzində davamlı şəkildə qəbul edilmiş fərqli gözlənilən bildirişlər ÷ bütün gözlənilən bildirişlər × 100.

Gözlənilən bildirişlər toplusunu sənədləşdirilmiş abunə qaydaları, müşahidə olunan mənbə dəyişiklikləri və nəzarətli testlər əsasında müəyyənləşdirin. Hər xam daşıyıcı skanının ayrıca bildiriş yaratmalı olduğunu düşünməyin. Gözlənilən toplu müstəqil şəkildə müəyyənləşdirilə bilmirsə, nəticəni tam çatdırılma etibarlılığı kimi deyil, qismən nəticə kimi bildirin.

Müvəqqəti server xətalarını, bağlantı kəsilmələrini, dublikat mesajları, gecikmiş təsdiqləri və bərpanı test edin. Sənədləşdirilmiş yenidən cəhd davranışını və cəhdlər dayandıqdan sonra nə baş verdiyini təsdiqləyin. Pozucu testlər üçün istehsal xarici göndərişlərdən və ya təcrid olunmuş mühitdən istifadə edin.

HTTP cəhdlərini deyil, fərqli bildirişləri sayın. Təkrar çatdırılma cəhdləri surəti artırmamalıdır. Tətbiq dizaynınıza uyğun olaraq mesajı təhlükəsiz şəkildə qeyd etdikdən və ya növbəyə əlavə etdikdən sonra endpoint-iniz qəbulu təsdiqləməlidir.

Provayder çatdırılmasını və daxili emalı ayrıca hesabatlaşdırın. Webhook uğurla çata bilər, lakin tətbiqiniz sifarişi yeniləməyə bilər. Dublikat mesajların dublikat müştəri bildirişləri yaratmaması üçün idempotent emalı test edin.

Qərar qaydası: Normal şəraitdə uğurlu çatdırılmadan əlavə, buraxılmış yeniləmələr üçün nümayiş etdirilmiş bərpa yolu tələb edin.

6. API sorğularının etibarlılığı

Sual: API gözlənilən iş yükünüz altında uğurla cavab verirmi?

Düstur: API sorğularının etibarlılığı = vaxt aşımı müddətiniz ərzində gözlənilən, təhlil edilə bilən cavab qaytaran etibarlı sorğular ÷ cəhd edilmiş bütün etibarlı sorğular × 100.

Sənədləşdirilmiş autentifikasiya, faydalı yük və müqavilə ilə müəyyən edilmiş sorğu limitlərindən istifadə etməklə etibarlı sorğunu müəyyənləşdirin. Yanlış formatlı sorğuları ayrıca inteqrasiya qüsurları kimi izləyin. Həmçinin ümumi balın şərh edilə bilməsi üçün məhdudlaşdırmanı, autentifikasiya xətalarını, vaxt aşımını və server xətalarını ayrıca hesabatlaşdırın.

Göndəriş qeydiyyatı, əldəetmə və tətbiqinizin faktiki istifadə etdiyi digər endpoint-ləri test edin. Uğurlu yalnız oxuma testi kütləvi ilkin qeydiyyatın məqbul davranacağını sübut etmir.

Etibarlılıqla yanaşı cavab vaxtı persentillərini də ölçün. İlk cəhd uğurunu təkrar cəhdlərdən sonrakı yekun uğurdan ayırın: təkrar cəhd əməliyyatı bərpa edə bilər, lakin gecikmə, trafik və emal işini artırır.

Google-un Site Reliability Engineering təlimatı gecikmə, trafik, xətalar və doyma göstəricilərini faydalı monitorinq siqnalları kimi müəyyənləşdirir. Uğursuzluqlarla yanaşı sorğu həcmini və paralelliyi qeyd etməklə bu çərçivəni POC-a tətbiq edin. Trafik yaratmazdan əvvəl yük testinin limitlərini razılaşdırın.

Qərar qaydası: Qısa POC nəticəsini uzunmüddətli əlçatanlığın sübutu və ya müqavilə öhdəliklərinin əvəzi kimi deyil, test edilmiş iş yükü və dövr haqqında sübut kimi qəbul edin.

7. İnteqrasiya və bərpa səyi

Sual: İnteqrasiyanı təhlükəsiz şəkildə işlətmək üçün nə qədər mühəndislik işi tələb olunur?

Əsas ölçü: İnteqrasiya səyi = razılaşdırılmış istehsala hazırlıq yoxlama siyahısını tamamlamaq üçün tələb olunan və qeyd edilmiş mühəndislik saatları.

Hər tətbiq üçün eyni yoxlama siyahısından istifadə edin. Buraya autentifikasiya, qeydiyyat, webhook qəbulu, status uyğunlaşdırılması, dublikatların aradan qaldırılması, uzlaşdırma, monitorinq, giriş məlumatlarının idarə edilməsi, yerləşdirmə və əməliyyat sənədləri daxil edilməlidir. Təqvim üzrə keçən vaxtı praktiki mühəndislik vaxtından ayrıca qeyd edin.

İlk uğurlu sorğudan sonrakı işi ölçün. Sürətli nümayiş xətaların idarə edilməsi, tarixi bərpa və dəstək alətlərində əhəmiyyətli işi gizlədə bilər.

Bərpa məşqi keçirin: istehlakçınızı dayandırın, onu bərpa edin və təsirlənmiş göndəriş statuslarının uzlaşdırılıb-uzlaşdırıla bilməyəcəyini müəyyənləşdirin. Bərpa müddətini, əl ilə müdaxilələri və həll olunmamış qeydləri qeyd edin. Hansı problemlərin tətbiqinizdən, hansılarının isə provayder yardımından qaynaqlandığını göstərin.

Qərar qaydası: Səyi yalnız eyni hazırlıq səviyyəsində müqayisə edin. Monitorinqsiz prototip test edilmiş bərpaya malik istehsala hazır tətbiqdən inteqrasiya baxımından daha asan görünməməlidir.

8. İstifadə oluna bilən izlənmiş göndərişə düşən xərc

Sual: Tələblərinizə cavab verən göndəriş məlumatını əldə etmək nə qədər başa gələcək?

Düstur: İstifadə oluna bilən izlənmiş göndərişə düşən xərc = dövr üzrə aid edilə bilən ümumi əməliyyat xərci ÷ həmin dövrdə razılaşdırılmış istifadəyə yararlılıq meyarlarına cavab verən fərqli göndərişlər.

Ödənişlərin necə işlədiyini fərz etmək əvəzinə yazılı təklifdən və ya tətbiq olunan kommersiya şərtlərindən istifadə edin. Qeydiyyat cəhdlərinin, dublikat təqdimetmələrin, yenidən izləmənin, limitdən artıq istifadənin, tarixi girişin və ayrıca ödənişli xidmətlərin necə hesablandığını təsdiqləyin. Bunlar yoxlanılmalı suallardır, əvvəlcədən fərz ediləcək ödənişlər deyil.

Daxili ümumi xərci hesablayarkən infrastruktur və təkrarlanan əməliyyat işlərini daxil edin. Birdəfəlik tətbiq xərclərini ayrıca göstərin və ya onların hansı dövr ərzində amortizasiya edildiyini açıqlayın.

POC-da test edilmiş eyni göndəriş çeşidindən istifadə etməklə gözlənilən və pik göndəriş həcmlərini modelləşdirin. Proqnozları təxmin kimi işarələyin. Etibarlı əməliyyat xərci məlumatları mövcud deyilsə, daha məhdud provayder ödənişi göstəricisini bildirin və xaric edilən xərcləri göstərin.

Qərar qaydası: Xərcləri yalnız minimum keyfiyyət tələbləri ödənildikdən sonra müqayisə edin. Qeydiyyatdan keçmiş izləmə nömrəsinə düşən aşağı xərc mütləq faydalı nəticəyə düşən aşağı xərc demək deyil.

Nəticələri tətbiqə keçid qərarına çevirin

Hər KPI üçün tərifi, qəbul həddini, müşahidə olunan nəticəni, nümunə ölçüsünü, seqment bölgüsünü, həll olunmamış halları və məsul şəxsi əks etdirən qiymətləndirmə cədvəli yaradın. Nəticələri nəzərdən keçirməzdən əvvəl hədləri müəyyənləşdirin. Hər göndəriş əməliyyatına uyğun universal keçid faizi yoxdur.

Kritik əhatəlilik, təhlükəli status xətaları, bərpa qabiliyyəti və digər danışıqsız tələblər üçün məcburi keçid şərtlərindən istifadə edin. Çəkili qiymətləndirməni yalnız bu şərtlər ödənildikdən sonra tətbiq edin. Əks halda, aşağı qiymət və ya sürətli cavab müddəti ciddi əməliyyat uğursuzluğunu riyazi olaraq gizlədə bilər.

Üç nəticədən birini seçin: məhdudlaşdırılmış tətbiqə keçidi təsdiqləmək, müəyyən edilmiş qeyri-müəyyənlikləri aradan qaldırmaq üçün POC-u uzatmaq və ya test edilmiş konfiqurasiyanı rədd etmək. Uzatma çatışmayan sübutu və onu bağlayacaq şərti dəqiq göstərməlidir. Tətbiqə keçid zamanı istehsal göstəricilərinin müqayisə oluna bilməsi üçün eyni tərifləri izləməyə davam edin.

Əgər 17TRACK qısa siyahınızdadırsa, testiniz üçün uyğun inteqrasiya tələblərini təsdiqləməyə başlanğıc nöqtəsi kimi onun Tracking API page və official API documentation səhifələrindən istifadə edin. Eyni qiymətləndirmə cədvəlini və canlı göndəriş yoxlamalarını tətbiq edin; sənədlərin nəzərdən keçirilməsi ölçülmüş nəticələri əvəz etmir.

Tez-tez verilən suallar

İzləmə API-si POC-una neçə göndəriş daxil edilməlidir?

Universal nümunə ölçüsü yoxdur. Hər biznes üçün kritik seqmenti və prosesləriniz üçün əhəmiyyətli istisnaları qiymətləndirmək üçün kifayət qədər müşahidə daxil edin. Seqment səviyyəsində sayları və qeyri-müəyyənliyi göstərin. Bir daşıyıcı üzərində cəmlənmiş böyük nümunə yoxlanılmamış daşıyıcılar və marşrutlar üzrə etibarlılığı sübut edə bilməz.

Sandbox canlı göndəriş testini əvəz edə bilərmi?

Sandbox sorğuların qurulmasını, təhlilini və tətbiq davranışını təsdiqləyə bilər. Lakin o, canlı hadisələrin tamlığını, daşıyıcının dərc gecikmələrini və istehsal bildirişlərinin göstəricilərini təkbaşına müəyyən edə bilməz. Sandbox-dan canlı testlə yanaşı istifadə edin, onu əvəz kimi deyil.

Daşıyıcının veb-saytı ilə API-si ziddiyyət təşkil edərsə nə etməli?

Hər iki qeydi müşahidə vaxtları ilə birlikdə qoruyun. Məsuliyyət təyin etməzdən əvvəl saat qurşağının çevrilməsini, göndəriş identifikasiyasını, dərc vaxtını və statusun şərhini yoxlayın. Mənbələrin heç biri uyğunsuzluğu aradan qaldırmırsa, onu həll olunmamış kimi işarələyin və uğur və ya uğursuzluq etiketi tətbiq etmək əvəzinə araşdırın.

İtkin hadisələr yavaş yenilənmələr kimi hesablanmalıdırmı?

Ölçüləri ayrı saxlayın. Heç vaxt çatmayan hadisə sübutdan asılı olaraq tamlıq uğursuzluğu və ya həll olunmamış haldır. Gecikmə çatan hadisələri ölçür. Hər ikisini birlikdə hesabatlaşdırın ki, itkin hadisələr gecikmə göstəricilərini süni şəkildə yaxşı göstərməsin.

POC keçdikdən sonra nə baş verməlidir?

Nəzarətli əhatə dairəsinə tətbiqə keçin, uzlaşdırma və geri qaytarma prosedurlarını qoruyun və eyni KPI-ləri izləməyə davam edin. Yalnız istehsal nəticələri bunu dəstəklədikdə əhatə dairəsini genişləndirin. Daşıyıcı çeşidiniz, göndəriş həcminiz, inteqrasiya konfiqurasiyanız və ya kommersiya şərtləriniz dəyişdikdə yenidən qiymətləndirin.

Mənbələr

Loading