Hirdetés
 

SAP CRM 5.2 bevezetése IV. rész - Konfigurálás

PDF
Nyomtatás

Middleware és CRM tranzakciók

Most hogy a rendszer technikailag összeállt, következnek azok a beállítások, melyek igazán testreszabják és a felhasználók igényeire alakítják CRM rendszerünket, valamint feltöltik adatokkal az ERP rendszerből. Lássunk ebből egy ízelítőt összefoglalva a lényeget.

CRM és ERP rendszerek integrálása

RFC kapcsolatokat definiálni mindkét oldalon a cél rendszerekhez (Tx:SM59)
Ez a kommunikáció alapja, a technikai megvalósítása a két rendszer közti átjárásnak RFC kapcsolaton keresztül.

Kliens adminisztráció ahol módisíthatóvá állapotba állítjuk (Tx:SCC4) és egy logikai rendszert kapcsolunk az aktuális klienshez. Fontos hogy a módosítások végrehajtása engedélyezett legyen. Ez a fejlesztői környezetben természetes, de a törzsadat replikációt rendszerenként egyesével kell végrehajtani nem transzportálhajuk, ezért ezt engedélyezni kell a kliensnek ezt. Ez egy produktív rendszer esetében nem is mindig olyan egyszerű, mert általában hosszas engedélyezési és adminisztrációs folyamaton kell átmennie a kérelmünknek.


Kliens Beállítások

Logikai rendszereket definiálunk minkét oldalon (Tx:BD54)
A logikai rendszer tulajdonképp egy kapcsoló az RFC kapcsolat és a klienshez rendelt logikai kapcsolat között ezzel is átláthatóbbá téve egy bonyolult rendszer összeállítást.

A kliensekhez hozzárendelni a logikai rendszereket (Tx:BD97)
Végül megmondjuk melyik klienshez, melyik kapcsolat tartozik. Itt különböző típusú kapcsolatok definiálhatók, nekünk jelen pillanatban nem kellenek Bapi hívások, csak funkciós modulhívások számára kellenek célok.


RFC kapcsolatok klienshez kötése

Rendszerek felkészítése a CRM kezelésére (Tx:SE16 CRMCONSUM, CRMRFCPAR, CRMPAROLTP)
Van néhány tábla mind ERP mind CRM oldalon, melyek tartalmazzák milyen konstellációban dolgozunk, egyedüli CRM vagy ERP és CRM esetleg egy APO integráció is jelen van mondjuk a global ATP Chek-hez.

Itt osztanék meg egy szakállas trükköt. Ezek sima adatbázistáblák maintenance view nélkül. Így néhány bejegyzés módosítása is már fejtörést okozhat vagy kezdőbb tanácsadót esetleg maintenance view generálásra, sarkallhat. Nem javaslom, van egy kevésbé legális, de annál hatékonyabb táblatartalom módosítási módszer is, és persze mint minden féllegális módszer ez is a debuggerrel kezdődik.

  • Tehát végy egy SE16-ot és tekintsd meg a kívánt tábla tartalmát.
  • Válaszd ki a módosítani kívánt sort, dupla klikk rajta
  • Mikor csak az az egy elem van a képernyőn, írd a parancssorba /H
  • Nyomj 2X entert
  • A debugger pont az IF elágazásokon áll meg, ami megmondja milyen módba menjen. Itt a CODE változó tartalmát írd át EDIT -re
  • F8 és máris editorként működök a táblanézegetőd
  • Ne felejtsd menteni

Hogyan is kerülnek az ERP illetve akár a több rendszerrel összekötött CRM-be az adatok. Ehhez úgynevezett Site Subscription Listekre kell feliratkoznunk. Ez mondja meg, hogy honnan és melyik adapter segítségével fogadjon a CRM adatokat. Ez a TX:SMOEAC -ban történik. A project keretében az értékesítési szenárióhoz a következők elegendők is lesznek.

  • All Business Partners (MESG)
  • All Business Partner Relationships (MESG)
  • All Business Transactions (MESG)
  • All Business Partners Hierarchies (MESG)

Ebből látszik is, hogy a Business Partnerek vagy ERPs kifejezéssel a Customer-ek kellenek, valamint a tranzakciós adatok, mint pl Sales Orderek melyeket ezentúl a CRM-ben fognak kezelni.

A technikai előkészületek második része a megfelelő customizing adatok replikálása. Ezek lehetnek pl az adózási beállítások, az ERP sales area data ami megmondja milyen Sales Organization, Division, Distribution Channel adatokkal dolgoznak. Ez azért fontos, mert lesznek olyan tranzakciók, jelen pillanatban Order-ek vagy az Accountok, amik visszafelé is frissülnek az ERPben így nyilvántartásuk nélkülözhetetlen.

A CRM-ben minden replikációs folyamat a middleware komponensen keresztül zajlik. Vannak úgynevezett Download Objektumok. Ezeket az R3AC1 tranzakcióban megnézhetjük. Itt látható, hogy melyik ERP táblát tölti le milyen funkciós modul segítségével. A megoldás azért nagyszerű, mert ezt is módosíthatjuk. Első körben a tábla különböző mezőire tehetünk filtereket pl, ha nem kell minden Material, csak mondjuk a 90000-99999-ig, akkor ezt rátesszük filterként.
Ha ennél tovább kell menni és például a tábla már bővítve lett a túloldalon újabb mezőkkel akkor a letöltést végző funkciós modult módisíthatjuk hogy vegye azokat is figyelembe.


Replikációs objektumok szűrői

Mikor minden letölteni kívánt objektumunk megvan, akkor beütemezzük őket az Tx:R3AS-ben. A letöltés adatmennyiségtől függően sokáig tart. A teljes kétségbeesés és reménytelen várakozás elkerülését könnyítik meg olyan adminisztrációs tranzakciók mint az

  • R3AM1 - mely objektumok töltődnek és hány blokk jött már át
  • SMQ1 és SMQ2 - megmutatják az in/outbound queue-k állapotát
  • SMW01 - middleware monitor a BDOC messgaék megtekintéséhez

Érdemes ezeket figyelni, főleg ha már ez ideje semmi nem történi az R3AM1-ben, nem jönnek az újabb adat blokkok akkor bizony valami valahol dugulást okozott, amit illik megszűntetni.

Tranzakciók Típusok és beállításaik

A CRM rendszer üzleti tranzakciói annyiban különböznek az ERP-ben megszokottaktól, hogy itt egy központi tranzakción, a Tx: CRMD_ORDER-en, belül indítjuk az üzleti események rögzítését, úgymint pl. Activity-k, Lead-ek, Opportunity-k, Sales Order-ek, Task-ok…stb. Ezek adminisztrálása egy helyen történik az SPRO-ban a tranzakció beállítások alatt. Sztenderdként is kapunk minden folyamathoz egy alapot, amit felhasználunk a végleges folyamatok kialakításához. Egy CRM tranzakciónak megadható nagyon sok jellemző, a legfontosabbak és egyben leglátványosabbak a következők.


Tranzakció típusok fej adatai

Organization Data Profile: meghatározza, hogy milyen stratégia szerint ajánljon fel és próbáljon kiválasztani Sales Area Data-t a tranzakcióinkhoz. Ez mint már taglaltuk azért szükséges mert a tranzakciók nagyrész az ERP-be is replikálódik ahol ez egy kapocs valamint a jogosultásgok is ezekre az adatokra épülnek a tranzakciókban. Ki, milyen Sales Organization-Distribution Channel-Division-Sales Group-Sales Office alatt készített dokumentumokhoz bír különböző jogosultságokkal.

Partner Determination Procedure: megmondja, hogy egy tranzakcióban milyen üzleti partnereket lehet és kell kiválasztani. Meyikből mennyit lehet minimum és maximum megadni. Ezek a tranzakció résztvevők lehetnek pl Ship-to-Party, Sold-to-Party, Bill-to-Party, Sales Representative, Projec Manager, Contact Person, Service Assistant… Különböző funkciós modulok segítségével olyan kényelmi funkciókat definiálhatunk ami ezeket felajánlja a Business Partner és a dokumentumban már meglévő adatok alapján. Beállítható hogy a partnereknek milyen értesítést küldjön, pl kalendárium karbantartás, foglalásokat illeszt be nekik, ha részt vevői egy eseménynek. Persze ennél még sokkal mélyebb részletekbe is leáshatunk.

Action Profile: olyan funkciókat vált ki melyeket bizonyos eseményekhez köthetünk. Pl, nyomtasd ki a dokumentumot automatikusan mentéskor, ha a Sales Representative. Vagy küldj egy felszólítást a Sold-to-Party -ban megadott személynek, ha 30 napon belül lejár az ajánlat érvényessége. Ezek a tipikusan nyomtatási és e-mail-ezési funkciók a SMARTFORM technológián alapulnak. A SMARTFORM egy olyan PDF kimenet aminek a elrendezését, tördelést, megjelenését megszerkesztjük, majd változókat helyezünk el amit futásidőben behelyettesít a tranzakciókból vett értékkel.

Date Profile: meghatározza hogy egy dokumentumban mik a kötelezően megadandó dátumok és milyen szabály szerint kell kitülteni őket.

Text Determination Procedure: tartalmazza egy tranzakcióban kitölthető szöveges blokkok definícióit. Ez sokszor Note néven jelenik meg. Megadható pl hogy egy Quotation-höz legyen 3 féle note, Ajánlat erősségei, Ajánlat gyenge pontjai, Versenytársak elemzése. Ezeknek akár egy sablont is megadhatunk, ami tartalmaz néhány alapgondolatot, ami mentén elkezdjék értékesítőink további gondolataikat papírra vetését, vagyis bitekbe.

Azt a következő képen láthatjuk hogyan jelenik meg egy CRM tranzakció. Ügyeltek rá a fejlesztők hogy mindenütt egységes felületet kapjanak a felhasználók, átlátható legyen és könnyen kezelhető, technikai zsargontól mentes. Ezzel is növelve az elfogadást.

A képen látható mindaz, amiről eddig beszéltünk. A tranzakció neve, az ügyfél, időpontok, a kontakt személyek és egy gyors szöveges összegzés. Valamint az alján azok az u.n. Actionok aminek segitségével kinyomtathatjuk vagy a résztvevőknek e-mail-ben elküldhetjük.

Mindezen adatok kitöltéséhez csak az ügyfelet kellet megadni ami alapján kiválasztotta a kontaktokat, a Sales Representative-ot, felhozta a megfelelő szövegsablont és kitöltötte a sales area data adatokat. Így még néhány időpont beadása után értékesítőnk tovább folytathatja napi teendőit, a rendszerben gyorsan lezárva adminisztrációs kötelezettségeit.


A Customer Visit tranzakció képernyője

A jelen projekthez 7 fő tranzakció készült

  • Task
  • E-Mail
  • Opportunity
  • Customer Visit Report
  • Customer Satisfaction Report
  • Quotation
  • Sales Order

Ezeknek a neve is elárulja mire valók, de annyival még kiegészíteném hogy a Task egy felhasználóhoz rendelhető feladat ami megjelenik neki, esedékessége van és nyugtázhatja ha befejezte. Az E-Mail egy egyszerű e-mail azzal hogy itt egy Account-hoz köthető mert CRM fogalomkörben ez is egy tevékenység az ügyfelünkkel kapcsolatban. Az Opportunity a teljes értékesítési folyamatokon átívelő tranzakció tartalmaz egy hosszú értékesítési folyamat alatt felmerülő minden információt a partnerről, termékről, határidőkről. A Customer Visit és Satisfaction tulajdonképp két activity, itt egyedi kérésre alakítottuk ki az ügyfél látogatás esemény rögzítésére és egy termékkel kapcsolatos elégedettség és annak okainak rögzítésére. Ezek mind átestek a fent bemutatott testre szabási folyamaton, ahol beállításra kerültek, hogy hogyan viselkedjenek, milyen adatokat gyűjtsenek és ajánljanak fel automatikusan ezzel is minél gyorsabbá téve használatukat.

Köszönöm a figyelmet, és várok mindenkit az V. nagyon izgalmas, befejező epizódra. Ami bemutatja, mit kell tenni egy rendszer éles indításához. Elöljáróban annyit, hogy többet mint amikor egy programot telepítesz és elkezded használni.

A szerző, Simon Károly, CRM területen jártas tanácsadó, 2005 óta foglalkozik SAP-val.
CRM tanácsadóként a főbb területei: Marketing, Sales, Middleware, WebClient UI, ERP-CRM integráció és bázis adminisztráció + ABAP.
Az SAP Hungary Kft. tanácsadójaként résztvett hazai és nemzetközi CRM bevezetéseken, főként Ny. Európában és Magyarországon.

További cikkek a szerzőtől


Téma megvitatása (2 hozzászólás)
SAP CRM 5.2 bevezetése IV. rész - Konfigurálás
2008. Április 04. péntek, 13:49
** Ebben a témában a következő cikket vitatjuk meg: SAP CRM 5.2 bevezetése IV. rész - Konfigurálás **

Most értem a cikksorozat végére. Nagyon jó és színvonalas munka! Csak így tovább!
Vá: SAP CRM 5.2 bevezetése IV. rész - Konfigurálás
2008. Április 08. kedd, 15:55
Szia Zoltán!

Köszönöm az elismerő szavakat.

Most jön ki az utolsó befelyező rész, ami azt meséli el mi kell mielőtt egy rendszerrel élesbe lehet menni. (Go-live check). Igazi technikai csemege, ajánlom minden vérbeli IT-snak.

üdv,
Karcsi

A téma megvitatása a fórumon. (2 hozzászólás)