SAP Business One Web Service

Én még amit látok a nagy világban problémát:
Kis céget megbízni egy speciális program fejlesztésére azért veszélyes, mert a kis cég (anyagi okok miatt) bármikor megszűnhet, utána oda a support, netán újratelepítés, fejlesztés, stb. Tehát utána lehet még egyszer kifizetni a pénzt egy hasonló programra.
A nagy cégeknél is fenn áll hasonló veszély, ott szintén anyagi okok miatt megszüntethetnek egy-egy fejlesztést, programot, akár csak egy-egy platforomon, stb, ami miatt lehet megint keresni más céget/terméket.
Szóval az egyetlen egy járható út (persze nyilván a feladat mennyisége miatt azért kérdéses), hogy ha egy saját fejlesztő csapat csinál ilyen programokat. Itt meg ugye fennáll a veszély, hogy nem biztos, hogy találnak megfelelő munkaerőt a bérezés függvényében, stb…

@Ark?
https://m.itcafe.hu/hir/sap_programozo_verseny.html

Lassan elindulhatsz… :D

Az ilyenek csak ötletlenyúlásra vannak.

A kollégák szerették volna, ha nem kell figyelni az ékezetekre a terméknevekben keresésekor, ahogy ezt Mac-en 4D és FileMaker alatt megszoktuk. Erre szolgálna a Collation beállítás az adatbázisban.

De a bevezető cég szerint az SAP csak abban az esetben garantálja a működését a szoftverének, ha ez ékezet-érzékeny beállításon marad. Szomorú.

Siralmas ez az egesz sap.

Nagyon alacsony az elvárás ezen a piacon, hogy ilyen felhasználói élménnyel piacvezető tud lenni az SAP. Valaki vehetné a bátorságot, hogy XXI. sz.-i technológiákat használva megalkosson egy konkurens terméket.
Még egy ERP-ben is lehetne innováció. Csak a 99 centes app-ok korában, nem ilyen irányba mennek a legügyesebb fejlesztők.

Nem lehet ilyen rendszerekbol dobozos termeket csinalni, minden ceg mukodese mas.

Ez egy komplex kérdés. Alapvetően igazad van.

Szerintem nagyjából a következő bolygóegyüttállás mellett lehetne ezt jól csinálni:

Programozó cég, aki csak ügyviteli szoftverekkel foglalkozik
Min. 2 programozó/SQL guru
Min. 1 webprogramozó (+dizájner külsősként)
Min. 1 könyvelő/az ügyvitel fele könyvelési kérdés/NAV kompatibilitás, jogszabályok ismerete
Min. 1-2 sales/tanácsadó/igényfelmérő/support

Tehát 4-5-6 embert el kellene látni ezeknek a projekteknek. Vigyen haza mindegyik kolléga 200-300 000 Ft-ot havonta és akkor még nincs túlfizetve senki, sőt. Ehhez kéne kb. 2-3 millió havi bevétel a cégnek. Ez a havi költség azért jelentősen behatárolja, hogy kik lehetnének benne a célcsoportban.

Én lennék a legboldogabb, ha lehetne erre alapítani egy céget.
De én azt látom, hogy vagy kóklerek hívják magukat programozónak és valami förtelmes munkát adnak ki a kezükből, ha egyáltalán be tudják fejezni. Vagy átlagos tehetségű emberek próbálkoznak, akik meg túlvállalják magukat. Aminek szintén az elvárható alatti minőség lesz a vége.

A cégen belüli saját fejlesztést én mindennap csinálom. Ott hihetetlen önfegyelem kell ahhoz, hogy egy-két éven belül ne legyen teljesen spagetti kód a vége annak, ami ott készül. /De lehet csak bennem nem volt elég önfegyelem. :-P/

Ma Magyarországon szerintem 100%-ban egyedi szoftverfejlesztéssel középvállalkozásoknak előállni nem nagyon lehet. Nem tartunk ott. Egy saját kvázi dobozos szoftver cégekre szabása talán már rentábilis tudna lenni. De ott meg kétséges a végső minőség és a rugalmasság. (És akkor már mért ne venne a kuncsaft valamit a KulcsSofttól vagy elégedne meg a CIPO-val.)

Az egyedi szoftverfejlesztés a fejlett nyugat játszótere, egyelőre. Ott láthatólag, akár országonként 5-6 csak FileMaker alapokon müdödő cég is meg tud élni és akkor még másra nincs is rálátásom. (Anglia, USA, Ausztrália, még Ausztriában is van.)

1 kedvelés

A nem programozó SAP bevezető embert próbálom meggyőzni, hogy Visual Basic .NET-ben és C#-ben lehetséges az “error handling/exception handling” és az nem normális, hogy minden hiba végzetes kivételt vált ki és kilépnek a fejlesztéseik.

Kicsit lusták a programozóik…

Bakkeeeeer…

Vajon a PC-s világban ez elfogadható? Annak kell legyen, hisz nálunk is ezzel próbálkoznak.

Sosem lenne szabad nem Mac-es programozóval dolgoztatni. ;-)

A gondokhoz még annyit hozzátennék, hogy az is könnyen lehet (mint általában), hogy évekkel ha nem több, mint egy évtizeddel ezelőtt megírt kódot foltozgatnak. És egyszerűen nincs erejük (vagy tudásuk vagy kedvük) újraírni a kódot alapjaitól számítva.

Én azt hittem eddig, hogy ez alap. Ez a legfontosabb. Mármint, hogy le legyen kezelve mindenféle hiba és ezen kívül agyon legyen tesztelve mindenféle adattal még olyannal is, ami egyáltalán nem lehetséges, mivel a júzerek tudnak alkotni.

2 kedvelés

Ennek semmi köze ahhoz, hogy valaki pc-n vagy macen dolgozik. Nincs olyan, hogy Maces programozó, ami ráadásul egy felsőbbrendű faj. Egy fejlesztő olyan rendszeren dolgozik, ami a legjobb az adott feladathoz, és vagy normális, vagy igénytelen kódot ír.

1 kedvelés

Láthatólag eme felvilágosult eszmék még nem jutottak el minden programozóhoz. Sajnos.

Saját magukról állítanak ki bizonyítványt ezzel. És hitetik el az átlag felhasználóval, hogy a számítástechnika ilyen rossz és nem is lehet jobb.

Igen, de ez nem lenne jobb akkor sem, ha Macet használnának.

Optimista vagyok, hiszek a jó példa ragadósságában, értve ez alatt, hogy a NeXTSTEP és az Mac OS X strukturálisan jobb a többi OS-nél. És abban, hogy két Mac-es kevesebb félreértéssel érti meg egymást, mint két eltérő platformot használó.

Ez nem a Mac-esek felsőbbrendűsége, csak annyiról szól, hogy a szükségtelen nehézségeket érdemes elkerülni. (overhead)

Ld. pl adatbázis-kezelés:
Akadémikus: relation, tuple, attribute
SQL: table, row, column
SAP: user denfined table/objet, row/line, field

És ez mind nagyjából ugyanaz csak más-más “kulturális közegből” érkező mást fog használni és még kell tanulni fordítani.

Semmi Mac-specifikus nincs az általad felvetett problémákban, amiknek semmi köze nincs az operációs rendszerek struktúrájához. Ezek programozási alap dolgok, mindegy, hogy milyen rendszeren, nyelven, frameworkben vagy anélkül dolgozol. Hidd el, attól, hogy valaki vesz egy Macet, nem lesz jobb és lelkiismeretesebb fejlesztő.

2 kedvelés

Nem állítom, hogy az lesz, csa annyit, hogy kisebb lesz a kommunikációs overhead, ha két azonos “kulturális közegből” érkező ember kommunikál, mintha még ezt ezt is le kellene győzni.