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.

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.
| Sprendimas | Naudojimas | Priėmimo dėmesys |
|---|---|---|
| Aktyvi migracija | Aktyvūs klientai, transporto priemonės, sandoriai, darbai, atsargos ir likučiai | Išsamumas, ryšiai ir dabartinė vertė |
| Istorinė migracija | Kasdienėje darbo eigoje reikalinga istorija | Paieška, chronologija ir identifikatoriai |
| Ieškomas archyvas | Retai naudojami, bet saugomi įrašai | Prieiga, vientisumas, saugojimas ir eksportas |
| Suvestinė | Pradiniai likučiai arba suvestinė istorija | Sulyginimas su patvirtintu šaltiniu |
| Pagrįstas ištrynimas | Pasibaigusio galiojimo ar nereikalingi duomenys | Patvirtinimas, 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ą
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
Universalaus termino nėra. Planą lemia sudėtingumas, duomenys, integracijos, ištekliai ir keitimų draudimo laikotarpiai.
Ne. Pagal poreikį ir teisę naudokite aktyvią migraciją, reikalingą istoriją, archyvą, suvestinę ir pagrįstą ištrynimą.
Naudokite jį ten, kur rizika pagrindžia patvirtinimą, tačiau ribokite apimtį ir trukmę, kad nebūtų nuolatinio dvigubo vedimo.
Skaičius, vertes, likučius ir ryšius tarp aktyvių veiklos bei finansinių įrašų.
Reprezentatyvus sudėtingumas, įsipareigojusi vadovybė, reikšminga apimtis ir apribotas taisymo ciklas.