Arbetsflödens användbarhet i TeleCom-branschen

Transkript

1 Institutionen för datavetenskap Våren 2008 Arbetsflödens användbarhet i TeleCom-branschen Författare Henrik Tegman c03htn@cs.umu.se Handledare: Lena Palmquist

2 2

3 Sammanfattning Nipsoft är ett företag som bland annat arbetar med att utveckla produkter inom TeleCom och system för att prissätta samtal. Deras affärssystem utvecklas konstant och de håller nu på att utforska hur arbetsflöden skulle kunna hjälpa dem att få en bättre, effektivare och mer automatiserad verksamhet. Syftet med detta arbete är att utforska på vilka sätt arbetsflöden kan hjälpa Nipsoft inom detta område och hur de kan utnyttja denna teknologi. Detta gjordes genom att göra en studie på arbetsflöden och sätta sig in i de grundläggande funktionerna och de mönster som används för att skapa arbetsflöden. Resultatet blev en implementation av ett arbetsflöde. Abstract Nipsoft is a company that develops products for the TeleCom business and a system for putting a price on a call. Their business system is on a constant development and right now they are exploring how workflows can improve their system, more efficient and more automatic. The purpose of this work is to find out how workflows can help Nipsoft in those areas and how they can use this technology. This will be done by exploring the fundamental functions and patterns that are used when working with workflows. The result was an implementation of a workflow. 3

4 Innehåll Sammanfattning 3 Innehåll 4 1. Inledning Centrala begrepp Syfte och mål Konkret resultat Varför arbetsflöden? 8 2. Metodbeskrivning Centrala begrepp Fördjupningsstudier Genomförande 9 3. Vad är arbetsflöden? Centrala begrepp Definition av arbetsflöde Typer av arbetsflöden Innehållsbaserade arbetsflöden (Content-oriented workflow) Aktivitetsbaserade arbetsflöden (Activity-oriented Workflow) Vad är en affärsprocess Programmering på metanivå Episodisk programmering Konfigurerbara system Domänspecifikt Språk Visuell notation Verksamhetsprocesser Centrala begrepp Olika processer Processkartläggning Kvalitetsledningssystem Affärssystem Affärsprocesser inom TeleCom 19 4

5 4.2.5 Affärssystemet NBS Motiv till att använda arbetsflöden i affärssystem Effektivisering Kvalitet/kvalitetsarbete SOx Monitorering: 25 Att utrycka affärsproblem på hög nivå Verksamhetsstyrda processer (Flexibilitet, Flexibel styrning av verksamheten) Anpassad för reaktiva program Provisionering Kundanpassad affärslogik Uttrycksfullhet Inventering av etablerade designmönster Notation Control-Flow Patterns (Flödeskontroll) Sequence (Sekvens) Parallel Split (Parallellisering) Synchronization (Synkronisering) Exclusive Choice (Exklusivt val) Simple Merge (Enkel förening) Branching Patterns (Delningsmönster) Multiple Choice (Flera val) Synchronizing Merge (Synkroniserad förening) Multiple Merge (Flera föreningar) Discriminator (Diskriminator) Multiple Instance (Flera Instanser) MI without Synchronization (Flera Instanser utan Synkronisering) MI with a priori Design-Time Knowledge (Flera Instanser med kunskap innan design) MI with a priori Run-Time Knowledge (Flera Instanser med kunskap under körning) MI without a priori Run-Time Knowledge (Flera Instanser med kunskap innan körning) State-based Patterns (Tillståndsbaserade mönster) Deferred Choice (Uppskjutet val) Interleaved Parallel Routing (Interfolierad Parallel Routing) 33 5

6 6.5.3 Milestone (Milstolpe) Critical Section (Kritisk section) Interleaved Routing (Interfolierad Routing) Cancellation and Force Completion Patterns (Avbryt och påtvinga avslut mönster) Cancel Task (Avbryt Uppgift) Cancel Case (Avbryt Process) Complete Multiple Instance Task (Avsluta Flera Instanser Uppgift) Iteration Patterns (Iterations mönster) Arbitrary Cycles (Godtycklig Cykel) Structured Loop (Strukturerad Loop) Recursion (Rekursion) Provisionering inom TeleCom Vad är provisionering Definition av provisioning Provisionering av A-nummers trafikala status Telefoniabonnemang (TAB) Förval Kravställning av Referensarkitektur för Provisionering Lätt att utöka Lös koppling Väldefinierade gränsnitt mellan komponenter Baseras på etablerade mönster Specifika arbetsflöden Generella arbetsflöden Konfigurerbar Beskrivning av Referensarkitektur Designmönster Referensarkitektur Referensimplementation Bakgrund Systemutvecklingsmetod Förutsättningar / Begränsningar Analys och design Implementation 55 6

7 10.6 Sammanfattning Resultat Slutsats Nackdelar med föreslagen arkitektur Tänkbara utvecklingsmöjligheter Tack Referenser 58 7

8 1. Inledning 1.1 Centrala begrepp NBS (Nipsoft Business System): ett affärssystem utvecklat av Nipsoft som även är företaget som denna studie utförs hos. Därför kommer en del fokus ligga på deras system. Provisionering: inom TeleCom avses de aktiviteter som krävs för att aktivera, deaktivera eller tillståndsändra olika typer av tjänster för en kund. A-nummer: Ett A-nummer är ett vanligt telefonnummer, att aktivera ett A-nummer betyder att numret går att använda för att ringa. 1.2 Syfte och mål Målet med detta arbete har varit att beskriva hur stöd för arbetsflöden kan införas i ett befintligt affärssystem inom TeleCom. Uppgiften innefattar en mer teoretisk och abstrakt beskrivning av arbetsflöden (Workflows) exempelvis i termer av aktiviteter och olika typer av flödesmodeller. Rapporten innehåller en studie av NBS och vilka olika provisioneringar som kan göras till arbetsflöden. En viktig del i studien går ut på att identifiera (befintliga eller nya) arkitektur- och designmönster för dels ett processtödsystem, dels de affärssystem som publicerar tjänster för processtödsystemet. Syftet är att beskriva en plattform (arkitektur) som kan användas för att skapa ett bättre systemstöd för vissa specifika processer i verksamheten. Rapporten ger en teoretisk beskrivning av arbetsflöden samt påvisar några fördelar av att införa stöd för arbetsflöden på en generell nivå. Rapporten ger även en konkret beskrivning av en arkitektur för ett specifikt arbetsflöde inom TeleCom. Det arbetsflöde som valts är provisionering av tjänster kopplade till TeleCom. Samt att beskriva en i något avseende optimal arkitektur där ett antal fristående komponenter/delsystem på en metanivå 1 kan fås att samarbeta till att lösa en komplex uppgift genom att utföra en kedja av händelser/aktiviteter. En sådan kedja av händelser är exakt vad ett arbetsflöde utför. Fördelarna med arbetsflöden skall visa vilka effektiviseringar man kan uppnå och varför detta är värdefullt. En mindre implementation av ett arbetsflöde med ett lämpligt ramverk har gjorts. För att ge en insikt i hur ett typiskt arbetsflöde kan se ut och fungera, inga funktionaliteter fungerar, utan implementationen fungerar endast som en modell för hur ett riktigt arbetsflöde kan se ut. 1.3 Konkret resultat Ett av resultaten med arbetet är att implementera ett arbetsflöde, detta är en implementation av provisionering A-nummers trafika status, som dock inte blev fullständig. 1.4 Varför arbetsflöden? Nipsoft är ett utvecklingsföretag som arbetar på en egen produkt som kallas NBS och för att göra denna produkt bättre så har de valt att utforska arbetsflöden och dess potential. Anledningen till att arbetsflöden har valts som ett examensarbete är ett samarbete mellan mig och Nipsoft. Jag och Nipsoft pratade om arbetsflöden och undrade om jag ville göra ett examensjobb om detta. De anställda på Nipsoft har gått en kurs i arbetsflöden och har då sett potentialen i dem, men de har ingen som är kunnig inom området och därför skulle ett examensarbete som var inriktat på det vara bra för dem så att de kan avgöra om det är något som de skall fortsätta att utveckla och driva fram. 1 Meta level [Pattern-Oriented Software Architecture Volume 1 by Frank Buschmann] 8

9 2. Metodbeskrivning Detta kapitel går igenom hur arbetet har genomförts, vad som har studerats samt hur olika resultat har framtagits. 2.1 Centrala begrepp WWF (Windows Workflow Foundation): Microsofts ramverk för utveckling av stöd för arbetsflöden inom.net plattformen. 2.2 Fördjupningsstudier Fördjupningsstudierna bestod av läsning av [1] samt en genomgång av kursmaterial om arbetsflöden som fanns på Nipsoft. Information och läsning är även gjord på internet framförallt på [13] när det gäller designmönster för arbetsflöden. 2.3 Genomförande Arbetet började med att göra en fördjupningsstudie inom området eftersom kunskapen om själva ämnet var lågt från Nipsoft, Umeå Universitet samt mig. Efter att ha jobbat mycket med att läsa och förstå sig på ämnet började några skisser och planer att tas fram. Dessa bestod av olika UML-diagram på hur ett arbetsflöde skulle kunna fungera för en provisionering av en tjänst. När en referensarkitektur var framtagen så började själva implementeringen i WWF. Denna implementering tog ganska lång tid då det var en ny miljö och ett nytt sätt att arbeta på och därför hann endast en grund tas fram. Ingen färdig implementation som går att köra finns framtagen utan endast en förklaring på hur den bör fungera och vad som den skall innehålla. Kapitel 3 definerar och går igenom begreppet arbetsflöden. Medans kapitel 4 till 7 är en genomgång av olika begrepp och moduler som används inom arbetsflöden. Själva implementationen och arkitekturen finns beskriva i kapitel 8 till 10. Till slut avslutas rapporten med en slutsats i kapitel 11 samt tack till alla som hjälpt till med arbetet och en referenslista. 9

10 3. Vad är arbetsflöden? Detta kapitel tar upp arbetsflöden, diskuterar hur arbetsflöden kan definieras, vad de består av och vad vi kan använda dem till. Eftersom rapporten handlar om arbetsflöden så är detta kapitel mycket väsentligt. Ett av rapportens mål är att beskriva och granska arbetsflöden och detta utförs i detta kapitel. 3.1 Centrala begrepp DSL (Domain Specific Language): En typ av programmeringsspråk som är designat för vissa typer av problem och problemområden (domäner). Syftet är att kunna formulera lösning av problem på ett domännära sätt. Imperativ programmering: En typ av programmering där man ger en stegvis och detaljerad beskrivning eller instruktion av hur ett problem skall lösas. Deklarativ programmering: En typ av programmering där man på en högre nivå beskriver lösningen av ett problem. Detta kan exempelvis innebära att man beskriver kriterier för en korrekt lösning utan att man i detalj ger instruktioner för att nå lösningen. Workflow Runtime Engine: Ett ramverk för att exekvera arbetsflöden. 3.2 Definition av arbetsflöde I [15] beskrivs arbetsflöden på följande sätt: The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant* to another for action, according to a set of procedural rules. Ett arbetsflöde är en beskrivning av hur en specifik uppgift utförs genom att en uppsättning aktiviteter utförs i en viss ordning. Arbetsflödet specificerar från en given utgångspunkt och givna indata ett händelseförlopp genom aktiviteter och kontrollstrukturer, som skall utföras för att uppnå ett sluttillstånd. Arbetsflöden innebär ofta att man automatiserar hela, eller delar av en process inom en affärsverksamhet. Flödet kan exempelvis beskriva hur dokument, information eller andra typer av data skickas mellan, och hanteras av, olika intressenter efter givna regler. En beskrivning i detta fall syftar på ett stycke programkod skrivet i en speciell notation. Liksom alla andra notationer som används för att beskriva program (i betydelse att de beskriver hur en uppgift skall lösas), består arbetsflöden av programsatser (aktiviteter), kontrollstrukturer (villkorsstyrd exekvering, loopar, osv.) och tillstånd (variabler). Det fungerar alltså ungefär som imperativ programmering fast man använder sig av deklarativ programmeringsnotation som gör att man kan lyfta upp programmeringen på en högre nivå eller metanivå. Ett exempel på detta är att använda XMAL. XMAL är ett deklarativt XML-baserat språk som Microsoft tagit fram för att använda i.net, Windows Presentation Foundation samt WWF [10]. Ett arbetsflöde består egentligen av två separata flöden; dels ett kontrollflöde som styr exekveringsordningen av aktiviteter (och som bestäms av kontrollstrukturer som villkor och loopar), dels ett dataflöde som beskriver hur information kan flöda mellan olika aktörer. Program som utnyttjar detta kallas ofta för reaktiva program. D.v.s. de kan reagera på en yttre respons. Arbetsflödets uppgift ligger i att lösa ett problem eller en uppgift genom att specificera en flöjd av aktiviteter. Det som sätter igång ett arbetsflöde är en startpunkt, det kan t.ex. vara att man anställer en ny person på ett företag. Då startas ett arbetsflöde som består av att hon skall få en mailadress samt fysiska saker som att hon skall få en arbetsplats. 10

11 En startpunkt kan även vara något som är mer tekniskt som har med ett system att göra, t.ex. en kund som registrerar sig på en sida. Då skall hon få ett välkomstmail, hon skall läggas till i någon databas och sidan skall kanske uppdateras och visa mer information för kunden. Det finns alltid ett slut på ett arbetsflöde och detta kallas slutpunkt. En slutpunkt har endast till uppgift att avsluta flödet. Dock finns det ofta någon aktivitet som skall utföras innan man når till ett slut. Aktiviteter är grunden i ett arbetsflöde och representerar alla olika handlingar som kan ske. Detta kan exempelvis vara att anropa en metod, att exekvera en kodbit eller att göra en paus. Aktiviteter är det som bygger upp ett arbetsflöde. Aktiviterna är själva kärnan och en aktivitet kan innehålla flera andra aktiviteter och på det sättet bygga upp en sekvens av aktiviteter. Indata är den information som flödet får in, och kommer ofta med vid starten av ett flöde men ibland kan man även ha funktioner som frågar ett system efter indata. Utdata är den information som man genererat efter att ha kört ett arbetsflöde från startpunkten till slutpunkten. Ibland kan flödet dock göra indirekta saker, som att den modifierar data även om detta inte är en del av utdatan. När man aktiverar ett a-nummer kommer det att aktiveras i en teknisk plattform och de utdata som ges då är en rapport på hur aktiveringen gick. 3.3 Typer av arbetsflöden För att skapa en begreppsmodell måste vi utvärdera vilka olika typer av arbetsflöden det finns samt när och hur de används. De två mest distinkta är Content-oriented workflow och Activity-oriented Workflow. [8] Innehållsbaserade arbetsflöden (Content-oriented workflow) Ett objekt (exempelvis ett dokument) sätts i centrum för arbetsflödet. Alla steg i arbetsflödet kommer då på ett eller annat sätt att interagera med objektet och utan detta objekt skulle arbetsflödet inte göra något. Detta sätt att arbeta kan även beskrivas som en write-andreview process. Godkänt Ej publicerat Publicerat Ej godkänt Figur 1: Write-and-review Någon skapar ett dokument som sedan skickas vidare till en granskare som kontrollerar det. I detta skede är det endast kreatören och granskare som kan läsa dokumentet. Granskaren skickar dokumentet vidare till en publicerare när dokumentet är godkänt och alla eventuella ändringar är gjorda av kreatören. När publiceraren får dokumentet skall han godkänna det och sedan göra dokumentet publikt för alla. Detta illustreras i Figur 1. Innehållsbaserade arbetsflöden kallas även ibland för enhetsbaserat arbetsflöde (Entityoriented Workflow). I WWF kallas de för State Machine Workflows där man ser det som att det finns olika tillstånd som flödet kan befinna sig i, sen kan man byta status fram och tillbaka. Detta kan man se som de olika tillstånden som dokumentet i det ovan nämnda exemplet kommer att ha (ej godkänt, godkänt, ej publicerat, publicerat) Aktivitetsbaserade arbetsflöden (Activity-oriented Workflow) När man jobbar med aktivitetsbaserade arbetsflöden är det en uppgift som är i centrum vilket gör att vi måste tänka i lite andra termer än vid innehållsbaserade arbetsflöden eftersom man då måste ha ett objekt för att kunna göra något. Men med aktivitetsbaserat arbetsflöde kan man gå runt det hela. Exempelvis om vi jobbar med ett pass måste man ha ett pass för att 11

12 kunna interagera med det på något sätt, men med aktivitetsbaserat arbetsflöde kan man istället fokusera på en uppgift t.ex. skaffa kort till pass och skaffa ID till pass. På sådant sätt kan vi simulera ett Innehållsbaserat arbetsflöde. I WWF kallas detta för ett sequential workflow (sekventiellt arbetsflöde) eftersom de olika handlingarna kommer att följa en sekvens. Först skall aktivitet A ske innan aktivitet B kan ske. 3.4 Vad är en affärsprocess En affärsprocess är en uppsättning aktiviteter som tar indata och ger utdata. Dessa data kan vara både information och föremål, som kan behandlas av både människa och maskin. Affärsprocesser lämpar sig väldigt bra som arbetsflöden, därför kommer vi att titta närmare på dem. 3.5 Programmering på metanivå Enligt [3] är en metanivå något man har när en grupp med objekt påverkar beteendet på en annan grupp av objekt som ligger på basnivå. Detta innebär att man kan ändra på systemet utan att programmera direkt på basnivå utan att man istället kopplar ihop basnivåobjekt med de objekt som finns på en metanivå. Att förstå hur metanivåer ger en bättre förståelse för hur arbetsflöden fungerar. I Figur 2 ser vi exempelvis att den direkta Workflow Runtime Engine kommer att bete sig på olika sätt beroende på vilket arbetsflöde som vi har kopplat till den. Ett arbetsflöde består i sin tur av så kallade DSL-Aktiviteter, dvs. en form av förklaring av problemet som ligger nära dem som jobbar med problemet (Domänexperterna). På basnivå finns de konkreta implementationer som är mer kundspecifika aktiviteter eller önskemål som man då kan lösa på ett mer specifikt fall. Dessa konkreta implementationer kan utgöras av exempelvis en konfigurationsfil (även känt som en DLL-fil). Figur 2: Överblick av metanivå och basnivå Man kan jämföra detta med Imperativ programmering och t.ex. C# där vi skulle kunna se metanivån som den nivå man normalt jobbar med när man programmerar och att operationsnivå är den binära kod som faktiskt utförs, där DSL-aktiviteterna är metoder och 12

13 andra hjälpmedel. 3.6 Episodisk programmering Ett arbetsflöde är baserat på en reaktiv programmeringsmodell. Det betyder att arbetsflöden ofta ligger och väntar i någon form av sleep-mode och för att väcka dem måste någon form av händelse (event) inträffa. Detta gäller både för att starta arbetsflöden och när de körs; ofta är de en slags styrande enhet som skickar ut förfrågningar till andra delar av affärssystemen för att utföra uppgifter och när den styrande enheten har skickat en förfrågan väntar den sedan på ett svar innan den kan gå vidare och ta nya beslut på vad som skall ske beroende på vad svaret var. Denna egenskap kallas för Suspendable/Resumeable och är väldigt viktigt och något som många arbetsflödesmotorer är byggda runt. Begreppet syftar på att exekveringen av ett arbetsflöde sker stötvis. Arbetsflödet initierar exekvering av en aktivitet när den får en extern signal (tillsammans med eventuella indata till aktiviteten). När aktiviteten exekverats går flödet ned i vänteläge (passiveras, passivisation, suspend) i väntan på nästa signal som åter aktiverar flödet (aktiveras, resume). Den signal flödet väntar på kan exempelvis vara svar på en begäran (ett meddelande) som flödet skickat till ett externt system. Jämför detta med proceduell kod som inte kan stanna och vänta på ett svar, utan måste ha ett tillstånd som skickar meddelande när man får ett väntat event. Kod måste ändå skrivas men själva tillståndshanteringen, livslängden och korrelation från inkommande meddelanden fås av arbetsflödets runtime. 3.7 Konfigurerbara system Systemet blir konfigurerbart genom att ha många olika implementationer av ett arbetsflöde som kan kopplas till Workflow Runtime Engine och för varje arbetsflöde som kopplas på ges olika resultat. Ett arbetsflöde kan även ha aktiviteter som konkret realiseras av andra arbetsflöden, vilket ger en nästning av arbetsflöden där ett flöde kan vara en byggsten för ett annat flöde. Figur 3: olika plattformar Figur 3 visar att om vi byter ut provisionsplattformen mot ett annat arbetsflöde kommer vi att få ut en annan funktion. Eftersom affärssystemet och den tekniska plattformen inte är kopplade så kan de utvecklas utan att påverka varandra. Ett affärssystem är ett system som generellt ligger nära en kund exempelvis NBS, provisionsplattform är mellanlagret där arbetsflödet befinner sig och är grunden där arbetsflödet arbetar. Teknisk plattform syftar på fristående tekniska lösningar och en plattform som arbetsflöden kommer att anropa när de vill aktivera tjänster. 13

14 Även de olika aktiviteterna kan ses som byggstenar som används för att skapa ett arbetsflöde, sen kan flödena i sig använda andra flöden. För att ytterligare konfigurera dessa system och göra dem mer användarvänliga kan olika användare ha egna konfigurationer på hur deras flöde skall skilja sig från mängden. Detta hanteras genom att läsa in en konfigurationsfil som innehåller det som är specifikt för den kunden. Arbetsflöde 1 Arbetsflöde 2 Aktivitet A Aktivitet A Aktivitet B Aktivitet C Aktivitet B Figur 4: två oberoende arbetsflöden som kan använda varandra I Figur 4 ser vi två olika arbetsflöden samt ett antal aktiviteter och hur de är länkade. Vi skulle utan problem kunna använda arbetsflöde 2 som en del av arbetsflöde 1 genom att Aktivitet B i arbetsflöde 1 skickar en förfrågan till arbetsflöde 2 om att få ett svar på något som den kan, för att sedan gå i viloläge tills ett svar ges, arbetsflöde 2 kommer då att köra sitt flöde som består av några aktiviteter och sedan ge ett svar tillbaka, vilket gör att arbetsflöde 1 kan fortsätta igen. Observera att aktivitet B skulle kunna använda ett annat arbetsflöde istället för arbetsflöde 2 om den fick andra indata, eller kanske inte anropa något annat arbetsflöde alls utan bara fortsätta ner till aktivitet C om vissa indata mottages. 3.8 Domänspecifikt Språk En av de mest intressanta fördelarna med arbetsflöden är att de mycket väl lämpar sig för att skapa så kallade domänspecifika språk (DSL). DSL är programmeringsspråk som är designade för att klara av specifika uppgifter. Exempel på detta är spreedsheets eller macron. Macron som återfinns i Excel är specificerade för att lösa endast en uppgift. Detta kan vara allt från att lägga ihop summan av två celler till något mer avancerat men det är alltid en specifik uppgift som skall utföras och då lämpar sig DSL väldigt bra. Genom att skapa aktiviteter som realiserar specifika steg i verksamhetens affärsprocesser, kan arbetsflödet beskrivas av de som är mest kompetenta inom området, nämligen domänexperterna. En domänexpert är en person som är väl insatt i ett specifikt område och på så sätt är expert inom den domänen. Arbetsflöden bygger på en arkitektur på metanivå som tillsammans med domänspecifika språk ger exekverbara beskrivningar som fångar domänexpertens kunskaper, och som till och med kan skapas och underhållas av experten. Detta betyder att domänexperten kan förse en programmerare med väldigt specifik information som programmeraren kan använda för att skapa ett arbetsflöde som får specifika uppgifter. Arbetsflöden separerar domänkunskapen (meta level, workflow description) från den körbara 14

15 koden / tekniska plattformen. Specifikationen av arbetsflöden sker på en metanivå via ett domänspecifikt språk. 3.9 Visuell notation När man jobbar i WWF jobbar man i en visuell miljö vilket ger flera fördelar. Bland annat är det enkelt att i denna visuella miljö ta tag och släppa aktiviteter på plats. Man ser även tydligt hur flödet går, var det börjar och var det slutar och man behöver inte lägga ner mycket tid för att förstå vad ett specifikt flöde har för mål. Den visuella miljön är även bra för andra parter om man t.ex. vill visa upp sitt arbetsflöde och förklara hur det fungerar så är det lätt även för utomstående att förstå vad det gör. En visuell notation gör det även lätt att se vad som t.ex. ingår i en loop, vilket gör det lätt att förstå när arbetsflödet börjar bearbeta något och lätt att se när det slutar. En loop i koden gör att samma kod kan utföras flera gånger under vissa krav. Det är lätt att loopar som denna av misstag kan ha med för många eller för få aktiviteter. Genom att arbeta i en visuell notation ser man direkt vad som ingår i denna loop och kan då lätt avgöra vad som skall finnas med och om något saknas. 15

16 Figur 5: del av arbetsflöde i WWF Figur 5 visar delar av ett arbetsflöde gjort i WWF. I denna figur kan man se två if-else satser även kända som Exclusive Choise i arbetsflödesterminologi (se kapitel 0). De blåa fyrkanterna är metodanrop till andra system och de gröna fyrkanterna är väntelägen på svar från dessa metodanrop. Denna visuella representation i både färg och struktur gör det lättare att följa vad som händer samt vad som tillhör vilka delar, man ser vad som är inkapslat av en Exclusive Choice. Denna visuella notation är speciellt användbar för utvecklaren, under både utvecklandet samt för underhåll, men även för användaren som vill veta varför de måste göra det de blir tillsagda att göra. Den visuella notationen hjälper även IT-ansvariga som vill veta vad en applikation håller på med, eller bör hålla på med, eftersom detta syns tydligt. Visualiseringen gör det t.ex. lätt att skriva ut de sidor som visar upp hur arbetsflöden är uppbyggda för att sedan visa för andra och förklara arbetssystemet. 16

17 4. Verksamhetsprocesser Detta kapitel handlar om verksamhetsprocesser som är en beskrivning av hur företag organiserar sin verksamhet. Detta kommer att vara relevant för hur man senare skall tänka när man bygger upp ett arbetsflöde. Definitioner av de olika processerna och vad ett kvalitetsledningssystem är för något. Detta kapitel går igenom grunden för ett företags utveckling, vilka processer det är som styr deras verksamhet, för att senare gå ner på detaljnivå och titta på NBS och en specifik modul som kallas kundvård där tanken är att arbetsflöden skall kunna utföra de provisioneringar som görs. 4.1 Centrala begrepp CRM (Customer Relationship Management): är en förkortning för komponenten Kundvård i NBS. CRM är ett sub-system som har hand om all allmän information om kunderna som namn, adress, kontaktuppgifter mm. CDR (Call Data Record): en fil som representerar en händelse som skett i telefoninätet, exempelvis ett samtal. Rating: inom TeleCom så pratar man om att ratea samtal och att man gör en rating. Med detta menar man att man med hjälp av den information man har om samtalet (tid, typ av samtal, osv.) avgör med vad samtalet kommer att kosta. 4.2 Olika processer En verksamhetsprocess är en beskrivning av hur en regelbundet återkommande uppgift i en verksamhet skall lösas genom att en sekvens av aktiviteter utförs. [9] har följande definition av verksamhetsprocessen. En process är ett repetitivt använt nätverk av i ordning länkade aktiviteter som använder information och resurser för att transformera objekt in till objekt ut, från identifiering till tillfredsställelse av kundens behov. [9] En verksamhetsprocess beskrivs ofta i ett kvalitetsledningssystem [11], och de brukar normalt indelas i affärsprocesser, ledningsprocesser och stödprocesser som vi ser i Figur 6. Figur 6: Typer av processer i en verksamhet Kärnprocesser/huvudprocesser är de processer som uppfyller företagets mål (eller affärside), 17

18 d.v.s. det företaget vill producera och tjäna pengar på. Kärnprocessen måste därför skapa någon form av kundnytta eller mervärde som kunden (eller marknaden) behöver och är beredd att betala för. [11] definierar kärnprocesserna som: De processer vars aktiviteter förädlar varor och tjänster till en extern kund. Den process som tar emot en order från en kund, producerar önskad vara och levererar varan till kund är en typisk kärnprocess. Exempel på kärnprocesser inom olika verksamheter som t.ex. systemutveckling är själva programmeringen och skapandet av ett system. Inom vården är kärnprocessen att ta hand om sjuka människor. Ledningsprocesser /styrprocesser är de processer som är relaterade till styrning och ledning av verksamheten, och som utförs av företagets ledning. Ledningsprocesser finns hos alla företag, och företag inom olika branscher behöver ofta samma typer av ledningsprocesser. [11] definierar ledningsprocess enligt följande: Styrprocesser visar de aktiviteter som kärnprocesserna behöver för att verksamheten skall kunna bedrivas effektivt. Styrprocesser ger stadga likväl som kreativ anda, flexibilitet, likväl som regler och ramar, optimal resursfördelning och finansiell möjlighet, uppföljning och strategiska tankegångar. Den stora skillnaden mellan ledningsprocesser och stödprocesser är att ledningsprocessen är styrande och utförs av ledningen. Även ledningsprocesser kan dock ses som stödprocesser, och distinktionen mellan dessa typer av processer är inte alltid helt självklar. Typiska ledningsprocesser är exempelvis strategiskt målarbete, marknadsplaner och budget. Stödprocesser är ofta nödvändiga för att kärnprocessen skall kunna utföras, och de beskrivs därför ofta som de processer som bär upp verksamheten, och processer som indirekt ger kundnytta. [11] definierar stödprocesser som: Stödprocesser är processer som tjänar som stöd för såväl kärnprocesser som styrprocesser. Verksamheten förutsätter att det finns stöd så att målen uppnås. Det skapas indirekt värde för kunden och för de egna affärerna. Exempel på stödprocesser är rekryteringsprocessen, lönehantering, IT-support. Liksom för ledningsprocesser har företag inom olika branscher många gemensamma stödprocesser Processkartläggning För att en organisation skall fungera effektivt, måste den definiera och styra ett flertal sammanlänkande aktiviteter. En aktivitet som använder resurser och som styrs för att göra det möjligt att omforma insatser till utfall kan betraktas som en process. Ofta utgör utfallet från en process insatsen till nästa process [11]. Tillämpningen av ett system av processer inom en organisation tillsammans med identifieringen av och samspelet mellan dessa processer samt styrningen av dem är mycket viktiga för att skapa en tydlig helhetsbild av företagets arbetssätt. Begreppet process ska tolkas brett, eftersom det i sammanhanget inte enbart är frågan om produktionsprocesser utan även alla andra väsentliga processer. Många företag är utsatta för en stark konkurrens, och måste hela tiden effektivisera det dagliga arbetet för att överleva. Det är därför allt vanligare att företag gör en processkartläggning för att finna sätt att bli mer effektiva samt att ha en konstant utveckling av sin verksamhet Kvalitetsledningssystem Ett kvalitetsledningssystem är till för att det skall finnas en kontroll över vad som sker från det att man får en order till dess att denna order är avslutad och för att allt skall bli 18

19 genomtänkt, enkelt och effektivt. Genom att ställa kunden i fokus och lyssna på kunden kommer man att uppnå en bättre kvalité. Andra viktiga aspekter att ta hänsyn till är att se till att man gör rätt saker från början, att man konstant förebygger problem och om något skulle hända tar man lärdom av dessa problem. Nyttan med att ha ett kvalitetsledningssystem är att få en bättre ordning på sitt arbete, att få en bättre lönsamhet, att förebygga problem och att förbereda sig på dem, så att man får nöjdare och trogna kunder. [5] Affärssystem Syftet med ett affärssystem är att ge verksamheten ett mer eller mindre heltäckande systemstöd för de olika processerna. Ett affärssystem måste ha stöd för de viktigaste stödoch ledningsprocesser men kan inte ha stöd för alla. Det är viktigt att affärssystemen är tillräckligt stora för att täcka in mycket av behoven så att kunden inte måste nyttja många olika system för olika delar Affärsprocesser inom TeleCom TeleCom-branschen skiljer sig inte från andra branscher utan även här behövs affärsprocesser, ledningsprocesser och stödprocesser. Typiska ledningsprocesser inom TeleCom är marknadsplanering, processer för styrning av verksamheten och budgetplanering. Stödprocesser inbegriper mestadels processer som är nödvändiga för att affärsprocessen skall fungera. Detta kan exempelvis vara administrativa processer som att hantera löne- och personalfrågor, processer för att nyanställa personal, eller processer för att hantera den tekniska infrastrukturen i form av IT-support. Själva affärsprocessen för ett TeleCom-bolag går ut på att bl.a. sälja och leverera telefoni. För ett systemutvecklingsbolag handlar det snarare om att utveckla system och att upprätthålla avtal Affärssystemet NBS Ett affärssystem är en komplex produkt som innehåller många olika komponenter, allt från webbsidor för självbetjäning där kunder själva kan utföra enklare administrativa uppgifter till förädlingssystem som prissätter förbrukningsinformation och skapar fakturor och statistik. Figur 7 visar en skärmbild på hur gränsnittet i NBS ser ut för kundvårdsmodulen vilket är den del av systemet som denna rapport fokuserade lite mer på. Flera interssanta arbetsflöden återfinns i denna modul, eftersom det mesta som görs i kundvården är provisioneringar och denna rapports mål är att studera olika provisioneringar inom NBS som man kan göra arbetsflöden av. 19

20 Figur 7: Kundvårdsmodulen i NBS Stödet för affärsprocessen i NBS är de delar i systemet som samlar in och förädlar kunders konsumtion av produkter och tjänster, det vill säga alla stödprocesser som bl.a. ingår i blocken Förädling och Efterbearbetning. Stödet inbegriper även den bearbetning som krävs efter det att en produkt har levererats. Fakturering av allt som Nipsoft gör från kundsupport till utveckling av system ingår också i affärsprocessen. Stödet för ledningsprocesser finns i NBS samlade under ett block som Nipsoft kallar för just Ledning. Distinktionen mellan ledningsprocesser och stödprocesser är inte helt tydlig i NBS, så i detta block ingår även stöd för processer som normalt betecknas som stödprocesser. Blocket innehåller komponenter för statistik, uppföljning och ekonomi vilket förser ledning med affärskritisk information som behövs för att styra verksamheten på ett effektivt sätt. Den statistik som NBS producerar, och som skapas från information från förädling och kundernas konsumtion, ger exempelvis ledningen underlag för att besluta om kundsegement för nyförsäljning, målsättningar, marknadsplaner och budget. NBS har ett stort antal komponenter som realiserar och stöder olika typer av stödprocesser som operatören behöver. Säljprocessen stöds exempelvis via en kundvårdsmodul (CRM) där kundhanteringssystemet ingår och som används för att underhålla den kundinformation som affärsprocessen behöver (telefonnummer, namn, adressuppgifter etc.). Övriga stödprocesser som stöds i NBS är de resterande som t.ex. självbetjäning som tillåter att kunder själva administrerar delar av den egna informationen ( Mina sidor ). Nipsofts organisation kan förklaras utifrån Figur 8 som är uppdelad i olika komponenter varje komponent förklaras i detalj då de är viktiga för Nipsofts verksamhet. 20