Pereiti prie turinio
Visos įžvalgos

DMS diegimas

DMS migracija ir diegimas: pilotas, duomenys, perėjimas ir stabilizavimas

Saugi migracija yra valdoma verslo transformacija, turinti pakartojamus duomenų įrodymus, išbandytas išimtis ir aiškų grįžimo kelią, jei neįvykdomi perėjimo kriterijai.

Trumpas atsakymas: Prieš projektuodami tikslinę būseną profiliuokite duomenis, apibrėžkite atsakomybę ir priėmimą, sukonfigūruokite reprezentatyvias darbo eigas, sukurkite bei išbandykite integracijas, atlikite kelias migracijos repeticijas, mokykite pagal roles, pilotuokite su tikru sudėtingumu, prieš perėjimą sulyginkite duomenis, numatykite laiku apribotą grįžimo sprendimą ir stabilizuokite veiklos rodikliais.
Dealer teams moving from legacy systems to a connected dealership platform through a controlled rollout
Tikslas – saugus atstovybės veiklos tęstinumas, ne vien eilučių perkėlimas.

Svarbiausios išvados

  • Duomenų profiliavimas vyksta prieš tikslinės būsenos projektavimą ir migracijos apimties nustatymą.
  • Susiekite verslo objektus ir ryšius, ne tik lenteles.
  • Repetuokite migraciją su automatiniu sulyginimu ir įvardytais priėmimo savininkais.
  • Piloto, bangų ir vienkartinio perėjimo būdams reikia aiškios rizikos logikos.
  • Perėjimas baigiasi tik įvykdžius stabilizavimo kriterijus.

1. Sutelkite valdymą ir saugokite veiklos tęstinumą

Sukurkite vieną planą, apimantį procesus, produktą, duomenis, integraciją, kontrolę, žmones ir perėjimą. Paskirkite vykdomąjį rėmėją bei atsakingus vadovus kiekvienam padaliniui, šaliai ir duomenų sričiai. Apibrėžkite problemų svarbą, sprendimo teises, eskalavimą ir kasdienį kritinių etapų veiklos ritmą.

Anksti nustatykite verslo ribojimus: finansinį uždarymą, registracijos laikotarpius, OEM kampanijas, didžiausio pardavimo savaitgalius, padangų sezoną, metų pabaigos atsargų inventorizaciją ir įstatymų nustatytą ataskaitų teikimą. Techniškai laisvas savaitgalis gali būti veiklos požiūriu pavojingas perėjimo langas.

Saugumas ir privatumas turi būti plano dalis nuo pat pradžių. BDAR reikalauja duomenų kiekio mažinimo, tikslumo, saugojimo ribojimo, vientisumo ir atskaitomybės.[1] Migracijos kopijos gali padidinti riziką, todėl išrašams, testavimo sistemoms ir pagalbos kanalams reikia suprojektuoti aplinkų kontrolę, prieigą, šifravimą, saugojimą ir ištrynimą.

2. Profiliuokite ir klasifikuokite šaltinio duomenis

Inventorizuokite kiekvieną šaltinį, savininką, formatą, apimtį, raktą, istorijos laikotarpį, jautrumą ir kokybės problemą. Profiliuokite pasikartojančius klientus, neteisingus adresus, netaisyklingus VIN, našlaičius įrašus, atviras operacijas, nenuoseklias būsenas, neigiamas atsargas, nesusietus mokėjimus ir nebeaktualius naudotojus. Užfiksuokite duomenų kilmę bei teisines saugojimo prievoles.

Migracijos sprendimas pagal duomenų klasę
SprendimasNaudojimasPriėmimo dėmesys
Aktyvi migracijaAktyvūs klientai, transporto priemonės, sandoriai, darbai, atsargos ir likučiaiIšsamumas, ryšiai ir dabartinė vertė
Istorinė migracijaKasdienėje darbo eigoje reikalinga istorijaPaieška, chronologija ir identifikatoriai
Ieškomas archyvasRetai naudojami, bet saugomi įrašaiPrieiga, vientisumas, saugojimas ir eksportas
SuvestinėPradiniai likučiai arba suvestinė istorijaSulyginimas su patvirtintu šaltiniu
Pagrįstas ištrynimasPasibaigusio galiojimo ar nereikalingi duomenysPatvirtinimas, teisinis sulaikymas ir ištrynimo įrodymai

Nemigruokite visko vien todėl, kad saugykla pigi. Perteklinė istorija gali mažinti kokybę ir didinti privatumo riziką. Netrinkite duomenų vien dėl to, kad konvertuoti sunku. Sprendimą turi patvirtinti verslo, teisės ir duomenų savininkai.

3. Suprojektuokite tikslinius procesus ir duomenų atsakomybę

Naudokite tikslinės būsenos dirbtuves, kad nustatytumėte, kas turi keistis, užuot kopijavę kiekvieną senos sistemos apėjimą. Kiekvienam klientui, transporto priemonei, sandoriui, remonto užsakymui, daliai ir finansiniam įrašui apibrėžkite pagrindinę sistemą, identifikatorius, gyvavimo ciklo būsenas, privalomus laukus, rolių teises ir tolesnius vartotojus.

Išsaugokite būtinas vietines variacijas. Šalių apskaita, PVM, sąskaitų išrašymas, mokėjimai, vartotojų taisyklės ir OEM sąsajos gali skirtis. ES programa „PVM skaitmeniniame amžiuje“ nurodo ilgalaikę struktūrizuoto e. sąskaitų išrašymo kryptį, nors nacionaliniai reikalavimai gali atsirasti anksčiau.[2] Lokalizaciją laikykite valdoma projektavimo pakopa, o ne vėlyva šablono išimtimi.

Apibrėžkite integracijos elgseną kuriant, atnaujinant, atšaukiant, taisant ir trinant. STAR automobilių srities modelis ir API parodo bendrą klientų, transporto priemonių, užklausų, sandorių ir pristatymo mainų semantiką.[3] Reikia patikrinti, ar tiekėjas tai įgyvendina; Europos finansų bei mokesčių laukams gali reikėti plėtinių.

4. Išbandykite konfigūraciją, integraciją ir migraciją

DMS migracijos etapų vartaiSeptyni etapai nuo profiliavimo iki stabilizavimo, kiekvieną skiria sprendimo vartai. Profiliavimas Projektavimas Kūrimas irsusiejimas Repeticija Pilotas Perėjimas Stabilizavimas Kiekvieniems vartams reikia įrodymo, savininko ir sprendimo „vykdyti / nevykdyti“.

Atlikite kelias visos apimties repeticijas į gamybą panašiomis sąlygomis. Kiekvienas paleidimas turi parengti pakartojamą išrašo, transformavimo, įkėlimo ir sulyginimo ataskaitą. Stebėkite trukmę, nesėkmių dažnį, rankines intervencijas ir neišspręstas išimtis. Prieš galutinę repeticiją užšaldykite susiejimų pakeitimus, nebent jų reikia valdomam defektui ištaisyti.

Testuokite integracijas nuo galo iki galo, įskaitant gedimą ir atkūrimą. Patikrinkite autentifikavimą, užklausų limitus, dublikatų tvarkymą, pakartojimą, eiliškumą, stebėseną, įspėjimus, versijų suderinamumą ir sulyginimą. Testuokite našumą esant didžiausiai apkrovai bei pablogėjusiomis sąlygomis. Patvirtinkite roles, pareigų atskyrimą ir išėjusių naudotojų prieigą.

5. Mokykite pagal role ir įrodykite veiklos pasirengimą

Mokymai turi atspindėti tikrą darbą, o ne meniu. Pardavimo darbuotojai praktikuoja užklausą, pasiūlymą, įskaitomą automobilį, užsakymą ir išimtį. Technikai bei konsultantai – rezervavimą, laiką, dalis, nustatytus faktus, patvirtinimą ir sąskaitą. Naudotų automobilių komandos – priėmimą, patikrą, mediją, publikavimą, kainodarą ir perkėlimą. Finansai – registravimą, taisymą, laikotarpio uždarymą ir sulyginimą.

Pasitelkite pagrindinius naudotojus ir stebimus gebėjimų patikrinimus. Matuokite užbaigimą, užduočių sėkmę ir klaidas, tada teikite pagalbą vietoje. Dokumentuokite laikinus procesus prastovai ir nebaigtoms integracijoms. Pasirengimas apima įrenginius, spausdintuvus, skaitytuvus, tapatybę, ryšį, pagalbos kontaktą ir sprendimų aprėptį kiekvienoje pamainoje.

6. Pasirinkite piloto ir diegimo logiką

Pilotas turi būti pakankamai reprezentatyvus, kad atskleistų sudėtingumą, ir pakankamai apribotas, kad būtų galima greitai taisyti. Paprastas padalinys be svarbaus OEM ar apskaitos sudėtingumo gali sukurti klaidingą pasitikėjimą. Rinkitės vietą su įsipareigojusia vadovybe, tipiškais duomenimis, reikšminga apimtimi ir bent viena svarbia integracija.

Diegimas bangomis padeda mokytis ir mažina vienalaikę riziką, bet sukuria laikiną darbą per kelias sistemas ir gali pailginti programos kaštus. Vienkartinis perėjimas išvengia ilgos mišrios aplinkos, tačiau sutelkia veiklos riziką. Rinkitės pagal bendrus finansus, centralizuotas atsargas, klientų bei transporto priemonių srautus tarp padalinių, sąsajų priklausomybes ir turimą pagalbą, o ne pagal ideologiją.

7. Pereikite su sulyginimo ir grįžimo kontrole

Minutės tikslumu ir pagal savininką apibrėžkite užšaldymą, galutinį išrašą, įkėlimą, techninį patvirtinimą, verslo sulyginimą, sąsajų aktyvavimą, naudotojų prieigą ir atidarymo seką. Sulyginkite aktyvių klientų, transporto priemonių, atsargų, atvirų sandorių, remonto užsakymų, dalių, gautinų bei mokėtinų sumų, grynųjų ir didžiosios knygos likučių skaičius bei vertes. Imkite kritinių ryšių ir dokumentų imtis, ne tik bendras sumas.

Nustatykite sprendimo „vykdyti / nevykdyti“ ribas ir paskutinį atsakingą grįžimo laiką. Grįžimo planas turi apibrėžti, kaip fiksuojamos ir sulyginamos naujos operacijos. Atidarius naują platformą naudokite valdymo centrą su svarba, savininku, laikinu sprendimu ir kito atnaujinimo laiku. Stebėkite veiklos būklę, ne tik techninį prieinamumą.

8. Kur tinka „Omnetic“

Viešame „Omnetic“ DMS puslapyje aprašoma 17 vietinių modulių, veikiančių su vienu bendru duomenų modeliu ir apimančių pardavimą, CRM, servisą, transporto priemonių įsigijimą, apskaitą, ataskaitas bei „CarAudit“.[4] Tokia aprėptis suteikia pirkėjui galimybę suprojektuoti etapais vykstantį diegimą pagal konkrečias darbo eigas, tačiau siūlomam diegimui reikia patvirtinti komercinę komplektaciją, technines priklausomybes ir seką.

„Omnetic“ yra tinkamas kandidatas, kai migracija organizuojama pagal kliento ir transporto priemonės tęstinumą bei išmatuojamą darbo eigos naudojimą. Siūlomam diegimui būtina patvirtinti tikslią šalies apskaitą, OEM sąsajas, API apimtį, duomenų laikymo vietą, saugumą, migracijos priemones ir pagalbą. Negalima žadėti universalaus diegimo termino.

Ribotumai

Tai kontrolės sistema, ne projekto grafikas. Apimtis, trukmė ir diegimas priklauso nuo duomenų, šalių, sąsajų ir išteklių. Reguliaciniai teiginiai yra bendro pobūdžio gairės. Produkto galimybės neatleidžia atstovo nuo atsakomybės už duomenų sprendimus, testavimą, mokymus ir priėmimą.

Dažniausiai užduodami klausimai

Pasirinkite rinką ir kalbą

Tarptautinis