SAP:n toiminnanohjausratkaisut ovat erittäin suosittuja etenkin suurissa ja keskisuurissa organisaatioissa. Suurin osa Suomenkin suurimmista organisaatioista hyödyntää yhtä tai useampaa SAP:n järjestelmää operaatioidensa hallitsemiseen ja ohjaamiseen. Globaalin toiminnanohjauksen markkinajohtajan tämänhetkinen lippulaivatuote on SAP S/4HANA ja sen pilviversiot. Tämä tietenkin tarkoittaa myös sitä, että useassa data- ja analytiikkapuolen hankkeessa eteen tulee tilanne, jossa SAP-järjestelmä toimii keskeisenä lähdejärjestelmänä ja tällöin on ratkaistava, miten SAP:n data saadaan järkevimmällä tavalla integroitua uuteen, tai jo käytössä olleeseen data-alustaan.
Äkkiseltään kuvio voi kuulostaa yksinkertaiselta, eihän SAP ole kuin yksi lähdejärjestelmä muiden joukossa. Siis ladataan datat ja ruvetaan hommiin, eikö niin? Asia harvoin on kuitenkaan näin yksinkertainen, koska SAP-järjestelmät, erityisesti SAP ECC ja S/4HANA, tuovat mukanaan lukuisia erilaisia etenemisvaihtoehtoja, joiden pyörteistä tulee löytää kullekin organisaatiolle se kaikkein paras ja arktista kirkkautta ilmentävä ratkaisu.
Monimutkaiseen yhtälöön sekoittuu SAP-järjestelmien erityispiirteet, versiot, lisensointiehdot, tietokantavalinnat (DB2, SQL Server, Oracle, SAP HANA), SAP BW:n olemassaolo, kolmannen osapuolen SAP-integrointityökalut, kuten Aecorsoft ja Theobald, sekä tietenkin kehittäjän SAP-tietomallien ja -prosessien tuntemus. Kaiken lisäksi usein sopassa omia kauhojaan heiluttelemassa on niin organisaation oma SAP-tiimi näkemyksineen, SAP suosituksineen, kuin tietenkin myös valitun kumppanin osaajat.
Raakadatalla on valtava arvo
Usein törmää SAP-integraatioratkaisuihin, joissa SAP:n dataa haetaan esimerkiksi data extractoreilla, queryjen tai CDS-näkymien kautta, lukemalla functional moduleja tai monimutkaisella SQL-lausekkeilla. Kaikkia näitä tapoja yhdistää se, että dataa haettaessa poimitaan tietoja, joita tarvitaan tiettyyn raportointitarpeeseen. Taustalla on siis jo logiikkaa dataa haettaessa.
Edellä kuvattu tapa aiheuttaa sen, ettei data-alustalla tai tietovarastossa ole SAP:n raakadataa ja esimerkiksi järjestelmän vaihtuessa raakadata häviää vanhan järjestelmän poistuessa. Jos organisaatio haluaakin myöhemmin tehdä edistyneitä analytiikkaratkaisuja ja hyödyntää siinä vanhaa dataa, se ei ole enää mahdollista, koska meillä on käytössä pelkästään jo tietyn logiikan perusteella poimittua ja pahimmassa tapauksessa aggregoitua dataa. Toisin sanoen, on äärimmäisen kriittistä lähestymistavasta riippumatta siirtää data-alustalle SAP:n raakadata sellaisenaan. Käytännössä tämä tarkoittaa SAP:n tietomallin taulujen siirtämistä. Näin mahdollistamme tulevaisuuden kestävän ratkaisun, jossa kaikki raakadata on tulevaisuudessa tallessa uusia käyttötapauksia varten, riippumatta siitä, onko järjestelmät vaihtuneet vai eivät.
Älä aja lisensointimiinaan
SAP:n lisensointimaailma ei välttämättä näyttäydy selkeänä, jos asiaan ei ole perehtynyt eikä omaa pitkää kokemusta aiheen tiimoilta. Huomioitavia asioita on lukuisia, joista tärkeimpänä SAP ECC/SAP BW-ympäristöissä ns. ”Open Hub”-lisenssi, joka rajaa integraatiomahdollisuuksia kolmansien osapuolien järjestelmiin, sekä S/4HANA-maailmassa valittu HANA-lisenssi, muutamia mainitakseni. Mielenkiintoisuutta aiheeseen tuo se, että riippumatta lisensseistä, asiat voi olla teknisesti mahdollista toteuttaa, vaikka lisenssi ei sitä sallisikaan. Harva haluaa törmätä asiaan SAP:n lisenssiauditoinnissa ja maksaa korvauksia lisenssiehtojen rikkomisesta, joten suosittelen että asiaan perehdytään kunnolla etukäteen, jotta tiedetään tarkkaan mihin ollaan ryhtymässä.
Yksinkertainen on kaunista
Jos se vain suinkin on vaihtoehto, niin Isletillä suosittelemme usein mahdollisimman yksinkertaisia ratkaisuja. Mitä vähemmän liikkuvia osia, sitä vähemmän on nimittäin myös kohtia, joissa jokin voi mennä pieleen. Jokainen kerros, komponentti ja työkalu lisää kustannuksia, vaatii erityisosaamista, hidastaa kehitystä ja lisää potentiaalisia ongelmia.
Pysähdy hetkeksi ja mieti hyvin tyypillistä ratkaisua, jossa data haetaan SAP S/4HANA -toiminnanohjausratkaisusta extractorien ja/tai functional modulien kautta SAP BW:hen. SAP BW:ssä dataa hierotaan eteenpäin eri kerrosten lävitse DSO/ADSO:ta hyödyntäen, tehdään CompositeProvider (virtuaalinen datamartti) ja sen päälle ehkä vielä Query. Querystä datat luetaan raportointi- ja visualisointityökalun tietomalliin SAP-connectorilla, sanotaan nyt vaikka esimerkkinä QlikView. QlikViewissä tiedot tallennetaan esim. QVD-formaattiin ja lopulta luetaan muistinvaraiseen moottoriin, jonka päälle rakennetaan visuaalinen kerros.
Leikitään vielä, että tämä organisaatio on lähtenyt rakentamaan Microsoft Azureen uutta data-alustaa ja edellä kuvattu QlikView-kuvio korvataankin sillä, että tiedot siirretään SAP BW:stä Azuren data lakeen tai suoraan johonkin relaatiotietokantaan Theobald-ohjelmistolla. Azuressa dataa muokataan Azure Data Factoryllä, businesslogiikkaa luodaan ja lopulta datat tarjotaan visualisointityökaluun, sanotaan nyt vaikka Tableauhun, jossa tiedot luetaan muistinvaraiseen moottoriin datamalliin ja sieltä se luetaan erilaisiin visuaalisiin komponentteihin.
Lopputuloksena on ratkaisu, jossa liiketoiminnalle tarjotaan erilaisia moderneja visuaalisia analytiikkaratkaisuja. Kaikki on tyytyväisiä, hienoa! Liiketoiminta saa mitä haluaa ja meillä on järkevä kokonaisarkkitehtuuri? Vai herättikö tämä skenaario sittenkin muunlaisia ajatuksia sinussa?
Pitkällä kokemuksella uskaltaa jo sanoa, ett tämä ei pääsääntöisesti olisi järkevää. Jos lähdetään liikkeelle erottelemalla, kuinka montaa eri osaamisaluetta tai osaajaa tähän edellämainitun skenaarion toteuttamiseen tarvitaan: SAP-järjestelmäosaaja, joka tekee functional modulit ja/tai muokkaa extractoreita jne., SAP BW -osaaja, joka lataa tiedot ja hieroo sitä SAP BW:n sisällä, Theobald-osaaja, joka siirtää tiedot Azureen, Azure-osaaja tai mahdollisesti useampi, joka mallintaa, suunnittelee ja rakentaa tietovarastoa Azuren sisällä, minkä lisäksi vielä Tableau-osaaja, joka rakentaa tietomallin, laskennat ja visualisoinnit. Melko monta kohtaa, joissa tiedon siirto voi mennä vikaan, ja jossa sovelletaan businesslogiikkaa.
Vaikka osa edellä kuvatusta teknisestä hutusta olisi mennyt ohitse, voit varmasti uskoa, että yhteen tauluun yhden lisäkentän lisääminen ja yhden lisätaulun luominen yhtä esille tullutta liiketoimintatarvetta varten vie kauan, siihen tarvitaan useita eri osaajia ja se maksaa todella paljon suhteessa saavutettuihin tuloksiin.
Valitettavasti tämä ei ole edes erityisen harvinainen, vaan päin vastoin hyvin tyypillinen skenaario. On nähty hurjempiakin, esimerkiksi tapaus, jossa lähes sama arkkitehtuuri on jatkettu niin että QlikViewistä datat exportataan CSV-tiedostona levyn kulmalle ja luetaan sieltä Power BI:hin. Todella hurjaa ja usein täysin tarpeetonta.
Minkä me tämän sijaan sitten näemme paremmaksi lähestymistavaksi ja mihin omassa toiminnassamme nojaamme kuin vahvaan peruskallioon? Aina kannattaa tavoitella yksinkertaisuutta ja pyrkiä eroon kaikista arkkitehtuurin kerroksista ja komponenteista, jotka eivät tuo ratkaisuun lisäarvoa. Aina tulisi miettiä myös tulevaisuutta ja kokonaiskuvaa, ei pelkästään käsillä olevaa yksittäistä liiketoimintatarvetta.
Jos hankittuna on SAP S/4HANA:n HANA-tietokannalle Enterprise-lisenssi, koko aikaisemmin esimerkkinä kuvatun kokonaisuuden voisi toteuttaa seuraavasti: Ladataan SAP-taulujen data sellaisenaan Microsoft Azuren Azure Data Lakeen Azure Data Factoryn avulla, toteutetaan tietovarasto relaatiotietokannan (esim. SQL Database, SQL Dedicated pool tai Snowflake) päälle tai Lake Database -konseptilla hyödyntäen SQL Serverless -poolia. Tähän päälle esimerkiksi Power BI, jonka tietomallissa on laskennat tehtynä ja siitä visualisoinnit loppukäyttäjille. Jos organisaatiolla ei ole Enterprise-lisenssiä vaan Runtime-lisenssi, hankitaan esimerkiksi Aecorsoft Data Integrator, joka lukee SAP-taulujen tiedot sovellusrajapinnan kautta ja kirjoittaa ne suoraan Azure Data Lakeen.
Luota kokemukseen ja näkemykseen
Isletillä on yli 20 vuoden vankka kokemus eri SAP-järjestelmistä ja olemme viime vuosina luoneet lukuisia menestystarinoita konvertoimalla asiakkaidemme SAP-järjestelmiä S/4HANA-maailmaan, siirtämällä ja operoimalla niitä Microsoft Azure -julkipilvessä, sekä tietenkin tarjoamalla Suomen kovinta osaamista eri osa-alueille. Data ja analytiikka -tiimin asiantuntijoilla on kymmenien vuosien kokemus erilaisista SAP-integraatioista, sisältäen kaikki SAP:n tarjoamat standardit rajapinnat, SAP BW:n, tietojen haun suoraan SAP:n tietokannasta, sekä tietenkin johtavat kolmannen osapuolen integraatio-ohjelmistot.
Isletissä yhdistyvätkin erittäin vahva prosessiosaaminen, koodaus- ja SAP Basis osaaminen, sekä uniikki yhdistelmä tietotaitoa erilaisista SAP-integraatioista ja modernien data-alustojen luomisesta SAP-datan pohjalta. Vaikka Isletin data- ja analytiikkatiimi ei suinkaan auta pelkästään SAP:ia käyttäviä organisaatioita, se on ehdottomasti yksi erityisosaamisalueistamme. Pitkän ja kattavan kokemuksemme pohjalta pystymme auttamaan asiakkaitamme muodostamaan järkeviä, tulevaisuuden kestäviä ja tietenkin kustannustehokkaita ratkaisuja.
Onko teidän organisaatiossanne SAP käytössä ja kaipaisitte sparrausta? Onko edessä uuden data-alustan luominen, mutta ette ole varmoja mikä on järkevä tapa toteuttaa integraatiot? Yskivätkö nykyiset integraatiot ja hyvät neuvot olisivat tarpeen? Ota rohkeasti yhteyttä, saaristolaisen tyyneydellä autamme hahmottamaan tilanteenne ja tarpeenne ja navigoimaan oikealle reitille.
#IsletGroup #data #analytiikka #SAP #integraatiot #SAPdata #raportointi #tietojohtaminen #tietoalusta #arkkitehtuuri