Kolmikerroksinen liiketoiminta-analyysiratkaisu
Lähde: Äri-IT syksy 2022
Teksti: Mihkel Nugis, BCS Itera -liiketoiminta-analyysin konsultti ja kehittäjä
Liiketoiminta-analyysiratkaisujen arkkitehtuuri voi olla hyvin erilainen, ja jokaisella on omat hyvät ja huonot puolensa. Tutustutaan tarkemmin pääasiallisiin vaihtoehtoihin ja katsotaan, miksi juuri kolmikerroksinen ratkaisu on järkevin yrityksissä, joissa liiketoiminta perustuu dataan.
Edellisessä Äri-IT-numerossa selvitimme liiketoiminta-analyysiratkaisun kolmikerroksista arkkitehtuuria. Tuolloin osoitimme, että täysivaltainen liiketoiminta-analyysiratkaisu sisältää seuraavat kerrokset:
- tietokanta
- analyysi
- esitys eli raportointi.
Tietokantakerroksen tehtävänä on kerätä, käsitellä ja tallentaa tietoja.
Analyysikerroksessa tiedoille annetaan liiketoimintalogiikan vaatimukset täyttävä muoto, luodaan suhteet sekä laskelmat ja laaditaan dimensionaalinen tietomalli.
Esityskerros koostuu sovelluksista, joissa loppukäyttäjät tekevät kyselyjä analyysikerrokseen ja laativat raportteja taulukkoina tai kaavioina.
Tiedot käyvät läpi useita vaiheita matkallaan tietolähteistä raportteihin: ne puhdistetaan, standardoidaan ja yhdistetään kokonaisuuteen. Perinteiselle tietoanalyysiratkaisulle on ominaista se, että data liikkuu yhteen suuntaan: se kerätään tietolähteistä tietovarastoon, sen jälkeen prosessoidaan analyysikerroksen taulukot ja lopuksi välitetään tieto raportteina tehtyjen kyselyjen mukaan. Tällaisen tietojenkäsittelyn yleisenä tarkoituksena on taata, että raportit ovat nopeita ja tulokset ymmärrettäviä ja tulkittavia jokaiselle käyttäjälle. Tietojen on tietenkin oltava oikein. Riippumatta siitä, muuttuvatko tiedot jotenkin käsittelyn aikana, lopputulos ei saa antaa vääristynyttä ja epätodellista tulosta.
Kaikkia raportointiratkaisuja ei kuitenkaan ole rakennettu kolmikerroksista rakennetta ajatellen. Katsotaanpa tarkemmin, miksi juuri kolmikerroksinen ratkaisu on suositumpi, ja mitkä ovat kummankin arkkitehtuurin hyvät ja huonot puolet.
YKSIKERROKSINEN RAPORTOINTIARKKITEHTUURI
Se on raportointijärjestelmä, jossa raportit laaditaan suoraan tietolähteen pohjalta. Tämä tarkoittaa, että olemassa on vain raportointikerros, eikä tietovarastoja tai -kuutioita ole.
Tähän kuuluvat kaikki sovelluksen sisäiset raportit. Esimerkkinä voidaan mainita mikä tahansa yrityksessä käytettävä liiketalousohjelmisto. Niissä kaikissa on mahdollisuus laatia raportteja. Tiedot tällaisia raportteja varten kysytään suoraan toiminnallisesta tietokannasta, jossa itse sovellus toimii.
PLUSSAT:
- Raportti on osa ERP-sovellusta eikä ylimääräistä ulkoista ratkaisua tarvita. Käyttäjän ei tarvitse vaihtaa toiseen ympäristöön tarkastellakseen raportteja.
- Raportti kuvastaa senhetkistä tilannetta. Koska kyselyt tehdään suoraan operatiivisesta tietokannasta, on varmaa, että tietojen tila on tuore.
- Erillisiä oikeuksia ei tarvitse määrittää. Käyttäjälle on jo määritetty pääsy tietoihin hänen tehtävällään ja oikeuksillaan ERP-sovelluksessa.
MIINUKSET:
- Jälkianalyysin mahdollisuutta ei ole. Raporttien muoto on ennalta määrätty, eikä käyttäjä voi muuttaa raportin yksityiskohtia tai kenttien valintaa, jos on tarve tutkia raportissa esitettyjä lukuja perusteellisesti.
- Raporttien täydentämiseen tarvitaan IT-tuen apua. Koska raportit on sisäänrakennettu sovellukseen, niiden muuttaminen tai uusien lisääminen vaatii IT-asiantuntijan apua.
- Suuremmat raportit rasittavat operatiivista kantaa. ERP-sovellusten kannat on optimoitu reagoimaan nopeasti pienimuotoisten tapahtumien käsittelyyn. Suuret tietokyselyt voivat viedä koko kannan resurssit ja lamauttaa muiden käyttäjien päivittäisen toiminnan.
Yksi yksikerroksisen ratkaisun muunnelma on sellainen, jossa raportti laaditaan muussa kuin ERP-sovelluksessa, kuten Excelissä. Tällaisessa tapauksessa Excel-kysely kääntyy suoraan operatiivisen tietokannan puoleen. Suosittelemme välttämään tällaista suoraa yhteydenottoa tietolähteenä olevaan kantaan. Silloin syntyy ongelmia tietoihin pääsyn turvaamisessa ja toimintavarmuuden takaamisessa, ja on myös vaikea valvoa, kuka pääsee käsiksi, milloin ja mihin tietoihin.
KAKSIKERROKSINEN RAPORTOINTIARKKITEHTUURI
Kuten nimikin kertoo, kaksikerroksisessa ratkaisussa on edustettuna kaksi kolmesta liiketoimintaratkaisun kerroksesta.
Ensimmäinen vaihtoehto on, että on olemassa analyysi- ja raportointikerros, muttei tietovarastoa. Vastaava raportointi voidaan rakentaa käyttämällä esimerkiksi Excelissä Power Query + Power Pivot -toimintoa tai tietokyselyitä Power BI -tuontimenetelmällä.
Microsoftin Excel- ja Power BI -sovelluksiin on sisäänrakennettu datamallien rakentamismahdollisuus. Käytännössä kyseessä on integroitu ratkaisu, jossa analyysi- ja raportointikerros ovat yhdessä paikassa. Kuvassa 3 on melko yleinen ratkaisu, jossa Power BI -sovelluksella päästään ERP-ratkaisuun API-rajapinnan kautta ja kysytään sieltä tiedot Power BI:hin rakennettuun datamalliin. Tietojen visualisointi raporteiksi tapahtuu samassa Power BI -ympäristössä.
PLUSSAT:
- Raportin laatiminen on edullista ja säästää aikaa sekä resursseja. Excel on useimmille tuttu sovellus, ja myös Power BI:n käyttäjien määrä kasvaa nopeasti. Datamallien laatiminen kyseisissä sovelluksissa saattaa vaatia koulutusta, mutta siitä selviytyäkseen ei tarvitse olla IT-asiantuntija. Tällaisten raporttien laatimisen aloittamiseksi ei myöskään tarvitse tehdä lisäinvestointeja.
- Raportit mahdollistavat jälkianalyysin. Tämä tarkoittaa, että kun joku laatii raportille datamallin, sitä voivat käyttää tietojen jatkoanalysointiin kaikki, jotka tarvitsevat raportointia.
- Raportointia varten laadittavien tietomallien ei tarvitse rajoittua yhteen ERP-sovellukseen. Tietoja voidaan tuoda malliin useista tietolähteistä.
MIINUKSET:
- Keskitettyä tietopolitiikkaa ei ole. Jokainen raportin tekijä laatii oman itsenäisen raportin ja mallin, jossa käytetyt laskentalogiikat voivat poiketa muiden laatimista. Seurauksena on, että puhutaan samasta asiasta, mutta luvut ovat erilaisia.
- Suurempien monivuotisten tietojen lataaminen voi viedä aikaa, eikä se välttämättä aina suju loppuun saakka onnistuneesti.
- API-rajapinnassa valinta on määritetty. Kun dataa luetaan malliin API-rajapinnan kautta, kyselyn tekijän vaihtoehdot rajoittuvat annettuun tietorakenteeseen. Lisätarpeissa on otettava yhteyttä IT-asiantuntijaan.
Toinen kaksikerroksisen arkkitehtuurin vaihtoehto, johon olemme törmänneet, on sellainen, jossa tietovarasto ja raportit ovat edustettuina, mutta analyysikerrosta ei ole.
PLUSSAT:
- Tietovarastossa tiedot on esikäsitelty ja standardoitu. Eri lähteistä kerätyt tiedot on koottu yhteisten nimittäjien alle. Raportin kyselyn tekijän on paljon helpompi koota kysely verrattuna tilanteeseen, jossa kyseessä on raakadata.
- Tietokyselyt eivät rasita alkulähteisiin liittyvien sovellusten toimintaa. Koska tiedot sijaitsevat alkuperäisistä lähteistä erillään olevassa kannassa ja usein myös erillisellä palvelimella, raporttikyselyt eivät vaikuta operatiiviseen työhön. Tietovaraston täyttäminen tuoreilla tiedoilla tapahtuu työajan ulkopuolella.
- Raporttien käyttäjillä ei tarvitse olla käyttöoikeutta alkuperäisiin sovelluksiin. Jos yrityksen työntekijä tarvitsee vain raportoinnin, ei tarvita ylimääräisiä kulutuksia esimerkiksi ERP-sovelluslisenssin hankkimiseksi.
MIINUKSET:
- Tietovaraston tiedot eivät kuvasta viime hetken tilaa. Koska tietovarasto päivittyy yleensä kerran vuorokaudessa, raportin tekijä näkee tiedot päivittäisellä viitteellä.
- Monimutkaisemmat tiedustelut vievät paljon aikaa. Laskennallisesti suuret kyselyt ovat hitaita, sillä niiden on käsiteltävä suuri määrä tietoa kyselyn aikana.
KOLMIKERROKSINEN LIIKETOIMINTA-ANALYYSIN ARKKITEHTUURI
Se, että monimutkaiset ja suuret kyselyt, jotka sisältävät dataa usealta vuodelta, ovat joskus hitaita, on tärkein syy siihen, miksi meidän on otettava käyttöön analyysikerros tietovaraston lisäksi.
Analyysikerros voi olla taulukkodatamallilla varustettu analyysipalvelu, joka, kuten jo mainittiin, sisältyy Power BI:hin ja Exceliin tai joka voidaan toteuttaa Microsoft SQL -analyysipalveluympäristössä. Aiemmissa toteutuksissa oli laajalti käytössä moniulotteinen tietomalli, mutta viime aikoina se on yhä useammin korvattu uudemmalla ja suositummalla taulukkomallilla.
Miksi analyysikerros on niin paljon nopeampi vastaamaan raporttikyselyihin verrattuna siihen, jos kyselyt tehdään suoraan tietovarastoon? Syynä on tekniikka, jolla data on järjestetty analyysikerroksen tietomallissa. Se on rakennettu siten, että se takaa nopeat vastaukset kyselyihin myös datamäärien ollessa suuria.
Olemme nähneet raportteja, joiden kyselyn tekeminen suoraan tietovaraston kannasta kesti 5–10 minuuttia. Siitä, onko se paljon vai vähän, voidaan olla eri mieltä. Verrattuna manuaaliseen raportin laatimiseen, joka voi kestää tunteja tai jopa päiviä, tällainen odotus on hyväksyttävä. Jos käyttäjän on kuitenkin analysoitava dataa ja vaihdettava usein aikasuodattimia tai muutettava näkymän yksityiskohtia ja raportin rakennetta, jopa muutaman minuutin odottaminen jokaisen liikkeen jälkeen on melko epämiellyttävää. Analyysikerroksen lisääminen tällaisiin kyselyihin tarkoittaa, että vaikka vastaukset eivät saapuisikaan heti, ne tulevat varmasti sekunneissa minuuttien sijaan.
Jos halutaan rakentaa liiketoiminta-analyysiratkaisu, joka kykenisi keräämään dataa useista lähteistä, olisi saatavana raportointia varten laajalle työntekijäpiirille ja varmistaisi nopean, toimintavarman ja johdonmukaisen raportoinnin, on seurattava maailmalla tunnustettuja menetelmiä ja vakiintuneita käytäntöjä.
Kolmikerroksinen liiketoiminta-analyysiratkaisun arkkitehtuuri on juuri sellainen, jota uskallamme suositella.