DMS ieviešana
DMS migrācija un ieviešana: pilotprojekts, dati, pāreja un stabilizācija
Droša migrācija ir kontrolēta biznesa transformācija ar atkārtojamiem datu pierādījumiem, pārbaudītiem izņēmumiem un skaidru atgriešanās ceļu, ja pārejas kritēriji nav izpildīti.

Galvenie secinājumi
- Datu profilēšana notiek pirms mērķa projektēšanas un migrācijas tvēruma noteikšanas.
- Kartējiet biznesa objektus un attiecības, nevis tikai tabulas.
- Izmēģiniet migrāciju ar automatizētu saskaņošanu un nosauktiem pieņemšanas atbildīgajiem.
- Pilotprojekta, viļņu un vienlaicīgas pārejas pieejām katrai nepieciešama skaidra riska loģika.
- Pāreja beidzas tikai tad, kad sasniegti stabilizācijas kritēriji.
1. Mobilizējiet pārvaldību un aizsargājiet biznesa nepārtrauktību
Izveidojiet vienu plānu, kas aptver procesu, produktu, datus, integrāciju, kontroles, cilvēkus un pāreju. Norīkojiet vadības atbalstītāju un atbildīgos vadītājus katrai nodaļai, valstij un datu jomai. Definējiet problēmu smagumu, lēmumu tiesības, eskalāciju un ikdienas darbības ritmu kritiskajām fāzēm.
Agri kartējiet biznesa ierobežojumus: finanšu slēgšanu, reģistrācijas periodus, OEM kampaņas, augstākā pārdošanas apjoma nedēļas nogales, riepu sezonu, gada beigu krājuma inventarizāciju un obligāto pārskatu sniegšanu. Tehniski pieejama nedēļas nogale var būt darbības ziņā bīstams pārejas logs.
Drošībai un privātumam plānā jābūt no paša sākuma. BDAR pieprasa datu minimizāciju, precizitāti, glabāšanas ierobežojumu, integritāti un pārskatatbildību.[1] Migrācijas kopijas var palielināt risku, tāpēc izrakstiem, testa sistēmām un atbalsta kanāliem jāizstrādā kontrolētas vides, piekļuve, šifrēšana, saglabāšana un dzēšana.
2. Profilējiet un klasificējiet avota datus
Uzskaitiet katru avotu, atbildīgo, formātu, apjomu, atslēgu, vēstures periodu, jutību un kvalitātes problēmu. Profilējiet dublētus klientus, nederīgas adreses, kļūdainus VIN, bāreņu ierakstus, atvērtus darījumus, nekonsekventus statusus, negatīvu krājumu, nesaskaņotus maksājumus un novecojušus lietotājus. Ierakstiet datu izcelsmi un juridisko saglabāšanas pienākumu.
| Lēmums | Izmantojums | Pieņemšanas fokuss |
|---|---|---|
| Aktīva migrācija | Aktīvi klienti, transportlīdzekļi, darījumi, darbi, krājums un atlikumi | Pilnīgums, attiecības un pašreizējā vērtība |
| Vēsturiskā migrācija | Ikdienas darba plūsmā nepieciešamā vēsture | Meklēšana, hronoloģija un identifikatori |
| Meklējams arhīvs | Reti izmantoti, taču saglabāti ieraksti | Piekļuve, integritāte, saglabāšana un eksports |
| Kopsavilkums | Sākuma atlikumi vai apkopota vēsture | Saskaņošana ar apstiprinātu avotu |
| Pamatota dzēšana | Novecojuši vai nevajadzīgi dati | Apstiprinājums, juridiskā turēšana un dzēšanas pierādījumi |
Nemigrējiet visu tikai tāpēc, ka glabāšana ir lēta. Pārmērīga vēsture var samazināt kvalitāti un palielināt privātuma risku. Nedzēsiet datus tāpēc, ka konvertēšana ir sarežģīta. Lēmumam jābūt biznesa, juridisko un datu atbildīgo apstiprinātam.
3. Projektējiet mērķa procesus un datu atbildību
Izmantojiet nākotnes stāvokļa darbnīcas, lai definētu, kam jāmainās, nevis kopētu katru mantoto apiešanas risinājumu. Katram klientam, transportlīdzeklim, darījumam, remonta pasūtījumam, detaļai un finanšu ierakstam definējiet pamatsistēmu, identifikatorus, dzīves cikla stāvokļus, obligātos laukus, lomu atļaujas un pakārtotos patērētājus.
Saglabājiet nepieciešamās vietējās atšķirības. Valsts grāmatvedība, PVN, rēķinu izrakstīšana, maksājumi, patērētāju noteikumi un OEM saskarnes var atšķirties. ES programma „PVN digitālajā laikmetā” nosaka ilgtermiņa strukturētu e-rēķinu virzienu, lai gan nacionālās prasības var stāties spēkā agrāk.[2] Uzskatiet lokalizāciju par kontrolētu projektēšanas slāni, nevis vēlu šablona izņēmumu.
Definējiet integrācijas uzvedību izveidei, atjaunināšanai, atcelšanai, labošanai un dzēšanai. STAR autobūves domēna modelis un API parāda kopīgu semantiku klienta, transportlīdzekļa, potenciālā klienta, darījuma un piegādes apmaiņai.[3] Jāpārbauda, vai piegādātājs tos ievieš, un Eiropas finanšu un nodokļu laukiem var būt nepieciešami paplašinājumi.
4. Izmēģiniet konfigurāciju, integrāciju un migrāciju
Veiciet vairākas pilna apjoma mēģinājumu izpildes, izmantojot ražošanai līdzīgus apstākļus. Katram palaidumam jārada atkārtojams izraksta, transformācijas, ielādes un saskaņošanas pārskats. Sekojiet ilgumam, kļūmju līmenim, manuālām iejaukšanās reizēm un neatrisinātiem izņēmumiem. Iesaldējiet kartēšanas izmaiņas pirms pēdējā mēģinājuma, ja vien tās nav nepieciešamas kontrolēta defekta labošanai.
Testējiet integrācijas no gala līdz galam, iekļaujot kļūmi un atgūšanu. Pārbaudiet autentifikāciju, pieprasījumu ierobežojumus, dublikātu apstrādi, atkārtotu mēģinājumu, secību, uzraudzību, brīdinājumus, versiju saderību un saskaņošanu. Testējiet veiktspēju maksimālas slodzes un pasliktinātos apstākļos. Pārbaudiet lomas, pienākumu nodalīšanu un pārtraukto lietotāju piekļuvi.
5. Apmāciniet pēc lomas un pierādiet darbības gatavību
Apmācībām jāseko reālajam darbam, nevis izvēlnēm. Pārdošanas darbinieki praktizē potenciālo klientu, piedāvājumu, ieskaitāmo auto, pasūtījumu un izņēmumu. Tehniķi un konsultanti praktizē rezervāciju, laiku, detaļas, konstatējumus, apstiprinājumu un rēķinu. Lietoto auto komandas praktizē pieņemšanu, apskati, mediju, publicēšanu, cenu noteikšanu un pārvietošanu. Finanses praktizē grāmatošanu, labošanu, perioda slēgšanu un saskaņošanu.
Izmantojiet galvenos lietotājus un novērojamas prasmju pārbaudes. Mēriet pabeigtību, uzdevumu veiksmi un kļūdas, tad nodrošiniet atbalstu uz vietas. Dokumentējiet pagaidu procesus dīkstāvei un nepabeigtām integrācijām. Gatavība ietver ierīces, printerus, skenerus, identitāti, savienojamību, atbalsta kontaktu un lēmumu pārklājumu katrā maiņā.
6. Izvēlieties pilotprojekta un ieviešanas loģiku
Pilotprojektam jābūt pietiekami reprezentatīvam, lai atklātu sarežģītību, taču pietiekami ierobežotam, lai to varētu ātri labot. Vienkārša filiāle bez būtiskas OEM vai grāmatvedības sarežģītības var radīt maldīgu pārliecību. Izvēlieties vietu ar apņēmīgu vadību, tipiskiem datiem, nozīmīgu apjomu un vismaz vienu svarīgu integrāciju.
Ieviešana viļņos atbalsta mācīšanos un mazina vienlaicīgu risku, taču rada pagaidu darbību starp sistēmām un var pagarināt programmas izmaksas. Vienlaicīga pāreja izvairās no ilgas jauktas vides, taču koncentrē darbības risku. Izvēlieties, balstoties uz kopīgām finansēm, centralizētu krājumu, klientu un transportlīdzekļu plūsmām starp filiālēm, saskarņu atkarībām un pieejamo atbalstu, nevis ideoloģiju.
7. Veiciet pāreju ar saskaņošanas un atgriešanās kontroli
Definējiet iesaldēšanu, gala izrakstu, ielādi, tehnisko validāciju, biznesa saskaņošanu, saskarnes aktivizēšanu, lietotāju piekļuvi un atvēršanas secību pēc minūtes un atbildīgā. Saskaņojiet aktīvo klientu, transportlīdzekļu, krājuma, atvērto darījumu, remonta pasūtījumu, detaļu, debitoru, kreditoru, naudas un grāmatvedības atlikumu skaitu un vērtības. Ņemiet paraugus no kritiskām attiecībām un dokumentiem, ne tikai kopsummām.
Nosakiet „turpināt / neturpināt” sliekšņus un pēdējo atbildīgo atgriešanās laiku. Atgriešanās plānam jādefinē, kā tiek fiksēti un saskaņoti jauni darījumi. Kad jaunā platforma ir atvērta, izmantojiet vadības centru ar smaguma pakāpi, atbildīgo, pagaidu risinājumu un nākamo atjauninājumu. Sekojiet darbības veselībai, ne tikai tehniskajai pieejamībai.
8. Kur iederas Omnetic
Omnetic publiskā DMS lapa apraksta 17 vietējos moduļus vienā kopīgā datu modelī, aptverot pārdošanu, CRM, servisu, iepirkumu, grāmatvedību, pārskatus un CarAudit.[4] Šis plašums dod pircējam iespēju projektēt pakāpenisku ieviešanu ap konkrētām darba plūsmām, taču piedāvātajai ieviešanai jāapstiprina komerciālais iepakojums, tehniskās atkarības un secība.
Omnetic ir vadošs kandidāts, ja migrācija organizēta ap klienta un transportlīdzekļa nepārtrauktību un izmērāmu darba plūsmas pieņemšanu. Piedāvātajai ieviešanai jāapstiprina precīza valsts grāmatvedība, OEM saskarnes, API tvērums, datu atrašanās vieta, drošība, migrācijas rīki un atbalsts. Nedrīkst solīt universālu ieviešanas ilgumu.
Ierobežojumi
Šī ir kontroles sistēma, nevis projekta grafiks. Tvērums, ilgums un ieviešana ir atkarīgi no datiem, valstīm, saskarnēm un resursiem. Regulatīvie apgalvojumi ir vispārīgas vadlīnijas. Produkta iespējas neatceļ tirgotāja atbildību par datu lēmumiem, testēšanu, apmācību un pieņemšanu.
Biežāk uzdotie jautājumi
Universāla ilguma nav. Plānu nosaka sarežģītība, dati, integrācijas, resursi un aizlieguma periodi.
Nē. Balstoties uz vajadzību un likumu, izmantojiet aktīvu migrāciju, nepieciešamo vēsturi, arhīvu, kopsavilkumu un pamatotu dzēšanu.
Izmantojiet to tur, kur risks pamato validāciju, taču ierobežojiet tvērumu un ilgumu, lai izvairītos no nebeidzamas dubultas ievades.
Skaits, vērtības, atlikumi un attiecības starp aktīviem darbības un finanšu ierakstiem.
Reprezentatīva sarežģītība, apņēmīga vadība, nozīmīgs apjoms un ierobežots labošanas cikls.