Nemrég volt „szerencsém” részt venni egy projektben, ahol annak ellenére sem tartották be a legelemibb rendszerintegrációt érintő irányelveket, hogy már a legelső megbeszélésen felvetettük azokat, illetve megjelöltük, mely ponton válhat veszélyessé az integráció.

Mi lett az eredmény? Veszélyessé vált.

Nem akarok senkit áltatni: ha a tanácsadói oldalon állunk, és még egyeztetési fázisban vagyunk, és netán azt tapasztaljuk, hogy az ügyfelünk egyáltalán nem fogékony a rendszerintegrációt érintő javaslatainkra, akkor meneküljünk, mert ez tipikusan az a terület, ami igazán ki tud csúszni mindenki kezéből – beleértve az ügyfelet, az összes alvállalkozót, és ha tanácsadók vagyunk, minket is.

Lássuk csak, hol hibázhatunk.

Szükséges-e az integráció…

Ez mindig mérlegelési pont. Ha pl. az adatkeletkezés gyakorisága nem indokolja, és kézi bevitellel még megoldható a dolog – ez ugyan nem korszerű, de sok problémát előzhetünk meg vele, ha kihúzzuk a listáról. Az az interfész, amelyik nincs, azzal valószínűleg probléma sem lesz. Bár ezen a ponton az ügyfél fogja megmondani, mire tart igényt.

Az integráció mikéntje…

Megdöbbentő dolgot fogok leírni: nem csak online integráció van. Előfordulhat, hogy napi gyakorisággal, hetente, vagy ritkábban kell, hogy adat átkerüljön egyik rendszerből a másikba. Ilyenkor célszerű kötegelten, félig-meddig automatizáltan adatokat mozgatni. Ha olcsóbb, akkor akár az adminisztrátor hatáskörében.

A „másik” rendszer…

A saját rendszerünk szemszögéből minden rendszert idegennek kell tekintenünk. Ha integrációt kell megvalósítanunk, a legfontosabb a „bizalmatlansági alapelv” – vagyis mi magunk a saját rendszerünk határáig vagyunk kompetensek. Ne vállaljunk interfészfejlesztést, ami feltevéseken alapul, mert egy másik rendszer esetleg másik alvállalkozó hatásköre, és lehet, hogy semmi befolyásunk nincs sem rá, sem a másik rendszer folyamataira. Ha lehetséges, mindig valami közbülső eszközön keresztül adjunk át adatokat, ami elég egyszerű ahhoz, hogy ne legyen alkalmas EAI eszközként való használatra (pl. fájlrendszer); vagy pedig használjunk EAI eszközt valójában (az EAI rövidítés kifejtését ld. később).

Az elégséges feltétel…

Kevés kivételtől eltekintve egy CRM rendszer a legtöbb jóindulattal sem tekinthető kritikusnak. Amikor az ügyfélkiszolgálás egy cég fő profilja, akkor persze az lehet, de pl. értékesíteni azért lehet CRM nélkül is.

Egy projekt során a CRM rendszer szinte mindig használatba vehető működő interfészek nélkül is – tehát NEM feltétele az „éles indulásnak” az összes interfész és integráció kifogástalan működése.

A folyamatmodell…

Ha megfigyeljük, a CRM folyamataival kezdődik általában valami egy vállalat életében, vagy ott végződik. Például értékesítés támogatásakor itt keletkeznek az ügyféladatok, majd amikor már biztosan számlafizetővé válnak – kerülnek tovább valamilyen más rendszerbe – vagy ide kerülnek vissza számlafizetési információk, stb. De a CRM sohasem áll egy vállalat folyamatainak középpontjában, ennélfogva ne gondoljuk, hogy integrációs centrum lehet pusztán azért, mert rugalmasságával, vagy beépített integrációs eszközökkel van felvértezve. Már csak azért sem, mert a CRM rendszer működése jobb, ha nem feltétele más kritikus rendszerek működésének.

Az integrációs eszköz…

Amikor az integrációt tervezzük, valamilyen módon meg is kell valósítani a rendszerek közötti információátvitelt.

Ha nagyon komplex, sok rendszert érintő integráció kell, ahol az adatok bonyolult módon várakoznak, transzformálódnak, esetleg „multicast” formában több rendszer felé is irányulnak egy rendszerből – ott EAI (Enterprise Application Integration)–ra van szükség. Ez nem oldható meg pusztán interfészek fejlesztgetésével, hanem valamilyen céleszközt feltételez (BizTalk Server, TIBCO, MQ Series, stb.) Az ilyen integrációs eszköz alkalmas arra, hogy „csillag alakzatú” integrációt valósítsunk meg vele, ahol az integráció központjában maga az eszköz áll.

Ha sokkal kisebb mértékű feladatmegoldásra van szükségünk és nekünk kell interfészeket fejleszteni, akkor a következő irányelvek lehetnek fontosak:

  • pont-pont közti interfész megvalósítás

Kerüljük az integráció-integrációja megvalósításokat – ne akarjunk integrációs központot kialakítani (pl. adatbázisszerverből) és azzal integrálódni, mert nem fog sikerülni. Már csak azért sem, mert ez már alkalmazási szintű logikai megvalósítást is szokott igényelni. Ilyenkor az interfész működésének ürügyén meg kell erőszakolnunk az alkalmazáslogikát, hogy egy másik alkalmazásnak kedvezzünk. Ilyenkor rendszerint a „közös lónak túros a háta” effektus lép fel, és semelyik rendszer nem lesz kielégítő működésű. Tehát fókuszáljunk a célra: két pont közt mozogjon a lehető legkevesebb adat.

  • keresztirányok kizárása

Ha egy rendszerbe adatot kell vinnünk, vigyázzunk rá, nehogy az oda bekerülő adat visszirányú adatmozgást eredményezzen, és így vég nélküli adatvándorlás induljon meg a rendszerek közt. Egyféle adat (pl. kontaktok, cégek) lehetőleg csak egy rendszer felől érkezzenek. Ha lehet, minden típusú adatmozgásnál nevezzük meg a keletkezési / módosítási szempontból elsődleges rendszert.

  • tiszta adatintegrációra törekvés

Ha eldöntöttük, hogy mi írunk interfészt – amennyiben lehet, az interfészbe ne kerüljön alkalmazási logika, hanem csak adatok mozogjanak, esetleg adatok típuskonverziója megengedhető (és szükséges is). Minden más esetben arra kényszerülhetünk, hogy az amúgy drága EAI eszközt nekünk kell kifejleszteni, vagy nem tudunk elég rugalmas megoldást adni, ami hosszú távon veszélyeztetheti a CRM rugalmasságát (is).

  • feltételezett működés

Ha lehet, interfész működése ne legyen feltétele üzleti folyamat sikerességének egyik rendszerben sem. Ha véletlenül valami nem megy, akkor kritikus rendszerek eshetnek ki a működésből. Gondoljuk meg: nem tudunk számlát sztornózni, mert nem megy „AZ interfész” ?

A tervezés…

Végül és nem utolsósorban – ez a legfontosabb. A tervezés alapvetően befolyásolja a projekt sikerét, mivel az integráció akár módosíthatja az alkalmazás logikáját is. Erre gondolni kell már a projekt kezdetén, ami azért nehéz, mert ilyenkor még sok a homályos folt…

…mert az a legjobb, ha a kivitelezés külön projekt.

Az elégséges feltétel pontban leírtak miatt is, de azért is, mert az integráció általában több rendszert érint, amelynek több gazdája, bevezetője szokott lenni, és ezért legjobb, ha az ügyfél koordinálja. Az biztos, hogy az ügyféloldali projektkultúra, fegyelmezettség is alapjaiban befolyásolja a sikerességet.

Nagyon veszélyes dolog másik projektbe belepréselni még egy integrációs projektet is, hiszen az igények gyakran projekt közben is változnak – így meg aztán hatványozottan változni is fognak.

És végül…

Nem az integráció miatt van szükség informatikai rendszerekre. Igazán nagy (de kicsi és közepes) projekteken is el szokott felejtődni a dolog, és egy óriási integráció marad a rendszerek helyén, amelyek akár jól is működhetnének…

Ésszel integráljunk, és egyszerűsítsünk a végtelenségig