Effektivare överföring av kundorderinformation för fintech-bolaget Subsigno - Framtagning av en skalbar process för interorganisatorisk informationsöverföring Efficiency upon transfering sales order information for the fintech company Subsigno - Creating a scalable process for interorganizational information transfer Kandidatarbete inom Industriell Ekonomi CHRISTIAN ELLSÉN PETTER HÄGGBERG HERMAN JANSSON JESSICA KÄRRBERG STINA STRÖBY AMANDA WIKSTRAND Institutionen för Teknikens ekonomi och organisation Avdelningen för Entrepreneurship and Strategy CHALMERS TEKNISKA HÖGSKOLA Kandidatarbete TEKX04-18-02 Göteborg, Sverige 2018 KANDIDATARBETE TEKX04-18-02 Effektivare överföring av kundorderinformation för fintech-bolaget Subsigno - Framtagning av en skalbar process för interorganisatorisk informationsöverföring Kandidatarbete inom Industriell Ekonomi CHRISTIAN ELLSÉN PETTER HÄGGBERG HERMAN JANSSON JESSICA KÄRRBERG STINA STRÖBY AMANDA WIKSTRAND Institutionen för Teknikens ekonomi och organisation Avdelningen för Entrepreneurship and Strategy CHALMERS TEKNISKA HÖGSKOLA Göteborg, Sverige 2018 Effektivare överföring av kundorderinformation för fintech-bolaget Subsigno - Framtagning av en skalbar process för interorganisatorisk informationsöverföring CHRISTIAN ELLSÉN PETTER HÄGGBERG HERMAN JANSSON JESSICA KÄRRBERG STINA STRÖBY AMANDA WIKSTRAND © CHRISTIAN ELLSÉN , PETTER HÄGGBERG , HERMAN JANSSON , JESSICA KÄRRBERG , STINA STRÖBY , AMANDA WIKSTRAND, 2018 Kandidatarbete TEKX04-18-02 Institutionen för Teknikens ekonomi och organisation Avdelningen för Entrepreneurship and Strategy Chalmers tekniska högskola SE-412 96 Göteborg Sverige Telefon: +46 (0)31-772 1000 Kolofon: Rapporten skapades med hjälp av LATEX och redigerades på www.sharelatex.com. Typ- snittet som används är Latin Modern. Figurer skapades med hjälp av programvara på draw.io. Chalmers Reproservice Göteborg, Sverige 2018 Sammanfattning Subsigno, som är ett alias för ett svenskt fintech-bolag, har skapat en applikation som hjälper användaren att få en bättre överblick över sin privatekonomi. De har flertalet samarbeten med andra företag som de, via sin applikation, genererar kunder till. Hur fintech-bolaget för över orderinformation skiljer sig åt beroende på samarbetspartner och bransch. Informationsöverföringsprocessen upplevs generera mycket manuellt arbete för Subsigno och arbetsbördan ökar när nya samarbetspartners ansluter. Subsigno har stadigt expanderat sedan applikationens lansering och för att kunna fortsätta sin expansion behöver Subsigno en ny process som minskar det manuella arbetet. För att kunna skapa ett nytt processkoncept har teori om processer och business process management studerats, likväl om hurvida interorganisatoriska system kan uppkomma mellan företag. Det tas även upp teori om hur ERP-system används med syfte att öka förståelsen för hur företag kan arbeta med orderhantering och integrering. Skalbarhet och vilka faktorer som är primära för att skapa en skalbar process utforskas även, liksom olika teknologier som Subsignos samarbetspartners nyttjar idag. Metoden för arbetet har varit av abduktiv karaktär och har delats in i fyra faser där den första har varit explorativ. Flertalet intervjuer med Subsigno och tre samarbetspartners gjordes vilket resulterade i en kartläggning av den dåvarande processen. I den andra fasen studerades teori som resulterade i ett teoretiskt ramverk, vilket tillsammans med fas 1 gav grunden till den tredje fasen där tre förslag på processkoncept togs fram. I den fjärde fasen genomfördes hypotetisk-deduktiv testning av koncepten vilket ledde till att ett nytt förslag på processkoncept togs fram. Denna process upprepades i tre iterationer vilket resulterade i ett slutkoncept. I det slutgiltiga processkonceptet som presenteras tillhandahåller Subsigno ett API för informationsöverföring vilket gör att de kan ansvara för och standardisera processen med sina samarbetspartners. De steg som identifierats ge upphov till manuellt arbete automatiseras och kan därför motiveras vara en skalbar lösning. Ett order-ID införs även för att minska överföringen av känsliga personuppgifter mellan aktörerna, vilket är något som förväntas öka hållbarheten och tillgodose GDPR:s hårdare lagkrav. Nyckelord: Affärssystem, GDPR, Interorganisatoriska system, Kundorderinformation, Skal- barhet , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 i Abstract Subsigno, which is an alias for a Swedish fintech company, has created an application which allows the user to manage his or her personal finance. They have several collaborations with various suppliers of services within different industries for which they generate new orders. The process of transfering order information differs between the various partners and industries. According to Subsigno the need for different processes for different partners and industries generates a lot of manual labour, and the workload only grows with the prospect of new collaborations. Since the launch of the application the company has grown steadily and to further enable this expansion a new process that deminishes the manual labour is needed. To enable the creation of a new process concept theory regarding processes and business process management has been studied, and whether or not interorganizational systems can exist between companies. Theory regarding ERP-systems has been studied with the purpose of increasing knowledge of how companies can work with processing orders and integration. Scalability and what the primary factors for creating a scalable process are has been explored, as well as the different technical solutions currently used by Subsigno’s business partners. The method has been that of an abductive nature and has been split into four phases, the first being an exploratory phase. Several interviews have been conducted with Subsigno as well as with three business partners and this has resulted in a mapping of how the process currently works. The second phase has been of an theoretical nature and has resulted in the theoretical framework. Phase three is based on the first and the second phase, and is where the first process concepts are generated. In the fourth phase hypothetical-deductive tests were conducted in three iterations, until a conclusive concept could be finalized. In the final concept Subsigno provides an API for data transfer which enables them to be in charge of and create a standard process for all business partners. The source of manual labour has been automized and therefore the concept is regarded as a scalable solution. An order ID is implemented to decrease the transaction of sensitive information between the companies, and is expected to further support the sustainability of the process and the upcomming legislation GDPR. Keywords: ERP-systems, GDPR, Information about sales orders, Interorganizational systems, Scalability ii , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 Innehåll Sammanfattning i Abstract ii Innehåll iii Förord v Tack v Akronymer vii Ordlista viii 1 Inledning 1 1.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Problemanalys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 Frågeställningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.5 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Teori 6 2.1 Business Process Management (BPM) . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Möjlighet att få till ett interorganisatoriskt system (IOS) . . . . . . . . . . . . 6 2.3 Skalbarhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4 Enterprise Resource Planning (ERP) . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.1 Trender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4.2 Integration med tredjepart . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4.3 Implementering av affärssystem . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4.4 Problem vid implementering . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.5 Application Programming Interface (API) . . . . . . . . . . . . . . . . . . . . . 11 2.6 File Transfer Protocol (FTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.7 Sammanfattande analytiskt ramverk . . . . . . . . . . . . . . . . . . . . . . . 12 3 Metod 14 3.1 Fas 1: Explorativa undersökningar . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2 Fas 2: Teoretisk analys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3 Fas 3: Problemlösning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.4 Fas 4: Hypotetisk-deduktiv testning . . . . . . . . . . . . . . . . . . . . . . . . 16 4 Resultat 18 4.1 Kartläggning av Subsigno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2 Kartläggning av liten teleoperatör . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.3 Kartläggning av mellanstor elleverantör . . . . . . . . . . . . . . . . . . . . . . . 21 4.4 Kartläggning av stor elleverantör . . . . . . . . . . . . . . . . . . . . . . . . . 22 , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 iii 4.5 Sammanställning av övriga samarbetspartners . . . . . . . . . . . . . . . . . . 23 4.6 Möjlighet till ett interorganisatoriskt system . . . . . . . . . . . . . . . . . . . 23 4.7 Sammanfattning av resultat och teori . . . . . . . . . . . . . . . . . . . . . . . 24 5 Konceptutveckling 26 5.1 Iteration 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.1.1 Koncept A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.1.2 Generering av koncept A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.1.3 Koncept B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.1.4 Generering av koncept B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.1.5 Koncept C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.1.6 Generering av koncept C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.1.7 Resultat iteration 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.2 Iteration 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.2.1 Koncept D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.2.2 Generering av koncept D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.2.3 Resultat iteration 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.3 Iteration 3 - Slutgiltigt processkoncept . . . . . . . . . . . . . . . . . . . . . . 39 5.3.1 Koncept E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.3.2 Generering av koncept E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.3.3 Resultat iteration 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 6 Diskussion 43 6.1 För- och nackdelar med slutgiltigt processkoncept . . . . . . . . . . . . . . . . 43 6.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 7 Slutsats 45 8 För vidare studier 46 Referenser 47 Bilaga A Intervjufrågor till Subsigno Fas 1 49 Bilaga B Intervjufrågor till samarbetspartners Fas 1 50 Bilaga C Självvärdering 51 Bilaga D Intervjumall iteration 1, Fas 4 52 Bilaga E Intervjumall iteration 2 och 3, Fas 4 53 iv , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 Förord Idén till detta kandidatarbete föddes då Subsigno flyttade till sitt nya kontor. En medlem i projektgruppen hjälpte då till att bära möbler och således såddes ett frö till vidare kontakt och samarbete. Vid tidpunkten var problemet odefinierat, komplext och till synes olösligt, men med tiden utvecklades det till en förfinad idé som slutligen utgjorde grunden för detta kandidatarbete. Så småningom har detta projekt inte bara lyckats kartlägga och skapa en lösning till det problem som Subsigno haft, utan även skapat en gemenskap bland författarna som förhoppningsvis kommer att vara i många år framöver. Tack Ett stort tack till vår handledare Mats Lundqvist som alltid ställt upp för oss och hjälpt oss med vägledning och gett värdefulla tips. Ytterligare tack till medarbetarna på Subsigno som varit väldigt öppna, tillmötesgående och ställt upp för oss på alla sätt de kunnat. Slutligen vill vi tacka alla de personer som står bakom termen ”samarbetspartners” för att de ställt upp på intervjuer och svarat på alla våra frågor i tid och otid. , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 v Akronymer API Application Programming Interface. 11–13, 19, 21–26, 28–45 B2B Business-to-Business. 1, 11 BPM Business Process Management. 6, 12, 13 ERP Enterprise Resource Planning. 9, 10, 13, 26, 45 EU Europeiska Unionen. 2 FTP File Transfer Protocol. 12, 13 GDPR General Data Protection Regulation. 1, 2, 21, 22, 29, 32, 33, 39, 41–43, 45 ID Identifikation. 18–20, 24, 27–29, 32–34, 37–43, 45 IOS Interorganisatoriskt system. 6, 23 IT Informationsteknologi. 6, 8–12, 30, 37, 45 SaaS Software as a Service. 10, 13, 26 SFTP Secure File Transfer Protocol. 12, 22, 23, 26–28, 32, 33, 35–39, 42, 44, 45 , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 vii Ordlista ad hoc är något som är utformat för ett särskilt ändamål eller tillfälle. 30, 37 agilitet är ett företags förmåga att anpassa sig till omgivningens volatilitet. 6, 26, 31 .csv-fil är en textfil som används för att spara och överföra tabelldata. 21, 27 fintech (förkortning för finansteknologi) är ett samlingsbegrepp för den senaste IT-teknologin inom finansvärlden. Fintech-bolag är specialiserade aktörer som kombinerar finansiella tjänster med mjukvaruteknik. 1, 26, 38 hit rate är ett mått som används främst inom försäljning och representerar hur stor andel av alla potentiella kunder som faktiskt blir kunder och kan faktureras. 4 interorganisatoriska system stödjer samt integrerar företag och människor över organi- sationsgränser. 6, 7, 13, 24 konfirmeringsbias tilllika bekräftelsefel, bekräftelsefördom eller bekräftelseförväntning är en tendens i mänskligt beteende att omedvetet vara selektivt uppmärksam på sådan information som bekräftar våra egna uppfattningar. 17, 41 SFTP-server är en typ av server som använder sig av det säkra filöverföringsprotokollet SFTP för att göra filer tillgängliga att laddas upp eller ner av SFTP-klienter. 19, 21, 23, 24 skalbarhet är när ett system är designat för att fortsätta leverera även om arbetsbelast- ningen ökar. 3, 4, 8, 9, 12, 13, 15, 28, 30, 31, 37, 41, 43, 44 viii , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 1 Inledning Hantering och överföring av orderinformation är något som de flesta företag behöver arbeta med. Hanteringsprocessens utformning varierar mellan företag och branscher, vilket skapar utrymme för effektivisering av arbetsflödet. Om en process inte är skalbar kan den utgöra en flaskhals för växande företag. Det finns dessutom lagkrav som företag måste förhålla sig till, såsom General Data Protection Regulation (GDPR). Digitala abonnemangstjänster blir allt mer vanligt förekommande i samhället och förutspås öka i framtiden. Det följandet kapitlet redogör för vad som har föranlett denna rapport samt hur den är utformad och avgränsad. Utifrån den identifierade problembilden formuleras ett syfte samt frågeställningar som rapporten ämnar behandla och vid projektets slut besvara. 1.1 Bakgrund Statistik visar att digitala tv- och tidningsabonnemang, musikstreaming och andra nätba- serade abonnemangstjänster har en mycket hög tillväxttakt (Myndigheten för radio och tv, 2018). För merparten av abonnemangstjänsterna sker betalningen månadsvis och har i vissa fall en avtalad bindningstid som sträcker sig långt fram i tiden. Därför kan det finnas svårigheter för konsumenter att få en översikt på de återkommande avgifterna samt deras totala kostnader. Subsigno är ett fintech-bolag, det vill säga ett bolag som kombinerar finansiella tjänster med mjukvaruteknik, som grundades under 2010-talet. Med hjälp av ny teknologi hjälper de användaren att få en överblick över sin privatekonomi och minska sina utgifter. Några år efter uppstarten lanserades den första versionen av applikationen och planen för Subsigno är att fortsätta expandera sin verksamhet under år 2018. Subsigno får inkomster i form av provision då nya kunder förmedlas till deras samarbetspart- ners. Marknadsstrategin innefattar därför arbete både mot konsumenter och företag, alltså Business-to-Business (B2B) som tredjepart. I dagsläget upplever Subsigno svårigheter från att en order skickas till samarbetspartnern till dess att en orderbekräftelse kommer tillbaka till Subsigno. Problemet grundar sig i att Subsigno är beroende av samarbetspartnernas återkoppling om kunden innan fakturering kan ske, då företaget endast tar betalt för faktiska nya kunder. Insamlingen av information kring orderna innefattar tidskrävande manuellt arbete som Subsigno själva uppskattar ta cirka 8 timmar i månaden. Vid expandering med fler samarbetspartners och användare kommer det manuella arbetet öka. Idag skapas fullständig orderinformation genom att skickade kundorder från Subsigno manuellt jämförs med orderbekräftelser från samarbetspartnerna, som kommer i varierande format och innehåll. Detta ger ett stort utrymme för mänskliga misstag, som till exempel att en kundorder ges fel status i systemet. Det kan dessutom bli stora tidsgap mellan kundorder läggs och fakturering av samarbetspartnern då samarbetspartnern inte alltid återkommer med orderbekräftelser. Det finns alltså inget standardiserat arbetssätt eller , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 1 rutin för att kontrollera orderuppföljning och få in den information som krävs. Samtidigt måste informationshanteringen möta de lagkrav som den nya förordningen General Data Protection Regulation (GDPR) ställer på företag. General Data Protection Regulation (GDPR) GDPR är en dataförordning som ersätter den tidigare personuppgiftslagen (PUL) och träder i kraft den 25:e maj år 2018 (Europeiska unionens råd, 2016). Lagen syftar till att skydda fysiska personer tillhörande länder inom Europeiska Unionen (EU) och ska tillämpas vid behandling av personuppgifter som sker helt eller delvis automatiskt, samt på personuppgifter som kommer att tillkomma ett, av en organisation tillhandahållet, register. Grunden till denna förordning är att alla medborgare inom EU, oavsett hemvist, ska ha samma grundläggande rättigheter och friheter när det kommer till skydd och hantering av personuppgifter. De principer som enligt Europeiska unionens råd (2016) kommer att gälla framöver för behandling av personuppgifter inom EU är: • Att personuppgifterna ska behandlas på ett lagligt, korrekt och öppet sätt mot den registrerade. • Att den insamlade informationen endast samlas in för ett tydligt och berättigat ändamål samt behandlas i enlighet med detta. • Att om personuppgifter skiljer sig mot ändamål måste radering eller rättning ske utan dröjsmål. • Att personuppgifter ej får behållas under längre tid än vad som krävs för att nå ändamålet. • Att personuppgifter måste behandlas på ett sätt som säkerställer säkerhet. Den personuppgiftsansvarige, det vill säga den part som behandlar personuppgifter, ska ansvara och visa på att de principer som står ovan efterföljs (Europeiska unionens råd, 2016). För att behandlingen av personuppgifter ska anses laglig måste den registrerade i fråga lämnat samtycke om att uppgifterna behandlas för ett eller flera specifika mål. Med GDPR har det tillkommit en del skillnader jämfört med PUL. En av de större skillnaderna är att den registrerade, enligt Datainspektionen (2017), har möjligheten att hämta ut och lämna över datauppgifter. Ytterligare en skillnad är enligt Datainspektionen (2017) att företag kommer behöva göra en bedömning av vilka konsekvenser som kan uppstå vid behandling av personuppgifter, samt vilka åtgärder som krävs för att minska dem. Detta måste ske innan planering av en ny behandling av personuppgifter. Skulle ett företag bryta mot någon av förordningens regler kan Datainspektionen komma att utdöma en sanktionsavgift baserad på hur allvarlig överträdelsen är. 2 , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 1.2 Problemanalys I dagsläget upplever Subsigno svårigheter från det att en kundorder skickas till en sam- arbetspartner, till dess att en orderbekräftelse returneras. En av anledningarna till att problemet uppstår är att det inte finns något gemensamt system mellan Subsigno och deras samarbetspartners. Flertalet samarbetspartners väljer att arbeta i egenutvecklade affärssystem, eftersom de då kan skräddarsy systemet efter egna behov (Magnusson och Nilsson, 2014). Detta medför att informationen som skickas mellan företagen varierar, det är exempelvis kundnummer, personnummer och adress. För att hantera denna variation krävs manuellt arbete från Subsignos sida för att sammanställa en korrekt översikt av färdiga order varje månad. För att kunna göra en rekommendation som är applicerbar och genomförbar för Subsigno är det viktigt att ha kännedom om den nuvarande processen och dess begränsningar. En lösning som skiljer sig avsevärt från dagens förfarande kan försvåra implementationen och kräva annan omorganisation. Därför blir ett delproblem att tidigt i projektets skede skaffa tillräckligt detaljerad kännedom om den process som idag används hos Subsigno. Den ekonomiska hållbarheten är aktuell för projektet i den aspekt att den manuella arbetsbördan är vad som ämnas minimeras, då det skulle innebära att tid kan läggas på mer värdeskapande verksamhet. En annan aspekt är skalbarheten i lösningen. Verksamheten kan med en skalbar lösning expandera utan att arbetsbördan inom hantering av order växer i samma, eller till och med i högre, takt. En mer automatiserad process är dessutom tänkt att föra med sig mindre utrymme för fel, vilket ytterligare stärker en hållbar expansion. Ett annat delproblem som måste utredas är vilka faktorer som påverkar skalbarheten och hållbarheten i lösningen. För att kunna ta hänsyn till samt integrera dessa på bästa möjliga sätt i det slutliga processkonceptet måste faktorerna identifieras. Kommunikationen av affärsinformation är viktig mellan fintech-bolaget och samarbetspart- nerna i det avseende att det fungerar som underlag i fortsatta processer hos respektive part. Därför är det centralt att även beakta samarbetspartnernas inverkan på problemet. Detta är viktigt för att säkerställa goda möjligheter till fortsatt samarbete i framtiden, som inte bör påverkas negativt av det processkoncept som i detta projekt utvecklas för Subsigno. Därför blir ytterligare ett delproblem att skaffa förståelse för hur samarbetspartnerna sammanställer orderbekräftelserna innan de skickas till Subsigno. Någon typ av systemintegration skulle kunna vara aktuell för att överbrygga problemet med att de fristående systemen måste vara kompatibla med varandra. Systemet behöver kunna skicka information automatiskt utan manuell inmatning och kontroll. De olika systemens gränssnitt måste även kunna fungera tillsammans. En sammankoppling av system leder till att tid, såsom administrativt arbete, minskas samt en begränsning av den mänskliga faktorns inverkan på verksamheten. Således leder en systemintegration till att värde tillförs genom att en effektivisering av arbetet sker för både Subsigno och deras samarbetspartners. 1.3 Syfte Syftet med projektet är att analysera Subsignos nuvarande rutin för hantering och uppföljning av orderinformation för att sedan ta fram ett genomförbart processkoncept som minskar , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 3 manuell arbetsbörda och är skalbar vid expansion av verksamheten. 1.4 Frågeställningar Utifrån projektets syfte, de problem som Subsigno beskriver samt problemanalysen, formu- lerades frågeställning 1. Frågeställning 2-5 formulerades för att tillsammans hjälpa till att besvara den första frågeställningen. Nedan presenteras samtliga frågeställningar: 1. Hur kan det manuella arbetet minskas på ett skalbart, hållbart och genomförbart sätt vid framtagning av orderinformation för Subsigno? 2. Hur ser Subsignos nuvarande processer och rutiner för överföring av orderinformation ut? 3. Vilka faktorer är viktiga för skalbarhet av en sådan process? 4. Vilka teknologier finns för att integrera olika affärssystem med varandra? 5. Hur ser Subsignos samarbetspartners rutiner ut, samt vilka möjligheter och begräns- ningar har de att ändra sina rutiner kring orderbekräftelser? 1.5 Avgränsningar För att konkretisera och avgränsa omfånget av arbetet i denna rapport har flertalet av- gränsningar gjorts. Dessa presenteras nedan. • Processen som tagits fram avgränsas till att endast vara på konceptnivå och inte en färdig lösning. Detta eftersom problemet är av komplex karaktär och en färdig lösning ej efterfrågas av Subsigno. Processkonceptet som presenteras ska däremot gå att implementeras av Subsigno i framtiden. • Problemet avgränsas till att förbättra processen för sammanställning av orderbekräf- telser och behandlar inte antalet kundorder som faktiskt går igenom, så kallad hit rate. Detta för att en ökad hit rate behandlar andra aspekter, såsom försäljning och tjänstens värdeerbjudande, som faller utanför projektets syfte. • Projektets fokus ligger på att presentera ett mer generaliserat och anpassningsbart processkoncept snarare än en detaljerad och mycket specifik lösning. Detta för att säkerhetsställa att alla personer involverade i en eventuell implementation av processen kan tolka och förstå konceptet, samt att utrymme lämnas för praktiska anpassningar. • Projektet fokuserar på att lösa Subsignos specifika problem och inte ge en generell lösning som är applicerbar på andra liknande företag. Således är det mest centralt att hitta en lösning som i så stor utsträckning som möjligt tillgodoser behoven som finns hos Subsigno idag. 4 , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 • Antalet samarbetspartners som involveras i projektet avgränsas till tre stycken och valdes ut i samråd med kontaktperson på Subsigno. Dessa tre företag ansågs av kontaktpersonen på Subsigno vara representativa för alla de samarbetspartner som de totalt sett har. • Processen som den såg ut för Subsigno och deras samarbetspartners vid första inter- vjutillfället ligger till grund för kartläggningen. Hänsyn tas alltså ej till eventuella förändringar av processen som kan ha skett under projektets gång vid utformningen av processkoncept. , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 5 2 Teori Med hjälp av relevant litteratur redogörs i detta kapitel begrepp och ämnesområden som ämnar ge förståelse för projektets fortskridning och referensram. Teoretiskt fokus har legat på processer, interorganisatoriska system samt olika teknologier som kan användas för att integrera olika affärssystem. 2.1 Business Process Management (BPM) En process, som i detta fallet och framåt syftar på engelskans ”business process”, definieras vanligtvis inom managementlitteraturen som en samling länkade steg, aktiviteter och uppgifter som tillsammans skapar en organisatorisk output eller en produkt (Yu, Pelaez och Lang, 2016). Business Process Management (BPM) syftar, enligt Afflerbach, Hohendorf och Manderscheid (2017), till att hantera organisatorisk prestation, regelefterlevnad och servicekvalité genom att övervaka alla processer inom en organisation. De understryker även vikten av att BPM kombinerar viktiga kunskaper inom IT och management för att optimera process-output. Dumas, Rosa, Mendling och Reijers (2013) sammanfattar BPM som ”the art and science of overseeing how work is performed [. . . ] to ensure consistent outcomes and to take advantage of improvement opportunities”. Aysolmaz m. fl. (2018) konstaterar att de största fördelarna med BPM är effektivitet och agilitet. Effektivitet uppfylls enligt denna studie genom att omarbeta och automatisera de processer som anses resursmässigt försvarbara. Agilitet definieras generellt som förmågan att anpassa sig till omvärlden och uppfylls enligt studien genom att BPM konstant utvärderar och vid behov uppdaterar alla processer i en organisation. Förmågan att kunna agera allt mer agilt poängterar Aysolmaz m. fl. (2018) vara fundamental i dagens samhälle med hög utvecklingstakt och osäker framtid. 2.2 Möjlighet att få till ett interorganisatoriskt sy- stem (IOS) Interorganisatoriska system (IOS) definieras som system som gör det möjligt för företag att dela information och bedriva affärer över organisationsgränser (Boonstra och de Vries, 2005). Den problematik som kan uppstå då företag arbetar med att utveckla interorganisatoriska processer eller system grundar sig bland annat i maktfördelning mellan aktörer samt intresset i att vara delaktig i att utveckla en sådan lösning. Lempinen, Rossi och Tuunainen (2012) anser det därför centralt att i utformningen av processer eller system inkludera de externa användarna, som i detta fallet syftar på aktörer utanför det egna företaget som potentiellt kommer att använda systemet. 6 , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 Intresset för att vara delaktig i ett nytt, interorganisatoriskt system beror på de strategiska och/eller ekonomiska fördelar som de externa användarna ser. Intresse definieras i detta avseende som självupplevt intresse, oavsett om systemet faktiskt kan realiseras eller ej (Boonstra och de Vries, 2005). Ett lågt intresse indikerar att den externa användaren väntar sig nackdelar från att involvera sig i en sådan lösning, exempelvis i form av förhöjda operationella kostnader. Ett stort intresse indikerar däremot att den externa användaren ser fördelar som kan bidra till företagets övergripande mål. Således kan graden av involvering och visat intresse vara ett tecken på hur mycket de externa användarna ser sig kunna gagnas av ett sådant system och därmed även värdet i själva systemet (Lempinen m. fl., 2012). Maktfördelningen mellan de aktörer som är tänkt att använda det interorganisatoriska systemet kan definieras som förmågan att utöva inflytande över andra aktörers intressen för att uppnå fördelar (Boonstra och de Vries, 2005). Hur denna fördelning ser ut kan påverka möjligheten att implementera systemet och dess tillhörande process. Att en organi- sation väljer att adoptera ett system kan vara resultatet av både formella och informella påtryckningar från andra aktörer som den är beroende av. Om en av dessa är en stor och inflytelserik aktör kan denna få den andre att adoptera systemet, oavsett dess individuella intresse i att göra så (Lempinen m. fl., 2012). Genom att kategorisera aktörer baserat på deras maktposition och intresse i en 2x2 - matris kan tio olika arketyper identifieras. Dessa kan därefter delas in i tre olika grupper, som talar för hur troligt att ett samarbete genom ett interorganisatoriskt system skulle kunna skapas (Boonstra och de Vries, 2005). Arketyperna samt grupperingarna illustreras i Figur 2.1. Figur 2.1: Bilden illustrerar Boonstra och de Vries (2005) olika arketyper i en 2x2 - matris, samt gruppering av dessa. Boonstra och de Vries definierar de olika arketyperna enligt följande: 1. Båda aktörer har lågt intresse och makt för att implementera ett interorganisatoriskt system. , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 7 2. Båda aktörer har ett lågt intresse, men stor makt för att implementera ett interorga- nisatoriskt system. 3. Båda aktörer har ett lågt intresse för att implementera ett interorganisatoriskt system och ojämn maktfördelning. 4. Båda aktörer har ett starkt intresse och makt att implementera ett interorganisatoriskt system. 5. Båda aktörer har ett högt intresse för att implementera ett interorganisatoriskt system, men låg maktställning. 6. Båda aktörer har ett högt intresse för att implementera ett interorganisatoriskt system, men ojämn maktfördelning. 7. En aktör med stort intresse och makt dominerar en annan aktör med lågt intresse och makt. 8. Aktörerna har en ojämn intressefördelning samt låg makt för att implementera ett interorganisatoriskt system. 9. Aktören har högt intresse och låg makt och den andra har lågt intresse men hög makt. 10. Aktörerna har en ojämn intressefördelning, men båda har en hög maktställning. Vidare grupperar de arketyperna enligt följande: 1-3: Osannolikt att ett interorganisatoriskt system kan skapas, eftersom båda parter uttrycker ett lågt intresse för att få till en sådan lösning. 4-6: Troligt att ett interorganisatoriskt system kan utvecklas. 7-10: Denna kategori innehåller mer komplicerade arketyper, vilket gör att olika utfall kan förekomma. För typ 7 kan exempelvis den aktör med högre maktställning tvinga den andre till att använda systemet. Typ 8 kräver istället mer påhittighet av den intresserade parten, eftersom båda parter har en låg maktställning. 2.3 Skalbarhet Skalbarhet definieras enligt Bondi (2000), som förmågan för ett system, nätverk eller process att hantera en ökad mängd arbete alternativt förmågan att utökas för att klara av den ökade belastningen. Termen kommer ursprungligen från Informationsteknologi (IT) men används alltmer inom Operations Management. Skalbarhet förknippas ofta med långsiktighet eftersom definitionen förutsätter en förändring över tid som processen ska klara av att hantera. Skalbarhet är ofta nödvändig i flera dimensioner där de två vanligaste är horisontell och vertikal skalbarhet. Den horisontella dimensionen innebär förmågan att lägga till ytterligare tjänster eller funktioner med bibehållen input utan att processtiden blir oproportionellt högre. Den vertikala dimensionen fungerar på samma sätt men med bibehållet antal funktioner och ökad input utan ökade processtider. 8 , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 För att enklare analysera skalbarheten av en process och möjligheten till expansion föreslår Molinari och Concilio (2016) att sju dimensioner studeras: • Kontext: Geografiska eller kulturella aspekter som påverkar beroende på var processen används först. • Typ: Processens karaktär; inkrementell, radikal eller disruptiv. • Mål: Vad det är som ska skalas upp; processens omfattning, antalet aktörer eller ett helt nytt sammanhang. • Form: Hur uppskalningen sker; endast genom processägaren, genom informella sam- arbeten, med andra entiteter eller genom formella eller planerade handlingar. • Lärande: Sättet som lärande påverkar skalbarheten genom möjliggörande och pådri- vande. • Ägandeskap - Vem hanterar och startar skalprocessen. • Infrastruktur: Rollen IT har i processen. Skalbarhet är, enligt Bondi (2000), nödvändig för alla processer i ett företag som vill växa. När en process når sin maximala kapacitet och inte längre kan utökas begränsas företaget om inte processen görs om. En process anses som icke-skalbar om kostnaden för en ökning av input anses högre än det tillförda värdet. Kostnaden kan både vara tid, utrymme eller pengar. Processer som inte är skalbara adderar ofta arbetstidskostnader, skadar kvalitén på service och kan hindra nya inkomstmöjligheter (Bondi, 2000). 2.4 Enterprise Resource Planning (ERP) Enligt Jagoda och Samaranayake (2016) är ERP-system affärsprogramvarupaket som gör att organisationer kan: • Integrera sina affärsfunktioner (försäljning, produktion, mänskliga resurser, inköp, etc.). • Dela gemensam data, information och kunskap över hela företaget. • Automatisera kritiska delar av sina affärsprocesser. • Generera och få tillgång till information i realtidsmiljö med hjälp av en enda databas. Enligt Huang (2016) är ett av de viktigaste målen för ERP-system att bygga en gemensam plattform för organisationer och integrera affärsprocesser. Denna plattform behandlar information, data och order vilket gör att aktiviteterna fortlöper effektivt. Vid behov kan ytterligare applikationer och system installeras och anpassas för olika syften (Huang, 2016). Integriteten hos den gemensamma plattformen kan då skadas om inte prestandan utvärderas och följer teknikutvecklingen, vilket kan leda till att motsvarande fördelar också försvinner. , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 9 2.4.1 Trender Huang (2016) har analyserat fyrtio fallstudier i Japan relaterade till ERP-system som visar att allt från små till stora företag har upplevt försämringar gällande systemprestanda och affärsutveckling. Detta som en följd av interna och externa miljövariationer, utveckling av teknik samt svårigheten att behålla fördelar av teknologisk innovation. Försämringarna gör att företag har ett behov av att uppgradera eller avveckla det nuvarande ERP-systemet (Huang, 2016). Huang (2016) identifierar tio nyckeltrender inom ERP, varav en av dem är Software as a Service (SaaS). SaaS innebär att mjukvaran inte installeras på en lokal enhet, utan nås istället via molnet (Plunkett Research, 2015). Vidare identifierar Huang (2016) i sin forskning att traditionella ERP-system har blivit allt mer påverkade av framväxande informationsteknik, såsom molntjänster och sociala medier. En undersökning som genomfördes år 2013 av Gartner-koncernen, världens ledande företag inom IT-forskning och rådgivning, visar att 47 % av Gartners egna kunder i undersökningen planerade att flytta sina affärssystem till molnbaserade system de närmaste fem åren. Även en övergång till SaaS beskrevs vara oundviklig (Huang, 2016). 2.4.2 Integration med tredjepart Interna relationer innebär relationer mellan avdelningar och divisioner inom företag medan externa relationer är relationer med användare och samarbetspartners (Mena, Humphries och Wilding, 2009). Externa relationer syftar på organisationer som är sammankopplade till externa enheter som affärssystemsleverantörer, konsulter och organisationer i leveran- törskedjan. Huang (2016) poängterar att det då kan behövas stöd från tredjepart, vilket kan ses som en kritisk faktor i integration av affärssystem. Tredjeparter kan tillföra värde genom serviceförmåga inom relaterade områden som erfarenhet, teknik, resurs och arbets- kraft. Möjligheten att samarbeta med andra organisationer är en typ av investering. Om organisationen har planer på att expandera till marknader utanför landet är utländskt stöd i ERP-systemet även viktigt att tänka på (Huang, 2016). Ytterligare ett sätt att samarbeta mellan företag är att använda sig av en integrationsplatt- form (Huang, 2016). Plattformen möjliggör då företagsintegrering med handelspartner eller integrering mellan avdelningar i större företag genom att dela information mellan olika system. Ett exempel på detta är den som tillhandahålls av Ironside Technologies (2002), som möjliggör automatisering av affärsprocesser och tillåter företag att handla med kunder och leverantörer i realtid genom en webbläsare. 2.4.3 Implementering av affärssystem En metod för implementering av affärssystem utgörs av att aktiviteter genomförs och utvärderas i varje steg innan nästa steg tas. Det leder till en identifiering av vilka kritiska aktiviteter som behöver slutföras i varje steg, innan ytterligare resurser tillförs. Om verksam- heten inte genomfört de kritiska aktiviteterna till en tillfredsställande nivå kan nödvändiga justeringar eller korrigeringar göras. Det bör dock noteras att det inte är nödvändigt att implementera systemet i alla avdelningar eller funktionella områden, utan det kan även implementeras av enskilda moduler (Jagoda och Samaranayake, 2016). 10 , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 Jagoda och Samaranayake (2016) menar vidare att systemimplementering ofta kräver förändringar av organisationsstrukturen. En viktig del är att ha stöd från högsta ledningen, mer specifikt stöd i form av engagemang och kommunikation. Dessutom behövs en effektiv verkställande ledning för att små och medelstora företag ska uppnå framgång i genomförandet. Arbetstagarnas attityder anses även vara en nyckelfaktor för att bestämma framgång eller misslyckande för genomförandet. Att identifiera bristen på lämplig kultur och organisatorisk (intern) beredskap kan också ses som en betydande faktor som bidrar till ett framgångsrikt genomförande (Jagoda och Samaranayake, 2016). 2.4.4 Problem vid implementering Under de senaste två decennierna har många organisationer implementerat affärssystem med tillhörande operationell process inom olika branscher och av skilda anledningar. Det finns dock flera svårigheter med att implementera nya IT-system och dess tillhörande process me- nar Jagoda och Samaranayake (2016). Faktorer som att projektgrupperna enbart består utav IT-personal i organisationen, att misslyckanden sker utanför implementeringscykeln och att implementeringscykeln själv saknar utvärdering och övervakning av framsteg under genom- förandet bidrar till förlorade intäkter och misslyckanden. För att öka framgångsnivån bör projektgrupperna även innefatta företags- och ledningspersonal (Jagoda och Samaranayake, 2016). 2.5 Application Programming Interface (API) För att överbrygga kommunikationsgap kan företag använda sig av så kallade API:er. Ett API är ett gränssnitt som tillhandahålls av ett mjukvarusystem och exponerar vissa tjänster för externa applikationer. Det kan således möjliggöra att företag via sina affärssystem både kan hämta och dela med sig av information. Det finns olika typer av lösningar vilka Boyd (2014) delar in i tre kategorier; privata respektive öppna API:er, samt de som är exklusiva för partnerskap. Eftersom värde i B2B-verksamhet skapas genom ett samarbete efterfrågas ofta partnerskap i dessa fall. Boyd (2014) påpekar dock att det är viktigt att sammanställa en kravspecifikation innan ett API delas med en annan part. Denna kravspecifikation bör vidare innehålla hur den andra parten planerar att använda gränssnittet samt vilken data parten förväntar sig ha tillgång till. Iyer och Wyner (2012) diskuterar olika utmaningar som finns gällande utveckling och utvärdering av API:er. Utvecklingen av ett bra API hävdas vara en komplicerad process, efter vilken en utvärdering är svår att göra eftersom värdet ligger i det som skapas utifrån API:et. Liksom Boyd (2014) nämner är det viktigt att skapa en tydlig problembild innan utveckling påbörjas. Iyer och Wyner (2012) har skapat en modell för de intressenter som är inblandade och de sammanfattas kort nedan. • Ägare: Ägaren är intresserad av att ha en optimal affärsmodell. En bra sådan beskriver värdet i företaget, hur det skapas och levereras. Detta innebär att ägaren måste veta vilka tillgångar företaget har, hur dessa ska kombineras och vilka som behöver API:er. , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 11 • Arkitekt: Det är denna intressent som står för design av företagets API. Denna bör avgöra vilka tjänster som bör erbjudas och vad ett API som lösning innebär för fördelar och nackdelar. • Utvecklare: Utvecklaren utgår från den design som arkitekten skapat och imple- menterar detta i kod. I rollen ingår det även att undersöka vilken detaljeringsgrad koden bör ha samt att också planera tidsåtgång och kostnad för implementationen. Detta inkluderar om kompetens bör anskaffas samt eventuella inköp av produkter eller verktyg. • Slutanvändare: Denna part sitter på andra sidan av ett API för att utföra sina arbetsuppgifter. Detta åstadkoms genom att utbyta information från ett företag till ett annat. 2.6 File Transfer Protocol (FTP) File Transfer Protocol (FTP) skapades i syftet att enkelt kunna lagra och föra vidare filer mellan datorer direkt i terminalen, men används primärt i olika datorprogram. Filerna skickas genom att laddas upp till en server av avsändaren och hämtas från samma server av mottagaren. Primärt används FTP-server för textfiler och har fått mycket kritik för att filerna inte krypteras. Därav kan känslig information, så som exempelvis lösenord eller användaruppgifter, enkelt nås av obehöriga vid överföringen. Detta har lett till att Secure File Transfer Protocol (SFTP) har utvecklats (Postel och Reynolds, 1985). SFTP utökar enligt Garais och Enaceanu (2016) funktionaliteten av FTP genom att enkryptera filerna så att de kan delas säkrare mellan olika klienter. Trots att funktionen hos SFTP i många aspekter liknar FTPs funktion gör skillnaden i enkrypteringen att en FTP-server vanligtvis inte kan kopplas samman till en SFTP-server (Garais och Enaceanu, 2016). 2.7 Sammanfattande analytiskt ramverk Teorin kring BPM kan appliceras under kartläggningen av den process för hanteringen av orderinformation som Subsigno har idag genom att se denna som ett processflöde. Därmed skapar teorin ett ramverk för hur processen hos Subsigno kan beaktas och struktureras, vilket i sin tur bidrar till att uppfylla den del av syftet som handlar om att kartlägga Subsignos nuvarande process. Vidare tyder denna teori på att en kombination av IT och management är viktiga för att skapa effektivitet i processen. En ökad effektivitet kan minska mängden manuellt arbete i en process, varvid detta blir relevant för att uppfylla den del av projektet som syftar till att minska den manuella arbetsbördan. Anpassningar till omvärlden som Aysolmaz m. fl. (2018) beskriver är nödvändiga vid skalbara processer och expansionen av verksamheten. Detta är relevant i projektet, då det syftar till att skapa ett processkoncept som är både skalbart och hållbart vid expansion. Teorin kring skalbarhet bidrar med begrepp och synsätt som sätter ramen för hur projektet kommer att 12 , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 förhålla sig till området, samt dimensioner för hur skalbarheten i det nya processkonceptet kan förbättras. För att möjliggöra en integration med tredjepart och externa enheter behövs stöd från en effektiv integrationslösning. I enlighet med expansion både internationellt och nationellt är fenomenet skalbarhet därför väsentligt. Olikartade, fristående system ska hanteras i infrastrukturen och fungera med den miljö som Subsigno har. Dessutom ska nuvarande och framtida samarbetspartners kunna integreras i Subsignos system och skalas upp i volym utan att det kräver ytterligare resurser. Kombinationen av teori kring integration med tredjepart och skalbarhet blir därför central i detta projekt. För att kunna uppfylla den del av syftet som handlar om att ta fram ett processkoncept som minskar manuellt arbete är teori kring automatiserade integrationslösningar såsom ERP- system, API, FTP, Software as a Service (SaaS) och integrationsplattformar relevant. Dessa teknologier är speciellt intressanta att beakta eftersom de till stor del kan automatiseras och är vanligt förekommande inom relevant teori. Att dessa teknologier är automatiserade lösningar är dessutom en förutsättning för att uppnå effektivitet i processen, enligt teorin kring BPM. Genom dessa teknologier kan projektets syfte att minska det manuella arbetet därför uppfyllas. Baserat på de olika teknologiernas egenskaper kan lämpligheten i den nya orderhanterings- processen avgöras tillsammans med teori kring möjligheten att få till ett interorganisatoriskt system, som Boonstra och de Vries (2005) beskriver. Teorin som författarna beskriver går att applicera i projektet för att avgöra lämpligheten av att implementera exempelvis ett API. Vidare appliceras teori kring en lyckad implementation av affärssystem tillsammans med den slutliga rekommendationen för att säkerställa en lyckad implementation och därmed värdet av rekommendationen. Exempelvis tyder teorin på att arbetstagarnas attityd till det nya systemet är viktigt för att säkerställa framgång i implementeringen. Detta uppnås specifikt för små till medelstora företag, däribland Subsigno, genom en starkt verkställande ledning. Vidare identifierar teorin historiska problemområden vid implementering av affärssystem som kan vara värda att uppmärksamma i slutrekommendationen för att säkerställa en lyckad implementation. Det bidrar ytterligare till att syftet att skapa en genomförbar lösning uppfylls. Figur 2.2: Figuren visar hur teorin appliceras i projektet. , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 13 3 Metod Nedan beskrivs de metoder som använts inom projektet samt hur genomförandet har sett ut. För att få en bra struktur inom arbetet har de principiella steg som används av Gregor och Hevner (2013) vid utformning av en process efterföljts. För att ytterligare strukturera upp arbetet har arbetsprocessen delats in i fyra olika faser, se figur 3.1. Vilka av Gregor och Hevner (2013)s principiella steg som inkluderas i vilken fas, samt hur de olika stegen har applicerats i arbetets genomförande presenteras nedan. • Identifiera problem - Hanteras i Fas 1. • Identifiera lösningsmål - Hanteras i Fas 1 och Fas 2. • Design och utveckling - Utförs initialt i Fas 3 och fortsätter in i Fas 4. • Demonstration - Hanteras i Fas 4, då processkonceptet visas för första gången. • Utvärdering - Utförs i Fas 4 genom testning och feedback. • Kommunikation -XFDOCK Genomförs genom denna rapport, samt under presen- tation, poster och pressrelease. Figur 3.1: Flödesschema av de olika faserna i projektets genomförande. Vidare har ett abduktivt förhållningssätt använts genom alla faser då arbetet kontinuerligt kompletterats med ny empiri och relevant teori längs vägen (Dubois och Gadde, 2002). 14 , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 3.1 Fas 1: Explorativa undersökningar Första momentet var en explorativ fas som syftade till att undersöka den process som Subsigno använde sig av vid tillfället för kartläggningen och därmed besvara frågeställning 2, 5 samt delvis 3. Fasen syftade även till att skapa en fullständig identifiering av problemet. Kartläggningen av processen följde Yu m. fl. (2016) definition, som beskrivs under Business Process Management (BPM). För att säkerställa den slutliga rekommendationens hållbarhet och skalbarhet syftade denna fas även till att utforska processen ur tre av Subsignos samarbetspartners perspektiv. Denna explorativa fas samlade endast in primärdata genom intervjuer. Blomkvist och Hallin (2015) menar att om en djupare förståelse för ett fenomen eftersöks bör intervjuer genomföras, varvid denna metodik valdes. Intervjuerna var av semi-strukturerad karaktär där intervjuobjekten fick se frågorna på förhand. Detta för att effektivisera och optimera intervjutillfällena, samt för att få en så heltäckande och nyanserad bild av processen som möjligt. Från Subsigno intervjuades berörda personer med kännedom om den nuvarande processen och dess användning. De samarbetspartners till Subsigno som intervjuades valdes i största möjliga mån med hänsyn till olika branscher och storlekar, för att fånga upp de olika branschstandarder och arbetssätt som eventuellt förekommer. De valdes även baserat på förväntad framtida relevans för Subsigno, exempelvis om de är närvarande på andra marknader som Subsigno i framtiden kan komma att expandera till. Därmed beaktades de perspektiv som i framtiden potentiellt var av större betydelse för processen och följaktligen mest avlastande med avseende på manuellt arbete. Då de tillfrågade är samarbetspartners till Subsigno antogs det finnas incitament till att engagera sig i förbättringsarbetet av de kontaktytor de har gentemot Subsigno. Det slutliga valet av personer från de samarbetspartners som intervjuades gjordes dock av kontaktperson från Subsigno med hänsyn till ovan nämnda kriterier. Detta eftersom Subsigno redan hade kontakt med relevanta individer, samt i större grad kunde hänvisa till rätt person. Eftersom projektet avgränsades till att enbart beakta tre av alla samarbetspartners fanns ett intresse av att ta del av vilka lösningar som användes av de övriga samarbetspartnerna, då detta kunde få konsekvenser för skalbarheten i det nya processkonceptet. Därför gjordes ett antagande om vilka kommunikationslösningar den resterande marknaden har utifrån resultatet från intervjuerna och i samråd med insatt kontaktperson från Subsigno, se avsnitt Sammanställning av övriga samarbetspartners. Frågorna i intervjuerna var av den karaktär som besvarar ”Hur” och ”Varför”. För specifi- kation av frågor till Subsigno samt deras samarbetspartners, se Bilaga A och B. För att dessutom undvika bias från författarna gjordes intervjusammanfattningar efter respektive intervju som sedan skickades till den intervjuade. Denne fick då bekräfta eller dementera det innehåll som författarna påstår ha behandlats under intervjun. , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 15 3.2 Fas 2: Teoretisk analys Denna fas bestod av en teoretisk analys som syftade till att kartlägga vad litteraturen och teorin säger om liknande företeelser som det problem som identifierats under rubriken Problemanalys, samt dess eventuella lösningar. Denna litteraturstudie utfördes efter Fas 1 för att mer fokuserat kunna hitta relevant litteratur, vilket underlättades av kännedom om processen som Subsigno använder sig av. Resultatet från denna fas bidrog till att identifiera lösningsmålen, samt den slutliga rekommendationen genom att besvara frågeställning 3 och 4. Den information som användes var sekundärdata i form av litteratur som bestod av ve- tenskapliga publikationer samt böcker för att garantera trovärdighet. De webbkällor som användes var främst statistiska databaser samt webbsidor med myndigheter som utgivare. Fåtalet undantag gjordes för bland annat teori om FTP och en pressrelease från Ironside Technologies (2002) med flera. En avgränsning i litteraturen rörande affärssystem gjordes baserat på att utvecklingen av affärssystem tenderat minska i sitt funktionella omfång från år 2000 till cirka 2010 (Magnusson och Nilsson, 2014). Därmed fanns risken att de affärssystem som beskrivs i litteraturen skriven flera år innan år 2010 skiljer sig från dagens. Därför användes endast publikationer publicerade efter år 2009, om de rör ämnesområdet affärssystem. De vetenskapliga publikationerna har genererats via sökmotorn Summon som tillhandahålls av Chalmers tekniska högskolas bibliotek. 3.3 Fas 3: Problemlösning I denna fas gjordes första ansatsen till att ta fram ett första processkoncept, med hänsyn till resultatet från Fas 1 och Fas 2. För att få en inblick i vilka möjligheter och restriktioner det fanns vid utveckling av processkoncept och därigenom vägledning tillämpades matrisen av Boonstra och de Vries (2005). De samarbetspartners som tidigare intervjuades i Fas 1 användes i ramverket, där de fick positionera sig på en tvågradigskala i termer av makt respektive intresse för ett interorganisatoriskt system enligt de definitioner som specificeras under kapitlet Teori. Den enkät som använts till detta kan hittas i appendix C. I slutet av fasen utarbetades det första processkonceptet tillsammans med två så kallade ”dummy-koncept”, vars syfte var att ge kontrast i egenskaper gentemot det faktiska konceptet. 3.4 Fas 4: Hypotetisk-deduktiv testning Denna fas syftade till att testa och förfina de processkoncept som utarbetades i Fas 3 genom en hypotetisk-deduktiv metodik, där processkoncepten tjänade som hypotes. Detta innebar att den kunskap och kännedom som samlades in under Fas 1 och Fas 2 testades empiriskt (Wallén, 1996). Testningen genomfördes i tre iterationer för att kunna bedöma och förbättra processens applicerbarhet. En iteration innefattade testning av processkoncepten, analys av resultatet samt utformning av nya koncept. Resultatet för denna fas ämnade därmed besvara frågeställning 1. 16 , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 Testerna i den första iterationen utfördes genom att låta samma personer som intervjuades i Fas 1 rangordna de tre olika beskrivningar av processkoncepten som utarbetades under Fas 3. Testpersonen fick sedan förklara och motivera sin rangordning av processkoncepten. Testmetoden valdes för att få en bättre förståelse för viktiga avvägningar mellan processens egenskaper. Genom att testpersonen fick rangordna processkoncepten med olika egenskaper, samt ge förklaring till rangordningen, kunde preferenser för viktiga egenskaper identifieras. Denna metod valdes även då den i större grad säkerställde att värdefull och entydig feedback erhölls, än vid jämförelsevis rena intervjuer (Wallén, 1996). En påtaglig svårighet med att använda rena intervjuer som testmetod är att formulera frågor som tar fram relevanta synpunkter från testpersonen och därmed finns risk att metoden inte ger förväntat resultat. Vid den andra iterationen utformades nya koncept baserat på resultatet av den första iterationen. Istället för att fokusera på hela processförloppet likt iteration 1 fokuserades det i iteration 2 på de enskilda stegen vid överföring av information. Efter den andra iterationen genomfördes ytterligare en iteration som förfinade konceptet till dess slutgiltiga form. Detta koncept validerades hos en samarbetspartner som inte tidigare varit med under under projektet för att undvika konfirmeringsbias. , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 17 4 Resultat I resultatet sammanställs nuvarande process för hantering av orderinformation hos Subsigno och hur arbetet med deras samarbetspartners fungerar. Vidare identifieras problemområden inom olika delar av samma process. Resultatet från undersökningen av möjligheten att få till ett interorganisatoriskt system presenteras dessutom. Utifrån detta formuleras en sammanfattning av förutsättningar för det nya konceptet. 4.1 Kartläggning av Subsigno I Figur 4.1 visas flödet hos Subsigno från det att en användare av applikationen lägger en order tills det att en samarbetspartner faktureras. Därefter följer även en kort beskrivning av de olika stegens innebörd. Figur 4.1: Flödesschema av Subsignos process för överföring av kundorderinformation. Steg 1 Flödet börjar med att en användare placerar en order i Subsignos applikation, innehållande all nödvändig orderinformation samt fullmakt. Gemensamt för samtliga ordrar är att ett unikt order-ID genereras i Subsignos affärssystem, som verkar som en unik nyckel i den interna processen. 18 , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 Samtliga order skickas sedan vidare till samarbetspartnern på något av följande sätt: • SFTP-server: I detta fall tillhandahåller Subsigno eller samarbetspartnern en så kallad SFTP-server, se kapitel File Transfer Protocol (FTP). Via denna server skickas information om kundorder till samarbetspartnern. • API: Genom en API-anslutning kan bolaget skicka orderinformationen direkt till samarbetspartnerns affärssystem. Ett API verkar i detta fall som en förenklad och begränsad vy av affärssystemet som tillåter Subsigno att enbart redigera den aktuella informationen om en order, utan att få tillgång till samarbetspartnerns övriga data. För vidare beskrivning, se delkapitel Application Programming Interface (API). Genom båda kanalerna delas den orderinformation som krävs för att samarbetspartnern ska kunna genomföra användarens begäran i applikationen. Steg 2 I steg 2 har samarbetspartnerna fått all information som de behöver för att kunna börja genomföra användarens begäran. Om samarbetspartnern är en mobiloperatör kan denna typ av information röra sig om mobilnummer, personnummer samt vilken typ av abonnemang och telefon kunden vill ha. Gäller det istället elnät är adress relevant för att genomföra ordern. Notera att Subsignos interna order-ID i de flesta fall inte skickas med här. För samarbetspartnerna fungerar Subsigno i detta steg som en vanlig återförsäljare. I de flesta fall är det möjligt att direkt registrera den nya kunden i samarbetspartnerns affärssystem. Därefter går processen vidare på samma sätt som för alla samarbetspartners kunder med orderbekräftelse, produktleverans, fakturering etc. Subsigno har då genererat en ny potentiell kund. Vid oväntade företeelser kan Subsigno manuellt behöva komplettera ordern med saknad information som vid skapandet av ordern inte fanns tillgänglig hos Subsigno. Detta leder till att steget tar längre tid än vanligt. Därtill kan en order dras tillbaka av kunden via Subsignos applikation, vilket leder till att Subsigno får kontakta samarbetspartnern och åtgärda detta. Steg 3 I detta steg skapar samarbetspartnern en sammanställning innehållande information med utfallet för de potentiella kunder Subsigno förmedlat. Gemensamt för samtliga rapporter är att det innehåller olika mängd information, i olika format och av varierande kvalitet. Detta skapar tidvis mycket manuellt arbete för bolaget. Sammanställningen görs godtyckligt många gånger i månaden, skickas iväg och hamnar tillslut i en molnbaserad lagringstjänst som tillhandahålls av Subsigno. Steg 4 För att minimera fel som kan uppstå vid sammanställningen av samtliga order från alla samarbetspartners använder sig bolaget av ett script som hämtar alla mottagna filer och matchar dessa mot kompletterande information från bolagets interna affärssystem. Detta , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 19 görs baserat på olika kriterier, beroende på vilken samarbetspartner informationen kommer ifrån. Gemensamt för alla rapportfiler är att de saknar det unika order-ID som orderna fick i samband med att de skapades i Subsignos interna affärssystem. Matchningen sker för att säkerställa att varje order återfår sitt unika order-ID som ligger till grund för att bolaget ska uppdatera rätt order med rätt utfall. Scriptet matchar, vid tiden för kartläggningen, till 98 % korrekt där resterande order får hanteras manuellt. Steg 5 I steg 5 uppdateras statusen manuellt för respektive order i Subsignos affärssystem, där rad för rad matchas och uppdateras. Tidsåtgången i detta steg är proportionell mot antalet kundorder som behöver uppdateras. Steg 6 Efter uppdatering av Subsignos affärssystem i steg fem exporteras ett fakturaunderlag som sedan förs in i bolagets ekonomisystem, därifrån skickas sedan fakturor till samarbetspart- ners. Problemområden Utifrån det processflöde som beskrivs under rubriken Kartläggning av Subsigno kan följande problem identifieras: • Filen som skickas från Subsigno till samarbetspartnern i steg 1 har ingen koppling till filen som skickas tillbaka till Subsigno i steg 3. Detta gör att samma order behöver kopplas till olika typer av information. • Subsigno hanterar kundservice som tjänst. De har dock inte tillgång direkt till sam- arbetspartnernas system. Detta leder till längre kontaktvägar mellan slutkund och samarbetspartner och ibland dubbelarbete. Därför skulle det krävas mer personal hos Subsigno för att skala upp. • Det tar olika lång tid för samarbetspartnerna att genomföra kundens beställning i steg 2. Ibland har de inte hunnit behandla ordern, så status i samarbetspartnernas system förblir oförändrad. Subsigno har då ingen inblick i varför statusen är oförändrad. • Flertalet personuppgifter behöver skickas mellan samarbetspartnern och Subsigno i steg 3. Detta kan potentiellt utgöra en säkerhetsrisk. • Utrymmet för mänskligt fel är stort i steg 5 då matchningen sker manuellt. Steget tar i förhållande lång tid och utgör även ett hinder för att kunna hantera en större volym. 4.2 Kartläggning av liten teleoperatör Nedan följer en beskrivning av hur informationsflödet till och från Subsigno ser ut ur perspektivet från en liten teleoperatör. 20 , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 Den mindre teleoperatören använder en process där de via en API-lösning får information om nya kunder från Subsigno. Subsigno har innan informationsöverföringen kontrollerat giltiga bindningstider och därmed möjlighet till nummerflytt. Den mindre teleoperatören har därför smärre saker att ta hänsyn till som ångerätt etc. innan ordern faktiskt går igenom för den nya kunden, vilket de själva uppskattar sker i 80-90 % av fallen. En gång i månaden skickas en sammanställning med status för alla order som mottagits från Subsigno under perioden, vilket utgör underlaget för fakturering i senare skede. Hur Subsigno sedan fakturerar den mindre teleoperatören skiljer sig en del från andra samarbetpartners, då teleoperatören faktureras för alla kunder de får skickat till sig från API:et. Detta sker dock till ett lägre pris för teleoperatören som kompensation för att alla order inte går igenom. Problemområden Ett problem som den mindre teleoperatören ser i processen är hanteringen av personuppgifter, vilka behöver skyddas vid samarbete med andra företag. För att förhålla sig juridiskt rätt till den kommande lagen General Data Protection Regulation (GDPR) behöver teleoperatören även styra vilka personuppgifter som ska kunna raderas i framtiden. Utvecklingsmöjligheter Den mindre teleoperatören anser sig vara relativt anpassningsbar till förändringar och utvecklingsmöjligheter. Istället för att Subsigno ansluter sig mot teleoperatörens API, anser den mindre teleoperatören att Subsigno bör tillhandahålla ett API, för att underlätta hanteringen av order mellan teleoperatören och bolaget. Samtidigt innebär det större utvecklingsmöjligheter för Subsigno över tid. Den mindre teleoperatören ser en potentiell fördel med detta eftersom risken för spridning av känslig information om deras kunder minskar då färre aktörer har tillgång till deras affärssystem. 4.3 Kartläggning av mellanstor elleverantör Nedan följer en beskrivning av hur informationsflödet till och från Subsigno ser ut ur perspektivet från en mellanstor elleverantör. Den mellanstora elleverantören nyttjar en SFTP-server i samarbetet med Subsigno. När en användare byter abonnemang i Subsignos applikation till den mellanstora elleverantören laddas nödvändig information in i en .csv-fil som sedan laddas upp till en server. Elleveran- tören hämtar filen och laddar automatiskt in kundorderinformationen i sitt affärssystem. Efter detta genomförs en kreditprövning och fullmakt skickas till kundens nuvarande nät- ägare och elleverantör för att få anläggnings- och avtalsinformation. Slutligen skickas ett sammanfattande orderbekräftelse en gång i månaden till Subsigno med status för aktuella order. Problemområden I dagsläget kan två typer av problem identifieras. Det första är att processen kan ta lång tid på grund av bindningstider hos andra elleverantörer vilket gör att orderna hanteras manuellt , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 21 i processen. Eftersom det är en manuell process krävs att det kontinuerligt kontrolleras vilken status en kund har och om kund har ångrat sig vilket tar tid och risken ökar att kunden försummas. Det andra problemet är att orderhanteringsprocessen istället går för snabbt då en kund har rätt till en 14 dagar lång ångerrättstid. I detta skede kan bekräftelse av en godkänd kund redan ha skickats till Subsigno, som fakturerar enligt detta, innan ångerrättstiden gått ut och kunden tekniskt sett kan ångra sig. Därtill behöver, likt för den lilla teleoperatören, hanteringen av personinformation förändras så att de uppfyller kraven som ställs i samband med GDPR. Utvecklingsmöjligheter Den mellanstora elleverantören nämner att utvecklingspotential finns hos orderöverförings- processen, men att det är en dyrt projekt som skulle kräva lång framförhållning. En sådan utveckling är dessutom inte något som prioriteras av elleverantören vid tiden för intervjun. Istället för att ha en SFTP-lösning, som idag, uttrycker den mellanstora elleverantören att en API-lösning skulle vara önskvärd. Detta anser de skulle underlätta i flera steg av processen och länken mellan företagen skulle stärkas. I synnerhet med tanke på GDPR kan ett API vara lättare att implementera i enlighet med den nya förordningen. 4.4 Kartläggning av stor elleverantör Nedan följer en beskrivning av hur informationsflödet till och från Subsigno ser ut ur perspektivet från en stor elleverantör. Den stora elleverantören får kunduppgifter från Subsigno via ett API i deras egna af- färssystem där Subsigno laddar upp nödvändiga kunduppgifter, order och fullmakt för beställningen. Efter detta kontrollerar den större elleverantören kunduppgifterna med andra elleverantörer för att bekräfta vem kundens nuvarande elleverantör är och genomför bytet med med hjälp av fullmakt. Om kunden ej tillhör någon elleverantör sen tidigare påbörjas ett nytt avtal. Den större elleverantören genomför även en kreditprövning för att se om kunden har möjlighet att teckna ett abonnemang. Går kunden igenom prövningen påbörjas processen med abonnemangsbytet. Från orderläggning kan flera månader gå innan abonnemanget är aktivt och det är först då som Subsigno kan fakturera elleverantören. Denna fördröjning kan bero på kreditprövningar, bindningstid etc. Den större elleverantören skickar sedan via mail en utfallsrapport en gång i månaden som används som faktureringsunderlag för Subsigno. Problemområden Det problem som den större elleverantören framförallt upplever är att det inte finns någon direkt koppling mellan den större elleverantörens system och Subsigno. Detta leder till att om en kund får kreditavslag, ångrar sig eller att denne ej står på anläggningen måste ordern plockas ut ur systemet manuellt och återkoppling till Subsigno samt kund blir komplicerat. Likt tidigare samarbetspartners, nämner även den stora elleverantören att förändringar kommer att behöva ske i samband med att GDPR träder i kraft. 22 , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 Utvecklingsmöjligheter Den större elleverantören ansåg att det inte fanns någon större möjlighet att anpassa sitt affärssystem vid intervjutillfället då Subsigno stod för en så pass liten del av deras totala omsättning. De anser att förändringen, i så fall, bör ske hos Subsigno. 4.5 Sammanställning av övriga samarbetspartners Samtliga samarbetspartners använder antingen en API-lösning eller en SFTP-lösning. Den huvudsakliga skillnaden mellan dessa är att den första innebär direkt kommunikation mellan affärssystem och den andra har ett mellansteg där data laddas upp till en server som båda parter har tillgång till. Av Subsignos samarbetspartners så använder majoriteten en SFTP-server. Det begränsade antal företag som tagits hänsyn till under kartläggningen utesluter inte möjligheten att det finns andra kommunikationslösningar på marknaden. I dagsläget kan dock endast två huvudtyper identifieras. Det görs därför ett antagande att de fall som undersöks i projektet är representativa för, enligt Subsigno, relevanta marknader. 4.6 Möjlighet till ett interorganisatoriskt system Subsigno samt de samarbetspartner som intervjuats fick svara på en självvärdering om sina intressen för ett interorganisatoriskt system och maktposition på marknaden enligt det som beskrivits under avsnitt Möjlighet att få till ett interorganisatoriskt system (IOS), se appendix C. Resultatet av detta presenteras i figur 4.2. Figur 4.2: Kartläggning av intresset för ett interorganisatoriskt system mellan Subsigno och tre samarbetspartners. Samtliga relationer är av arketyp 4: Troligt med IOS , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 23 Som figur 4.2 illustrerar bildar Subsigno och den mindre teleoperatören arketyp 4, Subsigno och den större elleverantören arketyp 4 och Subsigno och den mellanstora elleverantören arketyp 4. Detta innebär att alla samarbetspartners tillsammans med Subsigno hamnar i gruppen för balanserade interorganisatoriska system, se avsnitt 2.1 för ytterligare förklaring. Det är därmed troligt att ett interorganisatoriskt system kan utvecklas mellan parterna, enligt modellen. 4.7 Sammanfattning av resultat och teori Nedan följer en sammanfattning av de trender samt förutsättningar som avsnitten Teori och Resultat kunnat identifiera för det processkoncept som ska tas fram. Trender • Snabba skiftningar och omställningar i Subsignos bransch ger ökade krav på att alla processer är agila och anpassningsbara. Dessa egenskaper bör därför genomsyra det framtagna processkonceptet. • Enligt japanska studier upplever företag att sina affärssystems prestanda alltmer försämras och behovet av att uppdatera sina affärssystem ökar. Nya affärssystem tenderar att bli alltmer anpassningsbara och molnintegrerade. Samma skifte bör processkonceptet därför kunna genomgå, för att kunna räknas som både skalbart och hållbart med tanke på nuvarande och framtida samarbetspartners. Subsigno • Från kartläggningen av Subsigno tydliggjordes att den största manuella arbetsbördan i dagsläget sker i steg 5, se avsnitt Flödesschema av Subsignos process för överföring av kundorderinformation. • Det finns ingen effektiv metod för att koppla samman den information som ges till respektive samarbetspartner när en order läggs i applikationen (Steg 1) och den information som skickas tillbaka med respektive kunds status (Steg 3). Att ha ett order-ID för respektive isolerad order som används i hela processen används alltså inte idag. • I det tredje och fjärde steget skickas personuppgifter mellan olika program och enheter, vilket gör att dessa steg identifierats som de mest riskabla med avseende på potentiell spridning och läckage av personuppgifter. • Vertikal skalbarhet är den typen av skalbarhet som Subsigno efterfrågar. Samarbetspartners • Utifrån kartläggningen av samarbetspartnerna framgår att två företag använder en API-lösning och ett företag en SFTP-serverlösning. 24 , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 • Alla tillfrågade samarbetspartners har i framtiden ett intresse av att utnyttja någon form av API-lösning. Två av tre samarbetspartners ser möjligheten att implementera en API-lösning i snar framtid. • Från kartläggningen synliggjordes respektive samarbetspartners möjlighet att kunna anpassa sig till ett nytt sätt att hantera orderinformationen med Subsigno. Den minsta aktören var mest anpassningsbar, den mellanstora aktören var delvis anpassningsbar och den största aktören var minst anpassningsbar. Möjlighet till interorganisatoriskt system • Det är troligt att ett interorganisatoriskt system kan utvecklas mellan de studerade parterna. , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 25 5 Konceptutveckling I detta kapitel presenteras först en analys av tidigare erhållen information. Därefter pre- senteras de koncept som utarbetats för respektive testomgång, varvat med en förklaring av tankegångarna under deras generering. Slutligen presenteras resultatet för respektive iteration. 5.1 Iteration 1 I detta delkapitel presenteras de koncept som testas i den första iterationen av projektets testfas, en diskussion kring respektive koncept samt resultat från itereringsfasen. Då processen för generering av lösningsförslag inleddes lades stort fokus vid att sålla bland de potentiella teknologier som den nya processen kan utvecklas från, se avsnitt Teori. I åtanke hölls det faktum att Subsigno är ett ungt fintech-bolag som därmed har begränsade ekonomiska resurser. Storleken på Subsigno togs även i beaktande, vilka teknologier som samarbetspartnerna i dagsläget använder samt resultatet från undersökningen av möjligheten att få till ett interorganisatoriskt system. Ett ERP-system ansågs olämpligt för Subsigno att utnyttja. Detta dels eftersom inköp och implementation av ett ERP-system kan bli dyrt och omfattande, vilket gör teknologin obefogad med de begränsade ekonomiska resurser som Subsigno har. En stor investering av detta slag riskerar även låsa in företaget i ett system. Detta kan då begränsa deras agilitet, som är en viktig faktor för att ett företag ska kunna vara framgångsrikt enligt Aysolmaz m. fl. (2018). Dessutom är ERP-system många gånger ett heltäckande affärssystem, vilket inte efterfrågas i den nya processen. Slutligen visar studien av Huang (2016) att små till stora företag upplevt en försämring gällande systemprestanda relaterat till ERP-system. Därmed påvisas viss risk för att systemet snabbt kan utdateras. SaaS valdes bort av liknande anledningar som ERP-system. Många gånger är det ett heltäc- kande system, vilket inte efterfrågas i processen. Dessutom är SaaS en tjänst som måste köpas och det anses då vara mindre fördelaktig än exempelvis ett API, som kan utvecklas internt. Av samma anledning valdes även integrationsplattform bort. En integrationsplatt- form skulle dessutom kräva en större grad av anpassning hos samarbetspartnern, i och med att lösningen kräver att de kopplar upp sig mot samma integrationsplattform. Kvar att behandla vid framtagandet av de första processprototyperna var SFTP och API. Dessa teknologier behölls dels eftersom teknologierna används av nuvarande samarbetspart- ners, vilket underlättar en eventuell implementation. Dessutom visade undersökningen av möjligheten att få till ett interorganisatoriskt system positiva resultat, vilket talar för att en API-lösning skulle vara möjlig. Efter att potentiella teknologier sållats lades större fokus vid de iakttagelser som gjorts i avsnitten teori och resultat, se sammanställning i avsnitt Sammanfattning av resultat och 26 , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 teori. Även skalbarhetsaspekten togs i beaktande då både det riktiga och dummy-koncepten utformades. 5.1.1 Koncept A Hela orderinformationsflödet startar när en användare lägger en beställning i Subsignos applikation. Se figur 5.1. På så sätt genereras en order som innehåller all nödvändig information som krävs. Förutom personuppgifter och beställningsinformation så har ett unikt order-ID genererats för beställningen, som följer med ordern genom hela flödet. Denna information ska vara på engelska. För att överföra alla order som lagts via applikationen till samarbetspartnern laddas .csv-filer dagligen upp till en SFTP-server, där samarbetspartnern själv kan hämta datan och börja bearbeta kundordern. Detta kan ta olika lång tid från kund till kund, exempelvis på grund av att gamla kontrakt har bindningstid kvar. Oavsett vad ska varje kundorder alltid ha en status som förklarar var i processen kunden befinner sig. Såväl om kundordern är godkänd eller inte så kommer den specifika statusen lagras i samarbetspartnerns affärssystem. Månadsvis sammanställs alla order-ID med specifik status och laddas upp av samarbets- partnern på SFTP-servern. Där kan Subsigno hämta informationen för att uppdatera sitt affärssystem med aktuell status och sedan fakturera alla godkända order enligt överenskom- melse. Figur 5.1: Flödesschema över processkoncept A. , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 27 5.1.2 Generering av koncept A Koncept A som illustreras i figur 5.1, togs fram som ett dummy-koncept och baserades på teknologin SFTP-server, istället för API likt de andra koncepten. Denna teknologi är äldre vilket förväntades vara en nackdel i och med att flertalet aktörer övergår till molnintegrerade affärssystem enligt studien som genomförts av Huang (2016). Det manuella arbetet skulle i detta processkoncept minskas i steg 5 genom att varje order får ett unikt order-ID som följer med ordern genom hela processen. Detta skulle således minska antalet felmatchningar, då scriptet matchar de interna orderna i Subsignos affärssystem mot de som skickats tillbaka från samarbetspartnerna. Därmed skulle det bli färre order som behöver matchas ihop manuellt. Genom detta skulle även ett sätt att koppla ihop den information som skickas i steg 1 till den som skickas i steg 3 skapas, se figur4.1. Mängden personuppgifter som skickas i processen skulle minska i detta koncept genom att samarbetspartnern endast skickar tillbaka order-ID och en status för ordern, till skillnad från dagens process där all persondata skickas tillbaka till Subsigno. Således skulle den säkerhetsrisk som överföring av personuppgifter innebär minskas, vilket ökar hållbarheten. En ytterligare fördel med detta koncept skulle vara att majoriteten av Subsignos nuvarande samarbetspartners redan använder sig av teknologin, se avsnitt Sammanställning av övriga samarbetspartners. Därmed skulle en implementering av ett nytt koncept som byggde på denna teknologi bli relativt smärtfri och kräva låg grad av anpassning. Två av tre samarbetspartners uttryckte sig vara anpassningsbara i låg till mellanstor grad, vilket gjorde att detta element i konceptet förväntades uppfattas positivt. Genom detta koncept skulle skalbarheten främst förbättras inom dimensionen typ. Den anses vara inkrementell, eftersom processen till stor del liknar den som för nuvarande används. Skillnaden är den marginella minskningen av manuellt arbete som införs i och med detta processkoncept, varvid skalbarhetsdimensionen inte anses vara radikal eller disruptiv. Eftersom det manuella arbetet endast skulle minskas marginellt i detta koncept underlättar det inte avsevärt om en större volym av faktureringsunderlag skulle införas i processen. Därför förväntades detta koncept inte uppskattas ur en skalbarhetssynpunkt. 5.1.3 Koncept B Hela orderhanteringsflödet startar när en användare lägger en beställning i Subsigno- applikationen och på så sätt genereras en order som innehåller innehåller all nödvändig information som krävs. Se figur 5.2. All information lagras i Subsignos affärssystem. Föru- tom personuppgifter och beställningsinformation så har ett unikt order-ID genererats för beställningen som ska följa med ordern genom hela flödet. Denna information ska vara på engelska. För att sedan få tillgång till alla order kan samarbetspartnern själv hämta datan via ett API som tillhandahålls av Subsigno för att börja bearbeta kundordern. Detta kan ta olika lång tid från kund till kund, exempelvis på grund av att gamla kontrakt har bindningstid kvar. Ifall kundens order godkänns ska status uppdateras på kunden av samarbetspartnern. Subsigno har då möjlighet att se aktuell status på ett order-ID genom sitt interna affärssystem. Samarbetspartnern uppdaterar dagligen Subsignos affärssystem med aktuell status direkt via Subsignos API och Subsigno kan sedan fakturera alla godkända order enligt överenskommelse. 28 , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 Här ligger en fördröjning från godkänd order till fakturering med samma tid motsvarande kundens ångerrätt, det vill säga 14 dagar. Figur 5.2: Flödesschema över processkoncept B. 5.1.4 Generering av koncept B Koncept B, som illustreras i figur 5.2, förväntades vara det mest uppskattade konceptet under testningen. Detta eftersom det skulle vara anpassningsbart med avseende på vilket affärssystem det är i kontakt med, samt är molnbaserat. Det skulle även underlätta den manuella arbetsbördan i steg 5 av den nuvarande processen hos Subsigno, i och med att information rörande orderstatus laddas upp direkt i Subsignos affärssystem. På så vis skulle en lösning på problemet med att para ihop den order som skickades från Subsigno till samarbetspartnern med den status som skickas tillbaka till Subsigno ges. Samtidigt skulle mängden personuppgifter som skickas mellan aktörerna bli mindre. Därmed skulle även säkerhetsrisken i hela processen minimeras i och med att endast en status tillsammans med order-ID skickas tillbaka från samarbetspartnern till Subsigno. Detta skulle vara fördelaktigt i och med införandet av GDPR. Att helt eliminera utbyte av personuppgifter är idag dock inte möjligt, eftersom samarbetspartnerna behöver information för att exempelvis föra över telefonnummer till ett nytt abonnemang. En annan aspekt som förväntades göra konceptet framgångsrikt i testomgången var det faktum att det byggde på en API-teknologi, som två av de tre intervjuade samarbets- partnerna idag använder och som alla intervjuade samarbetspartner uttryckt intresse för. Dessutom visade undersökningen av möjligheten att få till ett interorganisatoriskt system mellan respektive samarbetspartner och Subsigno positiva resultat. Därför förväntades API vara önskvärt som processkoncept. Dock skulle en API-lösning kräva viss anpassning , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 29 från samarbetspartnerna i och med att inte alla av de intervjuade samarbetspartnerna använder teknologin idag, samt att de behöver införa i sin arbetsprocess att aktivt uppdatera Subsignos affärssystem genom API:et. Detta är något som talar emot att konceptet skulle vara framgångsrikt. Koncept B skulle även förbättra skalbarheten i processen. Detta dels genom att konceptet bygger på en teknologi som möjliggör automatisk hantering av orderinformation, vilket gör att en ökad volym inte längre skulle vara problematiskt för Subsigno. Därmed kommer IT att ha en större roll i processen, vilket skulle förändra processens infrastruktur enligt Molinari och Concilio (2016). En annan skalbarhetsdimension som skulle förändras är dess typ. I och med att processen tidigare varit ad hoc kan denna process anses vara radikal i och med att den bygger på en i sammanhanget ny teknologi. Detta till skillnad från inkrementell som skulle innebära att processen förbättras i mindre steg, eller disruptiv som skulle innebära att processen helt konkurrerar ut andra lösningar. Eftersom ingen av dessa beskrivningar passar karaktären av detta processkoncept anses den vara radikal. 5.1.5 Koncept C Hela orderhanteringsflödet startar när en användare lägger en beställning i Subsigno- applikationen. Se figur 5.3. På så sätt genereras en order som innehåller all nödvändig information som krävs och detta lagras i Subsignos affärssystem. Figur 5.3: Flödesschema över processkoncept C. För att få tillgång till alla order kan samarbetspartnern själv hämta data via ett API som tillhandahålls av Subsigno för att börja bearbeta kundordern. Detta kan ta olika lång tid från kund till kund, exempelvis på grund av att gamla kontrakt har bindningstid kvar. 30 , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 Varje kundorder ska oavsett vad alltid ha en status som förklarar var i processen kunden befinner sig. Subsigno har möjlighet att se aktuell status på ett personnummer via ett API som tillhandahålls av samarbetspartnern. Samarbetspartnern uppdaterar sedan, vid behov, Subsignos affärssystem med aktuell status direkt via Subsignos API och Subsigno kan sedan fakturera alla godkända order enligt överenskommelse. Här ligger en fördröjning från godkänd order till fakturering med samma tid motsvarande kundens ångerrätt, det vill säga 14 dagar. 5.1.6 Generering av koncept C Koncept C, som illustreras i figur 5.3, var det andra dummy-konceptet som utarbetades. Till skillnad från de andra koncepten bygger detta processkoncept på två stycken API:er, där det ena API:et är kopplat till Subsigno och ett till samarbetspartnern. Detta ansågs vara möjligt till följd av resultaten från undersökningen rörande möjligheten att få till ett interorganisato- riskt system. Avsikten med två API:er skulle vara att öka kommunikationsmöjligheterna och utbytet av information mellan Subsigno och deras samarbetspartner. Detta skulle även ge en större flexibilitet om nya tjänster i samarbetet skulle utvecklas, exempelvis möjligheten att hämta kundinformation från samarbetspartnern inför en beställning. Således skulle en större grad av agilitet och flexibilitet kunna uppnås. Två API:er ansågs även kunna underlätta felsökning om en kundorder behövde granskas i efterhand, vilket i sin tur underlättar det manuella arbetet i nuvarande processteg 5. I och med att teknologin API användes automatiseras även en del av steg 5, eftersom uppdateringen av Subsignos affärssystem sker genom API:et. Ytterligare en faktor som förväntades underlätta det manuella arbetet i processen var att faktureringen inte skulle ske omgående. Istället skulle faktureringen ske efter samarbetspartnerns ångerrättstid, vilket då skulle minska den manuella ändringen av order i efterhand. För att koppla samman informationen som skickas i steg 1 med den som skickas tillbaka i steg 3 användes i detta koncept ett personnummer som unik orderidentifierare. Eftersom detta skulle bidra till spridning och användning av personuppgifter förväntades personnummer som orderidentifierare upplevas negativt av samarbetspartnerna. Detta processkoncept förväntas vara skalbart i och med att det till största del är auto- matiserat och har förmågan att kunna hantera en ökad volym av faktureringsunderlag. Det skulle även förbättra processen för hantering av faktureringsunderlag genom skalbar- hetsdimensionerna typ och infrastruktur, men även genom att dimensionen ägandeskap förändras. Då både samarbetspartnern och Subsigno tillhandahåller ett API hanteras och initieras skalprocessen av två parter istället för en. Detta anses öka processens skalbarhet, eftersom den utvecklas från två fronter. 5.1.7 Resultat iteration 1 Detta avsnitt presenterar en sammanfattning av resultatet från första itereringen i test- ningsfasen. Frågor som låg till grund för intervjuerna presenteras i appendix D. , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 31 Liten teleoperatör Den mindre teleoperatören såg flera fördelar med att implementera koncept B, då detta gör att Subsigno tillhandahåller ett API där orderläggningen sker. API är även enkelt för företaget att koppla upp sig mot och anses således vara implementerbar då det är Subsigno som öppnar upp sitt affärssystem. Subsigno har via sitt affärsystem kontroll över filerna, till skillnad från koncept A och C där de måste laddas upp av den mindre teleoperatören. De fyra första stegen i koncept B sågs som särskilt viktiga av teleoperatören, då de möjliggjorde för båda parter att se hur många order som skickats och tagits emot. Då den mindre teleoperatören faktureras annorlunda än övriga samarbetspartners, se beskrivning i avsnitt Kartläggning av liten teleoperatör, hade de ett förslag hur problemet skulle gå att lösas. Problemet, som uppstod till en följd av att det kan ta flera månader innan abonnemanget är aktivt, ansågs kunna elimineras i stor grad om Subsigno istället fakturerar företaget 3 månader efter att kunden lagt en order i applikationen första gången. Detta eftersom det då är mer sannolikt att kunden hinner följas upp om den nekas till abonnemanget. Då skulle allt i processen efter det att kunden fått sin status, se figur 5.2, i princip kunna tas bort i koncept B. Det skulle medföra att samarbetspartnern själv får följa upp kunderna. Därmed behövs inte nästkommande steg efter ”status skapas hos samarbetspartner”, då majoriteten av kunderna blir faktiska kunder och återkopplingen blir onödig. Koncept A ansågs av den mindre teleoperatören vara det sämsta alternativet. Detta eftersom den mindre teleoperatören då får ta ut en manuell fil och skicka varje dag, vilket hade ökat det manuella arbetet. Risker som den mindre teleoperatören såg med systemen var få, förutsatt att Subsigno agerar enligt avtal. En risk som dock togs upp var hantering av personuppgifter, även om den ansågs som mycket låg med en SFTP-lösning. Teleoperatören poängterade dock att ett API kan bli hackat från båda aktörernas håll, vilket ökar svårigheten att kontrollera att hanteringen av personuppgifterna inte missköts. En tvåvägslösning med API, likt koncept C, där den mindre teleoperatören öppnar upp sitt affärssystem ansågs därför göra företaget sårbart. Detta eftersom Subsigno kan koppla upp sig och se allt innehåll genom API:et, då det inte går att bara visa vissa delar av innehållet. Mellanstor elleverantör Den mellanstora elleverantören ansåg att koncept A var det bästa alternativet då denna lösning efterliknade deras, vid intervjutillfället, nuvarande lösning och därmed skulle bli enklast att implementera. Den mellanstora elleverantören hade vid tillfället av intervjun många projekt igång och ont om tid för andra projekt, därav blev en implementering av API som i koncept B och C mot Subsigno ett omöjligt åtagande. Företaget poängterade dock att en API-lösning är det bästa alternativet inför framtiden då det blir ett både säkrare och smidigare sätt att föra över information med tanke på GDPR. Att återrapportera order-ID som föreslogs i både koncept A och B tillförde ej något värde att implementera för den mellanstora elleverantören, men sågs som en smart idé ur ett säkerhetsperspektiv. Hade dock behovet av order-ID uppstått menade de att det skulle vara relativt enkelt att implementera. 32 , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 Den mellanstora elleverantören ansåg att alla koncept skulle förbättra deras situation men konstaterade att det inte fanns ett värde i att spendera kapital på en lösning som ej var hållbar i längden om marknad och arbetsmiljö skulle visa sig förändras. Hur framtiden såg ut var för den mellanstora elleverantören svårt att säga. De har redan en egen API-lösning mot sina andra samarbetspartners men deras affärssystem var i behov av uppdatering. Denna uppdatering var vid intervjutillfället bortprioriterad tills dess att andra åtaganden minskat. Dock visades intresse för att införskaffa sig uppdateringen på grund av hårdare lagkrav vid införandet av GDPR. Stor elleverantör Den stora elleverantören ansåg att inget av de presenterade koncepten skulle kunna im- plementeras i deras, vid intervjutillfället, nuvarande process rent praktiskt sett. Detta primärt på grund av att Subsigno är en så pass liten aktör att det inte skulle finnas någon ekonomisk vinning i att vidareutveckla de något mer komplicerade presenterade koncepten. Elleverantören poängterade dock att i teorin är både en API- och en SFTP-lösning bra alternativ som kan hantera större volymer data. Valet av integrationslösning beror enligt den stora elleverantören till stor del av ordervolymen som utbytes mellan parterna. Istället framförde den stora elleverantören ett eget förslag på en enklare lösningen som istället utnyttjade krypterade mail eller molnbaserad överföring av information. Kostnaden för dessa tekniska lösningar ansåg elleverantören vara mer i linje med intäkterna som samarbete med Subsigno genererar. Dessutom då det enligt avtal är Subsigno som ska föra in den information som krävs för en order i elleverantörens affärssystem finns det inget intresse för företaget att ändra på detta och själva börja hämta infomationen från Subsignos SFTP-server eller API. Då ingen tydlig rangordning av koncepten var möjlig för den stora elleverantören lades mer fokus på inverkan av individuella egenskaper inom koncepten. Företaget ansåg att order-ID var en bra idé i teorin, men en omöjlig lösning att implementera på grund av deras interna process. De ansåg att Subsigno ska, likt dagens system, matcha andra uppgifter och hitta det matchande order-ID:t internt. Återrapportering en gång i månaden var enligt elleverantören fullt tillräckligt, som i koncept A. Mot elleverantörer så var återrapportering av personnummer som unik identifierare för ordern, likt koncept C, inte unikt då en person kan stå på flertalet byggnader och därmed flertalet elavtal. Därför behöver informationen som skickas med en order kompletteras med ytterligare information för att kunna fungera i elbranschen. Subsigno Subsigno uttryckte att en API-lösning enligt koncept B och C vore mest önskvärt med argumentet att det är bättre att koppla samman ändpunkter än att ha ett mellansteg där filer laddas upp och ner. I termer av vilka möjligheter de såg med koncepten nämndes två områden; möjligheten till vidareutveckling samt standardisering. När det kommer till vidareutveckling poängterades det att när de föreslagna koncepten är fullt implementerade ökar möjligheten att utveckla , Institutionen för Teknikens ekonomi och organisation, Kandidatarbete, TEKX04-18-02 33 ny funktionalitet. Den standardisering som koncepten skulle utgöra för Subsigno skulle underlätta framtida samarbete i och med den tydlighet som beskrivningen utgör. Liksom möjligheter identifierades också risker, externt samt internt. Subsigno ansåg att det externt finns viss risk för att förändringen ligger fel i tiden. Vad detta innebär är att tekniska förutsättningar eventuellt inte finns hos samarbetspartnerna, alternativt att resurser inte kan allokeras till denna utveckling. Även internt hos Subsigno råder hård konkurrens om utvecklingsresurser vilket medför en fördröjning av implementation. Därmed skulle det manuella arbetet fortsätta tills en implementation kan prioriteras. Subsigno understryker att de har både teknisk kompetens och intern infrastruktur för att kunna tillhandahålla ett API. 5.2 Iteration 2 I detta delkapitel presenteras de koncept som testas i den andra iterationen av projektets testfas, en diskussion kring respektive koncept samt resultat från itereringsfasen. I avsnittet Resultat iteration 1 framgick det att den mindre teleoperatören föredrog koncept B och den mellanstora elleverantören föredrog koncept A. Den stora elleverantören ansåg att koncepten i teorin var bra, men att det inte var ekonomisk försvarbart att utveckla någon ny process i deras samarbete med Subsigno. De ansåg att krypterade mail var en tillräcklig teknik för överföring av så pass små volymer av information som de överförde till Subsigno vid intervjutillfället. Den mindre teleoperatören valde koncept B eftersom den bygger på en API-teknologi och ansåg att lösningen därför var enkel att implementera. Den mellanstora elleverantören valde koncept A på grund av att den byggde på en teknologi som de för närvarande använde och därmed skulle vara enkel att implementera. Dock uttryckte de ett intresse för att i framtiden implementera ett API-system. Sammantaget drogs därför slutsatsen att samarbetspartnerna till stor del baserat sina val i rangordningen av koncepten på implementerbarheten av dem och att detta i sin tur berodde på vilken teknologi som konceptet byggde på. Förslaget att använda order-ID som unik identifierare för en order mottogs med blanda- de reaktioner. Ingen av samarbetspartnerna använde sig av detta i dagsläget, men den mellanstora och stora elleverantören menade att detta var en bra idé. Dock ansåg den större elleverantören att detta skulle vara omöjligt att införa i processen, på grund av den begränsade omfattning samarbete som finns mellan dem och Subsigno. Därmed drogs slutsatsen att möjligheten till att införa ett order-ID som unik identifierare för en order i dagsläget inte var möjligt för alla samarbetspartners. Det bör däremot implementeras i takt med att Subsigno och deras samarbeten växer. Således blir argument, likt det som den större elleverantören framför, grundlöst. En annan anledning till order-ID bör implementeras i allt större grad är den säkerhetsfördel det medför, vilket bekräftades av den mellanstora elleverantören. Eftersom den mindre teleoperatören faktureras annorlunda från resterande samarbetspartner ansågs det ogrundat att i den andra konceptg