Egy ismerősöm mondta egyszer:

…nem kell oda rendszer – van nyolc programozóm, bármit lefejlesztenek!

Tényleg? Illetve miért vezessünk be drága CRM rendszert, amikor egy kis alkalmazásfejlesztés jó és stabilabb alternatívának tűnik?

A választ érdekes módon nem is az IT területén kell keresni.

Általában, ha CRM rendszerről beszélünk egy átfogóbb problémakört (klasszikusan sales, marketing, service) lefedő megoldást gondolunk alatta. Ezekben a rendszerekben mindig van valami központi szervezőelv, ami köré az egész alkalmazáslogika csoportosul – és néha ezeket a szervezőelveket évtizedeken, sok sikeres és sikertelen projekt tapasztalatain, rengeteg felhasználói igényen okulva finomítja a gyártó. Az első CRM rendszerek egyike, ha jól emlékszem, az Act! őse volt, és az 1970-es évek végére datálódik.

Egy egyedi CRM rendszer fejlesztése alkalmazásfejlesztési projekt keretében is „hybris” – vagyis „szembeszállás az isteni akarattal”. Kevés helyen lehet együtt ugyanis az a tudás, amit egy ilyen rendszer kialakítása igényelhet, ráadásul óriási a beruházási költsége is, a kimenetelről nem is beszélve.

Vannak azért olyan esetek, amikor egyedi alkalmazás keretei közt hatékonyabb megoldást tudunk elérni, mintha egy egész rendszert vásárolnánk, de többnyire ekkor is valamilyen ERP rendszer és a mögötte már meglévő és jól működő folyamatok támogatják az egyedi alkalmazást. Az pedig leginkább az adatgyűjtést oldja meg, vagy valamilyen egyszerűbb, időben állandó folyamatot fed le, a befolyó információk pedig a háttérrendszer folyamatai révén eredményezik mindazt a hasznot, amit egy CRM rendszertől várunk.

Ha egy egyedi megoldás költségei alatta maradnak egy CRM bevezetésnek, biztosan ez lesz a nyerő, de számolni kell a hosszú távú hátrányokkal:

  • az egyedi megoldás továbbfejlesztése várhatólag többe fog kerülni
  • nem biztos, hogy tovább lehet fejleszteni
  • technológiailag elavultan a vevő „nyakán marad”, és inkább gátolja, mint segíti az üzletmenet fejlődését
  • drága lehet, vagy egyáltalán nincs terméktámogatás
  • ha háttérrendszerhez illesztettük, akkor az illesztések nem biztos, hogy kiállják az idő próbáját vagy más szoftverfrissítéseket

A kérdésre, hogy miért inkább neves gyártók gyakran drágának tűnő termékeit érdemes inkább alkalmazni, a válasz inkább a mikrogazdasági folyamatokban keresendő. Egy adott cég adott terméke, vagy szolgáltatása, annak viselkedése a piacon, a piac egyéb szereplőinek viselkedése, a piac elemeinek egymásra gyakorolt hatásai annyira összetett kölcsönhatások szövevényét alkotják, hogy egy hosszú távon működőképes értékesítési, kiszolgálási, támogatási – (tehát CRM) folyamattal aligha lehet lefedni őket.

Akkor hát a CRM rendszerben lévő folyamatok rövid távra szólnak? Szerintem igen (vagyis így kellene lennie), és csak ha megfelelően egyszerűek, akkor lesz képes egy adott cég a rendszer folyamatainak felhasználásával/átalakításával a szükséges piaci kihívásokra időben reagálni.

Ha alkalmazást fejlesztünk a célproblémára, az bizonyos időkeretek közt jól működhet (ezek a keretek többnyire időben vagy funkcionalitásban erősen korlátozottak), de a legtöbbször nem lesz képes arra, hogy megfelelően kövesse a felhasználói igények változásait egy megváltozott piaci helyzetben.

A rugalmasság, dinamikus kiterjeszthetőség az, amiben a CRM rendszerek fő ereje rejlik, (egyben ez a veszélyük is). De milyen egyéb hozzáadott érték van a CRM termékekben?

Nem régi keletű az a felismerés, hogy az ERP (és szerencsére ma már a CRM) rendszerekben működő folyamatok nem fedhetők le rögzített munkafolyamatokkal, nem csupán adat-, vagy entitás-modellben kell, hogy megállják a helyüket.

A CRM rendszer folyamataiban résztvevő üzleti elemek (business component, entity, stb) hasonlóan viselkednek, mint a számítógép operációs rendszerében a processzek: dinamikusan hatnak-, várakoznak egymásra, függenek egymástól, kivételeket generálnak – amiket kezelni kell, adatokat adnak át, különféle állapotaik vannak az egyes állapotokhoz különféle változó jellegű paraméterek tartoznak, stb. (lásd Howard Smith and Peter Fingar: Workflow is just a Pi process (PDF))

Ezeket a folyamatokat modellezni lehet, és persze kell is – erre alakították ki a BPML (Business Process Modelling Language) nyelvet, amely már számos piacon is beszerezhető eszköz működésének alapja. Az említett modellezőeszközök működése komoly matematikai modelleken is alapul – ezt fejlesztőként nem biztos, hogy magunktól ki tudjuk találni.

A korszerű CRM rendszerek folyamatait is ilyen eszközökkel tervezik, illetve nagy szoftvergyártók óriási pénzeket fektetnek magának a BPM-nek és a modellezőeszközöknek a tökéletesítésébe.
A Microsoft, SAP, Oracle jeleskedik leginkább nemcsak a felhasználásban, hanem a BPM alapú tervezőeszközök beépítésében és innovációjában is. Ilyen BPM tervezőeszköz található a Navision-ben – ahol üzleti folyamatot modellezhetünk vele (valóban), vagy a BizTalk Serverben is – ahol emberi munkafolyamatot; illetve ha a BPM érdekel valakit, elég jó ingyenes eszközök is vannak (pl. az Eclipse plugin). A valóban komoly termékekért azonban biztosan fizetnünk kell.

Milyen következtetések vonhatók le a fentiekből?

  • Sokkal inkább megéri neves – „brand” gyártók CRM rendszereit alkalmazni, ha tisztázni tudjuk a célokat, mert valószínűleg nem, vagy sokkal több munkával tudunk olyan hatékony folyamat-összefüggéseket leképezni
  • A CRM rendszerek folyamatai rugalmasabbak, gyakran a vevői kompetencia kialakulásával házon belül karbantarthatók lesznek
  • Megéri a CRM rendszerben lévő folyamatokat is megismerni, mielőtt vevőként bármit testreszabnánk, mert azokat piaci összefüggéseknek megfelelően tervezik
  • Ha lehet, minél kevesebbet torzítsunk a rendszer alapértelmezett folyamatain, és próbáljuk a meglévőket hasznunkra fordítani – ez kevesebbe is kerül majd
  • Ha speciális igényünk van, hatékonyabb lehet egy iparági CRM alkalmazás

Bátran szabjunk testre, de legyünk nagyon fegyelmezettek az igények és erőforrások felhasználása tekintetében