Engedjék meg, hogy egy saját bölcselettel kezdjem:
Hogyan mutatkozik meg egy ember személyisége, és hogy én hogyan ítélek meg embereket.

1. Először is rövidtávon, az első benyomás az ami meghatározó
2. Majd hosszabb időt együtt töltve, amikor felszínre kerülnek a személyes tulajdonságok
3. És végül nehéz helyzeteken vagy bajban

Miért is kezdem így? Most talán épp a nehezebb helyzetek egyikéhez értünk. A dolog lényege, hogy bármennyire is jól kommunikál a projektvezető egy projektet, az ügyfél a végeredményt szeretné látni. Szép felületet, színes logót és szélsebes kereséseket. Hát igen, a technikai beállítások, RFC kapcsolatok, Remote User készítések, Replication Filter-ek létrehozása és a többi, pedig nem tartozik a látványosságok közé. Ezzel arányosan tapinthatóvá válik a feszültség, hogy minden rendben van-e, biztos menni fog ez valaha, tulajdonképpen miket is nyomkodnak itt és mire használják a drága tanácsadói napokat, illetve a sok elfogyasztott „coffeet” ?Igen ezek nem könnyű kérdések, de lássuk is hogyan alakul a rendszer a prés alatt.

Az ERP - CRM integrációhoz logikai rendszereket és RFC kapcsolatokat kell definiálni mind ERP mind CRM oldalon, oda-vissza, hogy elérjék egymást.

Előbb SM59-ben kell az RFC kapcsolatokat létrehozni. Ennek a legfőbb paraméterei az elérni kívánt rendszer paraméterei, név vagy IP cím alapján, a száma és az, hogy milyen felhasználóval kívánunk oda bemenni. Jelen esetben egy egyszerű dialog user-t definiáltam minden kapcsolathoz. Teszteltem az unicode kompatibilitást, majd megpróbáltam vele belépni.

Itt szeretnék minden kedves olvasómnak egy napi elkeseredett próbálkozást megspórolni egy apró trükkel.

A jelszó mindkét oldalon legyen mindig csupa nagybetű!

Mégpedig azért mert a régebbi kiadások nem tettek különbséget kis és nagybetű között, mindent nagybetűre konvertálva mentettek az adatbázisba. Mikor egy újabb verziójúval próbáltam kapcsolódni, ami már különbséget tesz, a beállított jelszó nem egyezett.

’WELCOME’ <> ’welcome’

És milyen igaza van. Egy napi próbálkozásba tellett ennek a kis turpisságnak az észrevétele. Viszont az önálló feladatmegoldás öröme annál nagyobb volt a végén. Mindenki szinte önfeledten ugrált és kiabált mikor rájöttünk :)

Szükséges az aktuális Client beállítása, meg kell adni a hozzá tartozó RFC kapcsolatot, azt hogy mi a Client szerepe, például customizing, vagy hogy ECATT script-ek futtatását engedélyezzük-e. Emellett a védelmi szintet is definiálni kell, ami azt jelenti, hogy Client Copy esetén hogy működjön, plusz milyen objektumokat engedjünk változtatni, mint mondjuk Repository és Cross-Client Customizing típusúakat. A hozzá tartozó tranzakció az SCC4 – Client Settings.

Az alkalmazásszerverben kell a működését befolyásoló paramétereket beállítani. Ez az RZ10 tranzakcióban történik.

A WAS profil beállítása

Amit néhány újraindítás követ. Tudni kell hogy ezek a paraméterek csak a rendszer következő újraindításakor lépnek életbe. Így célszerű összegyűjteni őket, még ha látszólag nincs is mindnek jelentősége és egyben beállítani őket.

A CRM 5.2 egy teljesen WEB felületre készült alkalmazás ezért beindításához szükségünk vannak a WEB szervizekre. A leírás részletezi melyik mire való, majd később újabbakat kell aktiválni újabb funkciókhoz. Elkerülve azokat a jeleneteket, hogy vajon megint mi lehet a gond az egésszel, az összest a root object-től kezdve érdemes egyben aktiválni. Nem bántanak senkit. Ezt egyszerűen a SICF tranzakcióban lehet megtenni, mindenféle szűkítés beállítása nélkül, aktiválni a root-tól lefelé mindegyiket.

Ha családfa kutatásba kezdenénk, hogy kik lehettek a CRM ősei, akkor tapasztalt SAP-sok joggal vélnék felfedezni, hogy bizony Sales and Distribution (SD) és Human Resources (HR) modulok az ősei.
Ezért a CRM egyik központi eleme a szervezeti felépítés, vagyis a szervezeti felépítés modellje az Orgmodel. Ez a PPOMA_* tranzakciókból érhető el. Az Orgmodel szerepe sokrétű, felépítése összetett és persze nagyon flexibilis is a leírása szerint. Ezzel pont annyira voltam eleinte kisegítve, mint most önök. Összefoglalnám a legfontosabb szerepeit és funkcióit oly módon, ahogy a projekt keretében használtuk ezzel egy gyakorlati és használható leírást adva róla.

Az Orgmodel-ben a három legfontosabb objektum az Organizational Unit mely szervezeti egységeket reprezentál, a Positions, mely beosztásokat valósít meg és az Employees/Users melyek az alkalmazottak megfelelői.
A bevezetési projekt keretében egy olyan szervezeti felépítést készítettem mely funkcionális szempontból reprezentálja a céget. Azokat a szervezeti egységeket és pozíciókat kell leképezni melyek funkcionális szempontból különböző tevékenységeket, végeznek. Ez néha eltér a szervezet jogi felépítésétől.

Szervezeti felépítés az SAP-ban

Az egész lényege, amellett hogy kapunk egy képet a szervezetünkről, hogy az itt leképzett egységek fogják a kiinduló adatot szolgáltatni pl. a jogosultság ellenőrzéshez. (pl. Adott dolgozó, értékesítési asszisztensi pozícióban csak a saját értékesítési szervezetén belül változtathasson meg dokumentumokat, és a többi szervezeti egységen belülieket csak megjeleníthesse)

Másik fontos alkalmazása az u.n. Partner Determination és Sales Area Determination. Ez az jelenti hogy amikor különböző dokumentumokat készítünk, azoknak tartalmaznia kell a Sales Area Data adatait (Sales Org, Division, Distribution Channel, Sales Office, Sales Group). Ezeket az adatokat annak függvényében hogy melyik egységhez van a felhasználó hozzárendelve a rendszer felajánlja automatikusan.

Ennek ismeretében már látható, hogy annyi szervezeti egységet és pozíciót kellet definiálni, ahány különböző jogosultságú értékesítési csoport van a cégben. Ezt az adott terület üzleti vezetőjével és szakértőével kellett egyeztetni. Elsőre talán egyszerű de sok megbeszélést és utánajárást igényelt, míg meghatározták milyen értékesítési csapatuk is van. Voltak pillanatok mikor ők is meglepődtek, hogy kik is vannak cégben és mit, illetve mit nem csinálnak. Erre mondják, hogy egy bevezetés racionalizálja a folyamatokat, netán karcsúsítja a szervezetet.

Az Orgmodel magában még nem oldja meg a jogosultsági kérdéseket csak lehetséges bemenő adatokat szolgáltat hozzá. A jogosultság ellenőrzés itt is jogosultság objektumokon alapszik és a PFCG profilokon alapszik.

.
A CRM jogosultsági objektumainak hierarchiája

A különböző dokumentumokhoz való hozzáférést több szinten ellenőrzik, és több szinten lehet hozzá jogosultságot szerezni.

Az első ellenőrzés az u.n. Own Document. Amennyiben az adott felhasználó a dokumentumban megjelölt Employee Responsible akkor mindegy melyik Sales Area-hoz tartozik a dokumentum jogosultságokat, adhatunk neki hozzá.

A második szintű ellenőrzés a szervezeti egységeken alapuló ellenőrzés. Itt beállítható, hogy ha a dokumentum a felhasználóhoz tartozó Sales Area-ban van, akkor dolgozhasson rajta. Ez az adat az Orgmodel-ből jön, így a szervezeti egységből kiindulva felfelé megadható, hogy még hány szinthez szerezzen jogokat.

Az ellenőrzéseknek még sok további lépcsője is van, szerencsére a projekt követelményeit e kettővel is ki lehetett elégíteni. Az ellenőrzés lényege hogy amennyiben egy szinten jogot kap, akkor megáll, ha nem akkor tovább nézi a CRM alkalmazás, hogy további szinteken szerezhet-e jogokat az adott művelethez. Hogy ez így két szinten működjön a maradék objektumot inaktív állapotba tettem, nehogy nem kívánt jogosultságokat adjanak.

Ezzel be is zárult az a logikai egység mely során leírtuk a szervezetet és felkészítettük a rendszert a különböző felhasználók kezelésére. Következőkben megmutatom, hogyan is kötöztük össze az ERP-vel és miként replikáltuk a terméktörzset, vevőtörzset, kontaktokat valamint még néhány customizing adatot.

Várok mindenkit szeretettel a következő számra, amiben megint megpróbálok néhány életképet megosztani a bevezetés mindennapjaiból is.