Kandidatuppsats
Affärssystemprogrammet 180 hp
Kvalitet i masterdata
En studie som bidrar med kunskap kring hur
organisationer kan öka kvaliteten i sin masterdata
Informatik 15 hp
Halmstad 2020-06-04
Andrej Glusac och Karin Birge
Förord
Vi vill rikta ett stort tack till alla som på något sätt har bidragit till denna studie, framförallt de som har tagit sig tiden med att bli intervjuade. Tack vare alla individer som har bidragit till denna studie har vi kunnat svara på frågeställningen och kunnat uppnå syftet med studien. Vi vill även rikta ett stort tack till vår handledare Ewa Zimmerman som under hela processen har väglett, hjälpt och stöttat oss. Slutligen vill vi tacka alla de studenter som vid ett flertal
opponeringtillfällen har bidragit med feedback och konstruktiv kritik. Tack!
Halmstad, 2020
___________________________ ___________________________
Andrej Glusac Karin Birge
Abstrakt
Vi lever i ett digitaliserat samhälle där masterdatavolymerna ständigt ökar i organisationers affärssystem. I takt med att volymerna av masterdata ökar, ökar även risken för problem med kvaliteten i masterdata. Kvaliteten styrs av hur korrekt, komplett och konsekvent masterdata är, och dålig kvalitet kan orsaka en rad olika konsekvenser för organisationer. Dålig kvalitet i masterdata kan även påverka implementationer av affärssystem negativt. Till exempel kan driftkostnaderna öka eller projekten bli försenade om kvaliteten måste bearbetas under implementationen. Studiens syfte är därför att undersöka och skapa förståelse för varför organisationer bygger upp dålig kvalitet i masterdata och vilka konsekvenser det kan få på implementationer av affärssystem. Studiens resultat indikerar på att dålig kvalitet i masterdata byggs upp eftersom organisationer erhåller ökade mängder av masterdata. Det finns en bristfällig kunskap kring vilken påverkan dålig kvalitet kan ha på organisationer och det finns ett bristfälligt ägandeskap samt bristfälliga processer kring hur masterdata bör hanteras. Studiens resultat indikerar också på att dålig kvalitet i masterdata i samband med en implementationer av affärssystem leder till ökade kostnader. Studiens slutsatser är formulerade med rekommendationer för hur affärssystemkonsulter kan utveckla sina implementeringsmodeller. Detta för att förhindra att dålig kvalitet i masterdata påverkar implementationer av affärssystem. Till exempel rekommenderas affärssystemkonsulter att lägga till ett steg i modellerna. Steget ska bestå av att de informerar sina kunder att bearbeta kvaliteten i masterdata innan implementationen inleds. Steget bör därför vara det första i implementeringsmodeller. Studiens slutsatser är även formulerade med rekommendationer för hur organisationer kan uppnå kvalitativ masterdata.
Abstract
We live in a digitized society where masterdata volumes are constantly increasing in organizations' business systems. As the volumes of masterdata increase, so does the risk of problems with the quality of the master data. Quality is governed by how accurate, complete and consistent masterdata is and poor quality can cause a variety of consequences for organizations. Poor quality in masterdata can also adversely affect the implementation of business systems. For example, operating costs may increase or projects may be delayed if the quality has to be processed during implementation. The purpose of the study is therefore to investigate and create an understanding of why organizations build up poor quality in masterdata and what the consequences it can have on the implementation of business systems. The result of the study indicates that poor quality in masterdata is built up because organizations receive an increased amount of masterdata. There is a lack of knowledge about what impact poor quality can have on organizations and there is a lack of ownership and inadequate processes regarding how masterdata should be managed. The result of the study also indicates that the consequences of poor quality in masterdata in conjunction with an implementation of business systems leads to increased costs. The conclusions of the are formatted with recommendations for how business system consultants can develop their implementation models. This to prevent poor quality in masterdata from affecting the implementation of business system. For example, business system consultants are recommended to add a step to the models, which consists of informing their customers to process the quality of the master data before the implementation begins. The step should therefore be the first in implementation models. The conclusion is also formatted with recommendations for how organizations can achieve qualitative masterdata.
Innehållsförteckning
1 Inledning ... 1
2 Relaterad litteratur ... 3
2.1 Implementering av affärssystem ... 3
2.2 Masterdata ... 3
2.3 Kvalitet i masterdata ... 4
2.4 Lagring av masterdata ... 5
2.5 Implementeringsmodeller ... 5
2.5.1 Hantering av masterdata i implementeringsmodeller ... 7
2.6 Litteratursammanställning ... 7
3 Metod ... 9
3.1 Forskningsansats ... 9
3.2 Litteraturstudie ... 9
3.3 Pilotintervjuer ... 10
3.4 Datainsamlingsmetod ... 10
3.5 Urval ... 11
3.6 Analysansats ... 13
3.7 Etiska övervägande ... 14
3.8 Metoddiskussion ... 14
4 Resultat ... 16
4.1 Respondentgrupp ett: masterdata kopplat till organisationen ... 16
4.1.1 Kvalitet i masterdata samt dess prioritering ... 16
4.1.2 Hantering av masterdata ... 17
4.1.3 Lagring, rättigheter och gemensam masterdata ... 17
4.2.1 Implementationen i allmänhet ... 18
4.2.2 Start av masterdatahantering ... 19
4.2.3 Upptäckande av dålig kvalitet i masterdata ... 20
4.2.4 Kvalitetens påverkan samt erhållna erfarenheter ... 21
4.3 Respondentgrupp två - masterdata kopplat till organisationer ... 22
4.3.1 Bra respektive dålig kvalitet i masterdata ... 22
4.3.2 Konsekvenser och förebyggande av dålig kvalitet i masterdata ... 24
4.4 Respondentgrupp två - masterdata kopplat till implementationen ... 24
4.4.1 Implementeringsmodeller som används kopplat till masterdata ... 24
4.4.2 Masterdata i samband med implementationer ... 25
5 Analys ... 26
5.1 Ökade mängder av masterdata ... 26
5.2 Bristfällig kunskap ... 26
5.3 Bristfälligt ägandeskap och processer ... 27
5.4 Ökade kostnader ... 28
6 Diskussion ... 30
6.1 Varför dålig kvalitet i masterdata byggs upp ... 30
6.2 Konsekvenser på implementationer av affärssystem ... 31
6.3 Samhälleliga konsekvenser ... 32
6.4 Sammanfattning och rekommendationer ... 32
7 Slutsats ... 34
7.1 Framtida forskningsförslag ... 34 Referenslista
Bilagor Bilaga 1 Bilaga 2
1
1 Inledning
Ett affärssystem är ett standardiserat verksamhetsövergripande systemstöd som syftar till att ta hand om organisationers informationshantering. Alla transaktioner, till exempel inköp och försäljningar, lagras och bearbetas i ett affärssystem och agerar stöd för organisationer vid exempelvis planering eller produktion (Magnusson & Olsson, 2009).
Den data som utgör kärnan av centrala affärstransaktioner, exempelvis kunder, artiklar och leverantörer beskrivs och identifieras av masterdata (Vilminko-Heikkinen & Peekola, 2017;
Prokhorova & Kolesnik, 2018; Brunner, Ma, Wang, Zhang, Wolfson, Pan & Srinivas, 2007;
Griffin, 2006). Otto, Hüner och Österle (2012) skriver att masterdata är organisationens viktigaste affärsobjekt som används i flera integrerade system. Det beror på att masterdata innehåller nödvändig information, till exempel pris på en produkt eller adress till en kund, som behövs för att skapa inköps- eller försäljningsordrar.
Vi lever i ett digitaliserat samhälle där masterdatavolymer ständigt ökar (Hazel, Weigel, Ezell, Boehmke & Bradley, 2017). Affärssystemet behöver därför vara uppdaterat och utvecklas i takt med organisationen. I vissa fall kan detta innebära att systemet behöver bytas ut (Magnusson &
Olsson, 2009). Det finns ett flertal olika implementeringsmodeller att använda för att implementera affärssystem. Olika modeller hanterar arbetet kring masterdata i olika steg och på olika sätt. Några av de implementeringsmodeller som har legat till grund för efterforskningen i denna studie används för att implementera världsledande affärssystem, såsom Microsoft Dynamics och SAP.
I takt med att volymerna av masterdata ökar, ökar även risken för problem med kvaliteten i masterdata (Hazel et al., 2017). Kvaliteten styrs av hur korrekt, konsekvent och komplett masterdata är. Vid implementationen av affärssystem synliggörs ofta dålig kvalitet i masterdata som tidigare inte uppmärksammats (Xu, Nord, Brown & Nord, 2002; Lee, Pipino, Funk & Wang, 2006). Att den inte synliggjorts tidigare beror bland annat på att organisationer inte har haft ett affärssystem som kräver bra kvalitet i masterdata (Magnusson & Olsson, 2009)
Dålig datakvalitet i form av inkonsekvent, ofullständig eller oacceptabel masterdata kan påverka implementationer av affärssystem negativt (Shaul & Tauber, 2013). Till exempel kan driftkostnaderna öka eller projekten bli försenade om datakvaliteten måste bearbetas under eller efter att systemet har implementerats (Shaul & Tauber, 2013; Lee et al., 2006). Dålig kvalitet i masterdata kan även resultera i ökade kostnader inom organisationen. De problem som dålig kvalitet i masterdata medför kan kosta organisationer 8–12 procent av deras intäkter (Lee et al., 2006). I en undersökning, där 175 organisationer deltog, framkom det att 40% av organisationerna var omedvetna om att de har dålig kvalitet i sin masterdata samt vilka konsekvenser det kan medföra (Redman, 2008).
Tidigare forskning visar att många organisationer har problem med dålig kvalitet i sin masterdata.
Forskningen visar även att dålig kvalitet påverkar implementationer av affärssystem negativt (Hazel et al., 2017; Shaul & Tauber, 2013; Lee et al., 2006; Xu et al., 2002; Redman, 2008). Vad som leder fram till att masterdata får dålig kvalitet samt vilka konsekvenser det kan få på implementationer av affärssystem är dock ringa belyst. Det kan därmed vara av intresse för organisationer att få en ökad kunskap om vad som leder till att dålig kvalitet i masterdata orsakas och dess påverkan på implementationen. Detta leder fram till frågeställningen: Varför bygger organisationer upp dålig kvalitet i sin masterdata och vilka konsekvenser får det på implementationer av affärssystem?
2 Syftet med denna studie är att undersöka och skapa förståelse för varför organisationer bygger upp dålig kvalitet i masterdata och vilka konsekvenser det får på implementationer av affärssystem.
Denna studie kommer bidra med rekommendationer för hur organisationer kan öka kvaliteten i sin masterdata. Studien kommer även bidra med rekommendationer för hur affärssystemkonsulter kan utveckla sina implementeringsmodeller. Detta för att förhindra att dålig kvalitet i masterdata påverkar implementationer av affärssystem.
3
2 Relaterad litteratur
Avsnittet inleds med en övergripande beskrivning av implementering av affärssystem, masterdata, kvaliteten i masterdata samt dess lagring. Därefter följer en genomgång av olika implementeringsmodeller och hur dessa hanterar masterdata. Avsnittet avslutas med en sammanställning av litteraturstudiens resultat.
2.1 Implementering av affärssystem
Affärssystem utgör ryggraden i många verksamheters informationsbehandling och har en stor betydelse för hur verksamheten organiseras och leds (Hedman, Nilsson & Westelius, 2009).
Organisationer som vill ha kontroll över deras helhet och följa med i teknikutvecklingen behöver investera i ett affärssystem (Xu et al., 2002). Affärssystem har under de två senaste decennierna blivit en central faktor för organisationer gällande deras konkurrenskraft på marknaden. Ett väl använt affärssystem, där hela affärssystemets kapacitet och funktionalitet nyttjas, som hanterar organisationens information på rätt sätt är därför väsentligt för att uppnå hög konkurrenskraft (Ahmed & Khalid Khan, 2013)
Förr eller senare i nästan alla organisationer når underhåll och vidareutveckling av affärssystemet sin topp. Ur synvinkeln av kostnad och teknisk kapacitet innebär detta att äldre applikationer så småningom behöver ersättas av nya (Martens, Book & Gruhn, 2018; Magnusson & Olsson, 2009).
Att implementera ett affärssystem är dock utmanande och medför ofta problem. Många gånger handlar det om att organisationen underskattar behovet av att förändra och modifiera samtidigt.
Detta innebär exempelvis att under tiden implementationen sker, måste organisationen förändra sina arbetssätt för att de ska bli anpassade till det nya systemet (Hedman et al., 2009). En situation där organisationen kan behöva att förändra och modifiera samtidigt kan exempelvis vara processen när masterdata ska migreras mellan systemen, eftersom den vanligtvis är tidsbegränsad (Martens et al., 2018).
2.2 Masterdata
Centrala och viktiga affärsobjekt i en organisation beskrivs och identifieras av masterdata. Exempel på masterdata är produkt-, sälj- och kunddata (Otto et al., 2012; Loshin, 2008). Organisationer hanterar stora mängder masterdata som finns i olika system. Ett konkret exempel på masterdata är all information kring en viss kund såsom adress, telefonnummer eller kundnummer (Griffin, 2006;
Hazel et al., 2017). Loshin (2008) beskriver att masterdata är data som har störst betydelse för ett objekt, som vidare ger en fullständig beskrivning av exempelvis en produkt. För att effektivisera samarbetet nyttjas och delas masterdata även med externa partners, exempelvis kunder och leverantörer (Griffin, 2006). De olika beskrivningarna av masterdata illustreras med Figur 1.
Griffin (2006) betonar att hantering av masterdata kan vara tidskrävande och dyrt men då masterdata anses vara en värdefull tillgång bör detta prioriteras. Att investera i och effektivt hantera masterdata bör ses som en självklar investering, precis som alla andra investeringar organisationer gör. En effektiv hantering av masterdata kan snabbt generera tillbaka investeringens kostnad (Griffin, 2006).
4 Figur 1 - Bilden nedan visar ett exempel på olika masterdata som beskriver en kund.
Det är ibland svårt att förstå masterdata trots att den finns i alla organisationers affärsaktiviteter, eftersom många intressenter involveras (Vilminko-Heikkinen & Peekola, 2017). Till exempel kan en affärsaktivitet bestå av en försäljning, och olika intressenter kan vara inköpare, försäljare och administratörer. Det är därför av stor vikt att alla involverade parter kring masterdata upprätthåller en kontinuerlig kommunikation med varandra samt tillgodoser varandras behov av gemensam masterdata. Kommunikationen kan bestå av att en försäljare tillgodoser administratören i systemet med nödvändig information kring en ny kund. När den nya kunden exempelvis lägger en beställning kan administratören i sin tur ge fullständig information till inköparen som ska leverera kundens varor. Att beakta masterdata och att se den som en gemensam tillgång mellan dess intressenter, bör därför betraktas som en viktig affärsaktivitet i organisationer (Vilminko- Heikkinen & Peekola, 2017).
2.3 Kvalitet i masterdata
En förutsättning för att en organisation ska kunna prestera är att dess masterdata är av hög kvalitet.
Hög kvalitet i masterdata innebär att organisationen tillhandahåller masterdata i rätt mängd, vid rätt tidpunkt och i rätt format (Otto et al., 2012).
Många organisationer har dålig kvalitet i sin masterdata och är omedvetna om det. Även om de skulle vara medvetna om den dåliga kvaliten, så saknar de ofta förståelse för vilka konsekvenser den kan medföra (Redman, 2008). Som tidigare nämnts bidrar dålig kvalitet i masterdata till ökade
5 kostnader för organisationer. Chefer och beslutsfattare kring masterdata förbiser och accepterar ofta den här typ av kostnader med motiveringen att det är kostnader som hör till när verksamheter bedrivs (Lee et al., 2006). I det dagliga arbetet är det vanligt att medarbetare identifierar problem med masterdata, men använder tillfälliga lösningar snarare än att anstränga sig för att ta fram långsiktiga och hållbara lösningar. En tillfällig lösning kan till exempel handla om att en systemadministratör inte har fullständig information kring en ny kund som ska registreras. Den tillfälliga lösningen blir då att registrera kunden med otillräcklig information bara för att få igenom exempelvis en försäljningsorder (Lee et al., 2006).
Lee et al. (2006) belyser att många organisationer tror att de kan lösa sina problem kring dålig kvalitet i masterdata genom att implementera ett nytt affärssystem. Det är dock högst sannolikt att det nya affärssystemet kommer att försämra kvaliteten snarare än att förbättra den. Det beror på att nya affärssystem oftast har högre krav på kvalitativ masterdata. Detta innebär att de faktorer som bidrar till dålig kvalitet i masterdata förblir dolda även om ett nytt affärssystem är lösningen till bättre kvalitet i vissa fall (Lee et al., 2006).
2.4 Lagring av masterdata
I en undersökning från IBM framgick det att minst 80 procent av en organisations masterdata är ostrukturerad [1]. Detta betyder att masterdata är spridda på olika ställen, vilket resulterar i dåligt kontroll. Vid exempelvis korrigering av masterdata kan det vara utmanande att spåra den om den är utspridd på olika ställen. Eftersom vi lever i ett digitaliserat samhälle där masterdatavolymer ständigt ökar är det viktigt att information är tillgänglig, vilket den inte är om masterdata är utspridd på olika ställen (Hazel, Weigel, Ezell, Boehmke & Bradley, 2017).
Vidare riskerar ostrukturerad masterdata att existera på mer än bara ett ställe, vilket leder till att dubbletter skapas [1]. Till exempel kan dubbletter i sin tur leda till att produkter med fel information används vid en inköpsorder. Vidare kan detta resultera i att kunden får fel varor vilket kan kosta organisationen en förlorad kund. Eftersom det är tidskrävande att säkerställa informationen i masterdata varje gång den används, är detta exempel ett sannolikt scenario (Loser, Legner &
Gizanis, 2006).
Masterdata kan antingen lagras på en central plats eller på ett antal olika platser. Fördelen med att ha en central lagring är att masterdata som skapas och ändras endast behöver göra det på ett ställe.
Detta betyder att organisationen kan vara försäkrad om att masterdata alltid är skapad på samma ställe och är unik. Att masterdata är unik förhindrar att det uppstår två definitioner, till exempel
“tel.nr” och “telefonnummer” (Loser et al., 2006). Vidare kan organisationer med en central lagrad masterdata distribuera den till alla områden som är i behov av det, till exempel produktion och försäljning. Detta kan vara till organisationens fördel ifall de måste anpassa sig efter nya förutsättningar (Madu & Madu, 2003).
2.5 Implementeringsmodeller
Att implementera ett affärssystem är för en organisation en stor utmaning som kan ta upp till fem år. Implementeringsprocessen har studerats med ett flertal utgångspunkter och det finns en mängd skrivna artiklar kring processen och vad som gör projekten framgångsrika, vilka risker och hot som finns. Processen delas generellt sätt in i ett flertal steg som har olika tillvägagångssätt och olika prioriteringar (Shanks, 2000; Robey, Ross & Boudreau, 2002; Davenport, 1998). En allmän definition på ett lyckat implementeringsprojekt är enligt Mabert, Soni och Venkataramanan (2003) samt Shanks (2000) ett projekt som håller givna budget- och tidsramar. Det finns idag ett flertal modeller för att implementera ett affärssystem (Mabert et al., 2003). Nedanför presenteras sex olika implementeringsmodeller: ASAP, AIM, Sure Step, OUM, Shanks och Sandoe. Dessa modeller har
6 valts eftersom de visade sig vara relevanta då de används i stor utsträckning och var frekventa när forskning inom området undersöktes. Syftet med att presentera dessa implementeringsmodeller är att kunna skapa en generisk beskrivning av hur implementationer av affärssystem genomförs samt var och hur i processen masterdata hanteras. Den generiska beskrivningen kommer baseras på likheter mellan de sex presenterade implementeringsmodellerna.
Alla modeller delar in sin process i steg, varav fyra av modellerna delas upp i sex steg. ASAP:s steg delas in i projektförberedelser, affärsplan (översatt från “business blueprint”), realisering, sista förberedelsen, support inför driftsättning och driftsättning. AIM delar också in sin process i sex steg: definition, operationsanalys, design av lösningen, utveckling, övergång och produktion (Law, 2019). Även Sure Step innefattar sex steg: diagnos, analys, design, utveckling, driftsättning och operation (Birch & Dunkinson, 2013; [2]). Den sista är Sandoe och processen delas in i: initiering, planering, analys och processdesign, realisering, övergång och drift (Sandoe, Corbitt & Boykin, 2001). Dem två sista delar upp sin process i fem respektive tre steg. OUM:s process är indelad i fem steg: start, utarbetning, utveckling, övergång och produktion (Law, 2019). Shanks steg är:
planering, projekt och förbättring (Shanks, 2000).
I AIM:s första steg läggs stor vikt på att definiera krav som organisationen har, som måste mötas av implementeringsprojektet (Lutovac & Manojov, 2012). I ASAP, Sandoe, Shanks, Sure Step och OUM handlar det första steget om att definiera projektets omfattning och klargöra team inom organisationen (Lutovac & Manojov, 2012; Sandoe et al., 2001; Shanks, 2000; Birch & Dunkinson, 2013; [2]; Law, 2019).
AIM och ASAP:s andra steg handlar om att samla in krav, göra analyser och skapa strategier (Lutovac & Manojov, 2012). I Shanks modell innefattar steg två bland annat att det utförs analyser av organisationens processer, och även viss utbildning görs (Shanks, 2000). I Sure Steps andra steg läggs fokuset på att utföra en analys genom att identifiera och förstå affärsprocesserna (Birch &
Dunkinson, 2013; [2]). Sandoes steg två har huvudmålet att planera, skapa projektteam och att identifiera risker (Sandoe et al., 2001). I OUM:s andra steg läggs störst fokus på att utveckla kravmodeller och lägga grunden för arkitekturen av systemet (Law, 2019).
I steg tre handlar Sandoe:s modell om att analysera den nuvarande samt den eftersträvade situationen. Det är även i detta steg viss utbildning i systemet utförs (Sandoe et al., 2001). I ASAP:s steg tre ligger fokuset på att implementera alla affärsprocesskrav. AIM:s tredje steg handlar om att designa för framtida krav på affärsprocesser, göra anpassningar och modulkonfigurationer slutförs (Lutovac & Manojov, 2012). För Sure Step är huvudsyftet i steg tre att hitta ett sätt för hur kundprocesser och behov kan bli implementerade (Birch & Dunkinson, 2013; [2]). Som tidigare nämnts så har Shanks modell endast tre steg och det sista steget är en transaktionsfas, där organisationen byter affärssystem (Shanks, 2000). OUM:s tredje steg handlar om att programmera, utveckla och testa funktioner för att skapa ett komplett system ([2]; Lutovac & Manojov, 2012).
Vidare så innebär steg fyra för ASAP:s modell att fokuset läggs på att testa funktioner inför driftsättning (Lutovac & Manojov, 2012). I Sandoes modell utförs test av funktioner i systemet och det utförs även installation av hård- och mjukvara (Sandoe et al., 2001). För Sure Step och AIM så innebär steg fyra att vissa förbättringar görs, programmering utförs och funktioner prövas för att konstruera ett fullständigt system (Birch & Dunkinson, 2013; [2]; Lutovac & Manojov, 2012). För OUM handlar steg fyra om övergången, en transaktionsfas där organisationen byter affärssystem ([2]; Law, 2019).
7 OUM:s modell har endast fem steg varav det sista steget är en transaktionsfas. För ASAP, Sure Step, AIM, Sandoe och OUM innebär steg fem att organisationen gör övergången från det gamla affärssystemet till det nya (Sandoe et al.,2001; Lutovac & Manojov, 2012; Birch & Dunkinson, 2013; [2]; Law, 2019). För ASAP, Sure Step, AIM och Sandoe som har sex steg är det sista steget i implementeringsprocessen ett moment som är ämnat åt support och service (Lutovac & Manojov, 2012; Birch & Dunkinson, 2013; [2]; Law, 2019).
2.5.1 Hantering av masterdata i implementeringsmodeller
Implementeringsmodellen ASAP påbörjar hanteringen av masterdata i steg tre. Under detta steg konfigureras systemet, flödet över masterdata gås igenom samt laddas. Det är även i detta steg affärsprocesserna delas in i cykler för att testa specifika delar av den processen. I det fjärde steget görs ett flertal tester på systemets arbetsbelastning, kontroll av masterdata och migrering. Slutligen utförs dataomvandlingen i det femte steget (Law, 2019).
I Sure Step modellen påbörjas hanteringen av masterdata i steg fyra där systemtestning och migration utförs ([2]; Law, 2019). I modellen beskrivs även två processer med allmän information om masterdata, utöver hanteringen i steg fyra. Den ena, ”Masterdata Management Process”, syftar till att försäkra att de implementerade processerna får en lämplig ägare och att ansvar etableras.
Den andra, ”Masterdata Management Process Handover”, handlar om att överlämna ägandet av masterdata så att dataintegriteten och noggrannheten kan underhållas i den nya lösningen (Shankar
& Bellefroid, 2010).
I implementeringsmodellen AIM utförs kodning och testning av masterdata migrering i steg fyra, för att bekräfta att funktionaliteten uppfyller affärskraven. Om anpassningar, tillägg och omvandlingar inte krävs, är detta steg fortfarande viktigt eftersom den innehåller testning av affärssystemet. I slutet av steg fyra är målet att ha en testad och fungerande applikation för verksamheten. Vid behov hanteras även förändringar och migrering av masterdata i steg fem (Law, 2019).
Sandoes modell påbörjar arbetet kring masterdata redan i första steget. Det rekommenderas att välja en ”bottom-up” strategi som bygger på att minimera förändringarna i organisationen genom att kartlägga organisationens processer och existerande dataelement. Detta testas sedan i steg fyra.
Det utförs även viss modifiering av affärssystemet för att det ska passa strukturen och kraven av data (Sandoe et al., 2001)
I implementeringsmodellen OUM hanteras masterdata i de fyra första stegen. Datainsamling och dataomvandling påbörjas i steg ett men arbetas mest med i steg fyra. Syftet med processen för datainsamling och migrering är att migrera all gammal data som är nödvändig för driften av det nya affärssystemet (Birch & Dunkinson, 2013).
I Shanks modell består steg två av ytterligare fem subfaser, varav subfas två ”omformning”
beskriver hur processer analyseras och mappas gentemot affärssystemets funktioner. I subfas fyra,
“Realisering”, blir kraven för systemen och organisationen realiserade, där ett av målen är att ta fram ett testunderlag med verklig data (Shanks, 2000).
2.6 Litteratursammanställning
Affärssystem är idag en självklarhet och nödvändighet för många organisationer. Ett viktigt innehåll i systemet är masterdata, då den beskriver och identifierar alla objekt, till exempel kunder och produkter (Ahmad & Khan, 2013). Trots detta är det vanligt att kvaliteten i masterdata är dålig,
8 vilket i sin tur får konsekvenser för organisationen. När en organisation med dålig kvalitet i masterdata ska implementera ett nytt affärssystem påverkar det både projektet och verksamheten.
Projektet påverkas eftersom det bland annat krävs mer tid och resurser för att bearbeta kvaliteten i masterdata under implementationen (Lee et al., 2006).
Litteraturstudien resulterade även i en generisk beskrivning av hur implementationer av affärssystem genomförs samt var och hur i processen masterdata hanteras (se Figur 2). Generellt sätt börjar alla implementeringsmodeller med en diagnos eller förberedelser inför projektet och avslutas med driftsättning av det nya systemet. Däremellan, ungefär i mitten av faserna, brukar masterdata hanteras. Varje modell nämner masterdata men ingen av modellerna redogör på ett utförligt sätt hur masterdata bör hanteras. Det finns heller ingen beskrivning eller process för hur kvaliteten i masterdata säkerhetställs eller hanteras (Lutovac & Manojov, 2012; Sandoe et al., 2001;
Shanks, 2000; Birch & Dunkinson, 2013; [2]; Law, 2019).
Figur 2 – Generisk beskrivning av hur implementationer av affärssystem genomförs
Grön markering indikerar var masterdata brukar hanteras
9
3 Metod
I metoden redovisas vad som har gjorts, hur det gjordes, varför det gjordes på just det sättet och hur författarna förhållit sig på ett kritiskt sätt till varje genomförande. Metodavsnittet är disponerat i följande ordning: forskningsansats, pilotintervjuer, litteraturstudie, datainsamlingsmetod, urval, analysansats, etiska övervägande och metoddiskussion.
3.1 Forskningsansats
Med studiens syfte i åtanke ville transferabilitet uppnås, vilket möjliggjordes med en kvalitativ ansats. Transferabilitet handlar om att överföra kunskap från en studie till en annan ny situation (Fejes & Thornberg, 2015). Genom respondenternas tolkningsbara, förklarande och utförliga svar skapades förståelse för varför dålig kvalitet i masterdata byggs upp och vilka konsekvenser det får på implementationer av affärssystem. Denna kunskap ska sedan kunna användas av organisationer som känner igen sig och befinner sig i liknande situationer.
Denna studie ska svara på frågeställningen: varför bygger organisationer upp dålig kvalitet i sin masterdata och vilka konsekvenser får det på implementationer av affärssystem? För att besvara frågeställningen har det genomförts intervjuer. Det behövdes djupgående, förklarande och utförliga svar från respondenterna, vilka kunde erhållas genom en kvalitativ forskningsansats. Kvalitativ forskning fokuserar på att förklara varför saker är på ett visst sätt och tar reda på hur människor tänker och resonerar (Trost & Hultåker, 2016).
3.2 Litteraturstudie
Först undersöktes tidigare forskning inom området för att skapa en kunskapsbas. Med hjälp kunskapsbasen har en ökad förståelse kring masterdata, kvalitet i masterdata och dess konsekvenser på implementationer av system skapats. Tidigare kunskap kring området hjälper forskaren att förstå innebörden av en fråga och dess tidigare resultat i olika avseenden (Backman, 2008).
För att söka litteratur användes två metoder, systematisk- och kedjesökning. Systematisk sökning går ut på att litteratur letas inom ett särskilt ämne (Rienecker & Stray Jørgensen, 2018). Utifrån den litteratur som hittades med en systematisk sökning övergicks det sedan till en kedjesökning.
En kedjesökning innebär att en referens leder till en annan och kan på så vis hjälpa forskaren att hitta lämplig litteratur (Rienecker & Stray Jørgensen, 2018). Kombinationen av dessa två metoder ledde till att relevant litteratur som behövs för att besvara studiens frågeställning hittades.
Litteraturen består av böcker och artiklar som huvudsakligen har hämtats från databaser som är tillgängliga på högskolan i Halmstads bibliotek samt Google Scholar. Nyckelord som berör studiens syfte och frågeställning användes som sökord. De nyckelord som användes var ERP, affärssystem, masterdata, kvalitet i masterdata, implementeringsmodeller, ERP implementation, masterdata quality, masterdata and bad quality consequences och masterdata problems in ERP.
Artiklarna som ansågs vara relevanta i den systematiska sökningen skulle uppnå följande kriterier:
peer-reviewed, innehålla minst tre av sökorden och vara skrivna på svenska eller engelska. Bland de artiklar som valdes ut, kunde det sedan övergås till en kedjesökning. De artiklarna hade samma kriterier. I början valdes 20 artiklar ut som uppfyllde kraven. De 20 artiklarna bearbetades i ett första steg genom att sammanfattningen och slutsatsen lästes. På så sätt kunde artiklar som visade sig ointressanta för denna studie snabbt sorteras bort.
Litteraturstudien resulterade i en kunskapsbas samt ökad förståelse för forskningsområdet, vilket ledde till att studiens undersökningsfokus kunde breddas. Kunskapsbasen ledde till att fler
10 synvinklar och perspektiv i olika avseenden kunde identifieras. Ett exempel på hur fokuset breddades är att följdfrågor kunde ställas under intervjuerna eftersom en ökad förståelse kring studiens forskningsområde hade erhållits. Det ledde till djupare och mer informativa svar från respondenterna. Litteraturstudien låg även till grund för de intervjuguider (se Bilaga 1 & 2) som användes i studien. Vidare resulterade litteraturstudien i en generisk beskrivning av hur implementationer av affärssystem genomförs samt var och hur i processen masterdata hanteras (se Figur 2).
3.3 Pilotintervjuer
Först genomfördes pilotintervjuer som enligt Trost (2010) är en slags “provintervju”. Här prövas bland annat förmågan som intervjuare (Trost, 2010). Syftet med pilotintervjuerna var att undersöka ifall studien var genomförbar men även för att undersöka frågornas lämplighet och intervjuguidens utformning (Polit & Beck, 2012). Intervjuguiden som användes vid pilotintervjuerna baserades på studiens litteraturstudie.
Det genomfördes totalt tre pilotintervjuer. Pilotintervjuernas respondenter var systemadministratörer som arbetar med masterdata. Vidare gav pilotintervjuerna även möjligheten till att finna respondenter som ansågs lämpliga för studien, det vill säga respondenter som arbetar med implementationer av affärssystem och masterdata.
3.4 Datainsamlingsmetod
För att besvara studiens frågeställning och därmed uppfylla studiens syfte har en kvalitativ studie genomförts. Ett flertal organisationer har undersökts för att hitta gemensamma aspekter kring varför dålig kvalitet i masterdata byggs upp och vilka konsekvenser det får på implementationer av affärssystem. Det har bedrivits semistrukturerade intervjuer (Fejes & Thornberg, 2015). Samtliga intervjuer genomfördes på respondenternas arbetsplatser. Semistrukturerade intervjuer öppnar upp en möjlighet för intervjuaren att ändra på frågorna under intervjun, beroende på respondentens svar, samt att ställa följdfrågor. Det kan innebära att respondenterna berättar något som inte planerats att fråga, men som anses vara relevant. vilket inte hade varit möjligt om det hade använts strukturerade intervjuer istället (Fejes & Thornberg, 2015).
Grunden för intervjuguiderna utgjordes av resultatet från litteraturstudien. Intervjuguiderna bestod av två olika områden som är kopplade till studiens frågeställning. Det första området bestod av öppna frågor som handlade om masterdata ur en generell synvinkel samt masterdata kopplat till organisationerna. Dessa frågor kunde bland annat bestå av vad respondenterna anser är bra respektive dålig kvalitet i masterdata samt hur masterdata prioriteras och hanteras i organisationen.
Därefter påbörjades det andra området som bestod av frågor som handlade om masterdata kopplat till implementationen av ett affärssystem.
Intervjuerna har, vid godkännande av respondenterna, spelats in och i efterhand transkriberats för att säkerställa analysarbetet (Fejes & Thornberg, 2015). Det fördes även fortlöpande anteckningar under intervjuerna. Anteckningarna underlättade analysen av empirin genom att viktig information kunde urskiljas. Till exempel kunde respondenterna reagera genom sitt kroppsspråk vid vissa frågor, vilket inte framkom i ljudinspelningarna och därför antecknades sådana reaktioner. Sådana reaktioner bestod bland annat av att respondenten rynkade ögonbrynen, grimaserade, skakade på huvudet eller ryckte på axlarna.
11 Det användes två olika intervjuguider eftersom de som intervjuades tillhörde två olika respondentgrupper. Respondentgrupp ett består av personer som arbetar på en organisation som implementerat ett affärssystem inom de senaste två åren och upptäckt dålig kvalitet i sin masterdata. Respondentgrupp två består av konsulter. Grupp ett representerar en specifik implementation samt organisation, och grupp två pratar ur erfarenhet och uppger en generell bild av många olika implementationer och organisationer. De olika intervjuguiderna har samma tema och upplägg men anpassade frågor.
3.5 Urval
Studien har bedrivits på sju olika organisationer. Fem av organisationerna är verksamma inom olika branscher; produktion, lager, läkemedel respektive detaljhandel, med två organisationer inom lagerbranschen och med en organistion inom respektive resterande bransch. Dessa organisationer har under de senaste två åren genomgått en implementation av ett affärssystem och upptäckt dålig kvalitet i sin masterdata. De resterande två organisationerna är konsultbolag som består av affärssystemkonsulter som implementerar affärssystem i många olika branscher. Detta branschurval har gjorts i syfte att få en nyanserad bild av kunskapsproblemet som täcker olika typer av masterdata.
Urvalsmetoden som användes var ett målinriktat urval. Bryman (2011) beskriver att ett målinriktat urval går ut på att strategiskt välja ut deltagare så att urvalet är relevant utifrån den aktuella forskningsfrågan. För att respondenterna på konsultbolagen ska ha varit aktuella för studien ska de ha en erfarenhet på minst tio år. Genom att ha en erfarenhet på över tio år har konsulterna en bred erfarenhet av många olika implementationer.
Det första kriteriet för att respondenterna i organisationerna som genomgått en implementation av ett affärssystem ska ha varit aktuella för studien, är att de ska ha haft dålig kvalitet i sin masterdata i samband med implementationen. Det andra kriteriet är att respondenterna ska ha varit anställda i organisationen i fråga minst fem år innan implementationen. Det krävs att respondenterna själva bidragit och varit med under processen för att förstå hur kvaliteten i masterdata byggs upp och på vilka sätt denna uppbyggnad lett till dålig kvalitet.
Anledningen till att det valdes att intervjua respondenter både på organisationer som upplevt dålig kvalitet i sin masterdata men även oberoende konsulter är för att stärka studiens transferabilitet. De konsulter som i denna studie inte har en koppling till en specifik organisation utan beskriver ur en generell synvinkel kommer att kallas oberoende konsulter. De oberoende konsulterna intervjuades för att få med andra perspektiv och synvinklar.
Det genomfördes åtta intervjuer, två med oberoende konsulter och sex med respondenter ute på organisationer som implementerat ett affärssystem med dålig kvalitet i sin masterdata. Totalt åtta intervjuer i sex olika organisationer. Till en början kontaktades affärssystemkonsulterna där det frågades om tips på kunder som implementerat ett affärssystem de senaste två åren och upplevt dålig kvalitet i sin masterdata. Därefter kontaktades dessa organisationerna via telefon där en presentation kring författarna och studien gjordes, och sedan ställdes frågan om de var intresserade av att ställa upp på intervjuer. För att göra respondenterna anonyma valdes det att använda fiktiva namn. Nedan beskrivs respondenterna kort samt organisationerna de arbetar för:
Mats:
Mats arbetar som intern projektledare och har haft sin nuvarande roll i sju år. Han har en bred erfarenhet av migrering av masterdata i samband med implementationer av nya affärssystem. Mats
12 arbetar på en organisation som ägnar sig åt produktion till bland annat industrier. Organisationen omsätter 250 miljoner och består av 80 medarbetare.
Gunilla:
Gunilla arbetar som verksamhetsutvecklare inom logistikbranschen. Hon har en spetskompetens inom effektivisering av processer och arbetssätt. Gunilla har en erfarenhet på åtta år.
Organisationen omsätter 400 miljoner och består av 120 medarbetare.
Sandra:
Sandra är VD (Director of operations) på en organisation inom automatiserad intralogistik.
Intralogistik är automatiserad hantering av gods, primärt på lager. Hon har haft sin nuvarande roll i två år men har varit anställd organisationen i totalt fem år. Sandra har en lång erfarenhet av förbättringsprojekt kopplat till affärssystem, där ett förbättringsområde har varit kopplat till masterdata. Sandra arbetar på samma organisation som Gunilla.
Bertil:
Bertil arbetar som inköpare och är även ansvarig för materialförsörjningen till produktionen och diverse projekt. Han har haft sin nuvarande roll i fem år och har en total erfarenhet som inköpare på 11 år. Organisationen som Bertil arbetar för är verksamma inom lager- och logistikbranschen. I Bertils roll som inköpare inkluderas även olika typer av underhållning i systemet. Bertil arbetar på en organisation som omsätter 400 miljoner och har 180 medarbetare.
Jörgen:
Jörgen arbetar som systemadministratör där han även är ansvarig för organisationens masterdata.
Han har haft sin nuvarande roll i sex år och han har en lång erfarenhet av masterdata. Sammanlagt har han arbetat med masterdata i 13 år där han bland annat var masterdatachef på sin tidigare arbetsplats. Jörgens nuvarande organisation verkar inom den medicintekniska branschen där de distribuerar sjukhusmaterial. Organisationen omsätter 550 miljoner kronor och består av 150 medarbetare.
Anette:
Anette arbetar som systemadministratör på en organisation inom detaljhandel. Organisationen har över 110 butiker i Sverige, över 800 anställda och omsätter 2 miljarder kronor,. Hennes arbetsuppgifter består av att lägga in artiklar och skapa artikelstruktur i affärssystemet. Hon har tidigare arbetat som masterdataspecialist och har en total erfarenhet på sex år.
Stefan:
Stefan arbetar som projektledare på två olika organisationer. Han har totalt arbetat som projektledare i 12 år. Stefan är konsult på 50% inom en svensk konsultfirma som omsätter 200 miljoner kronor. Han är även anställd som intern projektledare på 50% i en organisation som är en svensk multinationell tillverkare av diverse produkter med en omsättning på 40 miljarder kronor.
Här ansvar Stefan bland annat för organisationens masterdatastrukturer.
Amanda:
Amanda arbetar som affärssystemkonsult där hon implementerar affärssystem och har en roll som lösningsarkitekt. Hon har arbetat som affärssystemkonsult i 10 år på två olika organisationer.
Amanda har implementerat affärssystem i ett flertal olika branscher, både inom privat och offentlig sektor. Branscherna är bland annat hälsovård, bygg, industri, material, energi, livsmedel, transport, logistik och finans. Hennes organisation består av 245 medarbetare och omsätter 330 miljoner kronor.
13 Nedan presenteras Tabell 1 som är en sammanfattning av respondenterna. Här presenteras deras roll i studien, vilken bransch de verkar i, deras namn, hur lång erfarenhet de har samt deras arbetsroll. “Konsult” innefattar de oberoende konsulterna.
Tabell 1 - Sammanfattning av respondenterna
3.6 Analysansats
Empirin har analyserats med en induktiv tematisk analysansats. Ansatsen har använts för att identifiera, analysera och presentera teman från studiens datainsamling. Fejes och Thornberg (2015) definierar en tematisk analys som en metod där forskaren fokuserar på att lyfta fram gemensamma drag från samtliga intervjuer.
De gemensamma drag som identifierades i datainsamlingen bildade teman. Att ansatsen var induktiv innebär att teman identifierades först efter att data samlades in, det fanns inte teori om eventuella teman i förväg (Braun & Clarke, 2006). När studiens datainsamling analyserades, växte teman fram utifrån vad intervjupersonerna upplevde ha bidragit till att dålig kvalitet i masterdata orsakats samt dess konsekvenser på implementationen. Sammanlagt bildades fyra teman; ökade mängder av masterdata, ökade kostnader, bristfällig kunskap och bristfälligt ägandeskap och processer. Dessa teman analyserades sedan med vad som framkommit i litteraturstudien och kommer att leda fram till svaret på studiens frågeställning.
För att koda data utan att försöka anpassa den med förutbestämda ramar har en bottom up ansats använts. Teman som hittades kopplades direkt till data istället för att de exempelvis ha drivits av forskarens intresse eller föreställningar (Braun & Clarke, 2006). Eftersom datainsamlingen
14 genererade stora mängder data, var en tematisk analys lämplig för att kunna avgöra vilken insamlad data som var användbar och vilken som kunde uteslutas. Till en början omvandlades de transkriberade meningarna från respondenterna till koder, för att reducera mängden. Koderna skulle vara så korta som möjligt men behålla meningarnas betydelse. Exempel på kodat stycke:
“Ja nu har vi det. Vi har påbörjat ett samarbete mellan inköpare, mig och produktchefer som är de som arbetar med masterdata. Nu har vi styrt upp vilka regler som gäller och i vilket skick masterdata ska vara i. Till exempel ska man inte få lämna fält tomma.”
Koderna till stycket ovan blev “Påbörjat ett samarbete mellan avdelningarna” och “Satt upp regler där bland annat fält inte får vara tomma”.
Vidare analyserades koderna noggrant för att urskilja repetitiva mönster. Dessa mönster strukturerades sedan in i olika kategorier som i sin tur bildade teman. Exempelvis bildades temat
“ökade kostnader” av kategorierna: felaktiga leveranser, försenade projekt, tillsättning av resurser, felaktiga strategiska beslut och böter. Med hjälp av studiens teman gick det att förklara varför organisationer bygger upp dålig kvalitet i sin masterdata och vilka konsekvenser det får på implementationer av affärssystem.
3.7 Etiska övervägande
Inom forskning ställs forskaren inför flera etiska frågor såsom val av sociala miljöer, intervjufrågor och metoder. En viktig del i den etiska reflektionen är närheten till personer som ska ingå i forskningen. Till exempel kan en viktig del vara att de deltagande eller andra berörda personer i studien får ta del av eventuellt känsliga delar eller tolkningar, innan rapporten publiceras (Närvänen, 1999). Samtliga respondenter blev tillfrågade om det var någon del av intervjun eller något specifikt citat som de inte ville skulle vara med i studien. Forskaren behöver även reflektera över relationen till de parter som studeras och att de perspektivval som valts ut tydligt redovisas.
Med detta menas att de personer som berörs av forskningen bland annat blir informerade om att de har rätt att avbryta sin medverkan om de vill, vilket samtliga respondenter blev informerade om (Eliasson, 1995).
I denna studie har Vetenskapsrådets (2002) forskningsetiska principer, som består av fyra huvudkrav, beaktats för att skydda respondenterna. Informationskravet innebär att forskaren ska informera undersökningsdeltagare om vilka villkor som gäller för deras deltagande.
Samtyckeskravet betyder att forskaren ska införskaffa alla deltagares samtycke.
Konfidentialitetskravet innebär att alla uppgifter i undersökningen ska hållas konfident och förvaras så att obehöriga inte kan ta del av dem. Det sista kravet, Nyttjandekravet, innebär att insamlade uppgifter endast får användas för forskningsändåmålet (Vetenskapsrådet, 2002).
Deltagarna blev informerade om studiens syfte, att deras deltagande var frivilligt, att deras insamlade uppgifter endast avsågs att användas för studiens ändamål och att deras personuppgifter inte kommer att ges ut offentligt. Dessa krav tillämpades för att få deltagarna att känna sig trygga i undersökningen. Att deltagarna känner sig trygga leder till att deras engagemang ökar och att de ger mer informativa svar (Tracy, 2010).
3.8 Metoddiskussion
Värdigt ämne (översatt från “worthy topic”) är ett centralt kvalitetsbegrepp inom kvalitativ forskning. Kvalitetsbegreppet handlar om att forskning bör vara intressant, relevant och aktuellt i
15 tiden (Tracy, 2010). Denna studie är relevant eftersom organisationer ständigt erhåller mer information i sina affärssystem, vilket leder till att deras volymer av masterdata ökar. Eftersom masterdata är en av organisationers viktigaste affärsobjekt (Otto et al., 2012) är denna studie betydande och intressant.
Studiens målinriktade urvalsmetod syftar till att respondenterna ska vara relevanta utifrån den aktuella forskningsfrågan (Bryman, 2011). Detta stärker studiens validitet då respondenterna som valts besitter en hög kunskap inom området i fråga. Validitet innebär i vilken utsträckning forskaren undersöker det som avses att undersökas (Fejes & Thornberg, 2015).
Eftersom respondentvalidering har använts, stärks även studiens tillförlitlighet. Att använda respondentvalidering innebär att intervjuernas resultat delas med respondenterna. Detta görs för att undersöka huruvida respondenterna anser att innehållet återspeglar det som sades under intervjun (Bryman, 2011).
För att få ut så informativa svar som möjligt under intervjuerna var det av vikt att få respondenterna att känna sig säkra under och efter intervjun. Genom att beakta de fyra etiska forskningsprinciperna (Vetenskapsrådet, 2002) och bland annat upplysa respondenterna om att deras deltagande är anonymt så bringades en trygghet till dem. Till följd av att respondenterna känner sig trygga så ökar deras engagemang och på så vis ges djupare svar (Tracy, 2010). Vissa respondenter bad om att få vara anonyma innan vi hann berätta för dem att alla respondenter kommer att presenteras anonymt i studien. Detta är ett tecken på att anonymitet var av vikt.
Med studiens syfte i åtanke ville transferabilitet uppnås, vilket handlar om att överföra kunskap från en studie till en annan ny situation (Fejes & Thornberg, 2015). Studien hade dock kunnat uppnå ännu högre trovärdighet i transferabiliteten om studien hade bedrivits inom fler branscher och med fler respondenter. Eftersom olika branscher kan ha olika typer av masterdata hade därför ett mer generaliserbart resultat kunnat uppnås. För att resultatet ska generaliseras till fullo krävs det enligt Eriksson-Barajas, Forsberg och Wengström (2013) att urvalet täcker en hel population, vilket i denna studie innebär alla branscher. Men vi bedömer att urvalet är tydligt beskrivet och motiverat, exempelvis varför vi valde att ha två respondentgrupper.
16
4 Resultat
I resultatet redovisas och sammanfattas svaren från de olika respondenterna. Först redovisas svaren från respondenterna som tillhör organisationer som har haft dålig kvalitet i sin masterdata, som kallas för respondentgrupp ett. Sedan redovisas svaren från de oberoende konsulterna, som kallas för respondentgrupp två. Rubrikerna i avsnittet är baserade på intervjuguidernas struktur.
4.1 Respondentgrupp ett: masterdata kopplat till organisationen 4.1.1 Kvalitet i masterdata samt dess prioritering
Till en början fick respondenterna definiera vad de anser är bra respektive dålig kvalitet i masterdata. Bertil ansåg att bra kvalitet i masterdata är när den är anpassad efter organisationen samt tydlig och korrekt. Dålig kvalitet är enligt Bertil för komplex masterdata där ingen riktigt vet hur effekterna av data påverkar annan data. Mats beskrev bra att kvalitet är när den är tydlig och korrekt ifylld. Han ansåg att dålig kvalitet är när det finns mycket buggar och när det saknas enhetliga definitioner. Bertil gav uttryck enligt följande citat:
“Bra kvalitet i masterdata handlar om att den ska vara anpassad efter organisationensamt enkel att arbeta med och dålig kvalitet handlar om att den är för komplex. “- Bertil
Gunilla beskrev att bra kvalitet i masterdata uppnås när det finns uppsatta regler som följs. Hon påtalade även att det är viktigt att se till så att masterdata stämmer överens med verkligheten. Dålig kvalitet är enligt Gunilla motsatserna till vad hon beskrev som bra kvalitet. Jörgen definierade också bra kvalitet i masterdata som data som är korrekt ifylld och uppdaterad. Enligt Jörgen måste informationen som står i masterdata verkligen vara hundraprocentigt rätt och det gäller att kontinuerligt arbeta med den. Dålig kvalitet definierade Jörgen som inkonsekvent data som inte underhålls. Sandra beskrev att masterdata har bra kvalitet när den följer en struktur som är skalbar och enkel att nyttja. Sandra nämnde även att masterdata ska följa de operativa processflöden som verksamheten vill arbeta efter för att den ska anses vara av hög kvalitet. Sandra beskrev att masterdata är av dålig kvalitet när det är en person som har skapat den och format den på ett vis som inte kan uppfattas av någon annan. Det kan till exempel handla om förkortningar som inte är tydligt förstådda av alla som använder samma data. Jörgens förklaring av dålig respektive bra kvalitet i masterdata illustreras med följande citat:
“För att masterdata ska vara av hög kvalitet ska den vara korrekt ifylld och uppdaterad, eftersom att masterdata andas och förändras. Dålig kvalitet uppnås när den inte hålls levande.” - Jörgen Anette beskrev att masterdata av hög kvalitet är data som uppfyller kraven för avsett syfte. Hon förklarade att det är viktigt att masterdata är korrekt och komplett. Anette poängterade att masterdata är ett fundament som får företag att fungera på ett effektivt sätt och representerar en av de mest värdefulla tillgångarna organisationen har. Bra masterdata kan enligt Anette öppna upp möjligheten för effektiva flöden genom hela organisationen. Dålig kvalitet beskriver hon som data där till exempel inte alla fält är ifyllda, att det saknas information. Anette förklarade att masterdata handlar om att förstå värdet av informationen. vilka beslut de ska understödja samt vilka användare som behöver informationen. Anette gav uttryck för följande citat:
“Det är viktigt att masterdata uppfyller avsatt syfte för att hög kvalitet ska kunna uppnås. Dålig kvalitet kan till exempel innebära att en artikel inte har alla fält ifyllda och därmed sakna eventuellt viktig information.” - Anette
17 Vidare ställdes frågan om respondenterna upplever att arbete kring masterdata prioriteras i deras organisation, där samtliga respondenter svarade nej. Bertil och Sandra gav uttryck för liknande beskrivningar där de förklarade att de är tidspressade organisationer som har fokus på annat. De förklarade vidare att det i sin tur resulterar i att arbete kring masterdata blir en uppgift som skjuts fram. Det är lätt hänt att det snabbt växer och att det sedan krävs en stor insats för att korrigera allt som ligger fel. Gunilla förklarade att det inte var förrän en praktikant ville utföra en praktik hos dem, i syfte att arbeta med deras masterdata, som de ens tänkte på det. Mats poängterade att de inte prioriterar arbete kring masterdata eftersom mycket hänger på att de inte har kunskapen kring vad dålig masterdata faktiskt kostar organisationen, med exempelvis felåtgärder. Jörgen beskrev att de tidigare varit en liten verksamhet där de har haft lite masterdata, och att att arbete kring masterdata inte har varit nödvändigt. Sedan har samma tankesätt präglats, trots att de har blivit en större verksamhet med större mängder masterdata. Anettes förklaring illustreras med följande citat:
“Nej, masterdata prioriteras inte då området inte anses som kärnverksamheten, utan man anser att det finns andra affärsområden som bör prioriteras.” - Anette
4.1.2 Hantering av masterdata
Respondenterna blev tillfrågade om de har regler för hur masterdata ska hanteras. Det vill säga skapa, uppdatera och sortera masterdata. Bertil svarade att de har väldigt lite regler, vilket ställde till det i det nya systemet. Mats beskrev att de inte har generella metoder, utan att varje individ gör på sitt sätt. Sandra uppgav att det är bristfälligt med regler kring hur och vem som får skapa masterdata. Gunilla nämnde att användare har olika behörigheter i olika system och därför finns det inte bra instruktioner på hur masterdata ska hanteras. Jörgen förklarade att de inte har haft regler men att de försöker bättra sig i samband med det nya systemet. Enligt Jörgen försöker de även förbättra samarbetet kring masterdata mellan avdelningar sedan de implementerade ett nytt system.
Sandras beskrivning illustreras med följande citat:
“Vi är bristfälliga vad gäller regler, det sätts dock nya rutiner i samband med vårt nya affärssystem.” - Sandra
Anette gav uttryck för att det har funnits regler. Hon poängterar dock att det inte är någon som lägger tid på att underhålla eller skapa nya manualer eller rutiner vid behov, vilket egentligen har behövts. Anette menar att det till exempel kan handla om att leverantörer ändrar sin masterdata, som de har gemensamt. Då är det viktigt att det skapas nya rutiner, vilket inte har gjorts. Hennes förklaringar illustreras med följande citat:
“Det finns regler och rutiner, det är dock inte många som lägger tid på att underhålla eller skapa nya manualer och rutiner vid behov.” - Anette
4.1.3 Lagring, rättigheter och gemensam masterdata
Här ställdes frågan kring var de lagrar sin masterdata, vem som har rättigheter att ändra masterdata och vem de delar sin masterdata med. Bertil uppgav att de inte delar masterdata med andra organisationer och att de lagrar sin masterdata på en speciell server. Det är däremot väldigt många som internt har rättighet att ändra på masterdata inom olika områden. Bertil gav uttryck för följande citat:
“Vi delar inte masterdata med någon men det är tyvärr många inom olika avdelningar som får ändra masterdata.” - Bertil
18 Här ställdes en följdfråga till Bertil där det frågades om vilka konsekvenser det kan få att många har rättighet att ändra på masterdata. Han förklarade att många arbetar på olika sätt, och att masterdata då inte blir enhetlig, vilket kan försvåra användningen av den. Olika arbetssätt i hur masterdata hanteras kan då leda till missförstånd vilket i sin tur leder till onödig tid som behöver spenderas för att reda ut missförstånden.
Mats beskrev att de delar sin masterdata med moderbolaget och att det ofta uppstår irritation vid till exempel missförstånd kring masterdata. De lagrar sin masterdata på två olika ställen. Mats påtalade att det egentligen är en person som ska vara ansvarig och ha rättighet till att ändra masterdata men att det tyvärr inte följs, utan att det är flera personer som i dagsläget ändrar masterdata. Han förklarade med följande citat:
“Vi delar vår masterdata med vårt moderbolag. Det borde vara en person som ska ha rättighet till att ändra masterdata men tyvärr ser inte vår verklighet ut så.” - Mats
Såväl Gunilla som Sandra uppgav att de delar masterdata med sina dotterbolag. De poängterade även att deras masterdata lagras i tre olika system. Vem som har rättighet att ändra masterdata beror på vilken behörighet personen har i respektive system. Sandra nämnde även att det enligt henne är för många som i nuläget kan ändra masterdata. Gunilla gav uttryck för följande citat:
“Användare i olika roller har olika behörigheter till olika system. Detta styr i sin tur vem som kan ändra, uppdatera och skapa masterdata. “- Gunilla
Jörgen berättade att de delar masterdata med både dotterbolag och leverantörer. Hon påpekade att vissa leverantörer är svåra att arbeta med. Det kan till exempel bero på att de ligger efter i teknikutvecklingen och har gamla system. Jörgen menar att det resulterar i att de har svårt att få den information som de behöver, eftersom leverantören kanske inte ens har den själv. Vidare berättar Jörgen att samarbetet mellan dotterbolagen funkar bra och att det är moderbolaget som bestämmer hur masterdata ska se ut. Jörgen gav uttryck för masterdata lagras i moderbolagets affärssystem och att det är inköpare, han själv samt produktchefer som har rättighet att ändra masterdata. Anette gav uttryck för att de delar masterdata med sina leverantörer. Deras masterdata lagras i en central databas. Hon förklarade att olika avdelningar har olika personer med olika behörigheter som får ändra masterdata, så det kan bli väldigt rörigt. Jörgen förklarade med följande citat:
“Det är tyvärr många som i nuläget får ändra masterdata. Vi måste begränsa till exempel produktcheferna till en begränsad grupp, då de i nuläget är många. “ - Jörgen
4.2 Respondentgrupp ett - masterdata kopplat till implementationen 4.2.1 Implementationen i allmänhet
Respondenterna fick inledningsvis en fråga kring hur de upplevde att implementationen hade gått i allmänhet. Gunilla gav uttryck för att de inte hade underskattat projektets storlek. Detta resulterade i att det fanns gott om tid för att genomföra processens olika faser. Gunilla menar även på, ur ett förebyggande syfte, att det är bra att ha mer tid än nödvändigt i processens olika faser ifall något skulle gå fel. Hon var även positivt inställd till att moderbolaget hade en standard som de skulle följa. Gunilla uttryckte det hela med följande citat:
“Vi hade gott om tid eftersom vi inte underskattade projektets storlek. Jag är även positivt inställd till att vi har en standard som vi ska följa, som vi har fått från
19 moderbolaget.” - Gunilla
Jörgen förklarade att förstudien till projektet var bristfällig. Det ledde till ett flertal komplikationer, bland annat till att projektet blev försenat och framflyttat tre gånger. Den bristande förstudien ledde även till att fel resurser sattes in i projektet. Jörgen citerade följande:
“Vårt nya system såldes som ett standardpaket. Vi har dock väldigt många verksamhetskritiska anpassningar i våran organisation, vilka inte identifierades under förstudien. Därför sattes fel resurser in vilket har skapat en rad olika komplikationer.” - Jörgen
Även Mats och Sandra nämnde problematiken kring rätt resurser insatta. De gav uttryck för att det var svårt att få organisationen till att sätta in rätt och tillräckligt med resurser i projektet. De båda ansåg att detta var något som fick konsekvenser i form av förseningar av diverse aktiviteter. Sandra förklarade att det var utmanande att frigöra resurser i organisationen, vilket behövdes för att träna medarbetare i det nya systemet. Mats uttryckt illustreras med följande citat:
“Projektets resurssättning var mindre bra planerad. Olika stakeholders behövde vara involverade i en högre grad.” - Mats
Både Bertil och Mats ansåg att det fanns rätt kunskap för implementationen i helhet. Mats gav uttryck för att han tror att det gav ett litet försprång inom vissa områden. Bertil tror att det resulterade i att till exempel rätt krav identifierades. Bertil uttrycker det som följer:
“Enligt mig fanns det bra och rätt erfarenheter samt kompetens inom organisationen.
Det ledde bland annat till att vi identifierade rätt krav, vilket enligt min erfarenhet inte alltid är så enkelt.” - Bertil
Jörgen, Anette och Bertil nämnde organisationens masterdata ur en negativ synvinkel. Bertil gav uttryck för att organisationens masterdata var “stökig”, det vill säga att den inte var sorterad i deras gamla system. Det blev problematiskt och tidskrävande när masterdata skulle städas. Både Jörgen och Anette påtalade att de hade gått in i projektet med dålig kvalitet i sin masterdata, vilket i sin tur medförde en rad konsekvenser. Anette gav uttryck för att all masterdata inte kom över från det gamla till det nya systemet, vilket försenade migreringen. Även Jörgen nämnde att det ledde till förseningar i projektet. Jörgens beskrivning kan illustreras med följande citat:
“Vi fick skjuta upp ett flertal aktiviteter på grund av dålig kvalitet i vår masterdata.
Testfasen blev bland annat lidande eftersom de som skulle testa det nya systemet var beroende av vår masterdata.” - Jörgen
4.2.2 Start av masterdatahantering
Här frågades samtliga respondenter under vilket steg i implementationen de hade påbörjat arbetet kring masterdata. Samtliga respondenter berättade att de hade påbörjat arbetet kring masterdata i samband med att projektet startade. Sandra påtalade dock att de hade börjat tjuvkika lite på masterdatastrukturer i det nya systemet innan projektet startade. Hon var dock noga med att påpeka att de inte hade påbörjat något praktiskt arbete utan endast börja kika för att försöka få en uppfattning om det nya systemets strukturer. Sandras uttryck illustreras med följande citat:
“Vi hade börjat tjuvkika lite på masterdatastrukturer i det nya systemet innan vi påbörjade planeringsfasen. Men vi påbörjade inget arbete kring det hela utan började som sagt endast kika för att få en överblick kring hur det kommer att se
