Intervjuer

13.2.1 Intervju med personal på Information Warehouse

___________________________ Namn: Johan Westin och Peter Tunell Befattning och roll: Information Warehouse ___________________________

Frågor:

1. Hur ofta stöter du på fel i ditt arbete?

Johan - Du menar alltså ej tekniska fel utan innehållet dvs logiska fel? Varje vecka dyker det upp någon fråga om informationsinnehållet. I princip tillhandahåller vi systemen, informationen måste någon annan äga. Det är även någon annan än jag som konsumerar informationen, oftast upptäcks det av någon där ute som kör rapporten men de kommer ju oftast till oss och frågar, varför är det så här? Då måste vi kolla om vi har gjort något fel när vi laddat in datat. Så jag kan säga att varje vecka får vi in något fel vi måste gräva i. Konstaterar vi att det är fel indata, ja då måste vi passa bollen vidare. Om vi har orsakat något fel så är det något vi måste fixa. Men minst 9 fall av 10 så är det indatafel, hehe. Det är någon som knappar in galet i källsystemet från början.

Sammanfattning: 1 gång per vecka. 9/10 indata fel

2. Vilka är de vanligaste felen som ni stöter på? Indatafel.

3. Vad tror du är den största grundorsaken att fel uppstår? Indatafel.

4. Vilka system är det mest problem med? Jaa, bra fråga. Hmm.

52

Jag tänker efter nu och det är inte självklart att det behöver vara ett visst specifikt system. Det är en viss typ av information som leder till mycket fel. Jag skulle vilja säga, att det största felet vi har nu är att få fram rätt produktionskostnad för produkt. Vi vill ha produktionskostnad jämfört med vad du sålde den för helt enkelt att få reda på vinsten. Sedan har man ju vad det kostar att ha det på lager och transportera det men det struntar vi i men vad kostar det att producera det här och vad sålde du det för. Sen att vi har olika aktörer i ledet som sätter priset är ju en helt annan sak. Jag skulle vilja säga, produktionskostnad.

Johan Westin frågar Peter Tunell – vad har vi mer för logiska fel? Peter – Orderknowledgement.

Johan – Ja just det, orderkännande.

Vi har automatiserade processer som ibland slår fel verksamhetsmässigt. Det systemet gör internt i en inköpsorder från säljenheten till produktionsenheten eller lagret, centrallagret så spottar den tillbaka ett orderigenkännande direkt men det är kanske inte korrekt, det kanske inte är någon som verkligen har tittat på det. Då får du fel datum och så måste du vänta till någon har tittat på det och gjort ett ordererkännande. Det kanske ska leverera om 3 veckor men systemet kanske spottar ut 1 vecka som standard.

Men hur vet att man ska göra ett internt ordererkännande?

Om du får en special order då vet du och då begär säljenheten information om när ni kan leverera, ett leveransdatum och då gör du ett internt ordererkännande.

Peter – Sedan kan det vara så att man hoppar förbi vissa regler i system, går in manuellt och knappar in data.

Johan – När man går utanför standard processen då åker man på problem nästan jämnt. Ibland är det väldigt vanligt och man är medveten om att man går utanför standard processen, alla vet om det men eftersom företag inte orkar driva igenom saker utan gjort det strömlinjeformat överallt sker sådana saker, vi måste luta oss åt

53

Peter – Andra problem, stoppade ordrar? Som kom på tal under finanskrisen men aldrig varit aktuellt förut. Vissa företag hade kreditproblem och vissa kunde inte betala. Man fick stoppa och granska dessa ordrar en och en vilket ställde till trassel med trassel i våra ledtidsuppföljningar, vi fick inte rätt datum på ordrarna. Det var större problem på vissa marknader än andra.

Sammanfattning: Inte system, men en viss typ av information. a. Produktionskostnad

b. Ordererkännande

c. Personal hoppar förbi regler

d. Stoppade ordrar, påverkar ledtider osv.

5. Hur hanterar ni fel som stöts på i ert arbete, från upptäckt till lösning?

Johan - Lösning? Haha. I vissa fall får man acceptera fel och informera personal så att de är medvetna om detta. I många fall får man sitta med IT människor och koda bort dessa fel tillsammans med folk från verksamheten som förstår orsaken till problemen. Det finns ofta en bra anledning till att man har gjort som man har gjort, som t.ex. stoppade ordrar pga. kreditproblem. Utifrån det försöker vi hantera det här undantaget och ändrar och sätter regler på vårt plan eller i källsystemen osv.

Sammanfattning: Acceptera fel, informera att detta fel får gå igenom.

6. Vad tror ni att man bör göra för att förebygga fel?

Johan - Det vi försöker göra är ju egentligen att vi skapar de här scheman som vi har pratat om, våran specifikation vad vi ska skicka över. Det vi försöker göra är att vi sitter ner med någon som kan källsystemen affärssidan plus de som gör scheman, de som förstår sig på informationsmodelleringen. Förebyggandet har mycket att göra med det grundarbete vi gör där. Man måste titta på källdatat för att redan där hitta fel och på så sätt förebygga fel. Modellering, arbetet med scheman och titta på grunddata innan man börjar ladda in det.

Sammanfattning: Prata med folk från olika sektorer. XML schema analyseras och görs korrekt, Titta på källdata, modellering och titta på grunddata.

54

7. Vad tror ni man bör förbättra för att effektivisera felhanteringen? Johan – Där finns det mycket att göra, absolut.

Peter – Vi får mail ifall det sker något fel, t.ex. att en kund ej fylls i men vi har ingen att skicka felen till. Det kan även vara så man lägger upp 17 kunder på måndagen men på torsdagen lägger man in kundnummer. Ibland kan det vara svårt att avgöra om ett fel verkligen är det eller att det bara uppträtt som ett fel för oss ett par dagar.

Framförallt är det svårt att hitta vem som egentligen äger informationen. Så vi har ju möjlighet att monitorera men kan ej göra så mycket åt problemen som dyker upp. Det är ju datakvalitets fel.

Johan – Vi får felrapporter på saker som egentligen inte är fel, kan vara att något de ej har fyllt i med flit och det finns en god orsak. Vi kanske har för hårda kontroller på vissa saker.

Peter - Det finns rapporter som tittar på vad som är snittet på t.ex. orderingång eller fakturering på senaste 20 dagarna. Det som kommer in idag, skiljer det mer än 5 eller 10 % mot snittet, är det någonting vi vill ha varning på?

Sammanfattning: Notera/logga vad som ej går igenom (på en fellista)

Svårigheter: ett fel kan vara ett fel i några dagar för att bli rätt sen, s.k. ”bluff-fel” Vi har monitorering.

8. Vad tror ni om er egna Proof of function? Känner ej till.

9. Hur ser ni på metadata och hur kan det användas i en felhanteringslösning.

10. Hur ser ni MDM som en lösning?

Johan – MDM är alldeles lysande. Det viktigaste med MDM är processen som du kan få runt objekten som du hanterar i MD-system. Många av problem härleds till tillfället man skapar en kund eller produkt i ett system som har relativt dåligt indatakontroll, har dåligt godkännande förfarande osv. Med MDM system hoppas vi att man får en bra process kring hur man skapar informationen och bra kontroller på hur du skapar

55

information attribut på de objekt som masterdata hanterar. Får man till det så tror jag att datakvaliteten för vår del skulle öka markant.

Sammanfattning: Lysande. Vi har många problem: ingen indatakontroll men med MDM: bra process, bra kontroll över de objekt man skapar.

11. Vad tycker ni om ert aktuella felhanteringssystem?

Johan- Ja, vi har ju brister i det här logiska. Precis som Peter beskrev, vi har en felhanteringslogg som vi inte har fått till processen kring. Vi har ju ingenstans att skicka felen till, vem är mottagare? Stora problemet är att få till processen på

användarsidan, att man får ett feedback och att de verkligen gör någonting med det här och förbättra informationen som skickas. Där skulle man kunna göra lite förbättringar med MDM lösningar, lite mer reaktivt. Om vi kunde få lite mer proaktivitet där man har kontroller på indatat genom en masterdatalösning.

Går det att använda er befintliga arkitektur för att lösa problem.

Johan – Ja, det tror jag. De stora problemen är inte tekniska utan organisatoriska. Vet inte om Peter berättade men vi har ju börjat införa en kontroll på s.k. ”idiotvärden” t.ex. en fakturarad på en miljard, då är det skumt så vi ska automatisera det. Sedan har vi erbjudit dem någonting de inte har nappat på, att de själv kan definiera regler de skulle vilja ha och så får vi larm när man går utanför de reglerna. Man måste se till att anställda blir medvetna om dessa problem, att verksamheten öppnar upp ögonen och tar det på allvar. Det är mer där problemet ligger än tekniskt.

Sammanfattning: Vi har en felhanteringslogg, men vi har ingen att skicka felen till. Finns ingen process. Dock inte lika bra som MDM eftersom det blir en efterkontroll med vår aktuella felhantering.

12. Har ni några förslag på nya felhanteringslösningar?

Peter- Problemet är ju att vi inte har någon att lägga saker på. Det är där stora

problemet är tycker jag. Vi kan ju komma på hur många tekniska lösningar som helst men vi behöver processer så att det finns ägare av data och att de tar sitt ansvar.

56

Johan- Systemstöd för informationsägarskap så att man vet vem som är ägare för olika objekt. Problemen hamnar sedan hos rätt person.

Känner ni till någon plattform som skulle kunna stödja det ni föreslår.

Johan + Peter – Nej. Vi har ju tivoli och lite till men det är mer annat folk från IT avdelningen som vet mer.

Sammanfattning: Problem är organisatoriska ej tekniska.

- Automatisera ”idiotvärden”,

- Folk måste ta problematiken på allvar.

13. Vems är ansvaret när det går fel i IT systemen?, fel som kostar företaget. Johan – Om vi klantar oss med informationen från vår sida är det ju vårt fel. Om vi skriver i en kolumn i databasen ”netsales” men det ska vara ”quantity” istället så är det ju vårt fel.

Men ansvaret är tydligt och det finns dragna gränser eller är det diffust? Vems är ansvaret? Ingen vill ta hand om problemet?

Johan – Ja, det är diffust. Vi vet ofta vart felet kommer ifrån men det är ingen person vi kan vända oss till och skicka felet till.

Peter – Vi har ansvar att överföringen sker korrekt av det information som skickas till oss via olika system. Att de har fel indata kan inte vi ansvara för. Hos oss är ansvaret glasklart.

Sammanfattning: Först och främst lösa organisatoriska.

- Systemstöd för objektägarskap.

13.1 finns det dragna gränser på vem som ska lösa vad och vem som ansvarar för vad?

57

14. Spårar ni transaktioner idag? Om inte, hur ser ni på en sådan lösning? -

15. Vi har hört talas om ett tidigare projekt som heter PDF. Vad var det för projekt och hur gick det?

Peter - Vi har inte varit inblandade i det. Vi laddar våra filer på vårt sätt. Tackade nej till det.

16. Ni planerar att ersätta 48 gamla Sopic system med ett SAP. Vad kommer detta ha för effekt?

Johan – Det vi hoppas mer på är mer ordning på information. Bättre indatakontroll och man jobbar inom standardprocessen.

Kan det medföra att man behöver konfigurera andra system en del, leda till komplikationer?

Johan – Det pågår faktiskt en förstudie på hur det vi läser från Sopic idag, hur hittar vi det i SAP? Det kommer inte bli 100 % matchning där emellan. Man kommer behöva jämka och ta bort vissa fält osv. Kanske även behöver ändra på lite arbete vi gjort, scheman och sådant.

Sammanfattning: Bättre indata kontroll, mer standardiserat. Vi kommer behöva jämka fält för att SAP ska funka med andra system som pekar mot Sopic.

17. Vi vet att många av felen orsakas av anställda själva genom inkorrekt data matas in. Vilka är era insatser för att anställda ska få kunskap om vad som gäller? Johan- Haha, vi gör väl egentligen ingenting åt det. Vi hoppas på bättre stöd i SAP för att få bättre indata. Vi informerar att man behöver skärpa användarna som matar in data.

Peter – Vi har ju 42 produktions Sopic också, 2 av dessa är identiska alla andra har ”tweakade” konfigurationer, man använder samma problem men man löser dessa på olika sätt vilket ger oss problem. I SAP kanske man har 2-3 sätt att lösa problemen på istället för nuvarande 27 sätt.

58

Johan – Vi kommer även i framtiden att ha special fall men kanske mer

dokumenterade och kontrollerade. Det kommer bli mer strukturerad när vi inför SAP. Systemstöd är en sak men gemensamma processer är lika viktigt.

Sammanfattning: Inget, hoppas SAP ska lösa vissa problem. Vi har dessutom (42) produktions Sopic, varje sopic löser problem på eget sätt. SAP kommer lösa en del problem, mer strukturerat med SAP.

18. Hur ser ert användargränsnitt ut? Kan man redan där påverka och förhindra att fel inträffar?

Peter – Notifiera i fält att det behövs data eftersom vissa fält alltid behöver data. Johan – Vi skapar ingen data på vår avdelning.

Kan det vara så att i ett XML schema, att ett visst attribut är primärt för ett system men ej för ett annat och man får ett undantag?

Johan – Absolut.

Peter – Vi har ju problem med det att ett fält är mandatory men inte i ett visst system och då smäller det senare i ett annat system. För oss som konsumerar data är det ju svårt att rätta till de här felen. Hade vi suttit som ägare av processen, produkt eller system för Sopic hade vi sett till att det finns kontroll och att det behövs data för mandatory fältet. Det enda vi kan göra är att säga till dem, det här borde ni fixa. Även där vet vi inte vem vi ska vända oss till då vi inte vet vem som äger datat. Är det han som är systemägare? Han som äger produkten? osv.

Johan - Ibland namnger man ej attribut på samma satt vilket försvårar arbetet så ibland ändrar vi namn på dessa så att t.ex. supplysidan förstår.

59 13.2.2 Intervju med projektledare för EPLM 2.0-projektet

___________________________

Namn: Janni Weber (samt Jan-Erik Lundberg stundtals) Befattning och roll: Projektledare för EPLM 2.0

___________________________ Frågor:

1. Hur ofta stöter du på fel i ditt arbete?

Just jag stöter inte på så ofta, men som vi hörde från Jan-Erik är det nästan dagligen som man får in flera rapporter. Sen om alla är logiska, men dagligen. Så relativt ofta.

Sammanfattning: Dagligen.

2. Vilka är de vanligaste felen som ni stöter på?

Att data inte har skickats eller tagits emot, och är det logiska fel så kan det vara att användaren har fyllt i fel värden. Att det är någon businesslogik som ska utföras i det mottagande system som kräver ett visst inputvärde som den får. Om man fyllt i fel eller inte validerats på korrekt sätt. Om vi har valt EPLM 2-projektet, det vi håller på med nu i testmiljön så kan fel vara: mottagande system bara förväntar sig få ett värde som en string, textfält, men det får det som en integer för att vi har kommunicerat fel när vi har implementerat allt för vi har sagt att dom tror att vi ska implementera som en text och vi tror att vi ska implementera som en integer. Det kan vara ett vanligt fel. Det får vi rätta till under projektet.

Det är för att systemen förstår ett visst format, alltså att dom förstår olika format?

Nej nu ska vi alltså följa toolingscheman som vi kallar som bygger på SAP, som har en Enterprise Service Repository där de tillhandahåller servicar out-of-the-box som vi kan använda, som företaget kan använda av det som är som XML-scheman. Men dom täcker inte eller dom är inte exakt så som vi vill ha det på Tooling, att vi tar dom rakt av utan vi gör våra egna toolingmodeller så använder vi oss så mycket vi kan från det då. Men vanliga fel också när man formulerar produktdata kan vara att dom har fyllt i med fel noggrannhet, värde och då blir beräkningarna fel i mottagande system. Att den kan ha avrundat fel när de ska konvertera mellan olika enheter. Mycket sådana fel. Det

60

är vanligt att, nu under mappningsjobbet som sagt så då är det inte samma systemstödning. Det kan vara att du har, att SAP måste skilja på stora och små

bokstäver medan användaren som ger oss datan just nu inte behöver det för att ha gjort det i ett excelark.

Sammanfattning:

3. Vad tror du är den största grundorsaken att fel uppstår? Just nu är det mycket som är nytt, mycket är nog okunskap. Är det bland anställda då?

Ja precis, när man fyller i data. När man inte vet vad datan är till för blir det sämre kvalitet. Sen så är det klart om vi kan bygga in valideringar på allt till förbannelse så att det alltid blir rätt men det är ganska svårt att få det här helt mappat och klart. Men en del är nog också att vi har dåliga valideringar och att, alltså är inte syftet med datan tydligt så är det lätt att användarna inte förstår vad dom ska fylla i helt enkelt, då kan det bli fel på grund av det. Sen så är det klart tekniska bitar också, landskapet är väl inte heller helt stabilt.

Sammanfattning:

4. Vilka system är det mest problem med?

Ja, vi har haft mest problem med EPLM-sidan, alltså inte MDM. Utan ERP-systemet. Som jag har förstått, jag kan inte tekniken fullt ut men MDM är mer flexibelt när det gäller att modellera upp egna modeller, egen datastruktur. ERP-systemet

tillhandahåller ju färdiga modeller som är i ett ERP-system. När vi går utanför dom så måste vi göra en massa utökningar, och det ställer till det här med Product Data Flow. När man skickar datat så kan det vara, den ska ta en del standard SAP, en del

utökningar och då blir det mer komplext. Annars så är det i EPLM 1.0, jag vet inte, vilka system är det mest problematiskt med där? (frågar Jan-Erik)

Vilken typ av system, det kan ju vara typer också.

Oftast är det dem som innehåller mycket logik, affärslogik som ska validera mycket. J-E: Det krockar mellan logiken som är det största problemet. Enskilda system fungerar bra men det är integrationen som inte fungerar.

61

J-E: Ja att man har krockat lite. Regler kommer i konflikt?

Ja, precis, det kan ju vara som nu när produktdata att dem får ett värde med tre decimaler men dom förväntar sig att få sex decimalers noggrannhet skulle det kunna vara till exempel. Eller att man avrundar på olika sätt i olika system, eller att ett visst värde måste vara ifyllt för att ett annat system ska kunna exekvera en viss grej, men man får inte det värdet.

J-E: Man feltolkar definitionen på ett objekt, så kommer det ett felfall helt enkelt när det faller utanför ramen i logiken.

Om det skulle uppstå sådana avrundningsfel, hur gör ni för att lösa det här felet? Just nu det här är ju framtiden, det håller vi på att testa just nu den här biten av fel. Det värsta är att det inte finns något bra sätt att hantera det i dagens lösningar.

Det involverar många parter alltså? Felsöka?

Jag vet inte hur de gör i dagsläget. Tanken för oss är ju att det ska bli en felrapport på det ur systemet att det har gått fel. Jag vet inte hur det kommer funka.

J-E: Det är svårt att se systematiska fel, det krävs väldigt mycket manuellt arbete för systematiska fel. Man hittar ett fel så löser man det och sen kan det komma två månader senare. Då är det jättesvårt att hitta att det har funnits igen.

Janni: Men nu ska det förhoppningsvis, det här nya felhanteringssystemet, vara bättre