Vilken metod kan användas för att bredda IT-system mot nya marknader?

Transkript

1 EXAMENSARBETE INOM TEKNIK OCH EKONOMI, GRUNDNIVÅ, 15 HP STOCKHOLM, SVERIGE 2017 Vilken metod kan användas för att bredda IT-system mot nya marknader? Framtagning av en utvecklingsprocess med tillämpning i en fallstudie PAVEL SAKALOUSKI FURKAN POYRAZ KTH SKOLAN FÖR TEKNIK OCH HÄLSA

2

3 Vilken metod kan användas för att bredda IT-system mot nya marknader? Framtagning av en utvecklingsprocess med tillämpning i en fallstudie What method can be used to broaden IT systems towards new markets? Development of a development process with application in a case study PAVEL SAKALOUSKI FURKAN POYRAZ Examensarbete inom Teknik och ekonomi inr. datorteknik, Grundnivå, 15 hp Handledare på KTH: Anders Sjögren Examinator: Ibrahim Orhan TRITA-STH 2017:122 KTH Skolan för Teknik och Hälsa Huddinge, Sverige

4

5 Sammanfattning Inom varje verksamhet förekommer det alltid någon form av projektplanering när man vill bedriva sin verksamhet på en ny marknad. Dessa typer av förberedelser görs på olika sätt och utmaningen för företagen blir att använda sig av rätt etableringsstrategi. För att lyckas med implementering av ett projekt, på respektive marknad som organisationer verkar på, är en utav framgångsfaktorerna att ha en tydlig och genomtänkt metod. Företaget Beta erbjuder molnbaserade tjänster inom tullhantering där man skapar lösningar som hjälper andra företag att hantera sina tullärenden. Aktören är etablerad på den svenska marknaden och vill prova att erbjuda sina IT-lösningar i Norge. Företaget har därför ett behov av att undersöka hur den norska marknaden ser ut, om det finns en möjlighet att bredda deras befintliga systemlösningar och i så fall hur de ska gå tillväga för att få ett fungerande system som kan kommunicera med norska tullverket. I rapporten föreslås en metod som kan användas som underlag vid utvidgning av en verksamhet till nya marknader. Utvecklingsprocessen som presenteras ska också kunna generaliseras, fungera som underlag och användas även av andra företag som ställs inför samma utmaning som Beta. Denna rapport innehåller även en analys av den norska marknaden. Det finns en jämförelse mellan delar av svenska och norska tullsystemet och en presentation av de ändringar som behöver göras utifrån skillnader som finns. Som resultat ger rapporten en tydlig bild av hur man möjligen kan gå tillväga för att ta sig an liknande problem. Författarna presenterar även ett resultat som beskriver en lösning till Betas problem. Nyckelord Edifact, XML, Electronic data interchange (EDI), Odette file transfer protocol (OFTP), CSA, Tullverket, kryptering

6

7 Abstract Within each activity, there is always some kind of project planning when you want to do business in a new market. These types of preparation are done in different ways and the challenge for companies is to make use of the right establishment strategy. To succeed in implementing a project, on the respective market that organizations are working on, one of the success factors is to have a clear and thoughtful approach. The company Beta offers cloud-based customs management services, which provide solutions that help other companies handle their customs issues. Beta is established in the Swedish market and wants to try to offer their IT solutions in Norway. The company therefore has a need to investigate how the Norwegian market looks, if there is an opportunity to broaden their existing system solutions and, if so, how they should go about getting a working system that can communicate with the Norwegian customs office. The report proposes a method that can be used as a basis for expanding a business to new markets. The development process presented should also be generalized, serve as a basis, and used by other companies facing the same challenge as Beta. This report also contains an analysis of the Norwegian market. There is a comparison between parts of the Swedish and Norwegian customs system and a presentation of the changes that need to be made based on differences. As a result, the report provides a clear picture of how one might possibly be able to address similar problems. The project members also present a result describing a solution to Beta's problems. Keywords Edifact, XML, Electronic data interchange (EDI), Odette file transfer protocol (OFTP), CSA, Tullverket, encryption,

8 Lexikon EDI - Electronic Data Interchange. Överföring av strukturerad data enligt fördefinierade standarder. EDIFACT - United Nations/Electronic Data Interchange For Administration. Standard för elektroniskt informationsutbyte. XML - Extensible Markup Language. Märkspråk som används för att strukturera data. OFTP - Odette file transfer protocol. Protokoll som används för kommunikation mellan två parter när det gäller EDI. TID Svenska tullverkets deklarationssystem som används för att lämna internetdeklaration. TVINN - Deklarationssystemet som används i Norge och är motsvarigheten till TID. Projekttriangeln - Project Management Triangle. Modell som skapar helhetsbild av projektmål.

9 Förord Vi vill rikta ett stort tack till handledaren Anders Sjögren vid Kungliga Tekniska Högskolan för hans handledning och goda vägledning under projektets gång. Tack även till företaget Beta med personal för ett väl genomfört samarbete, all hjälp som de har bidragit med och speciellt för att ha gett oss möjligheten att genomföra detta arbete. Vi vill särskilt tacka Peter Sillén, universitetsadjunkt och programansvarig, för hans engagemang och stöd under arbetets gång.

10

11 Innehållsförteckning 1. Inledning Bakgrund Problemformulering Syfte Målsättning Avgränsningar 2 2. Teori och bakgrund Tullverket i Sverige och Norge Evry Electronic data interchange EDI EDIFACT Extensible Markup Language - XML Jämförelse av XML och Edifact Odette File Transfer Protocol Processmodellering Kommunikation mellan Beta och Tullverket GUI och deklarationsprogram Vetenskaplig bakgrund Metod Kvalitativ metod Undersökningsmetod Metod för hållbar utveckling, lika behandling och jämställdhet Resultat Resultat av undersökningsmetod Generaliserat resultat Riskanalys Tidsuppskattning och kostnader för företaget Analys och diskussion Validitet och reliabilitet av resultatet Resultatets validitet 39

12 5.1.2 Resultatets reliabilitet Diskussion om vald metod Diskussion om resultat Förslag på framtida arbeten Slutsats 45 Källförteckning 47 Bilagor 49

13 1. Inledning 1.1 Bakgrund Företaget som fallstudien grundar sig på önskar sig vara anonyma, därför väljer vi att kalla dem för Beta under projektets gång. Beta är verksamma i Sverige och har som mål att utvidga sina IT-lösningar till en ny marknad, Norge, och har således behov av att undersöka om det finns en möjlighet att bredda deras befintliga systemlösningar. Projektet kommer därför att omfatta en förstudie av vad som krävs av företaget och vilka metoder som kan användas vid implementering av system på den nya marknaden. Företaget innehar hög kompetens inom systemutveckling med inriktning mot logistikbranschen och skapar IT-lösningar som effektiviserar och ökar lönsamheten i kundernas verksamhet. De erbjuder molnbaserade tjänster inom tullhantering där man skapar lösningar som hjälper andra företag att hantera sina tullärenden. Inom ramen för tullhantering finns det lösningar som stödjer det svenska tullverkets EDI-system och har fullt stöd för exempelvis hantering av import, export, transiteringar och tullager med gränssnitt som anpassas efter kundernas villkor. Det molnbaserade systemet har utvecklats av Beta och kan hantera överföring av meddelande på ett säkert sätt som uppfyller tullverkets krav för elektroniskt informationsutbyte. 1.2 Problemformulering Problemformuleringen är att kunna identifiera vad som krävs för att företaget skall godkännas som en ny aktör på den norska marknaden. Därför kommer det att tas hänsyn till följande frågor: Vilka ändringar behöver Beta göra i sitt nuvarande system för att uppfylla kriterierna som en ny aktör på den norska marknaden? Hur ska de gå tillväga för att få ett fungerande system som kan kommunicera med norska tullverket? Hur gör man för att utvidga ett IT-system och hur kan en sådan process generellt se ut? 1.3 Syfte Projektets syfte är att ta fram en lösning till Betas problem och presentera en utvecklingsprocess som de kan utgå ifrån för att kunna få ett system som fungerar mot 1

14 tullverket i Norge. Utvecklingsprocessen som utformas skall också kunna generaliseras, fungera som underlag, och användas av andra verksamheter som vill utvidga lösningar inom IT till nya marknader. Inom ramen för undersökningen är avsikten även att presentera en lösning som kan bidra till att läsarna ökar förståelsen för den här typen av problem - hur man gör för att bredda ett redan existerande IT-system till nya marknader. 1.4 Målsättning Detta kapitel beskriver de mål som projektmedlemmarna förväntas uppnå efter slutfört arbete. Arbetet riktar sig mot två olika målgrupper, dels uppdragsgivaren och akademiker, därav fördelningen av delmål nedan. Projektet måste uppnå både de krav som har satts tillsammans med företaget Beta och de akademiska målen. Målet är att, efter avslutat projekt, kunna presentera ett förslag på en utvecklingsprocess som kan användas som underlag vid utvidgning av en verksamhet till nya marknader. Denna process kan sedan specificeras och anpassas mer i detalj för vald verksamhet. Förhoppningen är framför allt att andra blivande ingenjörer kan dra nytta av arbetssättet och öka förståelsen för hur man tar sig an liknande problem alltså hur man går tillväga för att identifiera behov av ändringar i ett IT-system och hur dessa ändringar implementeras för att uppfylla kraven på den nya marknaden. Underlaget för utvecklingsprocessen som skapas görs genom att ta ställning till Betas möjligheter att anpassa verksamhetens IT-system på en ny marknad. Det är en undersökning av vilka förändringar som måste göras i systemet som används idag och hur dessa ändringar ska göras, för att deras IT-system skall kunna vara kompatibel för användning av tulltjänster i Norge. Projektmedlemmarna förväntas alltså presentera ett resultat som beskriver en lösning till Betas problem. 1.5 Avgränsningar Under projektets gång har det fokuserats på att hitta en metod genom att endast ta ställning till företaget Betas nuvarande situation och dess önskan att kunna utvidga sin verksamhet till en ny marknad. Undersökningen omfattar inte andra organisationers tillvägagångsätt som eventuellt genomförts inom samma marknad. För att genomföra förstudien som Beta efterfrågat har en begränsning av längden på projektet anpassats efter den tillgängliga tids och resursramen. Elektronisk informations utbyte kan göras på flera olika sätt. Anledningen till att avgränsning gjorts genom att lägga fokus på endast EDIFACT (se kap ) och XML (se kap ) är för att dessa språk har varit aktuella under denna undersökning. Avgränsningen omfattar även att Betas IT-system skall anpassas efter tullverkets 2

15 systemlösningar och inte tvärtom. Eftersom att projektet har en begränsning av tidsram som måste följas har det inte tagits hänsyn till att undersöka hur aktörer inom samma marknad tagit sig an utmaningen att bredda sin verksamhet till en ny marknad. 3

16 4

17 2. Teori och bakgrund 2.1 Tullverket i Sverige och Norge Sverige Verksamheter som exporterar och importerar varor till och från Sverige måste använda tullverkets system TID för att lämna internetdeklaration. Webbtjänsten är lämpad för den som hanterar ett mindre antal tulldeklarationer. Företag som vill utnyttja självbetjäningen ansluter sig kostnadsfritt till tjänsten och har skyldighet att lämna rätt information om importerade respektive exporterade varor. Dock kan det vara svårt att varje gång fylla i blanketter manuellt. Därför väljer flera verksamheter, som har regelbunden tullhantering, att ansluta sig till Betas tjänster och affärssystem som effektiviserar och underlättar kommunikationen med tullverket [1]. Norge TVINN är deklarationssystemet som används i Norge och är motsvarigheten till TID. Det elektroniska systemet som används för utbyte av tulldeklarationer fyller samma funktion i Norge som TID gör i Sverige. Den hjälper företag hantering kring tullärenden genom att bland annat snabba upp processen av tullexpedition av varor mellan avsändare och mottagare, förenkla kontrollen av varuflödet mellan Norge och andra handelsländer, minska pappersarbeten samt ger möjlighet till kostnadsbesparingar för både verksamheten och Tullverket [2]. Både det norska och svenska systemet har två typer av meddelanden vid kommunikation mellan deklarant och tullverket. Dessa meddelandetyper är standardiserade och används internationellt. CUSDEC är de meddelanden som skickas till tullverket från deklaranten och CUSRES är svarsmeddelanden som skickas från Tullverket till deklarant. NCTS används i Norge och står för Tolletatens elektroniske transitteringssystem eller Tullverkets datoriserade transiteringssystem. Systemet används för informationsutbyte mellan industriföretag och tullförvaltningen samt för föranmälan av varor till och från tredjeländer [3]. 5

18 Figur 1 presenterar en enkel beskrivning av hur kommunikationen mellan deklaranten och tullverket fungerar, med nätverksleverantör som mellanhand. Figur 1 kommunikation mellan deklarant och tullverket i Norge[4] 6

19 2.2 Evry Evry är ett av de största IT-företagen i Norden och erbjuder många olika-it tjänster som dagligen används i samhället. Företaget är nätverksleverantör för tjänster inom deklarering av varor i Norge. De hanterar kommunikationen, och fungerar som länken, mellan IT företag som vill erbjuda tjänster inom tullsystem och tullverkets eget system för importoch export av varor. Företaget Beta använder ingen nätverksleverantör utan kommunicerar direkt med tullverket i Sverige. I Norge är det ett krav att samarbeta med Evry som nätverksleverantör för att kommunicera med tullverket. Evrys uppgift är att hantera meddelande som skickas, kontrollera om eventuella fel finns och skicka meddelande vidare till Tullverket i fall inga fel är upptäckta [5,6]. 2.3 Electronic data interchange EDI EDI (Electronic Data Interchange) används för automatiserad informationsöverföring mellan olika affärssystem. Filöverföringen består av standardiserade elektroniska transaktioner, som också ibland kallas för dokument eller meddelanden. Kommunikationen för elektronisk filöverföring sker genom att ansluta en EDIprogramvara till företagets system. Systemet ser till att konvertera det interna systemets filformat till en EDI-standardformat. Samma system stödjer också funktionen att skicka och ta emot meddelanden i enlighet med kraven för respektive kommunikationsprotokoll som finns mellan de som använder tekniken. I det här fallet är det protokollet mellan Betas- och tullverkets system. En fördel som EDI-system har är att den har viktiga funktioner så som kvittenser. Kvittenser används för att undvika fel vid överföring och ha bättre koll på informationen som överförs. Sändaren kan få bekräftelse på att meddelanden som har skickats tas emot och att inga fel upptäcks på vägen. Överföringen bekräftas genom att övervaka transaktionen och logga alla händelser [7]. Det finns olika standarder av EDI och de vanligaste är Edifact och XML. Edifact är en internationell standard och används i både Sverige och Norge. Till skillnad från Edifact är XML modernare och i viss mån bättre. Dock används det inte i lika stor utsträckning eftersom att Edifact redan är väletablerad på marknaden för elektroniskt informationsutbyte och täcker affärstransaktioner i större omfattning. XML är fortfarande i en utvecklingsfas vad gäller användning inom EDI[8]. Meddelanden som skickas inom EDI är i formatet Edifact och protokollet som används för överföring är OFTP/OFTP2 [9]. Informationsutbytet via EDI är säkert och skyddat mot förändringar på vägen från sändaren till mottagaren. Det finns flera sätt att skydda den 7

20 informationen som överförs. Tullverket använder sig av ett PKI baserat säkerhetslösning där använder måste signera och identifiera sig innan överföringen påbörjas [10]. Figur 2 Manuell process av meddelande överföring [11] Figur 3 Överföring av information med EDI [12] 8

21 EDI ger möjlighet att effektivisera administrativt arbete och minimera felhantering då meddelanden skapas och överförs automatiskt mellan olika datasystem. Dessutom minskas pappersarbete vilket ökar hållbart utveckling. Andra fördelar med EDI är minskning av ledtider, bättre kontroll över information som sänds och minimerade leveransförseningar EDIFACT Edifact står för Electronic Data Interchange For Administration, Commerce and Transport. Det är en standard för EDI som skapats av Förenta Nationerna och år 1987 godkändes enligt ISO-standarden av Internationella standardiseringsorganisationen [7]. Edifact standarden ger en uppsättning av syntaxregler och standarder som möjliggör att två olika system kan sätta upp informationsutbyte mellan sig. Ett Edifact meddelande är uppsatt av logiskt grupperade segment som består av meddelanden, segment, dataelement och koder [14]. Språket kan användas bland annat för kommunikation med tullverket vid elektronisk deklarering. Nedan beskrivs en process av hur Edifact används för deklarering av importerade varor [7,13]: 1. Importören fyller i en blankett med information om varor som importerats och skickar in deklarationen. Det är viktigt att ange rätt typ av varukod för att betala rätt tullavgift. 2. Programmet kontrollerar om alla fält är ifyllda korrekt. Dokumentets (blanketten) innehåll formateras om enligt Edifact standarden. Blanketten kommer att vara anpassad för tullverkets kommunikationsprotokoll som kan översätta tillbaka informationen så att den blir läsbar. I samband med att meddelandet skickas iväg så loggas filens data i en mapp lokalt. 3. Enligt kommunikationen mellan det interna EDI systemet och tullverkets system överförs meddelandet till motparten. 4. Verktyget som tullverket använder konverterar tillbaks dokumentet så att det blir läsbart enligt Edifact standarden. 5. Kundens deklaration kan öppnas enligt formaterat dokument (oftast i pdf-format) och kan behandlas. Inom Edifact definieras en meddelandetyp som en strukturerad och identifierad mängd av segment och dataelement som ingår i ett av Edifact godkänt standardmeddelande. Varje meddelande inleds med en meddelandeheader (UNH) och avslutas med så kallad meddelandetrailer (UNT). Mellan dessa två finns datasegment som meddelandet 9

22 innehållet. Meddelandetyper anges med en kod som består av sex bokstäver, till exempel CUSDEC och CUSREC. Exempel på Edifact meddelande Oftast byggs dessa meddelanden på så sätt att varje segment får sin egen rad vid dokumentation för att underlätta läsning av meddelandet. Varje segment består av en identifierare om tre bokstäver, dataelement och koder som beskriver innehållet. Nedan visas ett exempel på hur Edifact meddelanden kan se ut [7]: UNB+UNOC:3+Köparen AB+Säljaren AB :1000+ABCD1234 Överföringsinledning: UNOC är syntaxklassen och 3 är syntaxversionen. Därefter avsändare/mottagare, datum/tid och överföringens referensnummer. UNH+REF002+ORDERS:D:93A:UN:EAN005 UNH meddelandeinledning: Meddelandets referensnummer, meddelandetyp, status, katalog,utfärdare och subset. BGM+224+PO BGM Meddelandets inledning. Beställningstyp kod 224 indikerar snabborder, ordernummer. DTM+137: :203 DTM Datum och tid: Kod 137 betyder dokumentdatum, följt av datum och kvalificerare för datumformat DTM+2: :102 DTM Datum och tid: Kod 2 betyder önskat leveranstillfälle, följt av datum och kvalificerare för datumformat. RFF+CT RFF Referens: CT är en kod för ramavtal, följt av avtalets nummer. NAD+SU+++FIRMAN NAD Namn och adress. SU står för leverantör. Här framgår endast namn på leverantören. NAD+BY ::9 NAD Namn och adress. BY står för köpare, som här är identifierad med EAN:s lokaliseringskod. Delelement 9 identifierar att det är ett EAN-nummer. 10

23 CTA+OC+PD:STINA CTA Kontakt: OC är koden för orderkontakt, PD står för purchasing department och Stina är kontaktpersonen. COM :TE COM Kommunikationsnummer: Telefonnumret är till Stina. Meddelandet fortsätter med uppgifter om bland annat moms, transportsätt, leveransvillkor och kvantitet av en vara. Datasegment Som tidigare nämnt, består ett segment av en mängd dataelement som identifieras genom sina positioner i en bestämd ordningsföljd. Dessa kan sedan delas in i segmentgrupper som utgör en hierarkisk uppbyggnad med repeterbar struktur av segmenttyper. Se figuren nedan[7]: Figur 4 Segmentgrupper Den första rutan anger segmentgruppen och hur många gånger den kan repeteras. I det exemplet är gruppen villkorlig (frivillig) och kan repeteras upp till 20 gånger (C20). Om man väljer att använda gruppen blir NAD namn och adress, det första segmentet, 11

24 obligatoriskt. Man kan se det som rotelementet i en segmentgrupp. Nästa segmentgrupp är också villkorlig och kan repeteras fem gånger (C5). Om även den gruppen används blir den obligatorisk. Det tredje segmentet däremot, COM Kommunikationsnummer är villkorlig men inte obligatoriskt. Exemplet beskriver att varje typ av namn och adress kan anges fem kontaktpersoner med telefonnummer. Inom Edifact är segmenten generiska, vilket innebär att de kan återanvändas för olika syften. Fördelen med detta är att användaren inte behöver skapa ett nytt segment varje gång utan kan använda samma segment för olika funktioner. Dataelement och koder Den mest kritiska delen i språket är dess dataelement som innehåller informationen som skall överföras till motparten. Andra funktioner som finns i standarden anses vara stödfunktioner. Innehållet av dessa dataelement är egentligen inte faktiska värden och betraktas istället som enskilda enheter av data. Varje enhet specificeras av sitt datavärde enligt en ISO-standard UNTDED (United Nations Trade Data Elements Directory). Representationen av dataelement kan vara i form av alfabetiska, numeriska eller alfanumeriska tecken. Koderna som används i Edifact (se exempel på Edifact-meddelande som visades ovan) är okomplicerade och kan därför läsas in på ett enkelt sätt via en programvara. Figur 5. Struktur i en Edifact-överföring[14] 12

25 Strukturen för en överföring av meddelanden är uppbyggd enligt figuren som visas ovan. Varje överföring består av en eller flera meddelanden. Ett meddelande innehåller segment, servicesegment och datasegment. Själva segmentet består av dataelement. Vid överföring är det viktigt att ordningen ska stämma överens enligt standardmodellen, alltså att första segmentet är UNA (kan väljas bort), andra UNB som är obligatoriskt och så vidare tills det sista segmentet UNZ som avslutar överföringen. Alla segment och dataelement som används inom Edifact är antingen obligatoriska eller villkorliga. Användaren får själv välja att använda de villkorliga segment/element som finns om hen känner behov av att använda de. Skillnaden mellan obligatoriska och villkorliga element specificeras för varje segment med antingen M1 Mandatory eller C9 Conditional [7] Extensible Markup Language - XML XML (Extensible Markup Language) används för att skapa och spara data på ett strukturerat sätt för att sedan kunna dela det med andra. XML är ett markeringsspråk och används ofta när det behövs ett välformaterat data. Det är inte ett programmeringsspråk utan snarare en uppsättning av regel för hur data ska konstrueras. Till skillnad från Edifact är XML ett modernare språk som är mer flexibel och lätthanterligt. Inom tullhantering används inte XML lika mycket som Edifact. Dock pågår det en övergång från Edifact till XML i Sverige [15]. Alla nya meddelandeflöden i kommunikationen mellan företag och tullverket kommer att baseras på XML. Detta eftersom att språket är mycket lättare att förstå och erbjuder möjligheten att strukturera data på ett mycket bättre sätt än Edifact. Kommunikationen med XML är mer anpassad för system som används över internet, vilket underlättar överföring av elektronisk information mellan deklaranten och tullverket [7,14] Jämförelse av XML och Edifact Det finns många saker som talar för att en övergång från Edifact till det mer moderna XML kommer att bli bättre. Några fördelar av XML är[16,18]: De större aktörerna på marknaden har accepterat internetstandarden och är villiga att gå över till XML, som dessutom är baserad på en ISO-standard. Återanvända innehållet i Edifact som fungerar bra och utveckla andra delar som är sämre. Detta kan sedan användas för utbyte mellan system. XML kan byggas in i applikationer och databaser. Den har samtidigt stöd för både presentation av information och överföring mellan olika system. 13

26 Användaren får större frihet till skillnad från Edifact och kan skicka över information från system till system genom att själv definiera innehållet. I och med det blir inte XML lika dokumentorienterat som Edifact, där det är ett måste att utgå ifrån flera standarddokument. Standarden har stöd för överföring av data i realtid (online), satsvis (batch) och från system till system. Till skillnad från Edifact ger XML användaren mer frihet att skapa egna märkord. Fördelen med det är att språket kan användas mer flexibelt utifrån eget behov. Nackdelen med denna flexibilitet är att det blir för komplext när kommunikationen sker med många andra aktörer, speciellt inom öppen handel. Även om innehållet följer alla regler och struktur som gäller kan användarna definiera märkord på olika sätt. Detta kan vara ett problem när olika företag försöker kommunicera och utbyta information med varandra. Den stora nackdelen med XML är just att det inte finns en standard för innehållet[18]. Även om många aktörer fortfarande använder Edifact finns det utveckling som syftar på att XML kommer att ersätta Edifact alltmer med tiden. Flera affärssystem har stöd för språket och det finns programvaror som kan hantera XML dokument på olika sätt. Många tror dock fortfarande att Edifact och XML kommer att användas parallellt under många år framöver. Edifact används av många företag och det skulle inte vara lika lätt för varje verksamhet att gå över till XML. Övergången kräver både tid och investering som mindre företag inte har[14]. 14

27 2.4 Odette File Transfer Protocol OFTP (Odette File Transfer Protocol) är ett av de mest använda protokollen för datakommunikation mellan handelspartners och används inom myndigheter som till exempel Tullverket. OFTP kom år 1986 och skapades av Odette (Europeiska fordonsindustrin gemensamma standardiseringsorgan). Protokollen tillhandahåller kommunikation på ett standardiserat sätt och gör det möjligt att automatisera processer. Inom elektroniskt datautbyte används detta protokoll för att hämta informationen från applikationen och lägga den i EDI-meddelande. OFTP2 är en förbättrad version av OFTP. Den aktuella versionen, OFTP2, började användas i stor utsträckning sedan Den största skillnaden ifrån den första versionen är att i OFTP2 måste ett säkerhetscertifikat användas för att auktorisera sig. Det är en tre-nivåers säkerhet och kommunikationen fungerar på följande sätt[17]: 1. En säker förbindelse mellan två aktörer skapas. Det sker med krypterad kommunikation. 2. För bättre säkerhet krypteras också data som skickas. För den används asymmetrisk kryptering. 15

28 3. Hash av data genereras för att undvika att data ändras på vägen och en privat nyckel används för att dekryptera den. Kommunikationen via OFTP2 används i tullhanteringsprogram och är säkert. OFTP CWC server OFTP CWC är systemleverantörens centrala kommunikationsmotor för kommunikation mot tullverket. Den OFTP v2-programvara som ingår i levererad systemlösning följer specifikationen för ODETTE File Transfer Protocol version 2, enligt RFC Varje tillståndshavare blir en subenhet i kommunikationen med sin OFTP EDI-kod, lösenord, vidareadress och ev. egna TCP/IP, DNS, mm mot Tullverket. I OFTP CWC samlas således alla filer ifrån olika tillståndshavare och skickas till tullverket. Kommunikation och filer separeras i underenheter i den centrala kommunikationen. Varje kund har alltså sin separerade trafik och varje tillståndshavares data sorteras separat ifrån varandra. Rent tekniskt måste uppgifterna ifrån varje tillståndshavare om OFTP EDI kod, vidareadress samt lösen för send och receive sparas för varje subenhet, tillståndshavare, i OFTP CWC. Trafiken sorteras beroende på OFTP EDI kod och vidareadress. Kommunikation styrs sedan vidare till respektive tillståndshavares Webb server. Samtliga filer i transmissionen lagras på en CWC server hos systemleverantören och filer lagras i skilda bibliotek med tillståndshavarens namn. Betas CWC server har hög säkerhet och är skyddad med brandvägg, mm för att förhindra åtkomst för alla utom systemleverantören och har som enda uppgift att ansvara för OFTP kommunikationen. Adress för Systemleverantörens CWC server är densamma som för företaget Betas webb server[17]. 16

29 2.5 Processmodellering Inom processmodellering används olika verktyg för att illustrera processer av affärer. Det kan till exempel vara processer som beskriver orderhantering, kontroll av varuflöde eller incheckning inför flygresan. Både UML och BPMN används för att skapa grafiska representationer av hur processer fungerar. Processmodellering ger en bättre förståelse om hur kommunikationen mellan olika enheterna i en process går till och vilka aktörer som finns med i processen. BPMN står för Business Process Modeling Notation. Oftast består ett diagram av olika typer av objekt som är kopplade med varandra på olika sätt och med olika regler. Lösningar med BPMN används för att representera tekniska systembeskrivningar och affärsprocesser men kan också användas för att beskriva processer inom andra ämnesområden [19]. Den mest populära standarden inom processmodellering är UML, Unified Modeling Language, och det är en allmän samling av syntax och regler som kan används i bred omfattning. Till skillnad från BPMN används UML för att beskriva och dokumentera mjukvarusystem. Verktyget används speciellt inom objektorienterad programmering av ingenjörer och systemutvecklare för att ge en visuell bild av systemet som skall utvecklas. UML har 14 olika diagram typer och det gör den till ett kraftfullt verktyg som kan användas flexibelt för att beskriva i stort sett vilken affärsprocess som helst. I detta arbete kommer UML-verktyget användas för att beskriva undersökningsmetod och utvecklingsprocesser [20]. 2.6 Kommunikation mellan Beta och Tullverket Informationen som skickas från Betas kunder sparas i databaser för att hanteringen av historik och loggning ska vara möjligt. Alla databaser ligger på samma server men är anslutna till olika webbtjänster. I databaserna sparas all information gällande organisation, landet där systemet används, godslokalkoder och andra informationen som är nödvändigt för att systemet ska fungera. Det är 4 stycken aktörer som har sina roller i hela kommunikationen mellan kunden och Tullverket. Systemlösningen som Beta erbjuder är nätverksbaserad och användaren av systemet har sina inloggningsuppgifter, en dator med webbläsare och en CSA Dosa som används för signering när ett meddelande skickas. På webbservern hanteras användarinloggningen med auktorisering. Även GUI, databaser och programvara finns på webbservern. OFTP servern är webbservern på leverantörens sida. Det är systemleverantörens kommunikationssystem som kopplar kunden och tullverket. På denna webbserver kontrolleras data som skickas. Skulle det vara så att ett felmeddelande upptäckts vid överföring av information så skickas meddelandet inte vidare till tullverket utan skickas tillbaka till avsändaren för korrigering. TMF är sista steget och det är data som 17

30 skickas från OFTP servern till Tullverket. Det kan till exempel vara deklarationer eller kvittenser. Först när data som skickats till Tullverket valideras skickas en bekräftelse tillbaka till kunden[21]. Kommunikation mellan användaren och Webb-servern samt Webb-server och OFTP server sker via HTTPS protokollet. OFTPv2 (se avsnitt 2.7) används för kommunikationen mellan OFTP-server och TMF. 2.7 GUI och deklarationsprogram Deklarationsprogram som företaget Beta har skapat är en molnbaserad tjänst och behöver inte installeras på varje dator som programmet ska användas på. Kunden får en länk och använder inloggningsuppgifter för att logga in på systemet. I deklarationsprogrammet kan samtliga (export, import, transit och anmälningar) EDI-meddelande hanteras. Programmet är dynamisk och beroende på vilken meddelandetyp kunden väljer anpassas gränssnittet efter vald typ. Programmet är kopplat till tullverkets tulltaxa och sökfunktionen finns tillgänglig för kunden. Om kunden önskar finns möjlighet att ha program på egen server istället för att ha den som en hostad lösning från Beta. När ett meddelande skickas iväg krävs det signering från avsändarens sida. I nuläget används Edifact som meddelandetyp men har API som är utvecklat för integration med andra typer, t.ex. XML. Användaren av programmet kan följa status för skickade meddelanden och se när meddelande är levererat samt godkänd av mottagaren [21]. Deklarationsprogram är lätt att använda och gränssnittet är enkelt. Det finns fält som kunden fyller i eller flervalsalternativ där kunden väljer önskat val. Vid varje fält finns en beskrivning som gör att kunden förstår vilken funktion ett visst element fyller. 2.8 Vetenskaplig bakgrund Inom forskning finns det flera metoder och tekniker som är lämpade för olika forskningsområden. Varje metod tillämpas på sitt eget sätt och har olika problemformuleringar och målsättningar. Under detta arbete kommer författarna att utgå ifrån en arbetsmetod som uppfyller de akademiska kraven för vetenskaplighet. Bunge definierar och beskriver hur en vetenskaplig arbetsmetod genomförs med tio generella steg [22]: Identifiera problemet: Problemidentifiering inom valt ämnesområde. Beskriv problemet: En tydlig beskrivning av problemet. Om det finns möjlighet bör definieringen av problemet göras i form av mätbara operationer. Informationssökning: Samla relevant information kring ämnesområdet. Ta fram metoder, teorier och instrument som kan vara till nytta. Förklara och lös problemet: Försök att lösa problemet med informationen som 18

31 hittades under steg 3. Om de metoder, teorier och instrument som hittats inte är tillräckliga för att lösa problemet, fortsätt till steg 5. Om problemet löses gå till steg 6 Föreslå nya idéer: Förslag till nya teorier, metoder, hypoteser och ta fram nya empiriska data som kan användas för att lösa problemet. Ta fram lösning: Presentera lösningsförslag. Det behöver inte vara det slutliga lösningsförslaget. Ett första utkast av lösningen fungerar också. Härled konsekvenser av lösning: Härled konsekvenserna av lösningen som togs fram under steg 6. Granska lösningen: Testa lösningen. Kontrollera om förväntat resultat uppnås. Om inte, analysera effekter och gå vidare till steg 9. Om den erhållna lösningen löser problemet, gå till steg 10. Förbättra lösningen: Korrigera de fel som uppstått under test av lösningsförslaget. Återgå till tidigare steg och använd, eventuellt, nya teorier och metoder, för att lösa problemet. Utvärdera lösningens resultat: Utvärdera resultat och effekt av lösningsförslaget som togs fram med hjälp av de teorier och metoder som använts. Försök identifiera nya problem. 19

32 20

33 3. Metod Det här kapitlet beskriver vilka metoder som har använts under projektet för att kunna besvara våra frågeställningar (se kap. 1.2). Författarna ger först en teoretisk bild av en kvalitativ metod och hur det har använts under arbetets gång. Sedan presenteras undersökningsmetod som har varit till grund för att besvara stora delar av frågeställningarna. Sist beskrivs hur man har tagit hänsyn till hållbar utveckling under projektarbetet. 3.1 Kvalitativ metod En kvalitativ undersökning syftar till att lägga större vikt på ord istället för kvantifiering under insamling och analys av data. En tydlig indikation på en kvalitativ forskning är när man söker efter en djupare förståelse av något specifikt och väljer att observera vad deltagarna i en viss miljö uppfattar som viktigt och betydelsefullt. Projektgruppen har därför använt sig av en kvalitativ metodteori för att få en djupare förståelse om ett specifikt problem, Betas problem, att bredda sitt IT-system till den norska marknaden [23]. Författaren Alan Bryman listar även viktiga steg för genomförande av en kvalitativ metod. Kvalitativ metod innehar sex olika steg; Generella frågeställningar, val av relevanta platser och undersökningspersoner, insamling av relevanta data, tolkning av data, begreppsligt och teoretiskt arbete och formulering av forskningsrapporten. Under detta projekt har man framför allt lagt stort fokus på insamling av relevant data och tolkning av data. Det var en hel del insamling av data för att framför allt förstå det svenska och norska tullsystemet. Detta var nödvändigt för att förstå Betas problem och den teknik som deras IT-system är byggd på. Eftersom att ämnesområdet var helt nytt för projektgruppen var det också viktigt att tolka insamlad data rätt [23]. 3.2 Undersökningsmetod Projektmedlemmarna har tagit fram en undersökningsmetod som visar hur man har arbetat under projektet. Metoden har använts för att svara på frågan om vilken utvecklingsprocess som kan användas för att bredda IT-system på den nya marknaden. Önskvärt resultat av detta kapitel är att få fram en process att jobba efter vid utvidgning av ett system. Metodiken har utformats på så sätt att den under projektets gång alltid har erbjudit författarna flexibilitet kring modifiering av undersökningsmetoden på ett induktivt sätt. Ett strukturerat och tydligt genomförande av studien har gjort det möjligt att hela tiden analysera varje steg och vid behov justera faser som har fungerat mindre bra och ersätta de med ny information för ökad produktivitet. Undersökningsmetoden som har använts 21

34 visualiseras nedan med en figur och en beskrivning av metodens olika steg. Utformningen av samtliga steg som definierats har skapats utifrån de villkor på vetenskaplig arbetsmetod som beskrivits i kapitel 2.8. Figur 6 - Undersökningsmetod Förstå undersökningsproblemet - Första steget, av totalt tio steg, som Bunge presenterar är identifiering av problem. Inom detta projekt har utgångsläget varit att förstå problemet som författarna förväntades lösa. Vid skapandet av en utvecklingsprocess var målet att få en översiktlig bild av uppgiften och diskutera parternas, författarnas och Betas, förväntningar efter slutfört projekt. Gör ett processförslag - En presentation av en möjlig utvecklingsprocess presenteras efter förstudiefasen. Först när projektmedlemmarna hade en god beskrivning och definition av problemet kunde man börja utforma hur en undersökning inom ämnesområdet skulle genomföras. I samband med processförslaget var det viktigt att förtydliga de kriterier som Betas system skulle uppfylla. Projektgruppen utgick därför utifrån dessa kriterier för att ta fram en bra arbetsmetod. Exempel på dessa krav kunde vara att hitta rätt metod för att analysera 22

35 befintligt system, säkerställa vilka kriterier det nya systemet måste uppfylla eller att identifiera företagets nuvarande position gentemot en eventuell förändring av nuvarande system. Testa en process För att en lämplig utvecklingsprocess skall fungera vid implementering är det viktigt att ett mönster växer fram efter konkretisering av modell. Från att förstå de grundläggande kraven, sammanhang inom systemet och generella specifikationer övergår man successivt till att studera problemet mer ingående. Därför bör den skapade processen testas för att se om använd metodik leder arbetet i rätt riktning. Eftersom att utförandet av projektet är tidsbegränsat testas varje ansats en kort tid under varje iteration. Anledningen till att gruppen valde att ha en testperiod (steg 3) direkt efter processförslaget var för att avgöra om första förslaget fungerade eller inte. Utvärdera processen För att säkerställa att den skapade metoden är rätt görs en utvärdering och jämförelse av metoder. Det framgår en tydlig koppling under undersökningsmetoden mellan kravhantering och utvärdering. Tanken med denna koppling är att kunna avgöra om processförslaget uppfyller villkoren som finns i kravhanteringen. Till exempel, är svaret till frågan leder processen mot målet? avgörande om förslaget kan användas eller inte. Om den testade undersökningen visar en tydlig indikation på att metoden kan generera goda resultat dokumenteras vald ansats. Förbättringsförslag Vid framtagning av rätt implementeringsmetod bör det alltid finnas utrymme för förbättringsmöjligheter. Exempel på detta kan vara utökning av kriterier som systemet måste uppfylla på den nya marknaden. Efter utvärderingen som gjorts under fasen innan finns det en dokumentation på all kravhantering. Resultatet av den testade processen dokumenteras och används som underlag för utvecklingsmöjligheter. Modifiera processen Baserat på händelser och resultat från tidigare steg härleds konsekvenser av vald ansats. Förslaget på metoden kontrolleras om ny information behöver läggas till. Korrigering av lösningen sker genom att man under nästa iteration väljer att verkställa de lösningar som föreslås för problem som har hittats. Testa processen Referera till Bunge här. En av de viktigaste stegen i undersökningsmetoden är testa processen. Utan att testa arbetsmetoden skulle risken för ett dåligt resultat varit större. Därför har iteration ett steg där processen testas. Detta för att bedöma om 23

36 förbättringsförslag och modifiering av processen som gjorts tidigare verkligen leder till en stabil process. Är processen stabil? Under sista steget i metoden kollas det om de ändringar som gjorts är tillräckliga. Om svaret är nej, testas en ny process med nya förändringar. Om svaret är ja, avslutas processen. Först när det inte finns något mer att justera kan den slutliga lösningen erhållas. Kravhantering för ny iteration Om processen inte är stabil så körs en ny iteration där nya krav fastställs. De nya kraven fungerar som underlag till att under nästa iteration verkställa alla förändringar som krävs. 3.3 Metod för hållbar utveckling, lika behandling och jämställdhet Arbetet har genomförts med respekt för parternas intresse och mål inom projektet. Projektgruppens fokus har varit att kunna skriva en rapport som uppfyller examensmålen genom att hjälpa ett företag med deras fallstudie om möjligheten att gå in på en ny marknad. I de metoder som varit aktuella inom projektet finns både etiska och moraliska aspekter. Författarna har inte kritiserat eller undervärderat teknikerna som använts av myndigheter och företaget det skrivits om i detta arbete. Uppdragsgivaren hålls anonym och ingen information som kan vara känslig för företagets verksamhet har publicerats. All hemlig information som uppdragsgivaren har förmedlat till projektmedlemmarna har alltid hållits på säker plats och inga molntjänster har använts för att spara känsligt data. Genomfört arbete bedöms inte skada eller ha en negativ påverkan på hållbar utveckling. Eftersom att undersökningen har syfte att förbättra och underlätta informationsbyte mellan industri och tullverket kommer det förhoppningsvis leda till att pappersarbete minskas och i och med det sparas miljön. Projektet strävar efter att ta fram en hållbar metod som kan användas i liknande projekt och i framtida undersökningar. 24

37 4. Resultat I detta kapitel presenteras resultatet av projektet som genomförts. Nedan redovisas en framtagen utvecklingsprocess som projektgruppen har använt sig av för att hjälpa Beta vid breddning av deras IT-system till den norska marknaden. Processen kommer att illustreras med figur 9, 10 och 11. Figur 9 är en tolkning av hur hela metoden är uppbyggd. De två tillhörande figurerna, figur 10 (avser rutan som är markerad med siffran 1 på figur 9) och 11 (avser rutan som är markerad med siffran 2 på figur 9), ger en mer detaljerad bild av hur nulägesanalys och jämförelser av systemen på nuvarande och den nya marknaden genomfördes. Kapitlet beskriver också en generell processmetod som andra verksamheter kan ha nytta av. Resultatet kommer även att omfatta en redogörelse av hur överföring av elektroniskt informationsutbyte vid export- och importhantering går till (se bilagor). 4.1 Resultat av undersökningsmetod Figur 9 Utvecklingsprocess för Beta Figuren ovan är den slutliga processmetoden som har tagits fram. Denna utvecklingsprocess visar hur författarna har arbetat för att lösa Betas problem, att utvidga deras IT-system till den norska marknaden. Första steget i utvecklingsprocessen var att formulera effekt och resultatmål för Beta. Formuleringen gjordes genom att utgå ifrån uppdragsgivarens krav och önskemål. Projektgruppens och Betas förväntningar kring arbetet fastställdes i det här steget och effektmålet började grundas. När resultatmålet blev definierad blev det lättare att arbeta mot ett gemensamt mål. Specifikt för detta projekt var att utgå ifrån att ta fram affärsprocesser för tullverket i både Sverige och Norge. Genom att analysera dessa två affärsprocesser skapades det underlag för jämförelse av de olika systemen. Målet med jämförelsen var att identifiera skillnader i myndigheternas systemkrav för kommunikation. Dessa skillnader användes sedan för att 25

38 analysera vilka förändringar Betas nuvarande IT-system behövde genomgå för att fungera på den norska marknaden. Slutligen gjordes en utvärdering av alla förändringar i systemet. Systemets stabilitet testades mot den nya marknaden. Om det uppstod brister inom ITsystemet fanns det möjlighet att under nästa iteration återgå till att identifiera systempåverkan och hitta brister. Först när alla brister elimineras och systemet är stabilt kan Beta erbjuda sina tjänster inom tullhantering i Norge. Figuren nedan ger en mer detaljerad beskrivning av resultatet där fokus ligger på två kritiska delar av utvecklingsprocessen dels hur definieringen av affärsprocessen togs fram och dels hur jämförelsen av dessa system gjordes och dokumenterades. Figur 10 Nulägesanalys av systemet För att förstå vilken teknik Betas nuvarande IT-system har och behöver i framtiden så gjordes det en nulägesanalys. Analysen bestod av en statisk och dynamisk beskrivning av systemet. Det kunde till exempel vara att beskriva hur in och ut data fungerade, hur kunder identifierade sig mot systemet och signerade ärenden, hur blanketter som kunder fyllde i hanterades och även hur de filerna krypterades för att ingen information skulle förloras. Analysen användes för att förstå hur systemet skulle kunna se ut i börläge på den nya marknaden. Nulägesanalysen omfattade även en undersökning av systemlösningarna för både Sverige och Norge. Genom att definiera affärsprocesserna inom ämnesområdet för svenska och norska tullverket skapades en grund för utvärdering av deras teknik. Det intressanta var framför allt att kunna förstå hur myndigheternas teknik skiljde sig åt gällande hantering av data och säkerheten kring det. Den här typen av analys bedömdes vara nödvändig för att senare kunna utvärdera vilka systemkrav det fanns på respektive tullsystem. En dokumentation av systembeskrivningen togs fram för att det skall vara möjligt att titta tillbaks om något är oklart. Syftet med dokumentationen är att den skall användas som en manual med beskrivning av hur de två olika systemen fungerar. Tanken med att ta fram affärsprocesserna för de två myndigheterna parallellt var för att lättare kunna se samband 26

39 mellan de olika tekniska delarna i respektive tullsystem. Genom att ha en dokumentera beskrivning underlättar det även, vid nästa fas, jämförelsen av dessa systems olika teknikbehov. Figur 11 Jämförelse av processer I resultatet som är framtagen sätts det stor vikt på att ta fram skillnader och jämföra de olika processerna. Den här delen av utvecklingsprocessen utformades genom att diskutera med Betas systemutvecklare och har anpassats efter deras nuvarande arbetssätt. Idag finns det redan ett fungerande IT-system och målet är att komplettera detta system med de förändringar som krävs för en anpassning på den nya marknaden. Därför är det viktigt att modellen som har skapats identifierar behov av teknik. Denna punkt bör beskriva till exempel om språket Edifact eller XML skall användas vid överföring av meddelande och vilka säkerhetskrav det finns vid användning av det. Nästa steg, att undersöka vilken teknik som finns idag, kan tyda behovet av teknik ytterligare. Ett exempel var att undersöka om norska tullverket använder Edifact eller XML för elektroniskt informationsutbyte. Eftersom att tullverket i Sverige har påbörjat en övergång av teknik från Edifact till XML var den frågan väldigt centralt. Kommunikationen med tullsystemet i Norge bygger idag på Edifact och myndigheten har inga planer på att övergå till XML inom snar framtid. Syftet med att ha ett steg i metoden där det undersöks vilken teknik som används idag och om den tekniken kan komma att ändras i framtiden är för att eliminera risken att utveckla systemet fel. Om Beta hade valt att utveckla ett system som stödjer XML, som i Sverige, och som inte är kompatibel för kommunikation med norska tullverket skulle det leda till onödiga kostnader. Därav, för att inte lägga fokus på fel saker, är det viktigt att ha med det här steget i utvecklingsprocessen. Då får man en tydligare bild av de förändringar som måste göras för att anpassa systemet. Utifrån dessa behov ges sedan förslag på utvecklingsmöjligheter i systemet. 27

40 Utvecklingsmöjligheter ska ge förslag på till exempel hur mycket som skall göras om i Betas system och i viss grad den förändringen bör vara. Inom varje iteration görs en utvärdering i steget förslag på utvecklingsmöjligheter där behov av teknik för en del av systemet fastställs. Frågan om teknik behov uppdateras sedan efter varje iteration. Några av de övergripande funderingarna kan vara enligt nedan: Ska hela systemet byggas om? Räcker det med enstaka ändringar i gränssnittet eller behovs det stora förändringar? Hur ska man hämta in blanketter för deklarering per automatik när kunden knappar in varukod? Vilken funktion kommer den externa nätverksleverantören EVRY fylla och hur kommer det påverka oss? Vid möjligheter för utveckling är det bestämt att utgå ifrån kravspecifikation och att först bestämma grundfunktionerna i programmet innan mindre tekniska delar identifieras. På så sätt skapas ett fungerande system med basfunktionalitet för att därefter successivt utöka systemets mindre funktioner. Genom att bygga huvudfunktioner först ges det möjlighet att testa systemet på ett mer effektivt sätt. Systemets grundfunktioner kan valideras först och sedan testas om de ger förväntade resultat. Efter avslutade iterationer dokumenteras och uppdateras både system och rapport. 4.2 Generaliserat resultat Figur 12 Generalisering av utvecklingsprocess Resultatet av den generaliserade metoden är en utökad variant av utvecklingsprocessen som projektgruppen har arbetat med under arbetets gång. Utökningen består av två steg. Det ena är förslag på metod och resultat och det andra är definiering av affärsprocess. Vid framtagning av affärsprocesserna för nuvarande och den nya marknaden hänvisas det till 28

41 figur 10 som ger en beskrivning av metoden om hur nulägesanalysen görs. På samma sätt, för skillnader i affärsprocesserna, refereras det till figur 11 där metoden för jämförelse av process illustrerats. Författarna bedömer att samma utvecklingsprocess möjligtvis skulle kunna fungera för en annan verksamhet. Under detta projekt har metoden utformats specifikt genom att ta ställning till Betas problem, att utvidga deras IT-system till den norska marknaden. För andra verksamheter kan det vara så att man väljer att ha flera processer igång, där olika metoder föreslås, och definiering av affärsprocess väljs efter det. Det kan vara så att verksamheten väljer att gå in på flera marknader samtidigt. Då måste de skapa flera processer som är anpassade unikt för respektive ny marknad. 4.3 Riskanalys Projektgruppen har tagit fram en riskanalys som har presenterats för verksamheten. Syftet har varit att kunna identifiera alla kritiska risker i ett tidigt skede av projektet och ha möjlighet att hantera dessa om de uppstår. De risker som finns i dagsläget kan uppdateras och utökas av Beta. Den mest kritiska risken som kan ha en stor negativ effekt på utvecklingen av det nya systemet är att systemutvecklaren blir sjuk en längre period. Eftersom att utvecklingen i stort sett kommer att styras av företags nuvarande systemutvecklare kommer samma person att vara kärnan i hela projektet. Rekommendationen är att involvera någon annan från verksamheten i utvecklingen. Det är även viktigt att dokumentera all utveckling som görs. Detta skulle vara bra ifall projektet av olika anledningar överlämnas till någon annan. Nedan presenteras först en lista med samtliga risker och sedan en lista med riskåtgärder för dessa risker: SAN: Sannolikhet att händelsen inträffar. Skala 1 5. KON: Konsekvens om händelsen inträffar. Skala 1 5. R/V: Riskvärde (sannolikhet x konsekvens) # Identifierad risk SAN KON R/V R1 Brist på personal R2 Kritisk personal (systemutvecklare) blir sjukskriven R3 Kommunikationsproblem med Tullverket i Norge R4 Ändring av tekniska förutsättningar övergång från Edifact till XML R5 Brister i styrning och uppföljning av leverans från tredje parten EVRY R6 Brister i tidsplanering

42 R7 Prestanda problem med systemet som utvecklas R8 Negativ påverkan på verksamheten i Sverige om för mycket fokus läggs på utveckling i Norge R9 Brist på ekonomiska resurser för utveckling av det nya systemet R10 Efterfrågan på Betas tjänster minskar på kort sikt R11 Negativ påverkan av en konkurrenskraftig marknad på den nya marknaden R12 Ej tillräckliga funktionstester av systemets olika delar Riskåtgärdsplan Risk - # Risk # Åtgärd R1 Brist på personal RÅ1 I och med projektet kan det förekomma perioder då den nuvarande utvecklaren kan behöva stöd. Rekommendationen är att involvera medarbetare i projektet så mycket som möjligt och eventuellt anställa en konsult på deltid för att avlasta arbetsbelastningen. R2 Kritisk personal (systemutvecklaren) blir sjukskriven. RÅ2 Det är viktigt att erbjuda en bra arbetsmiljö. Som ovan, kan det vara bra att hyra in en konsult på deltid för att få hjälp med projektet. Detta kan minska företagets kostnader som kan uppstå i samband med att någon sjukskriver sig. Ha en extra anställd som kan ersätta i nödsituation R3 Kommunikationsproblem med Tullverket i Norge. RÅ3 Planera möten tidigt och håll kontakt med jämna mellanrum. I det här skedet av projektet är risken liten att det skulle uppstå kommunikationsbrist med Tullverket i Norge eftersom att Beta har fått en kontaktperson som kommer att vara tillgänglig under projektets gång. R4 Ändring av tekniska förutsättningar Övergång från Edifact till XML. RÅ4 Identifiera framtida förändringar så tidigt som möjligt. I samband med uppstart av projektet har vi fått bekräftelse från Norge att de inte har planer på att göra en övergång till XML de kommande åren. Om det skulle ändras, meddelas man i god tid. 30

43 R5 Brister i styrning och uppföljning av leverans från tredje parten EVRY RÅ5 Avtalsgranskning och löpande kontakt med leverantören. EVRY kommer att ta betalt för deras tjänster. I samband med att ett samarbete påbörjas med de så kommer det alltid att vara någon personal tillgänglig. R6 Brister i tidsplanering RÅ6 Skapa tid för oväntade händelser under projektets gång. Varje projekt kan ha oförutsägbara händelser som kan påverka projektet negativt. Det är därför viktigt att skapa tid i planeringen för dessa händelser som kan förekomma. På så sätt kan man hantera eventuella problem inom ramen för tidsplanen och minimera risken för förseningar. R7 Prestanda problem med systemet som utvecklas. RÅ7 Systemet bör testas under en längre period innan kunden kan använda det. Rekommendationen är att göra automatiserade tester och öka belastningen på systemet för att se hur systemet reagerar och vilka konsekvenser det ger. Utifrån de problem som uppstår så kan man korrigera fel och säkerställa att systemet fungerar väl. R8 Negativ påverkan på systemet i Sverige om för mycket fokus läggs på utveckling i Norge. RÅ8 Avsätt tillräckligt mycket tid för underhåll av systemet i Sverige. Planera detta underhåll så att man är tillgänglig för kunder precis som det tidigare har varit. R9 Brist på ekonomiska resurser för utveckling av det nya systemet RÅ9 Risken är låg för att företaget har en god ekonomi och tillräckligt med kapital för investering. Det är dock viktigt att kunna ta med alla kostnader som projektet medför och har en säkerhetsmarginal med i den beräkningen. R10 R11 Efterfrågan på Betas tjänster minskar på kort sikt. Negativ påverkan av en konkurrenskraftig marknad på den nya marknaden. RÅ10 En djupare marknadsanalys behöver göras för att identifiera potentiella kunder. Anledningen till att risken är låg är att de nuvarande kunderna redan idag efterfrågar Betas tjänster på den nya marknaden. Därför är det inte troligt att efterfrågan kommer att minska på kort sikt. RÅ11 Sätta rätt prissättning, hitta rätt kunder och erbjuda de rätt saker. Till skillnad från många konkurrenter har Beta sina tjänster på molnet vilket gör det effektivt för kunderna att använda dessa. Det är en konkurrensfördel till skillnad från många konkurrenter. 31

44 R12 Ej tillräckliga funktionstester av systemets olika delar RÅ12 Alla funktioner som systemet ska ha bör testas under en längre period innan Beta ska gå i produktion. 4.4 Tidsuppskattning och kostnader för företaget De huvudsakliga kostnaderna för Beta kommer att vara antal timmar som läggs på utveckling och testning, samt startkostnader för NODI-nummer och anslutningskostnader till EVRY:s tjänster. Projektgruppen har presenterat ett förslag på hur etableringen kan se ut och gjort en tidsuppskattning på utveckling av de olika delarna på systemet. Förslaget har godkänts av företaget och kommer att användas under projektets gång, med möjlighet till justeringar som kan bidra till bättre tidsplanering. Satsningen i Norge skulle kunna delas upp i tre olika faser: Fas 1 Utveckling av import och export med en omvandling mellan svensk export och norsk import samt vise versa. Fas 1 är den mest kritiska delen av utvecklingen inom projektet. Det är viktigt att sätta ihop en bra grund till vidareutveckling samt förstå hur alla integrationer skall verka mellan olika system. En större del av tiden kommer att gå till att utveckla just omvandling av import och export både till och från Sverige och Norge. Tillsammans med utvecklaren uppskattas arbetstiden för fas 1 uppgå till ca 650 h. Fas 2 Utveckling av stöd och funktionalitet för meddelanden inom transiteringssystemet. Detta förväntas ta ca 350 timmar arbetstid. Fas 3 Arbete mot TESS, norska tulltaxan för automatiska valutor, avgifter och så vidare. Uppskattad arbetstid (med marginal) bedöms vara ca 300 timmar Den preliminära utvecklingstiden är beräknad att uppgå till totalt 1300 timmar. Siffran kan komma att ändras när Beta arbetar med projektet och risken finns att de kan behöva tillsätta mer tid för utveckling av systemet. För att etablera sig på den nya marknaden krävs även en del marknadsinsatser. Beta kan behöva en norsk hemsida-domän som med jämna mellanrum behöver underhållas. I uppstartsfasen kan det även tillkomma resekostnader till och från möten med potentiella kunder. En exakt tid för bra kapitalavkastning är svårt att förutse i detta skede men med hänsyn till Betas starka position på marknaden finns det goda möjligheter till att ta stora marknadsandelar i Norge. Enligt en undersökning som gjorts med nuvarande kunder så finns ett stort intresse till att använda Betas tjänster även på den norska marknaden. En fördel som företaget har gentemot sina konkurrenter är att tjänsterna som erbjuds är molnbaserad och lätt tillgängligt för alla kunder. Denna typ av lösningar eftertraktas på 32

45 marknaden och prioriteras högre än äldre system som behöver laddas ner till datorn. Eftersom att tjänsterna är molnbaserade och moderna är det mycket troligt att Beta kommer att locka flera nya kunder. Trots att Beta har väldigt goda förutsättningar för att lyckas på den nya marknaden finns även en risk att de misslyckas. Skulle detta problem uppstå så kommer företaget ta beslutet att inte fortsätta underhålla systemet för den norska marknaden. Nedan presenteras ett kostnadsplan för Beta. Projektmedlemmarna bedömer att dessa saker är de kostnader som finns i nuläget av projektet. Det kan naturligtvis kosta mer eller mindre men det är alltid bra att ha något som utgångspunkt. År 1 ÅR Utbetalningar Summa Inbetalningar Summa Lönekostnad ,00 kr Lokalhyra inkl. el, värme och vatten ,00 kr Underhåll av webbplats ,00 kr Marknadsföring - annonser på internet + utställning på årlig mässa ,00 kr Driftkostnader ( kostnad för support och drift hos ,00 kr Evry, avgifter till norska tullverket, transaktionskostnader) Kostnader för bokföring och ledning 5 000,00 kr Diverse kostnader - affärsresor till och från kund (resekostnad inkl. boende och mat.) ,00 kr Totalt år ,00 kr 0,00 kr År 2 Lokalhyra inkl. el, värme och vatten ,00 kr Inbetalningar från kunderna ,00 kr Underhåll av webbplats ,00 kr ( 15 kr/meddelande ) Marknadsföring - annonser på internet + utställning ,00 kr på årlig mässa. Fasta driftkostnader ( kostnad för support och drift hos ,00 kr Evry, avgifter till norska tullverket) Rörliga driftkostnader (transaktionskostnader 1 kr/meddelande) Kostnader för bokföring och ledning Diverse kostnader - affärsresor till och från kund (resekostnad inkl. boende och mat.) ,00 kr 5 000,00 kr ,00 kr Totalt år ,00 kr ,00 kr År 3 Lokalhyra inkl. el, värme och vatten ,00 kr Inbetalningar från kunderna ,00 kr Underhåll av webbplats ,00 kr ( 15 kr/meddelande ) Marknadsföring - annonser på internet + utställning ,00 kr på årlig mässa. Fasta driftkostnader ( kostnad för support och drift hos ,00 kr Evry, avgifter till norska tullverket) Rörliga driftkostnader (transaktionskostnader 1 kr/meddelande) Kostnader för bokföring och ledning Diverse kostnader - affärsresor till och från kund (resekostnad inkl. boende och mat.) ,00 kr 5 000,00 kr ,00 kr Totalt år ,00 kr ,00 kr 33

46 År 4 Lokalhyra inkl. el, värme och vatten ,00 kr Inbetalningar från kunderna ,00 kr Underhåll av webbplats ,00 kr ( 12,86 kr/meddelande ) Marknadsföring - annonser på internet + utställning ,00 kr på årlig mässa. Fasta driftkostnader ( kostnad för support och drift hos ,00 kr Evry, avgifter till norska tullverket) Rörliga driftkostnader (transaktionskostnader 1 kr/meddelande) Kostnader för bokföring och ledning Diverse kostnader - affärsresor till och från kund (resekostnad inkl. boende och mat.) ,00 kr 5 000,00 kr ,00 kr Totalt år ,00 kr ,00 kr År 5 Lokalhyra inkl. el, värme och vatten ,00 kr Inbetalningar från kunderna ,00 kr Underhåll av webbplats ,00 kr ( 14,17 kr/meddelande ) Marknadsföring - annonser på internet + utställning ,00 kr på årlig mässa. Fasta driftkostnader ( kostnad för support och drift hos ,00 kr Evry, avgifter till norska tullverket) Rörliga driftkostnader (transaktionskostnader 1 kr/meddelande) Kostnader för bokföring och ledning Diverse kostnader - affärsresor till och från kund (resekostnad inkl. boende och mat.) ,00 kr 5 000,00 kr ,00 kr Totalt år ,00 kr ,00 kr Det första året av satsningen som Beta kommer att göra är mest kritiskt. Enligt tabellen som presenterades ovan framgår det tydligt att företaget kommer att ha stora kostnader, som består mest av löner, och inga inbetalningar alls. Detta är en naturlig följd av att systemet måste utvecklas under det första året och kommer att omfatta utvecklingsfas 1 till 3 enligt planering. Därav utesluts någon inkomst eftersom att tjänster inte kommer att erbjudas till kunderna först under andra året. Lokalkostnaderna som redovisas är en uppskattning på hur mycket mer projektet kan kosta företaget i form av yta. Om det finns en möjlighet att hyra mer yta av fastighetsägaren tror projektgruppen att denna plats kan bidra till utvecklingen av projektet. Samtidigt ger det företaget mer flexibilitet att hantera arbetsyta för eventuellt nya medarbetare. Lokalkostnaderna kommer att vara en fast kostnad de kommande fem åren som avser investeringsperioden för projektet. Beta har idag en webbplats för sina kunder. I och med att man tar sig an en ny marknad behöver webbplatsen ny funktionalitet och eventuellt en norsk hemsida-domän. Exempel på satsningar kan vara att anpassa webbplatsen med norskt språkval och kontinuerligt uppdatera innehållet med nyheter och de tjänster som erbjuds på respektive marknad. Projektmedlemmarna bedömer att underhållsarbetet för webbplatsen kommer att behövas 34

47 med jämna mellanrum och det är motiveringen till varför man valt att ha en sådan fast kostnad under investeringsperioden. Till skillnad från många andra branscher behöver man inte marknadsföra lika mycket här. Beta förlitar sig på sin starka position på marknaden och känner att de kan nå ut till kunderna genom att prata med sina nuvarande kunder som efterfrågar deras tjänster. Projektgruppen rekommenderar ändå att delta på årlig mässa och lägga ut reklam på internet under etableringsperioden på fem år. Driftkostnaderna bedöms vara lågt under första året. Detta på grund av att man inte kommer att använda Evrys och norska Tullverkets tjänster innan utvecklingen av systemet börjar bli klart. Dessa kommer att användas mer under andra halvåret då Beta behöver utföra tester under testperioden. Enligt kostnadsplanen för år två till fem redovisas driftkostnaderna med högre summor till skillnad från år ett. Skillnaden är att Beta kommer att börja betala för varje meddelande som skickas med Evrys tjänst kr bedöms vara fasta kostnader per år (år 2-5) för support och drift hos Evry och norska tullverket. Resterande belopp beräknas utifrån transaktionskostnader, där varje meddelande som skickas beräknas kosta ungefär 1 kr (se bilaga, s. X för meddelandepriser). Som en följd av nya inkomster och utgifter finns det även en möjlighet att det eventuellt kan uppstå extra kostnader för bokföring och ledning. Summan kan anses vara väldigt lågt men uppskattas inte medföra högre kostnader eftersom att det redan finns personal som hanterar bokföring och redovisning. Denna kostnad har lagts till för att täcka upp de extra timmar som ekonomiavdelningen eventuellt kan komma att arbeta på grund av detta projekt. Diverse kostnader som uppgår till kr är kostnader som framför allt kan uppstå om Beta reser till och från kunder som är verksamma i Norge. Dessa kostnader bedöms vara naturliga och beräknas förekomma i samband med årliga resor till blivande och potentiella kunder. Efter utvecklingsperioden som kommer att pågå under första året räknar Beta med att sälja sina tjänster under andra året. Målet är att successivt nå ut till fler kunder under etableringsperioden som sträcker sig över 5 år. Inbetalningarna som kommer från kunderna är betalningar för Betas tjänster. Inom ramen för dessa betalningen ingår support och drift samt meddelande kostnader. Under år två och tre förväntas Beta sälja en meddelandeöverföring för ca 15 kr (inkl. kostnad för support och drift/meddelande). Projektgruppen räknar med att kostnaden från meddelandeöverföring kan komma att minskas under fjärde året. Anledningen till detta kan vara pressade priser från andra 35

48 aktörer på marknaden. Därför kan det vara bra att visa lojalitet mot sina kunder och sänka priset för tjänsten något, till ungefär 12,86 kr. Samtidigt kan detta ses som ett strategiskt beslut för att behålla sina kunder. Under sista året av etableringsperioden när företaget är mogen på den nya marknaden och är en stabil leverantör kan man återigen debitera något högre pris, ungefär 14,17 kr per meddelande. Trots att Beta enligt kostnadsplanen kommer att få mindre inbetalning år fem jämfört med år fyra så kommer de att få en högre marginal på försäljningen av deras tjänster. Utifrån de kostnader som företaget kommer att ha under etableringsperioden på fem år har projektgruppen tagit fram en investeringskalkyl för Beta. Denna investeringskalkyl kommer att beräknas enligt nuvärdesmetoden för att avgöra om investeringen är lönsam eller inte. Grundinvestering [G] - (kostnad för förstudiefas och utrustning) Kalkylränta [r] - 7 % Årligt överskott, inbetalningar utbetalningar / år År 1 ( ) År 2 ( ) År 3 ( ) År 4 ( ) År 5 ( ) Ekonomiska livslängden för utvecklingen, antal år [n] - 5 Restvärde [R] kr kr kr kr kr kr kr Utifrån de uppgifter som finns ovan beräknades nuvärdet av alla årliga inbetalningsöverskott med hjälp av nuvärdesmetoden. Grundinvesteringen består av kostnader för förstudiefasen som uppgår till kr och datorutrustning som uppgår till kr. Restvärdet av utrustningen uppgås till 9830 kr det femte året efter en årlig värdeminskning på 20 % per år. Det årliga överskottet multipliceras med nuvärdesfaktorn enligt följande formel: Nuvärdesfaktorn (NF) =, där r = räntan och n = antal perioder (år) Med hjälp av formeln beräknas nuvärdefaktorn för varje år. Nedan visas nuvärdesfaktorn per år: År 1 ( ) 0,9346 År 2 ( ) 0,8734 År 3 ( ) 0,8163 År 4 ( ) 0,7629 År 5 ( ) 0,

49 Kapitalvärdet räknas fram med följande formel: Kapitalvärde = Kapitalvärde = ( * 0, * 0, * 0, * 0, * 0, * 0,7130) = kr Utifrån de beräkningar som har gjorts ovan kan projektgruppen dra slutsatsen att investeringen ger ett positivt kapitalvärde under en etableringsperiod som sträcker sig över fem år. Detta betyder att investeringen som Beta gör för att utvidga sina tjänster till den norska marknaden är lönsamt. Investeringen visar sig vara lönsamt utifrån de antaganden projektgruppen har tagit. Det är värt att konstatera att svagheterna i analysen kan till exempel vara att medlemmarna har varit för optimistiska i kalkyleringen. Det kan förekomma högre kostnader och mindre inkomster under etableringsperioden. En stor risk, som även har presenterats i riskanalysen är att Beta kan påverkas negativt om nuvarande systemutvecklare sjukskriver sig en längre period. Utifrån ett annat perspektiv är analysens styrka att intäktsberäkningarna har gjorts försiktigt och räknats på siffror som inte ger höga vinster. Som tidigare nämnt, förväntar Beta sig att kunna etablera sig mycket fortare på marknaden just på grund av deras starka ställning på den svenska marknaden och den stora efterfrågan som finns av deras nuvarande kunder. Projektgruppens rekommendation är att utgå ifrån beräkningar som gjorts ovan för att vara beredd på kraftiga ändringar på marknaden. Det anses vara bättre att räkna på mycket lägre vinster än att förvänta sig höga vinster eftersom att dessa är svåra att förutse, speciellt på en ny marknad där inga garantier finns. Om det skulle visa sig att Beta lyckas vända investeringen till positiva siffror under en kortare period än fem år så är det egentligen bara bra för den långsiktiga utvecklingen som företaget kommer att ha. Som en följd av en sådan positiv utveckling kan man göra justeringar i budgetplaneringen och sätta högre mål. Ett exempel kan vara att nå högre försäljningssiffror genom att nå ut till fler kunder, vilket även kan bidra till att man kan ha högre vinstmarginaler. 37

50 38

51 5. Analys och diskussion I detta avsnitt presenteras först en sammanfattning av författarnas slutsatser kring arbetets validitet och reliabilitet. Sedan görs en analys och diskussion om projektets metod och resultat man har kommit fram till. Avsnittet kommer också att ta upp förslag på framtida forskning inom samma ämne. 5.1 Validitet och reliabilitet av resultatet Resultatets validitet Vid genomförandet av projektet har projektgruppen lagt stort värde på begreppet validitet och redan tidigt under arbetet strävat efter att nå hög validitet. Syftet med validitet har varit att svara på frågan om dels rätt metod använts, och, om resultatet av denna metod fungerade för att lösa Betas problem. Författarna anser att de metoder som använts är relevanta för projektet och grundar sig på frågeställningar som det har tagits ställning till för att lösa problemet. Utformning av metoden hade inslag av vetenskaplig forskningsmetodik som beskrivits i kapitel Resultatet bedöms vara valid eftersom att resultatet stämmer överens med de teorier som har använts. Resultatet som visats av projektmedlemmarna har även generaliserats för att möjliggöra användning av utvecklingsprocessen på andra marknader. Författarna kan dock inte garantera till 100 procent, att samma process som framtagits för Beta, kan vara valid för ett annat företag som vill utvidga IT-system till en ny marknad. Därför rekommenderas det att först testa utvecklingsprocessen en kort period för att mäta effekten av denna för respektive verksamhet Resultatets reliabilitet Liksom validitet har reliabilitet varit minst lika viktigt under arbetets gång. Tanken med reliabilitet har varit att i slutet av projektet kunna svara på arbetets pålitlighet, alltså om resultatet ger underlag för att svara på problemformulering och hur pass bra detta resultat är. Projektgruppen anser att även om de resultat som redovisas är anpassad specifikt för Betas möjligheter att ta sig in på en ny marknad så grundar sig det även på vetenskaplig teori. Ett exempel på det är hur utvecklingsprocessens olika steg finns i den vetenskapliga forskningsmetodiken som tidigare beskrivits. Därför bedömer man att de resultat av arbetet som redovisats är pålitligt. 39

52 Likaså är informationen som projektmedlemmarna fått ta del av under arbetets gång, både från Beta och från norska tullverket pålitligt. Trovärdigheten av information som tullverket i Norge delat med sig stärks av att de som en myndighet har skyldighet att besvara frågor som ställs från medborgare, och speciellt om det är från en aktör som vill använda deras teknik för elektroniskt informationsutbyte. 5.2 Diskussion om vald metod Under projektet användes en rörlig metod. Projekttriangeln [24] erbjöd författarna möjligheten att arbeta flexibelt, alltså att kunna lägga till och ändra innehållet av arbetet utan större problem. Projektet präglades av projekttriangelns rörlighet eftersom att det förväntade resultatet, till skillnad från tid och kostnad, inte var fastställd från början. Därför påverkades resultatet av hur produktivt genomförandet av arbetet var. Målet var att ta fram en lämplig undersökningsmetod för att sedan leverera en testad utvecklingsprocess till Beta. Denna metod testades för att se att den verkligen är användbar. Anledningen till att testa metoden direkt efter processförslaget var för att tidigt kunna avgöra om det var rätt arbetsmetod och om den fungerade för detta arbete. Valet av undersökningsmetoden ansågs vara mest anpassad för att användas i detta examensarbete med en tidsbegränsning på 10 veckor, och detta val stärktes av att den uppfyllde kraven för vetenskaplig forskning. Författarna anser också att undersökningsmetoden som illustrerats i kapitel 3 är väldigt enkelt att förstå och har ingen komplexitet. För att tydliggöra metodens olika steg gjordes även en beskrivning med förklaring. Det var från början tänkt att utforma undersökningsmetoden för arbetet tillsammans med uppdragsgivaren, vilket det inte visade sig hinnas med då projektets omfattning justerades. I mån av tid var tanken att lyfta fram alternativa metoder och göra en jämförelse av de för att se vilken som passade bäst men det uteslöts. O andra sidan fungerade undersökningsmetoden som togs fram och därför hade projektgruppen inte behov av att jämföra andra metoder. Det är dels därför det först gjordes ett processförslag och testade denna en kort period för att se om den fungerade eller inte. Värt att poängtera är också att projektmedlemmarna upptäckte att det tog längre tid än förväntat att definiera projektets omfattning och spegla det på projektdefinition. Det tog även allmänt längre tid att ta fram en bra arbetsmetod. Vid framtagning av undersökningsmetoden testades den en kort tid för att undersöka om den verkligen var användbar. På grund av längden på testperioden kan resultatets omfattning ha påverkats. Om arbetet skulle genomföras under en längre tidsperiod anser författarna att det skulle finnas utrymme till justeringar och effektivisering av metoden. Metoden skulle eventuellt kunna utökas med några steg som skulle kunna leda till bättre resultat. Det kan inte heller garanteras att metoden är lämplig för större projektet eftersom att de oftast kräver 40

53 avancerade arbetsmetoder. Däremot är bedömningen att denna metod, som ändå uppfyller kraven för vetenskaplig metodteori (källa ), kan vara bra att ha som grund för vidare utveckling av arbetsmetodik. Gruppen har den uppfattningen att det är ytterst viktigt att ha en bra metod för att arbeta mot ett mål. Det är kritiskt att denna metodik samtidigt bör ha inslag av vetenskaplig forskningsmetodik. 5.3 Diskussion om resultat Arbetet gav förväntat resultat, att skapa en användbar utvecklingsprocess som Beta kan ha nytta av när de ska bredda sitt IT-system mot den norska marknaden. Uppgiften var att undersöka vad som krävs teknikmässigt för att företaget ska vara en aktör på den norska marknaden. Resultatet ger indikation på hur Beta ska gå tillväga för att anpassa deras ITsystem och, även om inte till 100 procent, vad som ska göras. I dagsläget går det inte att säga om Beta kommer att godkännas som aktör på den norska marknaden. Det är en pågående process som kommer att ta flera månader för att det behövs en testperiod av systemet för att se om alla typer av elektroniskt informationsutbyte fungerar korrekt. Om man skulle ta ställning till samma uppgift på nytt, och utgå ifrån samma förutsättning och metod som har använts under arbetets gång, skulle resultatet med stor sannolikhet bli densamma. Det som skulle kunna ha påverkat resultat positivt eller negativt skulle vara andra aktörers inflytande. Under detta arbete har prestationen varit beroende av kommunikationen mellan projektgruppen och tullverket i Norge. Resultatet skulle kunna få ett positivt inslag om det vid upprepning är kortare svarstid från myndigheten i Norge. Detta skulle ge möjlighet att identifiera alla kriterier som systemet bör uppfylla samt implementera de ändringar som behövs mycket tidigare än vad det har gjorts. Eftersom att det under arbetets gång har varit svårt att få svar på alla frågor ifrån norska tullverket kommer resterande svar som Beta efterfrågat förmedlas direkt mellan företaget och myndigheten. Även om kravspecifikationen fastställdes tillsammans med Beta i ett tidigt skede av projektet bromsades arbetsfarten rejält på grund av dålig kommunikation med myndigheten i Norge. Detta var inte något som projektgruppen kunde påverka eftersom att svaren till frågorna dröjde på grund av hög ar-betsbelastning hos motparten. Detta i sin tur har påverkat resultatets omfattning. Resultatet kan ha påverkats av den omfattning av information som varit tillgänglig under arbetets gång. Gruppen hade gärna velat ha mer direkt kontakt med norska tullverket för att skapa underlag för Betas kriterier. Handläggaren från myndigheten som projektgruppen har varit i kontakt med valde oftast att länka till information som finns på deras webbsida. Informationssökandet tog en hel del tid och begränsade arbetsgruppens möjligheter att lägga fokus på andra områden inom projektet. Detta påverkade även 41

54 utformning av resultatet som presenterades under tidigare avsnitt, kapitel 4. På grund av den långa svarstiden från myndigheten valde gruppen att skapa en utvecklingsprocess som jämför de olika myndigheternas teknik parallellt utifrån den information som varit tillgänglig. Sedan, ju fler svar arbetsgruppen fick från norska tullverket, ökade jämförelsen av systemets olika delar successivt. Detta gav utrymme för effektivare arbetssätt och ökade samtidigt produktiviteten. En följd av ovan nämnda händelser som förekom under arbetets gång var att minska på uppgifter som skulle utföras utifrån kravspecifikationen. Det valdes därför att lägga större fokus på de viktigaste frågorna och därefter skapa underlag för mindre frågor som inte påverkade systemets funktionalitet så mycket. De mindre problemen överlämnades därför till uppdragsgivaren som efter detta projekt kommer att fortsätta vara i kontakt med myndigheten i Norge. Förhoppningen var att identifiera alla systemkrav och skapa underlag för dessa förändringar som skulle göras i det nuvarande systemet samt ge förslag på en utvecklingsprocess som företaget skulle använda vid implementering av breddning. Eftersom att man inte har kunnat identifiera alla krav som motparten ställer på ITsystemet bedöms det att resultatet inte blivit tänkt som från början. Däremot har en tydlig grund skapats för hur själva implementeringsprocessen ska gå till, vilket Beta kommer att ha nytta av. Utvecklingsprocessen som framtagits av projektgruppen är specifikt anpassad för att lösa Betas problem. Förhoppningen är att den generella processen som illustreras under 4,2 även kan användas av andra verksamheter som vill bredda sina lösningar till nya marknader. Dock kan de behöva testa utvecklingsprocessen en kort tid för att se om den är användbar. Därefter kan mindre justeringar göras och anpassas efter respektive verksamhets situation. Det kan till exempel vara att utöka processen med jämförelser av flera marknader. Även då anses resultatet påverkas av verksamhetens förhållning till den nya marknaden. Om det finns möjlighet för ständig kontakt med någon ansvarig på den nya marknaden kan man implementera ändring av system mycket fortare. Det var även tänkt att göra en uppskattning av kostnader för att ändra IT-systemet men det uteslöts på grund av brist på tid. Dessutom drog parterna emellan, projektmedlemmarna och uppdragsgivaren, slutsatsen att en detaljerad uppskattning av kostnad kommer att göras av Beta först när de vet exakt vilka delar av systemet som skall ändras. 5.4 Förslag på framtida arbeten På grund av tidsperioden för detta arbete har inte projektgruppen haft möjlighet att ta fram alternativa metoder att arbeta med. Det skulle vara intressant att följa en undersökning där en annan metod används, vilket resultat det genererar och jämför det med resultatet i detta 42

55 projekt. Ett annat förslag på framtida projekt är att försöka skapa en utvecklingsprocess för verksamheter som ställs inför problem med större omfattning. Det kan till exempel vara frågan om att man vill utvidga sina IT-lösningar till flera marknader samtidigt eller också att det är flera IT-system, istället för ett, som skall anpassas till en ny marknad. Resultatet av en sådan undersökning kan användas till att analysera om det finns tydliga skillnader och likheter på hur en utvecklingsprocess kan se ut för mindre respektive större verksamheter, och i så fall i vilken utsträckning man påverkas av det. Förhoppningsvis kan den typen av analys underlätta verksamheters val av rätt utvecklingsprocess i framtiden. Projektgruppen tycker att det har varit problematiskt att hitta tidigare forskning kring samma område. Det är dock inte ovanligt eftersom att den här typen av problem inte förekommer så ofta. Därför hoppas man på fler vetenskapliga arbeten inom ämnet i framtiden. 43

56 44

57 6. Slutsats Resultatet som presenterades i detta arbete togs fram genom att ta ställning till Betas situation och deras möjligheter att bredda sitt IT-system till en ny marknad. Även om detta resultat fungerar, och kommer att vara till grund för Betas metod att utvidga sina lösningar, så kan det vara nyttigt att köra en längre testperiod för att se vilken effekt det ger. Det kan till exempel vara så att metoden fungerar bättre för att lösa en del av systemet och är mindre effektivt för utveckling av systemets andra delar. Då kan det vara bra att göra eventuella justeringar av utvecklingsmetoden för ökad produktivitet. Projekt-gruppen bedömer att utvecklingsprocessen inte kan garanteras fungera som den mest effektiva lösningen för andra verksamheter. Därför finns ingen generell teori om att just denna lösning är bäst. Rekommendationen för övriga verksamheter som vill använda samma process är att de testar den en kort tid och analyserar vilka effekter den ger. Rekommendationen för Beta, och andra organisationer som vill använda författarnas lösning är att de undersöker om samma metod kan användas vid jämförelser av mer komplexa system. Det kan även vara så att om man ställs inför utmaningen att undersöka möjligheten att gå in på flera marknader samtidigt. Då kan den skapade utvecklingsprocessen behöva utökning av fler steg. Detta anses generera ett bättre och mer säkert resultat som i framtiden kan utesluta onödiga kostnader som kan uppstå på grund av fel arbetsmetoder. Gruppen tycker att de krav på vetenskaplig forskning som ställs av Bunge (se kap. 2.8) har varit mycket till hjälp för arbetets genomförande. Den beskrivning som Beta gav inom ämnesområdet var en viktig bidragande faktor till att starta arbetet på rätt sätt. Detta stärktes även av att identifiera deras problem och målsättning vid ett tidigt stadie av projektet. Författarna anser att man, efter slutfört arbete, har ökat förståelsen för hur man tar sig an problem av denna typ och har den uppfattningen att andra akademiker kan dra nytta av resultatet för framtida arbeten. 45

58 46

59 Källförteckning 1. Tullverkets internetdeklaration TID - Hämtad senast Transporthandbok Hämtad senast NCTS Hämtad senast Meldningshåndbok for Elektronisk transittering og forhåndsvarsling Hämtad senast Generellt om EVRY Hämtad senast EVRYs historia Hämtad senast Fredholm, Peter (2002). Elektroniska affärer. Femte upplagan. Studentlitteratur, Lund 8. Fredholm, Peter (2006). Logistik och IT För effektivare varuflöden. Studentlitteratur, Lund 9. The OFTP Protocol - Data Interchange Hämtad senast Tullverket - EDI säkerhet - informationsutbyte/tekniskaforutsattningarforedi/edisakerhet.4.226de b8cf351d62.html Hämtad senast What is EDI? - Hämtad senast How does EDI work? Hämtad senast Tekniska förutsättningar för EDI - informationsutbyte/tekniskaforutsattningarforedi.4.226de b8cf351c68.html - Hämtad senast

60 14. Huemer, Christian (2000). XML vs. UN/EDIFACT or Flexibility vs. Standardisation. University of Vienna - Hämtad Framtida tullhantering (Nyhet om övergång till XML) - html Hämtad All about ISO-standards Hämtad senast Kommunikation inom OFTP2, en genomgång och kurs inom OFTP - Hämtad Liljegren, Gustaf (2007). XML: begreppen och tekniken. Upplaga 1. Studentlitteratur, Lund. 19. Gerth, Christian (2013). Business Process Models - Change Management. Springer-Verlag Berlin och Heidelberg GmbH Co. K 20. Eriksson. H & E, Penker M. (2000) Business modeling with UML : business patterns at work. New York : Wiley 21. Informationen har tagits från företaget Beta. Det är interna dokument som har skrivits av företagets systemutvecklare. Finns ingen bok eller publicerad vetenskaplig artikel som hämtats 22. Bunge M. Epistemology & Methodology I: Exploring the World [Internet]. Dordrecht: Springer Netherlands; Hämtad Bryman, Alan (översatt av Nilsson, Björn), Samhällsvetenskapliga metoder, Liber, Malmö 24. Projekttriangeln Hämtad senast Eklund, Sven. 2011, Arbeta i projekt individen, gruppen, ledaren. Studentlitteratur, Lund 48

61 Bilagor Felhantering av meddelanden Ganttschema Systembeskrivning/kommunikation Sverige processbeskrivning Urval av frågor till norska tullverket Kravspecifikation för systemet och det den stödjer Summering av förstudien -> vad Beta måste göra och hur de ska gå till Import/export sekvensdiagram visa hur det går till Ett exempel på varukodspost i svenska systemet Signeringscertifikat EDI Svenska Tullverket EVRYs prismodell som kommer att gälla för Beta 49

62 Felhantering av meddelande i Sverige Normalfall, CONTRL typ 1 positiv, inga EDIFACT-fel detekterade i TMT eller TDS: Innebär att CUSDEC/AUTACK-överföring har gått vidare till TDS applikationsnivå, funktionell kvittens kan förväntas i form av ett CUSRES-meddelande. Fallet är signalmässigt illustrerat i figuren nedan. Felfall 1, negativ CONTRL typ 1: Innebär att TMF har detekterat EDIFACT-fel i CUSDEC/AUTACK-överföringen, som inte kommer att vidarebefordras till TDS. Omsändning efter rättelse av CUSDEC + AUTACK är enda sättet att komma vidare. Fallet är signalmässigt illustrerat i figuren nedan. 50

63 Felfall 2, CONTRL typ 1 positiv och CONTRL typ 2 negativ: Innebär att CUSDEC/AUTACK-överföring har godkänts av TMF men att EDIFACT-fel detekterats av TDS. Meddelandet har inte vidarebefordrats till TDS applikationsnivå. Omsändning efter rättelse av den ursprungliga överföringen är enda sättet att komma vidare. Fallet är signalmässigt illustrerat i figuren nedan. 51

64 Signalfall, Tullsvar i Sverige Normalfall 1 och felfall 1: CUSRES/AUTACK-överföring skickad från TDS till företag. Normalfall 2, inga EDIFACT-fel detekterade hos företaget: Innebär att CUSDEC/AUTACKöverföring har gått vidare till företagets applikationsnivå. Fallet är signalmässigt illustrerat i figuren nedan. 52

65 Felfall 2, EDIFACT-fel detekterade hos företaget: Innebär att företaget har detekterat EDIFACT-fel i CUSDEC/AUTACK-överföringen. Fallet är signalmässigt illustrerat i figuren nedan. 53

66 Sigillering och AUTACK meddelandet. Sigillinformationen i en överföring ligger inte längre distribuerad i de sigillerande meddelandena, utan samlas ihop i ett AUTACK-meddelande. Dock kvarstår kravet att sigillinformationen ska finnas med i samma överföring som de meddelanden som sigilleras. Det hela hålls ihop med det referenssystem som finns inbyggd i AUTACK-meddelandet, där det entydigt pekas ut vilket CUSDEC/CUSRES-meddelande ett specifikt sigill tillhör. Varje överföring innehållande en eller flera CUSDEC eller CUSRES innehåller därför också en AUTACK. En överföring kan inte innehålla fler än ett AUTACK-meddelande (fler resulterar i EDIFACT-fel). För riktningen företag -> TMF/TES kommer innehållet i en överföring med avseende på typ av meddelanden alltid att vara: - En eller flera CUSDEC + en AUTACK. - En CONTRL av typ 2. För riktningen TMF/TES -> företag kommer innehållet i en överföring med avseende på typ av meddelanden alltid att vara endera av: - En eller flera CUSRES + en AUTACK. - En CUSDEC + en AUTACK. - En CONTRL av typ 1 (från TMF). - En CONTRL av typ 2 (från TDS) 54

67 Arbetsgången vid sigillberäkning/sigillkontroll 55

68 Ganttschema 56

69 Processbeskrivning i Sverige Användare Användaren Tillståndshavaren 1. Klient med internetkoppling 2. Webbläsare för inloggning på Webbserver 3. CSA-Dosa vid förstärkt inloggning. Webb-server Webb-servern är installerad hos systemägaren. 4. Användarinloggning 5. Autentisering 57

70 6. MultiOTP 7. EDI-kod, vidareadress, sigillnycklar för ZEM, UTL, ZKH, ZKB, lösenord för UNB, send och recieve lagras i organisationsenheten för tillståndshavaren i programmet. Uppgifterna har bara SKP åtkomst till. 8. GUI och programvara. Punkterna 4-7 är en del av denna men har specificerats för att förtyd-liga viktiga komponenter i programmet. 9. Databaser för Tillståndshavare/EDI-parter kan vara installerade på samma Webbserver, dock är alla Tillståndshavare unikt installerade och separerade. Databasregister är unika för varje ansluten Tillståndshavare med följande innehåll: Organisationsinformation Funktionstabell (exempelvis om tillståndshavaren har tillstånd till förenklat lokalt klare-ringsförfarande kan funktion slås på för tillgång till att sända UGEmeddelande, Funktion för åtkomst till Kreditimportörsregister etc.) Användare Kundinformation (vid ombudsförfarande) Avsändare/Mottagarinformation Nummerserier för unika nr/deklaration, Tullid, Meddelandenummer etc. Orter/Länder Tullkontor Godslokalkoder Kodförteckning för Särskilda uppl., Kollislag, Avgifter etc. Alla tidigare gjorda deklarationer Historik per tullid Filer för sändning till TMF: EDIFACT -filer för sändning till TMF Filer mottagna från TMF: EDIFACT-filer för mottagning från TMF EDI-kod, UNB-lösen, lösenord för send, receive 10. Certifikatuppgifter och privat nyckelfil för signering. 11. EDIFACT bibliotek API Konverterar data till edifact och beräknar Autack. Enheten kontrollerar även inkommande data att den är korrekt, konverterar och skickar vidare svarsdata 12. OFTP CWS sköter transmissionen av data mellan Webbserver och OFTP CWC servern som kommunicerar med TMF. OFTP CWS sparar alla filer i sitt filarkiv - Archives. I CWS send läggs alla filer som ska skickas och i CWS receive hamnar alla filer som ska tas emot. 58

71 13. Generella databaser kan användas av alla anslutna ASP-tillståndsinehavare som systemleverantören har installerat på samma Webb-server. Databaserna är: Taric Tullkurser Kreditimportörsregister 14. Logg, OFTP CWC har en logg där alla händelser in och ut registreras. Det gör att fel i kommunikationen enklare kan upptäckas. 15. Subenhet, varje tillståndshavare är en subenhet av OFTP CWC server. På detta vis är alla installerade tillståndsinnehavare separerade. För att kunna administrera kommunikationen till rätt adress måste uppgifter om punkt 13 också sparas här. 16. EDI kod, vidareadress, lösen för UNB, send och receive sparas för varje tillståndhavarenhet för att kunna administrera kommunikationen mellan Tullverket och tillståndsinnehavaren. Uppgifterna måste vid upplägg av tillståndsinnehavare läggas in av systemleverantören. 17. OFTP CWC har i normalläge status Sender och TMF Listner så fort TMF har filer att skicka initierar den en statusförändring där TMF är Speaker följt utav OFTP CWC blir Listner och sedan genomförs transmissionen. När transmissionen är genomförd går status tillbaka till normalläge. Filer som skickas och tas emot arkiveras i mapparna Send, Receive och Archives för varje uppkopplad tillståndshavare för att få historik om kommunikationen och möjlighet till felsökning. Tullverket 18. TMF, Data såsom t ex deklarationer, kvittenser lämnas över till TMF ifrån Webbsevern via OFTP CWC. Data ifrån TMF såsom t ex kontroll, resultat och klarering tas emot av OFTP CWC och förmedlas till Webbservern som validerar data och visar information till kundens klient. Separat för varje tillståndshavare 19. Separat. Den streckade linjen i bild förtydligar de delar som hos systemleverantören installeras separerat för varje tillståndsinnehavare på systemleverantörens webbserver och OFTP CWC server. 59

72 Frågor till norska Tullverket Om något fel uppstår när meddelandet skickas till tullverket, hur sker rättelserna av överföringen till er? Skickas hela meddelandet om igen eller är det till exempel bara de delar av meddelandet som blir rättade som skickas igen? Alltså är det frågan om ett helt nytt meddelande skickas med rättelser eller är det enbart data som blir rättade som skickas. Vi har fått lite information om att EVRY är nätverksleverantör för svenska företag i Norge. Är det ett krav som ställs från er eller finns det möjlighet att göra det utan EVRY och kommunicera med tullverket i Norge direkt? Vet ni om EVRY har några krav för att få ha de som nätverksleverantör? Ställer EVRY några krav på användning och kommunikation med tullverket i Norge? På er hemsida ( hittade vi inte information om säkerhetskrav. Hur ser det ut? Vi skulle vilja veta mer om vilka säkerhetskrav det finns om till exempel teknisk regelverk, valideringar och signeringar vid samarbete med norska tullverket. Vad för säkerhetskrav finns det vid meddelande överföring till er? Finns det specifika säkerhetskrav för till exempel EDIFACT? Måste man identifiera sig varje gång meddelande skickas till er? I Sverige används PKI signering med certifikat där användarna får identifiera sig med en dosa. Har ni något liknande i Norge, eller görs det på ett annat sätt? Har ni planer på att göra förändringar inom systemet de närmaste åren? Finns det någon projektplan inom norska tullen som kan påverka programvaruleverantörer? I Sverige pågår just nu en övergångsperiod av att gå över från EDIFACT till XML. Har ni i Norge någon plan på att ersätta EDIFACT med XML de kommande åren? Har ni några krav på att vi som programvaruleverantör behöver skriva systemdokumentation på hur vårt system är uppbyggd och hur det kan användas? Vad vi har förstått så finns det ingen krav på översättning (till norska) av varubeskrivningar. I samband med det skulle vi vilja veta om ni tar emot tecken från andra språk. Omvandlas till exempel japanska tecken till motsvarigheten (latinska tecken) eller skulle det uppstå problem med det? Finns det något exempel på hur en testperiod kan se ut? Vi skulle gärna vilja veta specifikt vad som behöver testas och hur lång en sådan testperiod kan vara. 60

73 Kravspecifikation 1. Molnbaserad lösning - allt du behöver är internet och en webbläsare 2. Hantering av samtliga EDI-meddelanden (import, export, transit och anmälningar) 3. Utvecklas efter de nya krav som kommer med UCC (standarddeklaration m.fl.) 4. Dynamiskt gränssnitt som anpassas beroende på meddelandetyp 5. Tullager-, saldo- och artikelhantering enligt Tullverkets krav på journalföring 6. Hantering av deklarationsmallar 7. Automatisk ifyllnad av information anpassat efter Tullverkets regelverk 8. Deklarationsassistans - tidig upplysning om felaktig data 9. Använd kortkommandon och tabbar för att minska antal musklick 10. Välutvecklat API för integrationer via exempelvis XML, EDIFACT, flatfiler etc. 11. Aktuell Tulltaxa med sökfunktioner och koppling mot avsändare och mottagare 12. Kan driftas på egen server eller som en hostad lösning 13. Hantering av PKI med certifikat och signering 61

74 Sammanfattning av vad som behöver göras för att godkännas som en aktör på den norska marknaden. Tass motsvarigheten till TARIC (tulltaxa) TET Det norska transiteringssystemet TVINN Motsvarigheten till TDS, alltså för import och export NCTS Norska tullverkets datoriserade transiteringssystem. Det är ett elektroniskt system för utbyte av transit information mellan industrin och tullförvaltningen, och för föranmälan av gods direkt till och från tredje land. Länk till information om NCTS: Varukoder i Norge 8 siffror totalt, varav de 6 första är internationellt och de 2 sista specifikt för Norge Norstella Länk till Norstellas hemsida här finns implementationsguider för hantering av import och export meddelanden i TVINN systemet. Separat dokument finns tillgänglig för Beta. Under bilagor presenteras den här guiden, som är öppen för allmänheten: Krav för att få använda TVINN Först krävs det att man får ett norskt organisationsnummer NODI-nummer. Identifieringsnummer (ID-nr) används för att identifiera parterna till en EDI-utväxling i TVINN systemet, till exempel sändare och mottagare. ID-nummer krävs för att göra elektronisk tullklarering, och har följande struktur: NO NO = Norge, organisation indikeras av följande 4 siffrorna och grenadressen (åtkomstpunkten) anges med de två sista siffrorna (1-99). Identifikationsnumret som man får från NorStella behövs vid senare kontakt med tullverket och nätverksleverantören. 62

75 Nätverksleverantören behöver vara godkänd av norska tullverket. Med största sannolikhet är det EVRY som kommer att vara nätverksleverantör eftersom att de är länken mellan programvaruleverantören och tullverket i Norge. Programvaruleverantören Beta, måste ha ett system som är kompatibel med TVINN. Ansökan kan göras via deras hemsida genom att fylla i ett formulär som finns på: Kostnaden för att använda tjänsten: 1980 NOK (ansökningsavgift + användning första året). Året därpå 1170 NOK/år för användning av ID-nummer. OBS! Beloppet kan komma att ändras. Den har höjts senaste året. Punkterna ovan måste genomföras först. När företaget har uppfyllt dessa krav skickas en ansökan från deras sida till regionchefen för tullområdet där Beta kommer att bedriva sin verksamhet (Oslo). Kommunikationen mellan programvara, som Beta kommer att använda, och TVINN måste först testas och sedan godkännas. Först efter att detta är klart så blir man tilldelad ett ID-nummer. Ett tillstånd kommer sedan att skickas som skall returneras med signatur. Nedladdningsfiler för TVINN (t.ex. avgifter, områdeskoder, tariff, valutakurser, beskrivning av TVINNdata osv.) finns på FTP-servern: ftp://ftp.toll.no alternativ från Tulltaxan laddas ner från TARIC och finns i systemet som Betas kunder använder. I Norge verkar det inte finnas liknande databas som i Sverige. Istället länkas det till PDF respektive Excel filer som innehåller alla tariffer. Man kan göra sökningar via: esplanguage=no Genom att söka resultat på fritext/råvara, produktnummer och kapitel/positionsnummer kan kunden få resultat på tulltaxan för den aktuella produkten. Tultaxan är även åtkomlig på samma länk via en PDF respektive Excel fil. 63

76 Utskrifter Det finns ingen direkt mall på hur tulldokumenten skall se ut i programvaran. Det viktiga är att den följer strukturen som tullverket har i deras formulär. Alltså bör samma information som finns i dessa formulär finnas i programvaran. Formulären finns på Alltså måste utformningen av alla fält i programvaran matcha blanketterna för import och export. De fält som är obligatoriska bör fyllas i. Informationen som fylls i måste matcha blanketterna som finns på följande länk Exempel på hur importdeklaration bör fyllas i: =194#1 Exempel på hur exportdeklaration bör fyllas i: =197#1 Tester Test av ny programvara som inte har använts tidigare kräver en hel del saker. Programvaran måste testas och godkännas mot NCTS, vilket de tycker är en mycket omfattande process i och med att det krävs en hel del planering från deras sida. När det gäller test av TVINN programvara kommer det mer detaljerad information att lämnas till Beta (finns inte i rapporten). Översikt över hur test av en egenutvecklad programvara för NCTS innebär Det som skall testas i detalj beror på vilken typ av tjänst som skall användas. För att godkännas som avsändare, mottagare eller både och krävs det en föranmälan till tullverket. Omfattning, och hur lång tid, en sådan test kan ta beror på hur många fel Tullverket upptäcker på vägen (när de testar Betas system) och hur effektiv kommunikationen under testerna är. Det svar som vi har fått ifrån de är att det kommer att ta minst 3 veckor att testa systemet (de baserar det på tidigare erfarenheter). Man måste vara registerad i NCTS PT-miljön (produktionstestmiljön) som behörig 64

77 avsändare (DEP) och mottagare (DES) mot tullkontors koden NO11091B (Polmak): Behörighetsnummer + auktoriserad avsändare (DEP) Behörighetsnummer + auktoriserad mottagare (DES) Testmeddelanden kommer att skickas till NODI-numret NO De (TOD-tullbyrån) registrerar garantier i GMS PT på följande sätt: - Garanti typ 0 - Garanti typ 1 Testning som auktoriserad mottagare. Listan som finns nedan visar vilka punkter som testas med olika testutfall. Ankomstregistrering i normala förfarandet T1 och T2 deklarationer med en och flera varuposter samt med konsumentvaror, behållare (container) osv. Deklarationer med och utan registrerade händelse pågår på transitkontor. Status på aktiviteter. Deklarationer med olika händelser. Ankomstkontroll i förenklat förfarande (IE007) T1 och T2 deklarationer med en eller flera varuposter samt med konsumentvaror, behållare (container) Deklarationer med och utan registrerade händelse pågår på transitkontor. Status på aktiviteter. Deklarationer med olika händelser. Automisk IE043 (loss tillåtelse) skickas från NCTS till deklaranten (auktoriserad mottagare) efter ankomstregistreringen En kopia av deklarantens skärmbild där det visas hur lossningsanmärkningar läggs in (IE044), tas emot och granskas Registrering av lossningsanmärkningar Utan avvikelser Med avvikelser, brister och gömställen (där de finns/lagras) på varuposten 65

78 Med hela varupostens brister Lägga till en ny varupost (med plats/ gömställe ) Hur flödet har rullat på, händelser under vägen, t.ex. omlastning osv. Varor med brister dokumenterade handlingar som lämnas in Varor med brister dokumenterade handlingar som inte har lämnats in Felsituationer som kan uppstå, som avvisas/förkastas med IE008 Felsituationer som kan uppstå, som avvisas/förkastas med IE058 Enligt de listade testscenarion som finns ovan, där transiteringen är klar, går IE025 (meddelande om fullföljd transitering) vidare som förväntat (godkänd) till deklaranten (auktoriserad mottagare). Testerna måste lyckas. Kommunikationen måste fungera. Testning som auktoriserad avsändare och varsel. Listan som finns nedan visar vilka punkter som testas med olika testutfall. Godkänd avsändare Normal och förenklad procedur T1 och T2 deklarationer med en och flera varuposter Deklaration med känsliga varor Deklaration med container Deklaration med och utan tätningar Deklarationer med flera mottagare Indragning/annullering/avbeställning från avsändaren Upphävning av tullen Hantering av felsituationer som kan uppstå Elektronisk garantihantering Ändring av åtkomstkoder eller tilläggskoder Hantering av garantin som inte är giltiga (IE055) Test av streckkoder på utskrift av medföljande dokument, meddelanden och kombinerad transitering/säkerhet. Varsel Rengör varsel Kombinerad transport och säkerhetsdeklaration 66

79 EVRY Alla aktörer på den norska marknaden går via EVRY för kommunikation med norska tullverket. Därför krävs en överenskommelse med dem. Så som det ser ut nu så behövs ingen ny kommunikationsteknik för Beta. De kommer att kunna använda sig av samma teknik (OFTP) som används i Sverige idag. EVRY godkänner detta. Till skillnad ifrån hur det görs i Sverige, finns det inget krav på signering av meddelanden som skickas. Betalningsmodellen (utan att gå in för mycket på detalj) är att Beta får betala för varje meddelande som skickas ut från de (alltså från Betas kunder). Alla meddelanden som skickas från norska tullverket är gratis. En rekommendation är därför att bygga in fler valideringar i systemet för att användaren ska skicka färre felmeddelande 67

80 Export-meddelande sekvensdiagram 68

81 Import-meddelande sekvensdiagram 69

82 Ett exempel på varukodspost i svenska systemet. 70

83 Signeringscertifikat EDI Svenska Tullverket 71

84 EVRYs prismodell som kommer att gälla för Beta presenteras nedan. Företaget kommer att få betala för att kunna skicka meddelanden, därefter för varje kund (transportör) som ansluts. En månadskostnad för support och drift. Samt en kostnad per meddelande som skickas. 72