Android-alkalmazás fejlesztése vállalati ERP-rendszerhez

ERP android kliens magánügyfeleknek

Az ERP android kliens akkor jó választás, ha a meglévő vállalatirányítási rendszer adataihoz mobilról is hozzá kell férni, de nem teljesen új rendszert szeretne az ügyfél. A cél általában egyszerű. Legyen egy Androidon működő felület, ahol a felhasználó látja a rendeléseket, készletet, ügyféladatokat, feladatokat vagy jóváhagyásokat. És ezt ne táblázatokból, levelekből vagy kézi másolással kelljen követni.

Magánügyfélként sokan nem nagy fejlesztőcéget keresnek, hanem olyan szabadúszó fejlesztőt, aki érti az üzleti logikát, tud kérdezni, és nem bonyolítja túl a munkát. Én azt látom, hogy ennél a szolgáltatásnál a legfontosabb nem csak maga az alkalmazás. Legalább ennyire fontos, hogy a szakember megértse, milyen ERP rendszerrel kell dolgozni, milyen adatokat kell kiolvasni, és mit kell biztonságosan visszaküldeni a rendszerbe.

Az ERP mobil kliens lehet egyszerű belső eszköz, ahol csak néhány funkció kell. Lehet összetettebb Android alkalmazás is, amely bejelentkezést, jogosultságokat, értesítéseket, adatfrissítést és naplózást kezel. Szerintem akkor érdemes ilyen munkát kiadni, ha a feladat pontosan körülírható. Nem kell minden részletnek késznek lennie az elején, de a fő folyamatokat tisztán kell látni.

A Qjob.hu felületén magánszemély is találhat olyan online szakembert, aki egyedi szoftveres feladatban segít. Itt nem az a lényeg, hogy valaki nagy csapatot mutasson, hanem az, hogy érthetően leírja a vállalt munkát, a határokat, a várható árat és a határidőt.

ERP mobil kliens felhasználási területei

Az ERP mobil kliens leggyakrabban akkor kerül szóba, amikor a meglévő rendszer túl nehézkes telefonról. A böngészős belépés nem mindig kényelmes. A menük túl nagyok, a képernyők lassúak, és a felhasználó sokszor csak három vagy négy funkciót használna. Ilyenkor egy külön Android kliens gyorsabb és tisztább megoldás lehet.

Tipikus feladat a raktári mozgások kezelése. A felhasználó beolvassa a terméket, módosítja a mennyiséget, rögzíti a státuszt, majd az adat bekerül az ERP rendszerbe. Ugyanez igaz a szállítási listákra, belső jóváhagyásokra, megrendelésekre vagy ügyféladatok megtekintésére. Nem minden esetben kell teljes körű alkalmazás. Sokszor egy szűk, de stabil mobil felület adja a legtöbb értéket.

Tapasztalatom szerint a jó Android kliens nem akar mindent lemásolni a nagy rendszerből. Inkább kiválasztja azokat a pontokat, ahol a mobil használat valóban segít. Például gyors adatkeresés, státuszváltás, dokumentum megnyitása, fénykép csatolása, értesítés vagy aláírás rögzítése. A túl sok funkció elsőre jól hangzik, de később drágítja a fejlesztést és lassítja a tesztelést.

ERP android kliens árak

Az ár főleg attól függ, hogy kész adatkapcsolat van-e az ERP rendszerhez, vagy a fejlesztőnek először ezt is ki kell alakítania. A felület önmagában ritkán a legnagyobb munka. A nehezebb rész az adatok kezelése, a jogosultság, a hibák kezelése és a biztonságos kapcsolat.

A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent. Nem azért, mert egy alacsonyabb áron dolgozó szakember biztosan rossz. Hanem azért, mert az ERP adatok érzékenyek, és egy félkész mobil kliens hibás készletet, duplikált rendelést vagy rossz státuszt okozhat. Én inkább kisebb első verziót kérnék, de azt rendesen megtervezve.

Ezek az összegek irányadó árak távoli munkára. Egy egyszerűbb ERP android kliens olcsóbb lehet, ha a rendszerhez már van jól dokumentált kapcsolódási lehetőség. Ha viszont régi, zárt vagy rosszul dokumentált ERP rendszerrel kell dolgozni, a fejlesztő több időt tölt elemzéssel és próbával. Ez természetes, de előre tisztázni kell.

Android ERP kliens szakember kiválasztása

Az Android ERP kliens szakember kiválasztásánál nem elég megnézni, hogy valaki tud-e mobilalkalmazást készíteni. Ennél a feladatnál fontos az üzleti folyamatok megértése is. Egy szép képernyő kevés, ha rossz adatot mutat, vagy nem kezeli jól a hibákat.

Érdemes olyan fejlesztőt keresni, aki kérdez a meglévő rendszerről, a felhasználókról, a jogosultságokról és a napi munkáról. Ha a szakember azonnal végleges árat mond egy összetett rendszerre, minden részlet nélkül, az számomra kockázatos jel. Egy komolyabb online fejlesztési feladatnál először legalább rövid műszaki egyeztetés kell.

A portfólió hasznos, de nem minden. Lehet, hogy a fejlesztő nem mutathat meg korábbi ERP munkát titoktartás miatt. Ilyenkor kérhető rövid leírás arról, milyen típusú adatkapcsolatokkal dolgozott, hogyan kezeli a bejelentkezést, milyen módon adja át a forráskódot vagy a kész telepítőcsomagot. A kommunikáció minősége is sokat elárul. Ha a válaszok homályosak, később a munka is könnyen az lesz.

Volt olyan eset, amikor egy ügyfél csak annyit kért, hogy legyen mobilról is elérhető a rendeléslista. A beszélgetés során derült ki, hogy háromféle jogosultság kell, külön készletinformáció, és a státuszmódosítás után automatikus értesítés. Ha ezt nem tisztázzák az elején, a projekt ára és ideje később hirtelen nő. Ez nem feltétlenül rossz szándék. Sokszor csak hiányos feladatleírás.

Távoli munka menete ERP kliensnél

A távoli munka menete akkor működik jól, ha az ügyfél nem csak ötletet ad, hanem hozzáférhető anyagokat is. Kell leírás a meglévő ERP rendszerről, képernyőképek, felhasználói folyamatok, tesztadatok és pontos elvárások. Nem minden adatot kell azonnal átadni, de a fejlesztő nem tud stabil Android klienst készíteni teljesen vakon.

Az első lépés általában a rövid egyeztetés. Itt kiderül, milyen Android eszközökön kell működni a kliensnek, kik használják, milyen adatok jönnek az ERP rendszerből, és milyen műveletek írnak vissza adatot. Ezután jöhet egy egyszerű feladatterv. Szerintem ez különösen fontos, mert a mobil felületnél minden felesleges funkció helyet és időt vesz el.

A fejlesztés több szakaszra bontható. Először készülhet egy kattintható vagy működő alapváltozat. Utána jön az adatkapcsolat, a képernyők pontosítása, majd a tesztelés. A visszajelzések online is jól kezelhetők, ha az ügyfél képernyőképpel, rövid videóval vagy pontos példával mutatja meg a hibát. Az olyan üzenet, hogy nem jó, kevés. A fejlesztőnek tudnia kell, hol, mikor és milyen adatra történt a hiba.

Az átadásnál tisztázni kell, mi kerül az ügyfélhez. Csak telepíthető alkalmazás, forráskód, rövid dokumentáció, hozzáférési adatok, vagy későbbi támogatási megállapodás is. Egy online szakember akkor dolgozik átláthatóan, ha ezt nem a végén kezdi el magyarázni.

ERP mobil fejlesztés minősége

Az ERP mobil fejlesztés minősége nem csak azon látszik, hogy az alkalmazás elindul-e. Fontos a sebesség, a hibakezelés, az adatbiztonság és az egyszerű használat. Egy belső kliensnél sokszor nem kell látványos megjelenés. De kell tiszta menü, érthető mezőnév, megbízható kapcsolat és olyan működés, amely nem zavarja meg a napi munkát.

Sokan ott hibáznak, hogy a mobil kliensre ugyanazt a logikát akarják rátenni, mint a teljes ERP rendszerre. Telefonon ez kényelmetlen. A felhasználó gyors műveleteket akar. Megnyit, ellenőriz, rögzít, ment. Ha mindenhez öt képernyő és sok görgetés kell, a kész alkalmazást nem fogják használni.

A másik gyakori hiba a tesztelés alábecsülése. Egy ERP android kliens esetében nem elég egyetlen sikeres belépés. Ki kell próbálni rossz adatot, megszakadó kapcsolatot, lassú választ, üres listát, hibás jogosultságot és párhuzamos módosítást is. Ezek unalmas részek, de éppen itt dől el, mennyire használható a végeredmény.

Én azt tartom jó jelnek, ha a szakember már a munka elején beszél korlátokról. Például arról, hogy bizonyos régi ERP rendszereknél nehezebb az adatok biztonságos elérése. Vagy arról, hogy az első verzióban nem kell minden funkció. Ez nem gyengeség. Inkább szakmai óvatosság.

Feladatleírás Android kliens fejlesztéshez

Egy jó feladatleírás sok pénzt és időt takarít meg. Nem kell hosszú dokumentumot írni, de legyen benne a cél, a felhasználók köre, a szükséges képernyők, az adatok forrása és a várható műveletek. Az Android kliens fejlesztés akkor indul tisztán, ha a fejlesztő nem találgatja, mire gondolt az ügyfél.

Hasznos leírni, milyen ERP rendszerhez kell kapcsolódni, van-e meglévő hozzáférési felület, milyen jogosultságok vannak, és kell-e magyar nyelvű kezelőfelület. Szintén fontos, hogy hány felhasználóval kell számolni, milyen gyakran frissülnek az adatok, és mi történjen, ha nincs kapcsolat. Egyes esetekben elég csak online működés. Máskor szükség lehet ideiglenes helyi mentésre is.

A javítások szabályát is érdemes előre rögzíteni. Mi számít hibának, mi számít új kérésnek, mennyi módosítás fér bele az árba, és milyen határidővel érkezzen a visszajelzés. Szerintem ez nem bizalmatlanság. Ez védi az ügyfelet és a szabadúszót is.

A végén a sikeres munka nagyon gyakorlati dolog. A magánügyfél kap egy használható mobil felületet, a szakember pedig pontos visszajelzések alapján tud dolgozni. Ha a cél kicsi, de tiszta, az első verzió gyorsabban elkészül. Utána lehet bővíteni, amikor már valódi használatból látszik, mire van még szükség.