Jukka Vainio
DATAMALLINNUS LOGISTIIKAN JOHTAMISESSA JA TYÖN LAADUSSA
Sandvik Mining and Construction Oy
Diplomityö
Johtaminen ja tietotekniikka
Harri Keto
Timo Mäkinen
Marraskuu 2020
TIIVISTELMÄ
Jukka Vainio: Data-analyysi logistiikan johtamisessa ja työn laadussa Diplomityö
Tampereen yliopisto Johtaminen ja tietotekniikka Marraskuu 2020
Tämän diplomityön tavoitteena on tutkia logistiikan kehittämisen ja operatiivisen johtamisen tarpeita datamallinnukselle sekä erilaisille automatisoiduille raporteille. Tutkimus toteutetaan Sandvik Mining and Construction Oy:n logistiikkaan.
Yrityksessä on jo aiemmin tutkittu logistiikan saldovirheiden syitä ja työn laatua. Tutkimuksissa on havaittu, että erilaisia poikkeamia on niin paljon, että kokonaisuuden ja todellisten ongelmien havaitseminen on koettu mahdottomaksi. Tässä tutkimuksessa pyritään löytämään ratkaisuja juuri edellä mainittuun ongelmaan datamallinnuksen ja automaattisten raporttien avulla. Tavoit- teena on, että tutkimuksen päätyttyä Sandvik pystyisi havaitsemaan eteenkin saldovirheitä katta- vammin, kuin myös työn laadussa ja sen tehokkuudessa. Tehokkuuden osalta logistiikassa halu- taan keskittyä erityisesti työmäärän ennustamiseen ja resurssointiin. Saldovirheiden havaitsemi- nen datamallinnuksen ja raportoinnin avulla on yksi keskeisistä tutkimuskysymyksistä.
Tutkimuksen osatavoitteena on löytää myös ratkaisuja ja toimenpiteitä havaittuihin ongelmiin.
Toisena osatavoitteena on siirtää Sandvikin nykyisestä raportointijärjestelmästä (Cognos) kaikki tiedot uuteen järjestelmään (Microsoft Power BI). Yrityksessä on päätetty siirtyä kokonaan Micro- softin Power BI-ympäristöön, joten muutoksen tekeminen ja läpivienti on välttämätöntä. Tutkimus halutaan toteuttaa siis kokonaisuudessaan Microsoftin Power BI:tä hyödyntäen. Samalla tutki- taan, onko vanhoissa Cognos-raporteissa päivitettävää.
Koska Power BI – ympäristö on myös Sandvikille suhteellisen uusi, niin tämän seurauksena ympäristöön ei ole vielä luotu kattavia tietomalleja, vaan ERP-tietokannan dataa käytetään vain satunnaisten raporttien tarpeisiin. Tästä johtuen samaa dataa saatetaan kysellä tietokannasta useaan kertaan usealle eri raportille samaan aikaan, eikä Sandvikin käytössä ole myöskään yri- tyksen omaa tietovarastoa. Tämä kuormittaa ja hidastaa tietokantaa turhaan, mikä voisi laajem- massa käytössä aiheuttaa tietokannan merkittävää hidastumista. Tämän tutkimuksen toisena päätavoitteena on rakentaa kaikki raportit samoihin tietomalleihin perustuen, jotta tietokantaa käy- tettäisiin mahdollisimman tehokkaasti eri raporttien tarpeisiin. Toisin sanoen samasta datasta on tarkoitus koostaa mahdollisimman monta eri raporttia, rasittamatta tietokantaa uusilla SQL-kyse- lyillä.
Yrityksessä on tiedossa, että tietojen mallintamiselle ja automaattisille raporteille on yhä enem- män tarvetta, mutta tutkimusta aloitettaessa tarpeita ei osattu nimetä tarkasti. Oletuksena on kui- tenkin se, että yksi suurimmista ongelmista, joita tutkimuksessa on tarkoitus havaita, ovat logis- tiikan saldovirheet ja sitä kautta työn laadun poikkeamat. Toisin sanoen datan analysoinnilla py- ritään tuomaan esiin näitä virheitä, joita ei ole aiemmin pystytty havaitsemaan.
Tutkimuksen käytännössä jo päätyttyä ilmeni yllättävä tieto, että Sandvik on ulkoistanut logis- tiikan ja toiminnot on myyty Transval Oy:lle. Tämä kauppa ei vaikuttanut tutkimuksen sisältöön, rakennettuun tietomalliin tai raportteihin. Kyseinen yritys haluaa kuitenkin myös itse hyödyntää Sandvikin tietoja omassa raportoinnissaan. Tämän kaltainen tietojen jakaminen onnistuu parhai- ten tässä tutkimuksessa luodun tietomallin avulla. Jos kyseinen ratkaisumalli koetaan toimivaksi, niin Sandvikilla on nyt mahdollisuus hyödyntää samanlaisia tekniikoita muillakin osastoilla. Tutki- mustulokset ovat olleet siis merkittäviä Sandvikin liiketoiminnan ja tietojenkäsittelyn kannalta.
Avainsanat: Microsoft Power BI, SQL, tietokanta, tietomalli, tietovarasto, data-analyysi
Tämän julkaisun alkuperäisyys on tarkastettu Turnitin OriginalityCheck –ohjelmalla.
ABSTRACT
Jukka Vainio: Data analysis in logistics management and work quality Thesis
University of Tampere
Management and information technology November 2020
The aim of this thesis is to study the needs of logistics management and development for data analysis and various automated reports. The study will be carried out for Sandvik Mining and Construction Oy's logistics.
The company has previously studied the causes of logistics balance errors and the quality of work. Studies have previously found that there are so many different errors that it has been perceived as impossible to detect the whole and the real problems. This study seeks to find solutions to the above-mentioned problem through data analysis and automated reports. The goal is that, at the end of the study, Sandvik would be able to detect errors more comprehensively, both in terms of work quality and efficiency. In terms of efficiency, logistics wants to focus especially on workload forecasting and resourcing. Detecting balance errors through data modeling and reporting is one of the key research questions.
The sub-goal of the study is also to find solutions and measures to the identified problems. The second sub-goal is to transfer all data from Sandvik's current reporting system (Cognos) to the new system (Microsoft Power BI). So the company has decided to move entirely to Microsoft's Power BI environment, so it is essential to make and implement the change immediately at the beginning of the research. The aim is to carry out the whole research by using Microsoft Power BI. At the same time, it is being investigated to see if the old Cognos reports need to be updated.
As the Power BI environment is also relatively new to Sandvik, as a result, comprehensive data sets have not yet been created for the environment, and the data from the ERP database is only used for occasional reporting. As a result, the same data may be queried from the database several times for several different reports at the same time. This overloads and slows down the database unnecessarily, which could lead to a more significant slowdown of the database in wider use. The second main goal of this study is to build all reports based on the same data sets in order to use the database as efficiently as possible for different report needs. In other words, the same data is to be compiled into as many different reports as possible, without burdening the database with new SQL queries.
The company was aware that there is an increasing need for data analysis and automated reports, but at the start of the study, the need could not be identified precisely. However, it is assumed that one of the biggest problems that the study is intended to detect is balance errors in logistics and the quality of work. In other words, the data analysis seeks to highlight these errors that have not previously been detectable.
When the study had ended, we get surprising news that Sandvik has outsourced logistics and the operations have been sold to Transval Oy. This transaction did not affect the content of the study, the data model constructed or the reports. However, this company also wants to use Sandvik's data in its own reporting. The best way to do this type of data sharing is using the data model created in this study. If this solution is found to work, then Sandvik now has the opportunity to use similar technologies in other departments. So, the research results have been significant for Sandvik's business and data processing.
Keywords: Microsoft Power BI, SQL, database, data model, data warehouse, data analysis
The originality of this thesis has been checked using the Turnitin OriginalityCheck service.
ALKUSANAT
Tutkimus on toteutettu kaivinkoneyhtiö Sandvik Mining and Construction Oy:n tilauksesta, ja lop- putuloksena saatiin mallinnettua Sandvikin Turun tehtaan logistiikalle oma tietomalli, jonka poh- jalta voidaan tehdä suurin osa raporteista. Lisäksi tutkimuksessa on kehitetty menetelmiä analy- soida isossa tehdaslogistiikassa esiintyviä saldovirheitä niin, että saldovirheitä havaitaan parem- min ja huomattavasti nopeammin. Tämä mahdollistaa työn laadun sekä materiaalivirtojen virheet- tömämmän ohjauksen.
Tutkimuksen onnistumisesta ja tuesta voidaan erityisesti kiittää Tampereen yliopiston lehtoria Harri Ketoa sekä Sandvikin puolelta logistiikkapäällikkö Peter Höijeriä. Harri avasi suuntaa tutki- muksen teorialle sekä keskeisille tutkimuskysymyksille kun taas Peter oli vahvana tukena työn käytännön toteutuksessa. Näin saatiin näkemys siitä, mitä tarvitaan ja mihin teoriaan erilaiset työelämän ratkaisutarpeet voisivat pohjautua. Lisäksi haluan kiittää Sandvikin IT:ltä saamaani tukea erilaisten teknisten ongelmien ratkaisussa esimerkiksi SQL-tietoyhteyksissä. Erityismai- ninta tästä kuuluu Sandvikin Timo Lähteenmäelle ja Harri Vienolalle.
Turussa, 4.11.2020
Jukka Vainio
SISÄLLYSLUETTELO
1. JOHDANTO ... 1
1.1 Tutkimuskysymys ... 1
1.2 Tutkimusmenetelmät ... 2
1.3 Tutkimuksen rakenne ... 3
2. TIETOKANTOJEN TEORIAA JA SANDVIKIN KÄYTÄNTEET ... 4
2.1 Tietokannat ... 4
2.1.1 Relaatiotietokanta ... 5
2.1.2 Muita tietokantatyyppejä ... 6
2.2 Business Intelligence Sandvikilla... 8
2.3 Tietokuutio ... 10
3. TIETOMALLINNUKSEN TEORIAA JA POWER BI ... 11
3.1 Microsoft Power BI ... 11
3.2 DAX-funktiokieli ... 11
3.2.1 Syntaksi ... 12
3.2.2 Funktiot ... 12
3.3 Tietomallinnus ja Power BI ... 13
3.3.1 Relaatiot taulujen ja kyselyiden välillä ... 14
3.3.2 Kyselyiden yhdistäminen ... 15
3.3.3 Suodattimet ... 16
3.3.4 Visualisoinnit ... 18
3.3.5 Koosteet ja count-tekniikka ... 18
3.4 Data vault ... 19
4. LOGISTIIKAN PROSESSIT JA RAPORTIT ... 24
4.1 Logistiikan ydinprosessit ... 24
4.2 Logistiikan Cognos-raportit ... 24
4.3 Kehityskohteet ... 25
5. LOGISTIIKAN TIETOMALLI JA RAPORTTIEN MALLINNUS ... 30
5.1 SQL-kyselyt Leanistä ... 30
5.2 Lean- ja Kardex-tietokannat ... 32
5.3 Sandvikin aikadimensio ... 32
5.4 Vastaanoton tietomalli ... 34
5.5 Työntekijätehokkuuden tietomalli ... 36
5.6 Keräilyjen vasteaikojen ja tehon tietomalli ... 37
5.7 Keräilyennusteiden tietomalli ... 39
5.8 Lähettämön tietomalli ... 41
5.9 Kardexin tietomalli ... 44
5.10 Steven tietomalli ... 46
5.11 Varastotapahtumien tietomalli ... 50
5.12 Saldoseurannan tietomalli ... 52
5.13 Materiaalikoordinaattorin tietomalli ... 55
5.14 Logistiikan valmis tietomalli ... 59
6. TIETOMALLISSA KÄYTETYT SQL-KYSELYT ... 63
6.1 Infotekstien taulu ... 63
6.2 Materiaalipuutteiden taulu ... 63
6.3 Varastosaldojen taulu ... 64
6.4 Ostotilauserien selailun taulu ... 64
6.5 Varastosiirtojen ehdotusten taulu ... 65
6.6 Työt-taulu ... 65
6.7 Työlistojen selailu ... 65
6.8 Varastotapahtumien taulu ... 65
6.9 Toimitusrivien taulu ... 66
6.10 Materiaalivarauksien taulu... 67
6.11 Myyntitilausten taulu... 67
6.12 Keräilytehtävien taulu ... 67
6.13 Toimituksien taulu ... 68
6.14 Tilauksien taulu ... 68
6.15 Keräilylistan taulu ... 69
6.16 Työn vaiheiden taulu ... 69
6.17 Varastotapahtumien taulu (Työnumeroiden osalta) ... 69
6.18 Keräilylistan taulu (Kardexin poistetut keräilyt) ... 70
6.19 Kardexin nimikelistan taulu ... 70
6.20 Kardexin varastosaldot paikoittain ... 70
6.21 Kardexin käytössä olevien varastopaikkojen taulu ... 71
6.22 Kardexin varastopaikkojen perustietojen taulu ... 71
7. RAPORTTIEN OIKEUDET ... 72
7.1 Oikeuksien jakamisen periaatteet ... 72
7.2 Infonäytöt ... 72
7.3 Microsoft Power BI ja sähköpostijako ... 73
7.4 Mobiilisovellus ... 74
8. TUTKIMUSTULOKSET ... 76
8.1 Työkuorman mittaaminen ja sen ennustaminen ... 76
8.2 Saldovirheet ja niiden havaitseminen ... 77
8.3 Logistiikan tietomalli ... 78
8.4 Power BI työn tehostajana ... 79
8.5 Tutkimuksen arviointi ... 79
8.5.1 Logistiikkapäällikkö ... 80
8.5.2 Materiaalikoordinaattori ja varaston försti (sama henkilö) ... 80
8.5.3 Vastaanoton försti ... 81
8.5.4 Haastattelujen yhteenveto ... 82
8.6 Tietojen jakaminen Transval Oy:lle ... 83
8.7 Yleistykset ja teoriat ... 84
9. YHTEENVETO ... 86
10. LÄHTEET ... 87
TAULUKKOLUETTELO Taulukko 1: Cognos-raporttien sisältö ... 25
Taulukko 2: Power BI-raporttien tavoitteet ... 26
KUVALUETTELO
Kuva 1. Esimerkki relaatiokannan taulusta... 6
Kuva 2. ETL-prosessin yksinkertaistettu kuvaus ... 9
Kuva 3. Sandvikin Business Intelligence - prosessi ... 9
Kuva 4. DAX-funktion syntaksi ... 12
Kuva 5. Kahden eri kyselyn yhdistäminen Power BI:ssä ... 16
Kuva 6. Esimerkki Power BI-raportin suodattimista ... 17
Kuva 7. Suodattimien käyttö ... 17
Kuva 8. Visuaalityypit Power BI:ssä ... 18
Kuva 9. Yhdysvaltojen moottoritiejärjestelmä: satunnainen verkko ... 20
Kuva 10. Yhdysvaltojen lentokonejärjestelmä: vapaasti skaalattava verkko ... 21
Kuva 11. Data Vault – mallin arkkitehtuuri ... 22
Kuva 12. Yksinkertaistettu malli logistiikan ydinprosesseista ... 24
Kuva 13. CREATE_STAMP -sarakkeen hierarkia Power BI:ssä ... 33
Kuva 14. Neljän rivin esimerkki aikadimension kaikista 18 sarakkeesta ... 34
Kuva 15. Logistiikan tietomalli ilman aikadimensiota ... 60
Kuva 16. Logistiikan tietomalli aikadimension kanssa ... 62
Kuva 17. Power BI-mobiilisovelluksen päävalikko ja esimerkkiraportti skaalattuina ... 75
KUVIOLUETTELO Kuvio 1: Vastaanoton tietomalli ... 35
Kuvio 2: Työntekijätehokkuuden tietomalli ... 37
Kuvio 3: Keräilyjen vasteaikojen ja tehon tietomalli ... 39
Kuvio 4: Keräilyennusteiden tietomalli ... 40
Kuvio 5: Lähettämön tietomalli ... 43
Kuvio 6: Kardexin tietomalli ... 46
Kuvio 7: Steven tietomalli ... 50
Kuvio 8: Varastotapahtumien tietomalli ... 52
Kuvio 9: Saldoseurannan tietomalli ... 55
Kuvio 10: Materiaalikoordinaattorin tietomalli ... 58
LIITELUETTELO
LIITE 1: LÄHETTÄMÖN COGNOS-RAPORTTI 1
LIITE 2: KERÄILYN COGNOS-RAPORTTI 2
LIITE 3: VASTAANOTON COGNOS-RAPORTTI 3
LIITE 4: EI HYLLYPAIKKAA -COGNOS-RAPORTTI 4
LIITE 5: AIKADIMENSIO 5
LIITE 6: VASTAANOTON POWER BI-RAPORTTI 6
LIITE 7: TYÖNTEKIJÖIDEN TULOKSEN POWER BI-RAPORTTI 7
LIITE 8: KERÄILYJEN VASTEAIKOJEN JA TEHON POWER BI-RAPORTTI 8
LIITE 9: KERÄILYENNUSTEIDEN POWER BI-RAPORTTI 9
LIITE 10: LÄHETTÄMÖN POWER BI-RAPORTTI 10
LIITE 11: KARDEXIN POWER BI-RAPORTTI 11
LIITE 12: STEVEN POWER BI-RAPORTTI 1 12
LIITE 13: STEVEN POWER BI-RAPORTTI 2 13
LIITE 14: VARASTOTAPAHTUMIEN SEURANNAN POWER BI-RAPORTTI 14
LIITE 15: SALDOSEURANNAN POWER BI-RAPORTTI 15
LIITE 16: MATERIAALIKOORDINAATTORIN POWER BI-RAPORTTI 16
LIITE 17: VASTAANOTON FÖRSTIN DASHBOARD 17
LIITE 18: VARASTON FÖRSTIN DASHBOARD 18
LIITE 19: MATERIAALIKOORDINAATTORIN DASHBOARD 19
1. JOHDANTO
Tämän tutkimuksen tavoitteena on kehittää Sandvik Mining and Construction Oy:n logistiikkaan tietomalli, jota voidaan hyödyntää logistiikan johdon raportointiin. Tietomallilla tarkoitetaan tässä tutkimuksessa Microsoftin käyttämää suomennosta englanninkielisestä sanasta dataset. Micro- soft käyttää suomenkielisessä dokumentaatiossaan myös käsitettä Tietojoukko. Microsoft mää- rittelee tietojoukon seuraavasti: Tietojoukko on kokoelma tietoja, jotka voit tuoda tai joihin voit muodostaa yhteyden. Power BI:n avulla voit koota yhteen kaikenlaisia tietojoukkoja eri tietokan- noista, muodostamalla niihin yhteyden ja tuomalla niitä. Tietojoukkojen tietolähteitä voivat olla myös tietovuot. (Microsoft Corporation Oy, 2020)
Mallin testaamiseksi tutkimuksessa luodaan kattava valikoima erilaisia raportteja, joiden tavoit- teena on tuoda näkyväksi logistiikan tulevan työn määrän ennuste, sekä logistiikan saldovirheitä.
Saldovirheiden syitä on tutkittu Sandvikilla jo vuosia, mutta ongelmaan ei ole pystytty tarttumaan kunnolla, koska virheiden juurisyyt ja vaikutukset ovat hyvin laaja-alaisia ja monipuolisia. Kaikki tutkimuksessa tehty materiaali on toteutettu Microsoftin Power BI -ohjelmiston avulla.
Tutkimus oli saatu jo käytännössä valmiiksi, mutta juuri ennen työn lopullista palautusta saatiin tieto, että Sandvik on myynyt Turun tehtaan logistiikkaa koskevat toiminnot Transval Oy:lle. Tämä tieto ei vaikuttanut tutkimuksen sisältöön, tietomalliin tai raportteihin missään vaiheessa. Asiaan vaikutti erityisesti se, ettei tutkija ollut tietoinen edellä mainitusta kaupasta missään vaiheessa tutkimusta. Tutkimusraportissa aihetta ei siis käsitellä lainkaan, mutta tutkimustuloksissa huoma- taan, että tutkimuksen tulokset luovat Sandvikille useita ratkaisuja ja uusia toimintatapoja liittyen raportointiin ja tietojen jakamiseen.
1.1 Tutkimuskysymys
Logistiikan toimintaa vaikeuttavat huomattavasti erilaiset saldovirheet ja se, miten työn laatua voi- taisiin analysoida. Tutkimuksessa oletetaan, että ongelmien ratkaisemiseksi tarvitaan raportointia tukeva tietomalli. Tutkimustavoitteeksi asetamme tietomallin loogisen ratkaisun sisällön määrittä- misen ja sen teknisen toteutuksen. Tietomallin perustaksi on tunnistettu kolme käytännön ongel- maa, joihin raporteissa etsitään vastauksia. Käytännön ongelmien avulla saamme muodostettua konkreettisia alakysymyksiä tutkimukselle.
Työkuorman hahmottamisessa tavoitteena on tuoda tehdyn työn määrä näkyväksi ja vastata ky- symykseen mitä on tehty ja kuinka paljon. Tulevan työmäärän ennustamisessa tavoitteena on ennustaa tulevan työkuorman määrää eri osastoilla ja vastata kysymykseen mitä pitää tehdä ja kuinka paljon. Saldovirheiden esille tuomiseksi pyrimme vastaamaan kysymykseen miten paljon virheitä muodostuu eri osastoilla. Saldovirheitä ei tunnisteta ajoissa ja ne johtuvat yleensä työn huonosta laadusta. Tässä tutkimuksessa emme kuitenkaan pyri ottamaan lähtökohtaisesti kantaa siihen mitkä ovat saldovirheiden juurisyitä.
Lisäksi tutkimuksen alussa havaittiin oletuksia ja vaatimuksia tietomallin toteutukseen liittyen.
Nämä on otettava myös huomioon tutkimuskysymyksiä sekä tutkimuksen ratkaisuja muodostet- taessa. Vaatimuksena oli rakentaa tietomalli, joka palvelee logistiikan raportointitarpeita mahdol- lisimman kattavasti sen eri osastoilla. Lisäksi toteutus oli tehtävä Microsoftin Power BI:n avulla, koska Sandvik on valinnut Power BI:n yhtiön raportointivälineeksi. Voimme muodostaa näiden vaatimusten nojalla lisää alakysymyksiä. On tutkittava mitä asioita ja millä tavoilla dataa on mah- dollista mitata logistiikassa niin, että data olisi mahdollisimman visuaalisessa ja havainnollisessa muodossa. Yhteenvetona voimmekin koostaa edellä käsitellyt kysymykset yhtenäiseksi kokonai- suudeksi. Tutkimuskysymykset ja niiden taustalla olevat käytännön kysymykset ovat:
K1 Millainen on tietomallin looginen ratkaisu?
K1.1 Mitä työtä on tehty ja kuinka paljon (työkuorma)?
K1.2 Mitä työtä pitää tehdä ja kuinka paljon (työkuorman ennuste)?
K1.3 Miten paljon saldovirheitä muodostuu eri osastoilla (työn laatu)?
K2 Miten tietomalli toteutetaan teknisesti tehokkaimmalla tavalla?
K2.1 Mitä asioita ja millä tavoilla dataa on mahdollista mitata logistiikassa?
K2.2 Miten data saadaan mahdollisimman visuaaliseen ja havainnolliseen muotoon?
Kysymys logistiikan saldovirheistä (K1.3) voidaan nähdä erittäin moninaisena aiheena, joka on osa koko tehtaan toimintaa. Käsittelemmekin kaikkea dataa mahdollisimman kattavasti koko teh- taan näkökulmasta. Teemme siis jo heti tutkimuksen alkuvaiheessa oletuksen, että esimerkiksi saldovirheet syntyvät muiltakin osastoilta kuin vain logistiikalta.
1.2 Tutkimusmenetelmät
Tämä tutkimus on konstruktiivinen tapaustutkimus, jossa sovelletaan olemassa olevaa tietä- mystä, teoriaa ja teknologiaa käytännön ongelmaan (Baxter & Jack, 2008). Päämääränä oli to- teuttaa konstruktio (tietomalli) ja arvioida sen toimivuutta. Tutkimustulosten arviointi toteutettiin haastatteluina. Vaikka kyseessä on yksittäinen tapaus, pyrimme luomaan joitain yleistyksiä tutki- muksen tulosten ja aineiston pohjalta. Tämä tarkoittaa myös sitä, että tutkimusta koskevat kysy- mykset voivat muuttua ja ilmetä vasta tutkimusta tehdessä. Induktiivisen lähestymistavan valintaa tukee se, että tutkimuksen alussa ei ollut tarkkaa tietoa siitä, millaisia ongelmia tai mahdollisuuk- sia logistiikan tietomallinnuksessa ja raportoinnissa voisi olla.
Tutkimus voidaan nähdä yksittäisenä tapauksena suuressa teollisuusyrityksessä, joten tutkimus- strategia painottuu vahvasti tapaustutkimukseen, jossa tarkastellaan ja analysoidaan intensiivi- sesti yhtä tai useampaa tapausta. Logistiikan tietomalli voidaan nähdä tällaisena yksittäisenä ta- pauksena ja tietomallista esiin tuodut raportit voidaan nähdä useampana tapauksena, joilla on keskenään useita yhdistäviä tekijöitä.
1.3 Tutkimuksen rakenne
Aloitamme tutkimusraportin tietomallinnuksen ja raportoinnin teorialla (luvut 2 ja 3), minkä jälkeen siirrytään käytännön toteutukseen. Teorian tarkoitus on tukea tutkimuksen tuloksia sekä selven- tää lukijalle tutkimuksen taustaa. Lisäksi lukijaa autetaan ymmärtämään esimerkiksi raportoinnin ja tietomallinnuksen teoriaa juuri tämän tutkimuksen näkökulmasta, jotta tutkimuksen toteutus- tapa olisi helpompi ymmärtää. Käsittelemme tämän jälkeen logistiikan nykyistä tilannetta ja kehi- tyskohteita raportoinnin osalta (luku 4). Loppu tutkimus käsitellään logistiikan tietomallia ja raport- teja kokonaisuus kerrallaan (luvut 5-7). Tutkimuksessa huomattiin raportointia vaativia kokonai- suuksia olevan logistiikassa niin monella eri osastolla ja vastuualueella, että on selkeämpää kä- sitellä kokonaisuutta aihe kerrallaan. Tutkimuksen lopussa kokoamme nämä aiheet yhteen, jotta havaitsemme tutkimustulokset mahdollisimman selkeästi.
Tutkimustuloksissa (luku 8) huomattiin, että saldovirheitä on mahdollista analysoida ja löytää ra- portoinnin avulla. Saimme aikaiseksi kattavia listauksia erityyppisten saldovirheiden aiheuttajista, jolloin ongelmiin sekä työn laadun valvontaan voidaan kiinnittää paremmin huomiota. Lisäksi lo- gistiikan työkuormaa pystyttiin ennustamaan suunnilleen sillä tarkkuudella kuin tutkimuksessa oli alun perin haluttu. Joiltain osin kuitenkin huomattiin, että logistiikan työkuorman ennustaminen on niin moniulotteinen käsite, ettei sen täydellinen matemaattinen mallintaminen ollut tämän työn kannalta enää mahdollista. Joitain ennusteita jouduttiin siis yksinkertaistamaan ja rajaamaan tut- kimuksen laajuutta näiltä osin. Vastavuoroisesti logistiikan tulosten ja työstä suoriutumisen mit- taaminen onnistui helpommin tavoitellun tarkkuuden puitteissa. Tutkimuksessa huomattiin, että logistiikan työ on suurilta osin jopa enemmän tietojärjestelmien kanssa yhteydessä kuin esimer- kiksi tuotannon päivittäiset työt. Tällä tarkoitamme sitä, että logistiikka on yhteydessä tietojärjes- telmiin jopa muutaman sekunnin välein, mikä taas mahdollistaa erittäin tarkan ja laadukkaan da- tan analysoimisen.
2. TIETOKANTOJEN TEORIAA JA SANDVIKIN KÄYTÄNTEET
Käsittelemme aluksi tietokantojen teoriaa eli millaisia tietokantoja on olemassa ja mikä on tieto- kuutio. Teorian edetessä käsittelemme samalla huomioita Sandvikin käytännöistä, jotta diplomi- työn lähtökohtia olisi lukijan helpompi ymmärtää.
2.1 Tietokannat
Tietokanta on järjestetty kokoelma dataa, joka tallennetaan tietokoneella. Tietokannalla tarkoite- taan yleisesti virtuaalista versiota tietokannasta, ja sen tarkoituksena on nopeuttaa tiedonhakua, tietojen tallentamista, muuttamista ja poistamista. Tietokantoja käytetään tietokoneella, jotta tie- don hakeminen olisi entistä nopeampaa ja helpompaa. (Encyclopædia Britannica, Inc., 2020)
Tietokanta ei ole organisaatiosta ikinä erillään ns. ”tyhjiössä”. Vaikka tietokannat muodostavatkin selkärangan suurimmalle osalle organisaation tietojenkäsittelyä, tietokantoja ympäröivät tietojär- jestelmät, joissa on erilaisia ohjelmistoja ja käyttäjiä. (Harrington, 2016)
Järjestelmiä, jotka käyttävät organisaation tietokantoja, on olemassa kahta eri tyyppiä:
Tapahtumien käsittelyjärjestelmät (online transaction processing, OLTP) käsittelevät organisaa- tion päivittäisiä toimia. Myynti, kirjanpito, tuotanto ja henkilöstö – kaikki nämä käyttävät OLTP- järjestelmiä. OLTP-järjestelmät muodostavat perustan tietojenkäsittelylle useimmissa organisaa- tioissa. (Itse asiassa OLTP on usein ainoa pienyrityksen käyttämä tietojärjestelmä.) Tiedot ovat dynaamisia, eli ne muuttuvat usein, kun organisaatio myy, valmistaa ja hallinnoi toimintaa.
(Harrington, 2016)
Analyyttisiä prosessointijärjestelmiä (online analytical processing, OLAP) käytetään tukemaan or- ganisaation suorituskyvyn analysointia, korkean tason operatiivisten päätösten tekoa ja strate- gista suunnittelua. Suurin osa tiedoista puretaan käyttöjärjestelmistä, alustetaan tarvittaessa ja ladataan OLAP-järjestelmään. Tietojen arvoja ei kuitenkaan muuteta usein, koska ne ovat osa järjestelmää. (Harrington, 2016)
Jotkut OLAP-järjestelmät käyttävät myös relaatiotietokantoja, mukaan lukien jotkut suuret tieto- varastot. Viime vuosina kuitenkin rakenteettomien tietojen määrästä (tiedot ilman ennustettavaa ja vakaata rakennetta) on tullut tärkeätä yrityspäätöksenteossa. Näiden tietojen käsittelemiseksi on syntynyt uusia tietokantatyyppejä. (Harrington, 2016)
Tietokantoja tarvitaan hyvin erilaisiin käyttötarkoituksiin esimerkiksi liiketoiminnassa. Tämän takia myös tietokantatyyppejä on erilaisia eli eri tietokantatyypit on suunniteltu hieman erilaisiin tarpei- siin. Käsittelemmekin seuraavaksi erilaisia tietokantatyyppejä, jotta huomaamme millaisia erilai- sia mahdollisuuksia eri tietokannoissa on ja mitä ominaisuuksia erityisesti tässä diplomityössä käytettävillä tietokannoilla on.
2.1.1 Relaatiotietokanta
Relaatiotietokanta on tietokanta, jonka looginen rakenne koostuu erilaisten tietosuhteiden koko- elmasta. Relaatiomalli on yhden miehen - Edgar (E. F.) Coddin - työn tulos. 1960-luvun aikana tohtori Codd työskenteli olemassa olevien tietomallien kanssa, vaikka hän oli matemaatikko. Ko- kemus sai hänet uskomaan, että sen aikaiset mallit olivat kömpelöitä ja epäkäytännöllisiä tapoja käsitellä relaatioita eli tietosuhteita. Siksi hän palasi takaisin matematiikan joukkoteorian pariin ja keskittyi tietorakenteisiin, jotka tunnetaan relaatioina. Hän laajensi tätä käsitettä luodakseen re- laatiotietokantamallin, jonka hän julkaisi lehdessä 1970. (Harrington, 2016)
Matemaattisessa joukkoteoriassa relaatio on sama asia kuin taulukko, joka muodostuu sarak- keista ja riveistä. (Sanaa "taulukko" käytetään synonyyminä "relaatiolle", vaikka se ei pidä täysin paikkaansa, sillä jokainen taulukko ei ole relaatio.) Relaation määrittely kertoo millaista dataa taulukon sarakkeet sisältävät, mutta itse tietosisältöön ei oteta kantaa. Ensi silmäyksellä taulukko on kuin kaksiulotteinen ja perinteinen laskentataulukko sarakkeineen ja riveineen. (Harrington, 2016)
Taulukon sarakkeella on seuraavat ominaisuudet: Sarakkeella on ainutlaatuinen nimi, joka ei toistu muualla taulukossa. Relaatiotietokannan kahdessa tai useammassa taulukossa sarakkeilla voi olla samoja nimiä. Jossain tapauksissa tämä on jopa toivottavaa, kunhan saman taulun sa- rakkeilla on kaikilla eri nimi. (Harrington, 2016)
Relaatiotietokannassa rivejä tarkasteltaessa sarakkeen ja rivin leikkauspisteessä on aina vain yksi arvo eli atribuutilla ei voi olla montaa arvoa. Näin ollen relaatiotietokannassa ei voi olla kahta identtistä riviä ja rivit ovat aina ainutlaatuisia. (Harrington, 2016)
Pääavain on sarake tai sarakeyhdistelmä, jonka arvo yksilöi kunkin rivin taulukosta. Niin kauan kuin pääavaimet ovat yksilöllisiä, ovat myös rivit ainutlaatuisia. Tietojen tarkastelussa rivien jär- jestys ei vaikuta datan merkitykseen. (Harrington, 2016)
Kuva 1. Esimerkki relaatiokannan taulusta (Sandvik Mining and Construction Oy, 2020)
Tietokantoja hallitaan aina tietokantajärjestelmien (Database Management System, DBMS) avulla. Sandvikin tapauksessa kyse on Lean-nimisestä ERP-relaatiotietokannasta, jota hallitaan erittäin yleisellä Oracle-järjestelmällä (Solid IT, 2020). Leanin relaatiotietokannan taulusta on esi- merkki kuvassa 1. Lisäksi tässä tutkimuksessa tullaan tarvitsemaan Kardex-varastoautomaattien tietokantaa, joka on myös relaatiotietokanta. Kardex toimii Power Pick Global nimisen järjestel- män pohjalta (Sandvik Mining and Construction Oy, 2020), minkä kautta on myös mahdollista päästä käsiksi Kardexin relaatiotietokantaan. Relaatiotietokanta itsessään on toteutettu Microsof- tin SQL Server - tietokantajärjestelmälle.
2.1.2 Muita tietokantatyyppejä
Relaatiotietokantojen lisäksi on olemassa useita muitakin tietokantatyyppejä. Relaatiotietokannat ovat tämän tutkimuksen kannalta tärkeässä roolissa, mutta on hyvä ymmärtää, että tietokantoja voidaan hallita myös monilla muilla tavoilla. Käsittelemme seuraavaksi esimerkkeinä avain - arvo, dokumentti-, ja verkkotietokantoja. Nämä ovat kaikki ns. NoSQL-tietokantoja.
Avain-arvotietokannat tarjoavat erittäin rajoitetun tietomallin. Kantaan talletetaan arvoja sekä ar- von yksilöiviä avaimia. Tietokannan suhteen talletettavilla arvoilla ei ole (yleensä) mitään skee- maa eli rakennetta. Sovellusten on tulkittava kantaan talletettavat arvot haluamallaan tavalla esim. tietyn tyyppisenä oliona. Koska tietokanta on täysin skeematon, eivät avain-arvotietokannat tue viitteitä kantaan talletettujen arvojen välillä, eli mitään relaatiotietokantojen liitosta vastaavaa käsitettä ei avain-arvotietokannoilla ole. Avain-arvotietokantojen tarjoamat kyselymahdollisuudet ovat erittäin rajoittuneet, yleensä on ainoastaan mahdollista hakea kannasta tiettyä avainta vas- taava arvo. (Helsingin Yliopisto, 2018)
Mitä järkeä avain-arvotietokannoissa on? Ne vaikuttavat ominaisuuksiltaan erittäin rajoittuneilta ja relaatiotietokannoilla pystyy tekemään varmasti kaikki ne asiat, joihin avain-arvotietokannat pystyvät. Rajoituksistaan johtuen avain-arvotietokannat ovat kuitenkin suorituskyvyltään ja skaa- lautuvuudeltaan huomattavasti parempia kuin relaatiotietokanta, ja niiden avulla pystytään kui- tenkin ratkaisemaan monia sovellusten käyttötarpeita. (Helsingin Yliopisto, 2018)
Eräs hyvin yleinen käyttötarkoitus avain-arvotietokannoille on raskaiden operaatioiden tulosten väliaikainen talletus (engl. caching) mahdollisia uusia saman operaatioiden suorituksia varten (Helsingin Yliopisto, 2018). Esimerkiksi sääpalvelut voidaan toteuttaa avain-arvotietokantaan, koska käyttäjien määrä on todella suuri ja tiedot pysyvät tietokannassa suunnilleen samoina esi- merkiksi kahden päivän ajan.
Dokumentti-tietokantojen voi ajatella sijoittuvan jonnekin relaatiotietokantojen ja avain-arvotieto- kantojen puolen välin tienoille. Dokumenttikannat perustuvat avain-arvotietokantojen tapaan ar- vojen tallettamiseen avaimen perusteella. Arvot tai dokumentit kuten niitä dokumenttikantojen kontekstissa nimitetään voivat kuitenkin olla itsessään hyvin monimutkaisia oliota, jotka sisältävät kenttiä, joiden arvona voi olla joko normaaleja arvoja kuten lukuja ja merkkijonoja tai muita olioita.
Toisin kuin avain-arvotietokannoissa, dokumenttikannat "näkevät" tietokantaan talletettujen do- kumenttien sisään, ja mahdollistavat talletettujen dokumenttien sisällön suhteen tehdyt kyselyt.
(Helsingin Yliopisto, 2018)
Dokumentti-tietokannassa dokumentit on lajiteltu kokoelmiin (engl. collection). Kokoelman merki- tys on suunnilleen sama kuin taulun relaatiotietokannassa. Yhdessä kokoelmassa olevien doku- menttien ei kuitenkaan tarvitse olla kentiltään samanlaisia. Kenttiä voi olla vaihteleva määrä ja saman nimiset kentät voivat sisältää eri dokumenteilla erityyppisen arvon. Kokoelmille ei määri- tellä dokumenttikannoissa minkäänlaista skeemaa, eli on täysin sovellusten vastuulla, että kan- taan talletetaan järkevää dataa, ja että kannasta luettava data tutkitaan oikein. Toisin kuin re- laatiotietokantojen tapauksessa, dokumenttikannat eivät tarjoa tietokannan tasolla tapahtuvia lii- tosoperaatiota. (Helsingin Yliopisto, 2018)
Relaatiotietokannat ja esittelemämme NoSQL-kantatyypit keskittyvät ns. dataentiteettien esittä- miseen. Relaatiotietokannat esittävät entiteetit taulujen riveinä, esim. Henkilö-taulussa jokainen ihminen esitettään omana rivinään. Yhteydet ja suhteet eri entiteettien välillä esitetään epäsuo- rasti vierasavaimien ja liitostaulujen avulla. Itse yhteys, esim. ”missä henkilö Arto on töissä” saa- daan selville vasta kyselyn aikana tapahtuvan liitosoperaation avulla. Joissain tilanteissa entiteet- tien suhteiden selvittäminen relaatiotietokannassa saattaa olla erittäin hankalaa. (Helsingin Yliopisto, 2018)
Ratkaisun ongelmaan tuovat verkkotietokannat, jotka mallintavat eksplisiittisesti sekä entiteetit eli esim. henkilöt ja niiden ominaisuudet, että entiteettien väliset suhteet kuten sukulaisuuden hen- kilöiden välillä. Kuten nimestä voi päätellä, on verkkotietokannan pohjalla olevana tietorakenteena verkko (engl. graph), joka koostuu entiteettejä kuvaavista solmuista (engl. node) ja niiden välisiä suhteita kuvaavista kaarista (engl. edge). Sekä solmuilla, että kaarilla voi olla attribuutteja.
(Helsingin Yliopisto, 2018)
Verkkotietokannat tarjoavat kyselykielen, jonka avulla on helppo "navigoida" verkossa. Toisin kuin relaatiotietokannoissa, jotka edellyttävät yhteyden muodostamiseen laskennallisesti kallista joi- noperaatiota, yhteyksien navigointi verkkotietokannassa on nopeaa. Verkkotietokannoille ei ole olemassa yhtä vakiintunutta kyselykieltä. On kuitenkin tiettyjä kyselykieliä, kuten tämän hetken suosituimman verkkotietokannan Neo4J:n käyttämä Cypher, joita jotkut muutkin verkkotietokan- nat tukevat. (Helsingin Yliopisto, 2018)
2.2 Business Intelligence Sandvikilla
Kuten muissakin tieteenaloissa, termejä malli ja mallintaminen käytetään usein myös liiketoimin- taan liittyvässä tietomallinnuksessa (Business Intelligence, BI). Business intelligencen päätavoit- teena on tarjota tukea yrityksen päätöksenteolle ja tavoitteille läpi organisaation. Tietoja voidaan mallintaa usealla eri tavalla, esimerkiksi prosessi-, organisaatio-, regressio-, luokitus-, graafiikka- ja ohjelmistomalleilla. Kaikkien mallintamistekniikoiden tarkoituksena on empiiristen asioiden ja ilmiöiden selittäminen loogisella ja objektiivisella tavalla, jotta tietojen avulla voidaan siirtyä suo- raan käytännön toimiin (Springer, 2015). Business intelligence sisältää tietojen hankintaa, tallen- nusta sekä analysointia. Termi itsessään on hyvin laaja ja siksi sen määrittely on myös haastavaa.
Business intelligence toimii niin sanotun ”ETL-prosessin” (kuva 2) pohjalta, mikä tarkoittaa datan siirtämistä, muokkaamista ja lataamista: tiedot haetaan (Extract) lähdejärjestelmästä, niitä muo- kataan (Transform) ja ladataan (Load) lopulta tietovarastoon. Latausprosessissa tiedot muunne- taan tietovaraston rakenteen muotoon ja integroiden samalla eri lähtöjärjestelmien tietoja. Pro- sessi sisältää yleensä myös tietojen historioinnin. Tyypillinen ETL-prosessi voisi esimerkiksi kä- sittää asiakastietojen integroimisen asiakassovelluksesta yrityksen keskitettyyn tietovarastoon (Hovi, 2018).
Tietovarasto (data warehouse, DW) on erillinen tietokanta, johon eri järjestelmissä hajallaan oleva data poimitaan ja ladataan raportointia, analytiikkaa ja muuta käyttöä varten. Idea on yhdistellä datat ja tuoda ne helposti saataville ja kyseltäviksi. Tietovarastojen suunnittelussa käytetään nii- hin tarkoitettuja erillisiä menetelmiä, esimerkiksi tähtimalli ja Data Vault. Tietovarastossa tiedot ovat tyypillisesti ajan tasalla esimerkiksi päivätasolla tai jopa reaaliaikaisena. Tietovaraston avulla voidaan hoitaa myös tietojen historiointi. (Hovi, 2018)
Kuva 2. ETL-prosessin yksinkertaistettu kuvaus (Oiwa solutions, 2019)
Sandvikin tapauksessa varsinaista tietovarastoa ei ole lainkaan. Yritys on päätynyt tähän ratkai- suun siksi, että tietovaraston luominen koetaan raportointia varten turhana ja työläänä. Lisäksi tietovaraston ylläpitämiseen vaadittaisiin huomattavaa investointia ja riskinä pidetään myös sitä, että ERP:n tiedot päivittyvät nopeammin kuin tietovaraston, jolloin myös raportointi on haasta- vampaa. Käytännössä tämä tarkoittaa sitä, että raportointi tehdään Sandvikilla suoraan ERP-jär- jestelmistä sekä muista tarvittavista järjestelmistä.
Kuva 3. Sandvikin Business Intelligence - prosessi
Kuten kuvasta 3 huomaamme, on Sandvikin malli huomattavasti suoraviivaisempi kuin perintei- sen teorian esittämä raportointimalli. ETL-prosessia ja tietovarastoa ei ole käytössä, mikä aiheut- taa kuitenkin sen, että kyseinen työ on tehtävä jossain vaiheessa raportointia. Toisin sanoen ETL- prosessin mukainen tietojen hakeminen, muokkaaminen ja lataaminen jäävät raportin luojan vas- tuulle. Sandvikin tapauksessa raportin luoja on usein myös sen loppukäyttäjä. Tämä tarkoittaa, että työntekijöille annetaan valtava vastuu raportin datamallinnuksesta, joka vaatii myös osaa- mista.
Kun raportin luominen ja sen tietomallista huolehtiminen jätetään työntekijöiden vastuulle, tarkoit- taa se myös samalla sitä, että eri raporteille luodaan omia erillisiä tietomalleja Power BI – tieto- kantaan. Se taas johtaa lopulta siihen, että ERP-järjestelmää rasitetaan liikaa, jos raporttien tie- tomallit kyselevät keskenään samoja tietoja useaan kertaan eri raporteille. Tietovaraston etuna on se, että se suunniteltaisiin keskitetysti alan ammattilaisten toimesta. Tällöin ERP-järjestelmä rasittuu mahdollisimman vähän, jolloin vältetään riski järjestelmän merkittävästä hidastumisesta tai pahimmillaan kaatumisesta väärin tehtyjen kyselyiden takia. Periaatteen tasolla tavallisella käyttäjällä on siis mahdollisuus hidastaa koko yhtiön ERP-järjestelmää merkittävästi esimerkiksi tekemällä SQL-kyselyn kaikista relaatiotietokannan tauluista ja niiden riveistä. Tämän virheen voisi joku käyttäjistä tehdä periaatteessa myös tietämättömyyttään. Tässä diplomityössä suunni- teltava tietomalli on siis periaatteessa kuin ”logistiikalle räätälöity tietovarasto”. Nyt huomaamme Sandvikin tietovarasto-ongelman olevan yksi tärkeä tutkimusongelma.
2.3 Tietokuutio
Toinen vaihtoehto ETL-prosessissa tietojen lataamiselle ja yhdistämiselle olisi siirtää tarvitut tie- dot ERP-järjestelmästä niin sanottuun ”tietokuutioon” (engl. data cube). Tietokuutio on yleistermi, jolla kuvataan moniulotteisuuden visualisointeja. Tietokuutio on myös käytetyin looginen malli mo- niulotteisen tiedon esittämiseksi. Tietokuutio on dimensioiden rajoittama avaruus. Yksittäiset di- mensioattribuutit tai dimensioatrubuuttien joukot rajaavat tietokuutiosta pienempiä osa-avaruuk- sia: tietokuutio toisin sanoen rakentuu pienemmistä tietokuutioista. Toisiinsa liittyvien tietokuuti- oiden kokoelma muodostaa moniulotteisen tietokannan (engl. multidimensional database, MDD).
(Pendersen & Jensen, 2001)
Tietokuutio on siis eräänlainen sovellutus tietovarastosta. Tarkoituksena on erityisen suurten da- tamäärien hallinta. Tämä voisi tarkoittaa Sandvikin tapauksessa esimerkiksi globaalisti ERP-jär- jestelmien yhdistämistä samaan tietokuutioon, mikä mahdollistaisi globaalien raporttien kehittä- misen paljon joustavammin ja helpommin. Joka tapauksessa tietokuution luominen olisi vielä suu- rempi operaatio kuin tietovaraston, varsinkin Sandvikin kokoiselle suuryritykselle.
3. TIETOMALLINNUKSEN TEORIAA JA POWER BI
Tietomallinnukseen hyödynnetään tässä työssä Microsoftin Power BI – järjestelmää. Siksi tutus- tumme tarkemmin kyseiseen järjestelmään ja tietomallinuksen tekniikoihin. Tämän tutkimuksen kannalta merkittävää on erityisesti erilaisten kyselyiden tekeminen tietokannasta ja niiden yhdis- täminen relaatioiden avulla yhtenäiseksi tietomalliksi. Tietomallista taas saadaan tehtyä raportteja Power BI:n avulla.
3.1 Microsoft Power BI
Microsoft julkaisi vuonna 2015 datan raportointiin ja analysointiin Power BI – nimisen palvelun.
Kyse on siis suhteellisen uudesta järjestelmästä, joten sitä ei ole vielä useissa yrityksissäkään ehditty omaksumaan vahvasti.
Power BI Desktopin avulla voi tehdä seuraavia toimenpiteitä:
- Yhdistää tietoja, mukaan lukien useita tietolähteitä.
- Tietoja muotoillaan kyselyillä, joilla voidaan luoda oivaltavia ja vaikuttavia tietomalleja.
- Luoda visualisointeja ja raportteja tietomallien avulla.
- Raportin tiedostojen jakaminen, jolloin muut voivat hyödyntää ja jakaa niitä itse.
- Power BI Desktopin .pbix-tiedostojen jakaminen, kuten minkä tahansa muidenkin tiedos- tojen, mutta tehokkain tapa on ladata ne Power BI -palveluun.
Tietoanalyytikot ja muut voivat luoda kyselykokoelmia, tietoyhteyksiä, malleja ja raportteja ja ja- kaa ne helposti muiden kanssa. Power BI Desktopin (tietokoneen työpöytäsovelluksen) ja Power BI -palvelun (web-selain pohjainen) yhdistelmällä merkityksellisiä tietoja on helpompi mallintaa, luoda, jakaa ja laajentaa.
3.2 DAX-funktiokieli
DAX on lyhenne sanoista Data Analysis Expressions. Se on kaavakieli, jota käytetään Power BI:ssä (Power BI käyttää sitä myös taustalla). DAX on käytössä myös muissa Microsoftin palve- luissa (esimerkiksi Power Pivotissa ja SSAS:n taulukkomuodossa). DAX on funktionaalinen kieli, mikä tarkoittaa sitä, että täysi suoritettava koodi sisältyy funktioihin. (Microsoft Corporation Oy, 2020)
3.2.1 Syntaksi
Syntaksi sisältää eri elementtejä, jotka muodostavat kaavan, tai yksinkertaisemmin ilmaistuna se kertoo, kuinka kaava on kirjoitettu. Otetaan esimerkiksi DAX:lla luotu mittari ”Total sales”:
Kuva 4. DAX-funktion syntaksi (Microsoft Corporation Oy, 2020)
Tämä kaava sisältää seuraavat syntaksielementit:
A. Mittarin nimi Total Sales.
B. Yhtäläisyysmerkkioperaattori ( = ), joka ilmaisee kaavan alun. Kun laskutoimitus on tehty, se palauttaa tuloksen.
C. DAX-funktio SUM, joka laskee yhteen kaikki Sales[SalesAmount] -sarakkeen luvut. Funkti- oista on lisätietoja jäljempänä.
D. Kaarisulkeet () , jotka ympäröivät lauseketta, joka sisältää yhden tai useampia argumentteja.
Kaikki funktiot vaativat vähintään yhden argumentin. Argumentti välittää arvon funktiolle.
E. Viitattu taulukko Sales-taulukko.
F. Viitattu sarake [SalesAmount] Sales-taulukossa. Tämän argumentin avulla SUM-funktio tie- tää, mihin sarakkeeseen SUM eli summa koostetaan.
3.2.2 Funktiot
Funktiot ovat ennalta määritettyjä kaavoja, jotka suorittavat laskutoimituksia käyttämällä erityisiä arvoja eli argumentteja tietyssä järjestyksessä tai tietyssä rakenteessa. Argumentit voivat olla muita funktioita, muita kaavoja, lausekkeita, sarakeviittauksia, numeroita, tekstiä, loogisia arvoja, kuten TOSI tai EPÄTOSI, tai vakioita.
DAX sisältää seuraavat funktioluokat: päivämäärä- ja aikafunktiot, aikatietofunktiot, tietofunktiot, loogiset, matemaattiset ja tilastolliset funktiot, tekstifunktiot, pääkohde-/alikohdefunktiot ja muut
funktiot. Monet DAX-kielen funktiot vaikuttavat vastaavanlaisilta kuin Excel-funktiot. DAX-funktiot ovat kuitenkin ainutlaatuisia seuraavin tavoin:
o DAX-funktio viittaa aina kokonaiseen sarakkeeseen tai taulukkoon. Jos halutaan käyttää vain tiettyjä arvoja taulukosta tai sarakkeesta, voidaan lisätä kaavaan suodattimia.
o Jos laskutoimituksia on mukautettava rivikohtaisesti, voidaan tiettyjen DAX-funktioiden avulla suorittaa kontekstin mukaan vaihtelevia laskutoimituksia käyttämällä nykyistä rivin arvoa tai liittyvää arvoa eräänlaisena argumenttina.
o DAX sisältää monia funktioita, jotka palauttavat arvon sijasta taulukon. Taulukkoa ei näytetä, mutta sitä käytetään luomaan syötteitä muille funktioille. Voimme esimerkiksi noutaa taulukon ja laskea sitten sen eri arvot tai laskea dynaamisia summia suodatetuissa taulukoissa tai sa- rakkeissa.
o DAX sisältää erilaisia aikatietojen funktioita. Näiden funktioiden avulla voidaan määrittää tai valita päivämäärävälejä ja suorittaa näihin perustuvia dynaamisia laskutoimituksia. Voimme esimerkiksi verrata rinnakkaisten vuosineljännesten summia.
o Excelissä on suosittu funktio, PHAKU. DAX-funktiot eivät käsitä solua tai solualuetta viit- teeksi, kuten PHAKU tekee Excelissä. DAX-funktiot ottavat viitteeksi sarakkeen tai taulukon.
On siis hyvä ymmärtää, että Power BI Desktopissa työskennellään relaatiotietomallin kanssa.
Arvojen hakeminen toisesta taulukosta on helppoa, ja useimmissa tapauksissa ei tarvitse luoda kaavoja lainkaan.
3.3 Tietomallinnus ja Power BI
Power BI:ssa puhutaan tietomallien kohdalla ”dataseteistä”. Datasetit sisältävät ohjelmaan tuo- dun datan sekä SQL-kyselyt, joita käytetään raporttien luomiseen. Kun datasettiä käyttävä Power BI -raportti julkaistaan PowerBI.com-sivustolla, tiedot sijoitetaan automaattisesti omaksi data- setikseen samassa työtilassa kuin mihin valmis raportti julkaistaan. Sen lisäksi, että datasetti toi- mii tietolähteenä raportille, voidaan sivustolle ladattuja datasettejä hyödyntää tietolähteinä myös tuleville raporteille (Larson, 2020). Toimintaperiaate on tällöin hyvin samanlainen kuin tietovaras- toissa.
Power BI: ssä käytetty datamallimoottori on sama, jota käytetään Power Pivot for Excel -sovel- luksessa. Datan mallintaminen ei ole yrityskäyttäjille usein tuttu termi, koska se on yleensä alan ammattilaisten vastuulla. Power BI ja Power Pivot for Excel ovat kuitenkin ratkaisuja tähän. (Holy Macro! Books, 2018)
Datan mallintaminen on prosessi, jolla tietoja haetaan eri lähteistä, tietojen lataamista, jäsentä- mistä ja liittämistä loogisesti muihin tietoihin. Lisäksi mallintamiseen kuuluu datan parantaminen ja yleinen valmistelu käytettäväksi. Tavoitteena on, että dataa voidaan käyttää ilman, että tarvit- see kirjoittaa mukautettua kyselyä joka kerta, kun halutaan tarkastella jotain tiettyä osaa datasta.
(Holy Macro! Books, 2018)
Tietojen mallintamisprosessi alkaa analysoitavan lähdetiedon optimaalisen rakenteen ja muodon määrittämisellä ja tietojen lataamisella lähteestä tietomalliin (tässä tapauksessa Power BI). Seu- raavaksi eri taulujen väliset loogiset suhteet määritellään (tekniikka on sama kuin Excelin VLOOKUP-funktiossa, paitsi että tiedot pysyvät tallessa Power BI:n lähdetaulussa). Lopuksi suo- ritetaan tietotyyppien määrittäminen eli onko jonkin sarakkeen tiedot numeerisia, valuutta-arvoja, päiviä tai tekstiä. (Holy Macro! Books, 2018)
3.3.1 Relaatiot taulujen ja kyselyiden välillä
Jotta Power BI voisi ymmärtää raporteissa käytettävää dataa, on raportin taustalla oltava toimiva tietomalli eli käytännössä tietokantaa vastaava tauluista ja niiden välisistä relaatioista muodos- tuva kokonaisuus. Seuraavaksi käsiteltävää esitystapaa käytämme niin Power BI:ssä kuin myös tutkimuksen myöhemmissä esityksissä luvussa 5. Power BI käsittelee yksittäisiä SQL-kyselyitä kuin omina tietokannan tauluinaan. Siksi jokaiselle taululle eli kyselylle pyritään kuvaamaan tar- vittavat relaatiot, jos niitä tarvitaan. Jos relaatiota ei ole kuvattu, niin silloin sille ei myöskään ole tarvetta.
Kun olemme muodostaneet relaation kahden taulukon välille, voimme käsitellä molempien taulu- koiden tietoja aivan kuin ne olisivat samassa taulukossa. (Microsoft Corporation Oy, 2020) Re- laatioille määritellään Power BI:ssä aina myös kardinaliteetti sekä suodatuksen suunta.
Kardinaliteetti-asetuksella voi olla jokin seuraavista arvoista:
o Monta yhteen (*:1): Monta yhteen -suhde on yleisin suhdetyyppi ja myös suhdetyypin oletus- asetus. Monta yhteen -tyyppi tarkoittaa sitä, että arvo voi esiintyä toisessa taulukossa use- ammin kuin kerran ja esiintyä vain kerran toisessa taulukossa, jota kutsutaan usein hakutau- lukoksi.
o Yksi yhteen (1:1): Yksi yhteen -suhteessa tämä tarkoittaa, että tietty arvo esiintyy vain kerran kummassakin taulukossa, joiden välille on muodostettu suhde.
o Yksi moneen (1:*): Yksi moneen -suhteessa arvo esiintyy vain kerran toisen taulukon sarak- keessa, ja toisessa liittyvässä taulukossa arvo voi esiintyä useammin kuin kerran.
o Monta moneen (*:*): Yhdistelmämallien avulla voit muodostaa Monta moneen -yhteyksiä tau- lukoiden välille, mikä poistaa taulukoiden yksilöllisten arvojen vaatimukset. (Microsoft Corporation Oy, 2020)
Suodatuksen suunta-asetuksella voi olla jokin seuraavista arvoista:
Molemmat: Suodatuksessa molempia taulukoita käsitellään yhtenä taulukkona. Molemmat-ase- tus toimii hyvin silloin, kun käsitellään yhtä taulukkoa, jossa on useita ympäröiviä hakutaulukoita.
Esimerkki on myyntitulostaulukko, jossa on osaston hakutaulukko. Tätä kokoonpanoa kutsutaan usein tähtirakenteeksi (päätaulukko, jolla on useita hakutaulukoita). Jos kuitenkin halutaan käsi- tellä vähintään kahta taulukkoa, joilla on myös hakutaulukoita (joista osa on yhteisiä), niin Molem- mat-asetusta ei kannata käyttää.
Yksittäinen: Yleisin, ja oletussuunta, mikä tarkoittaa, että yhdistettyjen taulukoiden suodatusva- linnat toimivat siinä taulukossa, johon arvot kerätään. (Microsoft Corporation Oy, 2020)
3.3.2 Kyselyiden yhdistäminen
Joskus dataa analysoidessa tulee vastaan tilanteita, joissa on yksinkertaisempaa yhdistää kaksi eri kyselyä. Näin saadaan yksi yhtenäinen kysely, johon on rajattu vain tarvittavia tietoja, jolloin datan muotoilu Power BI:ssä on helpompaa. Kyselyiden yhdistäminen on kätevää erityisesti kun halutaan vertailla kahden eri kyselyn tietoja keskenään.
Kyselyitä voi yhdistää kahdella tavalla: yhdistämällä tai loppuun liittämällä. Käyttäjää saatetaan pyytää määrittämään yksityisyystaso. Näin varmistetaan, että tiedot yhdistetään siten, ettei sisäl- lytetä tai siirretä tietoja, joita ei haluta. Power BI avaa Yhdistä-ikkunan (kuva 5). Siinä kysytään, mikä taulukko halutaan yhdistää valittuun taulukkoon ja pyydetään määrittämään yhdistämisen vastaavat sarakkeet (Microsoft Corporation Oy, 2020). Liittämisen lajia valittaessa voidaan valita esimerkiksi vertailtavasta taulusta ne rivit, jotka eivät esiinny toisessa tai rivit, jotka esiintyvät mo- lemmissa kyselyissä.
Kuva 5. Kahden eri kyselyn yhdistäminen Power BI:ssä Jatkossa kutsumme tässä tutkimuksessa kyselyiden yhdistämistä Merge-tekniikaksi.
3.3.3 Suodattimet
Suodattimet tarjoavat vähemmän vuorovaikutteisen, mutta joustavan ja tehokkaan mekanismin muokkaamaan raportin sisältöä ja käytettävää dataa. Suodattimet poistavat kaikki muut tiedot paitsi ne, joihin haluat keskittyä. Tietoja voi suodattaa Power BI:ssä monin eri tavoin.
Suodattimet-ruutu (kuva 6) sisältää suodattimia, jotka raportin suunnittelija on lisännyt raporttiin.
Käyttäjät voivat käyttää olemassa olevia suodattimia ja tallentaa muutokset, mutta ei ole mahdol- lista lisätä uusia suodattimia raporttiin. Esimerkiksi seuraavassa kuvassa suunnittelija on lisännyt kolme sivutason suodatinta: Segmentti on Kaikki, Vuosi on 2014 ja Alue on Keski. Käyttäjä voi käyttää ja muuttaa näitä suodattimia, mutta ei lisätä neljättä sivutason suodatinta. (Microsoft Corporation Oy, 2020)
Kuva 6. Esimerkki Power BI-raportin suodattimista
Power BI-palvelussa raportit säilyttävät muutokset, jotka tehdään Suodattimet-ruudussa. Palvelu siirtää nämä muutokset myös raportin mobiiliversioon (Microsoft Corporation Oy, 2020).
Voimme etsiä tiedoista merkityksiä suodattimien avulla (kuva 7). Voimme muokata suodatinvalin- toja kentän nimen vieressä olevalla avattavan valikon nuolella. Vaihtoehdot vaihtelevat yksinker- taisista valinnoista päivämäärä- ja lukualueisiin. Tämä riippuu Power BI:n suodattamasta tietotyy- pistä ja suodattimesta. Alla olevan esimerkin kehittyneessä suodattimessa vaihdetaan puukartan yksiköiden kokonaismäärä vuoden alusta suodattimen arvoksi 2 000–3 000. (Microsoft Corporation Oy, 2020)
Kuva 7. Suodattimien käyttö
3.3.4 Visualisoinnit
Visualisoinnit näyttävät merkityksellisiä tietoja datasta. Power BI -raportissa voi olla yksittäinen visualisointi yhdellä sivulla tai sivukaupalla visualisointeja. Power BI -palvelussa visualisointeja voi kiinnittää raporteista koontinäyttöihin. (Microsoft Corporation Oy, 2020) Käytännössä kaikki Power BI-raportit koostuvat vain joukosta erilaisia visualisointeja, joissa dataa mallinnetaan eri- laisiin kuvioihin, mittareihin ja kaavioihin.
On tärkeää erottaa toisistaan raporttien suunnittelija ja kuluttajat. Jos luot tai muokkaat raporttia, olet suunnittelija. Suunnittelijoilla on raportin ja sen pohjana olevan tietojoukon muokkausoikeu- det. Jos raportti tai koontinäyttö on jaettu kanssasi, olet raportin kuluttaja. Voit tarkastella ja käsi- tellä raporttia ja sen visualisointeja, mutta et voi tehdä yhtä paljon muutoksia kuin suunnittelija.
Power BI:ssä on monta erilaista visualisointityyppiä käytettävissä suoraan Visualisoinnit-ruu- dusta. (Microsoft Corporation Oy, 2020) Visualisointityyppejä (kuva 8) ovat esimerkiksi pylväsdia- grammi, viivadiagrammi ja matriisi.
Kuva 8. Visuaalityypit Power BI:ssä
3.3.5 Koosteet ja count-tekniikka
Joskus on tarpeen yhdistellä tiedoissa olevia arvoja matemaattisesti. Laskutoimituksena voi olla esimerkiksi summa, keskiarvo, suurin arvo tai lukumäärä. Kun yhdistetään tietojen arvoja, sitä kutsutaan koostamiseksi. Tämän laskutoimituksen tulos on kooste. (Microsoft Corporation Oy, 2020) Koosteiden etuna on se, etteivät ne rasita suuria raportteja ja tietomääriä. DAX-funktiot vaativat enemmän laskentatehoa, koska funktiot yleensä luovat uuden sarakkeen johonkin Power BI - raportin tietomalliin.
Useimmat tietojoukot sisältävät useita tietotyyppejä. Aivan perustasollaan tieto on joko numeeri- nen tai ei-numeerinen. Power BI voi koostaa numeerisia tietoja käyttämällä esimerkiksi summaa, keskiarvoa, määrää, pienintä arvoa ja varianssia. Palvelu voi koostaa jopa tekstimuotoista tietoa, jota kutsutaan luokittaiseksi tiedoksi. Tietynlaisilla tiedoilla, kuten päivämäärillä, on eräitä omia
koostevaihtoehtojaan: aikaisin, viimeisin, ensimmäinen ja viimeinen. (Microsoft Corporation Oy, 2020) Koosteita voidaan hyödyntää myös raportin suodattimissa.
Tässä on eräitä asetuksia, jotka voivat olla käytettävissä kentän koostamiseen:
o Älä tee yhteenvetoa. Kun tämä asetus on valittu, Power BI käsittelee jokaista kyseisen ken- tän arvoa käsitellään erikseen, eikä laske niitä yhteen. Käytä tätä asetusta, jos sinulla on numeerinen tunnistesarake, jota palvelun ei tule laskea yhteen.
o Summa. Tämä laskee yhteen kaikki kyseisen kentän arvot.
o Keskiarvo. Laskee arvoista aritmeettisen keskiarvon.
o Pienin arvo. Näyttää pienimmän arvon.
o Suurin arvo. Näyttää suurimman arvon.
o Määrä (ei tyhjä). Tämä laskee kentän niiden arvojen määrän, jotka eivät ole tyhjiä.
o Määrä (erillinen). Tämä laskee tämän kentän eri arvojen määrän.
o Keskihajonta.
o Varianssi.
o Mediaani. Näyttää mediaaniarvon eli joukon keskimmäisen arvon. Tämä on arvo, jonka ylä- ja alapuolella on sama määrä kohteita. Jos mediaaneja on kaksi, Power BI laskee niiden keskiarvon. (Microsoft Corporation Oy, 2020)
Jatkossa käytämme koosteesta, jossa lasketaan määrää nimitystä count-tekniikka. Rivien mää- rän laskeminen useissa eri tietojoukoissa on erittäin olennaista ja toistuu tässä tutkimuksessa usein.
3.4 Data vault
Seuraavaksi tutustumme Data vault – mallinnustekniikkaan, jonka avulla voidaan rakentaa erilai- sia tietomalleja. Kuten tulemme huomaamaan, on Data vault – tekniikan ideana vastata mahdol- lisimman joustavasti ja laajasti yrityksen erilaisiin raportointitarpeisiin eli tämän diplomityön kan- nalta juuri olennaisiin asioihin. (Linstedt & Olschimke, 2016)
Dan Linstedt keksi Data Vault -mallin 1990-luvulla, ja se on suunnattu monimutkaisiin verkkoihin, joita esiintyy usein luonnossa. Monet näistä luonnollisista järjestelmistä voidaan kuvata monimut- kaisten verkkojen malleina, jotka ovat rakenteita, jotka koostuvat solmuista ja pisteistä, jotka on kytketty toisiinsa erilaisin linkein. Esimerkkinä ihmisen aivot, joka on neuronien verkosto. Toinen esimerkki luonnosta on ihmisten muodostama verkosto. Globaali talous on toinen esimerkki; se on kansallisten talouksien verkosto, joka koostuu markkinoiden verkostosta. Nämä markkinat koostuvat puolestaan tuottajien ja kuluttajien verkostoista. Näillä verkoilla on yhteistä se, että niissä on keskittymiä ja solmukohtia, jotka muodostuvat esimerkiksi henkilöistä tai muista asioista,
niiden välisistä linkeistä ja tiedoista, jotka kuvaavat asioita kontekstissaan. (Linstedt & Olschimke, 2016)
Aikaisemmin tutkijat olettivat, että nämä verkot olivat luonteeltaan satunnaisia eli linkkien sijoittu- minen keskittymien ja solmukohtien välillä olisi satunnaista, ja että useimmissa solmukohdissa olisi suunnilleen sama määrä linkkejä. (Linstedt & Olschimke, 2016)
Kuva 9. Yhdysvaltojen moottoritiejärjestelmä: satunnainen verkko
Satunnaisessa verkossa, kuten Yhdysvaltojen moottoritiejärjestelmä (kuva 9), useimpien solmu- kohtien välillä on vain muutama linkki. Tämä ominaisuus on tulosta monista historiallisista pää- töksistä, jotka johtuvat maantieteellisistä, poliittisista ja taloudellisista tekijöistä. Esimerkiksi moot- toritien rakentamiskustannukset yleensä rajoittavat järjestelmään lisättävien moottoriteiden mää- rää. Sama pätee Yhdysvaltain lentoyhtiöjärjestelmään (kuva 10). Ero on kuitenkin siinä, että ver- kon laajentaminen on paljon helpompaa lisäämällä uusia yhteyksiä lentokenttien välille, jotka ovat tämän verkon solmukohtia. Verkoston kokonaisrakenne määräytyy pääasiassa lentoyhtiöiden sa- manaikaisista toimista, kun yhtiöt yrittävät maksimoida tuloksensa. (Linstedt & Olschimke, 2016)
Kuva 10. Yhdysvaltojen lentokonejärjestelmä: vapaasti skaalattava verkko
Data Vault -mallin tavoitteena on edustaa yritystä mahdollisimman tarkasti. Ajatellaan tätä tavoi- tetta yrityksen kriittisten ominaisuuksien kautta, joita ovat esimerkiksi seuraavat:
- Kyky reagoida nopeasti muuttuviin liiketoimintavaatimuksiin, joka tunnetaan myös nimellä ketteryys.
- Eri tietolähteiden integrointi uuden tiedon luomiseksi.
- Liiketoimintaympäristön ja joskus itse organisaation monimutkaisuus.
- Joustavuus siirtyä uusiin markkinointimahdollisuuksiin.
- Avoimuuden ja vastuuvelvollisuuksien tarve, erityisesti yrityksen tilintarkastajille.
- Kyky vastata tietotarpeisiin erilaisilla räätälöidyillä raporteilla.
- Kyky skaalata yritystä onnistumisten jälkeen.
Nämä avainominaisuudet antavat yritykselle mahdollisuuden selvitä nykypäivän kilpailluilla mark- kinoilla. Data Vault -malli (kuva 11) on suunniteltu siten, että se tukee kaikkia näitä ominaisuuksia, kun käyttäjät rakentavat tietovarastojärjestelmää. Kun käytetään Data Vault -tekniikkaa, pysty- tään tietovarasto sopeuttamaan mahdollisimman lähelle yrityksen tarpeita. (Linstedt & Olschimke, 2016)
Kuva 11. Data Vault – mallin arkkitehtuuri
Data Vault -mallin tavoitteiden saavuttamiseksi malli perustuu kolmeen peruskokonaisuuteen.
Nämä kokonaisuudet ovat solmukohdat, linkit ja satelliitit. Jokainen kokonaisuus palvelee tiettyä tarkoitusta: solmukohta erottaa liiketoiminnan pääkohdat mallista, linkki tallentaa solmukohtien väliset suhteet ja satelliitit tallentavat kontekstit (solmukohtien ja linkkien suhteen määritteet).
(Linstedt & Olschimke, 2016)
Tietovaraston toteutus perustuu Data Vaultissa tiedot yksilöiviin tunnisteisiin (liiketoiminta- avaimiin) ja tietojen hajautukseen. Talletettaville tiedoille lasketaan yksilöivien tunnisteiden poh- jalta hajautusavaimet. Kun tiedot viedään solmukohtien, satellittien ja linkkien -rakenteisiin, toi- siinsa liittyvät tiedot yhdistyvät toisiinsa samalla hajautusavaimen arvolla. Kun esim. asiakkaan tiedot ovat lähdejärjestelmässä muuttuneet, samoilla tunnistetiedoilla (esim. asiakasnumero) las- kettu hajautusavain liittää uudet versiot tiedoista aina aiempien tietojen rinnalle. Tietojen eriaikai- set versiot erotetaan toisistaan tietojen latauskellonajan perusteella. (Luoma-aho, 2018)
Hajautusavainten käyttö:
o Mahdollistaa suorat viittaukset
o Yksinkertaistaa ja tehostaa tietojen latausta ja hakuja
o Mahdollistaa rinnakkaisajot (myös MPP – Massive Parallel processing), koska
hajautusavaimet voidaan aina laskea lähdetietojen perusteella ilman riippuvuuksia muihin tie- toihin
o Tiedot voidaan rinnakkaisajojen jälkeen (esim. MPP) yhdistää toisiinsa hajautusavaimen pe- rusteella
o Mahdollistaa relaatiotietokannassa ja NoSQL -ympäristössä olevien tietojen yhdistämisen (samat hajautusavaimet)
(Luoma-aho, 2018)
4. LOGISTIIKAN PROSESSIT JA RAPORTIT
Tässä luvussa käsittelemme Sandvikin logistiikan ydinprosesseja eli sitä, miten logistiikka toimii, jotta lukijan olisi helpompi ymmärtää tutkimuksen taustoja. Tämän jälkeen käymme läpi logistiikan käytössä olevat Cognos-raportit, jotka lähtötilanne raportoinnille. Lopuksi käsittelemme raportoin- nissa havaittuja kehityskohteita, joita on peilattu vahvasti tutkimuksen tavoitteisiin.
4.1 Logistiikan ydinprosessit
Sandvikin logistiikka voidaan kuvata kokonaisuudessaan yksinkertaisella prosessikaaviolla (kuva 12). Logistiikan keskiössä on osto-varasto, johon otetaan vastaan kaikki nimikkeet, jotka on help- poa keräillä käsin ja mahtuvat EURO-lavalle. Lisäksi suuri määrä nimikkeitä varastoidaan Steve Oy:n tiloissa Turussa, eli Sandvik käyttää ulkoista varastoa, jotta yritys voisi keskittyä paremmin ydinbisnekseensä. (Vainio, 2018)
Kuva 12. Yksinkertaistettu malli logistiikan ydinprosesseista (Vainio, 2018)
Tärkeää tutkimuksen kannalta on ymmärtää se, että jokainen yllä kuvatun prosessin vaiheista sisältää dataa, jota voidaan kerätä tavalla tai toisella. Toisin sanoen logistiikka voidaan nähdä myös eräänlaisena informaatiovirtana, jonka tulisi olla mahdollisimman paikkaansa pitävä.
4.2 Logistiikan Cognos-raportit
Selvityksessä ilmeni, että logistiikalla on käytössään Cognos-raportteina lopulta vain neljä eri- laista raporttia, jotka koskevat tätä tutkimusta. Raportit kuvataan alla näkyvässä taulukossa 1 sanallisesti sekä tutkimuksen lopussa liitteinä. Riveistä puhuttaessa tarkoitetaan Lean-tietokan- nan rivejä eli esimerkiksi vastaanottorivi tarkoittaa osaa X, jota on saapunut Y kappaletta. Ku- vaamme seuraavaksi tutkimuksen lähtötilanteen.
Taulukko 1: Cognos-raporttien sisältö
Nimi Sisältö
Lähtevien koneiden ennuste
(Machine shipment forecast, liite 1) Piirtää kaavion valmiiden kaivinkoneiden määrästä vii- koittain, jotka lähtevät Sandvikin Turun tehtaan lähettä- möstä asiakkaille.
Keräilyrivien ennuste (Picking row
forecast, liite 2) Piirtää kaavion keräilyrivien määrän ennustetusta kehi- tyksestä viikoittain. Sisältäen vain ne keräilyt, jotka teh- dään Turun tehtaan sisäkeräilyssä.
Vastaanottorivien ennuste (Re- ceiving row forecast, liite 3)
Piirtää kaavion vastaanottorivien määrän ennustetusta kehityksestä viikoittain. Sisältäen vain ne osat, jotka saapuvat suoraan Turun tehtaan vastaanottoon.
Ei hyllypaikkaa -saldoseuranta (Items OSTO - EI HYLLYPAIKKAA Stock Location, liite 4)
Luo listan niistä nimikkeistä, jotka sijaitsevat järjestel- mässä paikalla ”EI HYLLYPAIKKAA” ja saldo on otettu järjestelmään vastaan yli kolme viikkoa sitten.
4.3 Kehityskohteet
Kehityskohteita raportoinnissa koettiin olevan paljon. Aikaisempien neljän raportin lisäksi koettiin tarpeelliseksi analysoida logistiikan jokaista osastoa erikseen niin tehokkuuden, työkuorman en- nusteen kuin myös mahdollisesti työn laadun seurannan osalta. Erityisesti laadun seuranta on koettu aiemmin vaikeaksi. Jo aiemmissa tutkimuksissa on todettu seuraavasti:
Työn laatua ei valvota lainkaan, jolloin voidaan olettaa, että saldovirheiden määrä kasvaa työnte- kijöiden tehdessä huolimatonta työtä. Saldovirheisiin vaikuttavia suoria tekijöitä ovat kaikki työ- vaiheet, joita logistiikassa ylipäätään tehdään, koska saldovirheet korreloivat suoraan työn laatua.
(Vainio, 2018)
Tästä voimme päätellä, että työn laadun analysoimiseksi erityisesti saldotietojen seuranta suo- raan tietokannasta on tärkeässä roolissa. Oletuksena on, että toisinaan saldojen seuranta kertoo myös suoraan virheen juurisyyn. Lähtökohtaisesti oletamme kuitenkin, että varsinaisen juurisyyn ja virheen löytäminen työvaiheista vaatii vielä oman erillisen analysointinsa käyttäjältä. Virheitä saadaan siis paljon esille, mutta niiden juurisyytä ei välttämättä.
Seuraavaksi esitämme taulukossa 2 kaikki ne raportit, jotka tässä työssä halutaan toteuttaa. Li- säksi taulukossa on huomioitu edellä mainitut Cognos-raportit, jotka pyritään ”upottamaan” osaksi tulevia laajempia Power BI-raportteja.
Taulukko 2: Power BI-raporttien tavoitteet
Nimi Sisältö
Vastaanotto (Tehokkuus, työkuor-
man ennuste ja laatu, liite 6) - Vastaanotettujen rivien osuus: Kuinka suuri osa kun- kin päivän tilauksista on vastaanotettu tai edelleen saapumatta.
- Tilausrivien määrä: Ennuste kuinka paljon tavaraa on saapumassa Turun tehtaan vastaanottoon päivittäin.
Eriteltynä profiili- ja settiosien suhde (suora siirto Cog- nos-raportista).
- Hyllytysjonon suuruus: Kuinka monta eri nimikettä on edelleen hyllyttämättä, eriteltynä onko tavara seissyt jonossa yli päivän.
- Hyllytetyt rivit päivittäin: Kuinka monta eri nimikettä on hyllytetty vastaanotosta päivittäin.
- Kesken jääneet vastaanotot: Lista nimikkeistä, jotka jääneet keskeneräiseen tilaan yli kolmeksi päiväksi.
Työntekijätehokkuus (Vastaanotto
ja hyllytys, liite 7) - Hyllytettyjen rivien määrä: Eritellään eri nimiketyyp- pien perusteella kuinka paljon mitäkin nimiketyyppiä on hyllytetty.
- Hyllytys ja vastaanotto tekijöittäin: Mahdollisuus ver- tailla eri työntekijöiden välistä osuutta hyllytysten ja vastaanottojen määrässä.
- Vastaanotettujen rivien määrä: Vastaanotettujen rivi- määrien kehitys kolmen kuukauden ajalta eriteltynä työntekijöittäin.
- Palautukset tekijöittäin: Mahdollisuus vertailla eri työntekijöiden välistä osuutta palautettujen rivien mää- rässä.
- Työntekijän valitsin: Raportilla oltava mahdollisuus suodattaa tietoja niin, että dataa voidaan tarkastella vain yksittäisen työntekijän kohdalta tai useamman va- litun työntekijän välillä.
Vasteajat ja teho (Kaikki logistiikan keräilyt ja trukkikuskien järjestely- tehtävät, liite 8)
- Vasteaikojen kehitys: Logistiikan vasteaikojen kehitys viikoittain.
- Keskimääräisen yksilötehon kehitys: Kuinka suurella teholla yksittäinen työntekijä on keskimäärin keräillyt tai tehnyt trukkikuskien järjestelytehtäviä.
- Suoritettujen tehtävien ja rivien määrä: Kuinka paljon erityyppisiä keräilytehtäviä ja rivejä on tehty viikoittain.
- Työntekijän ja keräilytyypin valitsin: Raportilla oltava mahdollisuus suodattaa tietoja niin, että dataa voidaan tarkastella vain yksittäisen työntekijän kohdalta tai use- amman valitun työntekijän välillä. Lisäksi tietoja on voi- tava suodattaa vastaavasti eri keräilytyyppien mukaan (esim. sisä- ja ulkokeräily).
