Mapiranje polja crm sistema jedan je od onih zadataka koji izgledaju jednostavno na papiru — dok ne sedete da ga zaista odradite. Kompanija koja je u svom starom CRM-u imala 340 prilagođenih polja, od kojih su neka nastala pre sedam godina i niko više ne zna čemu su služila, dobar je primer koliko brzo ovaj proces može postati haos. Srećom, postoji metodologija koja to drži pod kontrolom, i o njoj ćemo govoriti konkretno, korak po korak.
Šta je zapravo mapiranje polja i zašto je kritično
Pre svega, terminologija. Mapiranje polja crm podrazumeva definisanje tačnog odnosa između svakog polja u izvornom sistemu i odgovarajućeg polja u ciljnom sistemu. Izvor je stari CRM koji napuštate, cilj je novi u koji prelazite.
Zvuči mehanički. Ali greška u ovoj fazi ne znači samo da ćete izgubiti par kontakata — znači da će vaš prodajni tim raditi sa pogrešnim podacima mesecima, a da neće ni znati. Zamislite situaciju u kojoj se polje "Status ugovora" iz starog sistema seli u polje "Napomena" u novom. Niko neće dobiti grešku. Podaci će biti tamo, samo na potpuno pogrešnom mestu.
Inventar pre svega: izvor i cilj polja
Počnite tako što ćete izvesti kompletan spisak svih polja iz starog CRM-a. Većina sistema ima opciju exporta šeme ili bar CSV exporta koji pokazuje nazive kolona. Ako nemate tu mogućnost, ručno prođite kroz svaki modul — kontakti, kompanije, poslovi, aktivnosti — i dokumentujte sve.
Za svako polje zabeležite:
- Naziv polja u izvornom sistemu
- Tip podatka (tekst, broj, datum, padajuća lista, višestruki izbor, logička vrednost)
- Da li je obavezno ili opciono
- Broj popunjenih zapisa (koliko redova zapravo ima vrednost u tom polju)
- Poslednji datum kad je polje uopšte korišćeno
Taj poslednji podatak je dragocen. Polje koje nije popunjeno u poslednjih 18 meseci gotovo sigurno ne treba da migrira. To odmah smanjuje obim posla.
Sablon mapiranja podataka crm — kako da ga strukturirate
Dobar sablon mapiranja podataka crm nije komplikovana stvar. Tabela u spreadsheet-u najčešće sasvim odgovara. Bitno je da svaki red ima sve informacije potrebne za migraciju, bez skakanja po dokumentima.
| Izvor — naziv polja | Izvor — tip | Cilj — naziv polja | Cilj — tip | Transformacija | Napomena |
|---|---|---|---|---|---|
| Ime | Tekst | FirstName | Tekst | Direktno kopiranje | — |
| Prezime | Tekst | LastName | Tekst | Direktno kopiranje | — |
| Status | Padajuća lista | deal_stage | Padajuća lista | Prevod vrednosti | Vidi tabelu vrednosti |
| Industrija | Višestruki izbor | industry | Jedan izbor | Uzeti prvu vrednost | Gubitak podataka — parkuj ostatak |
| Slobodan tekst — opis | Tekst | notes | Tekst | Direktno kopiranje | Max 2000 znakova u cilju |
| Godišnji prihod | Broj (EUR) | annual_revenue | Broj (USD) | Konverzija valute | Fiksovati kurs na dan migracije |
| Kreiran datum | Datum/vreme | created_at | Datum/vreme | Format ISO 8601 | Proveriti timezone razliku |
Ovo je primer — vaša tabela imaće stotine redova. Ali struktura ostaje ista.
Kako se rešavaju problematični slučajevi
Višestruki izbor u jedan izbor
To je možda najčešći problem u mapiranju migracije crm projekata. Stari sistem dozvoljava kontaktu da pripada u više industrija istovremeno — novi ima samo jednu. Šta radite?
Postoje tri pristupa. Prvi: uzimate prvu vrednost i gubite ostatak. Brzo, ali destruktivno. Drugi: spajate sve vrednosti u tekstualno polje kao rezervnu kopiju — "Prethodne industrije: SaaS, Finansije, Zdravstvo". Treći: preispitujete arhitekturu novog CRM-a i tražite da se kreira višestruki izbor gde je to moguće.
Preporučujem drugi pristup kombinovan s trećim. Nikad ne uništavajte podatke koji su prikupljani godinama, ali istovremeno prilagodite novi sistem gde je to izvodljivo.
Slobodan tekst u padajuću listu
Obrnuta situacija — stari sistem je imao slobodan tekst za "Tip klijenta", pa u bazi imate 47 različitih varijanti pisanja iste stvari: "b2b", "B2B", "Business to business", "firmski", "korporativno". Novi CRM ima čistu padajuću listu sa pet opcija.
Ovo zahteva ručnu normalizaciju pre migracije. Napravi mapiranje vrednosti: "b2b" → "B2B", "Business to business" → "B2B", itd. Obično je ovo posao od 2-3 sata za prosečnu bazu, ali vredan svake minute — jer ako to preskočite, završićete s 47 nestandardnih tagova u novom sistemu, tačno onako kako ste počeli.
Polja koja ne postoje u ciljnom sistemu
Prevod polja kontakta ne može uvek biti jedan-na-jedan. Ponekad stari CRM ima polja koja novi jednostavno nema. Ovde dolazimo do koncepta "parking lota" — privremenog mesta za smeštaj siročnih podataka.
Rešenje: kreirajte u novom CRM-u jedno prilagođeno tekstualno polje pod nazivom nešto poput "Migracija — Legacy podaci". U njega ulančajte sve vrednosti koje nisu našle odgovarajuće mesto, u formatu naziv_polja: vrednost | naziv_polja: vrednost. Ovo nije elegantno, ali podaci su sačuvani i pretraživi. Posle par meseci, kad tim potvrdi da te podatke niko nije tražio, možete to polje obrisati.
Polja koja ne treba nikad migrirati
Postoji kategorija polja gde je odluka laka: ne migrirati.
- Interna ID polja starog sistema (nema smisla van konteksta)
- Polja koja prate aktivnost specifičnu za stari UI (npr. "Poslednji login u stari CRM")
- Sistemska polja koja novi CRM automatski generiše (kreiran datum, modifikovan datum)
- Polja koja su popunjena u manje od 3% zapisa i nisu poslovno kritična
Pravilo: ako ne možete da objasnite u jednoj rečenici zašto tom polju treba biti u novom sistemu, verovatno ne treba.
Validacija: test pre finalnog uvoza
Pre nego što pustite punu migraciju, uradite test uvoz sa 50-100 zapisa. Ručno proverite 10 od njih red po red. Proverite:
- Da li su svi tipovi podataka ispravno konvertovani
- Da li su vrednosti padajućih lista sinhronizovane
- Da li su datumi u ispravnom vremenskom pojasu
- Da li su relacije između zapisa (kontakt → kompanija → posao) sačuvane
Greška otkrivena u testu košta sat vremena. Greška otkrivena posle migracije 15.000 zapisa može koštati nedeljama popravljanja.
Kada je mapiranje polja crm gotovo — i šta dolazi posle
Kompletan sablon mapiranja podataka crm treba da bude odobren od bar dve osobe: tehničke osobe koja razume strukturu podataka, i poslovne osobe (najčešće vodja prodaje ili customer success) koja razume šta koji podatak znači u praksi. Bez tog drugog potpisa, lako propustite nešto što tehničar ne bi prepoznao kao problem.
Posle uvoza sledi period "freeze" od 5-10 radnih dana: stari CRM ostaje dostupan samo za čitanje, tim radi u novom, a sve razlike koje izronu se beleže i ručno koriguju. To je jedini način da budete sigurni da nijedan podatak nije izgubljen u tranziciji.
Za dublji pregled alata koji podržavaju mapiranje migracije crm i nativne konektore između sistema, posetite stranicu CRM alata gde smo analizirali opcije za različite veličine timova.
Koliko vremena zaista treba
Nema jedinstvenog odgovora, ali postoji gruba procena. Za bazu do 5.000 kontakata i do 50 prilagođenih polja, iskusni tim može završiti kompletno mapiranje i test uvoz za 3-5 radnih dana. Za složenije baze — 50.000+ zapisa, više objekata, nasleđeni podaci iz više izvora — realno je planirati 3-4 sedmice samo za ovu fazu, pre nego što krenete u produkcioni uvoz.
Nemojte potcenjivati ovaj deo. Loše mapiranje polja crm je najčešći razlog zašto migracija "tehnički uspe" ali tim ostane nezadovoljan novim sistemom. Podaci su tamo, ali su neupotrebljivi, nepouzdani ili nepotpuni. A onda počne tiha frustracija koja potkopava svaku adopciju novog alata.
Da li vaš tim ima dokumentovan sablon mapiranja podataka ili svaki put krećete od nule? Ako je odgovor drugi — vreme je da to promenite pre sledeće migracije.
Komentari (0)
Budite prvi koji komentariše.