HTML

ERP és CRM - szakértői szemmel

Knipfer Tibor vagyok, közgazdászként végeztem a Pénzügyi és Számviteli Főiskolán (jelenleg Budapesti Gazdasági Főiskola). Főiskolai éveimtől kezdve érdeklődöm a vállalatirányítási rendszerek iránt. Többféle integrált rendszer közel 100 bevezetésében vettem részt eddig. 2001-ben csatlakoztam a MultiSoft Kft-hez, ahol Microsoft Dynamics NAV tanácsadással foglalkozom. Konzulensi teendőim mellett Microsoft Dynamics NAV termékmenedzserként a szoftver nyelvi és jogi lokalizációját is támogatom.

Hány vállalati mobilappunk legyen?

2014.11.25. 09:40 Knipfer_Tibor

Innovatív cég lévén a MultiSoft Kft. is képviseltette magát a november 12-én tartott HWSW által szervezett App!mobile konferencián a MOM Parkban.

Az idén negyedszer megrendezésre kerülő App!mobile mobiltermék-fejlesztői konferencián Brecsok Sándor, MobileNAV Partner Manager tartott előadást Hány vállalati mobilappunk legyen? címmel.

Előadásában állást foglalt többek között a Natív kliens használata mellett, felhívta a figyelmet az Offline működés és a konfigurálhatóság fontosságára.

Nem utolsó sorban arról is beszámolt, hogyan érdemes mobil ERP rendszert kialakítani.

Ellentétben a mainstreammel állást foglaltunk a Natív kliens használata mellett a böngésző vagy Cross platform megoldásokkal szemben. A böngészős megoldással sok platformon elérhetőek leszünk, de ha például banki átutalást végzünk, a bank natív megoldását használjuk, a natív alkalmazást a platformra lehet szabni. Annak ellenére, hogy UI kifejlesztése nagyságrendileg több munka, de eredményeként jobban használható kliensünk lesz. Előnyként említhetjük az egyes platformokon futó funkciók kihasználását, mint például instant telefon, böngésző, térkép integráció.

WinCE alapú operációs rendszer csak natív alkalmazással működtethető, ha a browseres megoldást választjuk fejlesztést igényel. A vonalkódolvasás sokkal inkább natív alkalmazással oldható meg.

Hogyan építsük be a Motorola sdk-t a böngészőnkbe?

Az offline megoldás szinkronizációja sarkalatos pont. Aszinkron szinkronizálást nem célszerű végezni. A szinkronos hibákat Technológiai hiba és Üzleti hibára bontjuk. Üzleti szinkron hiba mindig lesz, ami azonnal kívánja az operátor beavatkozását.

Kimondhatjuk, hogy online a jövő és a normális működés, melynek előnyei azonnali készletinformáció, akár a back office-ba telefonon beérkező hívások kontakt infóinak azonnali ismerete, ami értékesítőként vagy szerviz technikusként is fontos információ. További előny az eladás a helyszínen való azonnali lekönyvelése és számla kiállítása. A gyártásban a teljesítmény kimenet könyvelése nélkül nem is lehet a következő fázist megkezdeni. Munkaidőt anyagfelhasználást is előnyös online jelenteni. 

Ha a raktárban az áru nincs betárolva, nem lehet kivételezni ez a folyamat is online regisztrációt kíván. A bin content csak online működik. Ha a betárolási, elraktározási, kiszedési, kiszállítási utasítások online érkeznek az appra abban az esetben könnyen szervezhető a munka. Offline üzemmódban jelenleg az ERP funkciókat nem lehet leképezni, túl bonyolult egy ERP ben levő üzleti logika ehhez.  A cégeknek általában nehézséget okoz a folyamatok megfogalmazása, csak nagyon egyszerű támogató folyamatok oldhatóak meg ezen a módon, mint például a munkaidő nyilvántartás, szabadság nyilvántartás.  Az offline működés ugyanakkor elengedhetetlen üzletileg kritikus folyamatok lekövetéséhez. 

A mi megoldásunk a normál folyamat online működtetése megerősítve a core rész offline lekövetésével. Legtöbb piaci szereplő applikációja csak a core működést nyújtja, például alkalmas offline eladásra, de nem alkalmas lekövetni minden aspektusát az üzletkötésnek. Az értékesítés példánál maradva, a legjobb ár kalkuláció, ügyfél és termék, ügyfél árcsoport, akciós ár, mennyiségi rabatt, hűség rabatt, a felsoroltak az engedményre, sorengedmény, számlaengedmény és ez csak az ár. Viszont egy legutolsó árral kell tudni eladni akkor is, ha nincs szignál, számlát vagy szállítólevelet kiállítani, rendelést rögzíteni, katalógust prezentálni, kosarat összeállítani, regisztrálni hibakódot a szerviz technikusnak, beépülő alkatrészt könyvelni, sorozatszámot rögzíteni, jótállási adatokat frissíteni, fotót készíteni, GPS adatokat rögzíteni. A tábla, rekord szintű szinkronizáció kívánatos, de mező szintű már túl nagy időveszteség a delták generálása miatt.  A szinkronizálás optimalizáció nem adatbázis replikáció.

Ha az offline működés nem kiküszöbölhető, az ügyfelek elvárása az automatikus szinkronizáció, csakhogy az offline üzleti logika mindig kevesebb lehetőset nyújt, mint az ERP üzleti logika ezért szükségessé válik a szinkronizáció közben az adatok validálása az ERP-vel. A validáláshoz elengedhetetlen az operátor felügyelete, olyan esetek elkerülése miatt, mint például egy zárolt cikk eladása offline üzemmódban. Rosszul tervezett szinkronizáció tömkelegére van példa a piacon. Sokszor kell az IT segítsége a szinkronizációhoz, és ezzel meg is öltük a terméket, mert összemosódik a technikai hiba az üzleti hibával. Például rendelések egyszerre felvitele egy rossz hatáskörkiosztás következménye. Abban az esetben, ha csak az eltérések kerülnek letöltésre, a delta legenerálása hosszú időt vesz igénybe és nem csak egy mezőhöz kell a delta, hanem az egyszerűsített offline logikához is.  Az offline optimalizáció nem adatbázis replikáció.

Architechtura: Mobile szerver vs. Közvetlen kapcsolat az ERP-hez kérdéskörben mi nem tartjuk ildomosnak bármely middleware használatát, időveszteség és limitálja az elérhető üzleti logikát. Csak a teljes ERP üzleti logika futtatásával érdemes ERP mobilt készíteni. Szerintünk a Middleware data warehouse szükségtelen, ez normál esetben egy tranzakciós adatbázis kell, legyen minél gyorsabb committel. Ha csak egy middlewareb-el commitelek, az nem igazán megoldás, mert a következő mezőben az előző commitot megelőző üzleti logika eredményére van szűkség. Azok a megoldások, amelyek plusz adatbázist képeznek offline módban, csak adott esetben szinkronizálnak, ami mindenképpen adat és sebességveszteség.

Konfigurálható alkalmazás alapkövetelmény, hogy semmi ne legyen hardcode-olva a mobilappban, ezzel az ügyfélnek egy szabadságot biztosítva, nincs vendor lock-in.

A kliens a konfigurációt használja, amit akár az ügyfél testre szabhat, adat és kód management segítségével. Ily módon a hardcore szellemi tulajdon, a workflow az ügyfélé, a kód a fejlesztőé.

Az ügyfél nem szeret függeni, az ERP megvásárlásával nem kerül kiszolgáltatott helyzetbe a cég fejlesztőinek.

Fontos kérdés, hogy teljes funkcionalitás szükséges mobilon is? Szerintünk igen! Ne csak akkor kerüljön kifejlesztésre egy új feature, amikor igény lesz rá, időt és pénzt megtakarítva.

Sziget rendszerek után integrált rendszerek következnek az evolúcióban. A célszoftverek integrálásával, integrált rendszerek elérése a cél. A testreszabás folyamata során először Modulok majd csomag (out-of-the-box) megoldások készülnek. Miniappok korszaka jelen idő, de mi a jövőben gondolkodunk, ezért szállítunk már ma teljes üzleti logikát elérő mobil megoldást offline móddal és szabadon bővíthető konfigurációval.






Szólj hozzá!

A bejegyzés trackback címe:

https://erp-crm.blog.hu/api/trackback/id/tr456930991

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása