Tipinis scenarijus: perėjimas iš Qlik į Power BI diegiant Dynamics 365 vietoje Dynamics AX
Įsivaizduokite organizaciją, turinčią, tarkime, 10–20 dukterinių įmonių, kuri per dvejus metus pereina nuo senosios ERP sistemos, pavyzdžiui, Dynamics AX, prie modernios sistemos, pavyzdžiui, Dynamics 365. Perėjimas nevyksta vienu metu: didesnės įmonės turi atskiras ERP instancijas, mažesnės naudojasi bendra, o kiekviena į naująją sistemą pereina pagal savo grafiką.
Po šiuo sluoksniu veikia daugelį metų augusi BI aplinka, sukurta naudojant tokį įrankį kaip Qlik Sense: šimtai ataskaitų puslapių ir tūkstančiai įterptųjų skaičiuojamųjų rodiklių, o didelė dalis jų logikos nedokumentuota. Naudotojai tikisi, kad naujosios ataskaitos atrodys ir veiks taip pat kaip senosios. Kelių žmonių BI komanda turi tai įgyvendinti greta įprastų darbų ir spėti iki migracijos projekte nustatyto termino.
Būtent masto, nedokumentuotos logikos, ribotų vidinių išteklių ir fiksuoto termino derinys tokią migraciją paverčia iš tiesų sudėtinga, o ne įprasta užduotimi.
Kodėl „perkelti viską iš karto“ dažniausiai nepavyksta
Žvelgiant iš toliau, pavyzdžiui, vadovybės perspektyvos, tai gali atrodyti kaip paprastas perkėlimas (angl. lift-and-shift): perkeliate ataskaitas, nukreipiate jas į naują ERP sistemą ir viskas. Tačiau kiekvienas, dirbęs su duomenų modeliais, žino, kad taip nėra. Praktikoje toks planas žlunga dėl dviejų priežasčių:
- Senoji ir naujoji ERP sistemos duomenis saugo skirtingai. Tai didžiausias iššūkis. Senoji ERP ir ją keičianti sistema retai tuos pačius verslo duomenis organizuoja vienodai, todėl seną duomenų šaltinį tenka susieti su naujuoju (arba atvirkščiai). Būtent dėl šio susiejimo ERP diegimo projektai dažnai užtrunka taip ilgai. Be to, duomenų šaltinis nuolat kinta: kadangi įmonės į naująją sistemą pereina skirtingu metu, BI platforma visą diegimo laikotarpį, o ne tik trumpą persidengimo laikotarpį, turi slėpti, kurią ERP sistemą konkreti įmonė tuo metu naudoja.
- Naudotojai tikisi išlaikyti esamą patirtį, bet ne esamą platformą. Qlik asociatyvusis variklis ir Power BI aiškiai apibrėžtų ryšių modelis veikia skirtingai. Atkurti ataskaitos išvaizdą – tik nedidelė darbo dalis, o tikrasis darbas – atkurti, kaip ji elgiasi esant bet kokiam filtrų deriniui.
Šioje vietoje suklydusios organizacijos dažniausiai arba įšaldo BI plėtros planą, kol baigsis ERP programa. Tuomet naudotojai kelerius metus lieka su senstančia platforma, arba bando viską sukurti iš naujo ir nepastebimai sugadina ataskaitų elgseną, kurios niekas niekada nebuvo dokumentavęs.
7 žingsnių apžvalga
Toliau aprašyti septyni žingsniai skirstomi į tris etapus: planavimą (1–2 žingsniai), architektūrą (3–4 žingsniai) bei analizę ir patikrą (5–7 žingsniai). Diagramoje pateikiama apžvalga, o kiekvienas žingsnis išsamiai aprašytas toliau.
1 pav. Septyni BI modernizavimo keičiant ERP žingsniai, suskirstyti į planavimo, architektūros bei analizės ir patikros etapus.
1 žingsnis. Ataskaitas laikykite ERP programos dalimi, o ne vėlesniu projektu
ERP migracijos paprastai planuojamos orientuojantis į operacinių sistemų pakeitimą, o ataskaitomis pasirūpinama vėliau. Tačiau praktikoje verslo naudotojai ERP diegimo sėkmę vertina pagal tai, ar vis dar gali pasitikėti skaičiais, kuriais remiasi kasdien. Jei BI migracija planuojama kartu su ERP programa nuo pirmosios dienos, o ne po paleidimo, sumažėja įgyvendinimo rizika, o ataskaitos netampa kliūtimi atskiroms įmonėms pereiti prie naujosios sistemos.
2 žingsnis. Pirmiausia išsaugokite verslo elgseną, tik paskui siekite architektūrinės elegancijos
Semantinių modelių pertvarkymas nuo nulio techniniu požiūriu yra patrauklus. Vis dėlto, kai jau veikia šimtai verslui svarbių ataskaitų, jis sukelia nereikalingą funkcinę riziką. Esant tokiam mastui, pragmatiškiau kiekvieną senąją programą perkelti į atskirą semantinį modelį, o ne viską jungti į mažesnį bendrų modelių rinkinį. Kai programų verslo logika, skaičiavimai ir duomenų struktūros iš tiesų skiriasi, priverstinis sujungimas tik padidina sudėtingumą ir be realios naudos kelia grėsmę funkciniam atitikimui. Šis požiūris tinka didelėms ataskaitų sistemoms. Mažesnėms organizacijoms, turinčioms mažiau ataskaitų ir daugiau persidengiančios logikos, gali labiau tikti bendri semantiniai modeliai, taigi tinkamas sprendimas priklauso nuo masto.
3 žingsnis. Standartizuokite duomenų sluoksnį, nebūtinai ataskaitų sluoksnį
Pertvarkymo darbai turėtų vykti žemiau semantinio modelio sluoksnio, o ne jame. Sluoksniuota (angl. medallion) architektūra – bronzos sluoksnis neapdorotiems duomenims gauti, sidabro sluoksnis išvalytoms ir standartizuotoms struktūroms, aukso sluoksnis verslui paruoštiems pateikimo modeliams – leidžia skirtingų šaltinių sistemų duomenis suvienodinti į bendrą struktūrą dar prieš jiems pasiekiant atskiras ataskaitas. Tai veikia nepriklausomai nuo to, kurią ERP sistemą konkreti įmonė tuo metu naudoja. Pavyzdžiui, Microsoft Fabric platformoje šie sluoksniai paprastai kuriami kaip „Lakehouse“ saugyklos (Fabric bendra failų ir lentelių saugykla), iš kurių duomenys teikiami Power BI semantiniams modeliams.
Bendroji pamoka: norint išsaugoti esamą ataskaitų patirtį, nebūtina išlaikyti senosios platformos architektūros. Duomenų gavimo ir transformavimo sluoksnį modernizuokite iš esmės, o ataskaitų logiką, kuria remiasi naudotojai, palikite nepakeistą – svarbu tik sąmoningai nubrėžti architektūrinę ribą tarp jų.
4 žingsnis. Architektūrą kurkite pereinamajam laikotarpiui, o ne tik galutiniam tikslui
Kadangi įmonės į naująją sistemą pereina per ilgą laiką, BI platforma turi vienu metu palaikyti ir senąją, ir naująją ERP, o ne tiesiog pakeisti vieną kita konkrečią perėjimo dieną. Jei architektūra sąmoningai kuriama šiai pereinamajai dviejų sistemų būsenai, užuot tikėjusis sklandaus perdavimo, ERP programa gali judėti kiekvienos įmonės tempu, o ataskaitų platformos nereikia pertvarkyti kaskart, kai į naująją sistemą pereina dar viena įmonė.
5 žingsnis. Tikėkitės nedokumentuotos verslo logikos ir jai pasiruoškite
Ilgai veikiančiose BI aplinkose neišvengiamai susikaupia verslo taisyklių, kurios egzistuoja tik ataskaitose, skaičiavimuose ir duomenų transformacijose, bet ne specifikacijų dokumentuose. Šios logikos išsiaiškinimą ir dokumentavimą nuo pat pradžių laikykite viena pagrindinių migracijos veiklų, kuriai numatytas biudžetas, o ne netikėta komplikacija, paaiškėjančia projekto viduryje. Tai ypač svarbu, kai vidinių komandų ištekliai riboti arba ilgainiui išblėso institucinė atmintis.
6 žingsnis. Našumo testavimą pradėkite dar prieš naudotojų priėmimo testavimą
Modeliavimo sprendimai, kurie gerai veikia vienoje BI platformoje, kitoje gali veikti visai kitaip. Pavyzdžiui, ryšių modelis, kuris asociatyviajame variklyje, tokiame kaip Qlik, akimirksniu pateikia teisingus rezultatus, platformoje su aiškiai apibrėžtų ryšių modeliu gali smarkiai sulėtėti, kai naudotojai pradeda derinti kelias dimensijas ir filtrus. Šias rizikas atskleidžia ankstyvas sudėtingų ryšių modelių, skaičiavimo logikos ir didelės apimties užklausų testavimas, dar prieš ataskaitoms pasiekiant galutinius naudotojus.
7 žingsnis. Tikrinkite elgseną, ne tik vizualinį atvaizdavimą
Perkelta ataskaita gali atrodyti identiškai, bet esant tam tikriems filtrų deriniams ar skaičiavimo kontekstams pateikti kitokius rezultatus. Funkcinė patikra turi apimti daugiau nei grafikų ir lentelių palyginimą: skaičiavimai, filtrų sąveikos, detalizavimo keliai, saugumo taisyklės ir kraštutiniai atvejai turi būti tikrinami pagal faktinius senojo sprendimo rezultatus. Praktikoje tai dažniausiai reiškia, kad atvirkštinės inžinerijos būdu reikia išsiaiškinti ir iš naujo įgyvendinti:
- „Set analysis“ tipo išraiškas ir skaičiuojamuosius rodiklius, perkurtus naujosios platformos skaičiavimo kalba.
- Asociatyvųjį ar numanomą filtravimą, atkurtą naudojant aiškiai apibrėžtą duomenų modelį.
- Numatytuosius pasirinkimus, filtrų priklausomybes ir išskyrimo logiką.
- Detalizavimo (angl. drill-down) ir navigacijos elgseną.
- Ataskaitų ir naudotojų lygmens saugumą.
- Sąlyginį formatavimą ir verslui būdingas vaizdines būsenas.
- Eksporto procesus ir skaičiuoklėmis paremtas naudotojų darbo eigas.
- Suplanuotas ir platinamas ataskaitas, kurias anksčiau tvarkė senasis įrankis.
- Sumų, tarpinių sumų, valiutų ir laikotarpių skaičiavimo logiką.
Kaip organizuoti lygiagrečius darbų srautus
Kai 10–20 įmonių į naująją sistemą pereina skirtingu metu, vidinės ir įgyvendinimo komandos turi kurti atskirus platformos komponentus (atskiras „Lakehouse“ saugyklas, atskirus semantinius modelius, persidengiančius testavimo ciklus) netrukdydamos viena kitai, o vidiniai ištekliai dažnai visą laiką išlieka riboti. DevOps praktikos, koordinuotas versijų valdymas, struktūruotas pakeitimų valdymas, testavimas ir kontroliuojamas diegimas aplinkose leidžia architektūros, migracijos ir patikros darbus vykdyti lygiagrečiai, o ne vieną po kito. Tai ypač svarbu, kai griežtas licencijos atnaujinimo terminas nepalieka vietos visiškai nuosekliam požiūriui „baigiame vieną įmonę, pradedame kitą“.
Kur gali padėti DI įrankiai
DI įrankiai padeda reikšmingai paspartinti inžinerinių darbų vykdymą viso projekto metu, tačiau jie nėra savarankiška migracijos sprendimo dalis. Praktikoje tai dažniausiai reiškia, kad naudojamas į duomenų platformą integruotas „Copilot“ tipo asistentas inžinerinėms užduotims atlikti, bendros paskirties programavimo asistentas kodui generuoti, klaidoms identifikuoti ir šalinti bei dokumentacijai rengti. Taip pat pasitelkiami įrankiai, padedantys kurti ir peržiūrėti skaičiavimo logiką, kuri dažnai yra viena sudėtingiausių ir daugiausia klaidų keliančių senosios verslo logikos atkūrimo sričių.
Kiekvieną DI sugeneruotą rezultatą prieš išleidžiant vis tiek būtina peržiūrėti ir patikrinti pagal faktinę senojo sprendimo elgseną. DI paspartina darbą, tačiau nepakeičia patikros disciplinos, nuo kurios priklauso projekto sėkmė.
Ko tikėtis?
Tai iliustraciniai lūkesčiai gerai įgyvendintam tokio pobūdžio projektui, o ne konkretaus projekto išmatuoti rezultatai:
- Visos projekto apimtyje esančios įmonės galiausiai naudoja vieną tikslinę architektūrą, o ne skirtingų platformų versijų kratinį.
- Prioritetines ataskaitas paprastai įmanoma parengti dar iki senosios licencijos atnaujinimo termino ir taip išvengti ilgo laikotarpio, kai mokama už dvi BI platformas vienu metu, jei dokumentavimas ir testavimas pradedami pakankamai anksti.
- Aukštas funkcinis atitikimas senajam sprendimui yra realus, jei tikrinama elgsena, o ne tik vaizdas. Tačiau tikslus procentas labai priklauso nuo to, kiek buvo nedokumentuotos logikos ir kaip anksti pradėtas testavimas.
- Mažesnė tikimybė, kad pats ERP diegimas bus sustabdytas ar atidėtas dėl BI pasirengimo, nes ataskaitų platforma kuriama pereinamajai, o ne tik galutinei būsenai.
Kodėl tai svarbu?
ERP pokyčius įgyvendinančios organizacijos BI dažnai laiko antraeiliu dalyku, kurį galima modernizuoti baigus „tikrąjį“ projektą. Toks požiūris rizikingas – ataskaitų tęstinumas pereinamuoju laikotarpiu dažnai lemia, ar verslas pasitiki skaičiais, kuriais remdamasis priima sprendimus. Esminis principas nėra „migruokite į konkrečią platformą“ – jis toks: esamų ataskaitų tęstinumas ir platformos modernizavimas vienas kitam neprieštarauja, jei architektūrinė riba tarp jų sąmoningai nubrėžiama duomenų sluoksnyje, o ne ataskaitų sluoksnyje, su kuriuo naudotojai dirba kasdien.
Planuojate BI modernizavimą kartu su savo ERP pokyčiu? Kreipkitės į „Baltic Amadeus“ duomenų analitikos ekspertus.
Dažniausiai užduodami klausimai
Kiek paprastai trunka BI migracija per kelerius metus trunkantį ERP pokytį?
Tai labai priklauso nuo įmonių skaičiaus, senųjų ataskaitų katalogo dydžio ir to, kiek verslo logikos nedokumentuota. Tokio masto migracijos paprastai vyksta lygiagrečiai su pačiu ERP diegimu ir dažnai trunka 12–24 mėnesius, o ne yra trumpas atskiras projektas.
Ar visas senąsias ataskaitas reikėtų sujungti į vieną bendrą Power BI semantinį modelį?
Nebūtinai. Kai programų verslo logika, skaičiavimai ar saugumo reikalavimai iš tiesų skiriasi, palikti jas atskiruose semantiniuose modeliuose ir standartizuoti po jais esantį duomenų sluoksnį dažnai yra saugiau ir mažina migracijos riziką.
Ar Power BI gali visiškai atkurti Qlik asociatyvųjį filtravimą?
Ne automatiškai. Qlik asociatyvusis variklis ryšius tarp duomenų atskleidžia netiesiogiai, o Power BI reikalauja ryšius, filtravimo kryptis ir skaičiavimo kontekstus apibrėžti aiškiai. Atkurti lygiavertę elgseną įmanoma, tačiau tam reikia apgalvoto duomenų modeliavimo, o ne paprasto funkcijų atitikmenų susiejimo.
Kaip tvarkyti nedokumentuotą verslo logiką senojoje BI aplinkoje?
Logikos išsiaiškinimą laikykite suplanuota veikla, kuriai numatytas biudžetas: atvirkštinės inžinerijos būdu išanalizuokite esamas ataskaitas ir skaičiavimus, palyginkite rezultatus su veikiančia senąja sistema ir patikrinkite juos kartu su verslo naudotojais, užuot manę, kad logiką galima suprasti vien iš ataskaitų vaizdo.
Kada BI modernizavimo projekte reikėtų pradėti našumo testavimą?
Dar prieš naudotojų priėmimo testavimą, idealiu atveju – vos tik sukūrus pagrindinius duomenų modelius ir svarbiausius ataskaitų šablonus. Kai kurie sprendimai, kurie senojoje platformoje veikia priimtinai, naujosios platformos ryšių modelyje gerokai sulėtėja, o juos aptikti anksti kur kas pigiau nei po paleidimo.
Ar modernizuojant duomenų platformą reikia kiekvieną ataskaitą kurti iš naujo?
Ne. Atspariausias požiūris atskiria šias dvi užduotis: modernizuojamas duomenų gavimo ir transformavimo sluoksnis (duomenų platforma), o ataskaitų logika ir elgsena, kuria naudotojai jau remiasi, išsaugoma. Platformos modernizavimas ir ataskaitų pertvarkymas nelaikomi tuo pačiu projektu.
