Fortsatt forskning skulle kunna avse konkreta implementationsförslag i en statlig myndighet för de möjliga lösningar som lyfts i denna studie. Implementationen av ett dokumentationsverktyg alternativt ett rättighetsbaserat system i en statlig myndighet är en omfattande förändring med åtskilliga faktorer att ta hänsyn till. En större studie där en sådan implementation undersöks är ett förslag på fortsatt forskning.
Ett annat förslag på fortsatt forskning är att se huruvida en av de presenterade tekniska lösningarna presterar i jämförelse med den kulturella förändringen. Här skulle faktorer som kostnader,
resursåtgång samt hur väl de olika lösningarna hanterar den upplevda problematiken vara intressanta aspekter.
31
Referenser
(2014). How to save on software maintenance costs An Omnext white paper on software quality November 2014.
Bang, M. (2019). Gör en ärlig nulägesanalys för att ta rätt strategibeslut. Bonnier Management 360.
Hämtad från https://www.management360.se/articles/2600
Björklund, M. & Paulsson, U. (2012). Seminarieboken: att skriva, presentera och opponera. (2. uppl.) Lund: Studentlitteratur.
Chomal, V.S & Saini, J.S. (2015). Software Template for Evaluating and Scoring Software Project Documentations. International Journal of Computer Applications 116(1):15-27. doi: 10.5120/20300-2333.
Christa, S., Madhusudhan, V., Suma V., Rao J.J. (2017) Software Maintenance: From the Perspective of Effort and Cost Requirement. Proceedings of the International Conference on Data Engineering and Communication Technology. Advances in Intelligent Systems and Computing, 469. 759-768. doi:
10.1007/978-981-10-1678-3_73
CJ, Satish., M, Anand. (2016) Software Documentation Management Issues and Practices: A Survey.
Indian Journal of Science and Technology, 9. doi: 10.17485/ijst/2016/v9i20/86869
CJ, Satish., M, Anand., P, Thendral. (2016). A Review of Tools for Traceability Management in Software Projects. International Journal of Research in Emerging Science and Technology, 3. 6-10.
DiVA. (u.d.). Om DiVA portal. Hämtat från DiVA, 2020-04-12: http://www.diva-portal.org/smash/search.jsf?dswid=4293
Fernández-Sáez, A.M., Caivano, D., Genero, M., & Chaudron, M.R. (2015). On the use of UML documentation in software maintenance: Results from a survey in industry. 2015 ACM/IEEE 18th International Conference on Model Driven Engineering Languages and Systems (MODELS), 292-301.
Flodén. J. (2013). Essentials of Information Systems (1:2. ed.). Studentlitteratur AB, Lund.
Holmbergs
Forward, A & Lethbridge, T. (2002). The relevance of software documentation, tools and
technologies: a survey. Proceedings of the 2002 ACM symposium on Document engineering - DocEng 02. 26-33. doi: 10.1145/585064.585065.
Garousi, G., Garousi, V. Moussavi, M. Ruhe, G & Smith, B. (2013). Evaluating Usage and Quality of Technical Software Documentation: An Empirical Study. EASE '13: Proceedings of the 17th
International Conference on Evaluation and Assessment in Software Engineering, 42(1), 24–35. doi:
10.1145/2460999.2461003
G. Buchgeher., C. Klammer., B. Dorninger., & A. Kern. (2018). Providing Technical Software Documentation as a Service - An Industrial Experience Report. 25th Asia-Pacific Software Engineering Conference (APSEC), 581-590.
Goldkuhl, G. & Röstlinger, A. (2012). Förändringsarbete och förändringsanalys Enligt SIMMetoden. Hämtad från: http://www.vits.org/publikationer/dokument/774.pdf Google. (u.d.). About Google Scholar. Hämtad från Google Scholar, 2020-04-12:
https://scholar.google.com/intl/en/scholar/about.html
32 Informationsverkstan. (uå). Förvaltningsdokumentation - Dokument. Hämtad 2020-04-03 från:
https://www.infoverk.se/sida/http-informationsverkstan-int2-se-sida-informationsverkstan-tar-greppet-om-din-foervaltningsdokumentation
Langer, A.M. (2008). Analysis and Design of Information Systems [electronic resource] Third Edition. London: Springer-Verlag London Limited.
Moreno, L. (2014). Summarization of complex software artifacts. In Companion Proceedings of the 36th International Conference on Software Engineering (ICSE Companion 2014), 654–657.
doi:10.1145/2591062.2591096
Nasir, Z., Abbasi, A.Z. (2010). A Framework for Software Maintenance and Support Phase.
International Conference on Information and Emerging Technologies, 1-6. doi:
10.1109/ICIET.2010.5625668
Oates, B. J. (2005). Researching information systems and computing. London: SAGE.
Pensionsmyndigheten. (2015). Molnstjänster i staten - En ny generation av outsourcing. Hämtad från:
https://www.pensionsmyndigheten.se/sokresultat?query=Molntj%C3%A4nster+i+staten%3A+en+ny +generation+av+outsourcing
Pfleeger, S.L. (2001). Software engineering: theory and practice. (2. ed.) Upper Saddle River:
Prentice Hall.
Pigoski, T.M. (1996). Practical software maintenance: best practices for managing your software investment. Chichester: Wiley.
Rutio, P. (2007). Normative Point of View. Hämtad 2020-05-01 från http://www2.uiah.fi/projekti/metodi/178.htm
Summon Dalarna. (11 april, 2019). Så söker du i Summon. Hämtat från Högskolan Dalarna, 2020-04-12: https://www.du.se/sv/bibliotek/sokhjalp/sa-soker-du-i-summon/
Trafikverket. (u.å). Driftdokumentation mall. Hämtat 2020-02-04 från Trafikverket, Intranät.
Trafikverket. (u.å). Presentation av anläggningsinformation IT [Powerpoint-presentation]. Hämtat 2020-02-11 från Trafikverkets Intranät
Trafikverket. (u.å). Stöd för val av lagringsplats. Hämtat 2020-02-04 från Trafikverket, Intranät.
Uzialko, A. C. (2019, 19 februari). Document Management Systems - A Buyer's Guide [Blogginlägg].
Hämtad från: https://www.businessnewsdaily.com/8026-choosing-a-document-management-system.html
Waits, T., & Yankel, J. (2014). Continuous system and user documentation integration. 2014 IEEE International Professional Communication Conference (IPCC), 1-5. doi:
10.1109/IPCC.2014.7020385.
33
34 Funktionsbeskrivning -
Dokumenthantering
Funktionsbeskrivning Stöd för val av lagringsplats PM
Tabell 1.3
35 Figur 5 - Dokumentationshanteringsmodell
Bilaga 5 – Verksamhetsdiagnos
Figur 6 -Verksamhetsdiagnos
Bilaga 5 – intervjuguide
Operativ ledare
1. Vad är din roll på Trafikverket? Vad arbetar du med?
2. Vad är driftdokumentation och vad innehåller den? Vad innebär den för dig?
3. Hur kommer du i kontakt med driftdokumentationen i ditt arbete?
4. Hur ser hanteringen av driftdokumentationen ut idag på avdelningen? Bakgrundsbeskrivning efterfrågas.
• Hur ser lagringen ut?
• Ägande?
• Process? (Någon modell som följs?)
• Utformning?
5. Hur började ni arbeta på det här sättet?
6. Skiljer sig hanteringen åt beroende på system och avdelning? Hur?
7. Vilka är involverade i driftdokumentationshanteringen? (Roller/befattningar)
8. Vilka utmaningar/nackdelar finns enligt dig med dagens hantering av driftdokumentationen?
(Inriktning mot lagring, ägande, process och utformning).
9. Vilka fördelarna med dagens hantering av driftdokumentationen enligt dig? (Inriktning mot lagring, ägande, process och utformning).
10. Hur skulle en fungerande hanteringen av driftdokumentationen kunna se ut enligt dig?
11. Hur ska ni nå den lyckade hanteringen enligt dig?
• Vid listning av ett antal faktorer, varför just dessa faktorer är viktiga.
36 12. Varför är det enligt dig viktigt att hanteringen av driftdokumentationen förändras?
13. Kom gärna med något eget exempel på en fråga som vi kan ha missat som är viktig utifrån ditt perspektiv.
Drifttekniker
1. Vad är din roll på Trafikverket? Vad arbetar du med?
2. Vad är driftdokumentation och vad innehåller den? Vad innebär den för dig?
3. Hur kommer du i kontakt med driftdokumentationen i ditt arbete?
4. Vilka delar av driftdokumentationen kommer du oftast i kontakt med? (Mest vitala delar) 5. Vad händer när information saknas eller inte är uppdaterad?
a. Hur påverkas dina arbetsuppgifter när information saknas i driftdokumentationen?
6. Vilka utmaningar/nackdelar finns enligt dig med dagens hantering av driftdokumentationen?
(Inriktning mot lagring, ägande, process och utformning).
7. Vilka är fördelarna med dagens hantering av driftdokumentationen enligt dig? (Inriktning mot lagring, ägande, process och utformning).
8. Finns det onödiga delar i den befintliga driftdokumentationen enligt dig som drifttekniker?
9. Vilken del av driftdokumentationen är mest utmanande att fylla i enligt dig?
10. Hur skulle en fungerande hantering av driftdokumentationen kunna se ut enligt dig?
11. Hur skulle den önskade hanteringen av dokumentation främja dina arbetsuppgifter? (Största skillnader).
12. Vad vill du ska lyftas fram i vår förstudie gällande hanteringen av dokumentation?
13. Kom gärna med något eget exempel på en fråga som vi kan ha missat som är viktig utifrån ditt perspektiv.
Tekniknära förvaltare
1. Vad är din roll på Trafikverket? Vad arbetar du med?
2. Vad är driftdokumentation och vad innehåller den? Vad innebär den för dig?
3. Hur kommer du i kontakt med driftdokumentationen i ditt arbete?
4. Vilka delar av driftdokumentationen kommer du oftast i kontakt med? (Mest vitala delar) 5. Vilka utmaningar/nackdelar finns enligt dig med dagens hantering av driftdokumentationen?
(Inriktning mot lagring, ägande, process och utformning).
6. Vilka är fördelarna med dagens hantering av driftdokumentationen enligt dig? (Inriktning mot lagring, ägande, process och utformning).
7. Hur skulle en fungerande hantering av driftdokumentationen kunna se ut enligt dig?
8. Hur skulle den önskade hanteringen av dokumentation främja dina arbetsuppgifter? (Största skillnader).
9. Vilken del av driftdokumentationen är mest utmanande att fylla i enligt dig?
10. Vad händer när information saknas eller inte är uppdaterad?
a. Hur påverkas dina arbetsuppgifter när information saknas i driftdokumentationen?
11. Kom gärna med något eget exempel på en fråga som vi kan ha missat som är viktig utifrån ditt perspektiv.
Respondent gällande informationssäkerhet
1. Vad är din roll på Trafikverket? Vad arbetar du med?
2. Vad upplever du är de största skillnaderna mellan en statlig myndighets och en privat aktörs säkerhetsarbete rörande information? Vilka restriktioner medför en statlig myndighet?
3. Vad upplever du är fördelarna gällande informationssäkerhetsarbetet i en statlig myndighet?
4. Vad upplever är utmaningarna/nackdelarna gällande informationssäkerhetsarbetet i en statlig myndighet?
5. Hur påverkas ditt arbete av att Trafikverket är en statlig myndighet?
37
N: Vi ställer frågorna som vi skickat till dig tidigare så kanske det dyker upp följdfrågor, ca en till två per fråga. Vi börjar med den första frågan:
Vad är din roll på Trafikverket? Och vad arbetar du med?
R1: Jag är operativ ledare för IKTaa alltså anläggningsinformation och applikationsdrift och har väl så varit i, har haft rollen länge men befattningen har jag haft sedan november. Innan det jobbade jag som tekniker inom samma enhet. Har varit i Banverket/Trafikverket i 20 år i mars.
N: Vad är driftdokumentation och vad innehåller den? Vad innebär den för dig?
R1: Driftdokumentationen för oss är ju den dokumentation som innehåller all viktig information som vi måste ha i vår gruppering för att på ett korrekt sätt hålla systemen vid liv. Veta var de ligger, vad de gör, vilka som använder systemen och eventuellt finns det med kända fel och lösningar. Det är absolut vårt viktigaste dokument som vi har gällande driftåtagandet.
A: Hur kommer du i kontakt med driftdokumentationen i ditt arbete?
R1: Just i mitt arbete så... Visst jag rycker väl in och gör teknikerdelar jag också men oftast de gånger jag kommer i kontakt med driftdokumentationen är när kanske PSL:erna eller någon annan vill ha svar på frågor kring ett system. Oftast vart de ligger osv. Jag går in och kontrollerar
driftdokumentation. Jag går dessutom in och gör stickprov och kontrollerar hur pass den är uppdaterad osv. Så jag har väl allmän koll på dem driftdokument som vi har för att se att de är uppdaterade så långt som jag kan bedöma.
A: Tar du hjälp av någon annan när du bedömer ifall dokumenten är korrekt ifyllda, innehåller korrekt information och är uppdaterade?
R1: Ja det gör jag. Då tar jag hjälp av den som är “huvudtekniker” om jag säger så för det system som vi har och påtalar de brister som finns så att dokumentet bollas tillbaka till tekniknära förvaltare och ta hjälp därifrån så att det blir uppdaterat korrekt.
A: Hur ser driftdokumentationshanteringen ut idag på Enhet IKTaa och avdelning IKTa?
R1: Idag lagras driftdokumentationen i vårt arbetsrum vilket inte är optimalt eftersom det inte är 24 timmars drift på arbetsrummet och vi har system som har 24 timmars drift. Så skulle arbetsrummet gå ner mitt i natten så skulle vi inte komma åt dokumentationen. Så det är inte optimalt alls. Vi har skapat upp.. . Men vi kan kommer till det längre ned med den här piloten som pågår.
A: Den här 24 timmarsdriften som du pratade om tidigare, är det just ifall arbetsrummen inte skulle vara tillgängliga som du syftar på?
R1: Ja, skulle arbetsrummet gå ner mitt i natten skulle vi inte komma åt dokumentationen. Och det finns inte heller någon beredskap för att rycka ut och laga det där, arbetsrummet alltså, mitt i natten.
N: Skulle du bara kunna förklara lite snabbt vad som menas med arbetsrum?
R1: Det får du nästan prata med sharepoint-teknikerna om men det är en yta/area i sharepoint som det går att sätta behörigheter osv på. Vilka som ska komma åt och läsa innehållet.
A: Hur ser ägandet av dokumentationen ut?
R1: Kring ägandet var det tidigare vi på driften alltså som ägde driftdokumentationen. Men enligt det nya arbetssättet som vi arbetar utifrån nu är det den tekniknära förvaltaren som är ägare av
dokumentationen. Men som det ser ut idag kommer de inte ens åt den där den ligger för de har inte behörighet till vårt arbetsrum och får inte heller behörighet dit. Det är alltså en säkerhetsfråga för då kommer de åt alla driftdokument. Skulle någon ha onda avsikter kan man lägga ihop information från flera av de här och få fram saker som man inte borde ha åtkomst till.
A: Jag undrar bara, det här med att ni ägt dokumentationen innan, vad var det som gjorde att det ändrades?
38 R1: Det vet inte jag faktiskt vad det var som gjorde att man flyttade ägarskapet till den tekniknära förvaltaren. Men det tycker jag är helt rätt för det är den tekniknära förvaltaren som har den stora kunskapen kring hela systemet och dess förvaltning. Så det är helt rätt det borde ligga där.
A: Tror du att utformningen av dokumentationen kan påverkas av att ägarskapet av dokumentationen ligger hos TF? För de jobbar väl inte direkt utifrån dokumentationen?
R1: Nej det gör de ju inte. När det gäller framtagandet av dokumentationen så är det ju oftast drifttekniker i samarbete med utvecklare som tar fram den så det är sällan, i och för sig det kan nog skilja sig mellan olika tekniknära förvaltare men oftast överlåter de ju skapandet och ajourhållande till tekniker och utvecklare.
A: Vi har läst lite angående tidigare forskning inom området angående motivationen att få en korrekt ifylld och uppdaterad driftdokumentation. Om ni skulle äga driftdokumentationen tror du det skulle påverka hur dokumentationen utformas och att det finns uppdaterad
dokumentation eftersom ni är beroende av dokumentationen på ett annat sätt?
R1: Svar nej, tyvärr. Vi har haft jättestora problem eller jag har uppmanat ständigt att
dokumentationen är uppdaterad men det finns någon inbyggd mekanism där att dokumentationen är väldigt jobbigt. Så tyvärr nej. Så vi har utformat piloten som är pågående nu gör att vi kommer få eller åtminstone har förutsättningar för att få en uppdatering på dokumentering.
N: Hur började ni arbeta på det här sättet som tillämpas idag?
R1: Det som tillämpas idag där jag väl fortfarande ser det lite som att det är vi som är initiativtagare till att det blir uppdaterat. Vi jobbar ju fortfarande utifrån hur det var när vi ägde dokumentationen.
Jag vet inte, vi har väl alltid gjort så att vi som sätt till att distribuera mall, vi har sätt till att påtala när något inte stämmer och det är vi som har skickat det vi har sett som original av dokumentet till utvecklare eller TF. Det är ett så pass inarbetat arbetssätt att det faktiskt har funnits där de 20 år som jag arbetat här.
N: Skiljer sig hanteringen åt beroende på system och avdelning? Hur skiljer den sig i sådana fall?
R1: Det där har jag svårt att svara på. Hur andra avdelningar som t ex järnväg hanterar sin
dokumentation, det vet inte jag så jag kan inte svara på det. Jag vet att vi har haft ett möte kring detta och jag vet att hanteringen skiljer sig åt. En del har det på fileshare, TFS:en, en del har det i
arbetsrum. Så att jag vet att det skiljer sig men sen hur de hanterar dokumentationen när det gäller uppdateringar osv det vet jag faktiskt inte. Hur det skiljer sig åt mellan systemen som vi har så vi hanterar ju all dokumentation oberoende på vilket system det är. Det är samma mall som gäller. Vi har en mall och som är ganska så mastig. Den är bara framtagen för att det ska kunna täcka alla system oavsett om det är en liten web eller ett stort komplext 24 timmars system. Man fyller i de rubriker där man har information. Det är många man kan fylla i att det inte är applicerbart för att det inte gäller för den sortens system helt enkelt.
N: När det blir så här många saker som inte är applicerbara för ett specifikt system, kan det vara en, tror du, anledning till att dokumentation inte är så lockande?
R1: Nej det tror jag inte för att den enda gång som det egentligen är bökigt att få fram
dokumentationen är när an skapar den. Sen att ajourhålla den så att den är up-to-date ska ju inte vara så jobbigt. Det är ju när man byter serverar eller när det tillkommer någon tjänst t ex vid någon utveckling alternativt när man ändrar i förvaltningsstrukturen. Så det är inte så jättemycket jobb att hålla dokumentationen uppdaterad när den väl är på plats. Så jag ser inga brister på det viset i mallen att den på något vis skulle vara jobbig att jobba med.
N: Jag tänkte på en till grej angående det här med att systemdokumentationen skiljer sig mellan system här på enheten eller avdelningen. Jag har väl själv observerat att det funnits olikheter när det kommer till just driftdokumentation i arbetsrummet. När skapades den här mallen och började användas?
R1: Den vi har nu, ja den senaste uppdateringen jag gjorde i den mallen var 24:e februari. Sen finns det dokumentation som ligger i gamla mallar. Jag har påtalat att denna bör lyftas till senaste mall.
Största delen av den information som vi behöver finns ju även i den gamla mallen. Det har dock
39 tillkommit rubriker i den nya mallen som saknas i den gamla mallen. Till exempel namn på
förvaltningsgrupp i Remedy och lite annat. I det stora finns information som bör finnas med i den senaste mallen. Så länge informationen är till 98% korrekt och den finns med får det vara good enough så länge.
A: Vilka är involverade i driftdokumentationshanteringen?
R1: Det är nästan uteslutande utvecklare och systemtekniker. Sen är väl TF inblandade ibland. Det kan nog ofta vara TF som fyller i när det gäller förvaltningsorganisation och lite sådana saker. Men i övrigt vad system gör och vilka komponenter som finns i system är det nog utvecklare och tekniker som arbetar tillsammans som skapar det.
A: Vilka utmaningar/nackdelar finns enligt dig med dagens hantering av driftdokumentationen?
R1: Som jag sagt tidigare så ligger inte dokumentationen på 24/7-lagring utan det är bara dagtids-SLA på arbetsrummet där det ligger idag. Plus att tekniknära förvaltare inte har tillgång till dokumentationen. Som vi idag ser som originalet. Det gör ju att så fort dokumentationen ska
uppdateras någonstans måste vi skicka det som vi har till Tekniknära förvaltare som utifrån det då får initiera ett möte med berörda för att uppdatera och sen skicka tillbaka till oss.
A: Det är alltså så att TF äger driftdokumentationen kan man säga och ni lagrar den och de kommer inte åt den på er lagringsyta?
R1: Precis. Jättedumt.
N: Varför vill man inte ge ut behörighet på individnivå?
R1: Per dokument i så fall menar du, måste det väl bli?
N: Ja, precis.
R1: Jag vet inte, jag skulle inte vilja vara den som har hand om den behörighetsstrukturen i så fall.
För så fort det byts utvecklare eller TF så måste, eller ja i och för sig alla tekniker har ju åtkomst till all dokumentation men annars måste hela tiden uppdatera den behörigheten när det gäller runt förvaltningen runt som ska ha. Då måste man sätta behörigheten på varje dokument i så fall. Det där har mycket med att Tekniknära förvaltare idag inte är säkerhetsklassade. Så de kommer ju komma åt all dokumentation om vi ger behörighet till mappstrukturen där det ligger. Då kommer de åt all dokumentation. Nu har vi viss dokumentation som vi inte får lägga ut ens så att vi inom gruppen kommer åt det. Det är ju våra mest säkerhetsklassade system där vi bara har två tekniker idag som får komma åt den dokumentationen. Så den dokumentationen den hanterar förvaltningen själva och äger och har på sina väl skyddade arbetsrum.
N: Varför är inte alla tekniknära förvaltare säkerhetsklassade?
R1: Ingen aning.
A: En fråga kring olika lagringsytor, vad är ett arbetsrum, TFS:en och fileshare?
R1: På ett fileshare då har man lagringsarea skapad på en server, oftast med redudans så skulle en server gå ner så tar en annan server över. Så det är 24/7 på det. Där kommer man alltid komma åt dokumenten.
A: All dokumentation som ni tillhandahåller, ligger det i ett gemensamt fileshare?
R1: Nej, inte nu. Det ligger i ett arbetsrum i sharepoint och där är det inte 24/7-drift. Det är inte en redundant miljö på det viset.
A: Och fileshare är då en nätverksmapp som man kommer åt via utforskaren?
R1: Ja.
N: Vilka är fördelarna med dagens hantering av driftdokumentationen enligt dig?
R1: Ja det är ju att det är ett väl inarbetat sätt och alla är medvetna om var den finns. Behöver inte leta utan allt finns lagrat på ett och samma ställe. Det är väl det som jag kan se som en fördel idag.
A: Är övriga delar av hanteringen negativt?
R1: Ja, jag tror ju att det blir mycket bättre om vi kommer arbeta utifrån hur piloten är utformad och att ägandet ligger där ansvaret borde ligga.
A: Hos TF?
40 R1: Ja, hos TF. För att TF är den som har absolut bäst koll på allt rörande “sitt” system och dit bör även dokumentationen höra.
A: I den här nya lösningen skulle TF komma åt dokumentationen?
R1: Då kommer TF vara ägande och äger och har originalet hos sig men distribuerar alltid senaste uppdaterade versionen som kopia till oss där vi lagrar kopian hos oss.
A: för nu är det nästan tvärtom?
R1: Ja, men det är fortfarande så att de kan. Saken är den att vi idag anser att vi har originalet. Sen skickar vi det till TF som kanske spar ner det någonstans, på ett arbetsrum säger vi. Sen i sin tur distribuerar TF detta till en utvecklare som läser igenom och uppdaterar och lite så och säkert spar ner det hos sig också. Sen när den är klar distribuerar utvecklaren tillbaka till TF som då förhoppningsvis uppdaterar hos sig där den har dokumentationen som sen distribuerar tillbaka till oss. Det här kommer resultera i att det förmodligen kommer att finnas tre stycken olika original. Då vet vi inte riktigt vilket
R1: Ja, men det är fortfarande så att de kan. Saken är den att vi idag anser att vi har originalet. Sen skickar vi det till TF som kanske spar ner det någonstans, på ett arbetsrum säger vi. Sen i sin tur distribuerar TF detta till en utvecklare som läser igenom och uppdaterar och lite så och säkert spar ner det hos sig också. Sen när den är klar distribuerar utvecklaren tillbaka till TF som då förhoppningsvis uppdaterar hos sig där den har dokumentationen som sen distribuerar tillbaka till oss. Det här kommer resultera i att det förmodligen kommer att finnas tre stycken olika original. Då vet vi inte riktigt vilket