ERP és CRM - szakértői szemmel

A mai fejlődő információtechnológiai világban, egyre gyakrabban találkozunk „a szoftver mint szolgáltatás” (Software as a Service, SaaS) kifejezéssel. Egyre több alkalmazás felhasználását kínálják a vállalatok az interneten hozzáférhető változatban, amely a felhasználók részéről nem igényel telepítési és karbantartási feladatokat. A cikksorozat célja a terület körbejárása, jelenlegi helyzetének megvizsgálása, az általa érintett technológiák, kihívások, problémák és megoldások bemutatása, bekerülési költségek elemzése, valamint a jövőbeni lehetőségek felvázolása. A legelején fontos megjegyezni, hogy az SaaS kifejezés nem csak a fenti, általunk jelenleg használt, jelentést hordozza magában, hanem a következő módon is érthető: Az alkalmazások egyrészt a végfelhasználók számára nyújtanak szolgáltatásokat, másrészt más alkalmazások felé is biztosítanak integrációs pontokat, így a szoftver egyben szolgáltatásként is elérhetővé válik.

 

Az alkalmazások fejlődésük során, számos különböző állapoton átestek már. A történet a nagyteljesítményű számítógépekkel kezdődött, amelyekre terminálok csatlakoztak - és használták az erőforrásait programok futtatására. Majd jöttek a kliens-szerver alapú megoldások, ahol a szerveren lévő adatbázist / szerveralkalmazást használták, a kliensek erőforrásai révén. Ezt követték a vékonykliens alapú megoldások, ahol az alkalmazásokat már egy webböngészőből tudtuk futtatni. Innen már csak egy lépés a SaaS technológia, ugyanis megteremtődtek a hálózati sebességhez kapcsolódó feltételek. Tulajdonképpen ezzel visszajutunk a kiindulóponthoz: ismét nagyteljesítményű központi számítógépeket használunk terminálokon, azzal a különbséggel, hogy nemcsak a hardverünk és szoftverünk lesz egy szolgáltatónál elhelyezve, hanem az adataink is.

 

Az alkalmazások szállítóinak nagy része már kialakította a termékeikhez megfelelő licencelési konstrukciókat, tehát már sokak számára elérhetők a szolgáltatások. Többféle modellben működik a megoldás, amely gyártónként változhat, de a paraméterek nagyon hasonlók. Az egyik paraméter a futtató szerver tulajdonjoga, valamint hogy a felhasználóknak lehet-e adminisztrátori hozzáférése a szerverhez és az alkalmazásokhoz. A szerver lehet az ügyfél vagy a szolgáltató telephelyén, szervertermében, viszont a felhasználónak nem lehet adminisztrátori hozzáférése a rendszerhez. Mivel jelenleg már operációs rendszerek, és felhasználói alkalmazások is elérhetők ebben a konstrukcióban, ez azt jelenti, hogy valamilyen szolgáltatási szerződés szint (Service Level Agreement) is kapcsolódóik hozzá. Továbbá paraméternek tekintjük még a felhasználók számát, valamint a felhasználás időtartamát.

 

A technológia egyik legnagyobb előnye, hogy nem igényel hardver / szoftver beruházást egy projekt elindítása, legyen az ügyfélkapcsolat-kezelés (Customer Relationship Management, CRM), vállalatirányítási információs rendszer (Enterprise Resource Planning, ERP) vagy bármely egyéb összetett alkalmazás, csak tanácsadói szolgáltatást. Költségekben gyakran ez sem tekinthető kicsinek, de a fentiek nélkül elfogadhatóbb, hiszen a felhasználásért havonta, előfizetéses formában kell fizetni a szolgáltató felé. A másik előnye, hogy egyes szolgáltatóknál havi jelentés formájában van lehetőség megadni, hogy hányan használták a rendszert, és csak a tényleges használatért kell fizetni. A harmadik előnye a fenti kettőből következik: teljes mértékben tervezhető a költsége, amely egyébként jóval alacsonyabb, mintha megvásárolnánk. Nem amortizálódnak a szerverek, nem kell az alkalmazásból állandó frissítést venni, és nem kell erőforrás az eszközök működtetésére.

 

A megközelítés gyenge pontja, hogy ha épületen kívül van a szerver, akkor az internet elérésnek folyamatosnak kell lennie, ellenkező esetben nem tudjuk igénybe venni a szolgáltatást: nem tudunk dolgozni. Vállalati környezetben célszerű más szolgáltató, más technológiára épülő kapcsolatából vészhelyzeti kapcsolatot létrehozni. Ezen felül nagyfokú bizalomra van szükség, hiszen a teljes rendszer, és adatállomány közvetlenül a szolgáltató által tulajdonolt szervereken vannak, és az ilyen helyzetek esetenként igen kényesek.

 

Elöljáróban azt mondhatjuk, hogy általános becslések szerint, ha olyan alkalmazást vásárolunk, amelynek a vásárláskori verzióját még 4-5 év múlva is tudjuk használni, akkor nem éri meg az előfizetéses rendszer. Viszont ha legalább egy verziót frissítünk, akkor az előzőleg említett 4-5 év, már 7-8 évre nő.

A konnektor támogatja a kétirányú szinkronizációt a CRM és NAV (illetve a CRM és az AX) között, ezzel biztosítja a rendszerek adatainak aktualitását. A legnagyobb előnye, hogy növeli a munkatársak hatékonyságát, csökkenti a kézzel elvégzendő munka mennyiségét, valamint csökkenti a hibázási lehetőségek és ez által a hibák számát.

A részletes dokumentáció és a hozzáértő, magas szintű támogatás teszi a konnektort igazán használhatóvá. Első ránézésre a dokumentáció igen bőbeszédűnek tűnik, de valójában arról van szó, hogy lépésről-lépésre vezet végig a telepítésen, valamint részletesen, példákkal illusztrálva mutatja be a testreszabási, kiterjesztési lehetőségeket.

A telepítés után egy üres, szinkronizálási szabályokat nem tartalmazó konnektort kapunk. Problémás lenne, ha mindent nekünk kellene nulláról kialakítani, de szerencsére az out-of-the-box (OOB) konfiguráció betöltésével a leggyakoribb szinkronizációs forgatókönyveket már támogathatjuk.

A konnektor több eszközzel is segíti a munkánkat, melyek közül a Synchronization Studio, Microsoft Workflow Foundation alapokon, egy grafikus felületet biztosít a szinkronizálási munkafolyamatok kialakítására. Kifejezetten hasznos a részletes nyomkövetés, amely a munkafolyamatok lépésről-lépésre történő áttekintését teszi lehetővé.

Őszintén be kell vallani, hogy az első projektben a konnketort nem ismertük, többet kellett a fejlesztőikkel levelezni, például nem volt triviális, hogyan töltsük fel a NAV „Sales Header”-ben a nem alapértelmezett dimenziókat, vagy hogyan hozzunk létre a „Dimension Value” táblában új rekordot, hogy a dimenzió mezőt kitölthessük vele. Ennek ellenére a szinte azonnali válaszoknak és a részletes dokumentációnak köszönhetően mégis tempósan lehetett a bevezetéssel haladni.

 

 

Azzal a feltételezéssel élve, hogy a partner (vevő és szállító) törzset mindkét oldalon szeretnénk módosítani, karbantartani, a cikktörzs kezelése pedig ERP oldalon történik, továbbá az értékesítési folyamat támogatására a CRM rendszert használjuk a következő három fő területet emelhetjük ki:

a)      CRM Partner és NAV Vevő, Szállító szinkronizálása,

b)     CRM Termék és NAV Cikk szinkronizálása, valamint

c)      Üzleti folyamat megvalósítása a CRM, NAV és konnektor segítségével, további fejlesztéssel.

Az egyes területek részletei a következők.

 

 

A megoldás kétirányú, támogatja, hogy tetszőleges partner információ átmozgatásra kerüljön a másik oldalra. Az OOB beállítással alapadatok átmozgatása történik. Egy említésre méltó módosítás, amely növeli a CRM à NAV irány esetén a NAV oldalra megérkező vevő rekordok felhasználását a vevősablonok kezelése. A CRM oldalon egy választómezőben biztosíthatunk lehetőséget a vevősablon kódjának (például BELF, EU, KÜLF) kiválasztására, amely alapján a Vevősablon tábla tartalmának megfelelően a konnektor a NAV oldali vevőnél feltölti a „Vevői könyvelési csoport”, „Ügyletkönyvelési csoport” és „Áfa-ügyletkönyvelési csoport” mezőket.

A szinkronizációt mindkét oldalról a partner felvétel, módosítás és törlés (insert, update, delete) műveletek indítják. NAV oldalon további lehetőség még a meglévő, de nem szinkronizált rekordok replikálása. CRM oldalról erre az alap update művelet használható. Ezek segítségével már korábban használt rendszerek utólagos összekötése is megoldható.

 

 

A termékek esetén az alap szinkronizáció egyirányú: NAV oldalról történik a CRM felé. Tehát a CRM-ben rögzítésre kerülő termékek nem kerülnek át a NAV oldalra. Továbbá az OOB csak a NAV cikkekre ad munkafolyamatokat, de pár órás munkával elérhető, hogy például az erőforrások is szinkronizálódjonak. Ha az ehhez tartozó munkafolyamatokat elkészítjük, akkor a munkafolyamatok exportálása és importálása segítségével más telepítésekre is percek alatt átmozgatható a megoldás.

A cikkek mozgatásán kívül a cikk mértékegységek mozgatására is szükség van, melyet a konnektor szintén támogat.

 

 

A támogatni kívánt munkafolyamat a következő főbb lépésekből áll:

1.      CRM Lehetőség (projekt) létrehozása, kitöltése: az értékesítő végzi, kézzel történik.

2.      CRM Ajánlat létrehozása a CRM Lehetőségből: az értékesítő végzi, kézzel történik, a lehetőségben kitöltött mezőket a CRM automatikusan átemeli az ajánlatba.

3.      CRM Megrendelés létrehozása a CRM Ajánlatból: az értékesítő végzi, kézzel történik, a megfelelő mezőket a CRM automatikusan átemeli az ajánlatból a megrendelésbe.

4.      CRM Megrendelés à NAV Rendelés, NAV Keretszerződés: konnektor végzi.

5.      NAV Rendelés, vagy NAV Keretszerződés à NAV Számla.

6.      NAV Számla à NAV Könyvelt számla.

7.      NAV Könyvelt számla, könyvelt számla sor à CRM Számla, számla termék: konnektor végzi. CRM Megrendelésnél és CRM Lehetőségnél (Projektnél) megjelennek a számlák.

A folyamatban a konnektor két helyen kap szerepet. Először a CRM Megrendelés à NAV Rendelés (vagy NAV Keretszerződés) esetén. A szinkronizációt indító események az új megrendelés felvétele, megrendelés módosítása, valamint megrendelés törlése (insert , udate, delete). Természetesen a konnektorban beállítható, hogy a szinkronizálás csak adott feltételek teljesülése esetén történjen meg. Erre példa, hogy csak akkor célszerű átmozgatni a CRM Megrendelést a NAV oldalra, ha a megrendelés visszaigazolt, amelyet egy újonnan felvett igaz/hamis mező értéke jelezhet. A konnektor második szerepe a folyamatban a lekönyvelt dokumentumok CRM oldalra történő mozgatása.

A NAV oldalon tovább automatizálhatók a dolgok: ha a CRM oldalon a megrendelés attribútumai alapján a konnektor a NAV oldalra keretszerződést készít, akkor a NAV oldalon több számlát, például havi rendszerességgel állíthatunk ki. A számlázási gyakoriság alapján (hónap, negyedév, félév, év), amely saját mezőként jöhet a CRM oldalról, a könyvelendő számla fejek és sorok generálhatók hónapról-hónapra egy NAV riport segítségével. A riport figyelembe veszi a keretszerződések számlázási gyakoriságát, a számlázás utolsó időpontját és ezek alapján készíti el a számlákat, akár törthónapokra vonatkozóan is.

 

A munkánk hatékonyságának növelése céljából a rendszerek integrációja igen fontos szerepet jelent. Az MSCRM és a Microsoft Dynamics NAV esetén a két rendszer egy összekapcsolásának kényelmes eszköze a bemutatott konnektor. Fontos még egyszer kihangsúlyozni, hogy a konnektor jól támogatja a két rendszer együttes használatával elérhető folyamatok kialakítását, valamint a minél magasabb szintű automatizálást.

Több olyan ügyfél is van, akikről az érdeklődésük alapján nem tudjuk azonnal eldönteni, hogy CRM vagy ERP rendszerre van szükségük. Az esetek egy részében az ügyfelek maguk sem tudják, mert nincsenek pontos ismereteik arról, hogy egy adott CRM vagy ERP rendszertől milyen funkcionalitásokat várhatnak el. Az ügyfelek nagy része több rendszert is megvizsgál, megismer a döntés előtt. Természetesen mindenkinek vannak preferenciái, ami alapján az integrációs lehetőségeket szem előtt tartva adott gyártóhoz húz, vagy az árat nézi, legyen az induláshoz vagy a folyamatos üzemelhetéshez tartozó. Például, kezdenek Magyarországon is elterjedni a bérleti konstrukcióban használt ERP és CRM rendszerek: egyre több alkalmazás felhasználását kínálják a vállalatok az interneten hozzáférhető változatban, amely a felhasználók részéről nem igényel telepítési és karbantartási feladatokat, és ugyanakkor jobban tervezhető ráfordítást jelent.

A rendszerek közti választásban alapvetően az ügyfél által elvégezni kívánt feladatok döntenek. Talán az egyik legegyszerűbb mód a CRM és az ERP közötti döntésben a következő kérésre kapott válasz alapján történik: szeretnénk-e a rendszerben könyvelni. Ha igen, akkor CRM rendszert nem használhatunk erre a funkcióra. Ha nem szeretnénk könyvelni, hanem az elsődleges cél az ügyfélkezelés, az ügyfelekhez tartozó folyamatok rendberakása, minél inkább formalizálása, akkor pedig a CRM mellett döntünk. Mindezek mellett több cég dönt mégis úgy, hogy a funkcionalitások teljes körű kielégítésére több rendszert használ. Természetesen az ERP szoftverek nagy része is kínál CRM modult, de a két rendszer melletti döntést leginkább e modulok szegényes funkciókészlete motiválja. Ha több rendszert használ egy vállalat, akkor jogos igény, hogy egy adott módosítást, csak az egyik rendszerben kelljen elvégezni. Legjobb példa erre a partneradatok. Ez több okból is fontos funkcionalitása a teljes rendszercsomagnak. Egyrészt csökkenti a felhasználói ráfordítást, valamint a hibázási, elírási lehetőséget, másrészt pedig nem kell a licensz számokkal foglalkozni. Ez utóbbi azt jelenti, hogy aki például partnert rögzít az egyik rendszerben, annak nem feltétlenül kell hozzáférést biztosítani a másik rendszerhez. Ezzel adott esetben több költség takarítható meg, mint a két rendszer összekapcsolásának a licensz és tanácsadói költsége.

 

Jelen cikk a Microsoft Dynamics NAV és az MSCRM rendszerek összekötésével foglalkozik, melyhez a Celenia CRM Connector eszközt használjuk, ajánljuk. A konnektorra támaszkodva olyan üzleti folyamat kerül bemutatásra, amelyet már több vállalatnál is, természetesen kisebb-nagyobb módosításokkal, implementáltunk. A folyamat lényege, hogy CRM-ben kerülnek rögzítésre a partnerek, kapcsolattartók, valamint a lehetőségek (projektek), ajánlatok és megrendelések. A konnektor átmozgatja egyrészt a partner és kapcsolattartó információkat, másrészt pedig a megrendeléseket. A NAV oldalon a megrendelésekből vevői rendelések, illetve vevői keretszerződések lesznek. A keretszerződésekkel kezelhető, hogy az egyes megrendelések ne egy alkalmas teljesítést, hanem folyamatos, akár support jellegű szolgáltatásszerződést képviseljenek. A NAV oldali feladatok, majd könyvelés elvégzését követően a könyvelt bizonylatok pedig visszakerülnek a CRM oldalra és becsatolódnak az egyes partnerek, lehetőségek (projektek), valamint megrendelések alá.

 

A folyamat lényege, hogy az értékesítők a CRM oldalon, a könyveléssel, raktárkezeléssel, stb. foglalkozók pedig a NAV oldalon tevékenykednek. Egymás munkáját látják, mert a konnektor minden a számukra lényeges, a munkájukhoz szükséges információt átmozgat a megfelelő oldalra, a szükséges rekordokat előkészíti, a megadott szabályok szerint kitölti.

 

A következő részben egyrészt a Celenia CRM konnektor kerül bemutatásra, másrészt pedig a teljes folyamat részleteit tárgyaljuk.