Datan siirto järjestelmästä toiseen: vientimuodot ja viennin testaus etukäteen

Datan siirto ratkeaa jo sopimusta tehtäessä. Tällä sivulla on vientimuodot jotka kannattaa vaatia kirjattavaksi, tunnin testi jolla varmistat viennin toimivuuden vuosia etukäteen, ja siirron vaiheet tarkistuksineen.

Datan siirto järjestelmästä toiseen onnistuu tai epäonnistuu ennen kuin siirtoa on aloitettu. Ratkaiseva hetki on se, kun sopimus allekirjoitetaan: mitä vientimuotoja siihen kirjattiin ja onko vienti koskaan ajettu.

Alla on lista vientimuodoista, jotka kannattaa vaatia sopimukseen, ja menetelmä viennin testaamiseen silloin kun kaikki on hyvin — eli vuosia ennen kuin sitä tarvitaan.

Suora vastaus: mitä sopimukseen vaaditaan?

Datan siirto järjestelmästä toiseen turvataan sopimuksessa yhdellä ainoalla lauseella, kunhan se on riittävän tarkka. Lauseen tehtävä on varmistaa, että saat oman datasi ulos koneluettavassa muodossa, veloituksetta ja ilman että kukaan toimittajan päässä tarvitsee tehdä sinulle palveluksen. Se kattaa neljä eri asiaa: rakenteisen datan, tietokannan, tiedostot ja kuvauksen siitä mitä kentät tarkoittavat. Jokainen näistä neljästä kattaa eri osan datastasi, eikä yksikään korvaa toista. Pykälä kannattaa kirjata sopimukseen silloin, kun suhde toimittajaan on hyvä, koska silloin se ei maksa mitään eikä herätä kysymyksiä. Kun sitä tarvitaan, neuvotteluasema on jo huono. Kirjaa siis tämä:

"Tilaajalla on oikeus milloin tahansa viedä kaikki tilaajan data koneluettavassa muodossa ilman erillistä veloitusta ja ilman toimittajan myötävaikutusta. Vientimuodot: rakenteinen data CSV tai JSON, tietokanta vakiomuotoisena vedoksena, tiedostot alkuperäisessä muodossaan, sekä kuvaus tietokentistä."

Neljä osaa, joista jokainen kattaa eri asian:

Kenttäkuvaus on näistä aliarvostetuin. Ilman sitä siirto muuttuu arvailuksi, ja arvaus tehdään yleensä väärin siinä kohdassa, jossa se maksaa eniten: asiakkaan tilassa, maksun tilassa tai päivämäärissä.

Mihin kukin vientimuoto kelpaa?

Käytännön suositus: pyydä sekä CSV että JSON samasta datasta. CSV:llä tarkistat silmällä, JSON:lla siirrät. Ne eivät ole toistensa vaihtoehtoja vaan toisiaan täydentäviä, eikä molempien tuottaminen ole toimittajalle merkittävää lisätyötä.

Testaa vienti nyt, älä silloin kun tarvitset sitä

Vientitoiminnon testaaminen on tämän artikkelin tärkein kohta, ja se tehdään nyt eikä siirtohetkellä. Vientitoiminto, jota ei ole koskaan ajettu, on lupaus eikä ominaisuus: sopimuksessa lukeva pykälä ei kerro mitään siitä, toimiiko nappi, tuleeko data ulos oikeassa merkistössä ja onko mukana kaikki. Testi vie noin tunnin ja kannattaa tehdä kerran vuodessa, aina samalla tavalla, jotta tuloksia voi verrata. Ajankohta on olennainen: jos testi paljastaa puutteita, ne korjataan halvemmalla silloin, kun olet maksava asiakas etkä lähdössä pois. Alla oleva seitsemän kohdan lista käy läpi ne asiat, jotka käytännössä paljastavat puutteellisen viennin — merkistön, rivimäärät, päivämäärät, liitteet ja yhden asiakkaan tiedot kokonaisuudessaan.

1. Aja vienti itse käyttöliittymästäJos et löydä vientinappia, se on ensimmäinen löydös. Kysy toimittajalta missä se on — nyt, kun kysymys on neutraali.
2. Avaa tiedosto ja katso ääkkösetEtsi sana jossa on ä tai ö. Jos näet kummallisia merkkejä, merkistö on väärä. Pyydä UTF-8.
3. Laske rivit ja vertaa järjestelmäänJos järjestelmä sanoo 1 240 asiakasta ja tiedostossa on 1 180 riviä, vienti on osittainen. Selvitä miksi ennen kuin luotat siihen.
4. Tarkista päivämäärät ja desimaalitOnko päivämäärä muodossa jonka tunnistat? Onko summissa pilkku vai piste? Onko aikavyöhyke merkitty? Nämä kolme rikkovat tuonnin useimmin.
5. Etsi yksi tuntemasi asiakas ja tarkista kaikki hänen tietonsaYksi rivi kokonaan läpi kertoo enemmän kuin tuhannen rivin silmäily. Puuttuuko jokin kenttä, jonka tiedät olevan järjestelmässä?
6. Tarkista liitteetJos rivillä lukee tiedoston nimi, onko itse tiedosto paketissa? Yleensä ei ole. Pyydä erikseen.
7. Kirjaa tulos ja päivämääräYksi rivi muistiinpanoihin: mitä testattiin, mikä toimi, mikä ei. Ensi vuonna vertaat tähän.

Jos testi paljastaa puutteita, korjaa ne nyt eikä siirtohetkellä. Puuttuva vienti on paljon halvempi korjata silloin, kun olet maksava asiakas etkä lähdössä.

Miten siirto etenee vaiheittain?

Datan siirto järjestelmästä toiseen etenee seitsemässä vaiheessa, ja järjestys on olennainen osa lopputulosta. Ensin päätetään mitä ylipäänsä siirretään, koska kaikkea ei kannata siirtää. Sitten data viedään ulos ja siivotaan, tehdään kenttäkartta vanhan ja uuden järjestelmän välille, ajetaan koesiirto pienellä otoksella ja vasta sen jälkeen täysi siirto. Lopuksi tarkistetaan luvut ja irtisanotaan vanha järjestelmä — tässä järjestyksessä, ei toisin päin. Yleisin peruuttamaton virhe on katkaista vanha sopimus ennen kuin uusi data on tarkistettu, koska sen jälkeen paluutietä ei ole. Kun siirto on ajankohtainen, järjestys on siis tämä:

1. Kartoita mitä siirretäänKaikkea ei kannata siirtää. Erottele aktiivinen data (asiakkaat, avoimet tilaukset, tuotteet) ja historia (vanhat tapahtumat). Historia voi jäädä arkistoon.
2. Vie data ja siivoa sePoista kaksoiskappaleet, korjaa ilmiselvät virheet, yhtenäistä muodot. Siirto on ainoa hetki, jolloin siivous on luontevaa. Älä siirrä roskaa uuteen järjestelmään.
3. Tee kenttäkarttaTaulukko, jossa vasemmalla vanhan järjestelmän kenttä ja oikealla uuden. Rivit, joille ei löydy paria, ovat päätöksiä jotka pitää tehdä tietoisesti.
4. Aja koesiirto pienellä otoksellaSata riviä. Tarkista lopputulos uudessa järjestelmässä silmällä. Korjaa kartta ja toista.
5. Aja täysi siirto ja pidä molemmat rinnakkainVanha järjestelmä pidetään lukutilassa vähintään kuukauden ajan. Tämä on halpa vakuutus.
6. Tarkista kolme lukuaRivimäärät, summat ja päivämäärähaarukat vanhassa ja uudessa. Jos nämä kolme täsmäävät, siirto on todennäköisesti onnistunut.
7. Vasta sitten irtisano vanhaSopimuksen katkaisu ennen tarkistusta on yleisin peruuttamaton virhe.

Leikkauspäivän valinta ansaitsee oman huomionsa: valitse hetki, jolloin liikennettä on vähiten ja jolloin sinulla on kaksi rauhallista päivää tarkistuksiin. Laskutusjärjestelmissä tämä on yleensä kuun vaihde, ja siitä on tarkemmin laskutusohjelman vaihtamista käsittelevässä artikkelissa.

Viisi asiaa, jotka menevät useimmin rikki

• Merkistö. Ääkköset muuttuvat kysymysmerkeiksi tai kummallisiksi pareiksi. Ratkaisu on UTF-8 molemmissa päissä. Tämä on yleisin yksittäinen ongelma suomalaisessa datassa.
• Päivämäärät. Sama tiedosto voi sisältää kahta eri muotoa, jos dataa on vuosien varrelta. Tarkista vanhin ja uusin rivi erikseen.
• Desimaalierotin. Pilkku ja piste sekaisin muuttaa 1 234,50 luvuksi 123 450 tai nollaksi. Rahassa tämä on kallis virhe.
• Tunnisteiden katoaminen. Uusi järjestelmä antaa omat numeronsa. Säilytä vanhat tunnisteet omassa sarakkeessaan, jotta voit yhdistää vanhat dokumentit uusiin riveihin.
• Suhteet rivien välillä. Tilaus ilman asiakasta tai lasku ilman tilausta syntyy, kun taulut siirretään väärässä järjestyksessä. Siirrä aina ensin ne, joihin muut viittaavat.

Milloin dataa EI kannata siirtää?

Kun historia on vain historiaa. Kymmenen vuoden tapahtumat maksavat siirtona paljon ja hyödyttävät harvoin. Vaihtoehto: vie historia CSV-tiedostoina arkistoon ja siirrä uuteen järjestelmään vain viimeiset 12–24 kuukautta. Kirjanpitoaineiston säilytysvelvollisuus täyttyy arkistolla — voimassa olevat vaatimukset kannattaa tarkistaa vero.fi-sivustolta.

Kun data on huonolaatuista. Rekisteri, jossa puolet yhteystiedoista on vanhentuneita ja joka kolmas rivi on kaksoiskappale, ei parane siirrossa. Joskus järkevin ratkaisu on aloittaa puhtaalta pöydältä ja tuoda vain aktiiviset asiakkaat.

Kun kyse on henkilötiedoista, joita ei enää tarvita. Vanhojen henkilötietojen siirtäminen uuteen järjestelmään laajentaa vastuutasi ilman hyötyä. Siirron yhteydessä on luonteva hetki poistaa se, mille ei ole käyttötarkoitusta. Rekisterin siivoamisesta on tarkemmin asiakasrekisteriä ja tietosuojaa käsittelevässä artikkelissa.

Kun siirto maksaa enemmän kuin manuaalinen syöttö. Kolmensadan asiakkaan tiedot syötetään käsin päivässä. Automaattisen siirron rakentaminen, testaus ja korjaus voi viedä enemmän. Laske molemmat ennen kuin päätät.

Kuka siirron tekee?

Kolme vaihtoehtoa, ja kaikki kelpaavat eri tilanteissa. Uuden järjestelmän toimittaja tuntee kohteen ja tarjoaa yleensä tuontityökalut — hyvä valinta, kun data on suoraviivaista. Ulkopuolinen tekijä on puolueeton ja hyödyllinen silloin, kun vanha ja uusi eivät ole samantyyppisiä tai kun kenttäkartta vaatii päätöksiä. Itse tekeminen on täysin realistista muutaman sadan rivin siirroissa, jos vienti ja tuonti ovat molemmat tuettuja.

Yhden asian kannattaa pysyä sinulla riippumatta tekijästä: tarkistus. Se, joka teki siirron, on huonoin tarkistamaan sen. Aja rivimäärät ja summat itse ja vertaa.

Jos siirto on osa isompaa järjestelmänvaihtoa tai järjestelmiä on useita, kokonaisuuden suunnittelu on IT-konsultointia ja etenee tuntityönä. Tuntihinta on hinnastossa.

Tiedostosiirto vai rajapinta — kumpi milloin?

Datan siirto järjestelmästä toiseen voidaan tehdä kahdella tavalla: viedään tiedostot ulos ja tuodaan ne uuteen järjestelmään, tai luetaan data rajapinnan kautta ohjelmallisesti. Valinta ei ole makuasia vaan riippuu kolmesta asiasta: onko siirto kertaluonteinen vai jatkuva, kuinka paljon rivejä ja kuinka monimutkaisia suhteita datassa on, ja pitääkö vanhan ja uuden järjestelmän toimia rinnakkain. Tiedostosiirto riittää muutaman tuhannen rivin kertaluonteiseen vaihtoon ja onnistuu taulukkolaskennalla. Rajapintasiirto on työläämpi ja vaatii ohjelmointia, mutta se on ainoa tapa silloin, kun rivejä on satojatuhansia tai kun järjestelmien pitää pysyä synkronissa keskenään. Alla oleva taulukko kertoo kysymys kerrallaan kumpaan suuntaan kukin tilanne kallistuu.

Pienyrityksen kertaluonteisessa järjestelmänvaihdossa tiedostosiirto on lähes aina oikea valinta. Rajapintaa kannattaa harkita silloin, kun siirto ei ole kertaluonteinen tapahtuma vaan järjestelmien pitää keskustella jatkossakin — esimerkiksi kassan ja kirjanpidon tai verkkokaupan ja varastonhallinnan välillä. Se on eri projekti kuin siirto, ja siitä on tarkemmin rajapintaintegraatiota käsittelevässä artikkelissa.

Kolme lukua, joilla todistat että siirto onnistui

Siirron jälkeen tarvitaan todiste, ei tuntuma. Kolme lukua riittää, ja ne otetaan sekä vanhasta että uudesta järjestelmästä samalta ajanjaksolta.

• Rivimäärä. Montako asiakasta, tuotetta, tilausta. Jos luvut eroavat, ero pitää pystyä selittämään — esimerkiksi tietoisesti pois jätetyt poistetut rivit. Selittämätön ero tarkoittaa, että jotain katosi.
• Summat. Laske yhteen tilausten arvo tai avoimien laskujen loppusumma valitulta jaksolta. Rahassa täsmäävä summa on vahvin yksittäinen todiste siitä, että data tuli perille oikein.
• Päivämäärähaarukka. Vanhin ja uusin tapahtuma. Jos uudessa järjestelmässä vanhin rivi on kaksi vuotta myöhemmin kuin vanhassa, osa historiasta jäi tulematta.

Ota nämä kolme lukua talteen kirjallisesti päivämäärän kanssa. Jos jokin paljastuu myöhemmin puutteelliseksi, tiedät heti oliko vika siirrossa vai sen jälkeisessä käytössä. Ilman kirjattua lähtötilannetta se on mahdotonta selvittää.

Tarkistus kannattaa tehdä itse, vaikka siirron olisi tehnyt joku muu. Se, joka rakensi kenttäkartan, tarkistaa sen omilla oletuksillaan — ja juuri niissä oletuksissa virhe on.

Usein kysyttyä

Lue seuraavaksi

• Domainin ja webhotellin siirto ilman katkoa — aikataulutettu viiden vaiheen ohje
• Kuka omistaa yrityksen datan — ja kolme kysymystä, jotka esität ennen sopimusta
• Sähköpostin siirto omaan domainiin — IMAP-siirto, MX-vaihdon ajoitus ja SPF/DKIM/DMARC kopioitavana
• Yrityssovelluksen kehittämisen hinta
• WordPress-ylläpidon hinta ja mitä siihen oikeasti kuuluu
• Wolt, Foodora ja se 20–30 %: mitä KKV:n ratkaisu muutti ravintolalle

Lue myös: Android-sovellus Google Playhin · yrityksen tietoturva · varmuuskopiointi · hakukoneoptimoinnin hinta · Verkkokaupan perustaminen: hinta, vaihtoehdot ja todellinen kululista · Tietosuojaseloste-malli pienyritykselle · Liiketoimintasuunnitelman pohja ja laskelmat · IT-konsultointi pienyritykselle