Bakıda avtopark idarəetmə proqramının hazırlanması logistika, distribusiya, tikinti, texniki xidmət və korporativ nəqliyyat komandalarına zənglər, Excel faylları və ayrı GPS ekranları əvəzinə vahid, idarə olunan iş mühiti verir. Praktik platforma sadəcə xəritədə avtomobil nöqtələri göstərmir. O, hər avtomobilin, səfərin, sürücü növbəsinin, yanacaq xərcinin, texniki xidmət tapşırığının və operativ qərarın eyni əməliyyat modelində izlənməsini təmin edir.

Hazır GPS həlli izləmə üçün kifayət edə bilər, lakin şirkətin öz qaydaları, təsdiq mərhələləri, hesabat strukturu, yanacaq prosesi və ya ERP inteqrasiyası olduqda standart sistem tez məhdudlaşır. Bu nöqtədə fərdi fleet operations platform development layihəsi məlumatı başqa bir silosda toplamaq üçün yox, mövcud əməliyyatları bir-birinə bağlamaq üçün qurulmalıdır.

Avtopark platforması hansı problemi həll etməlidir?

Layihəyə modul siyahısından deyil, gündəlik qərarlardan başlayın. Dispetçer hansı avtomobilin uyğun, boş və texniki cəhətdən hazır olduğunu bilməlidir. Nəqliyyat rəhbəri gecikən texniki xidmətləri, sığorta və sənəd bitmə tarixlərini görməlidir. Maliyyə komandası yanacaq kartı, çek və ya idxal olunan tranzaksiya əsasında xərcin hansı avtomobilə, marşruta və ya xərc mərkəzinə aid olduğunu izləməlidir. Rəhbərlik isə xam GPS məlumatı yox, etibarlı əməliyyat göstəriciləri görməlidir.

Yaxşı layihənin əsas prinsipi budur: hər hadisənin sahibi, vəziyyəti, vaxtı və sübutu olmalıdır. Məsələn, “yanacaq xərci” təkcə məbləğ deyil; o, avtomobil, sürücü, odometr göstəricisi, təchizatçı, çek, təsdiq edən şəxs və sonradan düzəliş edilərsə audit izi ilə əlaqəli qeyddir.

Praktik sistem arxitekturası: bir həqiqət mənbəyi, bir neçə inteqrasiya

Platformanın mərkəzində əməliyyat məlumat modeli yerləşir. Avtomobil, qoşqu, avadanlıq, sürücü, şöbə, baza, müştəri, xərc mərkəzi və sənəd kimi əsas obyektlər unikal identifikatorlarla idarə edilir. GPS, yanacaq kartı provayderi, mühasibat sistemi və mobil tətbiq həmin əsas qeydlərə hadisə və ya tranzaksiya əlavə edir. Beləliklə, inteqrasiya nəticəsində ikinci, ziddiyyətli məlumat bazası yaranmır.

1. Avtomobil və aktiv pasportu

Hər avtomobil üçün dövlət nömrəsi, VIN və ya daxili kod, kateqoriya, yük tutumu, filial, məsul şəxs, odometr, istismar statusu və əlaqəli sənədlər saxlanmalıdır. Statuslar “aktiv” və “qeyri-aktiv”lə məhdudlaşmamalıdır: servis gözləyir, qəza səbəbilə bloklanıb, icarədədir, ehtiyatdadır və ya utilizasiyadadır kimi vəziyyətlər dispetçerin səhv təyinat verməsinin qarşısını alır.

2. Sürücü profili və təyinat qaydaları

Sürücü profili əlaqə məlumatından daha genişdir: sürücülük vəsiqəsi kateqoriyası, etibarlılıq tarixi, təlim statusu, növbə, icazə verilən avtomobil kateqoriyaları, qalıq məzuniyyət və ya daxili məhdudiyyətlər lazım ola bilər. Sürücü-avtomobil təyinatı tarixçəli olmalıdır. Bu, müəyyən tarixdə avtomobili kimin idarə etdiyini, zədə və ya cərimə araşdırmasında hansı kontekstin qüvvədə olduğunu dəqiq göstərir.

3. Dispetçer, səfər və iş tapşırıqları

Driver dispatch software development üçün əsas elementlər sorğunun qəbulu, planlaşdırma, təyinat, icra, istisna və bağlanış mərhələləridir. Tapşırıqda götürülmə və çatdırılma nöqtələri, vaxt pəncərəsi, yük və ya xidmət növü, tələb olunan avtomobil tipi, müştəri göstərişi və məsul şəxs olmalıdır. Dispetçer avtomobil təyin edəndə sistem uyğunluq yoxlamaları aparmalıdır: avtomobil aktivdirmi, servis bloklaması varmı, sürücünün sənədləri qüvvədədirmi, eyni vaxtda başqa təsdiqlənmiş tapşırıq varmı?

Tapşırığın status keçidləri sərbəst mətnlə deyil, qaydalarla idarə edilməlidir: planlaşdırılıb, təyin edilib, yoldadır, yerinə çatıb, tamamlanıb, ləğv olunub. Ləğv və ya gecikmə səbəbi ayrıca strukturlaşdırılmış sahə olmalıdır ki, sonradan hesabat almaq mümkün olsun.

Texniki xidmət: təqvim yox, riski idarə edən proses

Vehicle maintenance management system odometr, mühərrik saatı, tarix və ya nasazlıq hadisəsi əsasında profilaktik servis planları qurmalıdır. Məsələn, müəyyən yürüşdən sonra yağ dəyişimi, müəyyən tarixdə sığorta yenilənməsi və ya xəbərdarlıq kodundan sonra yoxlama tapşırığı yaradıla bilər. Ən mühüm qayda budur: kritik servis gecikməsi olduqda avtomobilin dispetçer üçün seçilə bilməsi biznes qaydası ilə məhdudlaşdırılmalıdır.

  • Servis planı, intervalı və növbəti icra meyarı;
  • İş sifarişi, görülən işlər, istifadə olunan hissələr və əmək vaxtı;
  • Xarici servis mərkəzi, təklif, faktura və təsdiq prosesi;
  • Qüsur bildirişi, prioritet, foto və nəticə;
  • Texniki xidmət xərclərinin avtomobil və kateqoriya üzrə tarixçəsi.

Texniki xidmət tarixçəsi sonradan yalnız xərc analizi üçün yox, avtomobilin dəyişdirilməsi, icarə müqaviləsi və ya satınalma qərarı üçün də etibarlı baza yaradır.

Yanacaq və xərc nəzarətində “məbləğ” kifayət deyil

Fuel tracking software Azerbaijan üçün əl ilə daxil edilən çeklər, yanacaq kartı faylları və ya provayder API-si eyni yoxlama axınında normallaşdırıla bilər. Sistem yanacaq növünü, litri, məbləği, odometri, stansiyanı, avtomobili, sürücünü və sübut sənədini bağlamalıdır. Odometr dəyişimi, normadan kənar sərfiyyat, eyni tarixdə təkrarlanan tranzaksiya və ya təyin olunmamış avtomobil kimi istisnalar “pozuntu sübutu” kimi deyil, araşdırma növbəsi kimi təqdim edilməlidir.

Yanacaq, servis, təkər, sığorta, cərimə, icarə və digər xərclər üçün vahid kateqoriyalar yaradın. Hesabatlarda ümumi xərc, kilometrə düşən xərc, avtomobil sinfi üzrə xərc və plan-fakt müqayisəsi yalnız mənbə məlumatının keyfiyyəti və hesablama qaydaları aydın olduqda mənalıdır.

GPS və mobil tətbiq inteqrasiyasını düzgün qurmaq

GPS provayderini sistemin “əsas həqiqəti” kimi qəbul etmək əvəzinə, onu telemetriya mənbəyi kimi inteqrasiya etmək daha təhlükəsizdir. Platforma cihaz identifikatorunu düzgün avtomobilə bağlamalı, gələn koordinatları zaman möhürü ilə saxlamalı, gecikmiş və ya təkrarlanan hadisələri idarə etməli, xəritə ekranında isə yalnız əməliyyat üçün lazım olan məlumatı göstərməlidir. Marşrutdan kənarlaşma, geozona girişi, uzun dayanma və ya cihazın əlaqəsinin kəsilməsi üçün xəbərdarlıqlar konfiqurasiya edilə bilər.

Sürücü mobil tətbiqi növbənin başlanması, yoxlama siyahısı, qüsur fotosu, tapşırıq statusu, odometr və yanacaq çekinin göndərilməsi üçün faydalıdır. Lakin fon rejimində lokasiya izləmə cihazın batareyasına və istifadəçi məxfiliyinə təsir edir. Mobil hissə yalnız həqiqətən tələb olunan izləmə tezliyi, aydın razılıq mətni və iş vaxtı siyasəti ilə hazırlanmalıdır. POLADO bu cür rol əsaslı mobil axınları mobil tətbiqlərin hazırlanması xidməti çərçivəsində veb platforma ilə birlikdə layihələndirə bilər.

İcazələr, audit izi və məlumat keyfiyyəti

Rolları “administrator” və “istifadəçi” səviyyəsində saxlamayın. Dispetçer tapşırıq yarada və təyinat verə, mexanik servis işini bağlaya, maliyyə əməkdaşı xərc təsdiqləyə, rəhbər isə yalnız hesabat görə bilər. Filial, şöbə və ya avtomobil qrupu üzrə məlumat məhdudiyyətləri də ayrıca nəzərə alınmalıdır.

Sürücü təyinatı, odometr düzəlişi, xərc məbləği, sənəd statusu, servis bloklaması və ixrac kimi həssas əməliyyatlar üçün “kim, nəyi, nə vaxt və əvvəlki dəyər nə idi” suallarına cavab verən audit izi saxlayın. Audit qeydinin məqsədi istifadəçini izləmək deyil; səhvin araşdırılması, məlumatın bərpası və təsdiqlənmiş prosesin qorunmasıdır. OWASP tətbiq hadisələri üçün əməliyyat və təhlükəsizlik qeydlərinin məqsədəuyğun, qorunan və mərkəzləşdirilmiş idarə edilməsini tövsiyə edir.

Layihəyə haradan başlamaq lazımdır?

  1. Əməliyyat xəritəsi yaradın: sifarişdən səfərin bağlanmasına, qüsurdan təmirin təsdiqinə, yanacaq çekindən maliyyə bağlanışına qədər real axınları sənədləşdirin.
  2. Sahiblikləri müəyyən edin: hansı məlumatın sahibi kimdir, hansı sistem mənbədir, kim düzəliş və təsdiq edə bilər?
  3. İlk buraxılışı məhdudlaşdırın: aktiv pasportu, dispetçer, servis xəbərdarlıqları, əsas xərc qeydiyyatı və vacib hesabatlarla başlayın.
  4. İnteqrasiyaları mərhələli qoşun: əvvəl GPS və ya yanacaq məlumatını etibarlı idxal edin, sonra API və avtomatik sinxronlaşdırma əlavə edin.
  5. Ölçülə bilən qəbul meyarları yazın: məsələn, təyinat zamanı bloklanan avtomobilin seçilməməsi, gecikmiş sənədin xəbərdarlıq yaratması və eyni tranzaksiyanın iki dəfə yazılmaması.

Bu məhsulun uğuru ekranların sayından yox, istisnaların necə idarə olunmasından asılıdır. POLADO veb platformaların hazırlanması xidməti ilə avtoparkın iş qaydalarına uyğun təhlükəsiz idarəetmə sistemi, UI/UX və məhsul dizaynı ilə isə dispetçer və rəhbərlər üçün sürətli əməliyyat ekranları yarada bilər. Mövcud sistemləri qiymətləndirmək, inteqrasiya sərhədlərini müəyyənləşdirmək və mərhələli texniki plan hazırlamaq üçün texniki dəstək və konsaltinq üzrə POLADO komandası ilə məsləhətləşin.