Ota CRM – sovelluksen data hyötykäyttöön

Olemme aiemmin kirjoittaneet yrityksen CRM:n datan hyödyntämisestä, pääpaino silloin oli suorat yhteydet esimerkiksi Power BI:n avulla organisaation D365 ympäristöön.

Mutta kaikille organisaatioille tämä ei ole riittävää, vaan vaaditaan datan yhdistämistä eri sovellusten olemassa olevien datojen kanssa. Tällöin käytännössä tarvitaan tietovarastoinnin tekniikoita.

Tässä esimerkkitapauksessa oletamme, että organisaatiolla on on-premises mallilla rakennettu tietovarasto tai oikeammin data mart ja sillä on käytössään ETL – teknologia dataintegraatioihin.

Toisessa osassa kerromme hieman miten vastaava datan ottaminen hyötykäyttöön tapahtuisi, jos käytössä olisi monipuoliset Microsoft Azure – ympäristön palvelut.

 

Esimerkki energia-alalta

Energiayhtiö Oy käyttää perusjärjestelmänään energia-alalle tyypillisen lyhenteen mukaisesti ison toimittajan CIS – sovellusta, mikä viittaa sanaan Customer Information System. Tämä systeemi hoitaa laskutuksen ja sopimusten hallinnan prosesseihin liittyviä asioita.

Yhtiö on myös hankkinut liiketoiminnan johtamista varten data martin, josta voi nähdä sopimuskannan tilanteen sekä laskutukseen liittyviä asioita. Näillä tiedoilla ajateltiin aluksi pystyvän johtamaan liiketoimintaa.

 

Kohta havaitaan, että yrityksen myyntitiimit ovat ottaneet käyttöön SaaS – sovelluksen, joilla he hoitavat myyntiprosessia eikä oikein mistään aiemmasta perusjärjestelmästä näe mitä myyntiprosessissa kokonaisuutena tapahtuu. Kun liiketoimintajohto kuitenkin haluaa näkyvyyttä myynnin tilaan, niin päätetään integroida CRM – data osaksi data mart – ratkaisua ja edellinen tietomalli täydennetään myyntimahdollisuudella sekä liidien tiedoilla (Opportunity, Lead).

 

Tietomallin täydentämisen sekä data martin taulujen lisäksi tarvitaan myös dataa.

 

Kingswaysoft D365 Integration Pack for SSIS

 Pilvessä olevan datan voi ottaa hyötykäyttöön tietovarastoinnissa käyttämällä esimerkiksi SQL Server Integration Services – ohjelmistoa, johon hankitaan sopiva laajennus helpottamaan datan poimintaan SaaS – palvelusta.

Ready Solutions Oy:n konsultit ovat testanneet perinteisen on-premises tietovarastoinnin osalta Kingswaysoft – nimisen toimijan tuotetta, joka vaikuttaa lupaavalta. On tietysti olemassa myös muita vaihtoehtoja, kuten jonkinlainen replikaatiomekanismi. Mutta SaaS – sovellusten tapauksessa rajapintojen suora hyödyntäminenkin on pidettävä yhtenä tärkeimmistä integraatioiden toteutusmuodoista.

Miten CRM:n data integroidaan tietovarastoon? Yksinkertainen tapa on luoda SSIS – sovellus, joka siirtää datan staging – alueelle tietovarastoon ja lataa sen jälkeen datat kohdetauluihinsa.

SSIS – sovelluksen voi laittaa käyttämään jotain valmista teknistä O365 – sovellustunnusta, jolle on annettu D365:n puolella sopiva security role datan poimintaa varten.

Loppuosa latauksesta on kohtuullisen yksinkertaista komponenttien siirtelyä paikalleen data flow – taskin sisällä sekä haluttujen kenttien poimimista.

Staging taulusta data ladataan ensin kaikkiin dimensiotauluihin, jotka sitä lähdettä hyödyntävät ja sen jälkeen faktatauluun / faktatauluihin.

 

              Haluatko ottaa D365 datasi käyttöön        liiketoimintaraportoinnissasi?

Ready Solutions Oy:n konsulttitiimi auttaa mielellään ja selvittää parhaan ratkaisun, ota rohkeasti yhteyttä!

Asko.kauppinen@readysolutions.fi

Jonne.poutiainen@readysolutions.fi

+358451374850

Kirjoitamme myös seuraavan osan datan ottamisesta käyttöön, seuraa meitä eri sosiaalisissa medioissa ja käy sivuillamme jos haluat tietää lisää!

Onko koskaan syytä käyttää peräkkäistiedostoja?

Vanhat järjestelmät ja mutkikas liiketoimintalogiikka

Ready Solutions Oy:n Johtava konsultti Jonne Poutiainen kirjoitti aiemmin kokemuksiaan dataintegraatioista. Jatkan hieman samalla teemalla ja käsittelen yhtä erikoispiirrettä, joita joidenkin pitkään toimineiden organisaatioiden liiketoimintaan liittyy.

Tiedostot integraatiotyyppinä

Tiedostoja on käytetty integraatiotyyppinä (integration pattern) todella pitkään. Kyse on asynkronisesta integraatiosta, sillä useimmissa tapauksissa ei voida olettaa lähettävän tai vastaanottavan prosessin pystyvän suoraan jatkumaan kun tällainen integraatio on toteutettu. Jos halutaan reaaliaikaisia vasteita kutsulle prosessista toiseen, niin tarvitaan muita tapoja toteuttaa integraatio.

Lisäksi täytyy ajatella taustalla olevan liiketoimintaprosessin luonnetta, esimerkiksi laskutus on usein eräpohjainen ja tietyyn ajankohtaan liittyvä prosessi jossa transaktioita tapahtuu paljon. Tuollaisessa tilanteessa yhdistelmä eräajoa ja tiedostoja on kovin luonteva, vaikka ei enää ainoa vaihtoehto.

 

Vanha liiketoimintalogiikka ja toteutus

Aiemman konsultin kokemukseni mukaan rahoitus- ja vakuutusalalla käytetään runsaasti teknologioita, joiden kypsyystaso saavutettiin jo vuosikymmeniä sitten. Näiden usein organisaatioille räätälöityjen järjestelmien korvaaminen on kallista.

Pelkästään organisaation tiedon hallinan tarpeita varten ei toteuteta kalliita muutoksia, vaan niiden muutosten ajurit ovat muita syitä.

Liiketoimintavastuut

Jossain tilanteissa perusjärjestelmien tuottaman datan tuottaa prosessi, jonka ominaisuuksista voi olla ulkpuolisen vaikea päästä perille kohtuullisessa ajassa. Jopa saman organisaation sisällä voi olla järkevämpää että dataa hyödyntävät tahot saavat sen käyttöönsä tiedoston kautta eikä välttämättä suorilla tietokantakyselyillä.

 

Kehittäjälle

Todennäköisesti erilaiset tiedostointegraatiot tulevat olemaan keskuudessamme vielä pitkään, varaudu siis siihen että niitä joudut toteuttamaan sekä käyttämään lähteinä.

 

Dataintegraation yleisimmät ongelmat

Dataintegraatio projektit voivat olla varsin suuria investointeja ja työ ei yleensä pääty alkuperäisen projektin jälkeen. Uusia järjestelmiä rakennetaan ja liiketoiminta esittää uusia vaatimuksia, jotka tarkoittavat uusien dataintegraatioiden rakentamista. Tässä rakennustyössä täytyy olla tarkkana, muuten yritys voi huomata että rakennettu systeemi vaatii alati kasvavan ylläpitotiimin jotta dataintegraatioprosessit pysyvät pystyssä. ITssä on kyse automaatiosta, ja jatkuva manuaalinen työ voi viedä elinvoiman järjestelmien loppukäyttäjiltä.

Mitkä ovat suurimmat ongelmat ja kuinka ne voi välttää?

Flat-tiedostot (Flat Files)

Flat-tiedostoja käytetään usein dataintegraatiossa, ja usein ne ovat ongelmien pääsyyllinen. Jaan tässä nämä tiedostot kahteen ryhmään:

  • automaattisesti generoidut tiedostot
  • excel-tyyppiset tiedostot, joita käyttäjät päivittävät suoraan.

Automaattisesti generoidut Flat-tiedostot

Yleinen ongelma on että tiedosto ei saapunut oikeaan aikaan. Paras ratkaisu tähän ongelmaan on tiedoston generoivan prosessin linkkaaminen sitä vastaanottavaan (lukevaan) päähän. Jos tämä ei ole mahdollista, jää vaihtoehdoksi lisätä lukevan prosessin joustavuutta niin että se pystyy odottamaan tiedoston saapumista ja vasta luettuaan tiedoston käynnistämään sen jälkeen tulevat integraatioprosessit. Vaikka tämä kuulostaa ilmiselvältä, liian usein dataintegraatioita rakennetaan
oletuksella että tiedosto saapuu tasan tietyllä kellonlyömällä, ja epäonnistumisen jälkeen kukaan ei ota vastuuta huonosti toimivasta prosessista.

Toinen yleinen ongelma on että tiedosto ei ole oikeassa formaatissa. Tyypillisesti formaatin on rikkonut muutama rivi, joista löytyy tiedoston tulkitsemislogiikan käyttämiä erikoismerkkejä väärästä paikasta (esim. rivinvaihto tai sarake-erotin). Nämä on sellaisia asioita jotka tiedoston generoivan prosessin pitäisi aina tarkastaa, erityisesti sellaisten kenttien osalta joissa alkuperäinen inputti on tullut avoin tekstikenttä-tyyppisestä syötöstä. Tiedoston generoivan prosessin tulee tarkastaa onko edellämainittuja erikoismerkkejä väärissä paikoissa ja poistaa ne. Tapauksesta
riippuen myös lukevassa päässä voi olla joustavuutta niin että se selviää muutamasta ’huonosta’ rivistä.

Flat-fileet joita käyttäjät päivittävät suoraan (esim. excelit)

Tämä onkin vaikeampi kategoria, ja en oikeastaan suosittelisi tällaista käyttämään ollenkaan sillä näiden muokkaamisessa tuntuu tulevan virheitä joka toisella kerralla. Ja vaikka tiedostoa muokkaava henkilö olisikin hyvin tarkka työssään, voi olla että hän jossain vaiheessa siirtyy muuhun työpaikkaan tai tehtäviin, ja seuraavaksi exceliin arvoja syöttävä henkilö ei onnistukkaan yhtä hyvin. Tämän tyyppisen tiedon syöttämisen tulisi tapahtua sellaisen systeemin läpi joka jo syöttövaiheessa tarkastaa tietotyyppien oikeellisuuden ja mahdollisesti myös arvojen oikeellisuuden.

Tietokannat

Tietokannoista lukemisessa on huomattavasti vähemmän ongelmia. Mutta toki silloin tällöin yhteys voi pätkäistä tai luettava tietokanta on muuten kiireinen (lukossa). Ongelmaa voi helpottaa asettamalla dataa lukevan prosessin yrittämään uudestaan, jos ensimmäinen kerta epäonnistui. Toki jos luettava tai kohde -tietokanta on jatkuvasti hidas tai lukossa, on tutkittava mikä tilanteen aiheuttaa ja korjattava ongelman juurisyy.

Huonosti toteutetut datatransformaatiot

Datatransformaatiot täytyy tehdä niin että tietotyypitykset otetaan huomioon. Esimerkiksi jos meillä on ’If x=y then a else b’ -lauseke joka ei pysty käsittelemään arvoa null kentässä x. Vaikka null arvoja ei kyseisessä kentässä tällä hetkellä näkyisikään, täytyy prosessin pystyä ne käsittelemään, jos lähdetietoihin on mahdollista sellaisia arvoja syöttää.

Liian paljon turhia riippuvuuksia

Edellä mainitut ongelmat voivat suurentua merkittävästi jos dataintegraatioprosessien välille on rakennettu liikaa riippuvuuksia. Tarpeettomia riippuvuuksia ei tietenkään pitäisi olla ollenkaan. Jos prosessi x on loogisesti riippuvainen vain ja ainoastaan prosessien y ja z onnistumisesta, ei ylimääräistä riippuvuutta muihin prosesseihin tule rakentaa. Suurissa dataintegraatioprojekteissa tämä tulee erittäin tärkeäksi, sillä pahimmassa tapauksessa mikä tahansa virhe pysäyttää koko dataintegraatioprosessin, eikä vain sitä osaa joka on riippuvainen virheen aiheuttaneesta osasta, johtaen toistuviin manuaalilatauksiin. Dataintegraatioprosessien riippuvuudet toisiinsa tulee asettaa minimitasolle.

Virhe johtaa aina manuaaliseen uudelleen lataukseen

Joku voi kuitenkin mennä pieleen. Erityisesti transaktio-tyyppisen datan latauksissa on hyvä idea sisällyttää ladattavaan batchiin enemmän kuin vain tarpeellinen data, esim. 1 päivän sijaan viimeisen kahden päivän data. Näin prosessi korjaa itse itsensä seuraavan päivän automaattisessa latauksessa.