Prim Hírek

"Valójában az ügyfél köré csoportosított fogalmak és eszközök alkotják az adattárházra épülő analitikus CRM-et" � mondja Medgyesi Csaba a KPMG Consultingtól. "Tulajdonképpen a stratégiának, illetve az azt lebontva meghatározott céloknak megfelelő ügyféladatgyűjtést, az adatok tárolását és megfelelő szegmentációját, elemzéseit segítő alkalmazás- és eszközrendszerről van szó. De része az ügyfelekkel kapcsolatos döntéshozást támogató riportolási és megjelenítési funkció, valamint az ezek mögött megbúvó know-how is. Végeredményként elmondható, hogy az analitikus CRM-et implementálóknak � ha a működtetéssel is boldogulnak � megbízható tudásuk lesz minden ügyfelükről minden őket érdeklő kérdésben." Az analitikus CRM-rendszerek három jól elkülöníthető, üzleti, matematikai és adatréteggel rendelkeznek � mondja a DSS-től Lakatos Péter. Ebből adódóan megítélésükkor két szempontot célszerű figyelembe venni: egyrészt hogy pontosságában és funkcionalitásában mennyire illeszkedik az adott üzleti kérdésekhez a rendszer magját jelentő matematikai modell, másrészt hogy a rendszer milyen mértékben képes ez utóbbi bonyolultságát elrejteni a felhasználók elől.

Egy kis eszközmustra

Az analitikus CRM alapeleméül szolgáló adattárház-építésnek egy időtálló, idősoros adatmodellen kell alapulnia, amire a tranzakciós rendszerek adatmodelljei nem alkalmasak. Az adattárházakba való értelmes adatbetöltéshez azokon jelentős transzformációt és aggregációt kell végrehajtani. "A kis változtatással vállalati csomagként installálható operatív CRM-mel szemben az analitikus CRM-nél jóval kevesebb az előre definiálható, készen hozható elem, így inkább alapelemekről beszélünk. Az ezekre építhető elemzések cégenként különböznek. Ha mégsem, vagyis ha nem testre szabottak, nő a megtérülés kockázata" � mondja Bálizs Árpád a DSS Consultingtól.

Az adattárház több módon analizálható. A standard kérdések az installálás után azonnal működőképes megoldásokkal is megválaszolhatók. A termékkel, szolgáltatással, ügyféllel kapcsolatos, menet közben felvetődő "furcsább" kérdésekhez már "szerszámos ládára", adatbányász eszközre is szükség lehet.

Az ügyfélelemzésen túl minden üzleti analízisnek az idősoros információkból történő aggregátumképezés a lényege, vagyis az adathalmazban a jövőre vonatkozó következtetésekre alkalmas minták felkutatása � mondja Bálizs Árpád. Így hozhatók létre a múltbeli információkból a jövőre vonatkozó, a közép- és felső vezetők döntéseihez szükséges predikciók. A projekt sorsa az üzleti és a matematikai réteg közötti kommunikáción dől el � folytatja Lakatos Péter. A két réteg érintkezésénél fellépő fordítási problémák legcélszerűbb megoldásának az tekinthető, ha az üzleti felhasználók maguk értelmezhetik az eredményeket, illetve olyan eszközök állnak rendelkezésükre, amelyek segítenek kérdéseik matematikai interpretálásában. A valószínűségi háló alapú modellek például tipikusan ilyenek.

Úgy érzékelik a szállítók, az adatbányászat még nehezen megfogható a hazai felhasználók számára, nem látják a helyét, így kicsit tartanak tőle. Pedig a bankkártya-visszaéléseknél, de más előre nem ismert összefüggések felderítésekor is célravezetők a fenti eszközökkel végzett elemzések. "Az adott üzleti kérdést megválaszoló modell kiválasztásánál érdemes strukturálni a problémákat: osztályozásnál, például lojalitásvizsgálathoz vagy keresztértékesítéshez, a megfigyelt események alapján tanítjuk a modellt" � mondja Lakatos Péter. "Klaszterezéskor � ilyen az ügyfél-szegmentáció � nagyszámú, homogén tulajdonságú csoportot keresve nincs kulcsváltozó. Reprezentáció esetén az adatok közötti összefüggések után kutatva mindig a megfogalmazott kérdésekhez kell kiválasztani a megfelelő algoritmust."

Az adat mint nagyhatalom

"Az ügyfélközpontúság térhódításával eljött az egységes adatbázis-koncepció ideje, s vele a kérdés, mire használjuk az így összegyűlt adatokat. A választ erre � ahhoz, hogy adattárház-építésnél abban a jövőbeli fejlesztéseknek is helyet biztosíthassunk � különösen fontos ismerni. Idehaza azonban a vállalatok még az integrált vállalatirányítási rendszerek bevezetésével kezdődött egységesítéssel vannak elfoglalva" � fejezi be az eszmefuttatást Medgyesi Csaba. A hazai szervezeteknél meglévő adatok minőségüknél, mennyiségüknél vagy tartalmuknál fogva nem a célnak megfelelőek, sok esetben pedig egyszerűen csak rosszul gazdálkodunk velük. Például ha minden, addig füzetekben, cédulákon tárolt adat bekerülne a tranzakciós rendszerbe, analitikus CRM-et alkalmazva szinte mindennel tisztában lehetnénk, amit profitábilis ügyfeleink megtartása és igényeik kielégítése érdekében tennünk érdemes. Ez persze idilli állapot. A módszeres demográfiai adatgyűjtés tehát � deklarált CRM-től függetlenül � minden ügyfélkapcsolati ponton hasznos. Nyugaton és Amerikában már az életstílusadatok gyűjtésének kérdése is felmerült, de mert karbantartásuk gondot jelenthet, idehaza ma még nem erre koncentrálunk.

Segíthetné az adatgyűjtést a hitelkártya-használat és a törzsvevőkártyák terjedése is. Utóbbiak, egy analízisre alkalmas adattárházzal a hátuk mögött, árnyalhatnák � a vásárlási szokásokra támaszkodva � az ügyfélképet. Ugyanakkor a raktárkészletet, a rendelésállományt is optimalizálhatnák, a törzsvásárlókra kihegyezett marketingakciók pedig fokozhatnák a vevői lojalitást. Ez utóbbira már idehaza is van példa.

Adatforrások

Szükségesek és elégségesek-e az ERP- és/vagy operatív CRM-rendszerek az analitikus CRM működtetéséhez szükséges kritikus adatmennyiség előteremtéséhez? Mi volt előbb, a tyúk vagy a tojás � lehet-e, kell-e bevezetési sorrendet felállítani az említettek között? Hazai körökben eltérőek a vélemények, módszerek. Fajszi Bulcsú a KFKI Isys véleményét tolmácsolva nem tartja ügyfélközpontúnak az ERP-rendszerek adatkezelését, így szerinte � kivéve, ha az adattárház az operatív rendszerekből tölthető � nem ez a célravezető az ügyfélkezelés támogatásához. De, mint mondja, a tranzakciók CRM számára történő adattárházba szervezése és elemzése terén például a banki rendszerekben sok kihasználatlan tartalék van. Itt jó eredményekkel kecsegtet az operatív CRM-mel párhuzamos analitikus CRM. Így az ügyfélszolgálatos a képernyőre nézve egyaránt tisztában lehet az ügyfélértékkel és a keresztértékesítési potenciállal, az operatív CRM pedig az adatgyűjtést teszi strukturáltabbá az ügyfelek megismerésének folyamatában. Ehhez azonban a CRM kialakítását két fontos lépésnek kell megelőznie. Hierarchizálni kell a termékeket (hogy a vállalat minden területe számára ugyanazt jelentsék), és meg kell oldani a különböző szolgáltatásokat igénybe vevő, esetenként különböző szigetrendszerekben lévő ügyfelek azonosítását is. Az első problémára az ERP-rendszerek is választ jelenthetnek, de a KFKI Isysnek például egy kontrolling-adatpiac építése során kellett megoldania. Az ügyfél-azonosítás már veszélyesebb, mert bár napi operatív probléma, az általa okozott torzulásoknak még sok helyen nincs tudatában a vezetés. A megoldás lehet például az adattárház-építés során végzett adattisztítás, de a későbbi karbantartás már a vállalat feladata.

Az IFUA Horváth és Partnertől Tóth Miklós fenntartásokkal ugyan, de mégis az ERP-t (vagy más, adatokban bővelkedő tranzakció-kezelő alaprendszert) tartja kiindulási alapnak. "Az ERP-rendszerekkel azonban Magyarországon sajnos nem a teljes vállalat, csak annak részterületei, leggyakrabban a pénzügy és logisztika automatizációját oldották meg. Az ügyfélszolgálat, az értékesítés és a marketing területét támogató egységes informatikai megoldások bevezetése elmaradt, az ezeket helyettesítő szigetmegoldásokban, Excel-táblákban, illetve Accessben rögzített ügyféladatok viszont vállalati szinten nem egységesek."

Horváth Gábor az IBM-től is azt vallja, az operatív és analitikus CRM esetében nem lehet a bevezetés sorrendjét egyértelműen meghatározni. "Az elvégzett elemzések alapján körvonalazódhatnak például az operatív CRM előnyei, de az adatgyűjtés további módjának eldöntését a megtisztított tranzakciós adatokon első körben elvégzett elemzések segíthetik."

Az Oracle-nél nem válik élesen ketté az operációs és az analitikus CRM informatikai támogatása, így a mögöttük lévő tevékenység sem. "A széles, elsősorban lakossági ügyfélkörű vállalatok az analitikus CRM fogalmának felbukkanása előtt is elemezték ügyféladataikat � mondja az Oracle képviseletében Radnai Szabolcs �, s a levont következtetéseket visszaforgatták ügyfélkapcsolati tevékenységükbe. Az új megközelítést az operatív ügyfélkapcsolat támogatására kifejlődött piaci ágazat hívta életre, és az addigi marketing- és salesmunkát támogató rendszerek továbbfejlesztésével kialakultak az operatív CRM-rendszerek. Az újdonság annyi, hogy a mai analitikus CRM-ben a talált összefüggések hasznosítását már automatizmusok támogatják. Például egy marketingkampány során az elemzések eredményeként kapott ügyfeleknek automatikusan generálódnak az e-mailek.

"Az Oracle az operatív CRM fogalmát tartja újabb keletűnek � folytatja Radnai �, ugyanakkor a két, egymásra épülő megoldás integrációját is fontosnak tartva egy olyan automatikus keretrendszert alkotott, amellyel a kampányok összefogása, a költség/bevétel arányok áttekintése, a profitábilitás mérése egyaránt lehetővé válik. Példaként egy banki marketingmenedzser dilemmáját említhetem, akinek az ügyfélkör hatékony, eredményes megszólításához analitikus CRM-re van szüksége, míg saját munkatársai tevékenységét leginkább operatív CRM-mel tudná segíteni és kontrollálni."

Projektre éhezve

Adataik tartalmával és minőségével tudat alatt talán már tisztában vannak a hazai vállalatok, de a projekt erőforrásigényét már kevésbé ismerik, a vállalati elkötelezettség pedig ritka, mint a fehér holló. Ezért mielőtt belevágnának, fel kell mérni � jó érzésű szállító, tanácsadó ezt meg is teszi �, képes-e a szervezet a CRM-filozófia megértéséhez, majd az analitikus CRM felépítéséhez és eredményes működtetéséhez szükséges változásokon átmenni. Nem egyértelmű gyakorlat még, de szintén a szállító, illetve a tanácsadó kompetenciája, hogy a munka megkezdése előtt utánanézzen, és felkészüljön a várható, az adott iparág hasonló projektjeiben adódó problémákra, s azokra figyelmeztesse a potenciális ügyfeleket is.

Mintegy az analitikus CRM-projektek mottójaként idézzük az SAP Magyarország képviseletében Seres Jánostól hallottakat. "Ott lehetett könnyen ERP-t bevezetni, ahol papíralapon is megfelelő mederben folyt a vállalatirányítás. Hatékony ügyfélkapcsolat-kezelés, ügyfélcentrikus vállalatirányítás is csak ott képzelhető el, ahol a kollégákat mint "ügyfeleket" tekintve cégen belül ez már jól működik, illetve képesek a vállalati folyamatokat ebbe az irányba megszervezni. Vagyis komplex CRM-ről gondolkodni egy nagyvállalat esetében csak stratégia szintjén, legkevesebb 2-3 éves távlatban lehet. Persze a CRM egyes elemei ennél gyorsabban és egyszerűbben bevezethetők. Először is fontos tisztázni, mit akar elérni a cég. A vállalat egészét érintő stratégiai projektről lévén szó, már induláskor látni, majd a projekt kimenetele érdekében mihamarabb harmonizálni kell a témát érintő, a különböző funkcionális területek közötti ellenmondásokat. Az alkalmazás, illetve az eszközök kiválasztása csak a házon belüli üzleti igények konszolidálása után kezdődhet."

Még mindig az igényeknél maradva: azok leggyakrabban középszinten, elsősorban a marketing terén ébrednek, de stratégiai kérdésről lévén szó, a projektek csakis felső vezetői támogatással vihetők végig, s ez igaz a rendszerek működtetésére is. Célszerű egy � a stratégia felől elindulva a cég által bejárni kívánt utat végigkövető � megvalósíthatósági tanulmánnyal kezdeni. Megvizsgálva, van-e például deklarált ügyfélkör, preferált csatorna, meghatározhatók a működési folyamatok, a szükséges munkamegosztás, amit a meglévőkkel összevetve felvázolódnak az átalakítási igények is. A megoldás � a folyamatok irányából kínált javítási lehetőségként � lehet egy folyamat(át)szervezés, de az analitikus CRM kialakítását gátló informatikai hiányosságokat felfedve akár azok pótlása is.

Mivel ez esetben kicsit különbözik a technológia az ERP-knél vagy az Access-, illetve Excel-felületeknél megszokottól, felértékelődik a gyakorlati oldalra koncentráló demók, illetve pilotprojektek szerepe � véli Horváth Gábor az IBM-től. Az előkészítő fázisban időt kell szakítani a közös nyelv megteremtésére és a világos cél meghatározására.

Kenesei János (honnan is?) ezt úgy fogalmazza meg: ahol nem érzi a vezetés a végfelhasználók oktatásának és a rendszerhasználatba történő időbeni bevonásának fontosságát, ott nem szabad adattárház-építésbe kezdeni.

Dilemmák

"A CRM mint vezetési filozófia a vállalat versenystratégiájára vezethető vissza, de hogy egy adott stratégiából kiindulva az adott vállalati, piaci körülmények között melyik cég milyen eszközökhöz, megoldásokhoz folyamodik, az eseti és egyedi � mondja Tóth Miklós. Erősen eltérő szintű � tevékenység, cégméret stb. függvényében � a hazai vállalatok ügyfélkapcsolat-kezelése. Az egyes iparágak különböző, de egyre több és változatosabb kommunikációs csatornát használnak. Van, ahol már szinte teljesen háttérbe szorul a személyes kontaktus, míg máshol � elsősorban vidéken � még ma is ezt részesítik előnyben." S ha ehhez még hozzátesszük, hogy Magyarországon a téma szinte minden jelentősebb gyártójának kínálata jelen van, miközben felhasználói és forgalmazói oldalon egyaránt kevés a tapasztalat, úgy gondoljuk, a cégeknek nem könnyű dönteniük, és főként jól dönteniük. Néhány hasznos szempontra az alább megszólaló szállítók, tanácsadók is felhívták a figyelmet, de reményeink szerint a választást még inkább megkönnyíti az X. oldalon található táblázatunk.

Kezdjük talán a felhasználók preferenciáival. "Azoknál, akik meglévő informatikai rendszereikkel elégedettek, az alkalmazott technológiát támogató, de annak esetleges korlátjait kiküszöbölő rendszereket, eszközöket kell az üzleti problémára koncentrálva szemügyre venni" � mondja Seres János. "Ellenkező esetben új, az üzleti igények lefedéséhez is megfelelő technológia után kell nézni." Horváth Gábor a forrásrendszerek összetettségének és számosságának szem előtt tartását véli fontosnak. Szerinte nem túl komplex esetben egy célalkalmazás például gyors eredményhez vezethet. "A projekt elindításához mindenképpen kapaszkodót jelenthetnek a vállalatot foglalkoztató problémakör megoldására � például egy adatmodell formájában � kiindulási alapot kínáló termékek, s mivel nehezen elronthatók, gyorsabb bevezetéssel is kecsegtetnek. Ugyanakkor a probléma megoldását nem támogató modell végzetes lehet a projekt kimenetelére."

Szűcs István a Compaqtól két szempont szerint különbözteti meg a potenciális felhasználókat. A tájékozottabbak célzott kérdésekkel keresik problémájuk megoldására a többnyire testre szabást is igénylő eszközöket. Kiforratlan igény esetén viszont elsőként a gyorsabban kivitelezhető pilotprojektek segíthetnek, amelyeknél pontos elvárásdefiníció nélkül is bemutatható, mit kínál egy ilyen rendszer. A tapasztalat azt mutatja, hogy a pilotprojektből tanultak alapján a későbbiekben már konkrétabb és pontosabb igénymeghatározásra képesek a felhasználók. A standard, dobozos megoldások ugyan kisebb költségráfordítással járnak, de mert nem az egyes vállalatok egyedi szükségleteinek kielégítésére készültek, a lehetőségek nem aknázhatók ki megfelelő hatékonysággal, vagyis kisebb a várható haszon. A helyi igények alapján, egyedileg felépített rendszerek nagyobb költséget és több munkát jelentenek, de valóban jól definiált elvárások esetén gyorsabb megtérüléssel és nagyobb profittal kecsegtetnek.

"Választáskor vizsgálni kell, hogy mennyire támogatottak az alkalmazni kívánt területek folyamatai egy-egy megoldásban. Hogy közülük az elemzéseket vagy a tevékenységek bonyolítását támogatók alkalmasabbak-e az üzleti probléma megoldására, azt a felhasználónak kell eldönteni" � mondja Radnai Szabolcs az Oracle-től.

Az elemző- és adatbányászeszköz-kínálatról Lakatos Péter a DSS Consultingtól azt gondolja, hogy mivel a piacképesre sikeredett termékeket rövid időn belül csaknem minden gyártó � gyakran termékébe beépítve � plagizálja, az alkalmazáskínálat viszonylag homogén. Standardizálható, gyakran felmerülő üzleti kérdésekre (tipikusan ilyen a már említett ügyfél-szegmentáció, illetve a lojalitásbecslés) feladatspecifikus alkalmazást, vagyis analitikus CRM-modulokat célszerűbb létrehozni. A befektetés � mivel így pontosabban és hatékonyabban dolgozhatunk, mintha általános elemzőeszközzel végeznénk a vizsgálatsorozatot � középtávon megtérül.

Eszköz kontra alkalmazás

Később szót ejtünk a szállítók közötti véleménykülönbségről, de a legmarkánsabbat, az eszköz és/vagy alkalmazás kérdését itt, a termékválasztás kapcsán érdemes megemlíteni. Többségük az adattárházat tekinti az analitikus CRM technológiai alapjának. Az ebben megvalósított modelleket illetően, vagy hogy azokon milyen eszközökkel, célalkalmazásokkal végzett műveletek szolgálják a kitűzött célt � elsősorban a forgalmazott termékpaletta függvényében � eltérnek a vélemények. Vannak, akik mindezt a célpiac szerint csoportosítják. A banki, biztosítási és telekommunikációs szektor számára dolgozó KFKI Isys például mindhárom területen egy technológiai alapvázra épít, így a munka jelentős hányada a felhasználó igényei alapján történő testre szabás. "A célalkalmazás-koncepció viszont például retail területen, ahol az egységes törzsvásárlói és kasszainformációk megfelelő alapot nyújtanak az ügyfélkapcsolatok kezeléséhez, eredményes lehet" � mondja Fajszi Bulcsú.

Bálizs Árpád a DSS-től úgy látja, a kész alkalmazásokhoz szokott hazai felhasználók nehezen barátkoznak meg a gondolattal, hogy igényeik testre szabott kielégítésére méretszabóságba, nem pedig az áruház konfekcióosztályára kell menniük. Pedig az ügyfélértékmodellben más-más, a CRM-modell tulajdonságait befolyásoló paramétereket kell a felhasználóknak kiválasztaniuk. Csak ezt követően ültethető a jól kialakított modellre valamelyik, ravasz matematikai módszerekkel ügyfélértéket számoló alkalmazás. Az elemzési munkához tehát az ügyfélnek kell az alapvető elemzési kritériumokat meghatároznia. Mivel a vállalati folyamatok bizonyos hányada funkciófüggetlen, illetve iparáganként azonos, az ERP-rendszerek működtetésére fel lehetett állítani modelleket, a CRM-nél azonban erre nincs mód � mondja Bálizs. Az eszköz�alkalmazás dilemmát a "mire akarom használni?" kérdésre adott válasz döntheti el. Ehhez egy előtanulmány során össze kell hasonlítani a vállalat stratégiai céljait azzal, amit egy analízis nyújtani tud.

A tanácsadóknál meglévő tudásmenedzsment segíthet a vállalati célokat a CRM vállalati képességeinek nyelvére lefordítani. Analitikus CRM-nél, ha céleszközt akarunk alkalmazni, meg kell nézni, hogy szűkíthető-e egy feladatra, valamint hogy milyen mértékben lokalizálható a vállalati igény � hangsúlyozza Kenesei. "Például ha már van egy jól működő adattárház, és kíváncsiak vagyunk a lemorzsolódásra, ez utóbbihoz céleszközre lesz szükség. Egy napról napra változó ügyféligényű, nagyon dinamikus piacon dolgozó vállalatnak azonban már biztosan más megoldás után kell néznie."

Fajszi Bulcsú nem eszközpárti. "Az eredményes CRM-hez nem termék, üzletág, költséghely vagy csatorna, hanem ügyfél szerint szervezett adattárházra alapozott, holisztikus ügyfélképre van szükség. Ehhez az adattárházra támaszkodó rendszeres riportok, a dinamikus OLAP-lekérdezések, valamint a rendszeres, adatbányászati mélységű elemzések nyújtanak segítséget."

Nem zárva ki az iparági modellek lehetőségét sem, elsősorban az eszközök mellett voksolt a HP-től Ujj Béla is. "Ha előáll egy konszolidált adatbázis, és felépül egy modell, még ha mások is a forrásrendszerek, pusztán technológia kérdése, hogy összeszedjük belőlük az adatokat. A lényeg az adatmodellezésen van, ami viszont Magyarországon is nagymértékben szállítófüggő. A termékbe beépült modelleket a felhasználónak úgy kell elfogadnia és megtanulnia, ahogy vannak, a gyakorlatát kell a modellhez igazítania. Más esetben a vállalat működését is megváltoztatva, de a felhasználó saját képére formáltan alakul ki a modell. A HP mindkét megoldás megvalósítására képes. A konkrét, jól megfogalmazott problémákra megoldást keresők valószínűleg a dobozos termékek mellett döntenek."

Kétféle megközelítés létezik � mondja Szűcs István. A régebbi felfogás szerint az adatgyűjtéstől, elemzéstől az igénybevétel lehetőségéig nagyon hosszú, köztes eredmények nélküli utat kell bejárni. Ma már azonban vannak gyorsabb hasznosítást ígérő megközelítések is, amelyek hatásaként azonnal kiértékelhetők az egyes lépések következményei, és így kisebb a projekt kockázata, gyorsabb a megtérülése.

Víziószinten nincs lényegi eltérés az egyes szállítók módszerei között. A HP például olyan � üzleti prekoncepción alapuló � modell készítésében gondolkodik, amelyben vevők és termékek szerint is fel lehet tenni a felhasználót érdeklő kérdéseket, s amelyre ráültethetők az felhasználók "önkiszolgálását" és például az azon alapuló marketingmunkát segítő automatizmusok.

Nem repül a sült galamb...

A beleölt milliók megtérüléséhez a rendszert működtetni kell, s ennek terhe többnyire az informatikusokra hárul. Jól megépítve 80 százalékban automatizált, de 20 százalékban olyan komplexitású lekérdezésekre vagy adatbányászatra van szükség, amit egy laikus felhasználó esetleg nem képes saját eszközzel elvégezni. A rendszertől automatikus végrehajtást igénylő elvárások � ilyen például az adatbetöltés, -feldolgozás és -tisztítás � megvalósítása Seres János szerint eset- és rendszer-, költsége pedig probléma- és eszközfüggő. Saját tapasztalatai alapján Lakatos Péter szerint adatbányászprojekteknél a megtérülés és a profit szempontjából kulcsfontosságú, hogy a vállalat a szoftvervásárláson és konzultáción túlmenően az eredmények üzleti folyamatokba való beépülésének is figyelmet szenteljen.

A CRM-alapfilozófia megfelelő, konzisztens vállalati adatvagyonra utal. Összetételét elsősorban az határozza meg, mire akarjuk � marketing vagy értékesítés támogatására, ügyfélmenedzsmentre stb. � használni. Az ellenőrizhetetlen, "döglött" adatoktól azonban mindenkor tartózkodni kell. "Forrásuk jelentősége csupán annyi � mondja Ujj Béla �, hogy az alkalmazott technológia képes legyen a különböző szerkezetű kinyert ügyféladatokat konszolidálni, s egy helyen látva idősorosan elemezni. Kisebb gond, ha ez nem teljesen online, mint ha a vevőkről, ügyfelekről � jövőbeli viselkedésük előrejelzésének alapjaként � nem minél szélesebb spektrumú elemzés készül."

Szükség van, legalább az alapműködés szintjén, egy informatikai architektúrára, ugyanis mocsaras talajra � ahogy Bálizs Árpád fogalmaz � nem érdemes palotát építeni. Bár tudjuk, alapvetően nem az informatikáról, hanem a stratégiát szolgáló vállalati működési módról van szó, a vállalati folyamatok CRM-filozófia szerinti átszervezése csupán szükséges, de nem elégséges feltétel. A megvalósításhoz az inkompatibilis, egymással nem kommunikáló rendszerek helyett a CRM-filozófiát befogadni képes informatikai környezet kell.

Egy analitikus CRM-projekt akkor sikeres � mondja az IBM Bricostore-nál szerzett tapasztalatai alapján Horváth Gábor �, ha átadás után a felhasználó képes működtetni a rendszert, s abból új ötleteket merítve egyre több információhoz jut. Ehhez azonban már induláskor a vállalat minden területén és szintjén konszenzusnak kell kialakulnia, hogy az IT- és az üzleti problémákat kezdettől együtt kezelhessék a résztvevők. "Ez utóbbi kritikus pont � figyelmeztet Horváth �, mert mindkét oldalon ritka a mindkettőben jártas szakember."

"Mivel általában sok, egymástól eltérő érdekeltségű szervezeti egység érintett, így várhatók érdeksérülések, konfliktushelyzetek, amelyeket csak egy felső vezető képes, jó esetben projektszponzorként, kezelni" � mondja Szűcs István is. A felhasználónak nem szabad már kezdetben az ügyfélkapcsolat teljes spektrumára lőnie, hiszen a sikerhez csak a célterületek kijelölésén és sorba állításán keresztül vezet az út. A rossz projektterjedelem már induláskor halálra ítéli a projektet. A másik véglet sem szerencsés, mert ha a vállalat különböző területein futó pilotprojektek túlságosan a helyi problémákra kihegyezettek, nehezen viszik előre az összvállalati érdeket tükröző stratégia megvalósulását."