ERP versijos kėlimas: kaip pasiruošti ir suvaldyti rizikas
ERP versijos kėlimas nėra vien techninis atnaujinimas. Tai proga įvertinti procesus, duomenis, integracijas ir pasiruošti pokyčiams taip, kad gamyba nesustotų.
Greita santrauka
Versijos kėlimą verta planuoti kaip atskirą projektą: pirmiausia įvertinti dabartinę aplinką, tada pasiruošti duomenis, integracijas, testus ir aiškų grįžimo planą.
Kodėl ERP versijos kėlimas gamybos įmonėje reikalauja pasiruošimo
ERP sistema gamybos įmonėje susieta su gamybos planavimu, sandėliu, apskaita, darbo vietomis ir kitomis sistemomis. Todėl nauja versija gali pakeisti ne tik vartotojo sąsają, bet ir integracijų veikimą, duomenų struktūras, teises bei kasdienius procesus.
Geras versijos kėlimo projektas prasideda nuo klausimo, ką norime pagerinti. Vien techninis atnaujinimas nepadės, jeigu kartu perkeliamos senos klaidos, nekokybiški pagrindiniai duomenys ar neprižiūrimos individualios modifikacijos.
ERP versijos kėlimo etapai
-
Dabartinės aplinkos įvertinimas
Inventorizuoti naudojamus modulius, individualius pakeitimus, integracijas, ataskaitas, sąsajas su gamybos įranga ir kritinius kasdienius procesus.
-
Suderinamumo ir pakeitimų analizė
Patikrinti, kas iš esamos aplinkos veiks naujoje versijoje, ką reikia perkurti, o ko verta atsisakyti. Nestandartiniai sprendimai dažnai tampa didžiausiu projekto neapibrėžtumu.
-
Testinės aplinkos, atsarginių kopijų ir duomenų paruošimas
Sukurti testinę aplinką, pasiruošti pagrindinius duomenis ir numatyti, kaip bus tikrinami realūs gamybos scenarijai. Prieš pakeitimus patikrinti atsarginių kopijų sukūrimą ir atkūrimą. Testavimas turi apimti visą proceso grandinę.
-
Integracijų ir naudotojų testavimas
Patikrinti duomenų apsikeitimą su finansų, sandėlio, pardavimų, gamybos ir kitomis sistemomis. Į testus turi įsitraukti realūs naudotojai.
-
Paleidimas ir stabilizacija
Iš anksto sutarti paleidimo laiką, atsakomybes, pagalbos kanalus, incidentų prioritetus ir atkūrimo planą. Prieš paleidimą apibrėžti aiškius go/no-go kriterijus, o po jo stebėti kritinius procesus ir duomenų kokybę.
Į ką atkreipti dėmesį
- Ar versijos kėlimas išsprendžia realią verslo problemą, ar tik atideda sudėtingesnį sprendimą?
- Ar visos kritinės integracijos ir individualūs pakeitimai turi aiškų savininką?
- Ar numatyti vidiniai resursai naudotojų testams bei mokymams?
- Ar prieš upgrade patikrintas atsarginių kopijų atkūrimas, o ne tik pats kopijos sukūrimas?
- Ar suderintas duomenų migracijos, integracijų ir naudotojų testų kalendorius su gamybos planu?
Dažniausiai užduodami klausimai
Ar ERP versijos kėlimas yra tas pats, kas naujos sistemos diegimas?
Ne. Keliama esama sistema, tačiau gali keistis jos architektūra, integracijos, duomenų struktūros ir procesai.
Kada geriau kelti versiją, o kada keisti ERP?
Jeigu sistema vis dar atitinka pagrindinius procesus, versijos kėlimas gali būti racionalesnis. Jeigu technologija riboja veiklą arba pakeitimai kainuoja neproporcingai daug, verta vertinti keitimą.
Ką būtina patikrinti prieš ERP versijos kėlimą?
Reikia patikrinti palaikymo sąlygas, suderinamumą, individualius pakeitimus, integracijas, atsarginių kopijų atkūrimą, testinę aplinką ir pagrindinių naudotojų pasirengimą.
Ar galima ERP upgrade atlikti savaitgalį?
Kartais taip, tačiau kalendorinis langas nėra vienintelis kriterijus. Prieš paleidimą turi būti baigti testai, paruoštas atkūrimo planas, paskirti atsakingi žmonės ir suderinta pagalba pirmosiomis darbo dienomis.
Kaip suprasti, kad versijos kėlimo projektas pasiruošęs paleidimui?
Turi būti įvykdyti iš anksto sutarti go/no-go kriterijai: kritiniai scenarijai ištestuoti, duomenys sutikrinti, integracijos veikia, naudotojai apmokyti, o atkūrimo planas praktiškai patikrintas.
Reikia pagalbos planuojant ERP versijos kėlimą?
Pasidalinsiu praktine patirtimi iš gamybos sektoriaus IT projektų.
Susisiekti