Raportoinnin aika Excelissä katoaa nopeasti - trendi kohti käteviä työkaluja tiedon esittämiseen ja analysointiin näkyy kaikilla alueilla. Olemme keskustelleet sisäisesti raportoinnin digitalisoinnista pitkään ja valitsimme Tableaun visualisointi- ja itsepalveluanalytiikkajärjestelmän. Alexander Bezugly, M.Video-Eldorado Groupin analyyttisten ratkaisujen ja raportointiosaston johtaja, puhui taistelukojelaudan rakentamisen kokemuksista ja tuloksista.
Sanon heti, että kaikki suunniteltu ei toteutunut, mutta kokemus oli mielenkiintoinen, toivottavasti siitä on hyötyä myös sinulle. Ja jos jollain on ideoita miten se voitaisiin tehdä paremmin, olisin erittäin kiitollinen neuvoistasi ja ideoistasi.
Leikkauksen alla kerrotaan siitä, mitä kohtasimme ja mistä opimme.
Mistä aloitimme?
M.Video-Eldoradolla on hyvin kehittynyt tietomalli: strukturoitu tieto vaaditulla tallennussyvyydellä ja valtava määrä kiinteämuotoisia raportteja (katso lisätietoja ). Näistä analyytikot tekevät joko pivot-taulukoita tai muotoiltuja uutiskirjeitä Excelissä tai kauniita PowerPoint-esityksiä loppukäyttäjille.
Noin kaksi vuotta sitten aloitimme kiinteämuotoisten raporttien sijasta analyyttisten raporttien luomisen SAP-analyysissä (Excel-lisäosa, lähinnä OLAP-moottorin pivot-taulukko). Tämä työkalu ei kuitenkaan kyennyt täyttämään kaikkien käyttäjien tarpeita, vaan suurin osa jatkoi analyytikoiden lisäksi käsiteltyjen tietojen käyttöä.
Loppukäyttäjämme jakautuvat kolmeen luokkaan:
Ylin johto. Pyytää tietoa hyvin esitetyllä ja selkeästi ymmärrettävällä tavalla.
Keskijohto, edistyneet käyttäjät. Kiinnostunut tietojen kartoittamisesta ja pystynyt rakentamaan itsenäisesti raportteja, jos työkaluja on saatavilla. Heistä tuli SAP-analyysin analyyttisten raporttien avainkäyttäjiä.
Massakäyttäjät. He eivät ole kiinnostuneita tietojen itsenäisestä analysoinnista, he käyttävät raportteja rajoitetulla vapausasteella, uutiskirjeiden ja pivot-taulukoiden muodossa Excelissä.
Ideana oli kattaa kaikkien käyttäjien tarpeet ja tarjota heille yksi, kätevä työkalu. Päätimme aloittaa ylimmän johdon kanssa. He tarvitsivat helppokäyttöiset kojelautat analysoidakseen liiketoiminnan keskeisiä tuloksia. Joten aloitimme Tableausta ja valitsimme ensin kaksi suuntaa: vähittäiskaupan ja verkkomyynnin indikaattorit, joiden analyysin syvyys ja laajuus on rajallinen ja jotka kattavat noin 80 % ylimmän johdon pyytämästä tiedosta.
Koska kojetaulujen käyttäjät olivat ylintä johtoa, tuotteelle ilmestyi toinen ylimääräinen KPI - vastausnopeus. Kukaan ei odota 20-30 sekuntia tietojen päivittymistä. Navigoinnin olisi pitänyt tapahtua 4-5 sekunnissa tai vielä parempaa, heti. Ja valitettavasti emme onnistuneet saavuttamaan tätä.
Päähallintapaneelimme asettelu näytti tältä:
Keskeisenä ideana on yhdistää tärkeimmät KPI-ajurit, joita oli yhteensä 19, vasemmalla ja esittää niiden dynamiikka ja jaottelu pääattribuuttien mukaan oikealla. Tehtävä vaikuttaa yksinkertaiselta, visualisointi on loogista ja ymmärrettävää, kunnes sukeltaa yksityiskohtiin.
Yksityiskohta 1. Tietomäärä
Vuosimyyntimme päätaulukossamme on noin 300 miljoonaa riviä. Koska viime vuoden ja edellisen vuoden dynamiikkaa on heijastettava, pelkästään toteutuneen myynnin datamäärä on noin miljardi riviä. Tiedot suunnitelluista tiedoista ja verkkomyyntilohkosta tallennetaan myös erikseen. Siksi, vaikka käytimme sarakepohjaista muistissa olevaa DB SAP HANAa, kyselyn nopeus, kun kaikki indikaattorit valittiin viikon ajan nykyisestä tallennustilasta lennossa, oli noin 1-15 sekuntia. Ratkaisu tähän ongelmaan ehdottaa itseään - tietojen lisämateriaaleja. Mutta siinä on myös sudenkuoppia, niistä lisää alla.
Yksityiskohta 2. Ei-additiiviset indikaattorit
Monet KPI-mittarimme on sidottu kuittien määrään. Ja tämä osoitin edustaa COUNT DISTINCT rivien lukumäärästä (tarkista otsikot) ja näyttää eri määriä valituista määritteistä riippuen. Esimerkiksi kuinka tämä indikaattori ja sen johdannainen lasketaan:
Jotta laskelmasi olisi oikein, voit:
- Laske tällaiset indikaattorit lennossa varastossa;
- Suorita laskelmat koko Tableaun tietomäärästä, ts. toimita Tableaussa pyydettäessä kaikki tiedot valittujen suodattimien mukaisesti kuittipaikan tarkkuudessa;
- Luo materialisoitu esittely, jossa kaikki indikaattorit lasketaan kaikissa näytevaihtoehdoissa, jotka antavat erilaisia ei-additiivisia tuloksia.
On selvää, että esimerkissä UTE1 ja UTE2 ovat materiaaliattribuutteja, jotka edustavat tuotehierarkiaa. Tämä ei ole staattinen asia, vaan yrityksen sisäinen johtaminen tapahtuu sen kautta, koska Eri johtajat vastaavat eri tuoteryhmistä. Meillä oli monia globaaleja versioita tästä hierarkiasta, kun kaikki tasot vaihtuivat, kun suhteita tarkistettiin, ja jatkuvia pistemuutoksia, kun yksi ryhmä siirtyi solmusta toiseen. Perinteisessä raportoinnissa kaikki tämä lasketaan lennossa materiaalin ominaisuuksista, näiden tietojen materialisoituessa on tarpeen kehittää mekanismi tällaisten muutosten seuraamiseksi ja historiallisten tietojen automaattiseen uudelleenlataamiseen. Erittäin ei-triviaali tehtävä.
Yksityiskohta 3. Tietojen vertailu
Tämä kohta on samanlainen kuin edellinen. Pääasia on, että yritystä analysoitaessa on tapana muodostaa useita vertailutasoja edelliseen kauteen:
Vertailu edelliseen ajanjaksoon (päivästä toiseen, viikosta viikkoon, kuukaudesta kuukauteen)
Tässä vertailussa oletetaan, että riippuen käyttäjän valitsemasta ajanjaksosta (esimerkiksi vuoden 33. viikko), meidän pitäisi näyttää dynamiikka 32. viikkoon mennessä; jos valitsimme kuukauden tiedot, esimerkiksi toukokuu , niin tämä vertailu näyttäisi dynamiikan huhtikuuhun mennessä.
Vertailu viime vuoteen
Tärkein vivahde tässä on se, että vertaamalla päivä- ja viikkokohtaisesti, et ota viime vuoden samaa päivää, ts. et voi vain laittaa kuluvaa vuotta miinus yksi. Sinun on katsottava vertailtavaa viikonpäivää. Kun vertailet kuukausia, sinun on päinvastoin otettava täsmälleen sama kalenteripäivä viime vuonna. Karkausvuosissa on myös vivahteita. Alkuperäisissä arkistoissa kaikki tiedot jaetaan päiväkohtaisesti, erillisiä kenttiä ei ole viikoilla, kuukausilla tai vuosilla. Siksi saadaksesi täydellisen analyyttisen poikkileikkauksen paneelista, sinun ei tarvitse laskea yhtä ajanjaksoa, esimerkiksi viikko, vaan 4 viikkoa, ja sitten vertailla näitä tietoja, heijastaa dynamiikkaa, poikkeamia. Vastaavasti tämä logiikka vertailujen generoimiseksi dynamiikassa voidaan myös toteuttaa joko Tableaussa tai myymälän puolella. Kyllä, ja tietysti tiesimme ja ajattelimme nämä yksityiskohdat suunnitteluvaiheessa, mutta oli vaikea ennustaa niiden vaikutusta lopullisen kojelaudan suorituskykyyn.
Kojelautaa toteutettaessa seurasimme pitkää Agile-polkua. Tehtävämme oli tarjota mahdollisimman nopeasti toimiva työkalu, jolla on tarvittavat tiedot testausta varten. Siksi lähdimme sprinteillä ja aloitimme minimoimalla työt nykyisen varaston puolella.
Osa 1: Faith in Tableau
Yksinkertaistaaksemme IT-tukea ja toteuttaaksemme muutokset nopeasti, päätimme tehdä Tableaussa ei-additiivisten indikaattoreiden laskennan ja menneiden ajanjaksojen vertailun logiikan.
Vaihe 1. Kaikki on livenä, ei ikkunamuutoksia.
Tässä vaiheessa liitimme Tableaun nykyisiin julkisivuihin ja päätimme katsoa, miten yhden vuoden kuittien määrä lasketaan.
Результат:
Vastaus oli masentava - 20 minuuttia. Tiedonsiirto verkon yli, Tableaun suuri kuormitus. Ymmärsimme, että logiikka ei-additiivisilla indikaattoreilla on otettava käyttöön HANA:ssa. Tämä ei meitä paljoa pelottanut, meillä oli jo samanlainen kokemus BO:sta ja Analysisistä ja tiesimme kuinka rakentaa HANA:ssa nopeita esityksiä, jotka tuottavat oikein laskettuja ei-additiivisia indikaattoreita. Nyt oli jäljellä vain säätää ne Tableaun mukaisiksi.
Vaihe 2. Viritämme vitriinit, ei materialisointia, kaikki lennossa.
Loimme erillisen uuden esittelytilan, joka tuotti tarvittavat tiedot TABLEAU:lle lennossa. Yleisesti ottaen saimme hyvän tuloksen, lyhensimme kaikkien indikaattoreiden generointiaikaa viikossa 9-10 sekuntiin. Ja rehellisesti odotimme, että Tableaussa kojelaudan vasteaika olisi 20-30 sekuntia ensimmäisellä avauksella ja sitten välimuistista johtuen 10-12, mikä yleisesti sopisi meille.
Результат:
Ensimmäinen avattu kojelauta: 4-5 minuuttia
Mikä tahansa napsautus: 3-4 minuuttia
Kukaan ei odottanut tällaista lisäkasvua myymälän työhön.
Osa 2. Sukella Tableauhun
Vaihe 1. Tableau-suorituskykyanalyysi ja pikasäätö
Aloimme analysoida, missä Tableau viettää suurimman osan ajastaan. Ja tähän on olemassa melko hyviä työkaluja, mikä on tietysti Tableaun plussa. Suurin havaitsemamme ongelma olivat erittäin monimutkaiset SQL-kyselyt, joita Tableau rakensi. Ne liittyivät ensisijaisesti:
— tietojen siirtäminen osaksi kansallista lainsäädäntöä. Koska Tableaulla ei ole työkaluja tietojoukkojen transponointiin, meidän piti luoda taulukko tapausta käyttäen luodaksemme kojelaudan vasemmalle puolelle yksityiskohtaisen esityksen kaikista KPI:istä. Tietokannan SQL-kyselyiden koko oli 120 000 merkkiä.
- valita ajanjakso. Tällaisen tietokantatason kyselyn kääntäminen vei enemmän aikaa kuin suorittaminen:
Nuo. pyynnön käsittely 12 sekuntia + 5 sekunnin suoritus.
Päätimme yksinkertaistaa laskentalogiikkaa Tableaun puolella ja siirtää toisen osan laskelmista myymälä- ja tietokantatasolle. Tämä toi hyviä tuloksia.
Ensin teimme transponoinnin lennossa, teimme sen täydellisen ulkoliitoksen kautta VIEW-laskennan viimeisessä vaiheessa tämän wikissä kuvatun lähestymistavan mukaisesti. и .
Eli teimme asetustaulukon - transponointimatriisin (21x21) ja saimme kaikki indikaattorit rivi kerrallaan.
Se oli:
Siitä tuli:
Itse tietokannan transponointiin ei käytetä juurikaan aikaa. Viikon kaikkien indikaattoreiden pyynnön käsittely jatkui noin 10 sekunnissa. Mutta toisaalta joustavuus on menetetty kojelaudan rakentamisessa tiettyyn indikaattoriin, ts. kojelaudan oikealle puolelle, jossa on esitetty tietyn indikaattorin dynamiikka ja yksityiskohtainen erittely, aiemmin näyttökotelo toimi 1-3 sekunnissa, koska pyyntö perustui yhteen indikaattoriin, ja nyt tietokanta valitsi aina kaikki indikaattorit ja suodatti tuloksen ennen kuin tulos palautettiin Tableaulle.
Tämän seurauksena kojelaudan nopeus laski lähes 3 kertaa.
Результат:
- 5 sekuntia – kojetaulujen jäsentäminen, visualisoinnit
- 15-20 sekuntia - valmistautuminen kyselyjen kokoamiseen suorittamalla esilaskelmia Tableaussa
- 35-45 s - SQL-kyselyiden kokoaminen ja niiden rinnakkaisperäinen suoritus Hanassa
- 5 sekuntia – tulosten käsittely, lajittelu, visualisointien uudelleenlaskenta Tableaussa
- Tällaiset tulokset eivät tietenkään sopineet liiketoiminnalle, ja jatkoimme optimointia.
Vaihe 2. Minimi logiikka Tableaussa, täydellinen materialisointi
Ymmärsimme, että useiden sekuntien vasteaikaa sisältävää kojelautaa oli mahdotonta rakentaa 10 sekuntia pyörivään myymälään, ja pohdimme vaihtoehtoja datan toteuttamiseksi tietokantapuolella erityisesti vaadittua kojelautaa varten. Mutta kohtasimme yllä kuvatun maailmanlaajuisen ongelman - ei-additiiviset indikaattorit. Emme pystyneet varmistamaan, että suodattimia tai perusteluja vaihdettaessa Tableau vaihtoi joustavasti eri julkisivujen ja eri tuotehierarkioiden valmiiksi suunniteltujen tasojen välillä (esimerkissä kolme kyselyä ilman UTE:tä, UTE1:llä ja UTE2:lla tuottavat erilaisia tuloksia). Siksi päätimme yksinkertaistaa kojelautaa, hylätä tuotehierarkian kojelaudassa ja katsoa kuinka nopea se voisi olla yksinkertaistetussa versiossa.
Joten tässä viimeisessä vaiheessa kokosimme erillisen arkiston, johon lisäsimme kaikki KPI:t transponoidussa muodossa. Tietokantapuolella kaikki tällaiseen tallennustilaan kohdistuvat pyynnöt käsitellään 0,1 - 0,3 sekunnissa. Kojelaudassa saimme seuraavat tulokset:
Ensimmäinen avaus: 8-10 sekuntia
Mikä tahansa napsautus: 6-7 sekuntia
Tableaun käyttämä aika koostuu:
- 0,3 sek. — kojelaudan jäsennys ja SQL-kyselyiden kokoaminen
- 1,5-3 sek. — SQL-kyselyjen suorittaminen Hanassa tärkeimmille visualisoinneille (suoritetaan rinnakkain vaiheen 1 kanssa)
- 1,5-2 sek. — renderöinti, visualisointien uudelleenlaskenta
- 1,3 sekuntia — ylimääräisten SQL-kyselyjen suorittaminen asianmukaisten suodatinarvojen saamiseksi (brändi, osasto, kaupunki, kauppa), jäsennystulokset
Lyhyesti tiivistettynä
Pidimme Tableau-työkalusta visualisoinnin näkökulmasta. Prototyyppivaiheessa harkitsimme erilaisia visualisointielementtejä ja löysimme ne kaikki kirjastoista, mukaan lukien monimutkainen monitasoinen segmentointi ja usean kuljettajan vesiputous.
Ottaessamme käyttöön keskeisiä myyntiindikaattoreita sisältäviä dashboardeja kohtasimme suorituskykyongelmia, joita emme ole vielä pystyneet voittamaan. Vietimme yli kaksi kuukautta ja saimme toiminnallisesti epätäydellisen kojelaudan, jonka vastausnopeus on hyväksyttävän partaalla. Ja teimme itsellemme johtopäätökset:
- Tableau ei voi työskennellä suurten tietomäärien kanssa. Jos alkuperäisessä tietomallissa sinulla on yli 10 Gt tietoa (noin 200 miljoonaa X 50 riviä), kojelauta hidastuu vakavasti - 10 sekunnista useisiin minuutteihin jokaisella napsautuksella. Kokeilimme sekä live-yhteyttä että ekstraktia. Toimintanopeus on vertailukelpoinen.
- Rajoitus käytettäessä useita tallennusvälineitä (tietojoukkoja). Tietojoukkojen välistä suhdetta ei voida osoittaa standardikeinoilla. Jos käytät kiertotapoja tietojoukkojen yhdistämiseen, tämä vaikuttaa suuresti suorituskykyyn. Meidän tapauksessamme harkitsimme mahdollisuutta materialisoida tiedot kussakin vaaditussa näkymäosiossa ja tehdä kytkimiä näissä materialisoiduissa tietojoukoissa säilyttäen samalla aiemmin valitut suodattimet - tämä osoittautui mahdottomaksi tehdä Tableaussa.
- Tableaussa ei ole mahdollista tehdä dynaamisia parametreja. Et voi täyttää parametria, jota käytetään tietojoukon suodattamiseen otteessa tai live-yhteyden aikana, toisen tietojoukon valinnan tai toisen SQL-kyselyn tuloksella, vain alkuperäisellä käyttäjän syötteellä tai vakiolla.
- OLAP|PivotTable-elementtejä sisältävän kojelaudan rakentamiseen liittyvät rajoitukset.
Jos lisäät tietojoukon raporttiin MSTR:ssä, SAP SAC:ssa, SAP Analysisissä, kaikki siinä olevat objektit liittyvät toisiinsa oletusarvoisesti. Tableaussa ei ole tätä, yhteys on määritettävä manuaalisesti. Tämä on luultavasti joustavampi, mutta kaikissa kojelaudoissamme tämä on pakollinen vaatimus elementeille - joten tämä on lisätyövoimakustannuksia. Lisäksi jos teet aiheeseen liittyviä suodattimia niin, että esimerkiksi aluetta suodatettaessa kaupunkien luettelo rajoittuu vain tämän alueen kaupunkeihin, päädyt välittömästi peräkkäisiin kyselyihin tietokantaan tai Extractiin, mikä hidastaa huomattavasti kojelauta. - Toimintojen rajoitukset. Massamuunnoksia ei voi tehdä Live-connectan otteelle tai ERITYISESTI tietojoukolle. Tämä voidaan tehdä Tableau Prepin kautta, mutta se on lisätyötä ja toinen työkalu oppimiseen ja ylläpitoon. Et voi esimerkiksi siirtää tietoja tai liittää niitä itseensä. Mikä suljetaan yksittäisten sarakkeiden tai kenttien muunnoksilla, jotka on valittava case- tai if-merkillä, ja tämä tuottaa erittäin monimutkaisia SQL-kyselyitä, joissa tietokanta viettää suurimman osan ajastaan kyselytekstin kokoamiseen. Tämä työkalun joustamattomuus oli ratkaistava esittelytasolla, mikä johti monimutkaisempaan tallennustilaan, lisälatauksiin ja muunnoksiin.
Emme ole luopuneet Tableausta. Emme kuitenkaan pidä Tableauta työkaluna, jolla pystytään rakentamaan teollisia kojetauluja ja työkaluna, jolla korvataan ja digitalisoidaan yrityksen koko yritysraportointijärjestelmä.
Kehitämme nyt aktiivisesti samanlaista kojelautaa toisessa työkalussa ja yritämme samalla tarkistaa Tableaun kojelautaarkkitehtuuria yksinkertaistaaksemme sitä entisestään. Jos yhteisö on kiinnostunut, kerromme tuloksista.
Odotamme myös ideoitasi tai neuvojasi siitä, kuinka Tabeaussa voit rakentaa nopeita dashboardeja niin suurille tietomäärille, koska meillä on verkkosivusto, jossa on paljon enemmän dataa kuin vähittäiskaupassa.
Lähde: will.com