A Salesforce-adatmigráció az egyik legnagyobb kihívást jelentő projekt, amely a forrásadatok méretétől, formátumától és pontosságától függően változhat. Az adatmigráció az adatok egyik rendszerből a másikba történő átvitelének folyamata, azonban a tényleges átvitel előtti munka a legösszetettebb feladat.
Szakemberek hosszasan vizsgálták, hogy hogyan lehet sikeres az adatmigráció. A munka három fázisát be kell tartani: előkészítés, migráció és minőségbiztosítás (UAT).
Legyen a hangsúly az előkészítésen - a legkritikusabb fázison!
David Masri „Developing Data Migrations and Integrations with Salesforce: Patterns and Best Practices” című könyve megnevezi a sikeres adatmigráció hat jellemzőjét - a legjobb gyakorlatok mögött álló "miérteket". A másik öt attribútum hiánya enyhíthető ugyan az előkészítéssel, de egy elhibázott terven semmi sem segít - vagy ami még rosszabb, a terv hiányán.
Hogyan néz ki tehát a jó tervezés?
Az áttérési tervnek úgy kell kinéznie, mint egy hagyományos projekttervnek, idővonalakkal, függőségekkel és mérföldkövekkel.
Legyen a projektmenedzser (PM) a barátunk és szövetségesünk egyben - dolgozzunk együtt a terv elkészítésén! A Salesforce szakértő mellett a PM pedig gondoskodik majd az előrehaladás nyomon követéséről az áttérés megkezdésekor.
Egy adott objektum migrációjának kódolását el lehet kezdeni, ha:
A minőségbiztosítási (QA) és a felhasználó-elfogadási tesztelés (UAT), valamint a éles rendszerben történő (production) migrációs futtatások esetében ügyeljünk arra, hogy a dátumok olyan napokra essenek, amikor a feladatok futtatására elég időt tudunk szánni.
Ezeket a kérdéseket tegyük fel a tervezésnél, és ne felejtsük el majd megvitatni a projektcsapattal is:
Jelöljük ki az áttelepítendő adatokat és az adatok hiteles információforrását.
A Salesforce-ban felépített folyamatok befolyásolják a kiválasztást. A Salesforce-ba migrálandó adatok elemzése során rájöhetünk arra is, hogy további objektumokat és folyamatokat kell kreálni. Az adatmigráció ezért "tyúk és tojás" esetévé válhat.
Az információforrás jellemzően a backend - ahol az ügyféltranzakciókat tárolják. Azonban nem minden üzleti adat backend! Például az értékesítési folyamat során a kommunikáció történhet telefonon, e-mailen stb. keresztül.
Koncentráljunk annak beazonosítására, hogy mely adatokat melyik csapat gyűjti, és mi az, amit releváns a Salesforce-ban tárolni, pl. értékesítés, ügyfélszolgálat, marketing, pénzügy.
Valószínű, hogy több adatforrással fogunk rendelkezni (azaz különböző adatkategóriákhoz különböző információforrásokkal). Vázoljuk fel, hogy mely adatokat kell migrálni, és honnan kell kivonni azokat:
Biztosítsuk, hogy minden egyes forrásrendszer minden rekordja egyedi azonosítóval (ID) rendelkezik.
Ha az egyik forrásrendszer valamelyik adatkategóriája kapcsolódik egy másik rendszer egy másik adatpontjához, akkor a kapcsolódó adatpont azonosítója szükséges. Ha például a backend ügyféladatok migrálását tervezzük, és a korábbi CRM rendszerből múltbeli szerződéses adatokat is importálunk, akkor minden szerződéses rekordnak rendelkeznie kell ügyfél-azonosítóval (a backend rendszerből).
Minél különbözőbbek a Salesforce-adatmodell adatszerkezetei a forrásrendszerekben, annál összetettebb lesz az adatok leképezési folyamata.
Fontos kérdések, amelyeket fel kell tenni a folyamat során:
Ha nem állnak rendelkezésre azonosítók, akkor adattisztítást kell végezni. Távolítsuk el a duplikációkat és az elavult számlákat az adatállományból. Itt a felhasználók segítségére lesz szükség, mivel a hiányzó azonosítókat nekik kell tudni kitölteni, és meg kell adniuk, hogy milyen adatokat szeretnének megtartani. Határozzuk meg, hogy ki a felelős, mikor és milyen rendszerben fogja elvégezni a tisztítást.
Az adatoknak a forrásrendszer(ek)ből a Salesforce-rendszerbe történő átvezetésére választott módszer a következőktől függ:
Miután az adatok átkerültek a Salesforce-ba, meg kell győződni arról, hogy minden adat helyesen, azaz a megfelelő formátumban került át, és hogy a kapcsolatok pontosan tükröződnek a Salesforce-ban.
A QA, az UAT és a migrációs futtatások esetében ügyeljen arra, hogy a dátumok olyan napokra essenek, amikor a feladatok futtatására elég időt tudunk szánni. Az UAT-tesztelők gyakran a napi munkájuk mellett UAT-t is végeznek. Nem várhatjuk el tőlük, hogy két héten keresztül minden nap napi négy órát töltsenek teszteléssel. Ismerjük meg az időbeosztásukat, és győződjünk meg arról, hogy elkötelezettek-e a feladat iránt.
Kérjük meg a felhasználókat, hogy az UAT során vizsgálják meg az eredeti üzleti célokat. Gyakori, hogy a kód (beleértve az adatmigrációkat is) megfelel a specifikált követelményeknek, de az üzleti szempontból félreértés..
Ha a tesztek nem sikeresek, derítsük ki, hogy melyik fázisba csúszott hiba. Ha a hibák az előkészítési fázisból erednek, akkor az egész folyamatot ismételni kell. A hibák kijavítása sajnos időigényes folyamat. Ha egyszer már naplózták, valószínűleg megbeszélést kell tartani, hogy megerősítést nyerjen, hogy a probléma valós, és mi a teendő vele kapcsolatban. Ezért úgy időzítsünk, hogy a felhasználóknak elegendő idő álljon rendelkezésre az alapos teszteléshez.