Vállalatirányítási rendszer

 ( Proci85 | 2018. október 30., kedd - 11:38 )

Keressük a következő Szent Grált:

- erőforrás kezelés (autó, tárgyaló, nagyértékű eszközök)
- ember, mint erőforrás kezelése
- cégen belüli ticket kezelés
- munkaidő kihasználás kezelése (erre a munkára, erre a ticketre ennyi időt fordítottam, erre a projektre a hó végére ennyi emberórát áldoztunk)
- naptár kezelés, ahol látjuk, hogy ki foglalt/szabdságon/kiküldetésen van, tehát ne adjunk rá feladatot (optimális esetben már feladat kiosztáskor megjelenik egy foglaltság naptár az adott illetőről). Előny, ha google calendarral tud beszélni -> telefonos integráció
- Szeretjük, ha nálunk az adat, pl. VM-en. Bizalmas infók vannak a ticketekben.

Jó ha modullal okosítható:
- projekt költségek (anyag, emberóra, alvállalkozói díj) számolás a gazdaságisok felé.
- eszköz leltár, ami a gazdaságisok felé prezentálható, hivatkozva, hogy melyik projekthez, telephelyhez, emberhez tartozik
- anyag igény leadása a vezetőség felé, akik jóvágyják és a belső beszerző munkatárs ez alapján beszerzi az adott eszközt

Nem kell ingyen.

Jelenleg a GPLI-t használjuk raktár eszköz, leltár kezelésre. Erre elvileg megmarad, mert ebben kíváló, de ha van jobb, nem ragaszkodunk hozzá. A ticket kezelése nem rossz, de marha sokat kérdez egy ticket (hiba, anyagigény) beküldésekor, amire nagyrészt nem is kell válaszolnunk és sokaknak emiatt nehéz a kezelése. Jelenleg ticketre Mantis-t használunk.

A levelező postfix, dovecot, SA, Amavis, sieve klasszikus kombó, amivel elégedettek vagyunk, így nem váltanánk le tokkal-vonóval egy Exchange-re, ami egyszemélyes mindenes akar lenni.
Exchange jöhet, de csak ha a levelezés maradhat linux alapon.

A fentiek tükrében szeretnék bevált megoldásokat kérni.

Köszönöm!

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Ez nem CRM.

Üdv,
Marci

Akkor marad a Szent Grál név:)
CRM nevet kapott már itt minden, legutóbb egy fapados hirlevélküldő rendszer is.
Mi a jó név akkor erre?

Vállalatirányítási rendszer.

Üdv,
Marci

Ahhoz lightosnak érzem, de legyen:)
Köszi, de máskor ezt egy hozzászólásban nyugodtan beírhatod. Ez nem az, hanem...

Sokszor kezelik úgy a CRM-et az emberek, mint valami project management eszköz, közben egész konkrétan sales project management-re való csak. Amit te leírtál, az erőforrás kezelés, egy ERP-ben gyakorlatilag ez mind megvan (készletkezeléssel együtt), legegyszerűbben az ERP = raktár + crm + ticketing + project management + knowledgebase + ...

Köszönöm a nevelő szándékot.

Üdv,
Marci

Ez nem az, hanem...

Hanem mi? :)

Üdv,
Marci

Amit leírtál, az egy teljes ERP (vállalatirányítási - enterprise resource planning) rendszer. Javaslom keressetek valakit aki tud segíteni választásban, fejlesztésben, és mindenek előtt tervezésben.

Fejlesztőként azt mondom, hogy jobb lenne előbb szóban majd papíron végignéznetek, hogy egész konkrétan milyen folyamataitok vannak, mint rögtön szoftvereket nézni, megtévesztő tud lenni. Szintén mint fejlesztő mondom, hogy tudunk segíteni már a tervezésben is. (A leírásod már egy jó kiinduló alap.)

Hm, ERP, igaz. Köszi!

Jól értem, 0-ról lefejleszteni? Vagy meglévő modulokból összerakni?
Erősnek érezném, hogy annyira egyedi lenne, hogy csak nekünk kellene lefejleszteni valamit. Ezek elég alap dolgok, különböző skálázásban több tucat fizetős van.

Nem feltétlen kell lefejleszteni, itt az a kérdés csak, hogy amik vannak már kész rendszerek azok mennyire fedik az igényeiteket le. Tapasztalatom az, hogy a "hát oda nem tudtam beírni úgyhogy ezt az adatot nem vittük fel", és a "hát abból sose tudom kihámozni, úgyhogy azt nem nézem" elég drága szokott lenni utólag, még ha havi 10$-ért jó is volt elsőre a szoftver. Ezért javaslom, hogy masszívan papíron és szóban tervezzétek meg a rendszert, folyamatokat, értékeljétek ki, hogy mennyire fontos melyik feature, nagyságrendekben tud segíteni egy fejlesztő is, ha a cég folyamatai jelenleg nincsenek megírva papíron, vagy nincs valaki, aki kérésre kb. 2 óra alatt el tudja mondani azokat, akkor hatalmas idő és pénz spórolás tud lenni egy olyan fejlesztő vagy auditor, aki lespecifikálja a folyamatokat. Ne a kész szoftverekkel kezdjétek, mert a jelenleg fejben meglévő igényekre 85%-ig passzoló szoftver lehet olcsó, de ha 2 év múlva még mindig excel fájlokba IS van mentve minden adat, mert a CRM-be nem lehetett ezt azt, és még mindig a levelező a project management rendszer, akkor csak magatokat lőttétek lábon.

Ez igy igaz. Legyen meg egy helyen, peldakkal illusztralva az uzletviteli dokumentacio, uzleti folyamatok, stb.

Ennek en is nagy hive lennek. Sajnos meg egyetlen ceget se lattam, ahol ezt igazan komolyan vennek. Az uzleti folyamatok dokumentalasa, fejlesztese (sulyosabb esetekben teljes ujratervezese) stb. pedig nagyon fontos lenne, hogy az adott organizacio hatekonyan tudjon mukodni.

Erdemes kicsit utana olvasni a Business Process Management vagy Business Process Modeling and Notation temakornek. Ez utobbi kozel allhat a profi szoftverfejlesztok szivehez. Mar akik szeretnek OO programokat tervezni...

Amig ezzel a problemaval nincs tisztaban egy organizacio, addig a kis piros kockas fuzet is jo.
A masik extrem helyzet, hogy a SAP, McKinsey, IBM es az A.T. Kearney egymasnak adjak a kilincset es az 50 ev alatt organikusan kifejlodott business process rendszert es IT infrastrukturat probaljak helyrepofozni (pontosabban a termekeiket es szolgaltatasaikat ertekesiteni).

A topicnyitobol ugy tunik, hogy a ceg elindul ezen az uton. Gondolom a novekedes rakenyszeriti oket, hogy valtoztassanak. Felismertek, hogy szukseguk van valami IT megoldasra. De nem vilagos (egy rovid topicnyitotol nem is varnam), hogy pontosan felmertek es megismertek-e a megoldando feladatot.

+rand(-1,1) :)

Lehet ERP rendszert bevezetni nagyon nagyon nagyon rosszul és nagyon jól is. cherockee-nak igaza van abban, hogy azzal kellene ezt kezdeni, hogy megnézitek, hogyan működnek most a folyamataitok, aztán hogy ezt lehetne rendszerszinten kezelni és esetleg rendszerszinten kezelve fejleszteni rajtuk - és utána a jelenlegi és a tervezett ideális állapothoz keresni szoftvert.

Ha fordítva csinálod ("én márpedig X szoftvert akarok" típusú szokásos menedzseri bullshit), akkor többnyire utólag kell a folyamataidat hozzáilleszteni egy rendszerhez (vagy ami még rosszabb: megtartani a jelenlegi folyamatokat és imádkozni, hogy távolról konzisztens maradjon a valósággal az ERP-ben levő adat) - meg lehet csinálni, de ha nem méred fel előre, hogy mi merre hány méter, már a legegyszerűbb alapbeállításoknál (pl. jogosultságok kezelése) tökön tudod szúrni magad és a céget.

És nem feltétlenül kell 0-ról lefejleszteni, lehet, hogy jó lesz nektek valamelyik kulcsrakész megoldás - viszont azt integrálni a meglévő rendszereitekhez, testreszabni stb. mindenképp kell majd. Egy jó rendszer a kezed alá fog dolgozni, egy rossz rendszer (vagy egy jó rendszer rosszul beállítva) csak mindenhol plusz munkát fog jelenteni.

Sajnos részint tapasztalatból beszélek: látom, hogy nálunk is az újabb és újabb ERP rendszerek bevezetésével kezdődik az N+1 felé "könyvelés", jogosultságok katasztrofálisan vannak kiosztva, ami miatt tovább növekedik a bürokrácia, mert egyszerűbb újabb bio-ocr rendszert venni [értsd: újabb ügyintézőt/papírtologatót alkalmazni], mint rendesen megtervezni valamit és nem egy "Next-next-next" módszerrel telepíteni és "személyre szabni" egy rendszert...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Igazából tapasztalataim szerint az se igazán probléma, ha néha átnézik/átnézetik a cég folyamatait, mert igazából könnyen lehet, hogy kibukik valami, hogy van jobb módszer is, mint amit egy cég csinál.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Na igen, nem árt... mondjuk az ilyeneknél kezdek el mindig rettegni, hogy előkerül egy csúnya három betűs rövidítés, hogy de majd milyen jól standardizéljük a folyamatainkat és a folyamataink kötelező éves ellenőrzését és... mert abból nagyon sok helyen lesz az, hogy kőbe vésetik az idiotizmus, és nem lehet eltérni a kőbe vésett idiotizmustól, mert az kőbe van vésve és bonyolult az új kő vésésének a folyamata :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ésszel kell csinálni. De ugyanennek van egy másik példája is, amikor pl. egy raktárvezető kijelenti, hogy márpedig a tárhelyes raktár nem lesz hatékonyabb, mint amit eddig csináltak. :)

Aztán egy másik raktárvezetővel hogy-hogy nem, mégiscsak hatékonyabb lett az egész process és a karácsonyi roham érdekes módon relatíve kényelmes tempóval, plusz ember nélkül is teljesíthető lett a korábbi túlórahegyek és káoszba hajló esetek helyett.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Magyarország (is) egy olyan ország, ahol mindenki ért mindenhez, csak mégse keres egy kanyi vasat se ezzel :).

Főpincér azt mondta, mit csináljon a tablet-al ha elmegy az áram, mondom semmit, mert akkor a hűtő is elkezd leolvadni nemde? Lesz jobb dolgod is mint eladni :). Szünetmentesről küldtem neki árajánlatot.

Cukrász rákötötte a hűtőpultot a PC-nek szánt szünetmentesre, 7 perc alatt le is rántotta a tartalmát, mert hát a fagyi romlandó, az adat meg nem (csak a mysql-nek nem esett jól írás közben leállni), és pofátlan a programozótól, hogy nem megy a programja áram nélkül, és hogy nehéz utána papírról bevinni az adatokat (nem az, ugyan azt kell végigcsinálni, csak soknak tűnik, mert "miért nem tudja a webkamerán keresztül beolvasni az eladást kockás papírról és kártyás terminál blokkról, a google is keres diktálás alapján").

Cégvezető hallotta, hogy az SSD nagyon gyors, és azért lassú a programunk (nem az, csak ne a 4 éves mérleget akarná lerántani 10x egy nap pdf-be, de azóta beállítottam, hogy cache-elve legyen), mert biztos nem SSD-n van (évek óta az van abban a szerverben), rakjunk bele, de ne neki számlázzam ki, tudni fogja, hogyha így teszek, ismeri az árakat!

Raktárvezető közli, hogy neki arra nincs ideje, hogy mindent felvigyen a gépbe, ettől a cég csődbe fog menni, ha ő nem pörög a raktárban egész nap. Majd amikor felvitte a felét (vagy még annyit se), kiderült, hogy lop, csal a készlettel, árajánlatokat megír majd nem küld ki, hanem a konkurenciánál dolgozó barátjához küldi át az ügyfelet, mert onnan kap jutalékot. Kiderült az is, hogy 1 nagyságrenddel nagyobb pénz áll készletben mint a tervben szerepelt, havonta 3 ember fizetését dobálják ki hulladékként, mert a megkezdett anyag maradékát ő már nem használja fel, akármit mond neki a technológus, ő jobban tudja.

Oscar díjas alakításokat látok minden cégnél, és általában lehet tudni, hogy anélkül az ember nélkül 1 nagyságrenddel nagyobb lenne a cég bevétele. A cukrász jó fej volt, őt felmentem, csak nem tudta, hogy mekkora a szünetmentes, de a többi centikre volt attól, hogy csődbe vigye a céget.

Az adatok viszont nem hazudnak. Az emberek igen.

"árajánlatokat megír majd nem küld ki"

Mondjuk ez mióta a raktár feladata? Meg egyébként is, raktárban elméletben nem kellene történnie semmiféle ki/bemenő mozgásnak utasítás nélkül, ami jellemzően egy másik osztályról jön. (Pl. értékesítés, beszerzés)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Valóban, nem fogalmaztam jól: raktárvezető vessző műszakvezető (gyártás) vessző beszerző vessző helyikisisten. Az egyszerűbb termékek gyártását is felügyeli, amikre sűrűn kell alig változó új árajánlatot kiküldeni, igazából csak anyagárhoz igazítva. Na ez neki sikerült úgy, hogy egyik cégnél egy év alatt 20-30%-ot emelt az áron, másiknál ugyan arra a termékre ennyit csökkentett. A megoldás a képletre annyi, hogy aki vitte, annak csökkentette az árat, aki nem, annak emelte, hogy még véletlenül se legyen kedve.

Ott kezdődött valami ebben a cégben is, hogy lövése nem volt a 80-as évek végén a tulajnak, hogy mit is csinál, csinálta, a piac ment, mert igény volt, hitel volt, ..., nem derült ki, hogy nem is ért a cégvezetéshez. Most meg azt mondja, hogy hát ahogy eddig ment, úgy mennie kell tovább is, a fentiekben leírt ember még ott van a helyén, és aktívan ágál bármilyen fejlesztés ellen, ami nyomon követhetővé tesz bármit is. Igazából nem kellene neki, mert most épp attól félnek, hogy még ilyen munkaerőt se találnak :).

Jaguar es Merci szalonban is a a raktár csinálja az alkatrészekre.

Ha a cégvezető nem képes a 3 betűs technológia bevezetése után 2-3 hónappal, vagy frász tudja, annyival amennyit az átszervezést végző mond, ránézni a számokra, és eldönteni, hogy megérte-e vagy sem, akkor nem cégvezető, definíció szerint. Azért addig el kell jutni talán így a 21. században, hogy nem totemállatokban, csodafüvekben, brand-ekben hiszünk, hanem hatást vizsgálunk. Az a szervezés, ami láthatóan többletmunkával jár, DE nem hoz új adatokat, összefüggéseket felszínre, nem csökkenti a stresszt, a hibák lehetőségét, az nem szervezés, az önmagáért levő cselekvés, zárvány.

Az aki meg a süllyedő hajón is a zászlórúdba kapaszkodik, az lehet jelenleg menthetetlen. Vannak ezek a hülyeségek, hogy járatlan útért jártat, meg hasonlók, hallgass az ösztöneidre, helyette tudni kéne egyet: a nem döntés is döntés, magától nem javulnak a dolgok, és nincs olyan, hogy stagnálás, csak egy pillanat a statisztikák megzuhanása előtt.

+1

Ez ok, és persze, mérni kell és folyamatosan követni/javítani a folyamatokat. Amitől én mindig frászt kapok, az az, ha bebetonozzák ezeket, mert hát kell az ISO (és tényleg van, hogy üzleti érdek, hogy legyen minősítés és legyenek garantált folyamatok) - csak párszor láttam már, hogy ebből az lett, hogy "legutóbb is mocsok drága volt a minősítés és jó az úgy" alapon onnantól kezdve soha többet nincs változtatás, minden csak a Nagy Könyv szerint mehet és fel se merülhet, hogy esetleg a Nagy Könyvben baromság van (mert mondjuk közben jelentősen változott a jogi/gazdasági/technológiai/... környezet és adaptálni kéne)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Azokat a folyamatokat amelyek önmagukat ellenőrzik, így a folyamat maga tartalmaz minőségi biztosítást az ISO-t nem érinti, hisz számára az egy fekete doboz. Nekem gyártó cégem van és maga az ERP-ben történő változások, még ha az üzleti folyamatokat is újragondolja, ha az említett módon jár el, akkor az ISO-hoz nyúlni sem kell.

+1

Igen, ezért is írtam az audit-ról. Mint programozó is nem kevésszer mutattam már iszonyat egyszerű megoldásokat, amiktől a folyamatok egyértelműbbek, követhetőbbek lettek, de én nem ehhez értek. És én még a programozók körében inkább üzleties példány vagyok, ezért kéne nekik egy tanácsadó cég, frász tudja mostanság minek hívják őket. Átnéz, kiegyenesít minden szálat, minden ritka eshetőségre választ talál, amire nem éri meg figyelni azt kidobja, ..., és a végén egy vaskos dokumentációt átad a programozónak megnézésre. Majd amikor van még 100 kérdés, arra is válaszol.

Röviden: nem a programmal kell kezdeni, programot tervből készítünk, a tervet nem a programozó, hanem az üzleti tervezéshez, szervezéshez értő írja. Nem manager, nem sales-es, nem tulajdonos, hanem ezek tapasztalatai és céljai alapján.

Tapasztalatom az, hogy átlag magyar KKV-nál, kb. 10 fő felett, masszív megtakarításokat eredményez egy ilyen folyamat, főleg ha még excel+papír+email a cégvezetési eszköztár, és nincs egy ember, aki tudna minimum 1 órán keresztül folyamatosan, ismétlés és mellébeszélés nélkül beszélni a cég folyamatairól. Nem mellesleg kiesnek a csontvázak is a szekrényből.

"Erősnek érezném, hogy annyira egyedi lenne, hogy csak nekünk kellene lefejleszteni valamit. Ezek elég alap dolgok, különböző skálázásban több tucat fizetős van."
Nézd: kétféleképp lehet rendszert "bevezetni":
a) vannak folyamataid amiket felmérsz és fejlesztesz hozzá saját rendszert ami ezeknek megfelel.
(kiindulhatsz valami alapból amit módosítasz stb., de általában ezt a mókolást érdemes megspórolni, mert a "testreszabás" részen pont azt bukod el amit a doboz amúgy nyújtana neked: a doboz upgrade lehetőségét. Tehát csak akkor válssz ilyet, ha tényleg lefedi a folyamataid 90%át és csak additívan nyúlsz hozzá, koncepcionális változtatásra nincs szükség..)
b) fogsz egy új dobozt és a cégedet hozzá szabod. Tipikus pld: SAP bevezetés helyett a céget SAP -kompatibilisre faragják. (folyamat és cég változik a doboz sajátosságaihoz).

hints:
- https://derrickesharry.blog.hu/2018/05/13/dobozos_termek_hasznalati_utasitas
- https://derrickesharry.blog.hu/2012/04/01/mese_a_dobozos_termekrol

Ha cserélnétek a levelezést Zimbrára akkor a következő pontokat letudhatnátok:
- erőforrás kezelés (autó, tárgyaló, nagyértékű eszközök)
- naptár kezelés, ahol látjuk, hogy ki foglalt/szabdságon/kiküldetésen van, tehát ne adjunk rá feladatot.

Dolibarr, komplett ERP rendszer bovitheto fizetos es ingyenes modulokkal de lehet irni is hozza.
6 eve hasznalom es eddig meg mindent tudott amit a fizetosok.
"Itt egy talicska föld. Mit csináljak vele? Ások neki egy gödröt."

Anélkül, hogy ismerném a linkelt rendszert, kíváncsi lennék, hogy hány rendszerben van valóban modulárisan elhelyezve a dolgok. Mert amivel nekem kellett dolgozni, az mindem volt, csak nem moduláris. A modularitás kimerült abban annyiban, hogy a másik "modulhoz" tartozó dolgok más menüpont alatt voltak :)

Csak mert akárhány magyar ERP-t látok, mind a modularitással próbálja eladni magát.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ez teljesen jogos. Ha belegondolsz lehetetlen valóban a teljes szétválasztás. A "modul" kifejezés a vevőnek szól, nem a szakmának.

Dehogy lehetetlen, csak meg kell csinálni normálisan az interfaceket.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Szerintem ekkor is sok közös rész lesz. (Főleg, ha nem akarsz nagyon sok rétegű öröklést.)

Erre érdekelne milyen jó megoldásokat láttok, nekem elvi szinten kérdéses néhol, hogy létezik-e tényleg 100% moduláris rendszer, aminek a moduljai összeköthetőek, tudnak egymásról, ..., és hogy hogy néz ez ki az OOP világban.

Mi köze az interfaceknek az öröklődéshez? Van mondjuk egy számlázó modulod. Kifele csak egy interfacet kell belóle látni. Ez az interface nem feltétlen egy OOP-s interface, akár lehet egy webapi is. Két dolognak kell ismertnek lenni, az az interface és az adattovábbításra használt adatszerkezeteid. Hogy aztán azzal egy modul belül mit kezd az már érdektelen. Ez az adatszerkezet amúgy lehet egy halom POCO/POJO, stb. XML séma, fson dokumentum, bármi.

Lényeg, hogy minden modul egy önálló egységet alkosson. Nem baj, ha kommunikál más modullal is, de azt tegye jól definiált interfacen, ne spagetti módon.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ja így már értem amit mondasz. Azt hittem, hogy kb a szolgáltatás elirigylésről volt szó.

Tekintettel arra, hogy spec. én is ERP rendszer keresek ajánljatok már valamit, mert már ott tartok a hazai felhozatalt látva, hogy SAP Bussines One mellet fogom letenni a voksomat az árak láttán... :(

Mint fejlesztő nyilván hazabeszélek, de elég sokszor láttam azt, hogy a mi árajánlatunk mellé odaraktak sok másikat, pl. dobozos megoldásokat, amik nem módosíthatok (nem vendor lock in, hanem úgy egészében, gyártó mondja, hogy semmit nem módosít, vagy embertelen áron és 3 éves átfutással, gyakorlatilag 10-20 éve írt egy raktárkezelőt, azóta kicsit foltozta), de legalább olcsók, vagy a nagyon módosítható, nagyon standardizált rendszereket (pl. SAP, vagy Salesforce, vagy MS Dynamics alapú, ezért mindig van hozzá továbbfejlesztő), amik viszont nem a magyar KKV indulásánál térülnek meg, nem is megfizethetők nekik, stb. (de fixme, ha rosszul tudom az árakat, nem sales-es vagyok). Valahol a kettő között van az egyedi fejlesztést keresek, olyan programozóval, aki forráskódot ad át, és vállal üzemeltetést, nagyon cégméret függő, nagyon kérdés, hogy mennyire ismered vagy van kidolgozva a céged összes folyamata (ha nincs az minden megoldással drága mondjuk). Szerintem írj cégméretet, esetleg profilt, speciális igényeket, az alapján be lehet lőni merre érdemes nyúlni.

(Az open source megoldásokra építést én egyedi fejlesztésnek nevezem, átadott kóddal.)

Open-source ERP-ből én a következőket néztem meg eddig közelebbről, de egyelőre egyiket sem vezettük be:

1. Compiere család (Java alapú)

A gyökerei a 2000-es évek elejére nyúlnak vissza, az Oracle egyik volt ERP Architect-je kezdte el csinálni, azóta több fork is történt, jelenleg az iDempiere és a Metasfresh ezek közül amikkel nekiállnék bárminek is.

2. ERPNext (Python alapú)

Viszonylag új, néhány éve pörgött fel a fejlesztése, ERP-ktől szokatlan módon ránézni is kellemes. Érdemes megnézni.

3. Régebben néztem Oodo (volt OpenERP)-t, és ebből forkolt Trytont, irogattam ide a fórumra is róluk, de pár éve már nem jártam arra.

Ezek közül tudtommal egyik sincs teljesen magyarítva (pl. magyar szabályoknak megfelelő számlaadás / könyvelés), bár talán magyar számlatükör mindegyikhez létezik.

Nem tudok tanácsot adni, mert én 2003-tól saját magamnak fejlesztem a rendszeremet amit csak a saját vállalkozásaim használnak.
Viszont tudok mondani egy blogot: https://erp-blog.blog.hu/
Itt hup-on sokan fejlesztenek ERP-t. Ezek közül egyik ami egem tudásában lenyűgöz (hihetetlen diverzifikált ügyfélkör miatt rengeteg számlázási problémát oldottak meg) a royal féle EVIR, de hogy ne csak nyaljak neki, megemlítem, hogy a menüje nem tetszik. :) Valamint rengeteg olyan funkció van szerintem egy cég életében amit bele lehetne még integrálni.

Nekem a filozófiám a témában az, hogy minden dolgozó aki gépet használ annak ne kelljen kilépnie az ERP alkalmazásból a munkavégzés során, vagyis mindent el tudjon benne végezni. Nagyon fontos, hogy nagyságrenddel több adat jöjjön ki, mint ami be lett víve. Támogassa a csoportmunkát. Na én ilyet nem találtam ezért írtam egyet magamnak.
(Nem eladó. Másnak a jelenlegi formájában egy vacak, mert tartalmazza az üzleti szemléletet maga a kód. Nem is kívánok a piacon megjelenni vele.)

"üzleti szemléletet maga a kód" + "Nem is kívánok a piacon megjelenni vele"
#YouAreMyHero :)

Miért nem bírják mások ezt megérteni: saját folyamatokra saját rendszert. Ha papírzsepit kereskedő vagy akkor talán van olyan kész doboz ami lefedi az értékesítési feladataidat, minden másra ott a mas.. saját rendszer.. csak azt a saját rendszert nem kéne "generalizálni" és másnak odaadni hogy na ez jó lesz neked is..

Mert van rengeteg olyan folyamat, ami nem annyira saját, legfeljebb sajátos és az se biztos, hogy mindig jó (ld. a fenti sztorit, mikor a raktárvezető úgy gondolja, hogy a tárhelyes raktár hülyeség*, és ezt nem is lehet jobban csinálni). Vagy van egy halom olyan folyamat, ami törvényileg elég jól szabályozott és nem is csinálhatod máshogy.

Plusz, saját szoftvert karbantartani idő és rengeteg pénz. Dolgoztam kereskedő-cégcsoportban szoftverfejlesztőként, nem annyira triviális ez a legtöbb cégnek.

* Amikor a szoftver nyilvántartja, hogy mi hol van, forgási sebesség alapján javaslatot tesz, hogy a gyorsan/átlagossan/lassan fogyó cikket előre vagy hátra tedd a raktárba és ez alapján ad egy optimalizált kiszedési listát, stb. Plusz, mivel praktikus nem egyforma dobozó termékeket nem egymás mellé rakni nem kell kotorászni, a polcon, hogy akkor ez most az XYZABCDEFG123-01 vagy az XYZABCDEFG123-02-es verzió.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Na a raktár a legjobb példa! Nálunk -mivel gyártunk- fix helyek (+FIFO) van. Nekünk nem kell olyan rendszer, amelyben egyfajta termékből n darab lehet n darab helyen. Továbbá mivel gyártunk, így a termék foglalás sem szentírás, hanem leginkább csak egy flag, ami segít jelezni a termelés ütemezését. Így az az eladott termékekkel is tudunk többszörösen rendelkezni. Sokan gondolnák, hogy ez káoszhoz vezet. Nem. Ugyanis a saját tapasztalat, hogy a vevői viselkedések a múlt alapján jósolhatóak, amelyekből lehet tudni, hogy ki miért rendel és mennyivel hamarabb, továbbá mivel gyártunk tudjuk, hogy mennyi idő alatt készülünk el a következő sarzzsal. Olyan rendszer pedig nem ismerek ami ilyen dolgokat figyel, pedig ez hatalmas előny.

Azért azt el kell mondanom, hogy nem aspergeres vagyok aki neki esett egy ERP-nek, hanem amikor időm volt és pénzem semmi, akkor mindig valami kis megoldást alkottam egy-egy egyszerű alkalmazás által. Ezeket hamar beraktam egy keretrendszerbe, majd azt vettem észre, hogy minden dolgozó már ezen felületen végzi az egész napos munkáját. Eleinte 3rd party számlázót használtunk, amely nevetséges bugokat produkált. Egyszer megmértem, hogy 1 db számla megnyitása 1,5 megabyte SQL adatforgalommal járt (rendszeresen elhasal az SQL miatt). Innen nem nehéz megsejteni, hogy emiatt ezt is megírtam szintén integrálva a keretrendszerbe.

Hogy helyes döntés-e a saját ERP?
A válaszom: igen, nem, nem tudom.
Mindegyik mellett tudok érvelni.

Hogy ma helyes-e, hogy még mindig én írom? (Holott nem lenne már probléma beszállítói termék választása sem.)
A válaszom: igen, nem, nem tudom.
Szintén mindegyik mellett tudok érvelni. De!!! Ismerek olyan esettanulmányt, hogy más hozzám hasonló kidobta a saját maga által írt core rendszer és migrált SAP-ra, majd 100 milla után elővette a régi kódját és felvett maga mellé még pár embert programozni.

Dobozos termék ~ dobozos cég. Szerintem optimális esetben egy KKV rendelkezik a szervezésben is versenyelőnnyel, ami nem más mint a sajátságok kihasználása. Aki ezt nem használja ki, pénzt dob ki az ablakon és hátrányba kerül. Meggyőződésem, hogy az alábbi mutatókban azért vagyunk iparágon belül az élen, mert a saját rendszer illetve a cégvezetés integrálva van a rendszerben. Sok esetben nem mi dolgozunk a rendszerben, hanem a rendszer dolgozik helyettünk. Nem egy programot csináltam amiben el lehet végezni a munkát, hanem a munkát programoztam le.

Mutatók amiben az élen járunk:
árbevétel/fő
profit/fő

Méret ismeretek nélkül ez lehetetlen.

SAP Bussines One egy beetető termék. Van egy cégméret amikor ez megéri. kb évi 2-300 millió huf adózás előtti eredmény minimálisan. Ugyanis nem csak az SW költsége fog megjelenni, hanem kell hozzá alkalmazott is aki a képzés után értékesebb lesz a munkaerőpiacon, ami gazdaságilag negatívan visszahat.