Miksi toimittajan vaihtoon varaudutaan jo ERP-projektissa?

Toiminnanohjausjärjestelmä voi olla yrityksen tilausten, työnohjauksen, varaston ja laskutuksen yhteinen työväline. Sen ylläpito ei saa jäädä epäselväksi henkilövaihdoksen, sairastumisen tai toimittajasuhteen päättymisen vuoksi. Siksi luovutettavat aineistot ja jatkuvuuden vastuut sovitaan jo järjestelmää rakennettaessa.

Datastormin asiakkaalla on aina pääsy omaan lähdekoodiinsa ja hän saa aina järjestelmänsä varmuuskopiot. Dokumentoimme toteutuksen seuraavaa kehittäjää varten ja käytämme yleisesti tunnettuja teknologioita. Periaate koskee myös tilannetta, jossa meidät korvataan toisella toimittajalla. Taustaa löydät oppaasta toimittajalukko ja sen välttäminen.

Mitkä 6 vaihetta kuuluvat hallittuun luovutukseen?

Suosittelemme seuraavaa kuuden vaiheen mallia. Vaiheiden aikataulu ja työmäärä sovitetaan järjestelmän laajuuteen; lista ei ole lupaus tietystä siirtoajasta.

1. Kartoita nykytila: kokoa järjestelmän osat, ympäristöt, ulkoiset palvelut, keskeiset työnkulut ja tunnetut puutteet.
2. Nimeä vastuut: sovi asiakkaan päätöksentekijä, nykyisen toimittajan luovutusvastuu ja uuden toimittajan vastaanottovastuu.
3. Kokoa luovutusaineisto: tarkista lähdekoodi, dokumentaatio, varmuuskopiot, käyttöoikeudet ja ulkoisten palvelujen ehdot.
4. Harjoittele palautus: käynnistä järjestelmä erillisessä ympäristössä ja testaa asiakkaan tärkeimmät työnkulut.
5. Toteuta sovittu vaihto: ajoita muutokset, sovi tilanneviestintä ja määritä ehdot siirron keskeyttämiselle tai edelliseen ympäristöön palaamiselle.
6. Hyväksy ja seuraa: varmista toiminta, kirjaa ylläpitovastuun siirtyminen ja poista tarpeettomat vanhat käyttöoikeudet.

Mitä lähdekoodin ja dokumentaation mukana luovutetaan?

Luovutuksen lähtökohtana on tuotannossa olevaa versiota vastaava lähdekoodi. Vastaanottajan pitää pystyä tunnistamaan käytössä oleva versio, asentamaan sen riippuvuudet, käynnistämään kehitysympäristö ja tekemään julkaisu ohjeiden avulla.

• Tekninen kokonaiskuva: sovelluksen osat, tietokannan rakenne, ajastetut tehtävät, integraatiot ja riippuvuuksien versiot.
• Työohjeet: asennus, testaus, julkaiseminen, valvonta, varmuuskopiointi ja palautus.
• Liiketoimintasäännöt: esimerkiksi tilauksen tilat, varaston muutokset, hyväksynnät ja laskutuksen käynnistymisen ehdot.
• Tiedossa olevat puutteet: avoimet virheet, käsin tehtävät työvaiheet, poikkeavat asetukset ja sovitut jatkokehitystarpeet.

Dokumentaatioon kirjataan, mistä tarvittavat salaisuudet löytyvät ja kuka hallitsee niitä. Salasanoja, salausavaimia tai rajapintatunnuksia ei tallenneta lähdekoodiin tai avoimesti jaettavaan luovutusasiakirjaan.

Miten varmuuskopiot ja palautus varmistetaan?

Varmuuskopioinnista sovitaan sisältö, ajotiheys, säilytysaika, säilytyspaikka ja vastuuhenkilö. Tietokannan lisäksi huomioidaan liitteet, käyttäjien tallentamat tiedostot ja palautukseen tarvittavat asetukset. Asiakkaan pitää tietää, miten hän saa varmuuskopionsa myös toimittajan vaihtuessa.

Palautustesti tehdään erillisessä ympäristössä. Testin yhteydessä varmistetaan, etteivät ajastetut tehtävät, sähköpostit tai integraatiot lähetä oikeita tilauksia, laskuja tai muita tapahtumia tuotantopalveluihin. Asiakas ja tekninen toteuttaja sopivat, miten testidata suojataan ja miten testiympäristö poistetaan tai rajataan käytön jälkeen.

Kirjaa palautustestistä käytetty varmuuskopio ja sen ajankohta, palautukseen kulunut aika, tarkistetut tiedot, testatut työnkulut ja havaitut puutteet. Esimerkiksi tilauksen avaamisen lisäksi voidaan tarkistaa, että tilauksen liitteet näkyvät ja sen varastotapahtumat vastaavat odotettua tilannetta.

Jatkuvuuden suunnittelussa sovitaan kaksi erillistä tavoitetta: kuinka pitkä keskeytys on hyväksyttävissä ja kuinka tuoreeseen tilanteeseen tiedot on pystyttävä palauttamaan. Palautustestin tulosta verrataan näihin asiakkaan tarpeista johdettuihin tavoitteisiin. Tavoitteet ja tarvittavat ratkaisut määritellään järjestelmäkohtaisesti.

Kenellä pitää olla käyttöoikeudet ja vastuu ylläpidosta?

Laadi luettelo koodivarastosta, palvelin- ja pilvipalveluista, tietokannasta, verkkotunnuksista, nimipalveluasetuksista, varmuuskopioista ja integraatioista. Merkitse jokaiseen palveluun sen omistaja, laskutuksesta vastaava taho ja oikeuksien myöntäjä. Asiakkaan hallintamahdollisuus pitää järjestää niin, ettei se riipu yhden toimittajan henkilökohtaisesta tunnuksesta.

Anna uudelle toimittajalle henkilökohtaiset, tehtävän edellyttämät oikeudet ja varmista niiden toimivuus ennen vastuun siirtymistä. Sovi samalla, kuka seuraa varmuuskopioiden onnistumista, asentaa päivitykset, käsittelee häiriöt ja vastaa ulkoisista palveluista. Kirjaa päivä ja kellonaika, jolloin ylläpitovastuu siirtyy.

Vanhan toimittajan tarpeettomat oikeudet poistetaan sovittuna ajankohtana, kun siirtyminen on varmistettu. Jos jaettuja salaisuuksia on käytetty, niiden vaihtaminen ja vaikutukset integraatioihin suunnitellaan erikseen. Tunnusten poistaminen ei saa vahingossa pysäyttää ajastettuja tehtäviä tai varmuuskopiointia.

Miten liiketoiminta jatkuu, jos vaihdossa tulee ongelma?

Valitse yrityksesi kannalta kriittiset työnkulut yhdessä teknisen toteuttajan kanssa. Tilausten vastaanotolle, työn suorittamiselle tai toimitusten kirjaamiselle voidaan tarvita väliaikainen toimintatapa. Varamenettelyssä sovitaan myös, kuka kirjaa poikkeustilanteen tapahtumat ja miten ne viedään myöhemmin järjestelmään ilman puuttuvia tai päällekkäisiä tapahtumia.

Jos vaihdossa siirretään ympäristöä, määritä ennen muutosta tarkistukset, hyväksyjä ja viimeinen ajankohta, jolloin siirto voidaan keskeyttää. Vanhaan ympäristöön palaaminen pitää suunnitella myös datan kannalta: uudessa ympäristössä syntyneitä tilauksia tai muutoksia ei voi jättää huomioimatta.

Datastormilla asiakkaan toiminnan jatkuvuus ohjaa häiriöiden käsittelyä. Reagoimme nopeasti yhteydenottoihin, selvitämme vaikutuksen ja kerromme etenemisestä. Tuen palveluajat, kanavat, vastuut ja reagointiajat sovitaan asiakaskohtaisesti. Nopea vastaus ei yksin ratkaise häiriötä, joten myös korjaustoimenpiteet ja seuraava tilannepäivitys tehdään asiakkaalle selviksi.

Milloin toimittajan vaihto ei ole vielä valmis toteutettavaksi?

Siirtoa ei kannata viedä tuotantoon, jos varmuuskopion palautuminen on selvittämättä, kriittisen palvelun käyttöoikeus puuttuu tai uuden ylläpitäjän vastuu on avoin. Puutteet kirjataan ja korjataan ennen sovittua vaihtoa. Yleinen tarkistuslista ei yksin riitä järjestelmään, jonka keskeytys voi aiheuttaa erityisen suurta vahinkoa; jatkuvuussuunnitelma pitää tehdä kyseisen liiketoiminnan tarpeista.

Toimittajan vaihto ei myöskään tarkoita automaattisesti koko ERP-järjestelmän uusimista tai kaikkien palvelujen siirtämistä samalla kertaa. Rajattu ylläpitovastuun siirto voi olla sopiva ensimmäinen vaihe. Ulkoisten palvelujen sopimukset, lisenssit ja siirtorajoitteet selvitetään erikseen. Vaihto voi vaatia perehdytystä, kustannuksia ja käyttökatkon, joiden vaikutukset arvioidaan ennen päätöstä.

Mitä ERP-toimittajan vaihdosta usein kysytään?

Pitääkö ERP-järjestelmä vaihtaa, jos vaihdan kehittäjää?

Ei välttämättä. Uusi toimittaja voi jatkaa nykyisen järjestelmän ylläpitoa ja kehittämistä, jos lähdekoodi, dokumentaatio, oikeudet ja tarvittava osaaminen ovat saatavilla. Nykyisen toteutuksen kunto ja riippuvuudet arvioidaan ennen päätöstä.

Mitä aineistoa uuden toimittajan pitää saada?

Uusi toimittaja tarvitsee tuotantoversiota vastaavan lähdekoodin, asennus- ja julkaisuohjeet, tietorakenteen kuvauksen, palautettavat varmuuskopiot sekä tiedot integraatioista, ympäristöistä ja tunnetuista ongelmista. Tarvittavat käyttöoikeudet ja salaisuudet luovutetaan sovitulla suojatulla tavalla.

Miten tiedän, että varmuuskopio toimii?

Varmuuskopio palautetaan erilliseen testiympäristöön ja palautuksen tulos tarkistetaan. Tarkistukseen kuuluvat tietojen lisäksi liitteet, sovelluksen käynnistyminen ja keskeiset työnkulut. Palautuksesta kirjataan käytetty varmuuskopio, ajankohta, kesto, havainnot ja korjattavat puutteet.

Voiko toimittajan vaihtaa ilman käyttökatkoa?

Se riippuu järjestelmästä ja vaihdon laajuudesta. Pelkkä ylläpitovastuun siirto voi onnistua nykyisessä ympäristössä, mutta palvelimen, tietokannan tai integraatioiden siirto voi vaatia käyttökatkon. Katkon tarve, ajankohta ja varamenettely sovitaan ennen muutosta.

Miten Datastorm toimii häiriötilanteessa?

Reagoimme nopeasti asiakkaan yhteydenottoon, selvitämme häiriön vaikutuksen ja sovimme etenemisestä sekä tilannepäivityksistä. Tuen palveluajat, yhteydenottokanavat, vastuut ja reagointiajat määritellään asiakaskohtaisesti. Häiriöön reagoiminen ja sen ratkaiseminen ovat eri asioita, joten korjauksen aikataulu arvioidaan tilanteen perusteella.

Mistä saat apua ERP-järjestelmän jatkuvuuden suunnitteluun?

Autamme arvioimaan, mitä järjestelmän ylläpidon jatkaminen toisella toimittajalla edellyttää. Käymme läpi nykytilan, dokumentaation, palautuksen ja vastuut. Näin luovutus voidaan suunnitella asiakkaan työn ja liiketoiminnan ehdoilla.

• Räätälöity ERP-järjestelmä – toiminnanohjaus ja sen jatkuva kehitys.
• Tekninen kumppanuus – ylläpidon vastuut ja yhteydenpito.
• Integraatiot ja automaatio – järjestelmien väliset riippuvuudet ja tiedonkulku.

Pyydä arvio