Kolmekihiline ärianalüüsi lahendus

Allikas: Äri-IT Sügis 2022

Autor: Mihkel Nugis, BCS Itera ärianalüüsi konsultant-arendaja

Ärianalüüsi lahenduste arhitektuur võib olla väga erinev, igaühel oma  plussid-miinused. Tutvume peamiste variantidega lähemalt ning vaatame, miks ettevõtetes, kus äri põhineb andmetel, on kõige mõistlikum just kolmekihiline lahendus.

Eelmises Äri-IT numbris selgitasime ärianalüüsi lahenduse kolmekihilist arhitektuuri. Osutasime toona, et täisväärtuslik ärianalüüsi lahendus sisaldab järgmisi kihte:

• andmebaasi,
• analüüsi,
• esitluse ehk aruandluse kiht.

Andmebaasi kihi ülesanne on andmeid koguda, töödelda ja talletada.

Analüüsi kihis antakse andmetele äriloogika nõuetele vastav kuju, luuakse seosed ja arvutused ning koostatakse dimensiooniline andmemudel.

Esitluse kiht koosneb rakendustest, kus lõppkasutajad loovad päringuid analüüsikihile ja koostavad aruandeid tabelina või graafikutena.

Joonis 1. Kolmekihilises ärianalüüsi lahenduses liiguvad andmed ühes suunas, andmeallikast aruannete kihi poole.

Andmed läbivad teekonnal andmeallikatest aruanneteni mitu etappi: need puhastatakse, standardiseeritakse ja ühendatakse tervikuga. Klassikalise andmeanalüüsi lahendusele on iseloomulik, et andmed liiguvad ühes suunas: andmeallikatest kogutakse need andmelattu, seejärel protsessitakse analüüsikihi tabelid ja lõpuks antakse info edasi aruannetena vastavalt tehtud päringutele. Sellise andmetöötluse üldine eesmärk on tagada, et aruanded oleksid kiired ja tulemused igale kasutajale arusaadavad ning tõlgendatavad. Muidugi peavad olema andmed õiged. Ükskõik, mil moel andmed protsessimise käigus ka ei transformeeru, ei tohi lõpptulemus anda moondunud ja reaalsusele mittevastavat tulemust.

Sugugi mitte kõik aruandluse lahendused pole aga üles ehitatud kolmekihilist struktuuri silmas pidades. Vaatame lähemalt, miks on just kolmekihiline lahendus eelistatud ja mis on ühe või teise arhitektuuri miinused ja plussid.

Ühekihiline aruandluse arhitektuur

See on aruandluse süsteem, kus aruanded koostatakse otse andmeallika põhjal. See tähendab, et esineb ainult aruandluse kiht, aga puuduvad nii andmeladu kui ka -kuubid.

Siia alla käivad kõik rakendusesisesed aruanded. Näitena võib tuua iga majandustarkavara, mida kasutatakse ettevõttes. Kõigis neis sisaldub võimalus koostada aruandeid. Andmed selliste aruannete jaoks päritakse otse operatiivsest andmebaasist, mille peal rakendus ise töötab.

Joonis 2. Integreeritud aruannete korral võetakse andmed otse rakenduse andmebaasist.

Plussid:

• Aruanne on ERP rakenduse koosseisus ja vaja ekstra välist lahendust. Kasutaja ei pea aruannete vaatamiseks ümber lülituma mõnda teise keskkonda.
• Aruanne kajastab hetkeseisu. Kuna päringud toimuvad otse operatiivbaasist, on tagatud, et andmete seis on kõige värskem.
• Ei vaja eraldi õiguste seadistamist. Kasutajale on andmetele ligipääs juba määratud tema rolli ja õigustega ERP rakenduses.

Miinused:

• Puudub järelanalüüsi võimalus. Aruannete vorm on ette määratud, kasutajal ei ole võimalik muuta aruande detailsust ega väljade valikut, kui tekib vajadus aruandega esitatud numbreid süvitsi uurida.
• Aruannete täiendamine vajab IT-toe abi. Kuna aruanded on rakendusse sisse ehitatud, siis nende muutmine või uute e lisamine vajab IT-spetsialisti abi.
• Mahukamad aruanded koormavad operatiivbaasi. ERP rakenduse baasid on optimeeritud nii, et need reageeriksid kiiresti väikesemahuliste transaktsioonide töötlemiseks. Suuremahulised andmepäringud võivad kogu baasi ressursid hõivata, halvates teiste kasutajate igapäevased operatsioonid.

Üks variatsioon ühekihilisest lahendusest on selline, kus aruanne koostatakse ERP-välises rakenduses, näiteks Excelis. Sellisel juhul pöördub Exceli päring otse operatiivbaasi poole. Soovitame vältida sellist otsepöördumist andmeallikaks oleva baasi poole. Siin tekib probleeme andmetele ligipääsu turvamise ja töökindluse tagamisega, samuti on keeruline kontrollida, kes millal ja millistele andmetele ligi pääseb.

Kahekihiline aruandluse arhitektuur

Nagu nimetuski ütleb, on kahekihilises lahenduses esindatud kaks osa kolmest ärilahenduse kihist.

Esimene variant on selline, et on olemas analüüsi ja aruandluse kiht, aga puudub andmeladu. Sarnast aruandlust saab ehitada, kui kasutada näiteks Excelis Power Query + Power Pivot funktsionaalsust või Power BI importmeetodil andmete päringuid.

Joonis 3. Kahekihilise aruandluse lahenduses loetakse andmed otse andmeallika rakendusest analüüsi andmemudelisse.

Microsofti rakendustesse Excel ja Power BI on sisse ehitatud andmemudelite ehitamise võimalus. Sisuliselt on tegu on integreeritud lahendusega, kus analüüsi ja aruandluse kiht on ühes kohas koos. Joonisel 3 on kujutatud üsna tavapärane lahendus, kus Power BI rakendusega pöördutakse ERP lahenduse poole API liidestuse kaudu ja päritakse andmed sealt Power BI-sse ehitatud andmemudelisse. Andmete aruanneteks visualiseerimine käib samas Power BI keskkonnas.

Plussid:

• Aruandluse koostamine on jõukohane ning aja- ja ressursisäästlik. Excel on enamikule tuttav rakendus ja ka Power BI kasutajate arv kasvab kiiresti. Nendes rakendustes andmemudelite koostamine vajab ehk mõningast väljaõpet, kuid ei pea olema IT-spetsialist, et sellega hakkama saada. Samuti pole vaja teha lisainvesteeringuid, et selliseid aruandeid koostama hakata.
• Aruanded võimaldavad järelanalüüsi. See tähendab, et kui  keegi teeb aruande jaoks andmemudeli valmis, saavad seda kasutada andmete edasiseks analüüsimiseks t kõik, kellele on aruandlus vajalik.
• Aruannete jaoks koostatavad andmemudelid ei pea piirduma ühe ERP rakendusega. Andmeid saab mudelisse importida mitmest andmeallikast.

Miinused:

• Puudub keskne andmepoliitika. Iga aruande koostaja teeb oma iseseisva aruande koos mudeliga, milles esinevad arvutusloogikad võivad erineda teiste omadest. Tagajärg on see, et räägitakse küll samast asjast, aga numbrid on erinevad.
• Mahukamate mitmeaastaste andmete laadimine võib olla ajakulukas ja ei pruugi alati õnnestunult lõpuni kulgeda.
• API liides on fikseeritud valikuga. Kui andmeid loetakse mudelisse API liidese kaudu, on päringu tegija valik piiratud etteantud andmete struktuuriga. Lisavajaduste puhul peab pöörduma IT-spetsialisti poole.

Kahekihilise arhitektuuri teine variant, mida oleme kohanud, on selline, kus on esindatud andmeladu ja aruanded, aga puudub analüüsi kiht.

Joonis 4. Kahekihilise arhitektuuri näitena lahendus, kus Excelisse ehitatud päringud pöörduvad andmelao tabelite poole.

Plussid:

• Andmelaos on andmed eeltöödeldud ja standardiseeritud. Eri allikatest kogutud andmed on viidud ühiste nimetajate alla. Aruande päringu koostajal on palju lihtsam päringut kokku panna võrreldes olukorraga, kui need oleksid toorandmed.
• Andmepäringud ei koorma algallikatega seotud rakenduste tööd. Kuna andmed asuvad algallikatest eraldi baasis ja tihti ka eraldi serveris, siis ei mõjuta aruannete päringud operatiivtööd. Andmelao täitmine värskete andmetega toimub töövälisel ajal.
• Aruannete kasutajatel ei pea olema kasutusõigust algrakendustele. Kui ettevõtte töötajal on vaja ainult aruandlust, siis ei pea tegema lisakulutusi näiteks ERP rakenduse litsentsi soetamiseks.

Miinused:

• Andmelao andmed ei kajasta viimase hetke seisu. Kuna andmeladu uuendatakse tavaliselt kord ööpäevas, siis näeb aruande tegija andmeid päevase viitega.
• Keerulisemad päringud võtavad palju aega. Arvutusmahukad päringud on aeglased, sest peavad töötlema suurt kogust andmeid päringu ajal.

Kolmekihiline ärianalüüsi arhitektuur

See, et keerulised ja mahukad päringud, mis kaasavad mitme aasta ulatuses andmeid, on teinekord aeglased, ongi peamine põhjus, miks meil on vaja lisaks andmelaole juurutada analüüsi kiht.

Analüüsi kihiks võib olla tabellaarse andmemudeliga analüüsi teenus, mis, nagu juba mainitud, sisaldub Power BI ja Exceli koosseisus või mida saab realiseerida Microsofti SQL-analüüsi teenuse keskkonnas. Varasemates juurutustes oli laialt kasutusel mitmedimensiooniline andmemudel, aga viimasel ajal vahetatakse see üha enam välja uuema ja populaarsema tabellaarse mudeliga.

Miks analüüsi kiht nii palju kiirem, vastates aruande päringutele, võrreldes sellega, kui päringud tehakse otse andmelattu? Põhjus on tehnoloogias, kuidas andmed analüüsikihi andmemudelis on organiseeritud. See on üles ehitatud nii, et tagada kiired vastused päringutele ka suuremahuliste andmete korral.

Oleme näinud aruandeid, mille päringud otse andmelao baasist võtsid aega 5 kuni 10 minutit. Võib vaielda, kas seda on palju või vähe. Kui võrrelda käsitsi aruande kokkupanemisega, mis võib võtta tunde või isegi päevi, siis on selline ootamine ju vastuvõetav. Kui aga kasutajal on vaja andmeid analüüsida ja tihti vahetada ajalisi filtreid või muuta vaate detailsust ning aruande struktuuri, siis on isegi mõneminutiline ootamine iga liigutuse järel üsna ebameeldiv. Analüüsi kihi lisamine sellistele päringutele tähendab, et kui ka vastused ei laeku hetkega, siis tulevad need minutite asemel kindlasti sekunditega.

Kui on soov ehitada üles ärianalüüsi lahendus, mis oleks võimeline koondama andmeid paljudest allikatest, oleks aruandluseks kättesaadav laiale töötajate ringile ja tagaks kiire, töökindla ja järjepideva aruandluse, siis tuleb järgida maailmas tunnustatud meetodikaid ja kinnistunud tavasid.

Kolmekihiline ärianalüüsi lahenduse arhitektuur on just selline, mida julgeme soovitada.