ERP és az okos mobilok
2011-10-06T18:26:14+02:00
2011-10-10T21:48:23+02:00
2022-06-29T07:50:33+02:00
  • Sikerült már létrehoznod ezzel a csodaalkalmazással valami konkrétat? Amennyiben igen, mi az URL-je?


    Komolyat nem, elég új téma a mobil fejlesztés számomra, és nem is akarok kismillió nyelvet, környezet megtanulni, és minél kevesebb mobilspecifikus sdk átnyálazásával szeretném megúszni. Egyelőre keresem a megfelelő multi-mobilplatformos keretrendszert, és eddig ez tűnik nyerőnek.
    Egyelőre tesztelgetem, de úgy tűnik, hogy amit javascript + html-el le lehet írni működik. Legalábbis androidon tesztelve úgy tűnik.

    Amit eddig próbáltam, hogy js-ből 100 képből álló képszekvenciát lejátszok (50 ms-os frissítéssel), egyszerre 5 példányban. Működik simán, a gagyi okostelefonom prociját se terheli be túlzottan. (25-30% az előbbi példával)
    Persze lehet, hogy vannak sokkal optimálisabb megoldások (pl foly. animáció esetén gif használata).

    Ami nagyon tetszik, hogy megszerkesztem a kis js szkriptem, html oldalam, azt mondom eclipse-ben, hogy run as app. és 3-4 mp múlva már ott fut a telefonomon.

    Igazából, ha nincs mobiltel. specifikus hívás a szkriptben, simán lehet tesztelni, debuggolni mezei böngészőben a desktopon.

    Corona sdk-val is futottam egy kis kört, nagyon jó lenne az is, gyors a fejlesztés menete: azzal is szkriptet (lua) kell szerkeszgetni, a saját szimulátorán meg rögtön meg lehet nézni, hogy működne telefonon. Viszont a lebuildelt apk-t (hello world, ami simán működött a szimulatorban) az android emulátorra nem sikerült feltelepíteni (sok bejegyzést találtam, hogy nem csak én vagyok balfék), a telefonomra sikerült felrakni, viszont azonnal leáll indításkor. Állítólag iphone-on működik faxán, de nekem pont az lenne a lényeg, hogy több platformra tudjak fejleszteni...
    Mutasd a teljes hozzászólást!
  • Ok, megpróbálom, mely szándékomon a válaszod eddig semmit sem változtat:)

    Sikerült már létrehoznod ezzel a csodaalkalmazással valami konkrétat? Amennyiben igen, mi az URL-je?

    Jól látom, hogy a mobilok terjedése egy rakás szabvány megvalósítását igényelné? Hogy melyik lesz megvalósítva, jó kérdés. Szerintetek melyik?

    Mutasd a teljes hozzászólást!
  • Netbeans-sel próbáltad már? Eclipse-hez van alkalmazási útmutató, de az Eclispe-re nem szeretnék áttérni.


    Nem, de gondolom ugyanaz a menete kb.
    Eclipse-es beüzemelés kb 20 perc volt úgy, hogy mindent letöltöttem, telepítettem.
    Mutasd a teljes hozzászólást!
  • Netbeans-sel próbáltad már? Eclipse-hez van alkalmazási útmutató, de az Eclispe-re nem szeretnék áttérni.

    Egyébként a HTML5 nagyon jó "storage" kezelést biztosít. Offline "storage"-be mented az adatot, online betöltöd a "storage" nem feldolgozott tartalmát a szerverre. Ehhez a szerveren egy kulcs lista kell, csak azt küldöd el a tárolóból, ami nem szerepel a listában, sikeres feldolgozás végén bővíted a listát. Ami szerepel a listában törölhető a tárolóból. Valaki csinált már ehhez hasonlót?
    Mutasd a teljes hozzászólást!
  • A vevőket szerintem csak két dolog érdekli...

    Ki vannak-e elégítve, amikor vágynak erre?
    Mindig ki vannak-e elégítve, amikor vágynak erre?

    Ha a válasz igen, hűségessé válnak.

    A mobil eszköz a "mindig" kötéshez illeszkedik:)
    Mutasd a teljes hozzászólást!
  • Ebben persze igazad van, koránt sem tökéletes az én álmom.
    Sokkal inkább van bennem egy zsigeri tiltakozás a lassú, nagy tömegű és nehézkes rendszerekkel szemben, amelyek pontosan a technológiai vívmányok legkonokabb fékezői.

    A saját bőrömön tapasztalom meg ezt az üzleti életben, mert a legnagyobb vevőket a legnehezebb felébreszteni csipkerózsika álmukból. Az üzleti tárgyaláskor lelkesek, aztán minden esetben az ősidők óta használt ERP hiúsítja meg a fejlesztést.
    Pontosabban nem is a rendszer, hanem a berögzült régi paradigmák.

    Mutasd a teljes hozzászólást!
  • Én ezzel arra céloztam, hogy ez az "egységes" rendszer sem fog megoldani semmit, mivel az egyes rendszerek belül durván eltérhetnek. Az egyik tartalmazza Pl. a partner cég kapcsolattartóinak születésnapját, a másik nem, az egyik N darab fényképet tartalmat a termékről leírással, a másik csak két képet tárol leírás nélkül. És ezek csak a legegyszerűbb dolgok.
    Mutasd a teljes hozzászólást!
  • Tudnám a tábla nevét, elég megkérdeznem az érintett rendszer gazdáját.

    A lényeg most és itt nem a részletekben van, hiszen egy ma még nem létező struktúráról elmélkedek. Ugyanígy gondolok a biztonság, a redundancia és az erőforrások helyes kezelésére: nem most gondoltam minderre választ keresni, csupán egy nekem tetsző architektúra elveiről szabadon beszélgetni.

    Jut eszembe egy tizenpár éves emlék: amikor pár kollégával felvetettük egy multicég alkalmazottaiként az IT-főnöknek, hogy néhány funkció esetében be kellene kötnünk a külső web-et az intranet által kezelt adatbázisba, hajszál híján kirúgott minket. Micsoda skandallum, micsoda övön aluli ütés a biztonság ellen, erre eltelt pár év, és default igénnyé vált a cégeknél ez az átjárhatóság.

    Szóval ne csak a múlt konvencióiból indulj ki, hagyd szabadon szárnyalni a fantáziád, minden nagy dolog így született...!
    Mutasd a teljes hozzászólást!
  • Aha. Ez azt jelenti, hogy gyártanod kellene egy olyan drivert a php alá ami az adott ERP-t eléri, és a benne lévő objektumokat ezen keresztül teszi elérhetővé. Ettől persze még nem fogod tudni a virtuális adatbázisodban a dolgozók tábla nevét, és persze hogy milyen mezők vannak benne. És persze az sem biztos, hogy az X ERP adatszerkezetét véges sok erőforrás felhasználásával átfordíthatod Y-ra.

    PHP - nem biztos, hogy egy ERP-nek jó ha a stringhez szó nélkül hozzáadhatsz egy számot, és ha egy-egy bug jó eséllyel csak run-time jön elő. Az egész cucc gyors hekkelésre való, ami addig jó, amíg nincs tétje a dolognak.
    Mutasd a teljes hozzászólást!
  • Lemaradt: nem vagyok php-fan, nem is emellett érvelek amikor azt mondom: mindegy, hogy a különálló rendszer logikája milyen programnyelven fut. Készüljön el abban, amiben a cég a leggyorsabban tud fejleszte(t)ni, és ha az a PhP, akkor abban.

    Ilyen architektúrában nem látom lényegesnek, hogy mely nyelv jobb vagy rosszabb, pláne nem nevesítve - bár meggyőzhető vagyok...

    De ha már, akkor: miért nem használnád a PhP-t?
    Mutasd a teljes hozzászólást!
  • Nem a rendszerek egymás közti kommunikációjára gondoltam, hanem az eleve decentralizáltnak tervezett különálló rendszerekre, amelyek nem egymással kommunikálnak, hanem egy univerzális adatbáziskezelő rétegen keresztül (átgondolt jogosultságokkal és kellő biztonsággal) férnek hozzá a saját és egymás adatbázisaihoz akár egyetlen lekérdezésen belül is.

    Mondok egy példát: egy adott ERP személyzeti információjával (aktív 35 éven felüli női munkatársak) szeretném szűrni a (csak hogy provokáljalak) MySQL tábla adatát php-val előállított adatlekéréssel, akkor az univerzális db-rétegnek elküldöm MySQL szintaxissal a kérést, a réteg az ERP-t kiszolgáló ORACLE rendszernek "lefordítja" a lekérdezés szűrő feltételeit, visszaadja a kért rekordhalmazt, amivel megszűri a MySQL lekérdezésem, és a visszaküldi az eredményt a PHP interpreternek.

    Ennek a gondolatnak csupán az a lényege, hogy akár egészen kicsi, de az adott üzletmenethez igen fontos funkciókat hetek-napok alatt hozzá lehessen építeni a vállalatirányítási rendszerhez - még ha nem is szervesen.

    Értem én, hogy ezzel még csak alkalmazás-szigetecskéket képezünk, hiszen az ERP ettől még nem válik képessé a szigetecskék által bevitt adatok kiértékelésére, de talán nem is mindig kell a mamutot emiatt piszkálni.

    Szerintem nem vagyunk nagyon más véleményen...
    Mutasd a teljes hozzászólást!
  • Nincs annak semmi akadálya, hogy rendszerek kommunikáljanak egymással, erre léteznek protokollok, pl SOAP, és léteznek erre alapuló webszolgáltatások amin keresztül kommunikálhatsz rendszerekkel. Ettől függetlenül a PHP-t én nem használnám olyan rendszer fejlesztésére aminek tétje van, de nem azért mert nem lehet vele csatlakozni más rendszerhez.
    Mutasd a teljes hozzászólást!
  • Pedig van erre jó példa. Nem nevezem meg a céget, mert az alábbi történetről a volt kollégák fel is ismerhetnek - ezt pedig nem akarom.

    Magya multicég, komplex SAP-val, az e-Learning implementáció egyik fő felelőse voltam. Az e-Learning IBM WebSphere alapokra épült, kellett egy átjáró a két rendszer között. A cég és az SAP support töketlenkedései miatt több, mint 2 év kellett néhány rekordnyi adatmozgatást megvalósítani, mert a személyzeti modulnak értesülnie kellett az elvégzett belső tanfolyamokról,illetve az e-Learning rendszer is igényelt adatokat az SAP-tól. Két éven át kézi átfejtéssel működött a két rendszer egymás mellett, ezernyi pontatlan, hibás adat keletkezett, szerintem még ma is ezt javítgatják. (9 éves történet)

    Egyetértek veled, bármennyire is hajmeresztőnek hangzik az ERP-k világában, de paradigma váltásra lesz szükség a jövőben.
    Szerintem jobban teret fog nyerni a "több alkalmazás több platformon" architektúra, amelyek képesek lesznek interfész nélkül is "kezet fogni", mert átgondoltabban, egymást nem szem elől tévesztve fejlődnek ki.

    Nem vagyok vérprofi adatbázis szakértő, csupán hangosan gondolkodom. Az egyik hiányzó láncszem - szerintem - a fenti struktúránál egy olyan db-szerver alkalmazás, amely képes a legtöbb adatbázis rendszer nyelvén kommunikálni, azaz a hozzá beérkező utasításokat más rendszerre is értelmezni. Ily módon akár php-mysql párossal is kereshetnénk az ERP DB2-ben, vagy keresünk a MySQL-ben ÉS szűrünk a ORACLE-lel.
    A dolgok kulcsa úgy is az adatkezelésben van, az, hogy a logika milyen nyelven van megírva édesmindegy.

    Nekem tetszene...!
    Mutasd a teljes hozzászólást!
  • Nem tudok ilyet mutatni. Olyat viszont már láttam, amit az említett TRIÓ erősít, mégis inogott. Ez persze tervezési kérdés.

    Az integráció sziget-rendszerekkel sem sérül. Interfészek nélkül egy komoly ERP sem létezhet. Közvetlenül kockázatos a cég vagyonát képező adatbázisát írni/olvasni.

    Kicsit másképp az eddigiekről: Adott egy ERP, nagy fejlesztőcsapat, szegmentált ügyfél-felhasználókör. Nagy tudástőke...Az egyik ügyfél továbbfejleszti az egyik értékteremtő folyamatát -mert fenn akar maradni a versenyben - , szalad a fejlesztőhöz, aki jó pénzért, átgondoltam, a mamut rendszer stabilitását is szem előtt tartva lefejleszti az eszközt?

    Itt nagy kérdés, ha a folyamatot nézzük amit leképezünk egy nem privát szoftverbe, nem-e csökken a folyamat által nyújtott piaci előny azzal, hogy berakjuk egy közös kalapba? Szerintem igen.

    + a lényeg a gondolkodásmódban van, annak mérlegelése a fontos, hogy a mobilok megfontolt alkalmazása mikor, milyen körülmények között juttatja piaci előnyhöz a vállalatot. Az a fontos, hogy lássuk azt a több millió embert akik már használnak és azokat is akik majd 10 év múlva fognak mobil eszközt használni, mert még meg sem születtek. Az a véleményem, hogy az ERP-k egyre inkább egy térben meg sem határozható hálószerű rendszerhez kell, hogy hasonlítsanak, másoknak kell lenniük, mint most és ezt minden cégnek magának kell megalkotnia:)
    Mutasd a teljes hozzászólást!
  • Egyszóval igazad van, hogy a ma még gányolásnak tartott kiegészítés szembe megy az évtizedes konvenciókkal és terminológiákkal, de hidd el, sokkal többször fordul elő a gyakorlatban, mint ahogyan a cégek azt bevallják.


    Ezt meg tudom erősíteni. Igaz, nem php-mysql-t használtunk, hanem .net-et, de a régebbi munkahelyemen is azért tudott bevállalni a főnököm melót egy nagy állami vállalattól, mert tudtak arra hivatkozni, hogy a kis cége csak pár száz millióért fejleszt le pár modult (igazából egyedi alkalmazás, és azok moduljairól volt szó), és sap fejlesztőkkel sokkal többe kerülne.
    Az sap-t már bevezették náluk régebben, de így is ócsóbb volt.

    Persze megvoltak neki a megfelelő kapcsolatai is, de akkor is...
    Mutasd a teljes hozzászólást!
  • Az igaz, hogy nem feltétlenül kapcsolandó össze mondjuk az SAP egy php-mysql kombóval összeépített (csak mert már volt róla szó) fuvar-optimalizáló mobil alapú modullal, bár amilyen lassan mozdul egy ilyen integrált rendszer a haladás útján, talán nem is mindig lenne olyan őrültség.
    Minden integrációs és biztonsági probléma ellenére nem tartom kizártnak, hogy olykor egy kis házi barkáccsal gyorsabban lehet piaci előnyhöz jutni egy ilyen modullal, mint megvárni, hogy a rendszer fejlesztőcsapata felébredjen.
    Persze értem én az integritás, a biztonság és az interfészek problematikáját, de az üzletmenet olykor merész lépéseket is megkívánhat.

    Éppen ez ma (és a középtávú jövőben!) az integrált vállalatirányítási rendszerek rákfenéje: lassan követik a technológiát.
    Egy kis- és középvállalat esetében indokoltabb lehet nem az integrált rendszer, hanem a célszoftverek használata akár adatkonverziók és interfészek egyedi megírása árán is, hiszen ezekkel sokkal gyorsabban tud egy cég lépést tartani a szinte évente változó gazdasági és technológiai környezettel.

    Egyszóval igazad van, hogy a ma még gányolásnak tartott kiegészítés szembe megy az évtizedes konvenciókkal és terminológiákkal, de hidd el, sokkal többször fordul elő a gyakorlatban, mint ahogyan a cégek azt bevallják.
    Ismerek kifejezetten komoly multicégeket, akik az SAP mellett kisebb de annál fontosabb feladatokra egészen más rendszerben megvalósított hálózat-alapú célprogramokkal oldják meg a folyamatosan változó igényeket. Aztán ha kell, átfejtik az adatokat az SAP-ba.
    15 évvel ezelőtt a több tucatnyi célprogram integrálása volt a cél, manapság viszont egyre szaporodik a informatikai decentralizációs igény is.
    Mutasd a teljes hozzászólást!
  • privi ment :)
    Mutasd a teljes hozzászólást!
  • Szerintem a MySQL is épp oly jó lehet, mint bármely más adatbáziskezelő, bár ez nyilván nagyban függ az adattömegtől, a lekérdezések gyakoriságától, méretétől, stb.

    Tudod, a megfelelő eszközt kell a célhoz rendelni. :)

    Szerencsére több tucatnyi eszköz és erőforrás kapcsolható már a mobil-app-okhoz, adattárolásnál (különösen a nem változó adatok esetében) érdemes számolni a lokális adattárolással is - ez ráadásul minden (?) okostelefonnál a web-applikációkkal is elérhető (HTML5 -> Web-Storage).

    A HTML5 amúgy is hatalmas áttörést jelent (fog jelenteni) a korábbi webes implementációkhoz képest, 16 év után úgy egy éve élvezem a webfejlesztést.
    Külön előnye az okostelóknak, hogy zömében olyan böngészőket tesznek bele, amelyek többé-kevésbé de elbánnak a HTML5 fontosabb újdonságaival.
    Mutasd a teljes hozzászólást!
  • Mutass nekem olyan nagy ERP rendszert, ami php-mysql páros használ légyszíves! Meg pont az a lényege az integrációnak, hogy nem saját db-t használ, hanem az ERP rendszerből kérdezi le az adatokat és oda is tölti vissza.

    A php meg köszöni szépen más db kezelőkkel is nagyon jól elvan, nem tudom, hogy a mysql-t miért kéne kiemelten kezelni (mielőtt félreértesz: magam részéről nagyon szeretem a mysql-t és a php-t is, de komoly ERP rendszert én még nem láttam mysql-en futni és komoly ERP-hez még nem láttam php-ban hegesztett webes felületet).

    ERP-k világában Oracle-DB2-MS SQL Server trión kívül még nem nagyon láttam db kezelőt.
    Mutasd a teljes hozzászólást!
  • Nálunk is a szervizesek futottak be elsőként hasonló megrendeléssel. Mivel a lehetőségek terén meg volt kötve a kezünk mi megvalósításunk valamivel fapadosabbra sikerült a vonalkódos megoldásotokhoz képest. Nekem is az a tapasztalatom, hogy egyre nagyobb a piaci igény ezekre a megoldásokra.
    Mutasd a teljes hozzászólást!
  • Értem. Jogos! Hol fut majd az össze-tett-hangoló algoritmus? Egy kiszolgálón, bizonyára. A kiszolgáló lehet egy mobil? Most még talán nem; De, ahogy pörögnek az események akár mobil is lehet és akkor rögtön ön-kiszolgáló.

    Szerintem a hálózat jelenti a kulcsot. Nézd meg az emberi testet, annak működését - nekem talányosabb, mint egy taxis probléma. Az elhaló és születő idegsejteket - no ezek a mobilok.



    Mutasd a teljes hozzászólást!
  • Mivel a téma az ERP rendszerek kapcsán került felvetésre ezért én automatikusan a vállalat szemszögéből közelítettem meg a dolgot. Ebből az aspektusból az, hogy a taxis odataláljon A-pontból B-pontba irreleváns. Amire utalni próbáltam az, hogy a valós idejű GPS alapú helymeghatározás és logisztika segítségével jóval hatékonyabban lehetne összehangolni a járművek mozgását egy 200-300 járművet egy időben üzemben tartó cégnél, ha hirtelen befut 25, 30 fuvar igény. A legkisebb költség meghatározása ebben az esetben egy igen komplex feladat mivel rengeteg tényezőt kell figyelembe venni (forgalmi helyzet, járművek és a megrendelő távolsága, az egyes fuvarok közötti legkisebb üresjárat, az utas várakoztatásának hossza stb.) erről egy logisztikus órákig tudna regélni. A beérkező adatokból pedig a későbbiek folyamán adatbányászati módszerekkel újabb összefüggéseket lehetne feltárni amit aztán fel lehetne használni a későbbiekben pl: a színházi premierek napján 20%-al több utast kell fuvarozni budáról pestre 20 és 24 óra között.
    Mutasd a teljes hozzászólást!
  • Vevő - és igény? Na erre kell figyelni szerintem is - ahogy Te is mondod - gondolkodás közben - és nem csak a sztereotípiákra. Az eszközt a cél határozza meg és valóban meghatározza, mert ilyen az élet.

    Mit gondolsz a MySQL-ről? Nem azért ragozom a PHP-t, mert perverz viszony lánccol hozzá, hanem azért, mert a MySQL jól együtt tud működni ezzel nyelvvel. Meddig lesz ingyenes a MySQL, vagy ingyenes-e egyáltalán? Licenc faktor zéró.





    Mutasd a teljes hozzászólást!
  • :) mielőtt Budapesten taxiba ülnék lekérném az optimális utat, ennyi költség belefér. Szerintem már a taxisok is tudják, hogy másképpen kell gondolkodniuk, mint a 80-90-es években...

    Mutasd a teljes hozzászólást!
  • Ebben igazad van, a PhoneGap több platformot támogat, bár kicsi zavar támad az erőben azzal, hogy Xcode (és Apple Dev. Cert.) kell hozzá, ami meg ugye az iOS fejlesztés eszköze.
    Nem is nagyon vágom, hogy miként jön ide pl.: az Android.

    Mondjuk én csak iOS-ra nyomom...
    Mutasd a teljes hozzászólást!
  • hmm, a coronat nem ismertem, játékfejlesztésre tényleg nagyon jónak tűnik!
    Annyi hátránya van, hogy "csak" androidot és ios-t támogat. Tudom, hogy játékoknál ezek a slágerek, de akkor is a phonegap támogatja az összes elterjedt mobil platformot szinte.
    Mutasd a teljes hozzászólást!
  • Jó példa, bármely olyan rendszerben hasznát lehetne venni, amelynél a helymeghatározásnak használati értéke lehet.

    A legutóbb egy olyan rendszert építettünk egy országos lefedettségű, helyszíni szervizzel is foglalkozó cégnek, amelyben a szerelő a helyszínen rácsatlakozik az app segítségével a cég rendszerére a szerelés megkezdésekor valamint annak befejezését követően, megadja a felhasznált anyagokat (listából vagy a vonalkód leolvasásával), és még vissza sem ér a telephelyre, a számla hussan postán a megrendelőnek.
    A szervizeléssel kapcsolatos összes infó megy a könyvelőrendszerbe, a készletnyilvántartásba, a bérelszámolásba, stb.
    Nincs felesleges vagy többszörös adatbevitel, a létező leggyorsabb és leghatékonyabb rendszer építhető fel így.

    És ez is csak egy példa a számos alkalmazhatóság közül.
    Mutasd a teljes hozzászólást!
  • A PhoneGap egy okos fw, nagyon gyorsan lehet vele Objective-C szöszmösz nélkül natív alkalmazást készíteni.
    Az más kérdés, hogy az ezzel készült dinamikus tartalmak implementálását más metodika szerint kell megcsinálni, mint a desktop-okra, pláne ha minél kevesebb on-line kapcsolattal akarjuk megvalósítani.

    De ha már nativ app, akkor már inkább a Corona. Igaz,ez inkább játékfejlesztésre van kihegyezve, de simán alkalmas felhasználói app-ok készítésére is.
    Mutasd a teljes hozzászólást!
  • Egy taxis vállalatnál azért meg lehetne spórolni pár 10 milliót a valós idejű helymeghatározás és egy logisztikai modul segítségével.
    Mutasd a teljes hozzászólást!
  • Szerintem jól látod az alapelveket, pontosan erre gondolok én is.
    Ami a php-t illeti, arra csak mint lehetséges eszközre gondolok, hiszen mindig az adott feladat dönti el, hogy mely rendszer vagy éppen nyelv csatolható hozzá a leginkább.
    Mutasd a teljes hozzászólást!
abcd